第1回で作った資産台帳を使い、アカウントや端末の設定を一つずつ開いて、対策が実際に有効か確認します。確認できない項目は、次の作業を決めて記録します。
本記事は2026年11月2日公開のNIST CSWP 50正式版、主に2、14–18ページに基づきます。手順の順番、記入表、完了の目安は筆者による整理で、NISTの認証手順ではありません。高価なツール一式の購入も前提としません。サービスが設定に対応していない場合は、制約を記録し、代替策を検討します。
1. ほかの業務を左右するアカウントを確認する
メール、銀行・決済、機密ファイルの保存先、パスワードマネージャー、重要なクラウドサービスから確認します。バックアップ用アカウントも含めます。NISTは、対応するすべてのアカウントでMFAを有効にし、特に機密情報や高い権限を扱うアカウントでは耐フィッシング方式を重視するよう勧めています。原文2、15ページ
アカウントごとに次を実施します。
- 確認済みのサービス入口から安全設定を開き、現在の認証方式と選択肢を確認する。
- 提供されるMFAを有効にする。耐フィッシング方式があれば優先して検討し、利用する。原文は、PINや指紋などの要素と組み合わせるパスキーを一般的な例として挙げている。
- 復旧用の連絡先と提供元の復旧手続きを確認する。入口や管理された保管場所を記録し、通常の台帳にはパスワード、トークン、復旧コードを書かない。
- パスワードを使うアカウントでは、強く、使い回さないパスワードやパスフレーズを使う。パスワードマネージャーによる生成・保存も検討する。
原文2ページのパスワード長の推奨は15文字以上です。原文の推奨値であり、すべての製品に共通する適合認証の条件ではありません。パスキーやMFAを使っても、アカウントの乗っ取りを完全に防げる保証はありません。原文も、一部のMFA方式はフィッシングの影響を受け得ると述べています。通常の確認コードを、そのまま耐フィッシング認証と同一視しないでください。
設定や復旧方法を確認できないだけの場合は、要確認事項として残し、確認済みのサービス窓口や提供元のサポートに相談します。異常が起きている、または乗っ取りが疑われる場合は、第3回の事故対応手順を参照します。侵害が疑われる端末やアカウントを復旧作業に使わないようにします。
2. 日常の権限と外部アクセスを小さくする
原文は、日常業務では管理者アカウントを常用せず、標準ユーザーを使うことを勧めています。共用端末を使う家族には別のアカウントを用意し、機密の業務データにアクセスさせません。外部事業者のアクセスは、具体的な作業に必要な権限と期間に限定し、定期的に見直します。原文14ページ
台帳に沿って端末のアカウントとクラウドのメンバーを確認し、現在の利用者、権限の必要性、作業の終了時点を記録します。契約終了後は不要なアクセスを削除します。標準ユーザーを勧める記述は、唯一の管理者や未確認の復旧経路をむやみに削除する指示ではありません。
顧客向け業務で端末の共用が必要な場合は、私用と業務用のアカウントの境界を記録します。分離できない部分は既知のリスクとして残し、「最小権限を完了」として扱わないようにします。
3. 初期パスワード、更新、サポートを確認する
ルーター、プリンター、そのほかの接続機器も含め、台帳の機器を一つずつ確認します。
- 製造元の初期パスワードを使っていれば変更し、確認した機器を記録する。新しいパスワードは台帳に書かない。
- OSとアプリの利用可能な更新を適用し、適切な場合は自動更新を有効にする。
- 提供元にサポート終了を確認し、安全更新が提供されなくなった製品やサービスの置き換えを予定する。
- 適切なセキュリティソフトを維持し、更新と検知が動作しているか確認する。
NISTは14ページで、少なくとも月に1回の更新確認と、少なくとも年に1回のセキュリティ意識向上の研修を勧めています。17ページでは、計画的に更新を調べ、実行可能な限り速やかに適用することも勧めています。月次確認は定例の確認頻度の推奨であり、すでに見つかった安全更新を翌月まで延期する理由にはなりません。原文14、17ページ
確認後は、サポート中の機器、更新済みの機器、制約によって未対応の機器を区別して示せるようにします。一つの「問題なし」という表示で、その違いを覆い隠さないようにします。
4. 決済、請求書、アカウントの変更は別経路で確かめる
緊急の送金、振込先や請求書の変更、ログインを求めるメッセージが届いたら、操作を一度止めます。以前から分かっている信頼できる連絡先で相手に確認し、疑わしいメッセージに書かれた電話番号やリンクを確認手段に使わないでください。実際の送信元アドレスを見ることは役立ちますが、表示名だけでは判断できません。原文16ページ
次の筆者作成の確認記録を利用できます。
何を変更する依頼か：____
確認に使った既知の信頼できる経路：____
誰に確認し、どのような結果だったか：____
確認時刻と次の対応：____確認できていない依頼は保留し、急かされても確認を省略しません。この手順は依頼を調べる助けになりますが、すべての詐欺を見抜ける保証はありません。すでに権限のない操作が行われた場合は、事故対応へ移ります。
5. 異常を見つけ、通知の受け手を決める
サービスが対応する場合はログと、新規ログイン、パスワード再設定、銀行・決済取引、ドメイン情報変更の通知を有効にします。通知の届く経路と、異常を発見した後に対応計画へ移る手順を確認します。原文はこれらを検知の出発点として挙げており、小規模事業者に常時監視センターの設置を求めているわけではありません。原文18ページ
働く場所も対象です。自宅、カフェ、共有オフィスごとに、画面ロック、端末の保管、端末が実際に備える追跡・遠隔消去の機能を確認します。すべての端末が対応するとは仮定せず、共通の消去コマンドも示しません。
見直せる実施記録を残す
| 項目 | 現在の状態と根拠 | 未対応事項と次の作業 |
|---|---|---|
| 重要アカウントの認証と復旧 | 確認済みの設定と入口 | 機能の制約や要確認事項 |
| 端末と外部の権限 | 実際の利用者と必要な権限 | 削除・縮小するアクセス |
| 初期設定、更新、サポート | 確認日とサポート状況 | 未更新の理由と対応方法 |
| 通知と依頼の確認 | 通知先と計画の保管場所 | 未確認の通知や連絡先 |
筆者が設ける完了の目安は、重要アカウントの認証と復旧状態を説明でき、端末と利用者が台帳に対応し、未適用の更新には次の対応があり、異常通知の届く場所が分かることです。確認日を残し、業務の変化に合わせて見直します。適合証明書や、事故が起きない保証にはなりません。
依存関係と責任を確認するには第1回：資産とリスクの台帳、続いて第3回：バックアップ、準備、復旧を参照してください。