Sentinelのログ保存期間を決めずに導入すると、インシデント時に何が詰まるのか

山崎行政書士事務所　クラウド法務担当


2. リード文

Microsoft Sentinelは、Azure環境のログ監査、脅威検知、インシデント対応を支える強力な基盤です。

しかし、Sentinelを導入すれば、自動的に監査対応や契約上の説明責任が整うわけではありません。

現場で本当に詰まるのは、次のような場面です。

「ログは取っているはずなのに、必要な期間が残っていない」
「どのログを何の目的で保存しているのか、誰も説明できない」
「SOCはアラートを見ているが、契約上どこまで一次対応するのか曖昧」
「監査でログ提出を求められたが、提出形式・承認者・提出範囲が決まっていない」
「個人情報を含む可能性のあるログを、誰が、どの国から閲覧できるのか整理されていない」

この記事では、現場の情報システム担当者、CISO、法務部、内部監査部門、経営層向けに、Microsoft Sentinel導入前に決めるべきログ保存期間、契約条項、監査証跡の実務を整理します。

3. 今回の論点

今回の論点は、次の1点です。

Microsoft Sentinelを導入する前に、どのログを、どの期間、どの目的で保存し、その要件を契約条項・社内規程・監査証跡にどう接続するか。

本稿では、Azureセキュリティ全般、ゼロトラスト全体、クラウド契約全般を広く浅く説明しません。

対象を、Sentinel導入時の「ログ保存期間」と「監査で説明できる証跡設計」に絞ります。

4. 現場再現ケース

以下は、複数の実務経験をもとにした匿名化・一般化した再現ケースです。
実在顧客、実在企業、実在案件を特定する情報は含めていません。

金曜の夕方、情シス担当者がAzure Portalを開きながら困っていた。

Microsoft Sentinelはすでに有効化されている。
Log Analytics Workspaceもある。
Microsoft Entra IDのサインインログも取り込まれているように見える。
Azure Activity Logも検索できる。
SOC委託先からは、毎月アラート件数のレポートも届いている。

一見すると、セキュリティ監視はできているように見えた。

ところが、内部監査部門からこう聞かれた。

「管理者ロール変更のログは、何か月分残っていますか」
「なぜその保存期間にしたのですか」
「契約上、インシデント時に提出できるログの範囲はどこまでですか」
「SOC委託先は、どのログを閲覧できますか」
「そのログに個人情報が含まれる可能性は整理されていますか」
「海外サポートや再委託先がログへアクセスする可能性はありますか」

会議室の空気が止まった。

情シスはAzure Portal上の設定を見せた。
しかし、なぜその保存期間なのかを説明する資料がなかった。
法務部は契約書を確認したが、「ログ提供」「監査権」「データ削除」「再委託」の条項が、Sentinelの設定と対応していなかった。
経営層へ説明しようとしても、コスト削減のために短くしたログと、監査上必要なログの区別が整理されていなかった。

設定はある。
ログもある。
しかし、なぜその設定なのか、誰が承認したのか、何日残すべきなのか、監査で何を出せるのかを誰も説明できない。

この状態が、Sentinel導入で最も避けたい状態です。

5. 結論

結論は明確です。

Microsoft Sentinel導入では、分析ルールやダッシュボードを作る前に、ログ保存期間・責任分界点・契約条項・監査証跡を決める必要があります。

情シスの結論

情シスは、ログを「取れるか」ではなく、次の観点で設計する必要があります。

  • 何のログを取るのか

  • 何の目的で保存するのか

  • 何日または何年保存するのか

  • 誰が閲覧できるのか

  • 誰が外部提出を承認するのか

  • 監査時にどの形式で出すのか

  • 保存期間を過ぎたログをどう扱うのか

法務部の結論

法務部は、クラウド契約を購買条件だけで見てはいけません。

Sentinel導入時には、次の条項を技術設定と突き合わせる必要があります。

  • ログ提供

  • 監査権

  • 障害通知

  • インシデント通知

  • 再委託

  • データ所在地

  • 国外移転

  • データ返還

  • データ削除

  • 個人情報・機密情報・営業秘密の取扱い

経営層の結論

