【情シス向け】Azure機能一覧を眺める前に確認したい「責任分界」の考え方― “どのサービスを使うか”より先に、“誰が守るか”を決めないと説明できなくなる ―

※本記事は一般的な情報提供です。個別案件の法的助言ではありません。

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

はじめに

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

Azureの機能一覧（サービス一覧）を開くと、あまりの数に圧倒されます。Compute、Storage、Networking、Security、AI…どれも便利そうで、「とりあえず導入」「必要になったら追加」と進めたくなる。しかし、情シスが本当に詰まるのは“機能選定”ではなく、その後の社内説明です。

・「この構成で、セキュリティは誰が責任を持つの？」・「障害や侵害が起きたら、Microsoft？委託先？それとも自社？」・「監査で“証跡”を提出できる？保持期間は？」・「取引先からSLAやBCPを聞かれたとき、説明できる？」

結論、Azureは“責任共有”で成り立ちます。だからこそ、Azure機能一覧を見る前に、まず「責任分界の考え方」を整理しておくと、導入後の説明が崩れません。

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

1. まず押さえる前提：「Azureは安全」ではなく「責任共有」────────────────────────────

Azureのセキュリティ責任は、ざっくり次の3者に分かれます。

（1）Microsoft：クラウド基盤の提供者（物理・基盤の安全）（2）利用者（自社）：データと設定の責任者（設計・統制・運用）（3）委託先（MSP/SOC/運用ベンダー）：自社の作業を代行する者（契約で範囲が決まる）

ここで重要なのは2つです。

・委託しても「最終責任（説明責任）」は自社から消えない・“どこまでMicrosoftが守るか”は、IaaS/PaaS/SaaSで変わる

つまり、責任分界が整理されていない状態で機能を見ても、「便利なサービスを積み上げた結果、誰も説明できない構成」になりやすいのです。

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

2. 責任分界は「レイヤー」より「タスク」で考えると崩れない────────────────────────────

責任分界を「ネットワーク層」「OS層」「アプリ層」みたいな“技術レイヤー”で語り始めると、会議が長引きます。情シスが社内で説明を通すには、レイヤーではなく「やること（タスク）」で切る方が強いです。

最低限、次のタスクを並べて「誰がやるか」を決めるだけで、説明の骨格ができます。

・IDとアクセス（MFA、条件付きアクセス、RBAC、特権管理）・ネットワーク（公開/閉域、出口、WAF/Firewall、Private化方針）・脆弱性対応（ゲストOS、ミドルウェア、アプリ、コンテナ）・秘密情報（Key Vault、証明書、鍵、ローテーション）・監視とログ（何を集める、どこに置く、どれだけ残す、提出できるか）・バックアップ/DR（RPO/RTO、復旧訓練、責任分界）・インシデント対応（一次通知、保全、調査、報告書、再発防止）

この「タスク別の責任分界」が1枚にまとまると、Azureサービスを眺めたときに迷いが減ります。“このサービスを使うと、どのタスクが自社責任として残るか”が見えるからです。

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

3. Azure機能一覧の前に潰したい「法務・契約の地雷」3つ────────────────────────────

ここからが“技術はOK、説明はNG”になりやすいポイントです。

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

地雷①：「SLAがある＝全部守られる」と誤解する────────────────────────────

SLAは「稼働率の数字」だけが一人歩きしがちですが、事故時に揉めるのは次です。

・重大障害の一次通知は誰が、どのチャネルで、何分/何時間以内か・復旧の判断（切り戻し、例外解除、回避策適用）は誰が決めるか・取引先・親会社への説明文書は誰が作るか・“条件を満たした構成になっているか”の責任は誰か

SLAの数字が高くても、上の運用責任と説明責任が決まっていないと、社内説明は通りません。

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

地雷②：「ログは見られる＝監査で出せる」と思い込む────────────────────────────

Azureはログの仕組みが豊富です。しかし監査・取引先照会・事故調査で問われるのは「見られるか」ではなく、次の3点です。

・何のログがあるか（管理操作、権限変更、ネットワーク変更、認証ログ等）・どれだけ保持するか（90日なのか、1年なのか、7年なのか）・いつまでに、どんな形式で提出できるか（提出期限と形式）

さらに運用委託が絡むと、ログの所在が分散し「出ない」「遅い」が起きます。だからログは“取得機能”より先に、“保持・提出・保全”の責任分界を決める必要があります。

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

地雷③：「委託した＝責任が移った」と社内が誤解する────────────────────────────

委託先はMicrosoftの責任を肩代わりする存在ではなく、自社が背負う領域の作業を、契約で代行する存在です。

委託が入った瞬間に、次が曖昧になると説明不能になります。

・委託範囲は監視だけか？一次対応までか？復旧作業までか？・委託先の特権アクセスはどう統制するか（期限、承認、操作ログ）・再委託（国外SOCなど）がある場合、誰が監督し、どこまで説明できるか・ログ提出義務（提出期限・形式・保全協力）は契約で担保されているか

委託は便利ですが、契約と証跡を固めないと“責任の空白”が増えます。

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

4. これだけ作れば説明できる：責任分界の「最小3点セット」────────────────────────────

Azure機能一覧を見る前に、最低限これだけ揃えると、導入後の説明が崩れません。

