クラウドセキュリティの責任共有モデルで陥りがちな問題を回避する

This post is also available in: English (英語)

クラウドセキュリティの責任共有モデルは、ごく単純そうでいていざ実践しようとするとやっかいなもののひとつです。それが理由なのか、73%の組織が「クラウドワークロードの保護で、どこまでがクラウドサービスプロバイダ（CSP）の責任で、どこからが自分たちの責任なのかがわかりづらい」と報告しています。

責任共有の考えかたの細かい部分や、その実践方法を理解すること。誤解や思い違いを解きほぐしていくこと。これらは最新のクラウドネイティブなワークロードの保護にはかかせません。

そこで本稿では、責任共有のもつ意味や、そのわかりづらさをどうやって乗り越えていけばいいのかについてまとめていきます。

クラウドセキュリティにおける責任共有とは

責任共有モデルは大まかな定義だけならとくにむずかしくはありません。要するに「クラウドでホストされているワークロードのセキュリティ保護をCSPと顧客とで責任分担すること」というだけだからです。アマゾンウェブサービス（AWS）やAzure など、さまざまなCSPが独自の定義をしていますが、煎じつめれば中心となる考えは同じです。

CSPは、利用者がクラウド上で行うことすべてを完全にコントロールできるわけではありません。そう考えると、責任を共有するというのは理にかなっています。たとえば、CSPは利用者に安全な方法でIAMポリシーを構成するよう強制することはできませんし、利用者にかわって新たに脆弱性の見つかったアプリケーションにパッチを適用することもできません。ひるがえって、パブリッククラウドの利用者である組織がクラウドインフラに対して持てるコントロールにも限りがあり、利用者はCSPのサーバーの脆弱性を監視できませんし、ネットワーク侵入を検出したりもできません。

したがってCSPとその利用者は、セキュリティの責任を共有し、おのおのの管理下にあるリソースを主体的に保護する必要があります。

責任共有がわかりづらい理由

ということで、責任共有の考えかたじたいは、さほど込み入ったものではないように思えます。ところがさまざまな理由から、組織が責任共有をどう適用していけばいいかを理解し、自分たち側に責任のあるリソースの保護をまちがってCSP側にかぶせることなくきっちり運用していくのは、かなりむずかしいことがあります。

IaaS、SaaS、PaaSにおける責任の違い

おそらく責任共有をめぐる最大の混乱要因は、組織によってクラウドリソースの使いかたにかなりばらつきがあることでしょう。クラウドサービスモデルには大きくわけて3種類ありますが、このそれぞれが、責任共有についてちがった意味をもっています。その3種類とは、サービスとしてのインフラストラクチャIaaS、サービスとしてのソフトウェアSaaS、サービスとしてのプラットフォームPaaSです。それぞれについて見ていきましょう。

IaaS

責任共有の概念がいちばん明快に当てはまるのはIaaSでしょう。IaaSはAWSやAzureなど主要なパブリッククラウドにとっての本業ともいえるサービスモデルです。IaaSの場合、組織がインターネット経由でアクセスする仮想マシンやストレージなどのクラウドベースのハードウェアリソースへのアクセスをCSP側が提供します。この場合、インフラのセキュリティに責任をもつのはとうぜんそれを提供するCSPで、利用者はインフラ上で自身が実行するアプリケーションやデータのセキュリティについて責任をもちます。

SaaS

SaaSではちょっと境界があいまいになってきます。CSPがSaaSアプリケーションを提供する場合、つまり、ホストのインフラとソフトウェアの両方を提供する場合、利用者側の責任とCSPの責任とをきちんと線引きしづらくなります。この場合、ソフトウェアをコントロールするのは利用者ではなくCSPなので、SaaSアプリケーションに脆弱性がないことを確認する責任はCSPに移ります。同様に、SaaSアプリケーションが取り込む顧客データを安全に保存する責任も、通常はCSP側にあります。その一方、SaaSソフトウェアからダウンロードされるデータの保護や、SaaSソフトウェアにアクセスする経路の保護責任は、SaaSソフトウェアを使用する組織側にあります。

これを具体的な文脈において説明するのに、Microsoftが提供するクラウドベースのオフィスソフト、Microsoft365を利用する組織について考えてみたいと思います。MicrosoftにはMicrosoft365プラットフォーム経由で提供するソフトウェアが安全であることを保証する責任があります。プラットフォームで作成してクラウドに保存したWord文書や電子メールなどに、アクセスを許可していないユーザーがアクセスできないようにする責任もあります。ただし、Microsoft365のリソースに部外者がアクセスできないよう適切な処置をほどこしたり、社内のインフラにダウンロードされたファイルの安全性を確認するのは組織の責任です。たとえば、組織がアクセス制御をきちんと設定していなかったがためにある従業員がべつの従業員の電子メールを読んでしまったのであれば、組織がMicrosoftを責めることはできません。

PaaS

