Microsoft Sentinel導入前に決めるべきログ種別・保存期間・契約条項

2026年7月8日 06:30

2. リード文

この記事では、Microsoft Sentinelを導入する前に、情シス・法務部・内部監査部門・経営層が同じ表で確認すべき「ログ種別」「保存期間」「契約条項」「監査証跡」を整理します。

対象読者は、Azure環境を管理する情報システム担当者、情報システム部門責任者、CISO、法務部、内部監査部門、経営層です。

Microsoft Sentinelは、クラウド環境のログ監査、脅威検知、インシデント対応に有効な基盤です。
ただし、導入すれば自動的に監査対応が完成するわけではありません。

現場で問題になるのは、次のような場面です。

「ログは取っているが、監査で必要な形式で出せない」
「保存期間を情シスだけで決め、契約・規程と整合していない」
「SOC委託先や再委託先がどのログを見られるのか、法務部が把握していない」
「インシデント時に、誰が、いつ、どの証跡を提出するのか決まっていない」

この状態では、Sentinelは強力なSIEMであっても、経営層・法務部・内部監査部門に説明できる証跡基盤にはなりません。

3. 今回の論点

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

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

本稿では、Azureセキュリティ全般やゼロトラスト全体を広く説明しません。
あくまで、Sentinel導入前に決めるべき「ログ種別・保存期間・契約条項・監査証跡」に絞ります。

4. 結論

結論は、次のとおりです。

情シスがすべきこと

情シスは、ログを「取れるか」だけで設計してはいけません。

以下を設計時点で決める必要があります。

どのログをSentinelに送るか
どのログをLog Analytics Workspaceで分析するか
どのログを長期保管するか
どのログを監査提出対象にするか
誰が閲覧・検索・エクスポートできるか
どのKQLで証跡を抽出するか
保持期間とコストをどう管理するか

Microsoft公式情報では、Microsoft Sentinelはデータコネクタを通じてMicrosoftサービスや外部サービスのデータを取り込む仕組みとして説明されています。
また、Microsoft Entra IDのサインインログや監査ログは、診断設定によりAzure Monitor Logsへ統合し、他のAzureデータと合わせて分析できることが説明されています。

法務部がすべきこと

法務部は、クラウド契約を単なる購買契約として読んではいけません。

SentinelやSOC運用に関係する契約では、少なくとも次を確認する必要があります。

ログ提供範囲
ログ保存期間
障害通知
インシデント通知
再委託
監査権
データ所在地
国外移転
データ返還
データ削除
個人情報・機密情報・営業秘密の取扱い

特に、ログにはユーザーID、メールアドレス、IPアドレス、端末情報、サインイン履歴、操作履歴などが含まれる場合があります。
これらが個人情報、個人データ、営業秘密に該当するかは、個別環境・個別契約・社内規程を確認する必要があります。

経営層がすべきこと

経営層は、「すべてのログを長期保存する」か「最低限のログだけ取る」かを、現場任せにしてはいけません。

判断すべきことは次のとおりです。

どの業務を重点監視対象にするか
どのリスクを受容するか
どのリスクを技術で下げるか
どのリスクを契約条項で下げるか
どのリスクをSOC委託・保険・監査で補完するか
ログ保存にどこまで投資するか
重大インシデント時にどこまで説明責任を果たすか

ログ監査は、単なる技術費用ではありません。
取引先審査、ISMS監査、個人情報保護、BCP、経営説明の基盤です。

5. なぜこの論点が重要か

現場で起きやすい失敗

Sentinel導入で起きやすい失敗は、製品選定ミスではありません。
多くは、導入前の設計不足です。

