[AWS] S3 セキュリティ対策

## 1. パブリックアクセスを防止する

バケットやオブジェクトがパブリックに公開されるリスクを下げるために、以下の点を実施する。

1. **Block Public Access 機能の活用**
   - バケットやアカウントレベルで「パブリックアクセスをブロック」設定を有効化する。
   - ACL（アクセスコントロールリスト）によるパブリック許可を防ぎ、意図したバケットポリシーだけで公開制御を行う。
2. **バケットポリシーでの明示的な制御**
   - パブリックアクセスを許可しないようにデフォルトでは `Principal: "*"` を使わない。
   - 必要に応じて `s3:GetObject` のみパブリックに許可するが、`s3:ListBucket` は許可しないなど、「最小権限」で制御する。

### 1.1 Block Public Access の流れ

```mermaid
sequenceDiagram
    participant External as 外部ユーザー
    participant S3 as Amazon S3
    
    External->>S3: 1. バケット/オブジェクトへのアクセス(HTTP GET 等)
    alt バケットでPublic Access Blockが有効
        S3-->>External: 2. Access Denied (ACL上は公開でもブロック)
    else Public Access Blockが無効
        S3-->>External: 2. ACL/Public設定どおりにアクセス可
    end

```


# 2. 暗号化 (Server-Side Encryption) を利用する

バケットやオブジェクトに格納するデータを暗号化し、万が一のデータ流出に備える。

1. **SSE-S3 (AES-256)**
   - AWS 管理のキーを使用し、S3 が自動的に暗号化/復号を実施する。
   - 最も簡単でコストも低い。
2. **SSE-KMS** (AWS KMS)
   - AWS KMS (Key Management Service) で管理するカスタマーマスターキー(CMK)を使用。
   - キーポリシーや CloudTrail 連携で、キー使用履歴やアクセスを厳密に管理できる。
3. **SSE-C (Customer Provided Keys)**
   - 独自に管理するキーを都度アップロード時に送信し、S3 が暗号化/復号を実施する。
   - 鍵管理の責任がユーザー側にあるため運用コストが高い。

### 2.1 SSE-KMS を利用した場合の流れ

```mermaid
sequenceDiagram
    participant Client as ユーザー/アプリ
    participant S3 as S3バケット(SSE-KMS有効)
    participant KMS as KMS(カスタマーマスターキー)

    Client->>S3: 1. PutObject要求 (KMSキーを使用して暗号化したい)
    S3->>KMS: 2. データ鍵(Data Key)の生成/取得をリクエスト
    KMS-->>S3: 3. 暗号化用データ鍵を返却
    S3-->>S3: 4. データ鍵でオブジェクトを暗号化して保存
    S3-->>Client: 5. PutObject 成功 (S3内部では暗号化完了)

```



# 3. バケットポリシー & IAM ポリシーでの最小権限化

1. **バケットポリシー**
   - 具体的なアクション(`s3:GetObject`, `s3:PutObject`, `s3:ListBucket`など)とリソース(`arn:aws:s3:::my-bucket/*`)を指定し、最小権限付与の原則(Principle of Least Privilege)を守る。
   - 例: 「社内ネットワークからのみ GET を許可」など、ソースIPアドレス制限(`aws:SourceIp`)を組み合わせることも可能。
2. **IAM ポリシー**
   - ユーザーやロールが「自分が必要な権限だけ」を持つように設計する。
   - 例えば、アプリケーションサーバーのロールには `s3:PutObject` と `s3:GetObject` のみ付与し、余計なアクションを許可しない。

### 3.1 バケットポリシー適用の流れ

```mermaid
sequenceDiagram
    participant User as ユーザー/アプリ
    participant IAM as IAM(ユーザー/ロール)
    participant S3 as S3(バケット)
    User->>IAM: 1. 認証(ログイン/STS Assume Roleなど)
    IAM-->>User: 2. トークン発行
    User->>S3: 3. S3操作(APIリクエスト)
    alt バケットポリシーで許可
        S3-->>User: 4. 成功(オブジェクト取得など)
    else バケットポリシーで拒否
        S3-->>User: 4. AccessDenied
    end
```



# 4. ログと監査

1. **S3 Server Access Logging**
   - S3 が受け取ったリクエストの情報(IPアドレス, HTTPステータス等)を別のバケットにログとして格納。
   - 誰がいつどのオブジェクトにアクセスしたかを追跡しやすい。
2. **CloudTrail Data Events**
   - オブジェクトレベルの操作(PUT, GET, DELETE)を CloudTrail で監査。
   - 重要なアクションがあった場合にアラートを設定することも可能。

### 4.1 Loggingの流れ

