責任共有モデル：IaaS、PaaS、SaaS

クラウドサービスは主に3つのモデルで提供され、それぞれ抽象化のレベルが異なります。Infrastructure as a Service（IaaS）は、コンピューティング、ストレージ、ネットワークをそのまま提供します。Platform as a Service（PaaS）は、OS、ミドルウェア、ランタイム環境を追加します。Software as a Service（SaaS）は、インターネット経由で完全に機能するアプリケーションを提供します。これらのモデルを理解することは重要です。モデルによってセキュリティ上の責任が大きく異なるためです。

責任共有モデルは、どのセキュリティタスクがクラウドプロバイダーの義務で、どのタスクが顧客に属するかを定義します。このモデルは、「プロバイダーはクラウドのセキュリティ（物理データセンター、ハイパーバイザー、ネットワークインフラ）に責任を持ち、顧客はクラウド内のセキュリティ（データ、アクセス管理、アプリケーションセキュリティ、設定）に責任を持つ」と要約できます。この境界を誤解することは、クラウドセキュリティインシデントの主な原因の1つです。

IaaSでは、顧客が最も大きなセキュリティ責任を負います。クラウドプロバイダーは、物理インフラ、ハイパーバイザー、ネットワークファブリックを保護します。顧客は、OSのインストール、パッチ適用、ハードニング、ランタイムとミドルウェアの設定、アプリケーションセキュリティ、ネットワークセキュリティグループのルール、IAMポリシーとユーザー管理、保存時および転送中のデータ暗号化、コンプライアンス設定を担当します。IaaSは最大限の制御を提供しますが、最大限のセキュリティ対策が必要です。

PaaSでは、プロバイダーがOSとランタイムの管理を引き受けます。顧客は、OSへのパッチ適用やミドルウェアの管理を行う必要がなくなり、それらはプロバイダーが処理します。ただし、顧客はアプリケーションコードのセキュリティ（SQLi、XSSなどがないこと）、データの分類と暗号化、IDおよびアクセス管理、アプリケーション設定（環境変数、シークレット管理）、APIセキュリティを引き続き担当します。PaaSでは一部の負担をプロバイダーに移し、顧客はアプリケーションロジックに集中できます。

SaaSでは、プロバイダーがほぼすべてを管理します。顧客が主に担うセキュリティ責任は、アクセス管理（アカウントを持つ人の管理、MFAの適用、権限の確認）、データガバナンス（アップロードするデータと保持期間の管理）、設定セキュリティ（プライバシー設定、共有権限、サードパーティ統合）、そして許容される利用に関するコンプライアンスです。多くのSaaS侵害は、プロバイダーの障害ではなく、共有設定の誤りやサードパーティアプリへの過剰な権限付与に起因します。

一部の管理策は、プロバイダーと顧客の双方で共有されます。たとえば暗号化です。クラウドプロバイダーは暗号化サービス（KMS、デフォルト暗号化）を提供しますが、顧客はそれを有効にし、鍵管理を設定し、適切なアルゴリズムを選択する必要があります。同様に、ID管理ではプロバイダーがIAMツールを提供しますが、顧客は最小権限のポリシーを設定し、MFAを適用する必要があります。共有される管理策をプロバイダーが処理すると想定して設定しないことは、よくある危険な間違いです。

共有責任モデルが破綻する最大の原因は、プロバイダーの障害ではなく、ほとんどの場合顧客による設定ミスです。典型例として、一般公開されたままのS3バケット（2019年のCapital One侵害では1億件のレコードが流出）、権限昇格を許す過度に広範なIAMロール、機密性の高いポートでインバウンドの0.0.0.0/0ルールを設定したセキュリティグループ、クラウドにデプロイしたデータベースで変更されていないデフォルト認証情報などがあります。プロバイダーの基盤インフラは安全でしたが、顧客の設定は安全ではありませんでした。

共有モデルにおける重要な課題の1つが可視性です。オンプレミス環境では、セキュリティチームがすべてのログを管理します。クラウドでは、プロバイダーのインフラストラクチャログにアクセスできない場合があります。顧客は、クラウドネイティブなログ記録サービスを有効にする必要があります。AWS CloudTrail、Azure Monitor、GCP Cloud Audit Logsは、API呼び出しや設定変更を記録します。これらのサービスを有効にしなければ、組織にはクラウド環境で誰が何を行ったかを示す監査証跡がなくなり、コンプライアンスとフォレンジック調査に大きな空白が生じます。

組織がManaged Service Provider（MSP）を利用してクラウド環境を運用する場合、責任は三者間で分担されます。顧客は、契約（SLAとDPA）でセキュリティ上の義務が明確に定義されていることを確認する必要があります。SaaS経由で利用する第三者のクラウドアプリには、さらに複雑な問題があります。過度に広範な権限を持つアプリにOAuth同意を与えると、そのアプリがデータにアクセスできるようになります。第三者のOAuth同意を確認し、定期的に監査することは、SaaSのセキュリティ衛生管理の一環です。

ワークロードをクラウドに移行しても、コンプライアンス要件がなくなるわけではありません。HIPAAでは、PHIを扱うクラウドプロバイダーとのBusiness Associate Agreement（BAA）が必要です。AWS、Azure、GCPはいずれもBAAを提供しています。PCI-DSSでは、クラウド環境を評価対象範囲に含める必要があります。プロバイダーが提供する共有責任マトリックスには、どのPCI管理策が満たされているかが記載されています。組織は、監査に合格するためにプロバイダーが対応する範囲と、自ら実装する必要がある範囲を理解しなければなりません。

共有責任モデルには法的な効力があります。クラウドプロバイダーのTerms of ServiceとService Level Agreements (SLAs)には、可用性の保証と免責事項が定められています。GDPRに基づくData Processing Agreements (DPAs)では、データ処理者の義務が定義されます。プロバイダー側の障害が原因で侵害が発生した場合、顧客はSLAに基づく救済措置を求める根拠を持ちます。顧客の設定ミスが原因の場合、プロバイダーは責任を負いません。契約を理解することは、技術的な管理策を理解することと同じくらい重要です。

このレッスンで扱ったCompTIA Security+ (SY0-701)の概念について、理解度を確認しましょう。

このレッスンでは、共有責任モデルによって、IaaS、PaaS、SaaS全体におけるプロバイダーと顧客のセキュリティ上の義務が定義されること、IaaSでは顧客が最も多くのセキュリティ責任を負い、SaaSでは最も少ないが、アクセス管理とデータガバナンスについては常に顧客が責任を負うこと、そしてクラウド侵害の主な原因は、プロバイダーの障害ではなく顧客の設定ミスであることを学びました。次は、クラウドストレージのセキュリティとデータ漏えいのリスクについて学びます。