【クラウド責任分界】Azureセキュリティは誰の責任か？利用者・委託先・Microsoftの境界を“事故対応まで”整理（キーワード例：Azure セキュリティ／責任分界／運用委託／SLA／監査ログ）

はじめに

Azureのセキュリティは、製品や機能を増やすほど“強くなる”一方で、現場の情シスが一番困るのは「事故が起きたときに、誰が何をするのか説明できない」状態です。ベンダーからは「Microsoftのクラウドだから安全です」と言われ、社内からは「じゃあ障害や侵害はMicrosoftが責任を持つの？」と聞かれる。運用を委託していると「それは委託先？それとも自社？」という話も加わります。

結論、Azureセキュリティは“責任共有（Shared Responsibility）”で成り立ちます。技術の設計図はあっても、責任の設計図がないと、監査・取引先・親会社への説明で詰まります。

本記事では、利用者（自社）・委託先（MSP/SOC等）・Microsoftの境界を、実務で説明できる形に整理します。

────────────────────────────

1. まず技術としての「責任共有モデル」を1枚で理解する────────────────────────────

クラウドのセキュリティは、一般に Microsoft（クラウド提供者）と顧客（利用者）の“共有責任”であり、IaaS/PaaS/SaaSのどれを使うかで分担が変わります。

1-1. “AzureならMicrosoftが守ってくれる”の範囲Microsoft側の責任（ざっくり）・物理データセンター・ハードウェア・クラウド基盤ネットワーク・ホスト側の基盤（物理/仮想化基盤、基盤の安全な運用）・施設の物理セキュリティ（入退館、警備、設備など）

ここは利用者が直接コントロールできない領域で、Microsoftが担う部分です。

1-2. “どの形態でも利用者が必ず背負う”責任一方で、クラウド形態に関わらず、利用者が常に背負う責任があります。特に説明が必要なのは次です。

・データ（どの情報を置くか、分類、暗号化、持ち出し、削除、保全）・アカウント（ユーザー管理、管理者、退職者、委託先の棚卸し）・アクセス管理（RBAC、MFA、条件付きアクセス、特権管理）・エンドポイント（端末、管理端末の統制、準拠状態）・アプリケーション（設定、脆弱性、秘密情報の管理）・構成（公開設定、ネットワーク設計、監視、バックアップ、DR）

つまり、「Microsoftが基盤を守る」＝「自社は何もしなくていい」ではありません。

1-3. 委託先（MSP/SOC）はどこに入る？委託先は、Microsoftの責任を肩代わりする存在ではなく、基本的には “利用者が負う領域の作業を、契約で代行する存在”です。

・利用者（自社）が責任を持つべき領域　例：ID設定（Entra ID/条件付きアクセス）、RBAC、監視/ログ、バックアップ方針、インシデント一次対応…・その作業を委託先がやる場合　→ “委託先がやる”こと自体を、契約・手順・証跡で固めないと、事故時に説明が割れます。

（ここまでは技術の話。ここからが法務・契約の話です。）

────────────────────────────

2. 「技術はOK／契約はNG」で事故後に揉める落とし穴3選────────────────────────────

落とし穴①：SLAはあるのに、復旧・連絡・説明の責任が空白Azureには各サービスのSLAがありますが、実務で揉めるのは「数字」よりも・誰が一次通知するのか・誰が復旧判断するのか・取引先・親会社に誰がどんな報告を出すのかです。

また誤解されがちなのが、SLAは“条件付き”で、顧客側の設計・構成（冗長化、ゾーン/リージョン、バックアップ等）に依存することです。「SLAがある＝自動で守られる」ではなく、設計・構成・運用の責任が利用者側に残るのに、そこが契約・社内説明に落ちていないケースが多いです。

落とし穴②：“ログは見られる”のに“監査で出せない”Azureは監視・ログの仕組みが豊富です。しかし事故や監査で問われるのは、次の3点です。

・どのログを（何が取れているか）・どの期間（どれだけ残るか）・どの形式で、いつまでに提出できるか（提出能力）

これが「運用委託」「SIEM委託」になると、ログの所在が複雑化します。結果、監査・取引先照会で「提出が遅い／揃わない／説明できない」になりがちです。

落とし穴③：委託先に任せた瞬間、責任分界が“空気”になる委託を入れると、ありがちな破綻パターンはこの3つです。

・委託先の作業範囲が「監視だけ」なのに、社内は「対応もやってくれる」と誤解・特権アクセス（管理者権限）の統制が弱く、担当者交代や契約終了で剥奪漏れ・インシデント時の「誰が保全し、誰が報告書を作るか」が決まっていない

委託を入れたから安全になるのではなく、委託を入れた分だけ“契約で決めないと説明不能”が増えるのが実務です。

────────────────────────────

3. 事故・監査で「説明できる」状態を作る整理フレーム────────────────────────────