経営層は、ログ保存を単なるITコストとして扱うべきではありません。

判断すべきことは、次の3つです。

  1. どのリスクを受容するか

  2. どのリスクを技術・契約・外部委託で下げるか

  3. 重大インシデント時に、どの証跡をもとに説明責任を果たすか

6. 課題の整理

表面的な課題

Sentinelは導入されているが、ログ保存期間が明確に決まっていない。

本当の原因

ログの技術設定、契約条項、社内規程、監査証跡が別々に管理されていることです。

技術面の原因

  • データコネクタの有効化だけで設計完了としている

  • Log Analytics Workspaceの保持設定を確認していない

  • Azure Activity Logの長期保存設計がない

  • 診断設定の対象リソースが不明

  • Azure Policyで診断設定漏れを監査していない

  • KQLクエリが個人メモ化している

  • SOC委託先のRBACが過大または不明確

法務・契約面の原因

  • 契約にログ提供範囲が明記されていない

  • インシデント通知期限と技術通知が連動していない

  • 再委託先や海外サポートの範囲が未整理

  • 契約終了時のログ返還・削除が曖昧

  • 個人情報を含むログの取扱いが規程化されていない

運用面の原因

  • 月次棚卸がない

  • 変更申請書にログ影響欄がない

  • 保存期間変更の承認者が決まっていない

  • 監査提出時の承認フローがない

  • インシデント後レビューでログ不足を確認していない

監査で問題になる点

監査で問題になるのは、「ログがあるか」だけではありません。

  • なぜそのログを保存しているのか

  • なぜその保存期間なのか

  • 誰が保存期間を承認したのか

  • 誰が閲覧できるのか

  • 外部委託先がどこまで見られるのか

  • 提出ログが改ざんされていないことをどう説明するのか

  • 契約・規程と整合しているのか

ここを説明できないと、Sentinelを導入していても、監査上は弱い状態になります。

放置した場合のリスク

放置した場合のリスクは次のとおりです。

  • インシデント時に原因を追えない

  • 取引先監査で証跡を提出できない

  • ログ保存コストが膨らむ

  • 個人情報や機密情報の管理説明ができない

  • SOC委託先の権限が過大になる

  • 契約終了後のデータ削除・返還が曖昧になる

  • 経営層が残存リスクを判断できない

7. 原因分析

Sentinel導入の失敗原因は、製品機能の不足ではなく、設計の分断です。

情シスは技術設定を見る。
法務部は契約を見る。
内部監査は証跡を見る。
経営層は費用とリスクを見る。

しかし、ログ保存期間は、この4つをつなぐ項目です。

Azure Activity Logは既定では90日保持されるとMicrosoft Learnで説明されています。
長期保存や追加機能が必要な場合は、診断設定によりLog Analytics Workspace、Storage Account、Event Hubs等へ送る設計が必要です。

Log Analytics Workspaceでは、テーブルごとの保持設定や長期保持の考え方があります。
Sentinelでは、分析用に使うログと、長期保持するログを分けて考える必要があります。

つまり、ログ保存期間は「ポータル上の数字」ではありません。
契約・規程・監査・コスト・事業継続を結ぶ設計値です。

8. 解決策の全体像

解決策は、次の10ステップです。

  1. まず、現在Sentinelに取り込んでいるログを棚卸する

  2. Azure PortalでWorkspace、データコネクタ、診断設定を確認する

  3. CLI、PowerShell、KQLで設定とログの存在を確認する

  4. ログを「日常監視」「監査証跡」「長期保全」に分類する

  5. 保存期間を契約・規程・監査要件と突き合わせる

  6. 変更前に情シス、法務、監査、経営層の承認者を決める

  7. 変更時に設定値、理由、承認履歴、ロールバック手順を残す

  8. 変更後にログ出力、検索、通知、エクスポートをテストする

  9. 法務部がログ提供、再委託、削除、監査権の条項を確認する

  10. 経営層が残存リスクとログ保存コストを判断する

精神論ではなく、設定・契約・規程・証跡を同じ表にします。

9. 現場作業粒度の技術手順

9-1. Azure Portalで確認する場所

