Sentinelで12年保存できる時代に、ログをいつ消すか決められない会社

Microsoft Sentinel Data Lakeと「説明できるログ保存期間」

※本記事は、2026年7月14日時点のMicrosoft公式情報を基に作成しています。

「Microsoft Sentinel Data Lakeなら、ログを最大12年間保存できる」

この説明を聞いて、経営層や監査担当者は安心するかもしれません。

SOCは、過去の攻撃を長期間さかのぼって調査できると考えます。

法務は、将来の紛争や監査に備えて長く残した方がよいと考えるかもしれません。

一方、個人情報や機密情報を含むログを扱う担当者からは、次のような疑問が出てきます。

最大12年間保存できることと、自社が12年間保存すべきことは、本当に同じなのでしょうか。

Microsoft Sentinel Data Lakeは、分析層と長期保存層を組み合わせ、大量のセキュリティデータを最大12年間保持できる仕組みです。

しかし、製品上の最大値を、そのまま自社の保存期間にしてはいけません。

情シス、SOC、法務、監査、経営層に考えていただきたい問いがあります。

ログ保存期間は、Microsoftの既定値、SOCの希望、法務の要求、保険会社の質問のうち、どれを根拠に決めていますか。

結論：12年は「保存可能期間」であり、「保存義務」ではない

Microsoft Sentinel Data Lakeの最大12年という期間は、製品が提供する技術上の選択肢です。

自社の保存期間は、次の要素を組み合わせて決める必要があります。

Microsoft製品の保存可能期間
              │
              ↓
セキュリティ監視・調査に必要な期間
              │
              ↓
契約・監査・業界ルール上の要求
              │
              ↓
個人情報・機密情報を残すリスク
              │
              ↓
閲覧者・委託先・管理者権限
              │
              ↓
削除方法・事故時の保全方法
              │
              ↓
経営・業務・法務・情シスによる承認

説明できるログ保存期間には、少なくとも次の五つが必要です。

必要な説明	内容
保存目的	何のために残すのか
保存期間	いつまで残すのか
保存場所	分析層か、Data Lake層か
閲覧権限	誰がアクセスできるのか
削除・保全	誰が短縮・延長・保全を承認するのか

「安価に保存できるから」「最大12年だから」という理由だけでは、保存目的の説明にはなりません。

1．Microsoft Sentinel Data Lakeとは

Microsoft Sentinel Data Lakeは、大量のセキュリティデータを長期間保持し、KQL、Python、Spark、ノートブックなどを使って分析するためのセキュリティデータレイクです。

Microsoft Sentinel Data Lake自体は一般提供されており、Microsoftは、分析層とData Lake層という二つのストレージ層を使い分ける構成を示しています。Data Lake層では、最大12年間のセキュリティデータ保持が可能です。

図1　分析層とData Lake層の関係

セキュリティログ
・サインイン
・Azure操作
・端末
・Firewall
・DNS
・業務システム
       │
       ↓
┌──────────────────────────┐
│ 分析層（Analytics）                         │
│                                            │
│ ・高速なKQL                                │
│ ・分析ルール                               │
│ ・リアルタイム検知                         │
│ ・アラート、インシデント                   │
│ ・通常の脅威ハンティング                   │
│                                            │
│ 保持期間：30日～最大2年                    │
└──────────────────────────┘
       │
       │ ミラーリング／保持期間経過
       ↓
┌──────────────────────────┐
│ Data Lake層                                │
│                                            │
│ ・大量ログの長期保存                       │
│ ・履歴調査                                 │
│ ・傾向分析                                 │
│ ・フォレンジック                           │
│ ・KQLジョブ、Spark、ノートブック           │
│                                            │
│ 総保持期間：30日～最大12年                 │
└──────────────────────────┘

Microsoftのテーブル設定では、分析層の保持期間を30日から2年、Data Lake層の総保持期間を30日から12年の範囲で設定できます。総保持期間の既定値は分析保持期間と同じであり、12年が自動的に適用されるわけではありません。

表1　分析層とData Lake層の違い

比較項目	分析層	Data Lake層
主な目的	日常監視、リアルタイム検知、インシデント対応	長期保存、履歴分析、監査、フォレンジック
保持期間	30日～最大2年	総保持期間として最大12年
分析ルール	利用可能	直接のリアルタイム分析には利用不可
高性能KQL	対応	分析層より低速
通常のハンティング	対応	履歴データをKQL等で個別調査
アラート生成	対応	原則として直接生成しない
KQLジョブ	利用可能	利用可能
ノートブック	利用可能	長期データ分析に利用可能
主な担当者	SOCアナリスト	SOC上級者、調査担当、データ分析担当
設計上の焦点	検知性能	保存目的とデータライフサイクル

