CloudFrontセキュリティをSCS視点で完全理解する

この記事はAWS公式ドキュメントを前提に、SCS-C03で問われる「CloudFrontを使ったセキュリティ設計」を判断できる粒度まで分解します。

CloudFrontはCDNです。ただしSCS視点では、単なる高速化サービスではありません。CloudFrontはインターネットからアプリケーションへ入る通信を、エッジで受け止め、検査し、オリジンへ渡すためのセキュリティ境界です。

試験で大事なのは「CloudFrontを使う」ではなく、次の問いに答えられることです。

• ViewerからCloudFrontまでの通信は安全か
• CloudFrontで不正リクエストを止めているか
• オリジンへ直接アクセスできないか
• 限定コンテンツを期限付きで配信できるか
• DDoSやBotに対して可用性を守れるか
• ログでブロック理由と設定変更を説明できるか

まず結論

CloudFrontセキュリティの正解パターンは、多くの場合この形です。

Viewer
  -> HTTPS only / signed URL / signed cookie
  -> CloudFront
  -> AWS WAF Web ACL
  -> Shield Standard or Shield Advanced
  -> OAC or origin restriction
  -> S3 / ALB / API origin
  -> CloudFront logs + WAF logs + CloudTrail

特にS3 originの場合、SCSでは OACを使ってS3バケットを非公開にし、CloudFront distributionからのアクセスだけを許可する という判断が重要です。古いOAIを知っていても、現在の推奨はOACです。OACはSSE-KMSや一部の動的S3リクエストにも対応し、OAIより広いユースケースを扱えます。

CloudFrontで守る対象を分ける

CloudFrontのセキュリティ設定は、守る対象で分けると理解しやすくなります。

「CloudFrontで守る」と言っても、通信暗号化とWAFとOACは別物です。HTTPSだけではSQLiは止まりません。WAFだけではS3直アクセスは止まりません。OACだけではBotを制御できません。ここを混同するとSCSの選択肢で負けます。

Viewer側の防御: HTTPSとレスポンスヘッダー

Viewer Protocol Policyでは、ViewerがCloudFrontへHTTPで来たときの扱いを決めます。

SCSで「通信を暗号化」「平文アクセスを許可しない」と出たら、まず redirect-to-https か https-only を見ます。ユーザー体験を保ちながら移行するならリダイレクト、APIや厳格要件なら拒否です。

CloudFrontのResponse Headers Policyでは、レスポンスにセキュリティヘッダーを追加できます。

Strict-Transport-Security
Content-Security-Policy
X-Content-Type-Options
X-Frame-Options
Referrer-Policy

ここでの注意点は、CloudFrontがヘッダーを付けても、アプリケーションの脆弱性が消えるわけではないことです。CSPはXSSの影響を抑える補助線で、入力検証や出力エスケープの代替ではありません。SCSでは「最も包括的な対策」を問われたとき、ヘッダーだけを選ばない判断が必要です。

AWS WAF: L7攻撃をエッジで止める

CloudFrontにAWS WAF Web ACLを関連付けると、SQLインジェクション、XSS、既知の悪意ある入力、Bot、大量アクセスなどをエッジで検査できます。

基本構成は次のようになります。

AWSManagedRulesCommonRuleSet
AWSManagedRulesKnownBadInputsRuleSet
AWSManagedRulesAmazonIpReputationList
Rate-based rule
必要に応じて Bot Control / SQLi rule / Anonymous IP list

試験で大事なのは、WAFは万能IPSではなく HTTP(S)リクエストのレイヤー7制御 だという点です。SYN floodやUDP floodのようなL3/L4のDDoSはWAFではなくShield側の話です。

WAFルールの設計では、最初から全ブロックにしないことも実務上重要です。まず COUNT で観測し、sampled requestsやログを見て誤検知を確認し、問題がなければ BLOCK に上げます。

検出したい攻撃が明確
  -> managed rule groupをCOUNTで導入
  -> WAF logsとsampled requestsを確認
  -> false positiveを例外化
  -> BLOCKに変更

SCSの問題文で「誤検知を避けながら段階的に導入」「本番影響を最小化」と出たら、COUNTモードやログ分析を含む選択肢が強くなります。

Shield: DDoSに対する判断

CloudFrontはShield Standardの保護対象です。Shield Standardは追加費用なしで利用でき、一般的なL3/L4 DDoSを自動緩和します。

一方、Shield Advancedを選ぶ条件は明確です。

• DDoS Response Team、つまりSRTの支援が必要
• DDoSによるスケールアウト費用の保護が必要
• 高度な可視性やイベント対応が必要
• CloudFrontだけでなくALB、NLB、Elastic IP、Global Acceleratorなども保護対象にしたい
• WAFと連携したアプリケーション層DDoS緩和が必要

「最もコスト効率よくDDoS耐性を高める」なら、まずCloudFront、Route 53、ELB、Auto Scaling、WAFを組み合わせます。いきなりShield Advancedを選ぶのは、SRTやコスト保護が問題文に明記されているときです。

OAC: S3オリジンを直接触らせない

S3をCloudFrontのoriginにする場合、最も重要なのは S3バケットをpublicにしない ことです。CloudFront経由では見えるが、S3 URLを直接叩いても見えない状態にします。