確認対象確認場所確認する内容SentinelMicrosoft SentinelWorkspace、データコネクタ、分析ルール、インシデントWorkspaceLog Analytics workspacesテーブル、保持期間、アクセス制御、コストActivity LogAzure Monitor > Activity log管理操作ログ診断設定各リソース > Diagnostic settings送信先、ログカテゴリEntraログMicrosoft Entra 管理センター > Monitoring & healthサインインログ、監査ログAzure PolicyPolicy診断設定漏れ、準拠状況DefenderMicrosoft Defenderポータル / Defender for Cloudアラート、推奨事項RBACAccess control IAMロール割当、委託先権限StorageStorage accounts長期保存、削除、アクセス制御

9-2. 最初に棚卸するログ

優先して棚卸するログは次のとおりです。

  • Entra IDサインインログ

  • Entra ID監査ログ

  • Azure Activity Log

  • Key Vault診断ログ

  • Storage診断ログ

  • Azure Firewallログ

  • WAFログ

  • Defender for Cloudアラート

  • Sentinelインシデント

  • SOCレポートに使っているログ

9-3. Azure CLI確認例

以下は概念サンプルです。
テナント固有値、サブスクリプションID、IPアドレス、実アカウント名、機密値は含めていません。

az monitor diagnostic-settings list --resource <resource-id>

確認すること：

  • 診断設定が存在するか

  • 送信先がLog Analytics Workspaceか

  • Storage Accountへも送っているか

  • Event Hubs連携があるか

  • 必要なログカテゴリが有効か

Activity Log確認の概念サンプルです。

az monitor activity-log list --max-events 50

確認すること：

  • 誰が変更したか

  • 何を変更したか

  • 成功したか失敗したか

  • どのリソースが対象か

  • 監査で説明できる粒度か

9-4. PowerShell確認例

ロール割当確認の概念サンプルです。

Get-AzRoleAssignment -Scope "<scope>"

確認すること：

  • 誰にロールが付与されているか

  • どのスコープか

  • SOC委託先に過大権限がないか

  • 証跡提出担当と設定変更担当が分離されているか

9-5. KQL確認例

サインイン失敗の確認例です。

SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType != 0
| summarize FailureCount = count() by UserPrincipalName, IPAddress
| top 20 by FailureCount desc

ロール割当変更の確認例です。

AzureActivity
| where TimeGenerated > ago(30d)
| where OperationNameValue has "MICROSOFT.AUTHORIZATION/ROLEASSIGNMENTS/WRITE"
| project TimeGenerated, Caller, ActivityStatusValue, ResourceGroup, _ResourceId
| order by TimeGenerated desc

診断設定変更の確認例です。

AzureActivity
| where TimeGenerated > ago(30d)
| where OperationNameValue has "MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS"
| project TimeGenerated, Caller, OperationNameValue, ActivityStatusValue, _ResourceId
| order by TimeGenerated desc

上記は概念サンプルです。
個別環境で該当テーブルが存在するか、必要なログが取り込まれているかは要確認です。

9-6. IaCで管理する場合

TerraformやBicepで管理する場合は、次を設計レビュー対象にします。

  • Log Analytics Workspace

  • Microsoft Sentinel有効化

  • 診断設定

  • Azure Policy割当

  • RBAC割当

  • Storage長期保存

  • アラート設定

  • Logic Apps通知

  • Stateファイル保護

  • Pull Request承認

  • ロールバック手順

IaC化しても、監査証跡が自動的に整うわけではありません。
変更理由、承認者、テスト結果、影響範囲、ロールバック手順を変更申請に残す必要があります。

10. 実装前に決めるべきパラメータ

