Day16: 責任共有モデル：クラウドにおけるセキュリティの責任範囲
皆さん、こんにちは。エンジニアのAkrです。
「徹底比較！ AWS vs Azure」シリーズ、Day16へようこそ。
今回は、Day13やDay14でも触れてきた**「責任共有モデル」**について、より深く掘り下げます。このモデルは、クラウドを利用する上で最も重要なセキュリティの概念であり、これを正しく理解しないと、思わぬセキュリティ事故につながる可能性があります。
責任共有モデルの基本原則
責任共有モデルは、クラウドセキュリティを「クラウド事業者側の責任範囲」と「利用者側の責任範囲」に明確に分割する考え方です。
クラウド事業者の責任（Security "of" the Cloud）
クラウドそのものの基盤セキュリティを担当します。
- 物理的セキュリティ: データセンターの建物保護、入退室管理、監視システム
- ハードウェア: サーバー、ストレージ、ネットワーク機器の物理的保護
- 仮想化基盤: ハイパーバイザーのセキュリティとパッチ管理
- ネットワークインフラ: 基盤ネットワークの分離と保護
- ホストOS: 物理サーバー上で動作するホストOSの管理
これらはAWSやAzureが厳格に管理・保護する領域であり、利用者は関与できません。
利用者の責任（Security "in" the Cloud）
クラウド上で構築するシステムやアプリケーションのセキュリティを担当します。
- ID・アクセス管理: IAM/Azure ADでのユーザー管理と権限設定
- ネットワーク設定: VPC/VNetの設計とファイアウォール設定
- ゲストOS: 仮想マシンのOS管理とパッチ適用
- アプリケーション: アプリケーションのセキュリティ設定と脆弱性対策
- データ: データの分類、暗号化、アクセス制御
これらは利用者が責任を持って設定・管理する領域です。
分かりやすい例え
このモデルは、マンション管理に例えると理解しやすいでしょう。
- 管理会社（クラウド事業者）: 建物の構造安全性、共用部分のセキュリティ、設備の保守を担当
- 入居者（利用者）: 自分の部屋の鍵管理、貴重品の保管、室内のセキュリティ対策を担当
サービスモデルごとの責任範囲
責任共有モデルは、IaaS、PaaS、SaaSというクラウドのサービスモデルによって、利用者と事業者の責任分担が大きく変わります。
| 要素 | IaaS（EC2/VM） | PaaS（App Service/Lambda） | SaaS（Microsoft 365） |
|---|---|---|---|
| データ | 🔴 利用者 | 🔴 利用者 | 🔴 利用者 |
| ID・アクセス管理 | 🔴 利用者 | 🔴 利用者 | 🔴 利用者 |
| アプリケーション | 🔴 利用者 | 🔴 利用者 | 🔵 事業者 |
| ゲストOS | 🔴 利用者 | 🔵 事業者 | 🔵 事業者 |
| ネットワーク制御 | 🟡 共有 | 🟡 共有 | 🔵 事業者 |
| ホストOS | 🔵 事業者 | 🔵 事業者 | 🔵 事業者 |
| 仮想化基盤 | 🔵 事業者 | 🔵 事業者 | 🔵 事業者 |
| 物理インフラ | 🔵 事業者 | 🔵 事業者 | 🔵 事業者 |
凡例: 🔴 利用者責任 / 🔵 事業者責任 / 🟡 共有責任
各サービスモデルの特徴
| サービスモデル | 代表例 | 主な特徴 | 利用者の主な責任 | 注意点 |
|---|---|---|---|---|
|
IaaS （Infrastructure as a Service） |
Amazon EC2 Azure Virtual Machines |
最も柔軟性が高い インフラの完全制御が可能 |
OS管理、パッチ適用 ウイルス対策 ファイアウォール設定 アプリケーション全般 |
責任範囲が最大 専門知識が必要 運用負荷が高い |
|
PaaS （Platform as a Service） |
AWS Lambda Azure App Service Amazon RDS |
開発に集中可能 運用負荷の軽減 |
アプリケーション設定 データ管理 ID・アクセス制御 |
プラットフォーム制約あり ベンダーロックインリスク |
|
SaaS （Software as a Service） |
Microsoft 365 Salesforce Google Workspace |
すぐに利用開始可能 運用負荷が最小 |
ユーザー管理 データ分類・保護 アクセス権限設定 |
カスタマイズ性が限定的 データ移行の困難さ |
AWSとAzureの責任共有モデル比較
| 観点 | AWS | Azure |
|---|---|---|
| 責任範囲の明確性 | AWS責任共有モデル図で詳細に図解。サービス別の責任分担も明確 | Azure責任共有モデルで包括的に説明。Microsoft 365との統合観点も提供 |
| 責任支援ツール |
AWS Config: リソース設定の監視 AWS Systems Manager: パッチ管理 AWS Inspector: 脆弱性評価 |
Azure Policy: ガバナンス強制 Azure Update Management: パッチ管理 Microsoft Defender for Cloud: 統合セキュリティ管理 |
| 教育・ドキュメント | Well-Architected Frameworkでセキュリティピラーを詳細解説 | Azure Architecture Centerでセキュリティのベストプラクティスを体系化 |
| コンプライアンス連携 | AWS Artifactでコンプライアンス認証情報を提供 | Service Trust Portalでコンプライアンス情報を一元管理 |
責任範囲を誤解した場合の典型的なリスク
1. 設定ミスによるデータ漏洩
シナリオ: S3バケットやBlob Storageのアクセス権限を誤って公開設定にし、意図せず機密データがインターネットに晒される。
対策例:
// AWS S3 - パブリックアクセスブロック設定
{
"BlockPublicAcls": true,
"IgnorePublicAcls": true,
"BlockPublicPolicy": true,
"RestrictPublicBuckets": true
}
2. 権限管理の不備
シナリオ: 最小特権の原則を無視し、広範な権限を持つアカウントの認証情報が漏洩することで、リソースが不正に操作される。
対策: IAMポリシー/Azure ADロールの定期的な棚卸しと権限の最小化
3. OS・アプリケーションレベルの脆弱性
シナリオ: IaaSにおいて、VMのOSやアプリケーションのパッチ適用を怠り、攻撃の標的となる。
対策:
- AWS: Systems Manager Patch Managerでの自動パッチ適用
- Azure: Update Managementでの一元的なパッチ管理
4. ネットワーク設定の不備
シナリオ: セキュリティグループやNSGの設定が不適切で、意図しない通信が許可される。
対策: 必要最小限の通信のみを許可する「デフォルト拒否」の原則
実践的な責任分担の実装
チェックリストの活用
各サービスモデルに応じたセキュリティチェックリストを作成し、定期的に確認しましょう。
IaaSのセキュリティチェックリスト
- OSのセキュリティパッチは最新か
- 不要なサービスやポートは無効化されているか
- ウイルス対策ソフトウェアは導入・更新されているか
- ログ監視とアラート設定は適切か
- バックアップと復旧手順は確立されているか
PaaSのセキュリティチェックリスト
- アプリケーションの脆弱性診断は実施されているか
- API認証とアクセス制御は適切か
- 機密データの暗号化は実装されているか
- ログとモニタリングは設定されているか
継続的な改善プロセス
- 定期的な責任範囲の見直し（四半期ごと）
- 新サービス導入時の責任分担確認
- インシデント発生時の責任範囲分析
- チーム内での責任共有モデル教育
責任範囲を明確にするためのベストプラクティス
文書化の重要性
- 責任分担表（RACI表） の作成
- セキュリティポリシーの策定と共有
- インシデント対応手順書の整備
技術的な境界の明確化
- タグ付け戦略によるリソース管理
- アクセス制御の階層化
- 監査ログの包括的な設定
組織的な体制
- セキュリティ責任者の明確な指名
- 定期的な教育・訓練の実施
- 外部監査による客観的評価
まとめ
責任共有モデルは、クラウドセキュリティの基礎となる最重要概念です。AWSとAzureは、どちらも強固な「クラウドそのもの」のセキュリティを提供していますが、その上で安全なシステムを構築するのは利用者の責任です。
重要なポイントは以下の通りです：
- サービスモデル（IaaS/PaaS/SaaS）によって責任分担が変わることを理解する
- 利用者責任範囲のセキュリティ対策を怠らない
- 継続的な監視と改善を実施する
- チーム全体で責任共有モデルの理解を共有する
クラウドの恩恵を最大限に活用しながら、セキュリティリスクを最小限に抑えるためには、この責任共有モデルの正しい理解と実践が不可欠です。
次回のDay17では、CI/CDツールに焦点を当て、AWSのCodeシリーズとAzure DevOpsを徹底比較します。お楽しみに！
参考資料