【クラウド法務】クラウド責任分界（Entra ID）でトラブルになりやすい3つのポイント— Entra ID導入・運用で「誰がどこまで責任を持つか」を契約と運用で揃える —
- 山崎行政書士事務所
- 2025年12月12日
- 読了時間: 8分
導入：SSOは動いている。でも「事故ったとき誰の責任か」が説明できない
Entra ID（旧 Azure AD）は、M365 だけでなく各種SaaSや社内アプリのSSO基盤として定番になりました。条件付きアクセス、MFA、PIM、ID同期… 技術的な情報は豊富で、「構築して動かす」だけなら何とか形になります。
しかし、全国の情シス・IT部門の方から相談を受けていると、次のような声を非常によく耳にします。
「Entra ID は何とか運用できているが、クラウド責任分界（誰が何を担保するか）が整理できていない」
「ベンダー任せで進めてしまい、Global Admin が外部に残ったまま、責任範囲も曖昧」
「監査・親会社・取引先から“ID基盤としてこの構成で大丈夫？”と聞かれても、契約と運用の根拠が出せない」
Entra ID は“入口”です。入口で事故ると、M365、SaaS、Azure、ひいては全社業務に波及します。だからこそ 技術構成の整理 と同じくらい、契約・責任分界・運用ルールの整理 が重要になります。
本記事では、「クラウド責任分界 × Entra ID（旧 Azure AD） × クラウド法務」 という視点から、よくある落とし穴と、実務で使える整理方法をご紹介します。
1. Entra ID 導入時に、現場で実際に組まれている構成イメージ（技術の“事実整理”）
まずは「技術構成の事実」を、ざっくり言語化します。多くの企業で典型的なのは次の形です。
1-1. よくある全体像（テキスト簡易アーキテクチャ）
IDの源泉（Source of Truth）
オンプレAD（AD DS）を継続利用（人事DB→ADでアカウント発行）
同期方式
Entra Connect / Cloud Sync でオンプレ→クラウド同期
認証・アクセス制御
Entra ID を認証基盤にし、M365＋主要SaaSへSSO
条件付きアクセス（CA）で MFA / 準拠デバイス / 国・拠点制御
特権管理
PIM（Privileged Identity Management）で管理者ロールをJIT化
Break-glass（緊急用）アカウントを少数保持
外部ユーザー
B2B（ゲスト）で取引先・委託先を招待
グループ会社はテナント分離 or 同一テナントに集約
ログ・監査
Sign-in logs / Audit logs を監視基盤（Sentinel / SIEM）へ転送
ただし保持期間は「既定 or ライセンス任せ」で長期化が未整理なことも多い
ここまでは“技術構成”として整理されている一方で、現場では高確率でこうなります。
ここまでは技術の話。ここからが法務。「契約上、どこからどこまで誰の責任か」 の図が存在しない。
Microsoft（クラウド事業者）
構築ベンダー（SI）
運用ベンダー（MSP）
自社情シス（運用責任者）
人事・総務（ID発行プロセス）
事業部門（SaaSのオーナー）
グループ会社・海外拠点（利用者・管理者）
この“登場人物”が多いのに、責任分界が曖昧なまま運用に入る——ここが事故の起点です。
2. 全国の案件で見えてきた「クラウド責任分界（Entra ID）の落とし穴」3選
代表的なものを3つに絞ると、次のパターンが多いです。
① 「認証基盤の責任分界」がMicrosoft/SI/MSP/自社で混線している
技術的にはOK
SSOできる、MFAも入っている、条件付きアクセスも動いている
法務・実務的にはNGになりうる点
事故（アカウント侵害、設定ミス、管理者誤操作）が起きたとき、
誰が一次対応するのか
誰がMicrosoftへエスカレーションするのか
誰がログを保全して説明するのか
誰が復旧判断（CA緩和/ロールバック）をするのかが契約・運用設計書・BCPのどこにも明記されていない
結果として「今ベンダーに聞いてます」「Microsoft待ちです」で時間が溶け、被害が拡大しやすい
② “便利な運用”のために、ベンダーの強権限が残ったままになっている
技術的にはOK
ベンダーが迅速に設定変更できる体制で、運用も楽
法務・監査的にはNGになりうる点
Global Admin / Privileged Role Admin が外部ベンダーに常設付与されている
退職・契約終了後のアクセス剥奪が運用依存
監査で「外部がいつでも全権アクセスできる状態」を問題視される
いざインシデントが起きると「その操作は誰がやった？証跡は？」が説明不能になりがち
③ ログ・証跡の保持と“説明責任”が、契約・規程とズレている
技術的にはOK
サインインログも監査ログも見られる。必要なら調べられる。
法務・対外説明的にはNGになりうる点
実際は保持期間が短い／転送されていない／必要なログ粒度が取れていない
監査・親会社・取引先から「いつ・誰が・どこから入ったか」の説明を求められたとき、
ログが残っていない
改ざん防止や保全手順がない
“誰が保全責任者か”が決まっていない
その結果、技術的な復旧はできても「説明責任」を果たせず信用事故になる
3. クラウド責任分界（Entra ID）で、まず押さえるべき3つの整理軸
技術構成を大きく変える前に、最低限次の3つを紙に落とすだけで、ベンダー調整と社内説明が一気に楽になります。
① 誰がどのレイヤーを担保するか（責任分界表）
Entra ID は「サービス」「設定」「運用」「ID発行プロセス」が絡みます。おすすめは、責任分界をレイヤーと**シーン（平常時/緊急時）**で分けることです。
クラウド事業者（Microsoft）
Entra ID サービスとしての提供、基盤の稼働、公式SLA範囲
構築ベンダー（SI）
初期設計（CA、PIM、同期方式、ロール設計、命名規則）
移行・実装の成果物（設計書、手順書、復旧手順）
運用ベンダー（MSP）
監視、アラート一次対応、定常変更、チケット運用
ただし「最終判断」は誰かを明確化
自社（情シス/セキュリティ）
設定の最終責任、例外承認、権限付与の承認フロー
重大インシデント時の意思決定と対外説明
人事・総務
入退社・異動の起点情報、権限設計の業務要件
事業部門（SaaSオーナー）
SaaS側の権限/グループ設計、利用ルール
ポイントは「運用を委託しても責任は委託できない領域がある」ことを、表にして合意することです。
② 管理者権限と外部アクセスを、契約と手順で“縛る”
Entra ID の事故は「強権限」が絡みます。最低限整理したいのは以下です。
どのロールを誰に付与するか（常設/一時付与）
PIMでJIT化する範囲（Global Adminの常設は極力避ける）
Break-glassの管理責任者・保管方法・利用手順
外部ベンダーのアクセス方法（専用アカウント、MFA、端末条件、操作ログ）
契約終了時の剥奪・証跡提出・アカウント棚卸し
「ベンダーが作業できること」と「ベンダーが責任を負うこと」を混ぜないのがコツです。
③ ログ・証跡の“保持・保全・提出”までを運用に落とす
Entra ID で本当に困るのは、事故後に「説明できない」ことです。以下を決めます。
どのログを対象にするか（Sign-in / Audit / 変更履歴 / 特権ロールのアクティベーション等）
保持期間（規程・監査要件・取引先要件と整合）
保全手順（改ざん防止、アクセス権限、エクスポート手順）
インシデント時の提出責任（誰が、どの形式で、どの期限で）
これを決めておくと、監査・親会社・取引先への回答の質が変わります。
4. ケーススタディ：製造業A社（売上1,000億、拠点10カ国）の場合
実際に当事務所でご相談を受けた事例の一つをご紹介します（業種等は匿名化しています）。
業種：製造業
売上規模：約1,000億円
拠点：日本＋欧州＋アジア（10カ国）
テーマ：Entra ID 統合（M365＋主要SaaS）と責任分界の再設計
課題の整理
ベンダーから「技術構成図（同期・SSO・CA）」は出てくるが、責任分界図がない
海外拠点・グループ会社も同一テナントで利用し始め、「誰がどこまで管理者権限を持つか」が曖昧
監査部門から「外部ベンダーの強権限」「ログ保持」「緊急時対応」の整理を求められたが、情シス側だけでは社内合意が進まない
当事務所の支援内容（抜粋）
技術構成と契約書のクロスチェック
Entra ID の運用設計（CA/PIM/同期/ゲスト）と、運用委託契約・SLA条項を突合
責任分界マトリクスの作成
平常時（変更/監視/棚卸し）と緊急時（侵害/停止/復旧）を分け、Microsoft/ベンダー/自社/拠点の役割を1枚に整理
権限設計の“契約化”
ベンダー権限の範囲、PIM運用、緊急時の特権利用手順を文書化
ログ・証跡要件の整理
監査要件・親会社要件に合わせ、保持・保全・提出の運用案をレビュー
結果として
監査・親会社・海外拠点からの質問に、「技術構成＋責任分界＋運用証跡」のセットで一貫して回答できるようになった
“ベンダー任せ/属人運用”から脱却し、ID基盤としての統制（説明責任を果たせる体制）に近づけた…といった声をいただいています。
5. Entra ID 運用企業が、今すぐ確認しておきたいチェックポイント
記事をブクマしてもらう用のチェックリストです。全部YESと言える企業は、正直まだ少ないです。
□ Microsoft・構築ベンダー・運用ベンダー・自社の責任分界図が1枚で説明できる
□ Global Admin 等の強権限が、常設・外部残りになっていない（PIM等で統制）
□ Break-glass の管理（保管・利用条件・利用後の証跡）が文書化されている
□ 条件付きアクセスの例外（海外出張・委託先・緊急対応）の承認フローがある
□ Sign-in/Audit等のログが、保持期間・保全手順・提出責任まで含めて整っている
□ 侵害・不正アクセス時に「誰が・どこまで・いつまでに」を文章化した初動手順がある
□ 退職・契約終了時のアカウント棚卸し、外部アクセス剥奪が運用で回っている
□ 「ベンダーがやっているから大丈夫」ではなく、自社としてのID方針を説明できる
「すべて自信を持ってYESと言える企業は、全国的に見てもまだ多くありません。」
6. 全国からのご相談について
山崎行政書士事務所では、**Microsoft Entra ID（旧 Azure AD）/ M365 等の技術構成と、契約・規程・監査対応をセットで整理する「クラウド法務支援」**を行っています。
ベンダーとの責任分界を、Entra ID（ID基盤）前提で整理したい
監査・親会社・取引先からの質問に、一貫したストーリーで答えられるようにしたい
強権限・外部アクセス・ログ保全など、運用を契約と規程で固めたい
といったお悩みがあれば、**オンライン（全国対応）**にて初回のご相談を承っております。
👉 ご相談フォームはこちら
👉 お問い合わせの際に、**「クラウド責任分界 Entra ID の記事を見た」**と書いていただけるとスムーズです。
コメント