決定項目推奨される検討観点情シスの確認事項法務・規程の確認事項未決定の場合のリスク対象ログ種別何を検知・監査するかEntra、Activity、Key Vault、Firewall等ログ管理規程重要証跡が不足保存期間日常監視・監査・長期保全を分けるWorkspace保持、Storage保存契約・監査要件必要時にログがないWorkspace設計集約か分割かリージョン、権限、コストデータ所在地、国外移転管理範囲不明送信先分析と長期保存を分けるLog Analytics、Storage、Event Hubs証跡提出形式後で抽出できない閲覧権限最小権限RBAC、PIM権限管理規程過大権限証跡提出者外部提出の承認者を決めるExport権限監査対応手順提出ミスSOC委託範囲監視・一次対応・報告範囲Sentinel権限委託契約、再委託責任分界不明通知先障害・インシデント時Monitor、Sentinel通知通知条項初報遅延データ所在地保存国・地域Workspaceリージョン国外移転確認法務確認漏れ削除・返還契約終了時の処理Workspace、Storage、Backup削除・返還条項データ残存例外運用例外条件と期限Policy除外、RBAC例外例外管理台帳監査指摘ロールバック変更失敗時の戻し方IaC、設定バックアップ変更管理規程障害長期化

11. 本番導入前のテスト観点

テスト項目テスト内容成功条件失敗時の影響証跡として残すものログ取り込み確認対象ログがSentinelに入るか想定テーブルに記録される証跡不足KQL結果、画面記録診断設定確認主要リソースの送信先確認Workspace等へ送信ログ未取得設定一覧Activity Log長期保存90日超を想定した保存確認長期保存先がある過去操作を追えない設計書、設定証跡RBAC確認閲覧・編集・提出権限の分離最小権限過大権限ロール割当一覧SOC権限確認委託先が必要範囲だけ見えるか契約範囲内委託先管理不備アクセスレビューアラート確認重要イベントで通知されるか通知先へ届く初動遅延通知履歴KQL確認監査用クエリが動くか必要項目を抽出監査提出不能クエリ台帳エクスポート確認提出形式で出せるかCSV等で出力可能監査遅延出力サンプル例外確認Policy除外・権限例外承認済み例外のみ例外濫用例外台帳ロールバック確認設定変更を戻せるか既定状態へ戻せる障害長期化手順書、実施記録契約整合確認通知期限・ログ提供と技術設定契約と設定が一致法務・監査不備対応表

12. 運用開始後の定期確認

確認項目確認頻度確認担当確認方法証跡放置した場合のリスクログ取り込み失敗月次情シスSentinel、Workspace確認月次レポート検知漏れ診断設定漏れ月次情シスAzure Policy準拠状況証跡不足管理者ロール棚卸月次または四半期情シス・監査RBAC一覧棚卸記録過大権限SOCアクセス権四半期情シス・法務アクセスレビュー委託先台帳委託先管理不足保存期間確認半期情シス・法務Workspace設定設定記録規程不整合KQL台帳更新四半期情シスクエリレビュー台帳属人化アラートルール確認月次SOC・情シス分析ルール確認変更履歴誤検知・見落としDefender推奨事項月次情シスDefender確認是正記録脆弱状態放置契約条項確認契約更新時法務契約書・別紙確認記録条項不整合委託先管理台帳半期法務台帳更新台帳再委託把握漏れインシデント後レビュー発生後CISO・情シス・法務事後レビュー報告書再発防止不足監査前確認監査前監査部門証跡確認監査準備資料監査指摘

13. 法務面の実務ポイント

以下は一般的な確認観点であり、個別契約における最終的な法的判断は、弁護士等の専門家確認が必要です。

クラウド契約で確認すべき条項

SentinelやSOC運用を含む契約では、次を確認します。

  • サービス範囲

  • 責任分界点

  • SLA

  • 障害時の通知

  • インシデント通知

  • データ所在地

  • 再委託

  • 監査権

  • ログ提供

  • データ削除

  • データ返還

  • 個人情報の取扱い

  • 機密情報の取扱い

  • 営業秘密の取扱い

  • 国外移転

  • 証跡保全

  • 契約終了時の処理

  • 損害賠償責任の範囲

責任分界点

項目クラウド事業者自社情シスSOC委託先法務・監査クラウド基盤稼働契約範囲状況確認通知受領SLA確認Sentinel設定仕様提供設計・承認実装・運用規程反映ログ保持サービス仕様設定・確認運用確認契約・規程確認アラート対応対象外の場合あり判断一次対応通知要否確認インシデント報告契約範囲技術調査調査支援報告・通知整理証跡提出提供可能範囲抽出レポート作成提出範囲判断

