責任共有モデルとは？事業者とユーザーの責任範囲や種類を解説
クラウドサービスが普及する現代でプロバイダとユーザーの責任範囲を示した「責任共有モデル」の理解は欠かせません。しかし、以下のように思っている方も多いのではないでしょうか。
「責任共有モデルとはどのようなものなのか」
「責任共有モデルが重要なことは理解しているが、理由や詳細はわからない」
そこで本記事では、責任共有モデルの概要や重要視される理由、一般的な責任範囲などを解説します。後半では代表的なサービスの責任共有モデルも解説するので、ぜひ参考にしてください。
責任共有モデルとは
クラウドサービスが普及する現代において、責任共有モデル（SRM：Shared Responsibility Model）は重要な概念です。責任共有モデルとは、クラウドサービスプロバイダ（以下CSP）とそのサービスを利用するユーザーとの間で各々の責任を定義したものです。
具体的には、クラウドサービスを利用する際、どのコンポーネントについて誰が責任を持つのかを示しています。責任共有モデルは、クラウドのセキュリティの基礎となる考え方です。クラウドサービスを利用する際にはしっかり理解しておくことが必要です。
AWSやGCP、Microsoft Azureをはじめ、実際に多くのプロバイダが責任範囲を明示しています。
責任共有モデルが重要な理由
責任共有モデルを理解することがなぜ重要視されているのか、以下ではその理由を解説します。
- ハイブリッドクラウド環境での責任範囲の複雑化
- セキュリティインシデントの増加
それぞれ見ていきましょう。
ハイブリッドクラウド環境での責任範囲の複雑化
パブリッククラウドやプライベートクラウド、オンプレミスなどを組み合わせた環境を構築することがあります。この「ハイブリッドクラウド環境」においては、責任範囲がより複雑化します。
例えば、オンプレミスのデータセンターでは、セキュリティの責任はハードウェアベンダーではなくユーザー側のセキュリティ部門に帰属します。しかし、プライベートクラウドやパブリッククラウドを併用する場合、プロバイダ側もセキュリティの一部を担うことになります。
このように、複数の環境を組み合わせることで責任が曖昧になりがちです。そこで有用となるのが、責任共有モデルです。責任共有モデルにより、セキュリティやデータに関わる責任範囲をユーザー側とプロバイダ側で明確に区分けできるようになります。これにより、クラウド上での問題やインシデントを未然に防ぐための適切な対策を講じることが可能です。
一方、責任共有モデルを把握していない場合、さまざまなセキュリティリスクが生じます。ユーザーが自らの責任範囲をプロバイダの領分と誤認し、本来必要な対策を実施しない状況に陥るからです。
セキュリティインシデントの増加
2012年以降の12年間で日本国内における個人情報の漏えい数は、累計1億6,662万人分に達しているといいます。これは、日本の人口を超えています。
個人情報の漏えいを含むセキュリティインシデントの発生は、当然クラウドサービスに起因するものもあります。クラウドサービスの基盤はプロバイダ側が整えるものの、具体的な設定や運用はユーザーがおこなわなければなりません。このことからも、責任共有モデルの理解は不可欠であるといえます。
参照：2023年の「個人情報漏えい・紛失事故」が年間最多 件数175件、流出・紛失情報も最多の4,090万人分│東京商工リサーチ
クラウドサービスの設定ミスを引き起こすリスクの実態
Assured調べでは、半数以上のクラウドサービスが、アクセス権限設定の仕様を変更する場合の事前通知を実施していません。
また、以下のような問題も抱えており、設定ミスを引き起こすリスクが潜んでいます。
- クラウドサービスのうちの約3割が、他サービスとの連携機能の使用可否をサービス利用者の管理者権限で設定できない
- クラウドサービスのうちの約2割が、預託データの外部公開機能の使用可否をサービス利用者の管理者権限で設定できない
- クラウドサービスのうちの約半数において、サービス利用者は組織内のアカウントのログイン履歴や操作ログを確認できない
こういった状況下では、クラウド環境での情報漏えいや不正アクセスのリスクが高まります。クラウドサービスを利用する側は、設定ミスを避けるための理解と対策が求められます。
参照：クラウドサービスの設定ミスを引き起こすリスクの実態調査│株式会社アシュアード
設定ミスのリスクを低減する対策の必要性
気軽に利用できるのが、クラウドサービスの特長です。しかし、設定値の内容に対する理解が不足したまま利用すると、思わぬセキュリティリスクを招くことになります。最悪の場合、個人情報漏えいのような重大なインシデントにつながる恐れもあります。
設定ミスが発生した場合、その責任はユーザー側に帰属します。リスクを軽減するためには、適切な機能や仕組みが備わったクラウドサービスを選ぶことが欠かせません。
株式会社アシュアードが提供するyamoryは、設定ミスによるリスクの低減に寄与します。yamoryは、ソフトウェア内部の構成（SCA：ソフトウェアコンポジション解析）からホスト／コンテナ／クラウド／ネットワーク機器など、全レイヤーに対応した脆弱性管理ができる国内唯一のクラウドサービス。独自のリスクデータベースの活用で、クラウドの設定不備はもちろん、OSSのライセンス違反やEOLリスクの検知も可能です。
責任共有モデルのメリット4つ
責任共有モデルには多くのメリットがあります。
- サイバーセキュリティの強化
- コストの削減
- 運用負担の軽減
- スケーラビリティの高さ
それぞれについて見ていきましょう。
1. サイバーセキュリティの強化
サイバーセキュリティを強化できるようになることは大きなメリットです。
責任共有モデルにより、クラウドインフラにおいてセキュリティの責任が明確になります。これにより、脆弱性やデータ侵害のリスクを軽減できるでしょう。責任範囲を明確化することで、ユーザー側でおこなわなければならないセキュリティ対策を講じることもできます。
2. コストの削減
オンプレミスインフラにおいては、すべての責任はユーザー側に帰属します。一方、クラウドサービスにおいては一部の責任をプロバイダ側が負うことになります。
責任共有モデルを正しく理解することでユーザー側の負担が軽減され、無駄なリソースにかかるコストを削減できます。
3. 運用負担の軽減
運用負担の軽減も大きなメリットです。プロバイダ側がセキュリティ責任の一部を負うことを正しく理解できれば、ユーザー側の運用・管理の負担は軽減されます。
結果として他のコア業務に集中しやすくなり、より効率的な運営が可能となるでしょう。
4. スケーラビリティの高さ
プロバイダが形成するエコシステムのプラットフォームは、責任共有モデルに基づいて整備されています。責任共有モデルにより、セキュリティの責任範囲が明確になるため、ユーザーはプロバイダが提供するセキュリティ機能を効果的に活用することが可能です。例えば、AWSではファイアウォールや脅威検出サービスなどを提供しています。
企業の成長に応じて、その時々で必要なセキュリティ機能のみを柔軟に拡張できます。
責任共有モデルの責任範囲
一般的に、責任共有モデルの責任範囲は、大きく添付の図のように分けられます。
ただし詳細は利用するクラウドサービスによって異なるため、利用するサービスの公式情報を必ず確認しましょう。
CSPの責任範囲
CSP（プロバイダ）は、一般的にホストOSやデータセンターの保護、インフラストラクチャの管理などを担います。ハードウェアの維持や物理的なセキュリティ、データの保護も含まれます。
ユーザーの責任範囲
一方、サービス内でユーザー側で設定する範囲に関しては、ユーザーが責任を負うこととなります。例えば、自社のデータやアカウント、アクセス管理などの責任はユーザー側の責任範囲です。また、ネットワーク設定やデータの保存・分析で利用するデータの暗号化もユーザー側が責任を持ちます。
責任共有モデルの種類
ユーザーとプロバイダの責任範囲の境界を「責任分界点」といいます。自社が利用しているサービスの責任分界点を把握しておきましょう。
サービスごとにそれぞれ責任範囲の詳細は異なりますが、利用するサービスの種類によって責任分界点も異なります。
クラウドサービスは主に以下の3種類に分けられ、「IaaS＞PaaS＞SaaS」の順にユーザー側の責任範囲が多くなります。
- IaaS（Infrastructure as a Service）
- PaaS（Platform as a Service）
- SaaS（Software as a Service）
IaaS
IaaSの場合、プロバイダ側は物理データセンターや物理ネットワーク、物理ホストなど、ハードウェアにおける責任を負います。また、仮想化ソフトウェアもプロバイダの責任となります。
一方、それ以外のOSやミドルウェア・アプリケーション・データなどについては、ユーザー側での管理が必要です。PaaSやSaaSと比較してカスタマイズ性に富み自由度が高い反面、運用者の負担も大きくなるのが特徴です。
PaaS
PaaSの場合、プロバイダの責任範囲が広がります。PaaSでは、ハードウェア、仮想化ソフトウェアに加えて、OSやミドルウェアなどもプロバイダ側の責任となります。ユーザーは、アプリケーションと使用するデータを管理することになります。
IaaSよりも開発の自由度は低くなるものの、提供されるプラットフォームを利用するため、管理の手間は軽減できます。
SaaS
SaaSでは、アプリケーションも含め、ほとんどの責任がプロバイダに帰属します。ユーザーはデータの管理を中心におこなえばよく、管理の手間が軽減されるのが特徴です。
カスタマイズ性は低くなりますが、自社のリソースを抑えたい場合に向いているでしょう。
代表的なCSPによる責任共有モデル
ここからは、代表的なCSPにおける責任共有モデルを紹介します。同じプロバイダのサービスでもIaaS・PaaS・SaaSでそれぞれ責任範囲は異なりますが、以下では各プロバイダが公表している内容の特徴をまとめました。
- AWSの責任共有モデル
- Microsoft Azureの責任共有モデル
- GCPの責任共有モデル
- Oracle Cloud Infrastructure（OCI）の責任共有モデル
- アリババクラウドの責任共有モデル
- さくらのクラウドの責任共有モデル
- Salesforceの責任共有モデル
AWSの責任共有モデル
AWS（Amazon Web Services）の責任共有モデルは、プロバイダ側はインフラストラクチャの維持に責任を持つ内容となっています。
物理的なセキュリティやネットワークの保護は、AWSが担います。暗号化オプションを含むデータの管理やアセットの分類、IAMツールでの適切な権限の適用アクセス管理などはユーザー側の責任です。そのため、ユーザー側も自社のデータを守るために、必要に応じて積極的にセキュリティ対策に取り組む必要があります。
参照：責任共有モデル｜AWS
Microsoft Azureの責任共有モデル
Microsoft Azureでは、データとID、オンプレミスリソース、制御するクラウドコンポーネントの管理における責任がユーザー側に帰属します。制御するクラウドコンポーネントはサービスごとに異なります。しかし、デプロイの種類に関わらず、以下の管理はユーザー側で実施しなければなりません。
- データ
- エンドポイント
- アカウント
- アクセス管理
GCPの責任共有モデル
GCP（Google Cloud Platform）の責任共有モデルで、クラウドサービスの基盤となるネットワークとインフラストラクチャで責任を負うのは、GCP側です。一方、ユーザーはアクセスポリシーとデータについて責任を負うことが定められています。
またGCPでは、共有責任モデルで対応できない課題に対処するために「運命の共有」という考え方も導入しています。
参照：Google Cloud における責任の共有と運命の共有｜Google Cloud
Oracle Cloud Infrastructureの責任共有モデル
Oracle Cloud Infrastructureでは、共有セキュリティ・モデルが設定されています。
プロバイダは、クラウド・インフラストラクチャと運用のセキュリティを維持することを定めています。以下がその一例です。
Oracle Cloud Infrastructureが担う責任
- Oracle Cloud Infrastructureのサービス・機能
- Identity and Access Management（IAM）フレームワーク
- 物理的なセキュリティ
- ネットワーク・セキュリティ
- データ・センターの物理的なセキュリティ
- Oracleのサービスを実行するハードウェア、ソフトウェア、ネットワークや施設
一方、ユーザーは自らのワークロードの保護や、利用するサービスの安全な構成設定に責任を持たなければなりません。
Alibaba Cloudの責任共有モデル
Alibaba Cloudは、安全に管理されたインフラストラクチャの確保に責任を負っています。データセンターやネットワーク、コンピューティングリソースなど、広範囲にわたるセキュリティを確保します。一方、ユーザー側はプロダクトのセキュリティ設定の管理やデータセキュリティの確保などの責任を負うことになります。
Alibaba Cloudが担う責任
- データセンター
- アリバババックボーンネットワーク
- コンピューティング
- ストレージ
- 物理デバイス
- Apsara（散型クラウドOS）、およびApsara OSの上で動作する、すべての各種クラウドサービスや製品
- ID（アイデンティティ）、アクセス制御の管理
参照：セキュリティコンプライアンスに関するよくある質問｜Alibaba Cloud
さくらのクラウドの責任共有モデル
さくらのクラウドでは、ハードウェア部分とハイパーバイザやクラウド基盤を構成するソフトウェア部分、PaaS・SaaS系のサービスはプロバイダ側の責任範囲とされています。
一方、OSやその上で動作するソフトウェアについてはユーザー側の責任として定められています。
Salesforceの責任共有モデル
Salesforceでは、「Salesforceが責任を負う範囲」「ユーザーが責任を負う範囲」「両者が連携して解決すべき範囲」の3つに区分けしています。
Salesforceは、インフラストラクチャレベルのセキュリティにおいて監査や認証を取得。設定・運用周りの責任はSalesforceが担っています。
一方、ユーザー側の責任としては、アクセス制御やポリシーの管理、自社内やステークホルダーへの説明責任、法令対応などが挙げられます。また、インシデントレスポンスについては両者が連携して解決すべきであると示しています。
参照：Salesforceにおける責任共有モデル｜Salesforce
責任共有のベストプラクティス
責任共有モデルを理解するだけでなく、実際に適切に運用することも重要です。そのためには、ベストプラクティスに従い、自社のセキュリティを強化する取り組みが欠かせません。
ここでは、特に以下のポイントを解説します。
- サービスレベル契約（SLA）の把握
- セキュリティツール・可視化ツールの使用
サービスレベル契約（SLA）の把握
サービスレベル契約（SLA）とは、ユーザーとプロバイダとの間で交わされる、サービスの品質についての契約です。SLAによって、双方の責任を規定します。SLAの内容を正確に把握することで、自社が負う責任について正しく理解し、適切に対策できます。
SLAの内容は頻繁に変更される可能性があるため、定期的に確認するようにしましょう。変更があれば、それに応じて自社の運用方針を見直し、必要な対策を講じる必要があります。
セキュリティツール・可視化ツールの使用
セキュリティツール・可視化ツールの使用も欠かせません。
クラウド環境では、基本的にユーザー側がデータやアクセス管理をおこなう責任を持っています。しかし、実際にこれらのセキュリティ管理を実施するには膨大な量のリソースが必要となります。すべてを人の手でおこなうことは現実的ではありません。
そこで、セキュリティツールや可視化ツールを利用することにより、管理を効率化しリスクの早期発見と対処が可能になります。
クラウドサービスのセキュリティ対策なら「yamory」にご相談を！
クラウドサービスを利用する際は、責任共有モデルの範囲を正確に把握し、適切に運用しなければなりません。しかし、実際には複雑かつ変化の多い領域であり、ユーザーがすべての事象を把握することは困難です。そういったなか、クラウドインフラの設定不備によるセキュリティリスクの自動検知に注目が集まっています。
株式会社アシュアードが提供する「yamory」は、クラウドインフラの設定不備によるセキュリティリスクの自動検知・管理機能に対応しています。
脆弱性の早期発見はもちろん、ITシステムの全レイヤーにおける脆弱性対策の運用・管理までをオールインワンで実現できます。網羅的かつ効率的なセキュリティマネジメントをかなえたい方は、ぜひご相談ください。
