🔒 AWS Config

S3バケットのパブリックアクセス検出を完全理解
s3-bucket-level-public-access-prohibited

🏠 家のセキュリティで例えると超わかりやすい!

S3バケット = あなたの大切な家

大切なデータ（貴重品）を保管するS3バケット（家）のセキュリティ、
ちゃんと鍵をかけていますか？🔑

AWS Config は24時間365日巡回する セキュリティ警備員 🛡️
s3-bucket-level-public-access-prohibited は
「玄関の鍵」と「窓の鍵」がちゃんとかかっているかチェックするルール！

どこかの鍵が開いていたら アラート🚨 を出してくれます

🏠 家のセキュリティに例えると...

🏡

あなたの家（S3バケット）

🚪 玄関の鍵 = ACL（Access Control List）
「誰が玄関から入れるか」を管理する鍵。
- 家族だけOK → プライベート✅
- 誰でもウェルカム → パブリック❌

🪟 窓の鍵 = バケットポリシー
「誰が窓から入れるか」を管理するルール。
- すべての窓に鍵 → セキュア✅
- 一部の窓が開いてる → 危険❌
👮

警備員（AWS Config）

🛡️ AWS Config = 24時間巡回警備員
定期的にあなたの家（S3バケット）を巡回して、
セキュリティ状態をチェック！

📋 s3-bucket-level-public-access-prohibited
= 「玄関と窓、全部鍵かかってる？」チェック

🚨 アラート条件：
- 玄関の鍵が開いてる（ACLがパブリック）
- 窓の鍵が開いてる（ポリシーがパブリック）
- どちらか一つでも開いてたらアウト！
⚠️ 重要な比喩のポイント
玄関の鍵（ACL）も窓の鍵（ポリシー）も、両方チェックが必要！

玄関に鍵をかけても、窓が開いてたら泥棒は入れます。
同様に、ACLで制限しても、バケットポリシーでパブリックを許可していたら
誰でもアクセスできてしまいます！

このルールは「どちらか一方でもパブリックならNG」 と判定します。

📚 基本概念を理解しよう

🗂️

S3バケットとは？

クラウド上の大きな収納箱

• ファイルを無制限に保存できる
• 写真、動画、ドキュメント、バックアップなど
• インターネット経由でアクセス可能
• デフォルトはプライベート（鍵付き）

重要度: ★★★★★
🔓

パブリックアクセスとは？

インターネット上の誰でもアクセス可能

• URLを知っていれば誰でも見られる
• ログイン不要でアクセス可能
• 意図しない情報漏洩のリスク大
• セキュリティインシデントの主な原因

危険度: ★★★★★
🛡️

AWS Configとは？

AWSリソースの設定を監視・記録

• リソースの設定変更を自動検出
• コンプライアンスルールをチェック
• 設定の履歴を記録
• 問題があればアラート通知

有用度: ★★★★★

🔑 ACL vs バケットポリシー - 2つの鍵の違い

項目 ACL（Access Control List） バケットポリシー
たとえ 🚪 玄関の鍵システム 🪟 各窓の鍵システム
制御範囲 バケット全体 or オブジェクト個別 バケット全体
設定方法 シンプルな権限リスト
（読み取り/書き込み） 		JSON形式の詳細なポリシー
（条件付きルール可能）
柔軟性 ⭐⭐ 基本的な制御のみ ⭐⭐⭐⭐⭐ 高度な制御が可能
パブリック設定例 "Everyone"に読み取り権限を付与 Principal: "*"（誰でもOK）
推奨度 ⚠️ レガシー（古い方式）
新規では非推奨 		✅ 現在の標準
積極的に使用すべき
検出対象 ✅ このルールでチェック ✅ このルールでチェック
💡 重要ポイント
s3-bucket-level-public-access-prohibitedは両方チェックします！

• ACL（玄関の鍵）がパブリック → ❌ 非準拠
• バケットポリシー（窓の鍵）がパブリック → ❌ 非準拠
• 両方プライベート → ✅ 準拠

どちらか一方でもパブリックなら警告が出ます！

🔍 s3-bucket-level-public-access-prohibited の動作

1 AWS Configがバケットをスキャン
📡 定期的な監視
• すべてのS3バケットを定期的にチェック
• 設定変更があれば即座に評価
• 24時間365日自動監視

🎯 チェック対象：
• バケットACL設定
• バケットポリシー設定
• パブリックアクセスブロック設定
2 ACLをチェック（玄関の鍵）
🚪 ACL評価ポイント

❌ パブリックと判定される条件：
• AllUsers（すべてのユーザー）に権限付与
• AuthenticatedUsers（認証済みAWSユーザー全員）に権限付与
• READ/WRITE/READ_ACP/WRITE_ACP権限のいずれか

