【用語解説】AWS責任共有モデルとは？企業側に残る責任をわかりやすく解説

AWSを利用しても、セキュリティや運用に関するすべての責任がAWSへ移るわけではありません。本記事では、AWS責任共有モデルの基本と、企業側に残る管理・判断の範囲を、サービス別の具体例を交えて解説します。

AWSを利用しても、すべての責任がAWSへ移るわけではない

AWSを利用すると、物理サーバーやデータセンターを自社で保有・管理する負担を軽減できます。

一方で、IAMの権限設定、OSやアプリケーションの管理、ネットワーク設定、データ管理など、利用企業側に残る責任もあります。

この責任分担を整理するための考え方が、「AWS責任共有モデル」です。

責任共有モデルを正しく理解していないと、「AWSだから安全」「運用会社へ任せたから自社では対応不要」と考えてしまい、設定不備や対応漏れにつながる可能性があります。

重要なのは、「AWSが担う範囲」「自社で担う範囲」「外部へ委託する範囲」を明確にすることです。

この記事では、AWS責任共有モデルの基本、サービスによる責任範囲の違い、企業側に残る責任、外注時に確認したいポイントを実務視点で解説します。

AWS責任共有モデルとは？

AWS責任共有モデル（AWS Shared Responsibility Model）とは、クラウドのセキュリティと運用に関する責任を、AWSと利用企業で分担する考え方です。

AWSは、AWSクラウドを構成する施設、ハードウェア、ソフトウェア、ネットワークなど、クラウド基盤の保護を担います。

一方、利用企業は、利用するサービスに応じて、アクセス権限、データ、OS、アプリケーション、ネットワーク設定などを管理します。

つまり、AWSを利用することで企業側の運用負荷は軽減できますが、セキュリティや運用の責任がすべてなくなるわけではありません。

AWS側と利用企業側の責任範囲

責任共有モデルを大きく分けると、AWS側と利用企業側の責任は次のように整理できます。

ただし、この表はあくまで全体像です。

企業側が実際に担う責任範囲は、利用するAWSサービスや構成によって異なります。

責任範囲は利用するAWSサービスによって変わる

AWS責任共有モデルで注意したいのは、すべてのAWSサービスで責任範囲が同じではないことです。

一般に、利用企業が管理する範囲の広いサービスほど自由度が高い一方で、設定・保守・セキュリティ対応の負担も大きくなります。

Amazon EC2の場合

Amazon EC2は、仮想サーバーを提供するIaaS型のサービスです。

AWSは物理設備や仮想化基盤を管理しますが、利用企業はゲストOS、セキュリティパッチ、インストールしたアプリケーション、Security Groupなどを管理します。

そのため、EC2を利用する場合は、OSやミドルウェアの更新、脆弱性対応、ネットワーク設定まで含めた運用体制が必要です。

Amazon RDSの場合

Amazon RDSでは、データベース基盤の運用や一部の保守作業をAWSへ任せられるため、EC2上にデータベースを構築する場合よりも企業側の管理負担を軽減できます。

一方で、利用企業には、データベースへのアクセス権限、保存するデータ、暗号化、バックアップ設定、メンテナンスウィンドウや更新方針などを管理する役割が残ります。

Amazon S3の場合

Amazon S3では、AWSが物理基盤、OS、ストレージプラットフォームを管理します。

利用企業は、保存するデータの分類、アクセス権限、公開設定、暗号化方式やKMSキー、ライフサイクルなどを管理します。

S3自体の基盤管理はAWSが担いますが、「誰がデータへアクセスできるか」「外部公開してよいデータか」を判断する責任は利用企業側にあります。

このように、マネージドサービスを利用すれば企業側の作業は減らせますが、データや権限、設定方針に関する責任までなくなるわけではありません。

企業側に残る主な責任

1. IAM・アクセス権限の管理

誰がAWS環境へアクセスできるのか、どの操作を許可するのかは、利用企業側で管理します。

管理者権限の付与、MFAの設定、退職者や異動者のアカウント削除、アクセスキーの管理などが含まれます。

権限は必要以上に広くせず、業務に必要な範囲だけを許可する「最小権限」を基本にします。

IAMの基本については、「IAMとは？AWSの権限管理で押さえたい基本と運用ポイント」も参考にしてください。

2. データの管理

AWS上へどのデータを保存するか、誰にアクセスを許可するか、どのように暗号化するかは企業側で判断します。

個人情報や機密情報を扱う場合は、保存場所、アクセス権限、暗号化、ログ取得、社内規程との整合性まで確認する必要があります。

3. OS・アプリケーションの管理

EC2などを利用する場合、ゲストOSやインストールしたアプリケーションの更新、パッチ適用、脆弱性対応は企業側の責任です。

ただし、利用するマネージドサービスによっては、OSや基盤の管理をAWS側が担います。どこまでAWSへ任せられるかは、サービスごとに確認する必要があります。

4. ネットワークと公開範囲の設定

Security Group、ネットワークACL、パブリックアクセスなどの設定も、企業側で管理します。

一時的に開放したポートや広すぎるアクセス許可がそのまま残ると、セキュリティリスクにつながる可能性があります。

