Microsoft Sentinel導入前に決めるべき、ログ保存・責任分界点・監査証跡の実務

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

Microsoft Sentinelは、クラウド時代のログ監査・脅威検知・インシデント対応を支える重要な基盤です。

しかし、Sentinelを導入すれば、監査対応やインシデント対応が自動的に完成するわけではありません。
現場で問題になるのは、むしろ導入後です。

「ログは取っているが、監査で必要な形式で出せない」
「障害時や不正アクセス時に、誰が一次切り分けをする契約なのか不明」
「保存期間を情シスだけで決め、契約・規程・個人情報保護と整合していない」
「SOC委託先、再委託先、海外サポートがログへアクセスする範囲を法務部が把握していない」

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

この記事では、Microsoft Sentinelを中心に、Azure技術設計、クラウド契約、個人情報保護、NIST・ISMS等のセキュリティ基準を、同じ表で整理する実務を解説します。

結論は明確です。

Microsoft Sentinel導入では、分析ルールより先に、ログ保存方針、責任分界点、契約・規程上の証跡提出ルールを決めるべきです。

情シスは、Log Analytics Workspace、データコネクタ、診断設定、Azure Policy、RBAC、KQL、保管期間、コストを設計します。
法務部は、SLA、障害通知、再委託、監査権、ログ提供、データ返還・削除、個人情報・機密情報の取扱いを確認します。
経営層は、どのリスクを受容し、どのリスクを技術・契約・外部委託・監査で下げるかを判断します。

Microsoft Learnでは、SentinelはクラウドネイティブSIEMとして、マルチクラウド・マルチプラットフォーム環境での脅威検知、調査、対応、ハンティングを支援するサービスと説明されています。
また、Sentinelはデータコネクタを使ってデータを取り込む仕組みであり、MicrosoftサービスだけでなくSyslog、CEF、REST API等を使った外部データ連携も説明されています。

つまり、Sentinel導入とは「ログを集める設定作業」ではありません。
実務上は、ID、権限、ログ、契約、委託先、国外移転、監査証跡を統合して設計するプロジェクトです。

4. なぜ今このテーマが重要か

現場で起きやすい失敗

SentinelやAzure Monitorを導入した現場で起きやすい失敗は、次のとおりです。

現場の失敗技術上の原因法務・監査上の問題ログが足りない診断設定の対象外リソースがあるインシデント時に証跡が不足するログが残っていない保持期間を初期値のままにした監査・契約上必要な期間を満たさないログはあるが出せないKQL・出力手順が属人化監査提出や取引先説明が遅れるアラートが多すぎる分析ルールのチューニング不足重大インシデントの見落としにつながる誰が対応するか不明SOC・情シス・クラウド事業者の分担未整理障害通知・漏えい対応・責任分界が曖昧海外アクセスを把握していないサポート拠点・SOC拠点を未確認個人情報保護法・GDPR・契約上の確認不足

Azure Activity Logについて、Microsoft Learnではイベントは90日保持後に削除され、長期保持等が必要な場合は診断設定により別の場所へ送る必要があると説明されています。
Azure Monitorの診断設定は、ポータル、PowerShell、CLI、ARM、Bicep、REST API等で作成できることが公式情報で確認できます。

ここから分かる実務上の要点は、ログ保存期間は後から考えるものではなく、設計段階で契約・規程・監査要件と合わせて決めるものだということです。

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

情シスは、ログの取り込み、KQL、アラート、RBAC、コスト、Azure Policyには強くても、次の論点は単独では判断しにくいです。

  • 契約上、何日以内に障害・インシデントを通知すべきか

  • ログ提出の範囲と形式を契約でどう定めるか

  • 個人情報や営業秘密を含むログの保存期間をどう定めるか

  • SOC委託先・再委託先のログアクセスをどう記録するか

  • 国外移転や海外サポートの有無をどう確認するか

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

