「クラウド責任共有モデル」の知識、アップデートできてる？：一から考えるパブリッククラウドセキュリティ（1）

何かと小難しいパブリッククラウドのセキュリティを、やさしく解説する新連載。第1回は、クラウドの責任共有モデルについて、あらためて考えます。分かった気になりがちですが、実は奥が深いんです。

» 2024年03月11日 05時00分公開

[佐古伸晃，野村総合研究所]

この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。

　一般企業によるクラウドサービスの利用は一般的になり、かつての「クラウドサービスは安全なのか？」といった議論は、今では「いかに安全にクラウドサービスを使うか」に主軸を移しています。高度な統制やリソースコントロールが必要とされる場面以外では、クラウドサービスの利用が最初の検討選択肢となっており、クラウドファーストは定着したといっても過言ではないでしょう。

　政府情報システムのためのセキュリティ評価制度（ISMAP：Information system Security Management and Assessment Program）の拡充も進み、さまざまなクラウドサービスが政府調達の要件を満たすリストに並んでいます。

　とはいえ、クラウドサービスの利用が一般化するにつれて、クラウドサービスにおける情報セキュリティ障害（インシデント）も増えています。情報処理推進機構（IPA）が公開した「コンピュータウイルス・不正アクセスの届出状況」（2023）（PDF）では、原因の第1位は｢古いバージョンの利用や修正プログラム・必要なプラグイン等の未導入によるもの｣、次いで「設定の不備」「ID、パスワード管理の不備」となっています。いずれもクラウドサービス「事業者」側の過失ではなく、クラウドサービスの「利用者」側の誤った使い方や設定に起因しています。

　CSA（Cloud Security Alliance）が数年に一度公開している「CSA Top Threats」でも、サービス事業者側のみに起因する脅威はここ数年ランクインしておらず、利用者側に起因する脅威が増加しています。

　これは、クラウドサービスの利用が拡大するにつれ、クラウドサービス側の対策が進んでより強固になっていく一方、利用者側の裾野も広がってクラウドサービスの仕様が十分理解されないまま利用されている実態を反映していると思われます。また、クラウドサービスが高度化・複雑化するにつれ、複数のサービスを組み合わせた場合に想定外の接続許可をしてしまったり、脆弱（ぜいじゃく）なサービスから攻撃されて横移動で侵入される事例なども報告されています。

クラウドサービスは安全になったのに、なぜ脅威はなくならないのか？

　従来のオンプレミス環境では、アプリケーション、サーバ、ネットワーク（LAN、インターネット接続）がそれぞれ物理的な構成で分離され、別担当ということがよくあります。システムをインターネット公開するには複数の担当の承認・作業が必要で、すぐにできるものではありません。ある意味、多層防御が効いている状態です。

　一方でクラウド環境は、一部のプライベート接続を除けばそもそもインターネット接続が前提であり、権限さえあれば1人の担当者がインターネット公開やポート穴開けを、コンソール操作だけで実施可能です。構築時の切り分けでアクセスを全許可した後の戻し漏れや誤設定の他、公開範囲やデフォルト設定の誤認を起因とするインシデントも目立ちます。利用者にとって利便性が極めて高い半面、誤った設定も起きやすい状況といえます。

今こそあらためて考える「責任共有モデル」

　利用者がやるべきセキュリティ対策は何なのでしょうか？　利用規約や公式ドキュメントを確認するのが正確ですが、まずは基本となる「責任共有モデル」について正しく理解することが大切です。責任共有モデルでは「管理主体が責任を持つ」という原則の下、事業者側と利用者側で以下２つの管理責任があり、各々クラウドでの責任を共有する、とされています。

事業者側の責任：クラウドのセキュリティ（Security of the Cloud）
利用者側の責任：クラウドにおけるセキュリティ（Security in the Cloud）

　利用者は自分が使っているクラウドサービスのサービスモデルが何で、どのレイヤーの管理主体で責任を負っており、そのレイヤーにおけるセキュリティ対策が何かを認識しておく必要があります。サービスモデルは、2011年に米国国立標準技術研究所（NIST）がSP 800-145で定義した、「IaaS（サービスとしてのインフラストラクチャ）」「PaaS（サービスとしてのプラットフォーム）」「SaaS（サービスとしてのソフトウェア）」の３つを基本とします。それぞれのサービスモデルを構成するレイヤーと管理主体は下の図の通りです。

クラウドのサービスモデルと管理主体（出典：NRIセキュア　セキュリティ用語解説　責任共有モデル）

　利用者は、オンプレミスでは全レイヤーの責任を負うのに対して、クラウドでは事業者側と責任を分担します。責任分担の範囲はサービスモデルにより異なり、IaaSでは物理ホスト層、PaaSではOS層、SaaSではアプリケーション層よりも上位レイヤーに対して、利用者は責任を負うことになります。どんなサービスモデルであっても、必ず利用者側の責任があり、事業者任せにはできないことに留意しましょう。

