AWS Security
AWSのセキュリティ設計とチェックポイント
AWSはサービス数が多く、デフォルト設定のまま使うとセキュリティ上の穴が生まれやすいプラットフォームです。このページでは、IAM・EC2/Security Group・S3・CloudTrail・GuardDuty・KMSという、AWSアカウントを運用する上で最低限押さえるべき主要サービスと、それぞれで確認すべきセキュリティコントロールを整理します。
Shared Responsibility (recap)
AWSの責任共有モデル(要点)
AWSはShared Responsibility Modelのもと、データセンターやハードウェア、仮想化基盤など「クラウドそのもののセキュリティ」を担いますが、IAMポリシーの設計、S3バケットの公開設定、Security Groupのルール、暗号化の有効化といった「クラウド内のセキュリティ」は利用者側の責任です。このページで扱うチェックポイントは、すべて利用者側が構成・運用するレイヤーに属します。モデル全体の詳しい説明はCloud Security Fundamentalsを参照してください。
Core Services & Security Controls
主要サービスとセキュリティコントロール
| サービス | カテゴリ | 確認すべきセキュリティコントロール |
|---|---|---|
| IAM | Identity | 最小権限ポリシーの設計、IAM Access Analyzerによる未使用権限の検出 |
| EC2 / Security Groups | Network | SSH(22)やRDP(3389)など機密性の高いポートに0.0.0.0/0を許可していないか |
| S3 | Storage | Block Public Accessがアカウント/バケット単位で有効化されているか |
| CloudTrail | Logging | マルチリージョン証跡が有効で、ログファイル検証が設定されているか |
| GuardDuty | Detection | 全アカウント・全リージョンで有効化され、Organizationsで一元管理されているか |
| KMS | Encryption | 機密データに対してAWS管理キーではなくカスタマー管理キー(CMK)を使用しているか |
Common Misconfigurations
よくある設定ミス
-
S3バケットのBlock Public Access未設定 High Risk
バケット単位でBlock Public Accessが無効なまま作成され、意図せず外部から読み書き可能になる。
-
Security Groupの過剰開放 High Risk
SSH/RDP/DBポートに
0.0.0.0/0を許可したまま本番運用され、インターネット全体からの接続を許してしまう。 -
GuardDutyの未有効化・一部アカウントのみ有効 Medium Risk
Organizationsに新しく追加したアカウントでGuardDutyが自動有効化されず、検知の空白が生まれる。
-
IAMポリシーのワイルドカード許可 High Risk
"Action": "*", "Resource": "*"のような広範なポリシーが検証用として作られたまま本番に残る。
bash
aws s3api get-public-access-block --bucket <bucket-name>
bash
aws ec2 describe-security-groups --filters Name=ip-permission.cidr,Values=0.0.0.0/0
bash
aws guardduty list-detectors --region ap-northeast-1
bash
aws accessanalyzer list-findings --analyzer-arn <analyzer-arn>
Where to go deeper