一方、法務部だけでは次の判断は難しくなります。

  • Entra IDサインインログと監査ログの違い

  • Azure Activity Logとリソースログの違い

  • Log Analytics Workspaceの保持設定

  • Sentinelに送るログとStorageに長期保管するログの使い分け

  • Azure Policyで診断設定を強制できる範囲

  • SOCが必要とするRBAC権限

  • KQLで実際に証跡抽出できるか

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

経営層が見るべきなのは、製品導入費だけではありません。

  • どのシステムを重点監視対象にするか

  • どこまでログを長期保存するか

  • SOC委託にどこまで費用をかけるか

  • 重大インシデント時にどこまで説明責任を果たすか

  • 取引先監査・入札・ISMS対応へ投資を活用するか

  • 障害時にどの業務を優先復旧するか

Microsoft Cloud Security Benchmarkでも、ログ・脅威検知は、クラウドサービスの監査ログの有効化、収集、保存、SIEMによる集中分析、時刻同期、ログ保持を含む統制として整理されています。

5. 技術面の実務ポイント

対象サービス

本稿の対象は次のサービスです。

  • Microsoft Sentinel

  • Log Analytics Workspace

  • Azure Monitor

  • Azure Activity Log

  • 診断設定

  • Microsoft Entra ID

  • 条件付きアクセス

  • Privileged Identity Management

  • Azure RBAC

  • Azure Policy

  • Microsoft Defender for Cloud

  • Microsoft Purview

  • Key Vault

  • Private Endpoint

  • NSG

  • Azure Firewall

  • Azure Backup

  • Storage Account

  • Event Hubs

  • Logic Apps

  • Terraform / Bicep / Azure CLI / PowerShell / KQL

Microsoft SentinelはAzure RBACを利用して組み込みロールやカスタムロールを提供することがMicrosoft Learnで説明されています。
条件付きアクセスは、Microsoftがゼロトラストのポリシーエンジンとして説明しており、各種シグナルを用いてポリシー判断を行います。
PIMは、重要なリソースへのアクセスを管理・制御・監視するMicrosoft Entra IDのサービスとして説明されています。

設計時に決めるべき項目

1. ログ収集対象

最初に、Sentinelへ送るログを決めます。

優先度が高い候補は次のとおりです。

  • Microsoft Entra IDサインインログ

  • Microsoft Entra ID監査ログ

  • Azure Activity Log

  • Key Vault診断ログ

  • Storage診断ログ

  • Azure Firewallログ

  • Application Gateway / WAFログ

  • NSGフローログ

  • Defender for Cloudアラート

  • Microsoft 365関連ログ

  • EDR、VPN、SaaS、Firewall等の外部ログ

すべてのログを無条件にSentinelへ送ると、コストとノイズが膨らみます。
実務上は、以下を優先します。

  • 管理者権限の変更

  • 認証失敗・不審なサインイン

  • 条件付きアクセスの変更

  • Key VaultやStorage等の重要リソースアクセス

  • 外部公開経路の通信

  • 個人情報・機密情報を扱う業務システム

  • 監査・契約・規程で必要な証跡

2. Log Analytics Workspace設計

Workspace設計では、次を決めます。

設計項目確認内容注意点リージョンログ保存リージョンデータ所在地・契約・国外移転確認と連動分割方針本番、検証、子会社、海外拠点分けすぎると相関分析が難しいアクセス制御SOC、情シス、監査部門最小権限と証跡提出権限を分ける保持期間短期分析・中期監査・長期証跡契約・規程と整合させるコスト管理取り込み量、長期保持、検索頻度ログ量の実測が必要自動化Terraform、Bicep、Policy手動変更の検知も必要

3. RBAC、ID管理、管理者ロール

Sentinel運用では、以下を分けます。

  • Sentinel閲覧者

  • インシデント更新者

  • 分析ルール管理者

  • データコネクタ管理者

  • Workspace管理者

  • 証跡提出担当者

  • SOC委託先担当者

  • 緊急用管理者

Azure RBACは、ユーザー、グループ、サービスプリンシパル、マネージドIDへロールを割り当てることでAzureリソースへのアクセスを管理する仕組みです。