Microsoftも、Data Lake層はリアルタイム分析や通常の高性能ハンティングのための層ではなく、KQLジョブ、Sparkジョブ、履歴分析などに利用する長期保存層として説明しています。

2．12年分のログに、12年間リアルタイム分析が動くわけではない

最大12年間保存できるという説明から、次のように誤解されることがあります。

12年間保存すれば、12年前のログに対しても現在の分析ルールが自動的に動く。

しかし、分析層とData Lake層では利用できる機能が異なります。

図2　保持期間と検知期間は別である

今日
│
├──────── 分析層 ────────┤
│    高速検索・分析ルール・アラート
│
├──────────────────────────── Data Lake層 ────────────────────────────┤
│                 履歴検索・KQLジョブ・ノートブック
│
└────────────────────────────────────────────── 12年前

例えば、総保持期間を3年に設定し、分析保持期間を90日にした場合、概念的には次の構成になります。

直近90日
  ↓
分析層＋Data Lake層
リアルタイム分析・高速調査が可能

91日目から3年前
  ↓
Data Lake層
必要なときに履歴検索・ジョブで調査

「12年保存」と「12年リアルタイム検知」は同じではありません。

この区別をしないまま保存設計を行うと、長期保存費用をかけているのに、SOCが必要な速度で調査できないという問題が起きます。

3．最も重要な仕様――Data Lakeでは特定レコードを個別消去できない

Microsoft Sentinel Data Lakeの保存期間を検討する際、法務・個人情報・監査担当者が特に確認すべき仕様があります。

Microsoftの公式資料では、次の点が明示されています。

• 分析層に対する消去操作は、Data Lake層には影響しない

• Sentinel Data Lakeから特定のレコードを個別に消去できない

• データが元のサービスや分析層から削除されても、Data Lakeは設定済みの保持期間中、取り込んだデータを保持する

• Microsoft Purview側の設定変更も、Data Lakeに保存済みのデータには影響しない

図3　元データを削除してもData Lakeには残る場合がある

【元のシステム】
ユーザー、端末、業務システム
       │
       │ ログ取り込み
       ↓
【分析層】
Microsoft Sentinel
       │
       │ ミラーリング
       ↓
【Data Lake層】
設定した保持期間まで保存

元システムのデータを削除
          ×
分析層で対象データを消去
          ×
Purviewの設定を変更
          ↓
Data Lake内の特定レコードが
直ちに個別削除されるとは限らない

これは非常に重要な論点です。

削除要求が出てから考えるのではなく、Data Lakeへ取り込む前に、何を何年残すかを決めなければなりません。

表2　Data Lakeへ取り込む前に検討する事項

検討項目	確認内容
不要な列	氏名、メールアドレス、IP、端末名等を本当に保存する必要があるか
秘密情報	パスワード、トークン、APIキー、接続文字列が混入しないか
個人識別性	他データと照合することで個人を識別できないか
マスキング	取り込み前に伏字化・仮名化できるか
分離	機密度の異なるデータを別テーブルにできるか
保持期間	テーブル全体へ同じ期間を適用してよいか
削除要求	個別削除が必要になる可能性があるか
代替保存	Data Lake以外の証拠保全手段が必要か

Data Lakeへ長期保存した後に、「この一人分だけ消したい」「この一件だけ早く消したい」と考えても、製品上、特定レコードを個別消去できない場合があります。

したがって、データ最小化は、削除時ではなく取り込み設計時に行う必要があります。

4．保存期間を短縮しても、すぐに削除されるとは限らない

Microsoft Sentinelでは、テーブルの保持期間を後から変更できます。

ただし、設定変更の効果は、延長と短縮で異なります。

表3　保持期間を変更した場合の動作

変更	Microsoft公式資料上の動作	実務上の注意
総保持期間を短縮	データ削除前に30日間待機	「設定を変えた日＝削除日」ではない
総保持期間を延長	未削除の既存データにも新期間を適用	過去データも想定以上に長く残る場合がある
分析保持期間を変更	既存データに対して直ちに反映	SOCの検索範囲・分析ルールへ影響
Data Lakeのみへ変更	分析層への取り込みが停止	リアルタイム分析・通常ハンティングが停止
分析層へ戻す	以後の分析機能を再設計	過去データの状態を個別確認

Microsoftは、総保持期間を短縮した場合、誤設定によるデータ損失を防ぐため、実際に削除する前に30日間待機すると説明しています。また、総保持期間を増やした場合、新しい保持期間は、既に取り込まれ、まだ削除されていないデータにも適用されます。

図4　保存期間短縮時の流れ

