クラウドセキュリティの責任共有モデルとは？AWSとAzureの責任範囲をオンプレ経験者向けに徹底解説

クラウドに移行するとき、「セキュリティは誰が責任を持つのか」という疑問を持った方は多いはずです。オンプレミス環境では、物理サーバーからOS、アプリケーションまですべてを自社で管理していました。しかしクラウドでは、クラウドベンダーと利用者の間で責任が明確に分担されます。

この記事では、クラウドセキュリティの基本概念である「責任共有モデル（Shared Responsibility Model）」について、AWSとAzureそれぞれの責任範囲、オンプレとの比較、そして実務でどう活かすべきかを現場目線で解説します。

責任共有モデルとは何か？オンプレとの根本的な違い
AWSの責任共有モデル：サービスタイプ別の責任範囲
Azureの責任共有モデル：AWSとの違いと共通点
責任共有モデルでよくある誤解と落とし穴
責任共有モデルを実務に活かすセキュリティチェックリスト
AWSとAzureのセキュリティサービス対応表
よくある質問（FAQ）
本記事のまとめ
1. クラウドセキュリティの設定、本当に大丈夫ですか？

責任共有モデルとは何か？オンプレとの根本的な違い

オンプレミス時代は、物理サーバーの故障対応からOS・ミドルウェアのパッチ適用、ネットワーク設備の管理まで、インフラに関するセキュリティはすべて自社の責任でした。社内に専任のインフラチームがいない限り、セキュリティ対応が後回しになることも珍しくありませんでした。

クラウドではこの責任が「クラウドプロバイダーが責任を持つ部分」と「利用者が責任を持つ部分」に明確に分割されます。これを責任共有モデル（Shared Responsibility Model）と呼びます。

・クラウド側の責任（Security OF the Cloud）: 物理データセンター、物理ネットワーク、ホストOS、仮想化基盤などのインフラ部分
・利用者側の責任（Security IN the Cloud）: ゲストOS、アプリケーション、データ、IAM設定、ネットワーク設定など

「クラウドにするとセキュリティが強化される」と聞いたことがあるかもしれませんが、それはクラウド側が物理層をプロが管理してくれるという意味です。データや設定の安全性は引き続き利用者の責任であることに変わりはありません。

この区別を理解していないまま運用を続けると、「クラウドに上げたから大丈夫」という思い込みが情報漏洩事故の遠因になります。

AWSの責任共有モデル：サービスタイプ別の責任範囲

AWSの責任共有モデルは、利用するサービスの種類（IaaS・PaaS・SaaS）によって責任範囲が変わるのが特徴です。

1. IaaS（Amazon EC2）の場合

EC2のような仮想マシンを使う場合、AWSが管理するのは物理ホストまでです。

レイヤー	AWSの責任	利用者の責任
物理インフラ	○（データセンター・電源・物理NW）	×
仮想化基盤	○（ハイパーバイザー）	×
ゲストOS	×	○（OS選定・パッチ適用・ユーザー管理）
ミドルウェア	×	○（Apache・Nginxなどの設定・更新）
アプリケーション	×	○（脆弱性対応・認証設計）
データ	×	○（暗号化・アクセス制御・バックアップ）
IAM設定	×	○（権限設計・MFA設定）
ネットワーク設定	×	○（VPC・セキュリティグループ・NACL）

オンプレと比較すると、物理・仮想化層をAWSが担うことで、インフラチームの運用負担が大幅に減ります。しかしゲストOS以上の管理は変わらず自社の責任です。「Windowsのパッチを当てるのを忘れていた」という事故は、クラウドでも起きます。

2. PaaS（Amazon RDS）の場合

Amazon RDSのようなマネージドサービスを使うと、OSやデータベースエンジンのパッチ適用もAWSが担当します。

レイヤー	AWSの責任	利用者の責任
物理〜仮想化基盤	○	×
OSパッチ適用	○	×
DBエンジン更新	○（マイナーバージョン自動更新も可）	×
DBのアクセス制御	×	○（ユーザー管理・権限設定）
データ暗号化	△（KMSキーを提供）	○（暗号化の有効化はユーザー操作）
バックアップ設定	△（機能は提供）	○（保持期間・自動バックアップ有効化）