実務上は、全員にContributorを付与する運用は避けるべきです。
「見る権限」「調査する権限」「設定を変える権限」「証跡を提出する権限」は分けて設計します。

4. 条件付きアクセスとPIM

ログ監査は、検知だけでなく予防統制とも連動します。

  • 管理者はMFA必須

  • 管理者ポータルは信頼済み端末または特定条件に限定

  • レガシー認証は原則ブロック

  • 緊急用管理者アカウントは例外として棚卸

  • PIMで常時管理者を減らす

  • PIM有効化時の理由・承認・時間を記録する

ここで重要なのは、条件付きアクセスやPIMの設定自体も監査対象にすることです。
「誰がポリシーを変えたか」「誰が管理者権限を有効化したか」をSentinelやEntra ID監査ログで追える状態にします。

5. ネットワーク、Private Endpoint、NSG、Azure Firewall

ログ監査では、ネットワーク設計も重要です。

Private Endpointは、Azure Private Linkを利用するサービスへ仮想ネットワーク内のプライベートIPアドレスで接続するネットワークインターフェイスと説明されています。
Key VaultとPrivate Linkを統合する場合、Private Endpointと仮想ネットワークは同じリージョンである必要があることなどがMicrosoft Learnで説明されています。

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

  • 重要サービスをPrivate Endpoint化するか

  • Public network accessを許可するか

  • NSGで必要最小限に制御しているか

  • Azure Firewallログを収集しているか

  • ルーティング変更の監査ログを取得しているか

  • 名前解決の責任範囲を設計しているか

  • 障害時にどこまで情シスが切り分けるか

6. Key Vaultと暗号化

Key Vaultでは、Azure RBACによりキー、シークレット、証明書の権限管理ができることがMicrosoft Learnで説明されています。

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

  • Key Vault単位のRBAC設計

  • キー、シークレット、証明書の分離

  • アプリケーション単位のKey Vault分離

  • 監査ログ取得

  • キー更新方針

  • 削除保護、論理削除

  • Private Endpoint利用

  • 管理者操作の監査

  • CMK利用時の責任分界

Microsoft SentinelをDefenderポータルへ移行する場合、Microsoft Learnでは、データ保存・処理・保持・共有について、Azure portal利用時とDefender portal利用時で適用ポリシーが異なる旨が説明されています。CMKについても、オンボード後の扱いが説明されています。
そのため、既存の暗号化・データ保持・運用手順は、移行前に確認が必要です。

7. Azure Policy

Azure Policyは、ログ未設定リソースを減らすために有効です。
Microsoft Learnでは、組み込みAzure Policyを使い、サポート対象リソースのリソースログをLog Analytics Workspace、Event Hubs、Storage Accountへ送る方法が説明されています。

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

  • Audit、Deny、DeployIfNotExistsの使い分け

  • 診断設定を強制するリソース種別

  • 例外申請手順

  • 本番・検証環境の差分

  • Policy変更の承認

  • 監査証跡としての準拠状況レポート

8. Defender for Cloud

Defender for Cloudは、クラウドとオンプレミスリソースのセキュリティ態勢を把握し、マルチクラウド・ハイブリッド環境にも対応するCNAPPとして説明されています。
また、推奨事項では、対象リソース、リスク要因、攻撃パス、期限、ステータス等を確認できることが説明されています。

Sentinelと組み合わせる場合は、Defender for Cloudの推奨事項を「見るだけ」にせず、次を運用化します。

  • 重大推奨事項の担当者

  • 対応期限

  • 例外承認

  • 残存リスク

  • 経営報告

  • Azure Policyとの連携

  • Sentinelアラートとの相関

9. バックアップとDR

ログ基盤自体も、事業継続上の重要基盤です。

Microsoft Cloud Security BenchmarkのBackup and recoveryでは、各サービス層でバックアップを実施し、検証し、保護する統制が説明されています。

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

  • 重要システムのバックアップ対象

  • Recovery Services Vaultの設計

  • リストアテスト

  • バックアップログの監査

  • Sentinel/Log Analytics停止時の対応

  • 長期保管ログの復旧手順

  • 証跡保全と削除禁止

