責任共有モデル

読み：せきにんきょうゆうもでる　／　英語表記：Shared Responsibility Model

• セキュリティ
• サーバ・ストレージ

クラウドサービスのセキュリティを保つ責任を、クラウド事業者と利用者で分担する考え方である。事業者はデータセンターやサーバ機器など物理的な基盤を受け持つ。両者の境界はIaaS・PaaS・SaaSといったサービスモデルによって変わるが、保存する情報・アカウント・設定の管理はどれを選んでも利用者に残る。

イマシルちゃんの解説

クラウドを使うと、サーバやデータセンターを自分で持たなくてよくなるね。
でも、安全を守る仕事まで全部お任せできるわけじゃないんだ。
建物や機器を守るのはクラウドの事業者で、そこに置くデータやアカウントの扱いは使う側の担当になるよ。
この役割分担を整理した考え方を責任共有モデルというの。
仮想サーバを丸ごと借りる形なら、OSの更新まで使う側の仕事になるんだ。
完成したアプリを使う形なら、事業者の担当はぐっと広がるよ。
どこまでが自分の仕事かを知らないと、公開設定のミスで情報が漏れることもあるから大事なんだ。

より深い解説

定義と位置付け

責任共有モデル（Shared Responsibility Model）は、クラウドサービスのセキュリティ対策と運用を、クラウド事業者と利用者のどちらが担うかを整理する枠組みである。特定の規格やプロトコルの名前ではない。主要なクラウド事業者が自社サービスの説明で使い、利用者との役割分担を示すために用いている。

オンプレミスでは、建物からアプリケーションまですべてを自組織で管理する。クラウドへ移ると、その一部を事業者が引き受ける。ただし事業者に移るのは「事業者が管理できる部分」だけである。利用者が入れたデータや、利用者が決めたアクセス権の誤りまで事業者が責任を負うわけではない。

AWSはこの分担を、事業者側の「Security of the Cloud」と利用者側の「Security in the Cloud」という言葉で表している。前者はクラウドを動かすハードウェア・ソフトウェア・ネットワーク・施設の保護である。後者は、利用者がクラウドの上で選んだサービスをどう構成し、どう使うかの責任である（AWS：責任共有モデル）。

提供形態ごとに境界が動く

クラウドサービスの提供形態は、NISTの定義（NIST SP 800-145）でIaaS・PaaS・SaaSの三つに分けられる。この定義自体が、利用者が何を管理できるかで三つを区別している。

どの形態でも、その下にあるネットワーク・サーバ・OSなどの基盤は利用者が管理しない部分として定義されている。つまり、IaaSからSaaSへ進むほど事業者の担当が広がり、利用者の担当が狭くなる。

Microsoftは同じ関係を項目ごとの表で示している（Microsoft Learn：クラウドにおける共同責任）。次はその内容を日本語で整理したものである。「共有」は両者がそれぞれの部分を受け持つ項目を表す。

オンプレミスでは表のすべてが利用者の担当である。IaaSに移っても、OSから上は利用者に残る点が重要である。PaaSではOSや実行環境、ミドルウェアを事業者が管理するが、利用者は自分のコードの安全性やアプリケーションの設定を受け持つ。

どの形態でも利用者に残るもの

表の最下行のとおり、提供形態を変えても利用者から離れない責任がある。Microsoftの資料は「すべての形態で、データとIDは利用者のものである」と明記している。

SaaSを使えばサーバの管理は不要になる。それでも、ファイル共有の範囲を「誰でも閲覧可」にすれば、情報は外部から読める。この誤りは事業者の基盤の不備ではなく、利用者の設定の問題である。

管理者アカウントには多要素認証を求め、日常用のアカウントと分ける。ゲストなど外部の利用者の権限は必要最小限にする。これらは事業者が自動で行うものではなく、利用者が設定して初めて有効になる。

管理策を三種類に分けて考える

AWSは、セキュリティの管理策（コントロール）を受け持ち方で三つに分けている。監査や社内規程で「この管理策は誰が実施しているか」を説明するときに役立つ分け方である。

共有される管理策の代表がパッチ管理である。事業者は自社基盤の脆弱性を修正し、利用者はIaaS上のゲストOSとアプリケーションを修正する。「パッチはクラウド事業者が当ててくれる」と一言でまとめると、どちらの範囲の話かが分からなくなる。教育も同様で、事業者は自社の従業員を、利用者は自組織の担当者を教育する。

IaaSで公開Webサーバを動かす例

IaaS上の仮想サーバでWebサイトを公開する場合を考える。作業を担当者ごとに分けると次のようになる。

1. 事業者は、データセンターへの入退室管理、物理サーバとハイパーバイザの保守、基盤ネットワークの運用を行う。
2. 利用者は、仮想サーバに入れたOSとWebサーバソフトウェアの更新を計画し、適用する。
3. 利用者は、仮想サーバへの通信を制限するルールを設定する。AWSではセキュリティグループが仮想サーバ単位の仮想ファイアウォールにあたる。
4. 利用者は、管理用のSSH接続を管理端末のアドレスだけに許可し、管理者アカウントを個人ごとに発行する。
5. 利用者は、アクセスログと管理操作のログを取得し、保管期間と確認の手順を決める。
6. 利用者は、データベースの暗号化とバックアップの取得・復旧手順を設計する。