マネージドサービスを使うほど利用者の運用負荷は下がります。ただし「AWSが全部やってくれる」と誤解すると、データ暗号化や適切なバックアップ設定を怠るリスクがあります。実際にRDSでバックアップ保持期間をデフォルトの1日のまま運用していて、障害時に7日前のデータしか戻せなかったという話はよく聞きます。

3. SaaS（Amazon WorkMailなど）の場合

SaaSの場合、クラウド側の責任範囲がさらに広がります。インフラからアプリケーションまで大部分をプロバイダーが管理し、利用者はデータとユーザー管理のみを担当します。「誰にアクセス権を与えるか」という判断は、どのサービス形態でも常に利用者側の責任です。

Azureの責任共有モデル：AWSとの違いと共通点

Azureも基本的な考え方はAWSと同じです。ただしMicrosoftは公式ドキュメントで「共有（Shared）」という概念を明示しており、責任の境界がよりきめ細かく定義されています。

責任レイヤー	オンプレ	IaaS (Azure VM)	PaaS (Azure SQL)	SaaS (Microsoft 365等)
情報・データ	自社	自社	自社	自社
デバイス管理	自社	自社	自社	自社
ID・アクセス管理	自社	自社	自社	共有
アプリケーション	自社	自社	共有	Microsoft
ネットワーク制御	自社	自社	共有	Microsoft
OS	自社	自社	Microsoft	Microsoft
物理インフラ	自社	Microsoft	Microsoft	Microsoft

注目すべきはAzureが「共有（Shared）」という概念を明示している点です。ID・アクセス管理はSaaSでも「共有」とされており、エンドユーザーのアカウント管理は引き続き利用者側の責任であることが強調されています。

Azureでは Microsoft Entra ID（旧Azure Active Directory）を使ったID管理が責任分界の核心になります。シングルサインオン、条件付きアクセス、多要素認証の設定は利用者側でコントロールする必要があります。

クラウド上のLinuxサーバーの具体的な設定については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。

責任共有モデルでよくある誤解と落とし穴

現場のエンジニアがよくやってしまう誤解を4つ挙げます。

1. 「クラウドは安全だからデフォルト設定でいい」

AWSやAzureは多くの設定がデフォルトでオープンになっています。特にS3バケットのパブリックアクセス設定やEC2のセキュリティグループは「全許可」が初期値になっているケースがあり、意図せずデータを公開してしまう事故が多発しています。

「クラウドが安全」なのはインフラ層だけの話です。設定ミスによる情報漏洩は利用者の責任です。

2. 「バックアップはAWSが自動でやってくれる」

EC2のEBSスナップショットやRDSの自動バックアップは、利用者が設定を有効にして初めて機能します。何も設定しないとバックアップは取られません。特にEC2はデフォルトではスナップショットが一切作成されません。

3. 「IAMはとりあえずAdministratorAccess付けておけばいい」

開発を急ぐあまりフルアクセスの権限を付けたまま放置するケースがあります。最小権限の原則（Least Privilege）を守らないと、アカウント侵害時に被害が最大化します。AWSの侵害事例の多くがIAMの設定ミスに起因しています。

4. 「マルチAZにすればセキュリティも上がる」

マルチAZは可用性（障害時に復旧できる）を高める設計であり、セキュリティとは別の概念です。暗号化していないデータはマルチAZにしても漏洩リスクは下がりません。可用性とセキュリティは別のレイヤーで考える必要があります。

責任共有モデルを実務に活かすセキュリティチェックリスト

クラウド移行・新規構築時に確認すべき項目を整理しました。「利用者の責任」を果たしているかの確認に使ってください。

IAM設定

・rootアカウントのMFAを有効化しているか
・IAMユーザーにMFAを強制しているか
・AdministratorAccess付与が最小限になっているか
・不要なIAMユーザー・アクセスキーを削除しているか
・IAMロールを使ってEC2等からAWSリソースにアクセスしているか（アクセスキーの直書き禁止）

データ保護

・S3バケットのパブリックアクセスをブロックしているか
・EBS・RDSの暗号化を有効化しているか
・データのバックアップ設定（保持期間・自動取得）を確認しているか
・S3バケットポリシーで意図しないアクセスを許可していないか

ネットワーク

・セキュリティグループで不要なポートを閉じているか
・0.0.0.0/0（全許可）のインバウンドルールがないか確認しているか
・VPCのフローログを有効化しているか
・プライベートサブネットに配置すべきリソースが誤ってパブリックサブネットに置かれていないか