10. KQL、IaC、変更管理

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

TerraformやBicepを使う場合は、以下を管理します。

  • Sentinel有効化

  • Workspace設定

  • 診断設定

  • Azure Policy割当

  • RBAC

  • Key Vault

  • Private Endpoint

  • Storage長期保管

  • 変更承認履歴

  • Pull Requestレビュー

  • Stateファイル保護

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

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

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

Sentinel導入・SOC委託・Azure運用支援契約では、少なくとも次を確認します。

条項確認観点技術側で確認することサービス範囲監視、一次対応、月次報告、設定変更の範囲Sentinel、Defender、Azure Monitorの対象範囲責任分界点Microsoft、自社、SOC、再委託先の責任障害時の切り分け範囲SLA稼働率、サポート応答、除外条件自社SLOとの差分障害通知通知条件、通知期限、通知先検知経路、連絡フローインシデント通知不正アクセス、漏えい、改ざん、消失Sentinelインシデントと社内判断の接続データ所在地ログ保存リージョン、サポート拠点Workspaceリージョン、海外SOC再委託再委託先、業務範囲、所在国ログ閲覧・運用権限監査権レポート、質問票、実地監査可否証跡抽出、設定確認ログ提供形式、期限、範囲、真正性KQL、エクスポート、保全データ削除・返還契約終了時、移行時の処理Workspace、Storage、バックアップ個人情報ログ内の個人情報・識別子アクセス制御、保管期間機密情報・営業秘密ファイル名、設計情報、操作履歴閲覧制御、マスキング

Microsoft Azure Legal Informationでは、Azure利用に関する契約、Product Terms、DPA、Service Trust Portal、SLA等への案内が整理されています。
SLAについては、Microsoft Learnが、SLAは単純な可用性保証ではなく、定義、条件、除外を含む契約文書として読むべきものと説明しています。

個人情報保護法上の確認

個人情報保護委員会のガイドラインでは、個人データの安全管理措置、従業者監督、委託先監督、漏えい等報告等が整理されています。特に委託先監督では、委託先の選定、委託契約、委託先における個人データ取扱状況の把握、再委託時の確認が示されています。
安全管理措置については、個人データの漏えい、滅失、毀損防止その他の安全管理のため、リスクに応じた必要かつ適切な措置が求められると説明されています。

クラウドサービス利用に関する個人情報保護委員会Q&Aでは、クラウド事業者が個人データを取り扱うこととなっているかどうかが、第三者提供や委託該当性の判断基準になると説明されています。契約条項でクラウド事業者が保存された個人データを取り扱わない旨が定められ、適切にアクセス制御されている場合等も例示されています。

国外クラウドや海外サポートが関係する場合、PPC Q&Aでは、外国における個人データ取扱いについて、当該外国の個人情報保護制度等を把握したうえで安全管理措置を講じる必要があること、サーバ所在国等を本人の知り得る状態に置く必要がある場合があることが説明されています。

条項例：ログ提供

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

受託者は、本サービスの運用に関連して取得又は管理するログ、監査証跡及びインシデント関連情報について、委託者がセキュリティ調査、内部監査、取引先説明、法令又は社内規程に基づく確認を行うために必要な範囲で、別紙に定める保存期間、形式、提出方法及び提出期限に従い、委託者へ提供できる体制を維持する。

条項例：インシデント通知

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

受託者は、本サービスに関連して、不正アクセス、情報漏えい、改ざん、消失、利用不能その他情報セキュリティ上重大な事象を認識した場合、契約で定める期限内に、判明している事実、影響範囲、初動対応、再発防止策の検討状況を委託者へ通知する。

社内規程に反映すべき事項

  • ログの利用目的

  • ログの保存期間

  • ログの閲覧権限

  • ログの外部提出手順

  • SOC委託先のアクセス範囲

  • 再委託先の管理

  • 海外アクセスの確認方法

  • インシデント時の初報・続報

  • 個人情報漏えい時の社内判断フロー

  • 契約終了時のデータ返還・削除

  • 監査証跡の保全

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

