AWS 設定ミス - AWS でよくある設定ミス・ヌケモレ

AWS で最も頻繁に発生するのが、Security Group・NACL・VPC 構成における境界のヌケモレである。

SSH/RDP を全世界に開けてしまうパターンは AWS Trusted Advisor の「Security Groups - Specific Ports Unrestricted」チェックでも常に上位に挙がる典型ミスで、数時間で Botnet によるブルートフォース試行が始まる。

ミスの種類	典型例	危険度	主な検知手段
全開の SSH/RDP	0.0.0.0/0:22, 0.0.0.0/0:3389 で解放	高	AWS Config ルール restricted-ssh, restricted-common-ports / Trusted Advisor
RDS/ElastiCache の Public 配置	Public Subnet にデータベースを配置しさらに Public IP 有効	高	Security Hub AWS Foundational Best Practices RDS.2
ALB/NLB のリスナー証明書期限切れ	ACM の自動更新が失敗したまま放置	中	ACM + CloudWatch Events / EventBridge
VPC エンドポイント未使用	S3/DynamoDB へのアクセスが NAT Gateway 経由でインターネットに出る	中	VPC Flow Logs で異常な NAT 利用を検知
egress ルール放置	Security Group の Outbound がデフォルト全許可のまま	中	AWS Config 独自ルール / CSPM

発見に使う主な仕組みは次の 3 種類である。

• AWS Config + マネージドルール: restricted-ssh, vpc-sg-open-only-to-authorized-ports 等の既成ルールで継続監視
• AWS Security Hub: CIS AWS Benchmark / AWS Foundational Best Practices を横断チェック
• Trusted Advisor: Business 以上のサポート契約があれば Security カテゴリで自動警告

S3・EBS・RDS・スナップショットの公開事故は毎年繰り返されている。

Accenture が 2017 年に S3 バケット 4 個を誤って公開し認証情報とマスターキーを露出させた事件、Capital One が 2019 年に SSRF と過剰な IAM 権限の組み合わせで 1 億件以上の顧客データを漏洩させた事件は代表例で、いずれも「単独では軽微に見える設定ミスの積み重ね」が巨大インシデントに直結した。

ミスの種類	典型例	参考事件	対応する予防策
S3 Public Access Block 未設定	アカウントレベル/バケットレベルの 4 フラグが未有効	Accenture 2017, FedEx 2018	S3 Block Public Access を SCP で強制
Bucket Policy の Principal: *	本来 CloudFront OAC のみに限定すべき箇所を全公開	多数の医療/公的機関 S3 漏洩	IAM Access Analyzer で外部公開検知
EBS/RDS/S3 の暗号化未有効	既定の暗号化を設定せず作成した古いボリューム	HIPAA/PCI-DSS 不適合要因	アカウント既定の EBS 暗号化 ON
スナップショットの Public 共有	RDS スナップショットや AMI を誤って Public に設定	過去多数の DB スナップショット漏洩	AWS Config ルール rds-snapshots-public-prohibited
KMS キーポリシーの過剰許可	kms:* を幅広く許可し鍵管理を無効化	Capital One 周辺で類似の過剰権限	CloudTrail で kms:Decrypt を継続監査

Capital One 2019 年事件のメカニズム（簡略化）:

1. WAF (ModSecurity) の SSRF 対策不備により、攻撃者が EC2 からメタデータサービス（IMDSv1）に到達
2. EC2 にアタッチされたロールに s3:ListBucket, s3:GetObject が広く付与されていた
3. その一時クレデンシャルで S3 から 1 億件超のデータをダウンロード

つまり「SSRF + IMDSv1 + 過剰 IAM」という 3 つのヌケモレが直列でつながった結果の事故である。

長期クレデンシャルとメタデータサービスの扱いは、AWS で最も攻撃価値の高い領域である。

GitHub には毎日数千件規模で AWS Access Key が誤コミットされており、自動クローラーによって数分で悪用される（GuardDuty の UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration が検知するのもこのパターン）。

ミスの種類	典型例	影響	検知/予防
Access Key の Git コミット	.env や config.json にベタ書きしてそのまま push	数分で悪用され EC2 マイニングや S3 流出	truffleHog / gitleaks / GitHub Secret Scanning
IMDSv1 の有効化	古い AMI/起動テンプレートのまま IMDSv2 未強制	SSRF と組み合わせて一時クレデンシャル窃取（Capital One 型）	ec2-imdsv2-check Config ルール / 起動テンプレートで HttpTokens=required
IAM ユーザーへの長期キー発行	CI/CD やアプリ用にアクセスキーを発行し失効させない	退職者・旧プロジェクトのキーが残存	IAM Credential Report で 90 日超の未使用キーを棚卸し
ルートユーザーでの日常操作	マネジメントコンソールに root で直接ログイン	MFA 突破されるとアカウント全権喪失	CloudTrail の userIdentity.type = Root を即アラート
MFA 未設定の特権ユーザー	Administrator 相当に MFA を課していない	フィッシング 1 回で全権奪取	IAM Access Analyzer / Security Hub IAM.6

特に IMDSv1 から IMDSv2 への強制移行 は、新規アカウントでは必ず最初に設定すべき項目である。

アカウント全体での IMDSv2 強制は 2024 年以降の新規起動に対して段階的にデフォルト化されているが、既存環境では明示的な対応が必要になる。

侵入を防げなかった場合でも、ログと監査が整っていれば被害範囲の特定と封じ込めは可能になる。

逆に CloudTrail が無効、あるいは単一リージョンのみ有効な環境では、攻撃者が未監視リージョンを選んで活動するため、フォレンジックが事実上不可能になる。

ミスの種類	典型例	推奨設定
CloudTrail 無効 / 部分有効	単一リージョンのみ有効、マルチリージョン Trail 未作成	Organization Trail でマルチリージョン + 全アカウント収集
ログバケット削除防止なし	CloudTrail 用 S3 に MFA Delete / Object Lock 未設定	S3 Object Lock (Compliance mode) で改ざん防止
GuardDuty 無効	全リージョンでの有効化漏れ	Organizations で委任管理者経由の一括有効化
VPC Flow Logs 未取得	通信経路の証跡が残らない	サブネット/VPC 単位で全採取し CloudWatch Logs へ
ログ保管期間不足	7 日で消える設定のまま	最低 1 年以上（PCI-DSS は 1 年）、業種により 3 年以上
Config Recorder 未有効	リソース変更履歴が残らない	全リージョンで Config Recorder を有効化

ログ設計の原則: 「ログは書き込み専用、削除不可、別アカウント保管」を基本にする。

侵入時に攻撃者が最初に狙うのはログバケットの消去であるため、ログ保管用の AWS アカウントを本番アカウントと分離し、クロスアカウントで書き込むのが標準的な設計である。