守りの運用ガイド：記録・可視化とデータ・活動の保護

安全性は、仕組みを入れた時点で完成するものではありません。すべての活動を記録し、運用者がその記録から状況をつかみ、異常に気づいて対応する運用が回って初めて保たれます。このガイドは オフィス環境の認証・認可ガイド：従来型からゼロトラストへ、企業環境の連携ガイド：ID・端末・証明書・ネットワークはどうつながるか に続く第3部です。前半では環境の活動がどう記録・可視化されるかを、後半では利用者の活動とデータそのものをどう守るか（データの重みづけと利用者の行動の把握）を解説します。

1. 位置づけ：なぜ「運用」が安全性を支えるのか

第1部・第2部で扱った認証・認可・端末管理・ネットワーク制御は、いわば「鍵と門」です。しかし鍵は盗まれますし、正規の利用者が許された範囲で悪いことをすることもあります。そこで必要になるのが、記録し、見て、気づき、止める「運用」と、守るべきデータそのものに印を付けて守る「データ中心の保護」です。

運用が安全性を支える理由は3つあります。

• 抿止力：「記録されている」と利用者が知っていること自体が不正を抑える。
• 早期発見：侵入や不正は、入口で止められなかった場合も、記録から早く気づければ被害を小さくできる（ゼロトラストの「侵害を前提とする」）。
• 説明責任：事故の際に「何が、いつ、どこまで」を示せる。影響範囲を特定できないと、最悪を想定した報告や対応が必要になる。

2. 記録の全体像：誰が何を記録し、どこに集まるか

第2部で登場した仕組みは、それぞれが自分の担当範囲の出来事を記録しています。しかしバラバラのままでは「同じ人の同じ時刻の出来事」をつなげられないため、運用では大きく3つの集約先に集めて見ます。

3つの集約先は役割が異なります。

• Defender XDR：Microsoft のセキュリティ製品の検知結果をつなぎ合わせ、「1つの攻撃」として見せる。対応（端末の隔離など）もここから行う。
• Sentinel（SIEM）：オンプレのイベントログやネットワーク機器、他社製品も含めた全ログの長期保管と横断分析を担う。独自の検知ルールも作れる。
• Purview 監査：M365 上で「誰がどのファイルを開き、共有し、削除したか」を記録する。事後調査や法的な証跡の土台になる。

オンプレの ADDS を残す場合、DC 上の認証の動きは Defender for Identity が監視し、Pass-the-Hash など第1部第3章で触れた攻撃の兆候を検知します。

3. 主なログの中身と保持期間

各サービスの標準の保持期間は、事故調査に必要な期間より短いことがほとんどです。攻撃は発覚までに数か月かかることもあるため、「どのログを、どこに、何年残すか」を最初に決め、Log Analytics（Sentinel）やストレージへ転送します。

ログを読むときの「共通の鍵」

異なるログをつなぐには共通の項目が必要です。主に「利用者（UPN）」「端末（デバイス ID・ホスト名）」「IP アドレス」「時刻」の4つです。第2部で扱った命名規則や ID の一元化は、ここで「ログをつなげられるか」に直結します。共有アカウントがあると「誰がやったか」がわからなくなるのも同じ理由です。

また、ログはそれ自体が守る対象です。攻撃者は痕跡を消そうとするため、ログの削除や転送設定の変更ができる権限を絞り、その操作自体をアラートにします。

4. 状況把握の仕組み：アラートから対応まで

記録は集めるだけでは使えません。1000名規模でもサインインや端末のイベントは1日に膨大な件数になるため、「機械が異常を拾い、関連するものをまとめ、人が判断して対応する」仕組みを作ります。

アラートとインシデントの違い

アラートは個々の製品が出す「怪しい出来事」です。インシデントは、同じ攻撃に属する複数のアラートを束ねたものです。例えば「フィッシングメール受信（メール）」「不審な場所からのサインイン（ID）」「不審なプロセス（端末）」を Defender XDR が1件にまとめることで、運用者は攻撃の全体像を一度に見られます。

自動対応と、第1・2部の仕組みとのつながり

封じ込めで使う操作は、第1・2部で扱った仕組みそのものです。

第2部第3章の「シグナルが集まる流れ」により、検知結果がそのまま次のアクセス判定に反映されるのが、ゼロトラスト環境の運用の強みです。

夜間や休日も含めて人が常時監視するのは難しいため、自社では自動対応の範囲を決め、監視と初動は SOC/MDR サービスに委託する構成も一般的です。

5. 日々の運用で見るもの

インシデント対応が「何か起きたとき」の運用だとすれば、定期的な確認は「守りが崩れていないか」を見る運用です。仕組みは放っておくと、例外の増加、更新漏れ、期限切れで少しずつ弱くなります。

Microsoft Secure Score のような設定健全性の指標も、「前月より弱くなっていないか」を見るのに役立ちます。点数を上げること自体より、下がった理由を説明できることが重要です。

6. 環境の守りから活動の守りへ