個人情報・機密情報・営業秘密

ログには、次の情報が含まれる可能性があります。

  • ユーザーID

  • メールアドレス

  • IPアドレス

  • 端末情報

  • サインイン履歴

  • 操作履歴

  • ファイル名

  • リソース名

  • 管理者操作

  • エラー内容

  • 通信先情報

これらが個人情報、個人データ、営業秘密に該当するかは、個別確認が必要です。
本稿では一律に該当性を断定しません。

国外移転がある場合の確認事項

海外SOC、海外サポート、海外クラウド事業者、海外拠点からのログ閲覧がある場合、次を確認します。

  • どの国でログが保存されるか

  • どの国からサポートアクセスがあるか

  • 再委託先が外国にあるか

  • 外国制度の把握が必要か

  • 本人説明・同意・記録が必要か

  • GDPRが関係するか

  • 移転根拠が必要か

  • 委託先監督の証跡をどう残すか

14. 契約条項と技術設定の対応表

契約・規程上の論点Azure側の対応設定確認すべき証跡未確認の場合のリスク対応方針責任分界点Sentinel、Monitor、Support範囲RACI表障害時混乱契約別紙化SLA対象サービス確認SLA資料、障害履歴可用性誤解除外条件確認障害通知Monitor Alert、通知先通知履歴初動遅延通知条件明記インシデント通知Sentinel Incident初報・続報記録報告遅延通知期限設定ログ提供KQL、Export抽出結果監査提出不能形式・期限明記監査権Policy準拠、Defender推奨事項月次レポート監査実効性不足監査方法明記再委託SOC権限、アクセスレビュー委託先台帳再委託把握漏れ再委託条項確認データ所在地Workspaceリージョン設計書国外移転確認漏れリージョン明記国外移転海外サポート有無契約、DPA個人情報保護対応不足法務確認データ削除Workspace、Storage削除削除記録データ残存削除手順明記データ返還Export機能返還形式移行困難形式を契約化暗号化Storage暗号化、Key Vault設定証跡保護水準不明暗号化方針整理アクセス制御RBAC、PIMロール一覧過大権限定期棚卸証跡保存Log Analytics、Storage保持設定証跡不足保存期間表例外運用Policy exemption、RBAC例外例外台帳例外濫用承認制

15. セキュリティ基準への落とし込み

基準・観点実務上の意味Azure側の確認例契約・規程側の確認例未確認の場合のリスクNIST CSF 2.0 Govern経営としてリスク管理する監視対象、責任者、例外承認リスク受容、委託先管理規程技術部門任せになるNIST CSF 2.0 Detect検知能力を持つSentinel、Defender、KQL監視手順、月次報告検知遅延NIST CSF 2.0 Respond対応手順を持つSentinel Incident、通知インシデント規程初動遅延NIST SP 800-53 AU監査ログ管理Activity Log、Log Analyticsログ保存規程証跡不足NIST SP 800-53 ACアクセス制御RBAC、PIM権限管理規程過大権限ISO/IEC 27001ISMSとしてリスク管理Azure Policy、Defender推奨事項適用宣言書、内部監査管理策の有効性を説明できないCIS Controls実装優先度の高い統制ログ管理、脆弱性対応運用チェックリスト実装漏れMicrosoft Cloud Security BenchmarkAzure向け統制整理Logging、IR、Identityクラウド利用規程Azure設定と規程が乖離GDPREU個人データの処理・移転データ所在地、アクセス制御DPA、処理者、移転根拠越境移転確認漏れ個人情報保護法安全管理・委託先監督ログ閲覧権限、海外アクセス委託契約、台帳、本人説明安全管理措置の説明不足

出典：Microsoft Learn、NIST CSF 2.0、NIST SP 800-53 Rev.5、ISO/IEC 27001、EUR-Lex GDPR、個人情報保護委員会ガイドライン。確認日：2026年6月24日。上記表は公式情報をもとに、Azure運用・契約確認・監査証跡の観点で整理したものです。

16. 課題と解決策の対応表