現場で起きる失敗技術上の原因法務・監査上の問題ログが監査時に残っていない保持期間を初期設定のままにした契約・規程で求める証跡を出せないログはあるが検索できないKQLやテーブル構造が属人化証跡提出が遅れる重要リソースのログがない診断設定が未設定インシデント時に原因を追えないSOCが見られる範囲が広すぎるRBAC設計が粗い委託先管理・秘密管理の問題再委託先の関与が不明SOC・サポート体制を未確認個人情報保護・監査権の確認不足通知が遅れるアラートと契約通知期限が連動していない障害・漏えい時の初動が遅れる

Microsoft公式情報では、Azure Activity Logは既定で90日保持され、長期保持や追加機能が必要な場合は診断設定でLog Analytics Workspace、Storage、Event Hubs等へ送る設計が必要と説明されています。
この点からも、ログ保持は「あとで設定する運用項目」ではなく、導入前に決めるべき設計事項です。

情シスだけでは解決しにくい論点

情シスは、ログ取得やKQL、診断設定、Azure Policyの設計はできます。
しかし、次の判断は情シス単独では難しいことが多いです。

監査で何年分の証跡が必要か
取引先契約でログ提出義務があるか
個人情報を含むログの保存期間は適切か
海外SOCや海外サポートがログを見る場合、国外移転の確認が必要か
契約終了時にログ削除証明が必要か
インシデント通知期限は何時間以内にすべきか

法務部だけでは判断しにくい技術論点

一方、法務部だけでは次を判断しにくいです。

Entra IDサインインログと監査ログの違い
Azure Activity Logとリソースログの違い
Log Analytics Workspaceの保持設定
Sentinelの分析用保持と長期保持
診断設定で送れる宛先
Azure Policyでログ未設定を検出・修復できる範囲
KQLで実際に監査証跡を抽出できるか
SOC委託先に必要な最小権限

つまり、Sentinelのログ監査設計は、情シスと法務部が共同で行うべき領域です。

経営層が判断すべきリスク受容

ログ監査には費用がかかります。

Microsoft Sentinelでは、データ取り込み、分析、保持、長期保管、検索、関連サービス利用などがコストに影響します。
すべてのログを高性能な分析対象として長期間保持すれば、コストは増えます。
一方で、ログを削りすぎると、インシデント時に説明できません。

経営層は、次を判断する必要があります。

重要システムだけ長期保存するか
全社IDログを長期保存するか
FirewallやWAFログをどこまで保存するか
SOC委託範囲を24時間365日にするか
監査提出用の証跡整備に投資するか
取引先審査や入札でセキュリティ基準対応を活用するか

6. 対象サービスと前提条件

今回の論点に直接関係するサービス・文書・基準は次のとおりです。

Azure／Microsoft側

Microsoft Sentinel
Log Analytics Workspace
Azure Monitor
Azure Activity Log
診断設定
Microsoft Entra ID
Entra IDサインインログ
Entra ID監査ログ
Azure RBAC
Microsoft Defender for Cloud
Azure Policy
Azure Storage
Event Hubs
Logic Apps
Key Vault
Microsoft Defenderポータル

契約・規程側

クラウド契約
運用委託契約
SOC委託契約
SLA
クラウド利用規程
情報セキュリティ規程
ログ管理規程
インシデント対応規程
委託先管理規程
個人情報取扱規程
監査対応手順書
契約終了時のデータ返還・削除手順

セキュリティ基準・法令等

Microsoft Cloud Security Benchmark
NIST CSF 2.0
NIST SP 800-53
ISO/IEC 27001、ISMS
CIS Controls
GDPR
日本の個人情報保護法
個人情報保護委員会ガイドライン

本稿では、Azure Virtual Desktop、Azure OpenAI Service、Purviewの詳細設定、ネットワーク全体設計には踏み込みません。
ただし、ログ監査に関連する範囲では、Entra ID、Defender for Cloud、Azure Policy、Key Vault、Storage等に触れます。

7. 現場作業粒度の技術解説

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

Sentinel導入前に、少なくとも次の画面を確認します。