保持期間を7年から3年へ変更
             ↓
設定変更を記録
             ↓
30日間の待機
             ↓
関係部門が誤設定でないか確認
             ↓
新しい保持期間を超えたデータを削除

したがって、ログ削除手順書には、単に「保持期間を変更する」と書くのではなく、次の事項を記載する必要があります。

記録事項	内容
変更前の期間	何年・何日だったか
変更後の期間	何年・何日にするか
対象テーブル	どのログへ適用するか
変更理由	法令、契約、リスク、コスト等
影響評価	SOC、監査、調査への影響
承認者	誰が短縮を承認したか
設定変更者	誰がSentinelを操作したか
削除予定日	30日の待機を考慮した日付
確認者	実際の削除状態を誰が確認したか

5．ログ保存期間を決めるのは誰か

ログ保存期間について、よくある決め方があります。

Microsoftの既定値だから90日

SOCが必要と言ったから1年

監査法人から聞かれたから3年

契約書を7年保管するからログも7年

最大12年保存できるから12年

しかし、いずれも単独では十分な根拠になりません。

表4　保存期間を決める情報源と限界

情報源	有用な判断材料	その情報だけでは不足する理由
Microsoftの既定値	製品上の初期構成	自社の業務・契約・リスクを反映していない
SOCの要望	検知、調査、ハンティングに必要な期間	個人情報、契約、削除リスクを単独では判断できない
法務の要望	契約、法令、紛争対応の観点	実際に調査可能なログか、技術上必要かを判断しにくい
監査人の質問	証跡提出・統制評価の観点	保存すべき全データを決めるものではない
保険会社の質問	サイバー事故対応能力の確認	保険質問票が保存義務を直接決めるとは限らない
情シスの判断	技術構成、運用負荷、コスト	経営リスクや契約上の説明を単独では決められない
経営層	リスク受容、予算、説明責任	テーブル単位の技術的差異を把握しにくい

図5　推奨する意思決定体制

【SOC】
検知・調査に必要な期間
        │
        ├──────────┐
        ↓                    ↓
【情シス・Azure担当】     【法務・個人情報担当】
製品仕様・設定・コスト     利用目的・契約・データ
        │                    │
        └──────────┤
                             ↓
                    【データ・業務所有者】
                    業務上の必要性を判断
                             │
                             ↓
                     【CISO・経営層】
                    保存期間・例外を承認

保存期間は、法務が情シスへ通知するだけでも、SOCが希望日数を伝えるだけでも決まりません。

テーブル単位で、目的、リスク、アクセス権、削除可能性を確認し、組織として承認する必要があります。

6．保存期間を決める八つの質問

表5　ログ保存期間決定シート

質問	記載内容
1．何が記録されているか	ユーザー、IP、端末、操作内容、本文、URL等
2．何のために利用するか	検知、調査、監査、品質管理、契約上の証跡等
3．いつ利用するか	日常監視、事故時、年次監査、紛争時等
4．分析層に必要な期間は何日か	分析ルール、高速KQL、通常ハンティングに必要な期間
5．Data Lakeで必要な総期間は何年か	履歴調査、監査、傾向分析等に必要な期間
6．個別削除が必要になるか	個人情報、顧客情報、秘密情報を含むか
7．誰が閲覧できるか	SOC、情シス、MSSP、監査、開発者等
8．誰が短縮・延長を承認するか	CISO、データ所有者、法務、経営層等

7．保存期間を目的別に分ける

すべてのログを同じ期間保存する必要はありません。

次の表は、保存期間を議論するための設計例です。法令上の保存義務や、特定企業への推奨期間を示すものではありません。

表6　目的別の保存期間設計例

区分	主な目的	分析層の期間例	総保持期間の例	主な承認者
A：日常監視	アラート、一次調査、運用障害	30～90日	90～180日	SOC責任者
B：インシデント調査	過去の侵入経路、横展開調査	90～180日	1年	CISO、SOC
C：監査・統制確認	年次監査、アクセスレビュー	90～180日	1～3年	内部監査、法務
D：契約・事業上の証跡	顧客説明、委託先管理、取引証跡	90～180日	3～7年	業務責任者、法務
E：長期的な特別要件	業界上の要請、長期調査、特別契約	必要期間	10～12年	経営層、CISO
F：低価値・高容量ログ	DNS、詳細通信、デバッグ等	30日程度	90～365日	SOC、システム所有者

12年保存を選ぶ場合には、少なくとも次の問いに答える必要があります。

