はじめに
背景
本ドキュメントはAWSの責任共有モデルをわかりやすく説明します。クラウドを使うときに「誰が何を守るのか」を明確にすることは重要です。曖昧だと運用やセキュリティで問題が起きやすくなります。
本書の目的
- 責任共有モデルの基本をやさしく理解していただくこと
- AWS側と利用者側の具体的な責任範囲を整理すること
- 他のクラウドと比べて注意点を把握すること
- 実務で使えるポイントを示すこと
対象読者
クラウド導入を検討中の方、運用担当者、セキュリティ担当者など幅広く想定しています。
簡単な例（家のたとえ）
AWSは建物や基礎設備を提供します。利用者は部屋の内装や家具、鍵の管理を行います。どちらが何をするかを最初に決めると、トラブルを防げます。
読み方のポイント
具体例に目を通し、自分の環境でどの範囲を担当するかを確認してください。次章で詳細を丁寧に説明します。
責任共有モデルとは
概要
責任共有モデル（Shared Responsibility Model）は、クラウド事業者と利用者がセキュリティや運用の責任を分け合う考え方です。どちらが何を守るべきかを明確にすることで、誤解や見落としを防ぎ、安全な運用を実現します。
なぜ必要か
クラウドでは物理的な管理を事業者が行いますが、設定ミスやアカウント管理の不備は利用者側の問題で起こります。役割を明確にすると、どこに注意を向けるべきかがはっきりします。したがって、セキュリティ対策が効果的になります。
責任の分担（簡潔）
- クラウド事業者：データセンターの物理保護、ネットワーク基盤、ハイパーバイザーや基盤サービスのセキュリティを担います。
- 利用者：保存するデータ、ゲストOSやアプリケーションの設定、アクセス制御（ID管理）、暗号化やバックアップを管理します。
具体例
- IaaS（仮想サーバ）: 事業者はホストやハイパーバイザーを守り、利用者はOSパッチやアプリ、ファイアウォール設定を行います。
- SaaS（ソフトの提供）: 事業者はアプリ自体の保護を行い、利用者はユーザー権限や共有設定、保存データの扱いを管理します。
よくある誤解と心がけ
「クラウドに置けば全部任せられる」と思われがちですが、データや設定の多くは利用者の責任です。定期的に権限や設定を見直し、ログやバックアップも自分の側で管理する習慣をつけることをおすすめします。
AWSの責任共有モデルの詳細
概要
AWSの責任共有モデルは、セキュリティ責任を「AWS側（クラウドのセキュリティ）」と「お客様側（クラウド内のセキュリティ）」に分けます。どこまでAWSが管理し、どこからお客様が管理するかを明確にする仕組みです。
AWSの責任（クラウドのセキュリティ）
- 物理的な施設とハードウェア：データセンターの入退室管理やサーバーの保守を行います。
- 基盤ネットワークとハイパーバイザ：ネットワークの分離や仮想化基盤の安全性を確保します。
- インフラの冗長性と可用性：電源や冷却、ハードウェア故障対策を整えます。
お客様の責任（クラウド内のセキュリティ）
- データとアクセス管理：保存するデータの暗号化やアクセス許可の設定を行います。
- アプリケーションと設定：アプリの脆弱性対応やサービス設定の適切な管理はお客様の役割です。
- OSやミドルウェアの管理：特に仮想マシンを使う場合はパッチ適用や設定管理が必要です。
サービス別の違い
- SaaS（例：ホスト型アプリ）: AWSは基盤を管理し、お客様はデータやユーザー権限を管理します。
- PaaS（例：マネージドなアプリ実行環境）: お客様はアプリとデータ、設定の責任が大きくなります。
- IaaS（例：EC2）: 仮想マシン内のOSやソフトは全面的にお客様の管理です。
実践的な対策例
- IAMで最小権限を設定する
- 保存データを暗号化する（S3やボリューム）
- ログ収集と監視を有効にする
- OSやアプリに定期的にパッチ適用する
責任範囲を明確にし、適切な対策を組み合わせることで安全な運用が可能です。
他のクラウドプロバイダとの比較
Microsoft Azure
Azureではデータ、ID、オンプレミスとクラウドの接続、クラウド上のコンポーネント設定の多くが利用者の責任です。たとえば、仮想マシン(OSパッチ適用)やAzure ADのアクセス管理、データ暗号化の設定はユーザー側で行います。一方で物理設備や基盤サービスはAzureが管理します。
Google Cloud Platform (GCP)
GCPはネットワークや物理インフラの保護を担い、ユーザーはアクセスポリシーやデータ管理を責任持って設定します。例としてファイアウォールのルール、Cloud IAMの権限設計、保存データの暗号化設定が利用者の作業です。
Alibaba Cloud
Alibaba Cloudはインフラとその安全管理を主に担当します。ユーザーはプロダクトの構成やアプリケーション側のデータ保護、アクセス制御を実施します。例えばオブジェクトストレージの公開設定やアプリの認証実装は利用者が管理します。
さくらのクラウド
さくらのクラウドではハードウェアや基盤ソフトウェアをプロバイダが管理します。仮想サーバのOSやミドルウェア、アプリケーションのパッチ適用や設定はユーザー側の責任です。バックアップやログ管理の仕組みも利用者で準備します。
Salesforce
Salesforceは責任を三層に分け、インフラレベルの安全性はSalesforceが担います。顧客データの取り扱いやアプリ内のアクセス制御、設定ミスの防止は利用者の責任です。カスタムコードや設定の適切さがセキュリティに直結します。
実務的な比較ポイント
- 共通点：物理と基盤はプロバイダが担い、データやアクセス制御は利用者が管理する点が多いです。
- 優先すべき対策：IAM設計、データ暗号化、OS・アプリのパッチ、ログとバックアップの整備。
- 具体例：S3やBlob、OSSの公開設定は必ず確認し、不要な権限は最小化してください。
重要性と実装のポイント
責任共有モデルを正しく理解することは、AWSを安全に使うための基礎です。利用者が自分の責任範囲を把握しないと、設定ミスやデータ漏えいなどのリスクが高まります。ここでは重要性の説明と、実務で役立つ具体的な実装ポイントを分かりやすく示します。
なぜ重要か
- 責任の不明確さは運用ミスにつながります。たとえば、アクセス権を広く与えたままにすると、不要な操作でデータが漏れる可能性が高まります。
実装のポイント（具体的な手順）
- 責任範囲を文書化する：誰が何を管理するかを明確にします。例：ネットワーク設定は運用チーム、アプリ設定は開発チーム。
- 最小権限の原則を守る：必要な権限だけを与えます。管理者アカウントは日常運用で使わないようにします。
- データ保護を徹底する：保存時・転送時の暗号化、バックアップを自動化し、復元手順を定期検証します。
- 継続的なパッチ適用と資産管理：OSやミドルウェアの更新を計画的に実施し、資産を把握します。
- ロギングと監視：アクセスログやアラートを有効にし、異常を早期に検知します。ログは長期保存と定期確認を行います。
- インシデント対応計画：発生時の連絡手順、復旧手順、責任者を決めて演習します。
クラウドのレジリエンス（可用性）の共有
- AWSは基盤の可用性を提供しますが、ユーザー側も冗長構成やバックアップで対応します。たとえば、複数のアベイラビリティゾーンに分散した設計や、障害時のフェイルオーバー手順の整備が有効です。したがって、全体の耐障害性は両者の協力で高まります。
実践チェックリスト
- 責任分担の文書化、有効なIAMポリシー、暗号化とバックアップ、パッチ運用、ログ監視、インシデント演習。
これらを順に整備することで、責任共有モデルを生かした安全で強靭なクラウド運用を実現できます。
