Microsoft DefenderでMicrosoft Sentinelのログ保持を見直すなら、今回のポイントは「どのデータをAnalytics tierに残し、どのデータをData lake tierへ逃がすか」をテーブル単位で判断することです。2026年4月22日に更新されたMicrosoft公式ドキュメント「Manage data tiers and retention in Microsoft Sentinel」では、Microsoft Defenderポータル上でMicrosoft SentinelとMicrosoft Defender XDRのデータ階層、保持期間、コスト影響を管理する考え方が整理されています。(Microsoft Learn)
特にsecurity admins、identity teams、compliance teamsにとって重要なのは、すべてのログを長期間「分析可能な状態」で保持するのではなく、リアルタイム検知に必要なログと、監査・調査用に低コストで保管すべきログを分けることです。Microsoft Sentinelのデータ保持は、運用効率、インシデント調査、コンプライアンス、Azureコストに直結します。
Microsoft Defenderの最新動向: Manage data tiers and retention in Microsoft Sentinelで何が変わったか
2026年4月更新で押さえるべき流れは、Microsoft Sentinelのデータ管理がMicrosoft Defenderポータル中心に整理されている点です。Microsoft Learnでは、SentinelとDefender XDRに取り込まれるデータはテーブルに保存され、Defenderポータルから保持期間と保存コストに関わる設定を管理できると説明されています。(Microsoft Learn)
これは単なる画面変更ではありません。SIEMとXDRのデータを、次の観点で見直す必要があるというメッセージです。
- どのログをリアルタイム検知に使うのか
- どのログを長期監査・フォレンジック用に残すのか
- XDRの既定保持とSentinel側の取り込みをどう使い分けるのか
- テーブルごとの保持期間変更が検知ルールやハンティングに影響しないか
- コンプライアンス要件を満たしつつ、過剰なストレージコストを避けられるか
Microsoft Sentinelは、2027年3月31日以降Azure portalではサポートされず、Microsoft Defenderポータルのみで利用される予定です。現在Azure portal中心でSentinelを運用している組織は、保持期間管理も含めてDefenderポータルへの移行計画を進める必要があります。(Microsoft Learn)
データ階層の基本: Analytics tierとData lake tierの違い
Microsoft Sentinelのデータ保持を理解するうえで、最初に押さえるべきなのはAnalytics tierとData lake tierの違いです。
Analytics tierは、検知・調査・可視化にすぐ使うための階層です。アラート、ハンティング、分析ルール、ワークブックなど、Sentinelの主要機能で使うログはここに置く必要があります。公式ドキュメントでは、Analytics tierのデータはリアルタイム分析、高性能クエリ、分析ルール、脅威ハンティングに利用できると説明されています。(Microsoft Learn)
一方、Data lake tierは長期保管向けの低コストな階層です。監査、規制対応、過去傾向分析、フォレンジック調査には向いていますが、リアルタイムの分析ルールやハンティングにそのまま使う前提ではありません。必要な場合はKQL jobs、Spark jobs、summary rulesなどを使って参照・集計します。(Microsoft Learn)
| 観点 | Analytics tier | Data lake tier |
|---|---|---|
| 主な用途 | リアルタイム検知、ハンティング、分析ルール、ワークブック | 長期保管、監査、履歴分析、フォレンジック |
| クエリ性能 | 高速な対話型分析向け | 監査・バッチ分析向け |
| 検知ルールでの利用 | 向いている | 制限あり |
| コスト設計 | 検知価値の高いログに絞る | 大容量・長期保管ログに向く |
| 実務での例 | サインイン、アラート、エンドポイントイベント | 低頻度参照の監査ログ、長期証跡 |
判断の軸はシンプルです。SOCが毎日見るログはAnalytics tier、監査で後から見るログはData lake tierを基本に考えると設計しやすくなります。
2026年4月更新で重要な保持期間の考え方
公式ドキュメントでは、Microsoft SentinelとMicrosoft Defender XDRのデータは既定でAnalytics tierに30日保持されるとされています。また、Analytics tierの保持は最大2年まで延長でき、Data lake側のTotal retentionは最大12年まで延長できます。(Microsoft Learn)
ただし、保持期間を長くすればよいわけではありません。保持期間は、セキュリティ運用とコストのバランスで決めるべきです。
| 保持設計 | 向いているケース | 注意点 |
|---|---|---|
| Analytics tier 30日 | 日常運用が短期調査中心の組織 | 過去インシデントの深掘りには不足する場合がある |
| Analytics tier 90日 | 四半期単位の調査、IDリスク分析、監査対応がある組織 | データ量が多いテーブルではコスト影響を確認する |
| Analytics tier 180日以上 | 高度な脅威ハンティングや長期潜伏調査が必要な環境 | すべてのテーブルに適用すると過剰コストになりやすい |
| Data lake tier長期保持 | 規制対応、証跡保存、年単位の監査 | リアルタイム検知用途には向かない |
| Data lake only | ほぼ検知に使わないが保管義務があるログ | Analytics tier依存のルールやハンティングが使えなくなる |
たとえば、SigninLogsやIdentityInfoのようにID調査へ関係するログは、identity teamsが過去のサインイン傾向やユーザー属性の変化を確認する場面で重要です。一方で、毎日の検知に使わない大量ログは、Data lake tierで長期保管したほうが現実的です。
Defenderポータルで管理できるテーブルとできないテーブル
今回の更新で実務上見落としやすいのが、すべてのテーブルを同じようにDefenderポータルで管理できるわけではない点です。
Microsoft Learnでは、Defenderポータルで扱うテーブル種別として、Microsoft Sentinelの組み込みテーブル、カスタムテーブル、XDRテーブルが説明されています。カスタムテーブルには、_CLや_SRCHで終わるテーブルなどが含まれます。(Microsoft Learn)
一方、XDR default tierにある一部のXDRテーブルはDefenderポータルで表示できても、管理できない場合があります。また、Basic logsテーブルはDefenderポータルから表示できても、現時点ではLog Analytics workspace側で管理する必要があるとされています。(Microsoft Learn)
| テーブル種別 | 例 | 実務上の見方 |
|---|---|---|
| Microsoft Sentinel組み込みテーブル | AzureDiagnostics、SigninLogs、SecurityAlert | 検知・調査の中核。保持期間を個別に設計する |
| カスタムテーブル | _CL、_SRCHなど | 独自ログや検索ジョブ結果。用途を確認して過剰保持を避ける |
| XDRテーブル | DeviceEvents、AlertInfoなど | XDR既定保持とSentinel取り込みの関係を確認する |
| Basic logs | 環境により異なる | Defenderポータルだけで管理できない場合がある |
実務では、まずテーブル一覧を作り、各テーブルに「検知」「調査」「監査」「ほぼ未使用」のラベルを付けると判断しやすくなります。
XDRデータ保持で注意すべきポイント
Microsoft Defender XDRの脅威ハンティングデータは、既定でXDR default tierに30日保持されます。このデータは、既定ではAnalytics tierやData lake tierに取り込まれません。対応するXDRテーブルの保持を30日超に設定すると、Sentinelワークスペースにテーブルが作成され、Analytics tierに取り込まれ、Data lake tierにもミラーされると説明されています。(Microsoft Learn)
ここで重要なのは、30日を超える保持は単なる期間延長ではなく、Sentinel側の取り込み・課金・保存設計に関わるという点です。
XDRデータの設計では、次のように判断します。
| 要件 | 推奨される考え方 |
|---|---|
| 30日以内のハンティングで十分 | XDR default tierを基本にする |
| 31〜90日の調査が必要 | Analytics tierへの取り込みを検討する |
| 90日を超える履歴調査が必要 | Analytics tierとData lake tierの組み合わせを検討する |
| 長期監査が主目的 | Data lake tier中心に設計する |
| ほぼリアルタイム検知に使う | Analytics tierから外さない |
たとえば、エンドポイント侵害の調査で「3か月前の端末イベントを追いたい」場合、30日の既定保持だけでは不足する可能性があります。一方、過去数年分のデータを常時高速クエリできる状態で保持する必要はないかもしれません。この差を整理することが、コスト最適化につながります。
保持期間を変更すると何が起きるか
保持期間や階層を変更すると、検知や調査に直接影響します。公式ドキュメントでは、Analytics tierからData lake tierへ変更すると、リアルタイム分析とハンティングクエリが停止すると説明されています。(Microsoft Learn)
また、Total retentionを短縮した場合、Microsoftはデータ削除まで30日待機するため、誤設定に気づいた場合に戻せる余地があります。Analytics retentionを変更した場合は、既存データに対して即時に反映されます。(Microsoft Learn)
| 変更内容 | 起きること | 事前確認 |
|---|---|---|
| Analytics tierからData lake tierへ変更 | リアルタイム検知やハンティングが使えなくなる可能性 | 分析ルール、カスタム検知、ワークブックの依存を確認 |
| Analytics retentionを短縮 | Analytics側で参照できる期間が短くなる | SOCの調査SLAと照合する |
| Total retentionを短縮 | 削除まで猶予があるが、最終的には長期データが消える | コンプライアンス要件と監査証跡を確認 |
| Total retentionを延長 | 既に取り込まれ、削除されていないデータにも適用される | ストレージコストを確認 |
| XDRデータを30日超に延長 | Sentinel側の取り込みや課金に影響する可能性 | 対象テーブルとデータ量を確認 |
特に失敗しやすいのは、「コスト削減のためにData lake tierへ移したら、検知ルールが動かなくなった」というケースです。階層変更はストレージ設定ではなく、SOC運用の設計変更として扱うべきです。
実務で使えるテーブル保持期間の設計例
保持期間は組織のリスク、規制、ログ量によって変わります。ここでは、一般的な判断例として整理します。
security admins向け: 検知に使うログはAnalytics tierに残す
セキュリティ管理者が重視すべきなのは、アラート生成やインシデント調査に使うログです。
代表例として、アラート、サインイン、エンドポイント、クラウドリソースの操作ログなどがあります。これらは、日常の検知・調査で使う期間を基準にAnalytics retentionを設定します。
実務では、次の質問に答えると判断しやすくなります。
- インシデント調査で過去何日分を見ることが多いか
- 検知ルールはどのテーブルを参照しているか
- ハンティングクエリは30日を超える期間を前提にしているか
- 高リスク資産や特権IDに関するログは長めに必要か
「全テーブル90日」ではなく、「重要テーブルは90日、低頻度ログはData lake」という分け方が現実的です。
identity teams向け: ID関連ログは調査期間を長めに見る
ID侵害は、発見までに時間がかかることがあります。identity teamsは、サインイン履歴、ユーザー情報、条件付きアクセス、特権操作に関するログの保持を短くしすぎないよう注意が必要です。
たとえば、次のような調査では30日を超えるデータが必要になる場合があります。
- 過去の不審なサインイン傾向を確認する
- 退職者・休職者アカウントの利用履歴を確認する
- 特権ロール付与前後の操作を追跡する
- MFA疲労攻撃や不審な国・地域からのアクセスを時系列で見る
ID関連ログは、検知に使う期間をAnalytics tierで確保し、それを超える監査目的の履歴はData lake tierで残す構成が扱いやすいです。
compliance teams向け: 長期保管はData lake tierを前提にする
コンプライアンス担当者は、「何年残すか」だけでなく、「どの状態で残すか」を確認する必要があります。
監査対応では、リアルタイム検知に使える状態であることよりも、必要な証跡を後から取り出せることが重要です。そのため、年単位の保持はData lake tierを中心に設計するのが基本です。Microsoft Learnでも、Data lake tierはコンプライアンスや規制ログ、履歴傾向分析、低頻度参照データに適していると整理されています。(Microsoft Learn)
ただし、法規制や社内規程によっては、ログの完全性、アクセス制御、削除ルール、証跡の提出手順まで求められる場合があります。保持期間だけを設定して終わりにせず、監査時の検索手順と責任者も決めておくべきです。
Defenderポータルで保持期間を見直す手順
Microsoft Learnの関連ドキュメントでは、DefenderポータルのMicrosoft Sentinel > Configuration > Tablesからテーブル設定を確認し、Manage tableで保持期間や階層を変更できると説明されています。設定には、DefenderポータルのUnified RBACまたはLog Analytics workspace側の適切な権限が必要です。(Microsoft Learn)
実務では、いきなり変更するのではなく、次の順序で進めます。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 1 | 対象ワークスペースを確認 | 複数ワークスペース運用では誤選択に注意 |
| 2 | テーブル一覧を確認 | Sentinel、Custom、XDR、Basic logsを分類 |
| 3 | 各テーブルの用途を確認 | 検知、調査、監査、未使用に分ける |
| 4 | 現在の保持期間を棚卸し | 30日、90日、180日以上などを一覧化 |
| 5 | 分析ルールとの依存を確認 | Analytics tierから外すと検知が止まる可能性 |
| 6 | コンプライアンス要件を確認 | 必要な年数と検索手順を確認 |
| 7 | 変更内容を小さく適用 | 重要テーブルから段階的に実施 |
| 8 | クエリ・ルール・コストを確認 | 変更後の検知漏れと請求影響を確認 |
データコネクタ設定時にも、オンボード済みのMicrosoft Sentinel data lakeがある場合は、Analytics tierとData lake tierの保持を設定できます。既定ではデータがAnalytics tierへ送られ、Data lake tierにも同じ保持期間でミラーされると説明されています。(Microsoft Learn)
コスト最適化で失敗しないための判断基準
Microsoft Sentinelの保持期間管理でよくある失敗は、「高いから短くする」「不安だから全部長くする」という両極端な判断です。どちらも実務には向きません。
コストを抑えながら調査力を落とさないためには、テーブルごとに次の4分類を行います。
| 分類 | 方針 | 例 |
|---|---|---|
| 検知必須ログ | Analytics tierで必要期間保持 | アラート、サインイン、エンドポイント主要イベント |
| 調査補助ログ | 短期はAnalytics、長期はData lake | クラウド操作ログ、ネットワーク関連ログ |
| 監査ログ | Data lake tier中心 | 規制・社内監査用の証跡 |
| 低価値ログ | 保持短縮または取り込み見直し | ほとんど参照されない大量ログ |
特に、データ量が多いエンドポイント系ログやクラウド監査ログは、保持期間を一律に延ばすとコストが膨らみやすい領域です。まずは直近90日以内の調査頻度、分析ルールでの利用有無、監査要件の有無を確認しましょう。
変更前に確認したいチェックリスト
保持期間や階層を変更する前に、次のチェックを行うと事故を防ぎやすくなります。
| チェック項目 | 確認内容 |
|---|---|
| 分析ルール | 対象テーブルを参照するルールがないか |
| ハンティングクエリ | SOCが定常的に使うクエリに影響しないか |
| ワークブック | ダッシュボードの表示が欠損しないか |
| インシデント調査 | 過去調査で必要だった期間を満たすか |
| ID調査 | サインインやユーザー関連ログを短くしすぎていないか |
| 監査要件 | 年単位の保持が必要なログを削除対象にしていないか |
| 権限 | 変更者に必要なRBACまたはLog Analytics権限があるか |
| コスト | 取り込み、Analytics保持、Data lake保持の影響を確認したか |
| ロールバック | 誤設定時に戻す手順と責任者が決まっているか |
このチェックリストは、変更申請や運用手順書にそのまま組み込めます。特にグローバル環境では、地域ごとに監査要件や保持ポリシーが異なる場合があるため、単一の保持期間を全リージョンへ適用しないほうが安全です。
2026年4月更新を受けて今すぐやるべきこと
今回の「Manage data tiers and retention in Microsoft Sentinel」更新を受けて、最初に行うべきことは大きく3つです。
まず、Microsoft DefenderポータルでMicrosoft Sentinelのテーブル一覧を確認し、現在の保持期間と階層を棚卸しします。次に、各テーブルを「検知」「調査」「監査」「低頻度」に分類し、Analytics tierに残すべきログを絞ります。最後に、XDRデータの30日既定保持を前提に、31日以上の調査要件があるテーブルだけSentinel側の取り込みや長期保持を検討します。
Microsoft Sentinelのデータ保持は、セキュリティ運用とコスト管理の交差点です。security adminsは検知ルールへの影響、identity teamsはID調査に必要な期間、compliance teamsは証跡保管と監査手順を確認しましょう。
すべてのログを同じ期間・同じ階層で持つのではなく、テーブルごとに目的を決めることが重要です。2026年4月更新のポイントは、Defenderポータル上でその判断をより明確に行い、SIEMとXDRのデータを実務に合わせて管理することにあります。
コメント