12年保存の確認事項	確認内容
12年後に利用する場面	誰が、何の調査に使うのか
データの識別性	個人、顧客、端末を特定できるか
読取り手段	12年後もKQLやスキーマを理解できるか
閲覧者	12年間、誰にアクセス権を持たせるか
削除不能リスク	個別消去できないことを許容できるか
契約上の説明	顧客・委託先へ説明済みか
費用	保管・クエリ・調査コストを承認したか
終了判断	12年後に誰が削除を確認するか

8．テーブル単位の保存期間一覧を作る

「Sentinelのログは3年保存しています」という説明では不十分です。

Microsoft Sentinelでは、テーブルごとに分析層と総保持期間を設定できるため、保存期間もテーブル単位で整理する必要があります。

表7　ログ保存目的・期間一覧のひな型

テーブル	データ内容	情報区分	保存目的	分析層	総保持	個別削除リスク	所有者	承認者
SigninLogs	ユーザー、IP、端末、認証結果	個人関連・認証	不正サインイン調査			高／中／低
AuditLogs	ユーザー・設定変更	監査・機密	権限変更調査			高／中／低
AzureActivity	Azure管理操作	監査・機密	管理操作の追跡			高／中／低
SecurityEvent	Windowsセキュリティイベント	機密	侵害調査			高／中／低
CommonSecurityLog	Firewall等の通信情報	機密	通信・侵入調査			高／中／低
DeviceNetworkEvents	端末通信	個人関連・機密	EDR調査			高／中／低
DNSログ	名前解決、端末・IP	個人関連・機密	C2・不審通信調査			高／中／低
業務アプリ監査ログ	顧客、取引、操作	顧客・契約	不正操作・取引調査			高／中／低

表8　架空の製造業における記載例

※以下は整理方法を示す架空の例であり、保存期間を推奨するものではありません。

テーブル	保存目的	分析層	総保持	根拠	承認者
SigninLogs	アカウント侵害・遠隔保守調査	90日	1年	インシデント対応手順	CISO
AuditLogs	管理者権限・設定変更の追跡	180日	3年	特権ID管理規程	情シス部長
AzureActivity	Azure構成変更の監査	180日	3年	クラウド変更管理規程	クラウド責任者
CommonSecurityLog	工場・本社間の通信調査	90日	1年	SOC運用要件	SOC責任者
DNSログ	マルウェア通信の履歴調査	30日	180日	脅威検知要件	SOC責任者
生産管理監査ログ	生産計画・マスター変更の調査	180日	5年	業務・契約上の証跡整理	生産管理責任者
デバッグログ	アプリ障害解析	30日	30日	運用要件	アプリ責任者

重要なのは、年数そのものではありません。

なぜそのテーブルだけ、その期間なのかを説明できることです。

9．「12年残す」ことは「12年間アクセスされ得る」ことでもある

長期保存のリスクは、保存容量だけではありません。

12年間保存されたログには、12年間にわたり閲覧・検索・抽出される可能性があります。

Microsoft Sentinel Data Lakeでは、Microsoft Entra IDの一部ロールがData Lake内のすべてのワークスペースへ広い読取りアクセスを提供します。また、Azure RBACを使ってワークスペース単位のアクセスを付与することもできます。

表9　Data Lakeの主なアクセスモデル

アクセス範囲	主なロール・権限	注意点
すべてのワークスペースを読取り	グローバル閲覧者、セキュリティ閲覧者、セキュリティオペレーター、セキュリティ管理者、グローバル管理者	長期ログ全体へ広いアクセスとなる
特定ワークスペースを読取り	Log Analytics閲覧者、Sentinel閲覧者、Azure閲覧者等	割当てスコープを確認
Data Lakeへ書込み	セキュリティオペレーター、セキュリティ管理者、グローバル管理者等	ジョブ・出力テーブル作成へ影響
テーブル設定の変更	ワークスペース・テーブルへの書込み権限	保持期間の変更が可能
システムテーブルの管理	Defender XDR統合RBACのカスタム権限	XDR側の権限確認が必要
KQLジョブ管理	セキュリティオペレーター等	長期データの抽出・加工が可能

Microsoftは、Data Lakeの全ワークスペースへアクセスできる広域ロールと、Azure RBACによる個別ワークスペース権限を区別しています。また、ロール割当ては累積されるため、複数ロールの組合せで想定以上の権限になる場合があります。

表10　ログ閲覧権限表のひな型

利用者	対象ワークスペース	対象テーブル	検索	CSV等への出力	ジョブ作成	保持変更	利用目的
SOC一次担当	本番Sentinel	主要検知テーブル	○	△	×	×	一次調査
SOC上級担当	全SOC対象	セキュリティ全般	○	○	○	×	高度調査
Azure管理者	Azure管理WS	AzureActivity等	○	△	×	○	設定・運用
法務・監査	承認対象のみ	指定テーブル	△	△	×	×	監査・証跡確認
MSSP	契約対象WS	契約対象テーブル	○	契約による	契約による	×	監視委託
開発担当	開発WS	アプリログ	○	△	×	×	障害解析