結論、Azureセキュリティの境界は、技術より先に次の3つで固めると、説明が崩れません。

3-1. 整理軸①：責任分界表（Microsoft／利用者／委託先）を“タスク単位”で作るおすすめは「レイヤー」ではなく「やること」で切ることです。

例：最低限入れるタスク・ID・アクセス：MFA/条件付きアクセス/RBAC/PIM・ネットワーク：NSG/Firewall/WAF/Private Endpoint方針・脆弱性・パッチ：VMのゲストOS、ミドルウェア、アプリ・監視・ログ：収集範囲、保持期間、提出手順・バックアップ・DR：どのサービスに、どのRPO/RTOを求めるか・インシデント対応：一次対応、エスカレーション、証拠保全、社外報告

各タスクに対して「R（実行）」「A（最終責任）」「C（相談）」「I（共有）」を1枚で固定します（RACI）。

3-2. 整理軸②：証跡パック（監査で“これを出す”）を先に定義する“証跡パック”の最低ライン例・管理者（特権）一覧：常設／期限付き、付与理由、承認者・重要操作ログ：権限変更、ポリシー変更、キー操作、ネットワーク変更・重要リソースの構成証跡：公開設定、暗号化設定、バックアップ設定・インシデント時の保全手順：削除停止、隔離、抽出者記録

Azureは基盤側のセキュリティが強くても、顧客側には「データとID・アクセス管理の責任」が残るため、証跡パックの整備が実務上の生命線になります。

3-3. 整理軸③：委託契約に「事故対応の義務」を落とす委託契約（MSP/SOC）で、少なくとも次を“条項 or 別紙SOW”で固めると事故後に揉めません。

・一次通知の期限（例：検知から何分以内、どのチャネル）・ログ提出義務（提出期限・形式・保持・保全協力）・特権アクセスの統制（個人アカウント、期限付き、操作ログ、申請・承認）・再委託（国外含む）の可否・条件、監督責任・契約終了時：アクセス剥奪、データ削除・削除証明、ログ引渡し

────────────────────────────

4. ケーススタディ（匿名化）：運用委託が入った製造業A社の場合────────────────────────────

業種：製造業拠点：日本＋海外構成：Azure（IaaS＋PaaS混在）、IDはEntra ID、監視は委託先SOCで運用

起きていたこと・技術的な設計は整っていたが、「監査で出すログ」「提出期限」「誰が報告書を作るか」が曖昧・委託先は“監視はするが、証跡提出・保全は別メニュー”で、いざという時に動けない・社内では「MicrosoftのクラウドだからMicrosoftが責任」と誤解が残っていた

整理したこと（実務）・Microsoft／自社／委託先の責任分界（RACI）を事故タイプ別に固定・証跡パック（何を・どれだけ・どの形式）を決め、委託先の提出義務に落とし込む・特権アクセスのルール（期限・承認・記録）を規程＋運用で整備

結果・監査・親会社・取引先からの質問に、技術ではなく“責任と証跡”で一貫回答できる状態になった・「委託しているのに説明できない」状態から脱却できた

────────────────────────────

5. 今すぐ確認できるチェックリスト────────────────────────────

□ Azureの責任共有モデルを前提に「Microsoft／自社／委託先」の責任分界表（RACI）がある□ 自社が常に保持する責任（データ・エンドポイント・アカウント・アクセス管理）を社内資料で明文化している□ “証跡パック”（監査で出すログ・設定証跡）の定義がある□ ログの保持期間・提出期限・形式が決まっている（委託先があるなら契約化）□ 特権アクセス（委託先含む）が期限付き・記録付きで統制されている□ SLAの「条件」を満たす設計になっている（ゾーン/冗長化/バックアップ等）□ インシデント時の一次通知・保全・報告書作成の責任者が決まっている□ 再委託（国外含む）がある場合、範囲特定と監督責任が説明できる

────────────────────────────

6. 全国からのご相談について

────────────────────────────

山崎行政書士事務所では、Azureの技術構成（IaaS/PaaS混在、ID、ログ、委託運用）を前提に、「誰がどこまで責任を負うか」を契約・規程・監査対応まで含めて整理するクラウド法務支援を行っています。

・Microsoft／委託先／自社の責任分界を1枚にしたい・監査・取引先照会に耐える“証跡パック”を作りたい・運用委託契約に、ログ提出・保全・特権アクセスの条項を入れたい・SLAを社内・取引先へ説明できる形にしたい

といったお悩みがあれば、オンライン（全国対応）で初回相談を承っています。（お問い合わせ時に「Azureセキュリティ責任分界の記事を見た」と書いていただくとスムーズです。）

────────────────────────────

※本記事は一般的な情報提供であり、個別の契約条件・サービス構成により責任分界は変わります。導入形態（IaaS/PaaS/SaaS）と委託範囲を前提に個別整理が必要です。────────────────────────────