問題をさらにややこしくするのがPaaSを使っている場合です。PaaSはSaaSとIaaSを組み合わせたもので、組織はこの上でクラウドでアプリケーションを開発・実行することができます。CSPには、PaaSサービスをホストしている基盤インフラを保護する責任がありますが、ソフトウェアテストを保護し、デプロイ環境を保護する責任は利用者側にあります。CSPがPaaSの一部として提供するソフトウェアアプリケーションは、CSP側に保護責任があります。ただし、それらのソフトウェアアプリケーションを使って開発したソフトウェアは、利用者に保護責任があります（PaaSサービスを介し、SaaSモデルを使ってクラウドサービス利用者が自身のエンドユーザーに提供しているソフトウェアもこれに含まれます）。

要するに、責任共有の意味は使うクラウドサービスモデルの種類に依存する部分があるということです。ほとんどの主要CSPがIaaS、SaaS、PaaSソリューションを提供していることをふまえると、皆さんとCSPの間でどのように責任共有の線引きをすればいいのかを把握するには、自分の使っているサービスの種類を意識しておく必要があるということで、これは「AWSでの責任共有はこうでGoogle Cloudだとこう」と言ってしまえるほど簡単ではありません。

マルチクラウドやハイブリッドクラウドと責任共有

いまは複数のクラウドを並行して使用する組織も多いので、これがまた責任共有をややこしくしています。とくに、あるワークロードはパブリッククラウド上で実行し、べつのワークロードはプライベートクラウド上で実行、といったケースでは、線引きがむずかしくなります、

具体的な例でお話ししましょう。たとえば皆さんの組織が、オンプレミスでプライベートクラウドを実行してなんらかのアプリケーションをホストし、同時にパブリッククラウドで他のワークロードもホストしている場合を考えてみましょう。この場合、従来の責任共有モデルは、ワークロードのパブリッククラウド部分にだけ適用されます。ここでプライベートクラウドを保護する責任は皆さんにだけにあります。なぜならインフラとその上で実行されているワークロードの両方を管理しているのは皆さんだからです。

パブリッククラウドを複数使用している場合でも、皆さんのCSPは同じ責任共有ガイドラインに従っているはずです。ただし先に説明したとおり、CSPによるデータやワークロードの保護範囲は、お使いのクラウドサービスの種類によって違うということは意識しておかなければなりません。つまり、AWSではもっぱらIaaSを使い、SaaSはAzureにたよっている、というケースでは、これら2つのCSPは異なるレベルのセキュリティサービスを提供するということです。

マネージドクラウドサービスと責任共有

ここで「マネージド」なクラウドサービスを使っていると話がさらに複雑になります。何をもってマネージドクラウドサービスと呼ぶかは企業によってまちまちですが、たいていは、外部のプロバイダがソフトウェアのデプロイ、設定、更新（通常）をおこなうソリューションがそう呼ばれています。プロバイダ（これはCSPの場合もあるしクラウドベースのワークロード管理サービスを提供するだけの会社の場合もある）もワークロードのホスティングインフラを提供するものとしないものにわかれます。さらにはマネージドサービスの一環としてサービスとしてのセキュリティを提供する場合もしない場合もあります。

マネージドサービスの場合、登場してくる変数があまりに多すぎるので、どんなマネージドクラウドサービスにもぴったり当てはまるような責任共有モデルの万能ルールは存在しません。ですから利用者側で、サービスプロバイダの管理していることとしていないことの詳細をつめる必要があります。

そしてこれがいちばん大事なことですが、マネージドサービスを使用しているからといってプロバイダ側がセキュリティに全責任を負うと勘違いしてはいけません。たとえば、マネージドなKubernetesサービスであるAmazon Elastic Kubernetes Service（EKS）を使うことを考えてみましょう。この場合、AWSは提供するKubernetesインスタンスを保護する責任は負いますが、Kubernetesにデプロイするアプリケーションが安全であることを確認する責任を負うのは利用者側です。同様に、Platform9を使ってOpenStackクラウドを管理しているケースでは、Platform9はセキュリティ更新プログラムや、その他のサービスは提供しますが、インフラは提供していないので基盤ホスティングインフラは保護しません。

責任共有モデルを実践する

セキュリティ責任共有モデルの考えかたをクラウドワークロードに実践する場合、ワークロードの構成方法の仔細を評価する必要があります。原則としては、どのクラウドサービスモデルを使うのであれ、そのモデルのコンテキスト内で保護権限があるものはぜんぶ自身に保護責任があるとみなすべきです。このアプローチをとっておけば、CSPも自分も適切な処置を講じずセキュリティへの配慮が抜け落ちるというリスクを軽減できます。

それでもやはりワークロードとCPSのセキュリティ分担境界がわかりづらい、ということもあるでしょう。その悩みは皆さんおひとりだけではありません。いちばんよくあるクラウドセキュリティ神話の1つは「CSPは企業に必要なセキュリティすべてに対応してくれる」というものですが、クラウドセキュリティの神話はほかにもいくつかあります。これらの神話を学び、責任共有の詳細をこまかくチェックするには、弊社パブリッククラウドのCSOであるMatt Chiodiがホストをつとめた最近のWebキャスト、3 Myths Of Cloud Native Security（クラウドネイティブセキュリティの3つの神話）をご視聴ください。