クラウドセキュリティの責任共有モデルは、ごく単純そうでいていざ実践しようとするとやっかいなもののひとつです。それが理由なのか、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つの神話）をご視聴ください。

The shared responsibility model for cloud security is one of those things that seems simple enough on the surface, but is actually very complex when you try to put it into practice. That’s probably why as many as 73% of organizations report being unsure about where their cloud service providers’ (CSP) responsibility for securing cloud workloads stops and where theirs begins.

Overcoming this confusion by understanding the details of the shared responsibility concept and how to put it into practice is critical for securing modern, cloud native workloads. This article offers an overview of what shared responsibility means and how to navigate its complexities.

What Is Shared Responsibility in Cloud Security?

At a high level, the shared responsibility model is easy enough to define: it’s a concept that specifies that CSPs share responsibility with their customers when it comes to securing workloads hosted on their clouds. The various CSPs have their own definitions – like those from Amazon Web Services (AWS) and Azure – but they all boil down to the same core idea.

The shared responsibility concept makes sense given that CSPs don’t have full control over everything users do on their clouds. They can’t force customers to configure IAM policies in a secure way or make sure that they patch their applications against the latest vulnerabilities, for example.

Likewise, organizations that use public clouds have limited control over their cloud infrastructure. They can’t monitor for vulnerabilities in a CSP’s servers or detect intrusions inside its network.

Thus, it’s only reasonable that CSPs and their customers must share responsibility for security, with each party taking the lead in securing the resources it controls.

Why Shared Responsibility Can Be Confusing

The shared responsibility concept probably sounds straightforward enough. For several reasons, however, it can be very difficult for organizations to understand how to apply it and ensure that they don’t mistakenly assume their CSP (or CSPs, if they use multiple clouds) is securing resources when it’s actually not.

Shared Responsibility Differences between IaaS, SaaS and PaaS

Probably the greatest source of confusion surrounding shared responsibility is the fact that the way organizations consume cloud resources varies widely. There are three main cloud service models – infrastructure-as-a-service (IaaS), software-as-a-service (SaaS) and platform-as-a-service (PaaS) – and each has different implications for shared responsibility.

IaaS

The shared responsibility concept can be applied most cleanly when you’re dealing with IaaS, which is the bread-and-butter service model for major public clouds like AWS and Azure. IaaS means that the CSP provides access to cloud-based hardware resources, such as virtual machines and storage, which organizations access over the internet. Under this architecture, it’s pretty clear that the CSP is responsible for the security of the infrastructure it provides, while the customer has to take charge for securing any applications and data that it chooses to run on that infrastructure.

SaaS

Things get a bit murkier when you are dealing with SaaS. If a CSP offers a SaaS application, meaning it provides the host infrastructure as well as the software, the line separating customer responsibility from CSP responsibility can be harder to define. Because the CSP rather than the customer controls the software in this case, responsibility for ensuring that the SaaS application is free of vulnerabilities shifts to the CSP. Likewise, the CSP is typically responsible for securely storing any customer data that the SaaS application ingests. At the same time, however, organizations that use the SaaS software are responsible for securing any data they download from it as well as securing access to it.

To put this into context, consider an organization that uses Microsoft 365, Microsoft’s cloud-based productivity suite. Microsoft is responsible for ensuring that the software it delivers through the Microsoft 365 platform is secure. It also takes responsibility for ensuring that Word documents or emails (among other files) that you create in the platform and store in its cloud can’t be accessed by people to whom you haven’t given access. But it’s up to the organization to ensure that access to Microsoft 365 resources is properly locked down, and that any files downloaded to local infrastructure are secure. The organization can’t blame Microsoft if one employee reads another employee’s email because access controls were not properly configured, for example.

PaaS

Matters may be even more complicated if you use a PaaS, which lets you develop and run applications in the cloud, because a PaaS blends SaaS and IaaS together. The CSP would be responsible for securing any underlying infrastructure that hosts the PaaS offering, but responsibility for securing software testing and deployment environments lies with users. Software applications that the CSP provides as part of the PaaS must be secured by the CSP, but software developed with them (including software offered to end-users using an SaaS model via a PaaS service) has to be secured by users.

In short, then, the meaning of shared responsibility depends in part on which type of cloud service model you are using. Given that most major CSPs offer IaaS, SaaS, and PaaS solutions, you need to be cognizant of which type of offering you are using in order to understand how shared responsibility breaks down between you and the CSP. It’s not as simple as saying “on AWS shared responsibility means this, while on Google Cloud it means that,” for example.

Multi-Cloud, Hybrid Cloud, and Shared Responsibility

The fact that many organizations now use multiple clouds at once can also complicate shared responsibility, especially if some of their workloads run in a public cloud and others run in a private cloud.

If, for example, you have a private cloud running on-premises to host some of your applications, and you host other workloads in a public cloud, the conventional shared responsibility model only applies to the public cloud portions of your workload. Responsibility for securing your private cloud lies solely with you, because you manage both the infrastructure and the workloads running on it.

If you use multiple public clouds, your various CSPs should all follow the same shared responsibility guidelines. Keep in mind, however, that the extent to which a CSP secures your data and workloads depends on which category of cloud service you are using, as noted above. Thus, if you are using AWS just for IaaS but you rely on Azure for SaaS, those two CSPs will provide different levels of security services.

Managed Cloud Services and Shared Responsibility

Matters can be complicated further if you use a “managed” cloud service. While different companies have different ways of defining what counts as a managed cloud service, it generally entails a solution where an external provider takes responsibility for deploying, configuring, and (usually) updating your software. The provider (which could be a CSP or a company that merely provides management services for cloud-based workloads) may also provide hosting infrastructure for your workloads, or it may not. It may even offer security-as-a-service as part of its management offering, or it may not.

Given all of the variables at play when using a managed service, there’s no one-size-fits-all rule for applying the shared responsibility model in the context of managed cloud services. You’ll need to look at the details of what your service provider does and doesn’t manage.

And above all, don’t assume that just because you are using a managed service, the provider takes full responsibility for security. For example, if you use Amazon Elastic Kubernetes Service (EKS), a managed Kubernetes service, AWS is responsible for securing the Kubernetes instance that it provides, but it’s up to you to make sure applications you deploy on Kubernetes are secure. Likewise, if you use Platform9 to manage an OpenStack cloud, Platform9 will provide security updates and other services, but it won’t secure the underlying hosting infrastructure, because Platform9 doesn’t provide infrastructure.

Applying the Shared Responsibility Model

Putting the shared security concept into practice for your cloud workloads requires assessing the details of the way those workloads are configured. As a rule of thumb, you should assume that you are responsible for securing anything that you have the power to secure within the context of whichever cloud service model you use. That approach will mitigate the risk that some security considerations might fall through the cracks, because neither your CSP nor you deal with them adequately.

However if the line between your workloads and the CPSs security still seems blurry, you're not alone. One of the most common cloud security myths is that a CSP will handle all of the security a company needs. To learn some of the others and for a further rundown of shared responsibility, check out the recent webcast 3 Myths Of Cloud Native Security, hosted by Matt Chiodi, CSO for Public Cloud at Palo Alto Networks.