確認対象Azure Portal上の主な確認場所確認する内容Microsoft SentinelMicrosoft SentinelWorkspace、データコネクタ、分析ルール、インシデントLog Analytics WorkspaceLog Analytics workspacesテーブル、保持期間、アクセス制御、コストAzure Activity LogMonitor > Activity logサブスクリプション操作履歴診断設定各リソース > Diagnostic settingsLog Analytics、Storage、Event Hubsへの送信Entra IDログEntra admin center > Monitoring & healthサインインログ、監査ログ、診断設定Azure PolicyPolicy診断設定強制、監査、準拠状況Defender for CloudDefender for Cloud推奨事項、セキュリティ態勢、アラートRBACAccess control (IAM)ロール割当、過大権限StorageStorage accounts長期保存、削除保護、アクセス制御Key VaultKey Vaultsシークレット・キー管理、監査ログ

7-2. ログ種別の設計

最初に決めるべきは、Sentinelへ送るログ種別です。

優先度が高いログは次のとおりです。

ログ種別主な目的監査・契約上の意味Entra IDサインインログ認証成功・失敗、不審なアクセス確認不正アクセス調査Entra ID監査ログユーザー、グループ、ポリシー変更権限変更の証跡Azure Activity Logサブスクリプション操作履歴管理操作の証跡Key Vaultログキー・シークレットアクセス確認機密情報管理Storageログデータアクセス、削除、変更確認データ保護、削除証跡Azure Firewallログ通信制御、外部接続確認境界防御の証跡WAFログWeb攻撃検知攻撃調査、取引先説明Defender for Cloudアラートセキュリティ態勢・脅威検知リスク管理Sentinelインシデント検知・調査・対応記録インシデント対応証跡

すべてのログを同じ扱いにしてはいけません。
以下の3階層で分けます。

即時分析ログ
SOCや情シスが日常的にKQLで検索し、アラート対象にするログ。
監査証跡ログ
月次監査、取引先説明、内部監査で提出する可能性があるログ。
長期保全ログ
重大インシデント、契約紛争化リスク、個人情報漏えい調査、BCP上の確認に備えて保全するログ。

7-3. Log Analytics Workspaceと保持期間

Log Analytics Workspaceでは、テーブル単位の保持設計が重要です。

Microsoft公式情報では、Log Analytics Workspaceのテーブルで分析保持と総保持を設定できることが説明されています。
また、Microsoft Sentinelでは、分析保持と長期保持、データレイク等の考え方が示されています。

実務では、次を決めます。

Workspaceを本番・検証で分けるか
子会社・海外拠点ごとに分けるか
SOC委託先にどのWorkspaceを見せるか
テーブル単位で保持期間を変えるか
監査用ログをStorageにも保管するか
コスト配賦をどう行うか

保持期間は、単に「90日」「1年」と決めるのではなく、次の表で整理します。

ログ区分目的例保存方針日常監視SOC・情シスの日次調査サインイン失敗、アラート短期分析向け月次監査権限変更、設定変更レビューRole assignment、Policy変更中期保持重大インシデント侵害調査、時系列復元ID、Firewall、WAF、Key Vault長期保持契約・規程対応取引先説明、監査提出操作履歴、削除証跡契約・規程に合わせる

7-4. 診断設定とAzure Policy

Sentinelへログを送るには、各リソースの診断設定が重要です。

確認すべき項目は次のとおりです。

対象リソース種別
送信先Workspace
送信先Storage
送信先Event Hubs
送信するログカテゴリ
メトリック送信有無
診断設定名
設定変更者
設定変更履歴

Azure Policyを使えば、診断設定の漏れを監査・是正する設計が可能です。

ただし、いきなりDenyを設定すると、現場のリソース作成が止まる場合があります。
実務上は、次の段階導入が現実的です。

Auditで現状把握
DeployIfNotExistsで自動展開
例外管理台帳を整備
本番重要リソースだけDenyを検討
月次で準拠状況を監査証跡化

7-5. RBACと証跡提出権限

