AWSセキュリティの全体像と責任共有モデル

AWSセキュリティの設計原則

AWSのWell-Architected Frameworkでは、セキュリティを5つの柱の1つとして位置づけています。クラウド環境では、データ・システム・資産を多層的に保護し、継続的なモニタリングによってセキュリティ体制を強化することが求められます。

設計時に考慮すべき5つの事項

1. 全レイヤーでのセキュリティ対策

ネットワーク境界だけでなく、アプリケーション層、データ層、インフラ層のすべてでセキュリティ機構を配置します。例えば、VPCレベルでのファイアウォール、EC2インスタンスレベルでのセキュリティグループ、アプリケーションレベルでの認証・認可を組み合わせることで、多層防御を実現します。

2. アクセス追跡とモニタリングの確実な実施

すべてのAPI呼び出しをCloudTrailで記録し、CloudWatchでメトリクスを監視します。誰が、いつ、どのリソースにアクセスしたかを追跡可能にすることで、異常なアクティビティを早期に検知できます。

3. 条件ドリブンの自動応答

セキュリティイベントをトリガーとして、Lambda関数やSystems Managerの自動化ドキュメントを起動します。例えば、GuardDutyが脅威を検出したら、自動的に該当インスタンスをネットワークから隔離するといった対応が可能です。

4. 責任共有モデルに基づく保護範囲の明確化

AWSが管理するインフラストラクチャと、ユーザーが管理するゲストOS・アプリケーションの責任境界を理解し、自身の管理範囲に集中します。

5. セキュリティのベストプラクティス自動化

手動での設定ミスを防ぐため、以下を自動化します：

• CloudFormationやTerraformによるインフラストラクチャのコード化
• カスタムAMIを用いた標準化されたサーバーイメージのデプロイ
• AWS Configルールによるコンプライアンスチェックの継続的実行

セキュリティサービスの4領域

AWSのセキュリティサービスは、保護対象と目的によって4つの領域に分類されます。

データ保護領域

転送中および保管中のデータを暗号化し、機密性を保ちます。ELBでTLS終端、EBSボリュームの暗号化、S3バケットのサーバーサイド暗号化、RDSの透過的データ暗号化などを組み合わせます。暗号化キーはKMSで一元管理し、自動ローテーションとアクセス制御を適用します。

権限管理領域

最小権限の原則に基づき、IAMユーザー・ロール・ポリシーで細かくアクセスを制御します。管理者アカウントやルートユーザーには必ずMFAを有効化し、認証情報の漏洩リスクを低減します。

インフラ保護領域

VPCによるネットワークセグメンテーションで、リソースを論理的に分離します。パブリックサブネットとプライベートサブネットを使い分け、インターネットからの直接アクセスが必要なリソースのみをパブリックに配置します。

検出制御領域

CloudTrailですべてのAPI呼び出しを記録し、後から監査可能にします。CloudWatchで異常なメトリクス変動を検知し、アラームを発報します。GuardDutyが機械学習で脅威を自動検出し、Inspectorがインスタンスの脆弱性を継続的にスキャンします。

セキュリティ・コンプライアンス専用サービス

脅威からの保護とコンプライアンス要件への対応のために、専用のマネージドサービスが提供されています。

ファイアウォール・DDoS対策

サービス	保護対象	主な用途
AWS WAF	ALB、CloudFront、API Gateway	SQLインジェクション、XSSなどのアプリケーション層攻撃をブロック
AWS Shield	CloudFront、Route 53	L3/L4のDDoS攻撃を自動緩和（Standard版は無料）
AWS Network Firewall	VPC全体	ステートフルインスペクションとIPS機能でネットワーク層を保護
AWS Firewall Manager	Organizations全体	複数アカウントのファイアウォールルールを一元管理
AWS Security Hub	アカウント全体	セキュリティアラートを集約し、ベストプラクティスチェックを自動実行

暗号化・証明書管理

サービス	管理対象	主な用途
AWS KMS	暗号化キー	データ暗号化キーを生成・管理し、EBS・S3・RDSなどで使用
AWS ACM	SSL/TLS証明書	証明書をプロビジョニングし、ELB・CloudFrontに自動デプロイ
AWS CloudHSM	ハードウェアキー	FIPS 140-2 レベル3準拠のHSMでキーを厳格に管理

脅威検出・脆弱性管理

サービス	検出対象	主な用途
Amazon GuardDuty	悪意のあるアクティビティ	CloudTrail・VPCフローログ・DNSログを機械学習で分析し、脅威を自動検出
Amazon Inspector	ソフトウェア脆弱性	EC2とECRコンテナをスキャンし、CVEデータベースと照合
Amazon Macie	機密データ漏洩	S3バケット内の個人情報をMLで検出し、不正アクセスを監視
Amazon Detective	セキュリティインシデント	CloudTrail・VPCフローログ・GuardDuty結果をグラフ分析し、根本原因を特定

責任共有モデルの理解

AWSでは、セキュリティの責任をAWSとユーザーで分担する「責任共有モデル」が採用されています。この境界線を正しく理解することが、適切なセキュリティ対策の第一歩です。

