サイト内の現在位置

クラウドサービス利用における責任共有モデルの実情について

NECセキュリティブログ

2024年3月15日

NECサイバーセキュリティ戦略統括部セキュリティ技術センターの中野です。
私はクラウドサービスのセキュリティに携わることが多いのですが、その業務の中で責任共有モデルについて見つめ直す機会がありました。その際、一般的に定義されている責任共有モデルと現場の実情に乖離があるように思いました。
そこで本ブログでは、クラウドサービス利用における責任共有モデルの実情について、問題点やその問題点に対してどう向き合うべきかを考えてみたいと思います。

責任共有モデルとは

ここで、責任共有モデルについておさらいします。
責任共有モデルとは、クラウドサービスを利用する際のクラウド事業者とユーザの責任範囲を示したモデルのことです。一般的に、図1のようなモデルで表されることが多いです。

図1.一般的な責任共有モデルの例

IaaSでは多くの場合、クラウド事業者はネットワーク、ストレージ、サーバ、仮想化環境といったインフラストラクチャの運用管理やセキュリティ対策の責任を持ち、OSやミドルウェア、アプリケーションについての管理責任はユーザが持ちます。PaaSではインフラストラクチャだけでなくOSやミドルウェアについての管理責任もクラウド事業者側が持ち、ユーザはアプリケーションとデータに対して管理責任を持つことになります。SaaSではアプリケーションを含めたほぼ全ての管理責任をクラウド事業者側が持ち、ユーザ側の管理責任についてはアプリケーション上で取り扱うデータだけになります。
図1のように、クラウドサービスではクラウド事業者とユーザとで責任を共有することになりますが、実際には、この単純なモデルではクラウドサービスの責任範囲について説明できない場合があります。具体的な問題点として、下記の2つがあると思います。

  1. システムインテグレーターや業務委託などによる責任範囲の複雑化
  2. クラウドサービスモデルの多様化

下記に2つの問題点の詳細について、記載します。

システムインテグレーターや業務委託などによる責任範囲の複雑化

責任共有モデルの1つ目の問題点は「クラウド事業者」と「ユーザ」の責任範囲しか示せていない点です。例として、とある企業がシステムを導入する場合を考えてみましょう。システムを導入するために、まずはシステムインテグレーター(以下、SIer)に依頼したとします。そのSIerがクラウドサービスを利用する場合、これだけで「システム導入企業」、「クラウド事業者」、「SIer」の三者の責任範囲があることになります。さらに、SIerがアプリ開発を別の開発会社に委託する場合はどうでしょうか。運用を別の会社に委託する場合はどうでしょうか。責任範囲がより複雑になるのは明らかだと思います。
実際に、以下のような状況を仮定して、責任範囲を図1のモデルに無理やり当てはめてみました(図2)。

  • 金融会社A社がSIerであるB社にシステムを発注
  • B社はC社のPaaSサービスを使用してアプリを開発
  • C社のPaaSサービスはクラウド会社であるD社のIaaSサービスを使用
  • B社は運用をE社に委託
図2:複数の企業が関わっている場合の責任共有モデルの例

責任範囲が複雑になっていることが分かります。また、E社への運用委託について図中で表現できていません。このような例はよくあるパターンだと思いますが、図1のようなモデルではカバーしきれていません。

クラウドサービスモデルの多様化

2つ目の問題点は、新しいクラウドサービスの登場により、サービスモデルが多様化してきていることです。新しいクラウドサービスモデルの例として、サーバレス(FaaS)やコンテナ(K8s-aaS、CaaS)、NoCodeなどが挙げられます。これらのサービスの責任範囲は図1の責任共有モデルでは示せていません。
これらのサービスの責任共有モデルについて、CSA Japan(日本クラウドセキュリティアライアンス)の記事new window[1]で考え方が紹介されています(図3)。なお、図3はあくまで現時点での考え方であり、NISTやISOなどで正式に定義されたものではない点にご注意ください。

図3.新しい責任共有モデルの考え方(new window[1]より引用)

図3のモデルは図1と比較すると、ミドルウェア周りが詳細化され、CNCFレイヤーと呼ばれるレイヤーが追加されているのが分かります。CNCFはCloud Native Computing Frameworkの略で、クラウドネイティブに関するレイヤーになります。各レイヤーの内容は以下です(new window[1]より一部引用)。

  • プロビジョニングサービスプレーン
    コントロールプレーンに相当。コンテナの稼働や停止等の運用や、コンテナの配置、デプロイ時のコンテナ入れ替えや仮想ネットワークの提供等を行う。
  • マネージドサービスランタイム
    データプレーンに相当。コンテナが稼働する実行環境、もしくはサーバーインスタンスそのもので、コンテナランタイムを管理する。
  • アプリケーションビルドとパッケージ化
    コンテナイメージの作成、コンテナ環境への移動・実施といういわゆるビルドチェーンを管理する。
  • アプリケーション定義と開発
    アプリケーションのコードロジックを定義・開発する。

クラウドサービスモデルの複雑化により、責任共有モデルもより複雑になってきていることが図3から分かります。コンテナ、サーバレス、NoCodeについて、現在正式な責任共有モデルは定義されておらず、図1の責任共有モデルは実情に合っていません。また、図3の責任共有モデルが正式に定義されたとしても、クラウドサービスは常に新しいサービスが生まれるため、すぐに陳腐化する恐れがあります。

どう向き合うべきか

では、このような責任共有モデルの実情にどのように向き合えば良いのでしょうか。クラウド事業者とユーザがそれぞれ何を実施すべきか、何を求められているのかを考えてみます。
クラウド事業者に求められていることは、クラウドサービスを提供するにあたってどこまで責任を負うのか、どの部分の責任をユーザが負うのかを明確に示すことだと思います。そして、ユーザに対して必要な機能や情報を提供することが求められます。ただ責任範囲を示しただけではユーザが正しくセキュリティ実装できないため、そのための機能や情報を提供する必要があるということです。このことはCSA Japanが発行している「クラウドコンピューティングのための セキュリティガイダンス v4.0」PDF[2]にも記載されています。
一方、ユーザにはクラウド事業者から提供された機能や情報を活用しつつ、必要なセキュリティ対策の実施が求められます。そのため、何を自社がやらないといけないかを把握し、実行することが重要です。また、ユーザには説明責任も求められます。クラウド事業者はセキュリティの管理責任を一部担ってくれますが、お客様に対する説明は自社で担う必要があります。そのため、セキュリティポリシーをきちんと定め、お客様に説明すること、そしてそのポリシーを満たすことができるクラウドサービスを選定することが重要です。

まとめ

本ブログではクラウドサービス利用における責任共有モデルの実情について、問題点や実施すべきことを書きました。責任範囲の問題はクラウドサービス独自の問題ではなく、従来のオンプレシステムでも同様のことが言えます。ただ、クラウドサービスの場合は、サービス形態が多岐にわたること、常に新しいサービスが生まれることからその問題がより顕著になっていると思います。個人的にはSBOMのような管理ツールで責任範囲も管理できる未来が来ることに期待していますが、果たしてそのようなツールは今後生まれるのでしょうか。
本ブログが責任共有モデルについて見つめ直す良いきっかけになりましたら幸いです。

参考資料

執筆者プロフィール

中野 智晴(なかの ともはる)
セキュリティ技術センター 実装技術レギュレーショングループ

NECグループのセキュア開発・運用を推進。
CISSP Associate、情報処理安全確保支援士(RISS)を保持。

執筆者の他の記事を読む

アクセスランキング