CloudFront & Route 53 — エッジから始まるセキュリティ
OAC、署名付きURL、DNSSEC、DNS Firewallを講義形式で解説
おはようございます。今日は、インターネットの「入口」から始まるセキュリティ、CloudFront と Route 53 についてお話しします。
ユーザーがあなたのウェブサイトにアクセスする時、一番最初に接触するのは DNS です。その次が CloudFront（CDN）。その次が、あなたの本体サーバーやデータベース。
この流れを逆に見ると、セキュリティのレイヤーも一番最初から始まります。「入口を守らないと、中がどんなに堅牢でも意味がない」というセキュリティ原則が適用されるのです。
CloudFront — 「エッジから始まるセキュリティ多層防御」
CloudFront は一般的には CDN（コンテンツ配信ネットワーク）と説明され、「世界中のエッジサーバーからコンテンツを配信して高速化」という理解がされます。ですが、セキュリティ観点からは、CloudFront は攻撃から身を守る砦なのです。
例えば、S3 にアップロードした画像や動画をユーザーに配信する場合、直接 S3 URL を配信する選択肢もあります。ですが、セキュリティ的にはこれは最悪です。理由は複数あります。第一に S3 のバケット名が外部に露出します。第二に S3 のエンドポイントが DDoS 攻撃の直接的な対象になります。第三に S3 アクセスログが肥大化しコストが増加します。第四に S3 へのアクセス数が制限を超えると、レート制限エラーが発生します。
これらを CloudFront を中間に置くことで全て回避できます。ユーザーは CloudFront の URL のみを知り、S3 の存在は隠れます。CloudFront がキャッシュ層として機能し、DDoS 攻撃の矢面に立ちます。AWS のクラウドフロント インフラストラクチャが 99.99% の可用性 SLA で保護されるのです。
CloudFront を入れると、ユーザーがCloudFrontにアクセスして、CloudFrontがS3からコンテンツを取得する構造になります。ユーザーはCloudFrontのURLしか知らない。S3がどこにあるか、分からない。CloudFrontからS3へのアクセスはAWS内部ネットワークなので、高速だし、外部から見えない。CloudFrontが「攻撃の矢面」に立つわけです。
OAC（Origin Access Control）
では、CloudFront と S3 をどうつなぐか？
従来は OAI（Origin Access Identity）という仕組みを使ってました。
でも、これは今じゃ deprecated（古い）なんです。
新しいやり方は OAC（Origin Access Control）です。
OAC ってね——
CloudFront だけが S3 にアクセス可能。人間には、S3 を見えなくする。
これ、実装としては——
- OAC を作成する
- S3 バケットポリシーに「このOAC経由のアクセスだけ許可」と書く
- CloudFront の設定で、「S3 へのアクセスは OAC 経由で」と指定
——そうするとね、CloudFront 経由でしかアクセスできなくなるわけです。
ユーザーは CloudFront から受け取る。CloudFront が S3 から取ってくる。でもね、ユーザーは S3 には触れない。
OAC = CloudFront の背後に S3 を隠す。
署名付き URL と署名付きクッキー
ここからが、セキュリティの本番です。
あなたが動画配信サービスをやってるとしましょう。
「新作映画は、月額会員だけが見られる」——こういう要件ですね。
では、CloudFront からコンテンツを配信するとき、どうやって「会員だけ」を制限するんですか？
答え：署名付き URLと署名付きクッキーです。
署名付き URL = 時間限定の URL。
例えば——
署名付きURLの例としては、CloudFrontのドメイン名にmovie.mp4というパスがあり、Expiresパラメータで有効期限、Signatureパラメータで署名値、Key-Pair-Idパラメータで鍵ペアを指定したような形式です。
ユーザーが「映画を見たい」と言ったら、あなたのアプリケーションサーバーがね——AWS が提供する署名ライブラリを使って——この署名付き URL を生成します。
そしたら、その URL は——
15分だけ有効（Expires 値で指定） 署名が正しいかどうか検証される（CloudFront が署名を確認）
——つまり、偽造できない、時間制限がある、の2つのセキュリティが入ってるわけです。
万が一、その URL がオンラインで漏れても——「あ、15分で期限切れるか」「あ、署名が改ざんされたら無効になる」——こうして被害を最小化できるわけです。
署名付きクッキー = クッキーを使った、複数 URL 共通の認証。
映画配信の例で言うと——
ユーザーが一旦ログインしたら、あなたのアプリケーションが——署名付きクッキーを発行します。
そのクッキーを持ってると、CloudFront の任意の映画 URL にアクセスできる。
ただしね、クッキーも署名されてるから、改ざんは検出される。
署名付き URL = 単発。署名付きクッキー = 複数 URL 共通。使い分ける。
フィールドレベル暗号化
ちょっと別の観点から。
ユーザーが——CloudFront 経由であなたのサイトにアクセスします。
そこで、クレジットカード番号を入力する。
普通に考えると——
ユーザー（ブラウザ） → HTTPS 暗号化 → CloudFront → HTTPS 暗号化 → 本体サーバー
——2段階の HTTPS 暗号化がありますよね。
でもね、これでも——CloudFront で一旦復号化される。
つまり、CloudFront のキャッシュに——クレジットカード情報が一旦見える形で存在する可能性があるわけです。
「あ、これ、少し気になるな」——そういう場合の答えが——フィールドレベル暗号化です。
これはね——
ユーザーのブラウザで、クレジットカード番号だけを別途暗号化する。
ユーザー → CloudFront → 本体サーバー
——その過程で、クレジットカード番号は常に暗号化されたまま。CloudFront でも見えない。
最終的に、本体サーバーだけが復号化できる。
つまり、「個別フィールド単位での暗号化」なんです。
フィールドレベル暗号化 = CloudFront を信頼しない。エンドツーエンド暗号化を徹底。
Route 53 — DNS から始まるセキュリティ
では、CloudFront の話は終わり。次は DNS です。
Route 53 ってね、AWS の DNS サービスです。
「あ、DNS? ただの名前解決じゃん」——って思うでしょ。
違うんです。DNS も——セキュリティの重要な場所なんですよ。
例えば、世の中には DNS を悪用した攻撃があります。
DNS Hijacking = 攻撃者が、あなたのドメインの DNS レコードを改ざんして、悪いサイトに誘導する。
DNS Amplification = 大量の DNS クエリを送って、DDoS 攻撃をする。
——こんなのがあるわけです。
では、これを守るには？
DNSSEC
DNSSEC（DNS Security Extensions）ってね——
DNS レコードの真正性を、暗号化によって保証する。
こういうしくみです。
具体的には——
- DNS レコード（例：example.com → 192.0.2.1）に、デジタル署名を付ける
- その署名の公開鍵をね、親のドメイン（.com の管理者）に登録させる
- ユーザーが DNS クエリをしたときに、署名を検証する
そうするとね、攻撃者がね DNS レコードを改ざんしようとしても——署名が合わなくなるから、クライアント（ブラウザとか）が「あ、これ改ざんされてる」と検出するわけです。
DNSSEC は——Route 53 で簡単に有効化できます。
ただし、1つ注意があります。
親のドメイン（.com の管理者とか）にね、子のドメインの DNSSEC 鍵をね、登録させる必要があるんです。
つまり——
- Route 53 で DNSSEC を有効化
- AWS が自動生成した DNSSEC 鍵を、ドメイン登録者（例：Namecheap、GoDaddy）の管理画面で登録
——このステップが必要なんです。
手作業が少し入ります。でも——DNSSEC を有効化すれば、DNS Hijacking から守られるわけです。
DNSSEC = DNS レコードのなりすまし防止。有効化すべき。
DNS Firewall
ここからが、本当に面白い。
あなたの企業にね、AWS 環境がある。VPC とか。
その VPC の中のサーバーが、外部の DNS クエリをするとき——どこに向かうのか？
普通は、Route 53 のパブリック DNS（8.8.8.8 みたいな）を使ってますよね。
でもね、そこで——危ない DNS 解決が起こる可能性があるんです。
例えば——
「社員が誤ってね、フィッシングサイトにアクセスしようとした」 「そこで DNS クエリが発生する」 「悪いサイトに解決される」
こういう「危ない DNS クエリ」を、一か所で管理したい——そんな要件がありますよね。
Route 53 Resolver DNS Firewall がそれです。
これはね——
VPC 内の全サーバーからの DNS クエリに対して——
ホワイトリスト = 「このドメイン だけアクセス OK」 ブラックリスト = 「このドメイン は絶対NG」 信脅威リスト連携 = 「Managed Threat Intelligence と連携して、マルウェアサイトをブロック」
——こういう制御ができるんです。
つまり、VPC が外部インターネットと通信するとき、DNS Firewall が最初のゲートキーパーになるわけです。
DNS Firewall = VPC の外部通信を、DNS レベルで制御する最初の砦。
実務的なセキュリティアーキテクチャ
では、CloudFront と Route 53 を組み合わせると、どういうセキュリティアーキテクチャになるのか？
例えば——
ユーザーがRoute 53にDNSクエリを送り、DNSSEC検証が行われます。そしてユーザーがcloudfront.example.comに接続し、CloudFrontのエッジロケーションに到達します。そこからOAC経由でS3バケットにアクセスしますが、S3バケットは完全に隠されているという流れです。
ユーザーは——
DNS を信頼できる（DNSSEC 署名付き） CloudFront から安全にコンテンツを受け取れる（OAC で直接 S3 に触らない） 敏感な情報は署名付き URL で時間制限される
全部、セキュリティが多層的に入ってるわけです。
で、企業内からの通信なら——
VPC内のサーバーからDNSクエリが出ると、Route 53 Resolver DNS Firewallに到達します。そこでホワイトリスト、ブラックリスト、脅威インテリジェンスで検査され、外部DNSへの接続が許可されるか、それともブロックされるかが判定されます。このようなきめ細かい制御ができるわけです。
WAF との組み合わせ
あ、ちょっと大事な補足があります。
CloudFront の前には——WAF（Web Application Firewall）を置くことができます。
CloudFront WAF は——
SQL インジェクション攻撃を検出・ブロック XSS 攻撃を検出・ブロック DDoS 攻撃の一部を制限
——こんなことができます。
つまり——
ユーザーがRoute 53にアクセスします。そこでDNS Firewallが不正サイトをブロックします。次にCloudFront WAFでSQLインジェクション、XSS、DDoS攻撃を検出します。その後CloudFrontに到達し、OACでS3を保護し、署名付きURLで時間制限をかけます。最後に本体サーバーまたはS3に到達します。こうして多層防御が完成するわけです。
セキュリティ多層防御 = DNS → WAF → CDN → 本体サーバー
ビジネスインパクト
では、こんなセキュリティアーキテクチャを取ると——何が変わるのか？
パフォーマンス = CloudFront でコンテンツがエッジにキャッシュされるから、ユーザーの待ち時間が減る。
セキュリティ = DDoS 攻撃、DNS Hijacking、不正アクセスが多層的に防される。
コンプライアンス = DNSSEC、OAC、署名付き URL で、セキュリティ要件を満たす。
スケーラビリティ = CloudFront が世界中のエッジからスケールするから、トラフィック増加に自動対応。
つまり、CloudFront と Route 53 は——単なる「速度改善」ツールじゃなくて——
セキュリティと性能と規模を同時に実現するインフラストラクチャなんですよ。
では、最後にまとめます。
CloudFront は——
OAC で S3 を隠す 署名付き URL で時間制限と認証 フィールドレベル暗号化でエンドツーエンド保護
Route 53 は——
DNSSEC で DNS レコードの真正性を保証 DNS Firewall で VPC からの外部通信を制御
——この2つが組み合わさることで、インターネットの入口から————セキュリティが多層的に実現される。
それが、エッジから始まるセキュリティの正体なんです。
では、次のテーマに行きましょう。