Azure 管理者が今回まず押さえるべき点は、Microsoft Sentinel data lake のオンボードが Microsoft Defender ポータル起点で行われ、テナント単位のセキュリティデータ基盤として扱われるということです。2026年6月24日に更新された公式情報では、Defender を利用中の顧客が Microsoft Sentinel data lake にオンボードする手順、前提条件、権限、リージョン、課金、トラブル時の確認点が整理されています。特に重要なのは、オンボード時に指定した Azure サブスクリプションとリソースグループは後から別の場所へ移行できない点、Primary SIEM workspace の設定が前提になる点、そして Azure portal 版 Microsoft Sentinel の利用期限が 2027年3月31日に区切られている点です。(Microsoft Learn)
Azure の新機能・変更点：「Onboarding to Microsoft Sentinel data lake from the Defender portal」で確認すべきポイント
今回の更新は、単なる画面操作の追加ではありません。Microsoft Sentinel を Microsoft Defender ポータル上で使う流れが強まり、SIEM、XDR、データレイク、Graph をまたいだセキュリティ運用に向けた土台整備と考えるべき内容です。
Microsoft Learn の対象ページでは、Microsoft Defender を利用中の顧客向けに、Defender ポータルから Microsoft Sentinel data lake へオンボードする方法が説明されています。オンボードはテナント単位で一度実行され、指定した Azure サブスクリプションとリソースグループに Microsoft Sentinel data lake が作成されます。Graph の有効化もオンボードに含まれ、パブリックプレビュー時にオンボード済みの場合は一般提供版の data lake と graph に自動アップグレードされます。(Microsoft Learn)
| 確認ポイント | 内容 | 管理者の対応 |
|---|---|---|
| オンボードの起点 | Microsoft Defender ポータルから開始 | Azure portal ではなく Defender ポータルで手順を確認する |
| 対象範囲 | テナント単位で data lake を有効化 | 複数ワークスペースや複数製品での利用を前提に設計する |
| 課金先 | オンボード時に Azure サブスクリプションとリソースグループを指定 | 本番用の課金・管理単位として妥当か事前確認する |
| リージョン | Primary Sentinel workspace と同じ Azure リージョンに配置 | グローバル拠点やデータ所在地要件を事前に確認する |
| 移行制約 | 作成後は別のサブスクリプションやリソースグループへ移行不可 | 試験用の場所で安易に本番オンボードしない |
| 運用期限 | Azure portal 版 Sentinel は 2027年3月31日以降サポート対象外 | Defender ポータルへの移行計画を前倒しで進める |
Microsoft Sentinel data lake とは何か
Microsoft Sentinel data lake は、セキュリティ関連データを大規模に収集、保管、分析するためのクラウドネイティブなデータレイクです。Microsoft Defender XDR、Microsoft Sentinel、Microsoft 365、Microsoft Entra ID、ネットワークログ、EDR、クラウドワークロードのテレメトリなど、幅広いセキュリティデータを統合的に扱う基盤として位置付けられています。(Microsoft Learn)
従来の SIEM 運用では、長期保管したいログが増えるほどコストや検索性能のバランスが難しくなります。Microsoft Sentinel data lake は、分析向けの Analytics tier と、長期保管・大規模分析向けの Data lake tier を分けることで、検知・調査に必要なデータと、監査・フォレンジック・履歴分析に必要なデータを使い分けやすくします。公式情報では、Data lake tier は長期保管や Python ベースの高度な分析向けで、最大12年のセキュリティデータ保持に対応すると説明されています。(Microsoft Learn)
実務では、次のような使い方が想定されます。
| 活用シーン | 具体例 | 期待できる効果 |
|---|---|---|
| 長期ログ調査 | 半年前のサインイン履歴、端末イベント、クラウド操作ログを横断調査する | インシデントの侵入時点や横展開の痕跡を追いやすい |
| 脅威ハンティング | KQL で data lake 内のログを探索する | Analytics tier に常時置かないデータも分析対象にできる |
| フォレンジック | 攻撃キャンペーンの履歴を時系列で確認する | 短期ログだけでは見えない関連性を確認できる |
| AI・高度分析 | Jupyter notebook や Python ライブラリで異常検知を試す | SOC の調査や自動化の幅を広げられる |
| Graph 分析 | エンティティ同士の関係を可視化してリスクを追う | ユーザー、端末、アプリ、アラートのつながりを把握しやすい |
影響範囲：Defender 利用者だけでなく Sentinel 管理者も対象
今回のオンボードは「Defender ポータルの新しい設定項目」として見ると見落としが出ます。実際には、Microsoft Sentinel のワークスペース設計、Azure の課金管理、RBAC、リージョン、データ保持ポリシーに影響します。
特に影響を受けるのは、以下のような組織です。
| 対象 | 影響 |
|---|---|
| Microsoft Defender ポータルでセキュリティ運用している組織 | Sentinel data lake と Graph を Defender ポータルから利用する運用へ広がる |
| 既存の Microsoft Sentinel ワークスペースを持つ組織 | Primary SIEM workspace の接続状態とリージョンが重要になる |
| 複数リージョン・複数拠点で運用する組織 | data lake は Primary workspace と同じリージョンに配置されるため、データ所在地の確認が必要 |
| Azure Policy を厳格に使っている組織 | data lake 有効化に必要な Azure マネージドリソース作成がブロックされる可能性がある |
| CMK を利用している組織 | data lake に保存されるデータは Customer-Managed Keys 非対応のため、暗号化ポリシーとの整合確認が必要 |
| コスト管理を細かく行う組織 | data lake の取り込み、保存、クエリ、ノートブック利用などが課金要素になる |
Microsoft の前提条件では、Microsoft Defender と Microsoft Sentinel が構成済みであること、課金に使う Azure サブスクリプションとリソースグループがあること、Primary Sentinel workspace が Defender ポータルに接続されていることが求められます。また、data lake は Primary Sentinel workspace と同じリージョンにプロビジョニングされ、同じリージョンのワークスペースだけが data lake に関連付けられます。(Microsoft Learn)
オンボード前に確認すべき前提条件
オンボード作業に入る前に、最低限次の5点を確認してください。ここを曖昧にしたまま進めると、セットアップ失敗、想定外の課金、後から変更できない構成ミスにつながります。
Primary SIEM workspace が Defender ポータルに接続されているか
Microsoft Sentinel data lake のセットアップ前に、Microsoft Sentinel workspace を Defender ポータルへ接続し、Primary SIEM workspace として設定する必要があります。Defender ポータルでは、SIEM workspaces から対象ワークスペースを選択し、Connect workspace を実行して Primary に設定します。ワークスペースが表示されない場合や、サブスクリプションのフィルターが undefined になる場合は、権限不足を疑うべきです。(Microsoft Learn)
課金用のサブスクリプションとリソースグループは本番運用に適しているか
オンボード時には、Microsoft Sentinel data lake の課金に使う Azure サブスクリプションとリソースグループを選択します。公式情報では、data lake が特定の Azure サブスクリプションとリソースグループにプロビジョニングされた後、別のサブスクリプションやリソースグループへ移行できないと明記されています。(Microsoft Learn)
そのため、検証環境のリソースグループや、部門都合で将来廃止される可能性があるサブスクリプションを選ぶのは避けるべきです。グローバル企業では、セキュリティ基盤用の共通サブスクリプション、ログ管理用のリソースグループ、コスト配賦ルールを先に決めてからオンボードするのが安全です。
必要な権限を持つ担当者が作業するか
Microsoft Sentinel は、SIEM 側の権限に Azure RBAC、data lake 側の権限に Microsoft Entra ID RBAC を使用します。Microsoft は最小権限の原則を推奨しており、Global Administrator は既存ロールで対応できない緊急時に限定すべき高権限ロールと説明しています。(Microsoft Learn)
オンボード時にワークスペースが Defender ポータルに表示されない場合の最小構成として、公式トラブルシューティングでは、Entra ID の Security Administrator 以上に加え、Azure Subscription Owner、または User Access Administrator と Microsoft Sentinel Contributor の組み合わせが示されています。(Microsoft Learn)
| 作業 | 代表的に必要になる権限の考え方 |
|---|---|
| data lake のオンボード | Entra ID 側のセキュリティ管理権限と Azure サブスクリプション側の管理権限を確認 |
| data lake 全体の読み取り | Global Reader、Security Reader、Security Operator、Security Administrator などが候補 |
| KQL ジョブや notebook での書き込み | Security Operator、Security Administrator、Global Administrator などが候補 |
| 特定ワークスペースの読み取り | Log Analytics Reader、Microsoft Sentinel Reader、Reader など Azure RBAC を確認 |
| SOC 担当者の日常運用 | 必要な範囲だけに絞り、Global Administrator を常用しない |
リージョンとデータ所在地の要件を満たすか
Microsoft Sentinel data lake は、関連付けられた Primary Sentinel workspace と同じ Azure リージョンにデプロイする必要があります。グローバル展開している組織では、米国、欧州、日本、オーストラリアなどのリージョン対応状況に加え、Microsoft 365 データの所在地と data lake の所在地が異なる場合の扱いも確認が必要です。(Microsoft Learn)
たとえば日本環境では、公式の対応リージョン表で SIEM supported region と Data lake supported region が分かれて記載されています。日本の場合、表上は Microsoft Sentinel SIEM が Japan East と Japan West、data lake が Japan East とされています。リージョン対応は変更される可能性があるため、本番設計では必ず最新の Microsoft Learn を確認してください。(Microsoft Learn)
CMK 利用環境では暗号化ポリシーと矛盾しないか
Customer-Managed Keys を利用している組織は注意が必要です。Microsoft の前提条件では、Microsoft Sentinel data lake に保存されるデータは CMK 非対応であり、data lake に取り込まれるカスタムテーブルや変換済みデータは Microsoft-managed keys で暗号化されると説明されています。CMK 適用済みの Sentinel ワークスペースは data lake 体験からアクセスできない場合があります。(Microsoft Learn)
金融、公共、医療、重要インフラなど、暗号鍵管理のルールが厳しい組織では、オンボード前にセキュリティ部門、法務、監査部門と確認してください。
Defender ポータルから Microsoft Sentinel data lake にオンボードする手順
公式手順では、オンボードは Microsoft Defender ポータルから実行します。流れはシンプルですが、実行前の設計が重要です。
| 手順 | 操作 | 確認ポイント |
|---|---|---|
| 1 | Microsoft Defender ポータルにサインイン | 作業者の権限、対象テナント、ディレクトリを確認 |
| 2 | System > Settings > Microsoft Sentinel > Data lake を開く | 目的の Sentinel workspace が Defender 側に接続されているか確認 |
| 3 | Start setup を選択 | 権限不足のサイドパネルが出た場合は管理者に依頼 |
| 4 | Subscription と Resource group を選択 | 後から移行できないため、本番用の管理単位を選ぶ |
| 5 | Set up data lake を選択 | Azure Policy、リージョン、課金先の妥当性を再確認 |
| 6 | セットアップ完了を待つ | 最大60分かかる場合があり、パネルを閉じても処理は継続可能 |
| 7 | Data lake settings で状態を確認 | サブスクリプションとリソースグループが表示されるか確認 |
| 8 | Sentinel から Graphs や Query data lake を利用 | KQL による探索や Graph ベースのハンティングを開始 |
オンボード後は、Defender ポータルの Sentinel から Graphs や Query data lake を利用できます。Query data lake は KQL クエリエディターとして機能し、Microsoft Sentinel data lake 内のデータを探索・分析するために使います。(Microsoft Learn)
設定変更で特に注意すべきポイント
サブスクリプションやリソースグループを削除してはいけない
Microsoft は、Microsoft Sentinel data lake を含むサブスクリプションやリソースグループを削除しないよう明確に警告しています。削除した場合、data lake 関連の体験が停止し、3日後に取り込みが停止します。復旧するには data lake を再セットアップする必要があり、以前に取り込まれたデータは再セットアップ後に復元されると説明されています。(Microsoft Learn)
実務上は、対象リソースグループに削除ロックを設定し、リソース棚卸しやコスト削減作業で誤削除されないよう運用ルールに入れておくべきです。
新しく作成した Azure Monitor workspace は自動追加されない
オンボード後に作成された Azure Monitor workspace は、Microsoft Sentinel data lake に自動追加されません。追加が必要な場合はサポートチケットを開く必要があります。(Microsoft Learn)
複数ワークスペースを運用している組織では、新規ワークスペース作成時のチェックリストに「Defender ポータル接続」「Primary workspace とのリージョン整合」「data lake 追加要否」を入れておくと漏れを防げます。
新規テーブルやティア変更後のデータ反映には時間差がある
トラブルシューティング情報では、新しく有効化したテーブルやティア間で移動したテーブルのデータは、オンボード完了後90〜120分で利用可能になると説明されています。(Microsoft Learn)
セットアップ直後に KQL でデータが見えない場合、すぐに設定ミスと判断せず、テーブル状態、取り込み状況、時間差を切り分けてください。
Azure Policy がセットアップをブロックする可能性がある
Azure Policy によって、data lake 有効化に必要な Azure マネージドリソースの作成がブロックされる場合があります。公式のエラー例では、DL103 が「blocking Azure policies」に該当し、必要なポリシー例外を確認するよう案内されています。(Microsoft Learn)
セキュリティ強化のために「許可されたリソース種類のみ作成可能」「特定リージョン以外は禁止」「タグ必須」などのポリシーを設定している環境では、オンボード前にテスト用サブスクリプションで検証しておくと安全です。
移行期限：data lake 単体よりも Defender ポータル移行が重要
今回の公式ページ自体では、Microsoft Sentinel data lake オンボードの強制期限が個別に示されているわけではありません。ただし、Microsoft Sentinel 全体の運用では重要な期限があります。Microsoft は、2027年3月31日以降、Microsoft Sentinel は Azure portal ではサポートされず、Microsoft Defender ポータルでのみ利用可能になると案内しています。(Microsoft Learn)
つまり、管理者が取るべき現実的な対応は「data lake をいつ有効化するか」だけではありません。2027年3月31日までに、Sentinel の日常運用、インシデント対応、分析ルール、プレイブック、権限設計、SOC 手順を Defender ポータル前提へ移行する必要があります。
| 期限・制約 | 内容 | 推奨対応 |
|---|---|---|
| 2027年3月31日 | Azure portal 版 Microsoft Sentinel のサポート終了 | Defender ポータルでの運用手順に移行 |
| data lake 作成後 | サブスクリプション・リソースグループの移行不可 | 本番用の課金・管理単位を選定してから実行 |
| サブスクリプション/RG 削除後 | 3日後に取り込み停止 | 削除ロック、変更管理、監査ログ確認を設定 |
| オンボード後の新規 workspace | 自動追加されない | 新規 workspace 作成時に data lake 追加要否を確認 |
| テーブル変更後 | データ反映に90〜120分かかる場合あり | 反映待ち時間を運用手順に明記 |
課金で確認すべきポイント
Microsoft Sentinel data lake は、便利な長期保管基盤である一方、利用内容に応じた課金が発生します。公式の課金情報では、data lake tier の課金要素として、data lake ingestion、data processing、data lake storage、KQL クエリや KQL ジョブによる query、notebook セッションやジョブなどに使う Advanced data insights が説明されています。(Microsoft Learn)
特に注意したいのは、KQL クエリ課金が「スキャンした非圧縮データ量」に基づく点です。広い期間を対象に * に近い探索を頻繁に実行すると、想定以上のクエリコストにつながる可能性があります。SOC 向けには、検索期間、対象テーブル、対象列、集計条件を絞る KQL の書き方を標準化しておくとよいでしょう。
| 課金要素 | 発生しやすい場面 | コスト抑制の考え方 |
|---|---|---|
| data lake ingestion | Data lake tier only のテーブルにデータを取り込む | すべてのログを無条件に lake only にしない |
| data processing | 変換、正規化、フィルタリングなどを行う | 変換が必要なログと不要なログを分ける |
| data lake storage | Analytics tier の保持期間後も data lake に保持する | 保持期間を監査要件に合わせて設計する |
| data lake query | KQL で広範囲のデータを検索する | 期間、テーブル、条件を絞る |
| Advanced data insights | notebook や custom graph で計算を使う | 検証用と本番用の実行ルールを分ける |
よくある失敗とトラブルシューティング
Microsoft Sentinel data lake のオンボードでつまずきやすい原因は、画面操作そのものよりも、権限、リージョン、Azure Policy、既存リソースの状態にあります。
| 症状・エラー | 主な原因 | 対応 |
|---|---|---|
| workspace が Defender ポータルに表示されない | 必要な Entra ID 権限や Azure RBAC が不足 | Security Administrator 以上と Azure Subscription Owner などの権限を確認 |
| DL102 が表示される | リージョン側の Azure リソース容量不足 | Retry を実行し、継続する場合は対応リージョンを確認 |
| DL103 が表示される | Azure Policy が必要なリソース作成をブロック | data lake オンボードに必要なポリシー例外を確認 |
| Set up data lake 後に Something went wrong が出る | 関連リソースグループ削除、課金サブスクリプション削除・キャンセルなど | サブスクリプションとリソースグループの状態を確認し、必要ならサポートへ |
| 新しい workspace を data lake に追加できない | テナントはすでにオンボード済みで、新規 workspace は自動追加されない | Defender 接続、同一リージョンを確認し、必要に応じてサポートチケットを作成 |
| クエリでデータが見えない | テーブル有効化やティア変更後の反映待ち | 90〜120分の反映時間を考慮して再確認 |
| 特定リージョンで完了しない | 容量制約や未対応リージョン | 対応リージョンを確認し、必要なら別リージョン設計を検討 |
公式トラブルシューティングでは、DL102、DL103、特定リージョンの容量制約、新規 workspace の扱い、Something went wrong、Sentinel workspace が Defender に表示されない場合の確認点が整理されています。(Microsoft Learn)
管理者向けチェックリスト
オンボードを実行する前に、以下を確認してください。すべてを満たせない場合は、先に設計や権限を整えてから作業する方が安全です。
| チェック項目 | 確認内容 |
|---|---|
| Defender ポータル接続 | Sentinel workspace が Defender ポータルに接続済みで、Primary SIEM workspace として設定されている |
| 作業者権限 | Entra ID と Azure RBAC の両方でオンボードに必要な権限を持つ |
| 課金先 | 本番運用に適した Azure サブスクリプションとリソースグループを選定済み |
| リージョン | Primary workspace と data lake のリージョン要件を確認済み |
| データ所在地 | Microsoft 365 データや地域規制との整合を確認済み |
| CMK | Customer-Managed Keys のポリシーと data lake の制約を確認済み |
| Azure Policy | リソース作成を妨げるポリシーがない、または例外設定を準備済み |
| コスト | ingestion、storage、query、notebook などの課金要素を把握済み |
| 削除対策 | 対象リソースグループに削除ロックや変更管理を設定する方針がある |
| SOC 手順 | Defender ポータルでの調査、KQL、Graph 利用手順を整備する予定がある |
実務での導入判断
Microsoft Sentinel data lake は、すべての組織が同じタイミングで急いで有効化すべき機能ではありません。導入効果が大きいのは、ログ量が増え続けている組織、長期保管が必要な組織、Microsoft Defender と Sentinel を横断して調査したい組織、KQL や notebook を使った高度な分析を行いたい組織です。
一方で、現在の Sentinel 利用が小規模で、保持期間も短く、SOC 手順が Azure portal 前提のまま固定されている場合は、先に Defender ポータル移行と権限整理を進めた方が失敗しにくくなります。特に 2027年3月31日の Azure portal サポート終了を考えると、data lake の有効化だけを単独プロジェクトにするのではなく、Defender ポータル移行、RBAC 見直し、データ保持設計、コスト管理をまとめて計画するのが現実的です。(Microsoft Learn)
まとめ：次に取るべき行動
今回の更新ポイントは、Microsoft Sentinel data lake のオンボードが Defender ポータル中心の運用へ組み込まれたことです。管理者は、画面上の Start setup を押す前に、Primary SIEM workspace、権限、リージョン、課金先、CMK、Azure Policy、削除対策を確認する必要があります。
次に取るべき行動は明確です。まず Defender ポータルで Sentinel workspace が Connected かつ Primary になっているか確認し、オンボードに使う Azure サブスクリプションとリソースグループを本番運用の観点で決めてください。そのうえで、data lake の課金要素と KQL 利用ルールを整理し、SOC チームが Defender ポータルで Graphs と Query data lake を使えるよう手順化することが重要です。
コメント