この中で事業者の仕事は1.だけである。2.〜6.は、オンプレミスでサーバを運用するときとほぼ同じ作業が残る。仮想サーバ自体の通信制御を利用者が設定する点は、ファイアウォールの設計問題でもよく前提になる。

同じWebサイトをPaaSの実行環境に載せ替えると、2.のOS更新は事業者の担当に移る。一方、アプリケーションのコードの脆弱性と、アプリケーションに与えるアクセス権は利用者の担当のままである。提供形態を変えると「何が不要になり、何が残るか」を区別して説明できることが大切である。

設定の不備が事故につながる

利用者の責任範囲で起こりやすい事故が、利用者自身による設定の誤りである。ストレージの公開範囲の誤り、管理画面への接続制限の漏れ、不要になったアカウントの放置などが典型例である。

総務省のクラウドサービス利用・提供における適切な設定のためのガイドライン（2022年10月）は、この問題を責任共有モデルの観点から整理している。利用者は、使うサービスの設定項目を理解し、責任範囲の中で適切に設定することが求められる。事業者には、安全な初期設定と分かりやすい情報の提供が求められる。

同ガイドラインは、具体的な対策として次のような点を挙げている。

• 管理者と一般利用者のアカウントを分け、管理者には多要素認証を使う。
• サービスによっては初期状態で取得されないログを、有効にして監視する。
• 問題の発生を防ぐ予防的な対策と、発生を早く検知する発見的な対策を組み合わせる。
• 重要な情報を暗号化し、鍵を一元的に管理する。
• 定期的な監査や外部の評価で設定を点検する。

設定の誤りは、一度正しく設定しても運用中の変更で再び生じる。そのため、設定を変更する手順と、設定状態を定期的に点検する仕組みの両方を用意する。

委託先や多段の構成での責任

実際の構成では、事業者と利用者の二者だけで完結しないことが多い。日本ではシステムの構築・運用を外部のSIerへ委託する場合が多い。総務省のガイドラインは、委託先が設定作業を行っても、サービスを利用する組織が最終的な責任を負うと整理している。委託先と作業範囲を明確にし、設定内容を確認する仕組みが必要になる。

また、SaaS事業者が自社サービスを他社のIaaSやPaaSの上で提供することがある。この場合、SaaS事業者は基盤の利用者であると同時に、自社の顧客に対してはサービス全体の提供者である。顧客から見て、下位の基盤事業者の責任分担を理由に説明を省くことはできない。

契約と責任の範囲

責任共有モデルは「誰が何をするか」の整理であり、障害時の補償内容を直接定めるものではない。サービスの稼働率などの品質と、それを満たせなかったときの扱いはSLA（サービスレベル合意）や利用規約で決まる。

例えば、事業者がSLAで高い稼働率を示していても、それは事業者が管理する範囲の稼働に関する約束である。利用者が一つの仮想サーバだけで構成したシステムが、そのサーバの障害で止まった場合の対策は、利用者の設計の問題として残る。複数の拠点やゾーンへの分散、バックアップからの復旧手順は、利用者が責任範囲として設計する。

事業者の管理範囲が適切に運用されているかは、利用者が自分で立ち入って確認できない。このため、事業者が公表する第三者認証や監査報告書を確認し、自組織の要求を満たすかを判断する。

通信回線の責任分界点との違い

ネットワークの分野では、通信事業者と利用者の設備の境目を「責任分界点」と呼ぶ。これは回線のどこまでを通信事業者が保守するかという、設備の物理的な境界を指す。

責任共有モデルは、クラウドの上の層ごとにセキュリティと運用の責任を分ける考え方である。物理的な接続点ではなく、OS・アプリケーション・データ・IDといった層ごとに分担が決まる。どちらも「境目をはっきりさせて障害時の対応を迷わない」という目的は共通するが、分ける対象が異なる。

障害やインシデントの切り分け

クラウド上のシステムで問題が起きたときは、まずどの層の問題かを特定し、その層の担当者を判断する。次は切り分けの独自例である。

事業者側の障害でも、利用者が何もできないわけではない。複数の地域への分散やバックアップの別保管といった利用者側の設計によって、影響を小さくできる。

午後での問われ方

• クラウドへの移行案について、IaaSとSaaSのそれぞれで利用者が引き続き行う作業を答えさせる。
• IaaS上のサーバの脆弱性対応を誰が行うべきかを問い、OSから上は利用者の担当であることを根拠に説明させる。
• SaaSの共有設定の誤りによる情報漏えいを題材に、原因が利用者の責任範囲にあることと、再発防止策を記述させる。
• 委託先が設定作業を行った場合の確認手順や、利用組織が責任を負う理由を説明させる。
• 事業者の稼働率の保証と、利用者側の冗長化設計を区別して答えさせる。

参考資料

• AWS：責任共有モデル
• Microsoft Learn：Shared responsibility in the cloud
• NIST SP 800-145：The NIST Definition of Cloud Computing
• 総務省：クラウドサービス利用・提供における適切な設定のためのガイドライン（概要）

この用語が出てくる記事

• IaaS