概要

オリジンクローキングは、ウェブアプリケーションの攻撃対象領域を減らすことを目的とした一連の手法です。DDoS 攻撃や望ましくないボットに対する保護などのセキュリティ制御が適用されるウェブアプリケーションへの単一のエントリポイントとして CloudFront を使用するのがベストプラクティスです。オリジンクローキングは、CloudFront のエントリポイントから送信されないトラフィックをブロックするファイアウォールルールを使用して、悪意のある攻撃者が CloudFront とそのセキュリティコントロールを迂回してオリジンに直接攻撃するのを防ぎます。オリジンクローキングは、OSI モデルの複数のレイヤーで実現できます。

ネットワーク層で

オリジンでインバウンドネットワークアクセスを制御できる場合は、制限を追加して CloudFront のネットワークからのトラフィックのみを許可します。

オリジンが EC2 インスタンス、Application Load Balancer、または Network Load Balancer の場合、オリジンを VPC のプライベートサブネットに置き、CloudFront の VPC オリジン機能を活用できます。これにより、お客様の AWS アカウントの VPC オリジンを使用して設定された CloudFront ディストリビューションのみへのアクセスを制限できます。

VPC オリジン

このようなリソースをパブリックサブネットに残す必要がある場合（たとえば、ALB に複数の CDN からアクセスする場合）、または CloudFront の VPC オリジンでサポートされていないオリジンタイプがある場合は、セキュリティグループを使用して CloudFront へのアクセスを制限できます。オリジンをセキュリティグループに関連付ける必要があります。このセキュリティグループに Amazon CloudFront の AWS 管理プレフィックスリストを追加します。

オリジンがオンプレミスにある場合は、CloudFront のオリジン側 IP アドレスを一覧表示できるようにすることで、CloudFront へのアクセスを制限できます。この IP アドレスは、サービスフィールドの CLOUDFRONT_ORIGIN_FACING 値でフィルタリングするとこの IP リストに表示されます。この方法では、ACL を更新するには IP の変更をサブスクライブする必要があります。サードパーティのファイアウォールを使用してオンプレミスのウェブサーバーにオリジンクロッキングを実装する方法については、このブログ記事をご覧ください。インターネットからさらに分離するには、Direct Connect 接続のパブリック仮想インターフェイスを使用して、オンプレミスのインフラストラクチャと AWS の間にAWS Direct Connect を設定することを検討してください。

ネットワーク層でのアクセス制御は出発点ですが、それだけでは不十分な場合があります。たとえば、誰かがお客様のオンプレミスでオリジンドメイン名を発見した場合、その人は自分の AWS アカウントで CloudFront ディストリビューションを作成し、独自のディストリビューションをバイパスできます。別の例としては、VPC オリジン機能を使用している場合、AWS アカウントの VPC オリジンで構成されたすべての CloudFront ディストリビューションにアクセスできるようにするのではなく、オリジンを AWS アカウントの特定の CloudFront ディストリビューションに制限したい場合があります。この場合は、アプリケーション層のアクセスコントロールによる強化を検討してください。

アプリケーション層で

オリジンアクセスコントロール

オリジンアクセスコントロール (OAC) を使用すると、一部のオリジンを CloudFront にロックすることが非常に簡単になります。OAC は、IAM ポリシーに基づく AWS 署名バージョン 4 アルゴリズム (sigv4) を使用してネイティブに特定のタイプのオリジンへのリクエストに署名する CloudFront の機能です。現在、OAC は S3 、メディアストア、メディアパッケージ、Lambda 関数 URL 、および S3 オブジェクトラムダと互換性があります。OAC を S3 で使用すると、S3 バケットポリシーに基づいて CloudFront に排他的にアクセスできるため、S3 バケットをプライベートに保つことができます。

オリジンタイプが OAC でサポートされていない場合は、エッジ関数を使用してオリジンへのリクエストに署名できます。実装例については、以下のブログで説明されています。

共有秘密鍵に基づくアクセスコントロール

オリジンがリクエスト署名をサポートしていない場合や、アプリケーションにこのレベルのアクセス制御が必要ないと考えられる場合は、共有シークレットを含むカスタムヘッダーをオリジンに送信するように CloudFront を設定できます。このヘッダーは、オリジンで検証されてリクエストを処理できます。次の実装例を考えてみましょう。

  • ALB ベースのオリジン。ALB ベースのオリジンでシークレットヘッダーを検証するには、ALB ルールを使用するか、ALB が既に AWS WAF WebACL に関連付けられている場合は AWS WAF ルールを使用します。
  • API ゲートウェイベースのオリジン。API キーを使用して API ゲートウェイのシークレットヘッダーを検証できます。
  • NGINX ベースのオリジン。CloudFront が abc123 という値を持つカスタムヘッダー X-CloudFront を送信すると仮定すると、/etc/nginx/nginx.conf Nginx 設定ファイルのサーバータグに次のコードを追加することで、Nginx ベースのウェブサーバー (クラウドベースまたはオンプレミスベース) のシークレットヘッダーを検証できます。

    もし ($http_x_cloudfront!=「abc123」) {
        403 を返します。
    }
  • アパッチベースの起源。CloudFront が abc123 という値を持つカスタムヘッダー X-CloudFront を送信すると仮定すると、 httpd.conf 構成ファイル (および使用されている場合は ssl.conf ファイル) に次のコードを追加することで、Apache ベースのウェブサーバー (クラウドベースまたはオンプレミスベース) のシークレットヘッダーを検証できます。

    リライトエンジンオン
    Cond% {http: X-CloudFront} を書き直してください!^abc123$ [NC]
    リライトルール ^-[F]

いずれの場合も、シークレットが漏洩するリスクを減らすために、この共有シークレットを定期的にローテーションすることをお勧めします。上記で共有したサンプル実装では、API Gateway と ALB の両方にシークレットローテーションの自動化が含まれています。

このページはお役に立ちましたか?

 フィードバック