（1）責任分界表（タスク別RACI）・R（実行）誰が手を動かす・A（最終責任）誰が最終判断し責任を負う・C（相談）誰に相談する・I（共有）誰に共有する※「委託先がRでも、自社がAのタスク」は必ず残ります

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

（3）委託契約に入れるべき「事故対応の義務」・一次通知の期限（検知後何分以内等）・ログ提出義務（提出期限・形式・保持・保全協力）・特権アクセス統制（個人アカウント、期限付き、承認、操作ログ）・再委託（国外含む）の条件と監督責任・契約終了時の出口（アクセス剥奪、データ削除、削除証明、ログ引渡し）

この3点があると、Azureのサービスを追加しても「説明の骨格」が崩れません。

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

5. 典型サービスで見る「責任分界」のイメージ（超ざっくり例）────────────────────────────

ここからは、Azure機能一覧を見たときに迷わないための“読み方”です。同じAzureでも、サービスによって「自社が背負う範囲」が違います。

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

例1）Azure Virtual Machines（VM）────────────────────────────Microsoft側：物理基盤、データセンター、クラウド基盤の運用利用者側：ゲストOSのパッチ、ミドルウェア、アプリ、EDR、バックアップ設計、アクセス制御、鍵管理委託先：上の利用者側タスクのうち、契約で定めた範囲を代行

ポイント：VMは“自由度が高い＝自社責任も増える”。「脆弱性対応」「バックアップ」「証跡」が説明の中心になります。

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

例2）App Service（PaaS）────────────────────────────Microsoft側：基盤ランタイムの運用（OS基盤含む範囲が広がる）利用者側：アプリコード、認証連携、アクセス制御、設定ミス防止、ログ設計、秘密情報管理委託先：デプロイ・監視・一次対応などを代行することが多い

ポイント：PaaSは“OS運用が軽い”が、「設定」「認証」「秘密情報」「ログ保持」が事故原因になりやすい。

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

例3）Azure SQL Database（DB PaaS）────────────────────────────Microsoft側：DB基盤の冗長化や保守の多く利用者側：データの分類、ユーザー権限、監査ログ、暗号化キー方針、バックアップ保持と復旧手順委託先：DB運用を委託するなら権限・操作ログの統制が重要

ポイント：DBは「復旧できる設計」と「操作証跡」が説明の要になります。

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

例4）Storage Account────────────────────────────Microsoft側：基盤の耐久性・可用性利用者側：アクセスキー/SAS/権限、公開設定、暗号化キー、削除保護、ライフサイクル、データ保全委託先：監視・設定代行をするなら“誰が鍵を扱うか”が重要

ポイント：「公開設定ミス」「鍵の扱い」「削除・保全」が地雷になりやすい。

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

例5）Key Vault────────────────────────────Microsoft側：サービス基盤の運用利用者側：Secrets/Keys/Certificatesの棚卸し、所有者、期限切れ管理、ローテーション、アクセス制御、例外運用委託先：作業するなら特権アクセス統制と操作ログ提出が必須

ポイント：Key Vaultは“入れるだけ”で安全にならない。棚卸し・期限切れ・過剰権限が事故の中心です。

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

例6）監視・SIEM（Azure Monitor / Sentinel等）────────────────────────────Microsoft側：基盤利用者側：何を集めるか、保持期間、アラート運用、インシデント対応、提出能力委託先：SOC運用を委託するならログの所有・提出期限・再委託統制が重要

ポイント：「ログはあるが出せない」を避けるために、保持・提出・保全が先です。

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

6. チェックリスト：Azure機能一覧の前に“これだけ”確認────────────────────────────

□ 自社・委託先・Microsoftの責任分界を、タスク別に1枚で説明できる

□ 事故タイプ別（障害/侵害/設定事故/ログ提出）のRACIが決まっている

□ “証跡パック”（監査で出すログ・設定証跡）が定義されている

□ ログの保持期間と提出期限・形式が決まっている（委託なら契約化）

□ 特権アクセス（委託先含む）は期限付き・承認付き・操作ログ付きで統制できる

□ 例外運用（条件付きアクセス等）は台帳で管理し、期限と解除計画がある

□ バックアップ/DRは「取っている」ではなく「復旧できる手順と訓練」がある

□ 契約終了時の出口（アクセス剥奪、削除、削除証明、ログ引渡し）が決まっている

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

7. まとめ：Azure機能一覧は“責任分界の地図”を持ってから見る────────────────────────────

Azureの機能一覧は、見始めると「便利そう」「とりあえず入れよう」が増えます。しかし、導入後に問われるのは機能ではなく「責任」と「証跡」です。

・誰が守るか・誰が対応するか・何を根拠に説明するか（証跡）

この3点が固まっていれば、Azureの機能選定は“安全に前に進められる”ようになります。

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

お問い合わせ

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

山崎行政書士事務所では、Azure（IaaS/PaaS混在、ID、ログ、運用委託）を前提に、「責任分界」「証跡パック」「委託契約（ログ提出・特権アクセス・再委託）」をセットで整理する支援を行っています。

・Microsoft／委託先／自社の責任分界を1枚にしたい・監査・取引先に説明できる“証跡パック”を整えたい・運用委託の契約で、事故対応・ログ提出・再委託を固めたい

といった課題があれば、オンライン（全国対応）でご相談を承っています。

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

※本記事は一般的な情報提供です。実際の責任分界は採用サービス（IaaS/PaaS/SaaS）と委託範囲、社内体制により変わります。────────────────────────────