記号例

記号	意味
○	許可
△	承認または条件付き
×	不許可

10．一つのData Lakeを、誰が所有するのか

Microsoftの公式資料では、複数のMicrosoft Security製品で使用されるData Lakeは、テナントにつき一つと説明されています。

Data LakeはプライマリSentinelワークスペースと同じリージョンにプロビジョニングされ、同一リージョンにあるDefender接続済みワークスペースが自動的にオンボードされます。特定のワークスペースだけを利用者自身でオフボードすることはできず、オフボードにはサポートリクエストが必要です。

図6　テナント全体のData Lake

Microsoft Entra ID
Microsoft 365
Microsoft Defender
Azure
複数のSentinelワークスペース
          │
          ↓
┌───────────────────────────┐
│ テナント共通のSentinel Data Lake         │
│                                           │
│ ・複数セキュリティ製品から利用            │
│ ・複数ワークスペースの長期ログ            │
│ ・共通アクセス権                          │
│ ・共通の課金先・リソースグループ          │
└───────────────────────────┘

したがって、Data Lakeの管理責任者を「各ワークスペースの管理者」だけにすると、責任の空白が生じます。

表11　Data Lake全体で決める責任者

管理対象	決めるべき責任者
Data Lake全体の所有者	CISO、情シス責任者等
課金先サブスクリプション	Azure管理責任者
プライマリワークスペース	Sentinel責任者
テーブル保持期間	データ所有者＋SOC＋法務
全ワークスペース閲覧権限	ID・セキュリティ管理者
ジョブ作成権限	SOC上級責任者
オフボード判断	CISO、経営層
Microsoftサポート依頼	契約・クラウド管理担当

11．削除判断と事故時の保全を分ける

通常の保存期限による削除と、インシデント発生時の証拠保全は、別の手順として設計する必要があります。

図7　通常削除と例外保全の分岐

保存期限が近づく
       ↓
対象テーブルとデータを確認
       ↓
未解決の事故・監査・調査があるか
       │
       ├─ない
       │   ↓
       │ 通常の保存期間で削除
       │
       └─ある
           ↓
       保全対象・期間・承認者を特定
           ↓
       保持期間延長または別領域へ証拠保全
           ↓
       閲覧権限を限定
           ↓
       調査終了後に保全解除を承認

ここで注意すべきなのは、Sentinelの保持期間設定が基本的にテーブル単位であることです。

特定の一件だけを長期保全するためにテーブル全体の保持期間を延長すると、その案件とは無関係なログまで長期間残る可能性があります。

そのため、インシデント証拠については、必要な時間範囲、対象ユーザー、対象端末、KQL、抽出結果等を別途保全する手順も検討します。

表12　インシデント時のログ保全手順

手順	実施内容	担当
1．対象特定	インシデントID、テーブル、期間、資産を特定	SOC
2．期限確認	現在の分析・総保持期間を確認	Sentinel担当
3．消失リスク確認	何日後に保持期限を迎えるか確認	SOC
4．保全承認	延長または別領域への保全を承認	CISO・法務
5．証拠抽出	KQL、結果、設定、アラートを保全	SOC
6．完全性記録	ファイル名、ハッシュ、取得日時を記録	証跡管理者
7．閲覧制限	調査担当者だけに権限を限定	Entra管理者
8．調査終了	保全継続の必要性を再確認	調査責任者
9．解除承認	標準保存期間へ戻すか判断	CISO・法務
10．削除確認	実際の保存状態を確認・記録	Sentinel担当

12．証跡提出パックを作る

「ログを12年保存している」だけでは、監査や事故対応に十分とは限りません。

必要なデータを、必要な期間内に検索し、そのデータがどの設定で保存され、誰が取得したかを説明できる必要があります。

表13　証跡提出パックの構成例

証跡	内容
ログ保存目的・期間一覧	テーブル別の分析・総保持期間
Sentinel設定証跡	テーブルの層、保持期間の画面
データソース一覧	コネクタ、DCR、対象リソース
KQL	抽出に使用したクエリ
クエリ対象期間	UTC・日本時間を明記
抽出結果	CSV、JSON、レポート等
完全性情報	ハッシュ値、ファイルサイズ
取得者	氏名、所属、ロール
取得日時	タイムゾーンを含む日時
承認記録	抽出・提出を承認した者
閲覧権限	抽出時点のRBAC
インシデント情報	Sentinel・DefenderのID
外部チケット	ServiceNow等の番号
提出記録	提出先、方法、日時、範囲