現場で起きる課題根本原因技術的な解決策法務・規程上の解決策証跡として残すものログが残っていない保存期間未定Workspace保持、Storage長期保存ログ保存規程保持設定、承認記録ログ種別が不足対象未棚卸データコネクタ、診断設定監査対象定義ログ一覧提出できない出力手順未整備KQL、Export手順ログ提供条項出力サンプルSOC権限が広すぎるRBAC未設計最小権限、アクセスレビュー委託先管理規程ロール一覧再委託先不明契約確認不足アクセス元確認再委託条項委託先台帳通知が遅れる技術通知と契約通知が未連携Alert、Logic Apps通知期限条項通知履歴例外が残る承認・期限なしPolicy exemption棚卸例外管理規程例外台帳

17. 変更申請・設計レビューで使える観点

レビュー項目確認内容承認者証跡差戻し条件目的何のためのログ保存か情シス責任者変更申請書目的不明対象範囲対象リソース、ログ種別情シス責任者ログ一覧対象漏れ影響範囲コスト、権限、運用影響CISO影響評価コスト未見積セキュリティ影響検知・調査に使えるかCISO設計レビュー検知不能個人情報影響ログ内の個人情報可能性法務・個人情報担当確認メモ未分類契約影響ログ提供、再委託、削除法務契約確認表条項未確認監査影響監査で出せるか内部監査監査観点表証跡不足ロールバック戻し方があるか情シス責任者手順書戻せないテスト結果ログ出力・通知確認情シス責任者テスト記録未実施見直し期限いつ棚卸するかCISO運用計画期限なし

18. 情シス向けチェックリスト

確認項目Azure側の確認場所確認方法証跡未確認の場合のリスク優先度Sentinel対象WorkspaceMicrosoft SentinelWorkspace一覧設計書対象誤り高Entraログ連携Entra管理センター診断設定確認画面記録認証証跡不足高Activity Log長期保存Azure MonitorExport設定確認設定証跡90日後消失高主要リソース診断設定各リソースdiagnostic-settings list設定一覧ログ未取得高Workspace保持期間Log Analyticsテーブル保持確認設定画面監査不備高RBAC最小権限IAMRole assignment確認ロール一覧過大権限高SOC権限IAM / Sentinel委託先アカウント確認台帳委託先管理不足高KQL台帳Log Analyticsクエリ実行クエリ台帳属人化中アラート通知先Sentinel / Monitor通知テスト通知履歴初動遅延高Policy準拠Azure PolicyCompliance確認準拠レポート診断設定漏れ高エクスポート手順Logs / StorageCSV等出力出力サンプル監査提出不可中ロールバックIaC / 変更管理手順確認手順書障害長期化中

19. 法務部向けチェックリスト

契約・規程上の確認項目情シスに確認すべき技術事項確認資料未確認の場合のリスク対応方針クラウド事業者の契約主体契約形態契約書責任先不明契約体系整理再委託先の範囲SOC・サポート範囲委託先一覧委託先監督不足台帳化データ所在地Workspaceリージョン設計書国外移転確認漏れリージョン明記サポート拠点海外アクセス有無サポート資料外的環境把握不足所在国確認ログ提供KQL・Export可否契約別紙監査提出不能形式・期限明記監査権レポート取得可否監査条項実効性不足レポート種別確認障害通知Alert通知先SLA通知遅延条件・期限明記インシデント通知Sentinel Incident規程・契約漏えい対応遅延初報・続報整理データ返還Export形式契約終了条項移行困難返還形式明記データ削除Workspace/Storage削除削除条項データ残存削除証明確認個人情報の定義ログ内識別子個人情報台帳分類不備台帳反映機密情報の定義リソース名・操作履歴秘密情報規程営業秘密管理不備規程見直し損害賠償事故時責任範囲契約書リスク過大弁護士確認自社規程との整合保存期間・閲覧者規程類監査指摘規程改定

20. 経営層向け判断ポイント