NIST CSF 2.0は、組織がサイバーセキュリティリスクを理解、評価、優先順位付け、伝達するために利用できる高レベルな成果分類を提供し、特定の達成方法を処方するものではないと説明されています。
NIST SP 800-53 Rev.5は、情報システムと組織のためのセキュリティ・プライバシー管理策カタログであり、組織全体のリスク管理プロセスの一部として実装される柔軟でカスタマイズ可能な管理策を提供すると説明されています。
ISO/IEC 27001:2022について、ISO公式ページではISMS要求事項を定める規格として説明されています。
AzureのISO/IEC 27001関連情報では、Azure等が第三者監査を受けていること、Azure Policyの規制コンプライアンス組み込みイニシアチブがISO/IEC 27001のドメインや管理策に対応付けられることが説明されています。ただし、Azure Policyのコンプライアンス表示は全体のコンプライアンス状態の一部にすぎない点も示されています。

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

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

8. 図表

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

判断テーマ主な利用者Azure側の確認項目法務・規程側の確認項目未確認の場合のリスク次のアクションログ保存情シス・監査Workspace保持、Storage保管保存期間、提出形式必要時にログがないログ保存方針表を作成権限管理情シスRBAC、PIM、CA権限管理規程過大権限・内部不正管理者棚卸診断設定情シスAzure Policy、診断設定監査対象リソース定義証跡抜けPolicyでAudit/Deploy障害対応情シス・法務Monitor、Alert、RunbookSLA、通知期限責任分界不明障害時RACI作成インシデントCISO・法務Sentinel Incident、KQL漏えい判断、通知手順初報遅延初動フロー訓練再委託法務SOC権限、海外アクセス再委託承認、監査権委託先監督不足委託先台帳更新データ削除法務・監査Workspace、Storage、Backup返還・削除・証明契約終了後も残存削除手順書化

出典：Microsoft Learn「Azure Monitor診断設定」「Activity Log」「Microsoft Sentinel」、Microsoft Azure Legal Information、個人情報保護委員会ガイドライン。確認日：2026年6月24日。

図表2：情シス・法務部・経営層の役割分担

フェーズ情シス法務部経営層企画対象システム、ログ種別、概算コスト契約・個人情報・再委託の論点整理リスク受容方針設計Sentinel、Workspace、RBAC、Policy契約条項、規程、委託先台帳投資判断実装データコネクタ、診断設定、KQL契約別紙、通知フロー重点監視対象承認テストログ検索、アラート、権限確認証跡提出、通知訓練事業影響確認運用監視、チューニング、月次報告契約・規程との整合確認KPI確認、残存リスク判断監査設定証跡、ログ抽出監査回答、委託先確認取締役会・顧客説明

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

[導入前]
対象業務・個人情報・機密情報を整理
        ↓
[設計]
ログ種別・保存期間・Workspace・RBAC・契約条項を決定
        ↓
[実装]
診断設定、データコネクタ、Azure Policy、KQL、アラートを構成
        ↓
[テスト]
ログ検索、証跡出力、権限分離、通知訓練、コスト確認
        ↓
[運用]
SOC監視、月次レビュー、Defender推奨事項、Policy準拠確認
        ↓
[インシデント]
検知、初動、証跡保全、通知、原因分析、再発防止
        ↓
[監査・改善]
契約・規程・技術設定・残存リスクを更新

図表4：契約条項とAzure設定の対応表

契約条項Azure設定・証跡監査時の説明材料ログ保存Log Analytics保持、Storage保管保持設定、抽出結果ログ提供KQL、Export、Workbook提出形式、提出履歴障害通知Azure Monitor Alert通知履歴、対応記録インシデント通知Sentinel Incident初報、続報、クローズ理由再委託SOC用RBAC、PIM権限台帳、アクセスレビューデータ所在地Workspaceリージョンリージョン設計書削除・返還Workspace削除、Storage削除、Backup削除手順、証明取得可否監査権Policy準拠、Defender推奨事項月次レポート、例外台帳