```mermaid
sequenceDiagram
    participant Client as クライアント
    participant S3 as S3(バケット)
    participant LogBucket as ログ保存用バケット
    Client->>S3: 1. GET/PUT/DELETEなどS3リクエスト
    S3->>S3: 2. リクエストを処理 (オブジェクト取得/更新)
    S3->>LogBucket: 3. アクセスログを記録
```


# 5. バージョニングと MFA Delete

1. **バージョニングの有効化**
   - オブジェクトの上書きや削除が行われても、過去バージョンを保持することで誤操作やランサムウェア的な攻撃への耐性を高める。
2. **MFA Delete**
   - オブジェクトのバージョン削除やバージョニング設定の変更には MFA (多要素認証) が必要になる。
   - 誤ってバージョンを削除してしまうリスクや不正削除リスクを最小化。

### 5.1 バージョニングの流れ (オブジェクト削除の場合)

```mermaid
sequenceDiagram
    participant User as ユーザー
    participant S3 as S3(バケット: バージョニング有効)

    User->>S3: 1. DeleteObjectリクエスト
    alt バージョニングが有効
        S3-->>User: 2. 新しい“削除マーカー”作成
        Note over S3: 実際には過去バージョンは保持
    else バージョニングが無効
        S3-->>User: 2. オブジェクトを完全削除
    end
```

( MFA Delete が有効なら、「MFA デバイスのコードが正しいか」が追加でチェックされます )

# 6. VPC エンドポイント (PrivateLink) の利用

1. **VPC 内からのみアクセス**
   - Internet 経由ではなく、VPC 内のプライベートネットワークを介して S3 にアクセスする。
   - これにより、インターネット側からの攻撃を防ぎ、セキュリティグループやネットワークACLで制御可能。
2. **バケットポリシーで Source VPC / Source VPCE を条件に制限**
   - `aws:SourceVpc` や `aws:SourceVpce` などの条件キーを使って、特定の VPC エンドポイント経由のみアクセスを許可。

### 6.1 VPCエンドポイントの流れ

```mermaid
sequenceDiagram
    participant EC2 as EC2(Private Subnet)
    participant VPCe as S3 VPC Endpoint
    participant S3 as S3(バケット)

    EC2->>VPCe: 1. S3リクエスト(PrivateLink)
    VPCe->>S3: 2. AWS内部ネットワーク経由
    S3-->>VPCe: 3. レスポンス
    VPCe-->>EC2: 4. レスポンス
```


# 7. Access Analyzerを使用したバケットアクセスの確認

- 外部アクセスの検出
  - S3 のバケットポリシーや ACL を解析して、意図せずパブリックになっている (または他のAWSアカウントにオープンになっている) バケットを検出。
- ポリシーの継続的なモニタリング
  - ポリシーを変更した際にアラートをあげたり、推奨修正を提示してくれる。

### 7.1 アクセスアナライザーのイメージ

```mermaid
sequenceDiagram
    participant Admin as バケット管理者(AWSコンソール)
    participant Analyzer as Access Analyzer
    Admin->>Analyzer: 1. バケットポリシーを変更
    Analyzer-->>Analyzer: 2. 変更内容を評価
    Analyzer-->>Admin: 3. “パブリック公開”など警告が出る場合、通知
```



# 8. まとめ

1. **パブリックアクセスブロック** と **バケットポリシー** で、「意図した範囲のみ」を公開
2. **暗号化 (SSE-S3, SSE-KMS)** の利用で、保管時リスクを軽減
3. **IAM & バケットポリシー** で最小権限を遵守、ソースIP/VPC制限などを活用
4. **ログ/監査** (S3 Server Access Logging、CloudTrail Data Events) で不正アクセスを早期検知
5. **バージョニング & MFA Delete** により、誤削除や不正削除に強い運用
6. **VPCエンドポイント** を通じて、インターネットを介さないセキュアなアクセス
7. **アクセスアナライザー** でポリシーの継続的監査・アラート

これらを組み合わせることで、**誤設定や不正アクセスによるセキュリティリスクを低減**できる。

まずは「パブリックアクセスブロック」と「暗号化」「最小権限のポリシー設定」を導入し、その上で組織の要件に合わせて追加機能 (WAF/Access Points/Access Analyzer など) を取り入れる、などの進め方がある。



### 参考ドキュメント

- [AWS 公式: Amazon S3 のセキュリティのベストプラクティス](https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/security-best-practices.html#security-best-practices-prevent)
- [AWS 公式: S3の暗号化とキー管理](https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/serv-side-encryption.html)
- [AWS 公式: Access Analyzer for S3](https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/access-analyzer.html)