securing-s3-buckets

Overview

アクセス制御、暗号化、監視、設定ミスの修復に関する5つのワークフローを通じて、階層化されたS3セキュリティコントロールを実装します。AWS Well-Architectedセキュリティベストプラクティスに従います。

AWS MCPサーバーが接続されている場合はそれを使用してコマンドを実行し(サンドボックス実行、監査ログ、可観測性)、接続されていない場合はAWS CLIまたはシェルにフォールバックします。

Common Tasks

0. 依存関係の検証

開始する前に必要なツールを確認してください。

Constraints:

• 必要なツールが不足している場合、ユーザーに通知する必要があります
• aws sts get-caller-identityで認証情報を確認する必要があります

IAM権限の詳細についてはreferences/iam-permissions.mdを参照してください。

1. リクエストの分類

ユーザーの意図	ワークフロー
新しいバケットをセキュアにする	A: 新しいバケットのセキュア化
既存のバケットを監査/レビューする	B: 既存バケットの監査
特定の検出結果を修正する	C: 問題の修復
暗号化を設定する	D: 暗号化の設定
ロギング/監視を有効にする	E: 監視の有効化

Constraints:

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

put-bucket-policy セーフティルール

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

• 既存のポリシーを最初に取得する必要があります(aws s3api get-bucket-policy) — put-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を有効化

Constraints:

• create-bucket呼び出しで--bucket-namespace account-regionalを渡す必要があります — これはオプションではなく必須です。例:

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

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

• ACLの所有権コントロールを変更してはいけません — S3はデフォルトでACL(BucketOwnerEnforced)を無効にします

• 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を参照してください。

Constraints:

• 検出結果を報告する前に、すべての読み取り専用監査コマンドを実行する必要があります
• 監査中に書き込みや変更コマンドを実行してはいけません
• 各コントロールをPASS/FAIL/NOT CONFIGUREDで重大度付きで報告する必要があります
• ロギングについて: S3サーバーアクセスロギングまたはCloudTrailデータイベントのいずれかが有効な場合はPASSを報告; 両方が無効な場合のみNOT CONFIGUREDを報告します

4. ワークフロー C — 問題の修復

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

Constraints:

• 修正を適用する前に問題タイプを特定する必要があります
• ポリシーを修正する際はput-bucket-policyセーフティルールに従う必要があります
• 修正を適用した後、関連する監査チェックを再実行して解決を確認する必要があります

5. ワークフロー D — 暗号化の設定

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

Constraints:

• ユーザーが明示的にKMSをリクエストしない限り、SSE-S3 with S3 Bucket Keys and 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を参照してください。

Constraints:

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

トラブルシューティング

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

監査コマンドの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 Security Best Practices
• AWS Well-Architected Security Pillar