入られる前提で守る

第1回で見たとおり、攻撃者は侵入した後、管理者権限を奪い、セキュリティソフトを止め、社内に広がり、バックアップを壊し、データを盗んでから暗号化します。この回の6つの対策は、それぞれの段階に対応しています。

目的：自社ドメインを名乗るなりすましメールを、受信側で拒否させる。自社に届く悪性メールを減らす。

なぜ必要か

• フィッシングは侵害の16%で使われ^[G1]、ビジネスメール詐欺はIPA「情報セキュリティ10大脅威 2026」の10位です^[J5]。
• 大手のメールサービスは、送信者に認証を求めています。Gmailは2024年2月1日から、1日5,000通を超えて送る送信者に、SPFとDKIMの両方、DMARC（ポリシーはnoneでも可）、From:ドメインのアライメントを求めています^[G19b]。Yahooも同様の要件を課しています^[G19c]。
• 総務省は2025年9月1日、電気通信事業者の団体に、DMARCのポリシーを「隔離」「拒否」に設定するよう要請しました^[J14]。経済産業省・警察庁・総務省は2023年2月1日、クレジットカード会社等に、メールを送信しないドメインも含めた全ドメインでのDMARC導入と、受信拒否ポリシーでの運用を要請しています^[J14b]。

やること

1. SPF：自社ドメインからメールを送ってよいサーバーを、DNSに登録します。外部サービス（メール配信、SaaSの通知など）から自社ドメインで送っている場合は、それも含めます。
2. DKIM：送信メールに電子署名を付ける設定をメールサービスの管理画面で有効にし、公開鍵をDNSに登録します。
3. DMARC：SPF・DKIMの結果に基づき、受信側にどう扱ってほしいか（none＝何もしない／quarantine＝隔離／reject＝拒否）と、集計レポートの送付先をDNSに登録します。段階的に強め、p=noneのまま止めません（図4）。
4. 受信側の対策：メールサービスの迷惑メール・マルウェアフィルタ、添付ファイルの検査、外部からのメールであることの表示を有効にします。

メール認証は、SCS評価制度★3の評価基準には含まれていません。このガイドは、行政の要請と大手メールサービスの送信者要件を理由に、★3を超えて推奨しています（第7回6節）。

目的：盗まれても使えない形で保存し、そもそも不要なデータを持たない。

なぜ必要か

• 流出の被害の大きさは「何を持っていたか」で決まります。タイムズカーの事案では、退会者等の本人確認書類の画像も対象になりました^[J19]。個人情報保護委員会は、保管している個人データの必要性を、法令等の根拠とともに確認するよう注意喚起しています^[J11b]。
• KDDIの事案では、約762万名分のパスワードが平文で保存されていました^[J12]。
• 国家サイバー統括室は「保存データを暗号化する」「パスワードや認証情報を平文で保存しない」「利用目的を終えた情報は速やかに削除する」ことを求めています^[J8]。個人情報保護法第22条は、利用する必要がなくなった個人データを遅滞なく消去する努力義務を定めています^[J11]。

やること

最初に機密区分を決めます★3 3-1-4。自社の情報について、機密の特定、機密区分のレベルの判定と表示、区分に応じた取扱方法、取扱エリアの区分と制限を含む管理ルールを定め、年1回以上内容を点検します^[J7b]。以下の1〜4は、この区分に応じて適用します。生成AIに入力してよい情報の区分（第6回）も、この機密区分に合わせます（本ガイドの提案）。

1. 持たない：第4回で作ったデータ台帳で、データごとに保存期間を決めます。法令・契約上の保存期間を過ぎたもの、利用目的を終えたものを削除します^[J8]。本人確認書類の画像のように漏えいしたときの影響が大きいものは、確認した後に保持しない設計を優先します（本ガイドの提案）。
2. 暗号化する：PC・スマートフォンのディスク暗号化（2節）、サーバー・クラウドストレージ・データベースの保存時暗号化、通信の暗号化（HTTPS）。
3. パスワードはハッシュ化して保存する：自社で利用者のパスワードを保存するシステムを持つ場合、平文や元に戻せる暗号化ではなく、パスワード保存用のハッシュ関数で保存します（図7）^[G20]。委託開発やパッケージの場合は、この点を委託先・ベンダーに確認します。
4. アクセスを絞る：個人情報・機密情報にアクセスできる人・システムを最小にし、大量の閲覧・ダウンロードを記録します（7節）。

目的：侵入や不正を早く見つけ、起きたことを後から調べられるようにする。

なぜ必要か

• Mandiantの調査（M-Trends 2026）では、侵入から発覚までの世界中央値は14日で、自組織で検知できたのは52%でした^[G2]。
• アスクルの事例では当時のログが削除されており、原因の完全な究明が困難とされました^[J17]。半田病院では、インシデント後のファームウェア更新でログの調査ができなくなりました^[J16]。
• 国家サイバー統括室は、ログの取得・保管と大量アクセスの監視を求めています^[J8]。個人情報保護委員会のガイドラインは、手法の例として「ログ等の定期的な分析により、不正アクセス等を検知する」を挙げています^[J11]。

やること

1. 取るログを決める（本ガイドの提案）：①認証（サインインの成功・失敗、MFA）、②VPN・リモート接続、③管理者の操作、④ファイアウォール・プロキシ、⑤EDR・マルウェア対策のアラート、⑥クラウドサービスの監査ログ、⑦個人情報を扱うシステムのアクセスログ。
2. 攻撃者に消されない場所に集める：端末・機器の中だけに置かず、別の場所（ログ管理サービス、SIEMなど）に送ります。
3. 保存期間を決める：侵入の発覚が遅れることを前提に、調査に必要な期間を確保します（期間は自組織の要件で決める）。クラウドサービスはライセンスによって保存期間が短いことがあるので確認します。
4. 見るべき兆候を決めて、自動で通知する（本ガイドの提案）：海外からの管理者サインイン、短時間の大量のサインイン失敗、MFAの登録変更、管理者権限の付与、EDRのアラート、深夜・休日の大量ダウンロード、バックアップの削除操作。
5. インシデントのときは、ログを保全してから対応する：機器の更新・初期化の前に、ログを取り出します（半田病院の教訓^[J16]）。