securing-s3-buckets

概要

5 つのワークフローにわたって、S3 の多層セキュリティ制御を実装します。対象となるのは、新しいバケットの保護、既存の設定の監査、検出事項の修正、暗号化の設定、モニタリングの有効化です。AWS Well-Architected のセキュリティに関するベストプラクティスに従います。

接続時は AWS MCP サーバーを使用してコマンドを実行します（サンドボックス化された実行、監査ログ記録、オブザーバビリティ）。それ以外の場合は、AWS CLI またはシェルを使用します。

共通タスク

0. 依存関係の確認

開始前に必要なツールを確認します。

制約：

• 必要なツールが不足している場合は、必ずユーザーに伝えてください
• aws sts get-caller-identity を使用して認証情報を確認してください

ワークフローごとの IAM 権限については、references/iam-permissions.md を参照してください。

1. リクエストの分類

ユーザーの意図	ワークフロー
新しいバケットを保護する	A：新しいバケットの保護
既存のバケットを監査／レビューする	B：既存のバケットの監査
特定の検出事項を修正する	C：問題の修正
暗号化を設定する	D：暗号化の設定
ロギング／モニタリングを有効にする	E：モニタリングの有効化

制約：

• 必要なパラメーターはすべて、事前に必ず確認してください
• 書き込み操作の前に、必ずバケット名とリージョンを確認してください
• ユーザーのコンテキストでリージョンが明確に示されている場合は、そのリージョンを推測してもかまいません
• 書き込み操作の前に、aws iam simulate-principal-policy を実行して権限を検証してください
• 書き込みコマンドを表示して、実行前に確認を待つことを推奨します

put-bucket-policy の安全ルール

これらのルールは、put-bucket-policy を呼び出すすべてのワークフローに適用されます。

• put-bucket-policy はポリシー全体を置き換えるため、既存のポリシーを必ず先に取得してください（aws s3api get-bucket-policy）
• ポリシーが存在する場合は、変更前に必ずバックアップしてください：aws s3api get-bucket-policy --bucket <name> --output text > backup-policy-$(date +%s).json
• NoSuchBucketPolicy が返された場合は、新しいポリシーを適用してください。バックアップは不要です
• 既存のポリシーがある場合は、新しいステートメントをその Statement 配列に必ずマージしてください
• 適用前に、マージした JSON の構文を必ず検証してください（例：echo '<policy>' | python3 -m json.tool）
• put-bucket-policy のコマンド全体を表示し、実行前に確認を待つことを推奨します

2. ワークフロー A — 新しいバケットの保護

CLI の手順全体については、references/workflows.md を参照してください。

必須手順（順番どおりに実行し、省略しないでください）：

1. --bucket-namespace account-regional を指定してバケットを作成する
2. バージョニングを有効にする
3. 暗号化を有効にする（SSE-S3 + Bucket Keys + SSE-C をブロック）
4. ロギングを有効にする（条件付き。ユーザーにオプションを確認）
5. DenyInsecureTransport バケットポリシーで HTTPS のみを強制する
6. ABAC を有効にする

制約：

• create-bucket の呼び出しでは、必ず --bucket-namespace account-regional を指定してください。これは任意ではなく必須です。例：

  aws s3api create-bucket --bucket <name> --bucket-namespace account-regional --region <region>
  

• 新しいバケットでは S3 が Block Public Access をデフォルトで有効にするため、変更してはいけません

• S3 が ACL をデフォルトで無効にする（BucketOwnerEnforced）ため、ACL の所有権コントロールを変更してはいけません

• aws:SecureTransport が false の場合に s3:* を拒否する DenyInsecureTransport ステートメントを含むバケットポリシーを必ず適用してください。これは任意ではなく必須です。例：

  aws s3api put-bucket-policy --bucket <name> --policy '{"Version":"2012-10-17","Statement":[{"Sid":"DenyInsecureTransport","Effect":"Deny","Principal":"*","Action":"s3:*","Resource":["arn:aws:s3:::<name>/*","arn:aws:s3:::<name>"],"Condition":{"Bool":{"aws:SecureTransport":"false"}}}]}'
  

