T1-Q03: SSE-C強制はStringNotEqualsではなくNull条件で未指定を潰す

対象誤答: T1 Q03 S3 SSE C NULL CONDITION

あなたの選択と正答

観点	内容
あなたの選択	”Condition”: { “StringNotEquals”: { “s3:x-amz-server-side-encryption”: “aws:kms” } }
正答	”Condition”: { “Null”: { “s3:x-amz-server-side-encryption-customer-algorithm”: “true” } }
誤答の引力	SSEという大きい分類で見てしまい、SSE-KMS用の条件キーに寄った。問われているのはSSE-Cのヘッダーがリクエストに存在するか。
判断軸	SSE-Cは顧客提供キーなので、条件キーはcustomer-algorithm側を見る。未指定アップロードを拒否するにはStringNotEqualsよりNullが刺さる。

この問題の芯

T1-Q03 は、Organizations 配下の複数アカウントで、S3 の PutObject に SSE-C を必須化する SCP 条件を選ぶ問題。あなたは SSE-KMS を示す s3:x-amz-server-side-encryption = aws:kms 系に寄った。正解は s3:x-amz-server-side-encryption-customer-algorithm の Null 条件。

ここで落とし穴になる条件キー

S3のサーバー側暗号化は名前が似ている。

方式	キーの所在	試験で見る語
SSE-S3	S3管理	AES256 / S3 managed
SSE-KMS	KMS管理	aws:kms / KMS key / kms:Decrypt
SSE-C	顧客提供	customer-provided key / customer-algorithm

この問題は「カスタマー提供のキー」と明記している。つまり条件キーは通常の s3:x-amz-server-side-encryption ではなく、SSE-C用の s3:x-amz-server-side-encryption-customer-algorithm。

なぜStringNotEqualsだけでは弱いか

StringNotEquals は「ヘッダーがあるが値が違う」ケースには効く。しかし試験で狙われていたのは、そもそも SSE-C ヘッダーを付けずに PutObject するケース。

未指定を落とすなら Null。

{
  "Effect": "Deny",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::bucket/*",
  "Condition": {
    "Null": {
      "s3:x-amz-server-side-encryption-customer-algorithm": "true"
    }
  }
}

これは「SSE-C のアルゴリズム指定ヘッダーが存在しないなら拒否」という意味になる。

次回の秒殺ルール

「SSE-C」「customer-provided key」が見えたら、まず customer-* 条件キーを見る。
「必須化」「未指定を拒否」なら Null: true を疑う。
「KMS」や aws:kms が問題文にないのに出てくる選択肢は、かなり強いひっかけ。

仕上げの一問一答