Sentinelでは、閲覧、調査、設定変更、証跡提出の権限を分けます。

役割必要な権限の考え方注意点SOC監視担当インシデント閲覧・更新設定変更権限は不要な場合がある情シス管理者コネクタ、分析ルール管理過大権限に注意監査担当ログ閲覧、証跡確認改変権限は不要法務担当証跡の確認、提出範囲判断技術管理権限は不要外部委託先契約範囲内の最小権限再委託先も含めて台帳化緊急対応者一時的な高度権限PIMや承認履歴が重要

管理者が証跡を自由に削除・変更できる状態では、監査説明が弱くなります。
証跡提出権限と設定変更権限は分けるべきです。

7-6. CLI・PowerShell・KQLの確認例

以下は概念サンプルです。
テナント固有値、サブスクリプションID、実IP、実アカウント名は含めません。
個別環境で実行する場合は、権限、対象スコープ、テーブル名、保持期間を確認してください。

Azure CLI：診断設定の確認例

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

確認することは、送信先Workspace、Storage、Event Hubs、ログカテゴリです。

Azure CLI：Activity Logの確認例

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

確認することは、操作種別、実行者、状態、時刻、対象リソースです。

PowerShell：ロール割当確認例

Get-AzRoleAssignment -Scope "<scope>"

確認することは、誰に、どのロールが、どのスコープで付与されているかです。

KQL：サインイン失敗の多いユーザー確認例

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

KQL：Azureロール割当変更の確認例

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

KQL：診断設定変更の確認例

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

これらは概念サンプルです。
実環境で該当テーブルが存在するか、データが取り込まれているかは要確認です。

7-7. IaCで管理する場合の考え方

TerraformやBicepで管理する場合、次を設計します。

Workspace作成
Sentinel有効化
診断設定
Azure Policy割当
RBAC割当
Storage長期保存
Key Vault設定
アラート設定
変更承認
ロールバック
Stateファイル保護
機密値の管理

IaC化しても、法務・監査上の証跡が自動的に整うわけではありません。
Pull Request、承認履歴、変更理由、リリース記録を残す必要があります。

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

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

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

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

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

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

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

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

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

SentinelやSOC運用を含むクラウド契約では、以下を確認します。

サービス範囲
責任分界点
SLA
障害時の通知
インシデント通知
データ所在地
再委託
監査権
ログ提供
データ削除
データ返還
個人情報の取扱い
機密情報の取扱い
営業秘密の取扱い
国外移転
証跡保全
契約終了時の処理
損害賠償責任の範囲

責任分界点

責任分界点は、次のように整理します。

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

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

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

ユーザーID
メールアドレス
IPアドレス
端末情報
サインイン履歴
操作履歴
ファイル名
リソース名
管理者操作
エラー内容
通信先情報

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

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

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

どの国でログが保存されるか
どの国からサポートアクセスがあるか
再委託先が外国にあるか
外国制度の把握が必要か
本人説明・同意・記録が必要か
GDPRが関係するか
SCC等の移転根拠が必要か
委託先監督の証跡をどう残すか

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

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

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

基準・観点実務上の意味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運用・契約確認・監査証跡の観点で整理したものです。

14. 図表

図表1：Sentinelログ監査設計の全体像

[ログ発生源]
Entra ID / Azure Activity / Key Vault / Storage / Firewall / WAF / Defender
        ↓
[収集]
診断設定 / データコネクタ / Azure Policy
        ↓
[分析]
Microsoft Sentinel / Log Analytics / KQL / 分析ルール
        ↓
[対応]
インシデント / 通知 / SOC一次対応 / 情シス調査
        ↓
[証跡化]
ログ抽出 / 月次レポート / 監査資料 / 契約上の提出資料
        ↓
[改善]
保持期間見直し / RBAC棚卸 / 契約条項見直し / 規程改定

この図は、情シスが設計時に、法務部が契約確認時に、経営層が投資判断時に使うための整理です。
未確認の場合、ログ取得はできても、監査提出・契約説明・インシデント報告に使えないリスクがあります。