✅ プライベートと判定される条件：
• 特定のAWSアカウントのみに権限
• パブリックグループへの権限なし
3 バケットポリシーをチェック（窓の鍵）
🪟 ポリシー評価ポイント

❌ パブリックと判定される条件：
• Principal: "*" （誰でもアクセス可能）
• Condition無しでの広範なアクセス許可
• s3:GetObject等のアクション許可

✅ プライベートと判定される条件：
• 特定のAWSアカウント/ユーザーのみ
• 厳格なConditionによる制限
• VPCエンドポイント経由のみ等
4 判定結果を出力
📊 コンプライアンス状態

✅ COMPLIANT（準拠）：
• ACLもポリシーもプライベート
• パブリックアクセスブロックが有効
• セキュアな状態

❌ NON_COMPLIANT（非準拠）：
• ACLまたはポリシーがパブリック
• パブリックアクセスの可能性あり
• 即座に対応が必要
5 通知・対応
🚨 アラート機能

• SNS経由でメール/Slack通知
• EventBridgeで自動修復トリガー
• ダッシュボードで一元管理
• 履歴の記録と監査証跡

💡 即座に対応して、データを守りましょう！
⚠️ 検出される危険なパターン実例
🔴 パターン1: ACLでパブリック公開
❌ BAD EXAMPLE - パブリックACL 
# すべてのユーザーに読み取り権限
Grantee: http://acs.amazonaws.com/groups/global/AllUsers
Permission: READ