• 手順 4 の前に、どのロギングオプションを希望するか必ずユーザーに確認してください

• 手順 4 と 5 では、put-bucket-policy の安全ルール に必ず従ってください

• 次の手順に進む前に、各手順が成功したことを確認することを推奨します

3. ワークフロー B — 既存のバケットの監査

チェックリスト全体については、references/audit-checklist.md を参照してください。

制約：

• 検出事項を報告する前に、読み取り専用の監査コマンドをすべて実行してください
• 監査中に書き込みコマンドや変更コマンドを実行してはいけません
• 各コントロールを、重大度とともに PASS／FAIL／NOT CONFIGURED のいずれかで報告してください
• ロギングについては、S3 サーバーアクセスログまたは CloudTrail データイベントのいずれかが有効なら PASS と報告してください。どちらも有効でない場合に限り、NOT CONFIGURED と報告してください

4. ワークフロー C — 問題を修正する

問題の種類別の修正コマンドについては、references/remediation.md を参照してください。

制約：

• 修正を適用する前に、必ず問題の種類を特定してください
• ポリシーを変更する際は、必ず put-bucket-policy の安全ルール に従ってください
• 修正を適用した後、解決を確認するために、必ず該当する監査チェックを再実行してください

5. ワークフロー D — 暗号化を設定する

暗号化オプションとコマンドについては、references/encryption.md を参照してください。

制約：

• ユーザーが明示的に KMS を要求しない限り、デフォルトでは SSE-S3 と S3 Bucket Keys を使用し、SSE-C はブロックしてください
• SSE-KMS を使用する場合は、必ずカスタマーマネージドキーを使用してください。AWS マネージドの aws/s3 キーは絶対に使用しないでください
• カスタマーマネージド KMS キーは、エイリアスではなく完全な ARN で指定してください
• すべての設定に BucketKeyEnabled: true と BlockedEncryptionTypes: [SSE-C] を含めてください
• 注：S3 API は aws/s3 とエイリアスをエラーなしで受け入れます。これらの制約はエージェントによって適用されます。適用後に get-bucket-encryption で確認してください。

6. ワークフロー E — 監視を有効にする

CLI の手順については、references/workflows.md を参照してください。

制約：

• GuardDuty ディテクターを作成する前に、既存のディテクターがあるかどうかを必ず確認してください
• CloudTrail コマンドでは、バケットのリージョンではなく証跡のホームリージョンを使用してください
• AWS Config の推奨される 4 つの主要ルールをすべて有効にすることを推奨します

トラブルシューティング

ObjectLockConfigurationNotFoundError — Object Lock が有効になっていません。失敗ではなく、未設定として扱ってください。

監査コマンドでの AccessDenied — IAM ポリシー、バケットポリシー、Block Public Access、VPC エンドポイントポリシー、SCP/RCP を確認してください。aws iam simulate-principal-policy を使用して診断してください。

put-bucket-policy が既存のステートメントを暗黙に削除する — put-bucket-policy の安全ルール を参照してください。

GuardDuty の BadRequestException: detector already exists — 最初に aws guardduty list-detectors を実行し、結果が空の場合にのみ create-detector を呼び出してください。

CloudTrail の変更が反映されない — バケットのリージョンではなく、--region <trail-home-region> を使用していることを確認してください。aws cloudtrail describe-trails --query 'trailList[*].[Name,HomeRegion]' でホームリージョンを確認できます。

追加リソース

• references/iam-permissions.md — ワークフロー別の IAM 権限
• references/audit-checklist.md — 重要度と合格条件を含む、コントロールごとのチェックリスト
• references/encryption.md — 暗号化オプション、KMS のガイダンス、SSE-C のブロック
• references/remediation.md — よくある検出事項の修正コマンド
• references/workflows.md — ワークフロー A と E の CLI コマンド一式
• AWS S3 セキュリティのベストプラクティス
• AWS Well-Architected セキュリティの柱