図表2：技術要件と法務確認事項の対応表

判断テーマ主な利用者確認項目未確認の場合のリスク次のアクションログ種別情シスどのログをSentinelへ送るか重要証跡が不足ログ一覧作成保存期間情シス・法務何日・何年保存するか監査時に消失規程と契約に反映閲覧権限情シス・監査誰が検索・提出できるか過大権限RBAC棚卸SOC委託法務・情シス委託先が見るログ範囲委託先管理不足契約別紙作成国外移転法務海外保存・海外アクセス個人情報保護対応不足所在国確認証跡提出法務・監査形式、期限、真正性監査対応遅延提出手順作成コスト経営層保存範囲と費用過剰投資または過少対策リスク別投資判断

出典：Microsoft Learn「Microsoft Sentinel」「Azure Monitor診断設定」「Activity Log」、個人情報保護委員会ガイドライン。確認日：2026年6月24日。上記表は公式情報をもとに、実務確認用に山崎行政書士事務所が整理したものです。

図表3：ログ保存・監査・インシデント対応の流れ

フェーズ情シスの作業法務・監査の作業経営判断導入前対象ログ・保存期間案契約・規程確認リスク受容方針設計時Workspace、診断設定、RBACログ提供・再委託・監査権投資範囲実装時Sentinel、Policy、KQL契約別紙・台帳反映重点対象承認テスト時ログ検索、アラート、権限確認証跡提出テスト業務影響確認運用時月次監視、棚卸委託先管理、規程見直し残存リスク確認インシデント時検知、切り分け、証跡保全通知、報告、提出判断対外説明方針監査時設定・ログ提示監査回答改善投資判断

図表4：残存リスクと経営判断の関係

残存リスク技術で下げる方法契約で下げる方法経営判断ログ不足診断設定、Policyログ提供条項重点ログに投資検知遅延Sentinel分析ルールSOC応答時間監視範囲を決定過大権限RBAC、PIM委託先権限制限棚卸頻度を決定国外アクセスリージョン・アクセス制御国外移転条項海外利用を許容するか削除不能Storage設計、削除手順削除証明条項証明取得に投資監査説明不足レポート自動化監査権条項取引先審査活用

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

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

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

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

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

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

経営層が見るべき数字は、単なるログ容量ではありません。
重要なのは、重大インシデント時に、どれだけ早く、どれだけ正確に、どの証跡をもとに説明できるかです。

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

山崎行政書士事務所では、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利用規程、情報管理規程の整備支援

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

19. まとめ

Microsoft Sentinel導入前に確認すべきことは、分析ルールやダッシュボードだけではありません。

明日から実行すべきことは、次の3つです。

情シスは、Sentinelに送るログ種別、保存期間、診断設定、RBACを一覧化する。
法務部は、ログ提供、再委託、障害通知、インシデント通知、削除・返還、国外移転の契約確認表を作る。
経営層は、ログ監査へ投資する範囲と、受容する残存リスクを決める。

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

山崎行政書士事務所では、この「技術設定」と「法務文書」と「監査証跡」の接続部分を整理する支援を行います。

20. 確認済み事項

確認日：2026年6月24日