ここまでの守りは、主に「外からの攻撃」と「未管理のもの」を想定していました。しかし情報漏洩の多くは、正規の利用者が、管理された端末で、許されたアプリを使って起こします。誤送信、公開範囲の設定ミス、個人クラウドへのコピー、退職前の持ち出しなどです。これらは入口の検問をすべて通過するため、守る対象を「環境」から「データとその扱い」へ広げる必要があります。

「重要度に応じて変える」ためには、まずデータに重みを付ける必要があります。すべてを最高レベルで守ると業務が回らず、すべてを同じに扱うと本当に大事なものが埋もれます。次の章がその仕組みです。

7. データの重みづけ：分類と秘密度ラベル

データ保護の出発点は「何がどれだけ大事か」を決め、データにその印を付けることです。Microsoft Purview の秘密度ラベルは、ファイルやメール、Teams・SharePoint サイトに付ける「重さの印」で、一度付けるとそのデータについて回り、各所の守りがそれを見て強さを変えます。

ラベルの例は、既存の情報管理規程の分類に合わせて決めます。段階を増やしすぎると利用者が選べなくなるため、3〜5段階が一般的です。

ラベルをどう付けるか

ラベル運用の注意点

• 引き下げの理由入力：ラベルを軽くするときに理由を求め、監査ログに残す。持ち出し前の「ラベル外し」は典型的な兆候。
• 暗号化の副作用：暗号化したファイルは、取引先や一部のアプリが開けないことがある。暗号化するのは上位ラベルに限るのが一般的。
• 教育と定着：利用者が意味を理解しないと、すべて「公開」やすべて「極秘」になる。各ラベルの具体例を示す。
• 既存データの棚卸し：Purview のデータ分類（コンテンツエクスプローラー）で、どこに機密情報があるかを先に可視化する。

第2部では「全員に同じ基準」で守るポリシーを中心に解説しましたが、ラベルがあると、条件付きアクセスの「認証コンテキスト」で「極秘サイトを開くときだけフィッシング耐性 MFA を求める」ような、データの重さに応じた入口の強度調整もできます。

8. 利用者アクティビティの把握

利用者の活動を把握する仕組みは、「1回の操作をその場で止める」ものと、「行動の累積からリスクを見つける」ものに分かれます。前者は誤操作に、後者は意図的な不正に強い仕組みです。

インサイダーリスク管理の考え方

「大量ダウンロード」はそれだけでは不正とは言えません。しかし「退職日が決まった人が、社外秘ラベルのファイルを大量にダウンロードし、ラベルを外して USB にコピーした」という組み合わせは強い兆候です。インサイダーリスク管理は、こうした「きっかけ」と「続く行動」を結びつけて評価します。退職のきっかけを知るには、人事コネクターで人事システムの情報を取り込みます。

ここで第7章のラベルが効いてきます。「どのデータが重いか」がわかっているので、公開資料のダウンロードと極秘資料のダウンロードを同じ重さで扱わずに済み、誤検知が減ります。

プライバシーへの配慮：「見る側」を守る仕組み

利用者の行動を記録・分析する以上、運用者自身の権限の乱用も防ぐ必要があります。信頼できない監視は、利用者の反発を招き、運用そのものを崩します。

• 仮名化：インサイダーリスク管理は既定で利用者名を仮名化して表示する。実名は調査が必要と判断された段階で、権限のある人だけが見る。
• 役割の分離：アラートを見る人、調査する人、処分を決める人を分ける。IT 管理者が自由に社員のメールを読める状態にはしない。
• 見る側も記録される：調査操作や監査ログの検索自体も監査対象にする。
• 目的の明示と告知：何を、何のために、どこまで記録するかを情報セキュリティ規程や就業規則などで定め、従業員に告知する。具体的な法的要件は法務・人事や専門家と確認する。

9. シナリオで見る連携：退職予定者の持ち出し

ここまでの仕組みが1つの出来事にどう関わるかを、「退職を控えた社員が機密資料を持ち出そうとする」という典型的な内部不正の例で追います。この利用者は正規の ID で、準拠した会社端末から、権限のあるファイルにアクセスしているため、入口の守りはすべて通過します。

この例で大事なのは、②も③も単独では「業務上ありうる操作」であることです。ラベル（重みづけ）、人事情報（文脈）、端末の操作記録（行動）がそろって初めて意味のあるアラートになります。これが「環境の守り」だけでは守れない領域を、「活動の守り」が補う仕組みです。

10. 運用体制と役割分担

守りの運用は IT 部門だけでは完結しません。特に活動の守りは、「何が大事か」を決めるのも、利用者への対応を決めるのも業務側です。

3部作を通して見ると、安全性は「入口で確かめる（第1部）」「確かめるための材料と強制力をそろえる（第2部）」「記録し、見て、データの重さに応じて守り続ける（第3部）」の3層で成り立っています。どの層が欠けても、残りの2層では補えない穴が生まれます。

用語集（本書で初めて登場するもの）

参考資料

• Microsoft Entra data retention
• Audit log retention policies (Microsoft Purview)
• Learn about insider risk management