OACの基本は次の通りです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontServicePrincipalReadOnly",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/E123ABC456DEF"
        }
      }
    }
  ]
}

ポイントは、PrincipalがCloudFrontサービスプリンシパルで、Conditionにdistribution ARNを入れることです。これにより、別のCloudFront distributionや直接S3アクセスからの利用を防ぎます。

OACには落とし穴があります。

• S3 static website endpointにはOACを使えない
• OACでS3 originを保護するなら、通常のS3 REST endpointをoriginにする
• 推奨設定はリクエストに常に署名する設定
• S3 Object OwnershipはBucket owner enforcedが基本
• SSE-KMSを使う場合はKMS key policy側でもCloudFront/OAC経由の利用を考える

SCSでは「CloudFrontを置いたのにS3へ直接アクセスできる」という問題が出ます。この場合の正解はキャッシュ設定ではなく、OACとS3 bucket policyです。

ALBやAPIをオリジンにするとき

ALBをoriginにする場合、OACのようにS3専用の署名機構で閉じるわけではありません。よく使うのは次の設計です。

• CloudFrontからoriginへカスタムヘッダーを付与
• ALBまたはアプリ側でそのヘッダーを検証
• ALBのSecurity GroupでCloudFront managed prefix listからの通信だけ許可
• origin protocol policyをHTTPS onlyにする
• 必要に応じてorigin custom headerの値をSecrets Manager等で管理する

ただし、カスタムヘッダーは「秘密値」ではあるものの、漏れた場合に再利用されます。高い要件では、ALB側WAF、認証、mTLS、アプリケーション認可も合わせます。

Signed URLとSigned Cookie

CloudFrontの署名URLと署名Cookieは、限定配信のための機能です。

署名には期限を含められます。Custom policyを使うと、期限だけでなく開始時刻やIPアドレス条件も表現できます。SCSでは「S3 presigned URL」と混同しないことが重要です。

S3 presigned URL:
  S3 APIに対する期限付きURL。CloudFrontのキャッシュやWAFを通らない構成になりやすい。

CloudFront signed URL:
  CloudFront distributionに対する期限付きURL。WAF、ログ、OACと組み合わせやすい。

会員向け動画や教材のようにCloudFrontで配信しつつS3を非公開にしたいなら、CloudFront signed URLまたはsigned cookieとOACの組み合わせが強いです。

Origin Shield: セキュリティというより可用性の補助

Origin ShieldはCloudFrontのキャッシュ階層を追加し、originへの同時到達を減らします。直接の認可機能ではありませんが、SCSでは可用性・DDoS耐性・origin負荷軽減の文脈で効きます。

Origin Shieldが効く例は次の通りです。

• 人気ファイルにアクセスが集中する
• originがオンプレミスや単一リージョンで弱い
• 複数Edgeから同じoriginへ同時取得が走る
• キャッシュヒット率を上げたい

ただし、Origin ShieldはWAFの代替ではありません。不正リクエストを判断してブロックする機能ではなく、origin loadを下げるキャッシュ層です。

ログと監査

SCSで「検出」「調査」「証跡」が絡むときはログ設計まで見ます。

WAFログではAuthorizationやCookieをredactする設計も重要です。セキュリティログだからといって、機微情報をそのまま保存してよいわけではありません。

よくあるユースケース

S3静的サイトを安全に配信したい

推奨は、S3 bucketをprivateにし、CloudFront OACを使い、CloudFront経由だけで配信する構成です。S3 website endpointのリダイレクト機能が必要な場合はOACが使えないため、設計を分けます。

S3 private bucket
  + CloudFront OAC
  + bucket policy with AWS:SourceArn
  + Viewer HTTPS redirect
  + Response headers policy

APIをBotやSQLiから守りたい

CloudFrontをAPIの前段に置き、WAF Web ACLを関連付けます。Bot Control、rate-based rule、IP reputation、managed rule groupを段階的に導入し、CloudWatch metricsとWAF logsで調整します。

会員限定動画を配信したい

CloudFront signed cookieが向いています。複数ファイルをまとめて閲覧させるため、ファイルごとにURLを発行するより扱いやすいです。S3はOACで非公開にします。

DDoSでコスト増が心配

まずCloudFront、Route 53、ELB、Auto Scalingで吸収面を広げます。SRT支援、攻撃可視性、コスト保護が必要ならShield Advancedを選びます。

SCSでの引っかけ

試験直前チェック

• CloudFrontにWAFを付けても、origin直アクセスを閉じなければ迂回される
• S3 originはOAIよりOACが現在の推奨
• OACはS3 website endpointには使えない
• WAFはL7制御、ShieldはDDoS緩和
• Shield AdvancedはSRT、コスト保護、高度な可視性がキーワード
• Signed URL/CookieはCloudFront側の限定配信で、S3 presigned URLとは違う
• キャッシュキーに認可に関係するヘッダーやCookieを入れ忘れると情報漏えいにつながる
• WAFログでは機微ヘッダーのredactionを検討する

参考

• AWS公式: Configure secure access and restrict access to content
• AWS公式: Restrict access to an Amazon S3 origin
• AWS公式: Use signed URLs
• AWS公式: Understand response headers policies
• AWS公式: Use Amazon CloudFront Origin Shield