Microsoft Sentinelは、クラウドネイティブSIEMとして、脅威検知、調査、対応、ハンティングを支援するサービスとしてMicrosoft Learnで説明されています。
Microsoft Sentinelは、データコネクタを利用してMicrosoftサービスや外部サービス等のデータを取り込む仕組みとして説明されています。
Microsoft Entra IDのサインインログ・監査ログは、診断設定によりAzure Monitor Logsへ統合できることがMicrosoft Learnで説明されています。
Azure Activity Logは既定で90日保持され、長期保持には診断設定等による別保存が必要であることがMicrosoft Learnで説明されています。
Azure Monitorの診断設定では、プラットフォームメトリック、リソースログ、Activity Log等をLog Analytics Workspace、Storage Account、Event Hubs等へ送る設計が説明されています。
Microsoft Sentinelでは、分析保持、長期保持、データ保持階層に関する公式説明があります。
Microsoft Sentinelは、2027年3月31日以降Azure portalではサポートされず、Microsoft Defenderポータルで利用する旨がMicrosoft Learnで説明されています。
NIST CSF 2.0は、サイバーセキュリティリスク管理の枠組みとしてNISTから公表されています。
NIST SP 800-53 Rev.5は、情報システムと組織のためのセキュリティ・プライバシー管理策カタログとして公表されています。
個人情報保護委員会Q&Aでは、クラウドサービス利用時にクラウド事業者が個人データを取り扱うか否かにより、第三者提供・委託先監督の整理が必要となる旨が示されています。
GDPRはEUR-Lexで公式テキストを確認できます。
ISO/IEC 27001:2022は、ISMS要求事項を定める規格としてISO公式ページで説明されています。

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

Microsoft Sentinelは、ログを取り込み、検知・調査・対応を支援するSIEM基盤です。
Entra IDのサインインログや監査ログは、Azure Monitor Logsへ統合し、他のAzureログと合わせて分析できます。
Azure Activity Logは既定で90日保持されます。長期保持や監査証跡化が必要な場合は、診断設定等による保存設計が必要です。
SentinelやLog Analyticsの保持設計では、分析用に使う期間と長期保存する期間を分けて考える必要があります。
Azure Policyは、診断設定の展開や準拠確認に利用できます。
個人情報保護法上、クラウドサービス事業者が個人データを取り扱うか、委託先監督が必要か、国外における取扱いがあるかは個別確認が必要です。
GDPRが関係する場合、個人データの処理、処理者との契約、セキュリティ、侵害通知、域外移転を確認する必要があります。

22. 実務上の考察

Sentinel導入の失敗は、製品選定よりも、ログ種別・保存期間・契約条項・監査証跡の未整理から起きやすいと考えます。
ログ保存期間は、情シスだけで決めるより、契約、規程、監査、個人情報保護、取引先説明と整合させる方が実務上安全です。
Azure Policyによる診断設定の監査・自動展開は、ログ未取得リスクを下げるうえで有効です。ただし、導入前に例外運用を整備しないと現場の運用を止める可能性があります。
SOC委託では、監視範囲だけでなく、ログ閲覧権限、再委託、海外アクセス、証跡提出範囲を整理すべきです。
経営層への説明では、製品名よりも、残存リスク、費用対効果、監査説明可能性、事業継続の観点で整理する方が伝わりやすいです。

23. 推測・仮説

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

ログ監査基盤の未整備は、インシデント時だけでなく、取引先審査や入札時にも不利に働く可能性があります。
Sentinelの導入効果は、アラート数ではなく、重大時に説明できる証跡を出せるかで評価される可能性があります。
NIST CSF 2.0やISMSとAzure設定を対応表にすると、情シス・法務・経営層の合意形成が進みやすくなる可能性があります。
Defenderポータルへの移行・統合により、既存の運用手順、権限設計、監査証跡取得手順の見直しが必要になる可能性があります。

24. 確認できない事項

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

個別企業に必要なログ保存期間
個別企業にGDPRが適用されるかどうか
個別契約における条項の有効性、損害賠償範囲、責任制限
個別テナントで利用可能なMicrosoft Sentinel機能、ライセンス、課金額
KQLサンプルが個別環境でそのまま動作するかどうか
ログに含まれる情報が個人情報、個人データ、営業秘密に該当するかどうか
Microsoft Sentinelの将来機能、廃止予定、移行期限のうち、公式情報で確認できない内容
紛争性のある案件における法的判断
個別企業のSOC委託先・再委託先・海外サポート拠点
個別企業の監査要件、取引先要求、業界規制

25. 主な参照情報