図8　ログから説明可能な証跡へ

大量のログ
   ↓
対象テーブルを特定
   ↓
対象期間を特定
   ↓
再現可能なKQLを作成
   ↓
結果を抽出
   ↓
完全性・取得者・承認を記録
   ↓
監査・取引先・経営へ提出

13．ログ保存期間のRACIを作る

表14　ログ保存・削除に関するRACI例

作業	経営・CISO	情シス	Sentinel担当	SOC	法務・個人情報	データ所有者	内部監査
ログ管理方針の承認	A	R	C	C	C	C	I
ログ一覧の棚卸し	I	A	R	R	C	C	I
保存目的の決定	I	C	C	R	C	A／R	I
分析層期間の提案	I	C	R	A／R	I	C	I
総保持期間の提案	I	C	R	C	R	A	C
Sentinel設定の変更	I	A	R	C	I	I	I
保持期間の短縮承認	A	C	R	C	R	C	I
保持期間の延長承認	A	C	R	R	C	C	I
インシデント保全	I	C	R	A／R	C	I	I
ログ閲覧権限の承認	I	A	R	C	C	C	I
委託先の権限確認	I	A／R	C	C	C	I	I
証跡提出の承認	I	C	C	R	A	C	I
年次レビュー	I	R	R	C	C	C	A

凡例

記号	意味
R	実際に作業を行う担当
A	最終承認・説明責任
C	協議する担当
I	報告を受ける担当

RACIを作成した後は、実際のMicrosoft Entra IDロール、Azure RBAC、Defender XDR統合RBACと一致しているかを確認します。

文書上では法務が承認者でも、技術上は外部SOCが保持期間を変更できる状態であれば、責任分界は完成していません。

14．取引先チェックシートでは、一つの数字で回答しない

よくない回答

当社のセキュリティログは、Microsoft Sentinel Data Lakeで12年間保存しています。

この回答では、次の事項が分かりません。

• すべてのログが12年なのか

• 分析層も12年なのか

• 何のために12年残しているのか

• 個人情報を含むのか

• 誰が閲覧できるのか

• 個別削除できるのか

• 委託先もアクセスするのか

• 事故時に保存期間を延長するのか

改善した回答例

当社では、Microsoft Sentinelへ取り込むセキュリティログについて、ログの種類、情報区分、利用目的および調査上の必要性に応じ、テーブル単位で保存期間を設定しています。 日常的な検知・インシデント対応に利用するデータは分析層で［期間］保持し、履歴調査・監査等に必要なログはMicrosoft Sentinel Data Lakeで総期間［期間］保持しています。 最大12年間の保持が可能ですが、一律に12年間保存するものではなく、保存目的および承認記録に基づいて期間を設定しています。 ログへのアクセスは、Microsoft Entra ID、Azure RBACおよびMicrosoft Defender XDR統合RBACにより［担当部署・委託先］へ限定しています。 Microsoft Sentinel Data Lakeでは特定レコードの個別消去に制限があるため、取り込み前のデータ最小化、テーブル分離および保存期間設定を実施しています。

表15　取引先から聞かれやすい質問

質問	回答前に確認する事項
セキュリティログは何年間保存しますか	テーブル別の分析・総保持期間
最大12年保存しますか	実際に12年を設定したテーブル
個人情報を含みますか	ユーザー、IP、端末、位置等
ログは削除できますか	Data Lakeの個別消去制限
誰が閲覧できますか	Entra、Azure、XDRの各RBAC
外部SOCも閲覧しますか	委託範囲、再委託先
保存場所はどこですか	Data Lakeのリージョン
暗号鍵は誰が管理しますか	CMK対応範囲、Microsoft管理キー
事故時にログを保全できますか	延長・抽出・証跡保全手順
保存期間は誰が決めますか	RACI、承認者、レビュー日

15．NIST・ISMS・GDPRの観点

NIST CSF 2.0では、ログを継続的監視に利用できる状態にすることに加え、保存データを廃棄まで含めたライフサイクルで管理する考え方が示されています。保存することだけではなく、組織の保持方針に基づいて安全に破棄し、その記録を管理することも重要です。

表16　ログ管理文書とNIST CSFの対応

管理内容	NIST CSF 2.0の観点	成果物
ログ取得	継続的監視に必要な記録を生成	ログ取得一覧
ログ分類	リスク・資産・データの把握	ログ分類表
保存期間	リスク戦略に基づく管理	保存目的・期間一覧
閲覧権限	不正アクセスの防止	ログ閲覧権限表
インシデント保全	調査・対応を支える証拠	ログ保全手順
削除	データライフサイクル管理	削除基準・承認記録
委託先管理	サプライチェーンリスク管理	SOC・MSSP責任分界表
定期確認	統制の評価・改善	年次レビュー記録