AWSの責任範囲（Security OF the Cloud）

AWSは物理インフラストラクチャのセキュリティに責任を持ちます：

• 物理的セキュリティ: データセンターへの物理アクセス制御、監視カメラ、生体認証
• ネットワークインフラ: リージョン間接続、AZ間通信、DDoS対策
• ハードウェア・ファシリティ: サーバー、ストレージ、電源、空調システム
• 仮想化基盤: ホストOS、ハイパーバイザー、コンピュートエンジンの管理

これらはAWSの管理下にあり、ユーザーはアクセスできません。

ユーザーの責任範囲（Security IN the Cloud）

ユーザーはクラウド上に構築したシステムのセキュリティに責任を持ちます：

1. アカウント・アクセス管理

• IAMユーザー、グループ、ロールの作成と権限設定
• パスワードポリシーの強化（最小文字数、有効期限、複雑性要件）
• MFAデバイスの有効化

2. ネットワークセキュリティ

• セキュリティグループとネットワークACLの適切な設定
• VPCフローログの有効化と監視
• 不要なポートの閉鎖

3. OS・ミドルウェア

• ゲストOSのパッチ適用（Windows Update、yum update等）
• Apache、Nginx、MySQL等のミドルウェアの脆弱性対応
• 不要なサービスの無効化

4. アプリケーション

• アプリケーションコードの脆弱性診断（SQLインジェクション、XSS対策）
• セッション管理の適切な実装
• 入力値検証とサニタイゼーション

5. データ保護

• 転送中データの暗号化（TLS/SSL）
• 保管中データの暗号化（KMS、CloudHSM）
• バックアップとリストア計画

共有統制の3つの領域

AWSとユーザーの両方が責任を持つ領域があります：

1. パッチ管理

• AWS: ホストOSとハイパーバイザーのパッチ適用
• ユーザー: ゲストOS（Amazon Linux、Windows Server等）とアプリケーションのパッチ適用

例：RDS Auroraでは、DBエンジンのマイナーバージョン更新はAWSが自動適用しますが、メジャーバージョンアップグレードはユーザーが計画的に実施します。

2. 構成管理

• AWS: 物理サーバー、ネットワーク機器の構成管理
• ユーザー: ゲストOSの設定、アプリケーション設定、データベース設定

例：EC2インスタンスのネットワークインターフェース（ENI）の物理的な配線はAWSが管理しますが、OSレベルのネットワーク設定（/etc/sysconfig/network-scripts/）はユーザーが管理します。

3. 意識とトレーニング

• AWS: AWS従業員向けのセキュリティトレーニング
• ユーザー: 自社従業員向けのAWSセキュリティベストプラクティス教育

ユーザー固有の統制

アプリケーションのアーキテクチャに応じて、ユーザーが全責任を負う統制もあります：

• ゾーンセキュリティ: マルチAZ構成でのデータ分散方法
• データのルーティング: どのリージョンにどのデータを配置するかの判断
• データ通信の保護: 顧客が設定するVPN接続やDirect Connect回線のセキュリティ

例：EU一般データ保護規則（GDPR）への対応では、EU市民のデータをEUリージョン内に保管することはユーザーの責任です。AWS Config Rulesで「eu-west-1リージョン外へのS3レプリケーションを禁止」といったポリシーを実装できます。

実務での適用ポイント

設計段階でのチェックリスト

新規システムを設計する際は、以下を確認します：

1. データ分類: 扱うデータの機密度レベル（Public / Internal / Confidential / Restricted）を定義
2. 暗号化要件: PII（個人識別情報）を含む場合は必ずKMSでの暗号化を適用
3. アクセス制御: 最小権限の原則に基づきIAMロールを設計（開発者・運用者・監査者で分離）
4. 監視計画: CloudWatch Alarms、GuardDuty、Security Hubの有効化リージョンを決定
5. コンプライアンス: HIPAA、PCI DSS等の規制要件を確認し、該当する場合はAWS Artifact経由で監査レポートを取得

運用段階での継続的改善

定期的に以下を実施します：

• 四半期ごと: AWS Trusted Advisorのセキュリティチェック結果を確認
• 月次: IAM Access Analyzerで過剰な権限を持つロールを洗い出し
• 週次: GuardDutyとSecurity Hubの検出結果をトリアージ
• 日次: CloudTrailログでルートアカウントの使用がないことを確認

よくある設計ミスと対策

ミス	リスク	対策
ルートアカウントでの日常作業	全権限の誤操作	日常作業はIAMユーザーで実施し、ルートはMFA有効化して金庫保管
セキュリティグループでの0.0.0.0/0許可	全世界からのアクセス	必要最小限のCIDR範囲に制限、またはSecurity Hub自動修復で検出
アクセスキーのコード埋め込み	認証情報漏洩	Systems Manager Parameter StoreまたはSecrets Managerを使用
CloudTrail無効化	監査証跡の喪失	Organizations全体でCloudTrail統合を有効化し、S3バケットへの保存を強制
パブリックサブネットのDB配置	直接攻撃のリスク	RDSは必ずプライベートサブネットに配置し、踏み台経由でアクセス