経営判断テーマ判断内容情シスの論点法務の論点経営上のリスク推奨アクションログ監査投資どこまで保存するかSentinel、Storage、コスト保存期間、提出義務説明不能重要システム優先リスク受容何を受容するか技術的制約契約上の限界過少対策残存リスク表作成SOC委託外部監視範囲権限、アラート再委託、監査権責任不明RACI作成監査対応取引先審査活用証跡抽出契約・規程信用低下証跡テンプレ化障害時優先度復旧順序Backup、DRSLA、通知事業停止BCP連動個人情報保護保護水準ログ閲覧制御委託先監督漏えい時信用低下台帳・規程整備

経営層が見るべき数字は、単なるログ容量ではありません。

重要なのは、重大インシデント時に、どれだけ早く、どれだけ正確に、どの証跡をもとに説明できるかです。

21. 山崎行政書士事務所としての支援領域

山崎行政書士事務所では、Azureの設計・実装・運用監査の現場感と、契約・規程・個人情報保護・委託先管理の法務文書化をつなぐ支援を行っています。

クラウドの問題は、技術だけでも、契約だけでも整理しきれません。
ID、ログ、権限、データ所在地、再委託、削除証明、監査証跡を同じ表で見える化することが、実務上の第一歩です。

支援領域は次のとおりです。

  • Azure導入・移行の企画支援

  • Azure設計レビュー

  • Azure実装方針の整理

  • Microsoft Entra IDの設計支援

  • 条件付きアクセス設計支援

  • Microsoft Defender for Cloudの設計・運用整理

  • Microsoft Sentinelのログ監査設計支援

  • Microsoft Purviewの情報ガバナンス整理

  • Azure Policyによる統制設計支援

  • Azure Monitorによる監視設計支援

  • Azure Virtual Desktopの設計支援

  • セキュリティ基準への対応整理

  • NIST CSF 2.0、NIST SP 800-53、ISMS、GDPR等との対応整理

  • クラウド契約・委託契約・規程類の確認観点整理

  • 個人情報保護・委託先管理・情報管理体制の文書化支援

  • 情シスと法務部の橋渡し

  • 経営層向け説明資料の作成支援

  • 監査対応資料の整理支援

  • クラウド利用規程、生成AI利用規程、情報管理規程の整備支援

ただし、紛争性のある法律事件、代理交渉、訴訟対応、個別の法律判断が必要な事項は、弁護士等の専門家確認が必要です。

22. まとめ

Sentinel導入で最初に決めるべきことは、分析ルールの数ではありません。

最初に決めるべきことは、次の3つです。

  1. 情シスは、Sentinelに送るログ種別、保存期間、診断設定、RBACを一覧化する。

  2. 法務部は、ログ提供、再委託、障害通知、インシデント通知、削除・返還、国外移転の契約確認表を作る。

  3. 経営層は、ログ監査へ投資する範囲と、受容する残存リスクを決める。

ログは、取るだけでは足りません。
必要な時に、必要な権限者が、必要な形式で、契約・規程・監査要件に沿って提出できることが重要です。

23. 確認済み事項

確認日：2026年6月24日

  1. Microsoft Sentinelは、クラウドネイティブSIEMとして、脅威検知、調査、対応、ハンティングを支援するサービスとしてMicrosoft Learnで説明されています。

  2. Microsoft Sentinelは、データコネクタを利用してMicrosoftサービスや外部サービス等のデータを取り込む仕組みとして説明されています。

  3. Microsoft Entra IDのサインインログ・監査ログは、診断設定によりAzure Monitor Logsへ統合できることがMicrosoft Learnで説明されています。

  4. Azure Activity Logは既定で90日保持され、長期保持には診断設定等による別保存が必要であることがMicrosoft Learnで説明されています。

  5. Azure Monitorの診断設定では、プラットフォームメトリック、リソースログ、Activity Log等をLog Analytics Workspace、Storage Account、Event Hubs等へ送る設計が説明されています。

  6. Microsoft Sentinelでは、分析保持、長期保持、データ保持階層に関する公式説明があります。

  7. Microsoft Sentinelは、2027年3月31日以降Azure portalではサポートされず、Microsoft Defenderポータルで利用する旨がMicrosoft Learnで説明されています。

  8. NIST CSF 2.0は、サイバーセキュリティリスク管理の枠組みとしてNISTから公表されています。

  9. NIST SP 800-53 Rev.5は、情報システムと組織のためのセキュリティ・プライバシー管理策カタログとして公表されています。

  10. 個人情報保護委員会Q&Aでは、クラウドサービス利用時にクラウド事業者が個人データを取り扱うか否かにより、第三者提供・委託先監督の整理が必要となる旨が示されています。

  11. GDPRはEUR-Lexで公式テキストを確認できます。

  12. ISO/IEC 27001:2022は、ISMS要求事項を定める規格としてISO公式ページで説明されています。