図表5：Azure機能とセキュリティ基準の対応表

Azure機能主な役割対応する基準・観点Microsoft SentinelSIEM、検知、調査、対応NIST Detect/Respond、MCSB Logging/IRAzure Monitor監視、メトリック、ログNIST AU、ISMS運用監視Log Analyticsログ検索、保持NIST AU、CISログ管理Azure Policy統制、監査、自動修復ISMS、MCSB、内部統制Defender for Cloudセキュリティ態勢管理MCSB、CIS、NIST Identify/ProtectEntra IDID管理NIST AC、ゼロトラスト条件付きアクセスアクセス制御NIST AC、MCSB IdentityPIM特権管理NIST AC、ISMS権限管理Key Vault秘密情報・鍵管理NIST SC、Data ProtectionPrivate Endpoint非公開接続NIST SC、ネットワーク制御Purview情報ガバナンスGDPR、個人情報保護、ISMS

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

確認項目Azure側の確認場所法務・規程側の確認先未確認の場合のリスク優先度条件付きアクセスの例外アカウントは棚卸されているかEntra IDアクセス管理規程例外経由の侵害高管理者ロールは最小権限かAzure RBAC / Entra ID権限管理台帳過大権限高PIM利用要否を検討したかEntra ID PIM特権ID規程常時管理者の放置高緊急用管理者アカウントの扱いを決めたかEntra ID例外管理台帳ロックアウト・不正利用高Sentinelに送るログ種別は決まっているかSentinel Data connectorsログ管理規程証跡不足高Workspace保持期間は決まっているかLog Analytics保存期間規程監査不備高Activity Logの長期保存を設計したかDiagnostic settings監査要件90日後の消失高Azure Policyで診断設定漏れを検知するかAzure Policy統制規程ログ未取得高Defender推奨事項の担当者は決まっているかDefender for Cloud是正管理改善放置中Private Endpoint、NSG、Firewall責任範囲は明確かNetwork責任分界表障害時混乱高Key Vaultのアクセス制御は明確かKey Vault秘密情報管理規程鍵・秘密情報漏えい高バックアップとリストア検証を行ったかAzure BackupBCP規程復旧不能高障害時の一次切り分け責任は契約上明確かMonitor / SupportSLA・運用契約対応遅延高データ削除証明の取得可否を確認したかWorkspace / Storage契約終了条項データ残存中IaCの変更履歴と承認履歴が残るかTerraform / Bicep / Git変更管理規程無断変更中

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

契約・規程上の確認項目情シスに確認すべき技術事項確認資料未確認の場合のリスク対応方針契約主体Azure契約形態、販売経路契約書、Product Terms責任先不明契約体系を整理再委託先SOC、海外サポート委託先一覧委託先監督不足台帳化サポート拠点海外アクセス有無サポート仕様国外移転確認漏れ所在国確認データ所在地Workspaceリージョン設計書データ所在地不明リージョン明記個人情報の定義ログ内識別子個人情報台帳規程不整合ログ分類機密情報の定義ファイル名、操作履歴秘密情報規程営業秘密管理不備定義見直し障害通知条件Monitor通知SLA通知遅延通知期限明記漏えい通知期限Sentinel検知フローインシデント規程報告遅延初報手順ログ提供範囲KQL抽出範囲契約別紙提出不可形式を明記監査権Policy準拠、設定証跡監査条項実効性不足レポート取得可否確認監査レポートISO、SOC等STP等第三者評価不足取得手順確認データ返還Export可否契約終了条項移行困難返還形式明記データ削除削除対象、Backup削除条項データ残存削除証明確認SLA違反時救済対象サービスSLA救済範囲誤解除外条件確認損害賠償責任制限契約書リスク過大弁護士確認委託先管理台帳権限・ログ範囲台帳監査不備定期更新

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

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

経営層は、「Sentinelを入れたか」ではなく、次を確認すべきです。

  1. 重大インシデント時に、いつ、誰が、どの証跡を出せるか

  2. ログ保存と監査対応にどこまで投資するか

  3. 技術・契約・規程・監査で下げられない残存リスクを受容するか

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

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

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