　なお、この責任共有モデルは、セキュリティのみならず、予算・調達・契約・精算・ガバナンスなどその他の分野にも適用される、クラウドサービスの根幹を成す考え方です。

細分化する責任共有モデル

　これまで責任共有モデルは、オンプレミス、IaaS、PaaS、SaaSの４区分で説明されてきました。しかし、コンテナ技術の発展に伴って物理ホスト層・OS層の抽象化が進み、サーバレスやローコード／ノーコードなど「XaaS」と総称されるような多様なサービスモデルが登場したことで、細分化が進んでいます。

　このような状況に対して、2021年にCSAは新たな責任共有モデルを提唱しています。新たに「K8s-aaS（サービスとしてのKubernetes）」と「CaaS（サービスとしてのコンテナ）」が追加され、今までのPaaSを「FaaS（サービスとしてのファンクション）」と「ノーコード」に分割し、CaaS、FaaS、ノーコードを総称してサーバレスと定義しています。利用者にとってはさらにレイヤーが増え、責任が混在する層も出てきています。

クラウドネイティブにおける新しい責任共有モデル（出典：CSA Japan　クラウドネイティブにおける新しい責任共有モデルとセキュリティの考え方）

　以下はAmazon Web Services（AWS）における一例です。いずれもAWS特有のコンテナサービスである「Elastic Container Service（ECS）」の責任共有モデルですが、稼働する物理ホスト層・OS層が、EC2（仮想サーバ）かFargate（サーバ管理不要のマネジメントサービス）かによって、利用者の責任範囲が異なることを示しています。構成要素とレイヤーが入り組んでおり複雑ですが、これまで管理していた要素を事業者側に置き換える形で順を追って考えると理解しやすくなります。

ECSの責任共有モデル。上はEC2、下はFargate（出典：AWS Amazon Elastic Container Service 責任共有モデル）

責任共有モデルの課題と「運命の共有」

　責任共有モデルは責任分担の範囲を線引きすることで、対処すべきことを明確化できます。AWSのみならず、Microsoft Azure（Azure）やOracle Cloud Infrastructure（OCI）など他のパブリッククラウドでも採用されています。

　特徴的なのは、Google Cloudが提唱する「運命の共有」です。一般的な責任共有モデルでは、責任境界が明確になる半面、責任境界を超えた対応は難しくなります。利用者が対応し切れない課題に対処するためには、運命を共有して責任境界を跨って協力する必要があると説明しています。ここで言う運命（fate）は、本来の意味である決して抗えない不運ではなく、陥りがちではあるものの対処可能なパターンです。

　Googleが責任共有モデルによる「線引き」の課題として挙げるのは、ビジネスとクラウドサービスの変化の速さ、複数のクラウドサービスの組み合わせで生まれる複雑さ、サービスが稼働する所在地に応じた規制、インシデント管理や高度な持続的脅威への対処の難しさです。

　つまり、責任分担範囲を超えた継続的な連携が次なる課題であり、単なる事業者と利用者との関係ではなく、継続的なパートナーシップを築いてセキュリティ対策を向上させるとしています。通常のクラウドサービスの範疇を超えた、アドバイザリーや導入・運用支援など、これまでとは異なる並走サービスによるサポートを提供しようとしています。

Google Cloudにおける責任共有モデルと、運命の共有に基づく運用モデル。中央から右では、運命の共有という考え方の下で、Google Cloudがユーザーと共に取り組める領域を示している（出典：Google Cloud のセキュリティの概要）

　このような一歩踏み込んだ支援は、実はAWS、Azure、OCIやSaaS事業者も、同じようなアプローチで取り組んでいます。手厚いサポート、ソリューションアーキテクトによる支援、利用者側との連携、セキュリティ対策に貢献できる基盤、設計と手順を記したベストプラクティス、構築のためのインフラストラクチャコード提供など、取り組みは多岐にわたります。それらを体系的にまとめたベンチマークや、第三者機関によるフレームワークも存在します。活用しない手はありません。

　このように、責任共有モデルはいまだに進化し続けています。AIの普及により、今後はさらにクラウド事業者側に任せられる範囲が拡大していくことも予想されます。しかし、責任共有モデルはクラウドサービスのベースとなる考え方です。自分たちの利用しているクラウドサービスのサービスモデルが何で、どの範囲に責任を持つかを理解し、全てを事業者任せにはできないことを心に留めておきましょう。事業者や第三者機関が提供するフレームワークとベストプラクティスを活用することで、利用者側の責任に対応していきましょう。