24. 公式情報をもとにした要約

  • Microsoft Sentinelは、ログを取り込み、検知・調査・対応を支援するSIEM基盤です。

  • Entra IDのサインインログや監査ログは、Azure Monitor Logsへ統合し、他のAzureログと合わせて分析できます。

  • Azure Activity Logは既定で90日保持されます。長期保持や監査証跡化が必要な場合は、診断設定等による保存設計が必要です。

  • SentinelやLog Analyticsの保持設計では、分析用に使う期間と長期保存する期間を分けて考える必要があります。

  • Azure Policyは、診断設定の展開や準拠確認に利用できます。

  • 個人情報保護法上、クラウドサービス事業者が個人データを取り扱うか、委託先監督が必要か、国外における取扱いがあるかは個別確認が必要です。

  • GDPRが関係する場合、個人データの処理、処理者との契約、セキュリティ、侵害通知、域外移転を確認する必要があります。

25. 実務上の考察

  1. Sentinel導入の失敗は、製品選定よりも、ログ種別・保存期間・契約条項・監査証跡の未整理から起きやすいと考えます。

  2. ログ保存期間は、情シスだけで決めるより、契約、規程、監査、個人情報保護、取引先説明と整合させる方が実務上安全です。

  3. Azure Policyによる診断設定の監査・自動展開は、ログ未取得リスクを下げるうえで有効です。ただし、導入前に例外運用を整備しないと現場の運用を止める可能性があります。

  4. SOC委託では、監視範囲だけでなく、ログ閲覧権限、再委託、海外アクセス、証跡提出範囲を整理すべきです。

  5. 経営層への説明では、製品名よりも、残存リスク、費用対効果、監査説明可能性、事業継続の観点で整理する方が伝わりやすいです。

26. 推測・仮説

以下は、公式情報そのものではなく、実務上の推測・仮説です。

  1. ログ監査基盤の未整備は、インシデント時だけでなく、取引先審査や入札時にも不利に働く可能性があります。

  2. Sentinelの導入効果は、アラート数ではなく、重大時に説明できる証跡を出せるかで評価される可能性があります。

  3. NIST CSF 2.0やISMSとAzure設定を対応表にすると、情シス・法務・経営層の合意形成が進みやすくなる可能性があります。

  4. Defenderポータルへの移行・統合により、既存の運用手順、権限設計、監査証跡取得手順の見直しが必要になる可能性があります。

27. 確認できない事項

以下は、個別環境・個別契約を確認しない限り断定できません。

  1. 個別企業に必要なログ保存期間

  2. 個別企業にGDPRが適用されるかどうか

  3. 個別契約における条項の有効性、損害賠償範囲、責任制限

  4. 個別テナントで利用可能なMicrosoft Sentinel機能、ライセンス、課金額

  5. KQLサンプルが個別環境でそのまま動作するかどうか

  6. ログに含まれる情報が個人情報、個人データ、営業秘密に該当するかどうか

  7. Microsoft Sentinelの将来機能、廃止予定、移行期限のうち、公式情報で確認できない内容

  8. 紛争性のある案件における法的判断

  9. 個別企業のSOC委託先・再委託先・海外サポート拠点

  10. 個別企業の監査要件、取引先要求、業界規制

28. 主な参照情報

確認日：2026年6月24日

Microsoft関連

NIST関連

個人情報保護法関連

GDPR・EU関連

  • 出典名：Regulation (EU) 2016/679, General Data Protection Regulation
    発行元：EUR-Lex
    URL：https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng
    使用箇所：GDPR、処理者、セキュリティ、侵害通知、域外移転
    使用区分：要約

ISMS・CIS関連

山崎行政書士事務所関連

いいなと思ったら応援しよう！