→ 誰でもバケット内容を閲覧可能！ 🚨
🔴 パターン2: バケットポリシーでパブリック公開
❌ BAD EXAMPLE - パブリックポリシー 
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",  ← 誰でもOK！
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::my-bucket/*"
  }]
}

→ インターネット上の誰でもファイルをダウンロード可能！ 🚨
🔴 パターン3: 認証済みユーザーに公開（これもNG！）
❌ BAD EXAMPLE - 認証済みユーザーへの公開 
# 認証済みAWSユーザー全員に権限
Grantee: http://acs.amazonaws.com/groups/global/AuthenticatedUsers
Permission: READ

→ AWSアカウントを持つ人なら誰でもアクセス可能！ 🚨
   （世界中に何百万人もいます）
💀 これらのパターンは全て非準拠（NON_COMPLIANT）と判定されます！

✅ 安全な設定パターン

🔒

方法1: ACLを使わない

最も推奨される方法

• ACL無効化（ACL Disabled）
• バケットポリシーのみで管理
• シンプルで安全

✅ GOOD - ACL無効化 
# バケット作成時
ObjectOwnership: BucketOwnerEnforced

→ ACLが完全に無効化される
→ ポリシーのみで制御
推奨度: ★★★★★
🛡️

方法2: パブリックアクセスブロック

最強の防御壁

• すべてのパブリックアクセスをブロック
• ACL/ポリシー関係なく強制ブロック
• 4つの設定すべてをON

✅ GOOD - パブリックアクセスブロック 
{
  "BlockPublicAcls": true,
  "IgnorePublicAcls": true,
  "BlockPublicPolicy": true,
  "RestrictPublicBuckets": true
}

→ 完全にパブリックアクセスを防御
推奨度: ★★★★★
🎯

方法3: 特定ユーザーのみ許可

必要最小限の権限

• 特定のAWSアカウントのみ
• IAMユーザー/ロールを明示
• 条件付きアクセス制御

✅ GOOD - 特定アカウントのみ 
{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::123456789012:root"
  },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*"
}

→ 特定アカウントのみアクセス可能
推奨度: ★★★★☆
🌐

方法4: VPCエンドポイント経由のみ

ネットワークレベルの制限

• 特定VPCからのみアクセス許可
• インターネット経由を完全ブロック
• 企業内ネットワークからのみ

✅ GOOD - VPC制限 
{
  "Condition": {
    "StringEquals": {
      "aws:SourceVpce": "vpce-1234567"
    }
  }
}

→ 特定VPCからのみアクセス可能
推奨度: ★★★★☆
🏆 セキュリティベストプラクティス
1. パブリックアクセスブロックを常に有効化
• アカウントレベルとバケットレベルの両方で設定
• 4つの設定すべてをONにする
• これだけで大部分の事故を防げる

2. ACLは使わない方針を採用
• 新しいバケットではACL無効化
• バケットポリシーで一元管理
• レガシーACLは段階的に廃止

3. AWS Configルールを必ず有効化
• s3-bucket-level-public-access-prohibited を有効化
• s3-bucket-public-read-prohibited も併用
• s3-bucket-public-write-prohibited も併用

4. 自動修復の設定
• Systems Manager Automation ドキュメント使用
• 検出時に自動でパブリックアクセスを無効化
• 人的ミスによる設定ミスを即座に修正

5. 定期的な監査
• Config ダッシュボードで全バケット確認
• 非準拠バケットがないかチェック
• アクセスログの定期レビュー

6. 最小権限の原則
• 必要なユーザー/サービスにのみアクセス許可
• 時限的なアクセス権限を活用
• 定期的な権限レビュー

7. 教育と意識向上
• 開発チームへのセキュリティ教育
• パブリック設定の危険性を共有
• インシデント事例の学習

🛠️ AWS Configルールの設定方法

1 AWSマネジメントコンソールから設定
📱 GUI操作での設定手順：

1. AWS Configコンソールを開く
2. 「ルール」→「ルールを追加」をクリック
3. 「s3-bucket-level-public-access-prohibited」を検索
4. ルールを選択して「次へ」
5. スコープ：すべてのリソース
6. 「ルールを追加」をクリック

⏱️ 所要時間：約3分
2 CloudFormationで自動化
📄 CloudFormation テンプレート例 
Resources:
  S3PublicAccessConfigRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: s3-bucket-level-public-access-prohibited
      Description: S3バケットのパブリックアクセスを検出
      Source:
        Owner: AWS
        SourceIdentifier: S3_BUCKET_LEVEL_PUBLIC_ACCESS_PROHIBITED
      Scope:
        ComplianceResourceTypes:
          - AWS::S3::Bucket
3 自動修復の設定（オプション）
🔧 自動修復用 Remediation Action 
RemediationConfiguration:
  ConfigRuleName: s3-bucket-level-public-access-prohibited
  TargetType: SSM_DOCUMENT
  TargetIdentifier: AWS-PublishSNSNotification
  Parameters:
    AutomationAssumeRole:
      StaticValue:
        Values:
          - arn:aws:iam::123456789012:role/AutoRemediationRole
    TopicArn:
      StaticValue:
        Values:
          - arn:aws:sns:ap-northeast-1:123456789012:SecurityAlerts

# 検出時にSNS通知 → Lambda → 自動修復の流れ

❓ よくある質問（FAQ）

Q1 静的ウェブサイトホスティングで使いたい場合は？
A: CloudFrontとS3オリジンアクセスアイデンティティ（OAI）を使用

• S3バケット自体はプライベート設定
• CloudFrontからのみアクセス許可
• ユーザーはCloudFront経由でアクセス
• このルールは準拠（COMPLIANT）のまま

💡 パブリックアクセスを許可せずに、Webサイトを公開できます！
Q2 このルールの料金は？
A: AWS Config自体の料金がかかります

• ルール評価: $0.001/評価（東京リージョン）
• 設定項目記録: $0.003/記録
• 最初の1,000評価/月は無料枠あり

💰 通常は月額$10-30程度（小規模な場合）
Q3 既存の大量バケットに一括適用できる？
A: はい、可能です

• ルールを有効化すれば全バケットを自動スキャン
• 一括でコンプライアンス状態を確認可能
• 非準拠バケットのリストを一覧表示
• Lambda + Boto3で一括修復も可能

🚀 大規模環境でも効率的に管理できます
Q4 誤検知はありますか？
A: 基本的にありません

• AWSマネージドルールなので精度が高い
• ACLとポリシーを正確に解析
• パブリックアクセスブロックも考慮

ただし注意点：
• CloudFront OAI使用時も初期設定では検出される場合あり
• 意図的にパブリック設定している場合は「想定内の非準拠」として管理

✅ ほぼ100%正確に検出します

🎓 まとめ

🏠 家のセキュリティ = S3セキュリティ

玄関の鍵（ACL） も 窓の鍵（ポリシー） も
両方しっかり施錠することが大切！

AWS Config は24時間365日巡回する
信頼できる警備員 です🛡️

🚪
ACL

玄関の鍵
誰が入れるかを
シンプルに管理
🪟
ポリシー

各窓の鍵
詳細な条件で
アクセス制御
👮
Config

警備員
24時間体制で
監視・通知

🎯 今すぐやるべきこと：

1️⃣ パブリックアクセスブロック を全バケットで有効化
2️⃣ AWS Configルール s3-bucket-level-public-access-prohibited を有効化
3️⃣ ACLを無効化 してポリシーで一元管理
4️⃣ 定期的な監査 でセキュリティ状態を確認

これで大切なデータを守れます！🔒✨

💡 覚えておくべき最重要ポイント：

「 どちらか一方でもパブリックならアウト 」
ACLもポリシーも、両方プライベートに設定しましょう！

意図しないデータ漏洩を防ぎ、
安心してS3を活用できます！🎉

Created by SSuzuki1063

AWS SAP Learning Resources