監査・ログ

・AWS CloudTrailでAPI呼び出しを記録しているか（Azureは診断設定）
・CloudWatch・Azure Monitorでアラートを設定しているか
・ログの保持期間を適切に設定しているか
・rootアカウントのログイン・重要な権限変更の通知を受け取っているか

AWSとAzureのセキュリティサービス対応表

「利用者側の責任」を果たすために使うサービスの対応表です。自社環境に何が必要かの整理に活用してください。

セキュリティ機能	AWSサービス	Azureサービス
ID・アクセス管理	AWS IAM	Microsoft Entra ID
シークレット・キー管理	AWS Secrets Manager / AWS KMS	Azure Key Vault
Webアプリ保護	AWS WAF	Azure WAF
DDoS対策	AWS Shield	Azure DDoS Protection
脅威検知	Amazon GuardDuty	Microsoft Defender for Cloud
脆弱性スキャン	Amazon Inspector	Microsoft Defender for Cloud
セキュリティ一元管理	AWS Security Hub	Microsoft Defender for Cloud
APIログ・監査	AWS CloudTrail	Azure Activity Log
設定変更追跡・コンプライアンス	AWS Config	Azure Policy
S3データ分類・保護	Amazon Macie	Microsoft Purview

よくある質問（FAQ）

Q. 責任共有モデルはAWSとAzureで大きく違いますか？

基本的な考え方は同じです。「クラウドの安全」はプロバイダーが担保し、「クラウドを使う側の安全」は利用者が担保するという分担は共通しています。AzureはMicrosoftのエンタープライズ向け製品との統合が強く、Microsoft Entra IDやDefender for Cloudが責任共有の「利用者側」を補完するツールとして機能する場面が多いです。

Q. 責任共有モデルは資格試験に出ますか？

はい。AWS CLF（クラウドプラクティショナー）やAWS SAA（ソリューションアーキテクト）、Azure AZ-900の試験で必ず出題されます。特にCLFでは「この設定はAWSの責任か利用者の責任か」という形式で問われます。「Security OF the Cloud」「Security IN the Cloud」のフレーズを覚えておくと解答しやすくなります。

Q. 責任共有モデルを社内に説明するよい方法はありますか？

「マンション vs 一戸建て」の比較が伝わりやすいです。一戸建て（オンプレ）は建物から設備まで全部オーナーが管理します。マンション（クラウド）は建物・共用部分は管理会社が管理しますが、部屋の鍵の管理や内装は入居者の責任です。「鍵をかけ忘れたのは管理会社のせいではない」という点が特に伝わりやすいです。

Q. PCI DSSやISO 27001などのコンプライアンス対応に責任共有モデルはどう関係しますか？

AWSやAzureは主要な認定・コンプライアンスを自社インフラ部分で取得しています。しかし利用者側の設定・運用が適切でなければコンプライアンス要件を満たせません。責任共有モデルを理解した上で、利用者側でどのセキュリティコントロールを実装するかを明確にする必要があります。AWS Artifact（コンプライアンスレポートのダウンロード）やAzure Trust Centerが参考になります。

Q. オンプレからクラウドに移行する際、最初に確認すべきセキュリティ設定は何ですか？

まずIAMのrootアカウントMFAとAWS CloudTrail（監査ログ）の有効化を最優先にしてください。この2つを設定していない状態で運用を始めると、万が一の侵害時に何が起きたかを追跡できません。次にVPCのセキュリティグループで不要なポートを閉じ、S3のパブリックアクセスブロックを確認する順序が実務的です。

本記事のまとめ

責任共有モデルの要点を整理します。

・クラウドが守るのはインフラ層: 物理設備・仮想化基盤はクラウドベンダーの責任
・利用者が守るのはデータと設定層: OS・アプリ・データ・IAM・ネットワーク設定は引き続き利用者の責任
・IaaS→PaaS→SaaSの順で利用者の責任範囲は小さくなる: マネージドサービスを使うほど運用負荷は下がる
・「クラウドは安全」の誤解が最大のリスク: 設定ミスによる情報漏洩は利用者の責任
・実務チェックリストを定期的に回す: IAM・データ保護・ネットワーク・監査ログの4分野が基本

オンプレ時代に身につけた「全部自分たちで管理する」という感覚をアップデートし、クラウドとの責任分界点を正確に理解することが、安全なクラウド運用の第一歩です。