個人データがログへ含まれ、GDPRの適用がある事案では、保存期間について「処理目的に必要な期間を超えて個人データを識別可能な状態で保持しない」という保存制限の原則も考慮する必要があります。

ただし、GDPR、個人情報保護法、業界規制、契約等から具体的に何年間保存すべきかは、対象データ、利用目的、事業、地域、契約関係によって異なります。

最大12年という製品仕様だけから、適法性や必要性を断定することはできません。

16．30日で始めるログ保存期間の見直し

表17　30日ロードマップ

期間	実施内容	成果物
第1週	Sentinel、XDR、各ワークスペース、テーブルを棚卸し	ログ・テーブル一覧
第2週	保存目的、情報区分、個人情報、利用部門を整理	ログ保存目的一覧
第3週	分析層・総保持期間、閲覧権限、承認者を決定	保存期間表、権限表、RACI
第4週	設定変更、削除・保全テスト、説明資料作成	設定証跡、手順書、証跡パック

第1週に確認する技術項目

確認対象	確認内容
Data Lakeオンボード	有効か、対象リージョンはどこか
プライマリワークスペース	どのワークスペースか
対象ワークスペース	自動オンボードされた範囲
テーブル層	分析層、Data Lakeのみのどちらか
分析保持期間	テーブルごとの日数
総保持期間	テーブルごとの日数・年数
データコネクタ	どこからログが入るか
変換	不要列や機密情報を除去しているか
Azure RBAC	ワークスペースへのアクセス
Entraロール	全Data Lakeへの広域アクセス
XDR統合RBAC	システムテーブル等のアクセス
KQLジョブ	誰が作成・実行できるか
外部SOC	閲覧・出力・保全権限
CMK	適用対象と非適用対象
公式資料	最終確認日

17．情シス・SOC・法務向けセルフチェック

表18　ログ保存期間チェックリスト

質問	はい／いいえ
最大12年と自社の保存期間を区別している
テーブル単位で保存目的を記録している
分析層とData Lake層の期間を分けている
12年保存しているテーブルを特定できる
12年保存する理由を文書化している
個人情報を含むテーブルを把握している
特定レコードを個別消去できないことを理解している
元データの削除がData Lakeへ反映されない場合があると理解している
Purview設定だけではData Lakeを削除できないことを把握している
保存期間短縮後、削除まで待機期間があることを把握している
保存期間の短縮承認者が決まっている
保存期間の延長承認者が決まっている
全ワークスペース閲覧ロールを把握している
外部SOCの閲覧範囲を確認した
KQL結果の出力権限を管理している
インシデント時の保全手順がある
証跡提出パックを作成できる
取引先チェックシートをテーブル別に回答できる
年次で保存期間を見直している
保存終了後の削除確認を記録している

判定の目安

「はい」の数	状態
0～6	Microsoftの既定値や最大値が、そのまま社内方針になっている可能性があります
7～12	技術設定はありますが、目的・削除・承認者の整理が不十分です
13～17	基礎的なログガバナンスがあります。権限・保全・委託先を強化します
18～20	説明可能な基礎統制が整っています。仕様変更との継続照合が必要です

18．山崎行政書士事務所が支援できること

ログ保存期間の整備には、次の二つを接続する必要があります。

Microsoft Sentinelの実際の設定
                 ×
保存目的・権限・削除・証跡の文書

山崎行政書士事務所のクラウド法務では、Azure、Microsoft 365、Microsoft Entra ID等の技術構成と、契約、規程、監査資料、責任分界を一つの説明へつなぐ支援を行っています。

表19　主な支援成果物

支援項目	内容
ログ・テーブル棚卸し	Sentinel、XDR、Azure、M365ログの一覧化
ログ保存目的・期間一覧	テーブルごとの目的、分析期間、総保持期間
分析層・Data Lake使い分け表	検知用ログと長期保存ログの分類
ログ閲覧権限表	Entra、Azure RBAC、XDR統合RBACの整理
保持期間変更手順	短縮・延長時の承認、設定、確認方法
ログ削除基準	保存終了条件、削除承認者、確認証跡
インシデント保全手順	保持期限確認、抽出、完全性記録
SOC・情シスRACI	取得、監視、保全、削除の責任分界
委託先確認表	MSSP、SOC、SIerの閲覧・出力範囲
取引先説明資料	保存期間、所在地、権限、削除方法の回答
証跡提出パック	KQL、設定画面、抽出結果、承認記録
年次レビュー表	保存目的、期間、権限の定期見直し
プレビュー機能管理表	提供状態、制限、代替手順の整理
経営説明資料	長期保存の利点・リスク・コストの可視化