13. まとめ

Microsoft Sentinelは、単なるログ収集基盤ではありません。
適切に設計すれば、認証、権限、ネットワーク、データ保護、委託先管理、個人情報保護、監査証跡をつなぐ中核になります。

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

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

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

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

クラウド監査の実務では、「ログがある」だけでは足りません。
必要な時に、必要な権限者が、必要な形式で、契約・規程に沿って提出できることが重要です。

山崎行政書士事務所では、この技術と法務の接続部分を、実務文書とAzure設計の両面から整理します。

14. 確認済み事項

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

  2. Sentinelはデータコネクタによりデータを取り込み、MicrosoftサービスだけでなくSyslog、CEF、REST API等による外部データ連携も説明されている。

  3. Azure Activity Logは90日保持後に削除され、長期保持には診断設定による別保存が必要である。

  4. Azure Monitorの診断設定は、ポータル、PowerShell、CLI、ARM、Bicep、REST API等で作成できる。

  5. Microsoft SentinelはAzure RBAC等による権限管理が説明されている。

  6. 条件付きアクセスはMicrosoftのゼロトラストポリシーエンジンとして説明されている。

  7. PIMは重要リソースへのアクセスを管理・制御・監視するMicrosoft Entra IDのサービスである。

  8. Microsoft Cloud Security Benchmarkは、ログ、脅威検知、インシデント対応、Azure Policy等と関係するクラウドセキュリティ指針である。

  9. 個人情報保護委員会ガイドラインでは、安全管理措置、委託先監督、再委託時の確認等が説明されている。

  10. GDPRはEUR-Lexで公式テキストを確認できる。

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

  • Microsoft Sentinelは、複数のデータソースからログを取り込み、脅威検知・調査・対応に利用するSIEM基盤である。

  • Azure Activity Logの標準保持は90日であり、長期保存が必要な場合は診断設定等で別保存を設計する必要がある。

  • Azure Policyを使うことで、診断設定の展開や準拠確認を大規模に行う設計が可能である。

  • Microsoft Cloud Security Benchmarkは、ログ収集、SIEM、インシデント対応、Azure Policy等をクラウドセキュリティ統制として整理する際の参照情報になる。

  • 個人情報保護法上、クラウド事業者が個人データを取り扱うかどうか、委託・第三者提供・国外移転の確認が重要になる。

  • GDPRが関係する場合は、管理者・処理者、処理契約、技術的・組織的措置、個人データ侵害通知、域外移転の確認が必要になる。

16. 実務上の考察

  1. Sentinel導入は、技術設定だけでなく、契約・規程・監査証跡と同時に設計した方が実務上の失敗を減らせます。

  2. ログ保存期間は、情シスの都合だけで決めるのではなく、監査、契約、個人情報保護、取引先説明、BCPと整合させるべきです。

  3. SOC委託をする場合、検知・一次対応の責任範囲だけでなく、ログ閲覧権限、再委託、海外拠点、証跡提出範囲を整理すべきです。

  4. Azure PolicyとDefender for Cloudは、単なる技術推奨ではなく、内部統制・ISMS・監査説明に使える情報源として扱うと有効です。

  5. 経営層への説明では、製品名ではなく、残存リスク、費用対効果、監査説明可能性、事業継続を軸に整理すべきです。

17. 推測・仮説

本稿では、確認できない製品仕様や法的効果を断定していません。
以下は一般的な実務上の仮説です。

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

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

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

18. 確認できない事項

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

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

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

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

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

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

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

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

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

19. 主な参照情報

確認日：2026年6月24日

Microsoft関連

NIST関連

個人情報保護法関連

GDPR・EU関連

ISMS・CIS関連

Microsoft Sentinelは「入れたら終わり」ではありません。

本当に重要なのは、ログ保存期間、責任分界点、再委託、監査権、障害・インシデント通知を、Azure設計と契約・規程で同時に決めることです。

情シス・法務・経営層が同じ表で確認すべき実務論点を整理しました。

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