5. ログ監視とインシデント対応

AWS環境の操作履歴を把握するにはCloudTrailを、システムのメトリクスやログを監視するにはCloudWatchを活用します。

記録やログを保存するだけでなく、異常を検知した際に誰が確認し、どこまで対応するかを決めておくことも重要です。

AWSのモニタリングについては、「CloudWatchとは？AWSのモニタリング・ログ分析・アラート機能」で詳しく解説しています。

6. バックアップと復旧方針

バックアップ機能が提供されていても、何を、どの頻度で、どの期間保存するかは企業側で決める必要があります。

また、取得したバックアップから実際に復旧できるか、障害時にどのシステムを優先して復旧するかも整理しておきます。

7. 法令・契約・社内ルールへの対応

AWSをどのように利用するかは、企業に適用される法令、業界基準、顧客との契約、社内規程によっても変わります。

AWSが各種認証や統制を備えていても、自社の利用方法が要件を満たしているかを確認し、説明する責任は企業側にあります。

AWS運用を外注すれば責任も移せるのか

AWSの監視、保守、パッチ適用、バックアップ確認などは、運用支援会社へ委託できます。

ただし、外注したからといって、利用企業側で管理・判断すべき範囲がすべて運用会社へ移るわけではありません。

業務やデータの重要度、セキュリティ方針、予算、障害時の最終判断などは、自社で決める必要があります。

重要なのは、作業を誰が行うかだけでなく、判断・承認・説明を誰が担うかまで明確にすることです。

AWS運用の委託範囲については、「AWS運用はどこまで外注できる？責任分担の考え方」もあわせて確認してください。

責任分担が曖昧なままだと起こりやすい問題

設定変更の担当者が分からない

障害やセキュリティアラートが発生しても、誰が設定を確認・変更するのかが決まっていないと、初動が遅れます。

外注範囲の認識が食い違う

自社では対応範囲だと思っていても、契約上は対象外というケースがあります。監視、通知、復旧、原因調査の範囲を契約前に確認することが重要です。

権限やアカウントが放置される

担当者や委託先が変わった後も、不要なIAMユーザーやアクセスキーが残ることがあります。

障害時の最終判断ができない

技術的な復旧作業を委託していても、業務停止、切り戻し、DRへの切り替えなどの判断は自社に残る場合があります。

企業がAWSの責任分担を整理する5つの手順

1. 利用しているAWSサービスを洗い出す

まずは、EC2、RDS、S3、CloudWatchなど、現在利用しているAWSサービスと用途を整理します。

2. サービスごとの責任範囲を確認する

AWS公式ドキュメントを確認し、AWS側が管理する範囲と、自社で設定・運用する範囲を明確にします。

3. 自社と委託先の担当範囲を決める

監視、通知、設定変更、パッチ適用、バックアップ、障害対応などについて、実作業を誰が担当するか決めます。

4. 判断・承認者を明確にする

作業担当者だけでなく、設定変更や緊急対応を承認する責任者も決めておきます。

5. 定期的に見直す

AWSサービスや構成、担当者、委託契約は変化します。責任分担表を作成し、構成変更や契約更新のタイミングで見直すことが重要です。

よくある質問

AWS責任共有モデルとは何ですか？

AWS責任共有モデルとは、クラウドのセキュリティと運用に関する責任をAWSと利用企業で分担する考え方です。AWSはクラウド基盤を保護し、利用企業は利用するサービスに応じて、データ、権限、OS、アプリケーション、各種設定などを管理します。

AWSを利用すればセキュリティ対策は不要ですか？

不要にはなりません。AWSはクラウド基盤を保護しますが、IAM、データ、ネットワーク設定、ログ、バックアップなどは利用企業側で管理する必要があります。

利用企業の責任はすべてのAWSサービスで同じですか？

同じではありません。EC2のように企業側の管理範囲が広いサービスと、S3などAWS側がより多くの基盤管理を担うサービスでは、企業側に残る作業が異なります。

AWS運用を外注すれば企業側の責任はなくなりますか？

なくなりません。監視や保守などの実作業は委託できますが、データ管理、セキュリティ方針、承認、障害時の最終判断などは企業側に残ります。

責任分担はどのように整理すればよいですか？

利用サービスを洗い出し、AWS側、自社、運用支援会社の担当範囲を整理します。実作業だけでなく、判断・承認・説明の担当者まで決めることが重要です。

まとめ

AWS責任共有モデルとは、AWSと利用企業がクラウドのセキュリティと運用に関する責任を分担する考え方です。

AWSを利用することで物理設備やクラウド基盤の管理負担は軽減できますが、利用企業にはデータ、アクセス権限、各種設定、ログ、バックアップ、法令対応などの責任が残ります。

また、企業側の責任範囲は利用するAWSサービスによって異なります。マネージドサービスを活用すれば作業負担を軽減できますが、管理方針や最終判断までAWSへ任せられるわけではありません。

重要なのは、「AWSが担う範囲」「自社で担う範囲」「外部へ委託する範囲」を明確にし、継続して見直せる体制を作ることです。

参考情報

• AWS「責任共有モデル」
• AWS Well-Architected Framework「責任共有」