単に、

「何年間保存すればよいでしょうか」

という質問へ、一つの年数を回答するものではありません。

実際の、

• Microsoft Sentinelテーブル

• 分析層とData Lake層

• データコネクタ

• ログ内の情報項目

• Azure RBAC

• Microsoft Entra IDロール

• Defender XDR統合RBAC

• SOC委託範囲

• インシデント対応手順

• 監査・取引先への既存回答

を確認し、技術上の設定と文書上の説明を一致させます。

保存できることより、消す判断を説明できること

Microsoft Sentinel Data Lakeによって、企業は大量のセキュリティデータを最大12年間保存できるようになりました。

過去の攻撃を振り返り、長期間にわたる侵害を調査し、監査や経営報告に利用できることは、大きな利点です。

しかし、長く残せることには、別の側面もあります。

長く保存できる
      ↓
長く閲覧され得る

多く保存できる
      ↓
多くの個人・顧客・端末情報が残る

後から調査できる
      ↓
後から個別削除しにくい場合がある

問題は、12年間保存すること自体ではありません。

問題は、

• なぜ12年なのか誰も説明できない

• テーブルごとの保存目的がない

• SOCの希望だけで期間を決めている

• 法務がData Lakeの個別消去制限を知らない

• 外部SOCの閲覧範囲が分からない

• 保存期間を短縮する承認者がいない

• 事故時の保全と通常削除を分けていない

という状態です。

最後に、もう一度問いかけます。

ログ保存期間は、Microsoftの既定値、SOCの希望、法務の要求、保険会社の質問のうち、どれを根拠に決めていますか。

答えは、そのうちの一つではありません。

ログの内容、利用目的、調査期間、契約、個人情報、閲覧権限、削除方法をテーブル単位で整理し、組織として承認した期間。

それが、Microsoft Sentinel Data Lake時代の「説明できるログ保存期間」です。

技術上の脚注

脚注1：最大12年について分析層の保持期間は30日から最大2年、Data Lake層の総保持期間は30日から最大12年の範囲で設定できます。12年は上限であり、既定値ではありません。

脚注2：特定レコードの消去についてMicrosoft公式資料では、Sentinel Data Lakeから特定のレコードを消去できず、元サービスまたは分析層から削除された場合でも、設定された保持期間中はData Lakeに保持されると説明されています。

脚注3：保持期間短縮について総保持期間を短縮した場合、Microsoftはデータ削除前に30日間待機します。保持期間を延長した場合は、まだ削除されていない既存データにも新しい期間が適用されます。

脚注4：CMKについてMicrosoft Sentinel Data Lakeに保存されるデータでは、カスタマーマネージドキーが完全にはサポートされておらず、Data Lakeへ取り込まれるデータはMicrosoft管理キーで暗号化されると説明されています。

脚注5：オンボード・オフボードについてData LakeはプライマリSentinelワークスペースと同じリージョンに配置され、同一リージョンのDefender接続済みワークスペースがオンボード対象になります。個別ワークスペースのオフボードやData Lake全体の無効化には、サポートリクエストが必要です。

脚注6：周辺機能の提供状態についてMicrosoft Sentinel Data Lake本体は一般提供されていますが、行レベルRBAC、カスタムグラフ、システムテーブルへの一部KQLジョブ書込みなど、関連機能にはプレビューが含まれます。

本記事に関する注意事項

本記事は、2026年7月14日時点のMicrosoft公式情報等に基づく一般的な情報提供を目的としています。

Microsoft Sentinel、Microsoft Sentinel Data Lake、Microsoft Defender XDR、Log Analytics、Microsoft Entra ID等の機能、提供状態、保持期間、権限、料金、データ所在地、削除仕様は変更される可能性があります。

実際の導入・設定変更時には、Microsoft Learn、管理画面、製品条件、契約内容、メッセージセンター、リリースノートおよび実テナントの表示を改めて確認してください。

本記事で示した保存期間、RACI、権限表、削除手順は、一般的な整理例です。個別の事業、業界、契約、データ、利用地域、監査要件等に応じた調整が必要です。

本記事は、特定の事案について個人情報保護法、GDPR、業界規制、秘密保持義務、訴訟上の証拠保全等への適法性を断定するものではありません。個別具体的な法的判断、紛争対応、相手方との交渉または代理については、弁護士等の適切な専門家への相談が必要です。

山崎行政書士事務所はMicrosoftとは独立した事業者です。本記事はMicrosoftによる公式見解、保証または認定を示すものではありません。