Amazon CloudFront がオリジンへの mTLS 認証をサポート

本投稿は、 Sagar Desarda と Yutaka Okaによる記事 「Amazon CloudFront now supports mTLS authentication to origins」を翻訳したものです。 

Amazon CloudFront は相互TLS（mTLS）機能をカスタマーオリジンに拡張しました。これにより、ビューワーからカスタマーオリジンまでの接続パス全体を通じた、真のエンドツーエンド認証が可能になります。CloudFront はこれまで、ビューワーと CloudFront 間のビューワー mTLS をサポートしており、トラフィックが境界に入る前にクライアントを強力に認証することができました。今回のリリースにより、同じトラフィックが CloudFront からオリジンへも mTLS 経由で継続できるようになり、すべてのホップにわたって暗号化されたアイデンティティと信頼が維持されます。その結果、完全に認証されたリクエストパスが実現し、暗黙の信頼を排除し、エッジでのパフォーマンスを犠牲にすることなくゼロトラストの多層防御アーキテクチャを実現します。

CloudFront とオリジン間の mTLS が重要な理由

エッジからオリジンへ mTLS を拡張することで、リクエストライフサイクル全体にわたって、信頼を境界ベースからアイデンティティベースへと移行させます。お客様はビューワー mTLS とオリジン mTLS を CloudFront で有効にすることで、各層の間の暗黙の信頼を排除し、オリジンで最小権限アクセスを強制できます。これは規制対象および高リスクのワークロードにおいて重要です。そのような環境では、オリジンへのアクセスは検証なしに信頼するのではなく、明示的に認証され、監査可能でなければなりません。ビューワー mTLS で導入された多くの業界固有のメリットが、エンドツーエンドで適用されるようになりました。これには、API の強力なクライアントアイデンティティ、デバイス認証、規制コンプライアンスが含まれ、エンドユーザーから CloudFront を経由してオリジンまでの相互認証によって実現されます。これらのユースケースの業界別の詳細については、ビューワー mTLS に関する以前のブログ記事を参照してください。この記事は、エンドツーエンド mTLS がゼロトラスト原則をエッジの先にどのように拡張するかを理解するための前提知識となります。

mTLS の仕組み

標準的な TLS では、証明書管理は一方向です。サーバーが証明書を提示し、クライアントが信頼された認証局（CA）に対してそれを検証する一方、クライアントはトランスポート層では認証されません。運用上、これにより証明書管理はシンプルに保たれます。チームはサーバーの証明書のみをプロビジョニング、ローテーション、監視し、多くの場合、自動化ツールと公的に信頼された CA を使用します。クライアントのアイデンティティが必要な場合は、API キー、OAuth トークン、ヘッダーなどのアプリケーション層のメカニズムに委ねられます。

mTLS はこのモデルを根本的に変更し、双方向認証を導入します。クライアントとサーバーの両方が有効な証明書を提示し、信頼された CA に対してそれらを検証する必要があります。そのため、証明書管理は、小規模で明確に定義されたサーバー証明書のセットの管理から、大規模になりうるクライアント証明書群の管理へと拡大します。これにより、新たな運用上の考慮事項が生じます：証明書の発行と失効、ライフサイクルの自動化、CA 信頼の配布、証明書の侵害やローテーションが必要な場合の影響の局所化です。

mTLS が CloudFront エッジで終端される場合、CloudFront はクライアント認証の証明書検証の実施ポイントとして機能することで、この運用上の複雑さの多くを吸収します。お客様は信頼されたルート証明書とクライアントポリシーを管理し、CloudFront が検証処理をスケーラブルに行います。mTLS がオリジンに拡張された場合も、証明書管理はこのモデルに沿ったままです：CloudFront は独自のクライアント証明書をオリジンに提示し、オリジンの証明書を検証します。これにより、オリジンがすべてのエンドユーザーの証明書を直接管理または信頼する必要なく、相互認証が維持されます。

前提条件

この機能を有効にするには、以下の前提条件があります：
・拡張キー使用法（clientAuth）を持つ X.509v3 クライアント証明書（PEM 形式）を準備
・mTLS 認証を要求し、クライアント証明書を検証するように構成されたオリジンサーバー
・AWS Certificate Manager（ACM）で米国東部（us-east-1）AWS リージョンを選択

設定手順

CloudFront とオリジン間の mTLS 認証の実装には、3つの主要なステップがあります：ACM を通じたクライアント証明書の取得、オリジンサーバーの構成、CloudFront ディストリビューションでの mTLS の有効化です。

ステップ 1：クライアント証明書の構成

CloudFront は2つのソースからのクライアント証明書の導入をサポートしており、それぞれ異なる運用ニーズに適しています：AWS Private Certificate Authority とサードパーティ CA です。

AWS Private Certificate Authority（推奨）
AWS Private Certificate Authority は、ACM とのシームレスな統合による、完全マネージドの証明書ライフサイクルを提供します。このアプローチにより、手動の証明書管理のオーバーヘッドが排除されます。

証明書をリクエストするには：
1. ACM コンソールを開き、米国東部（バージニア北部）リージョンにいることを確認
2. 「証明書のリクエスト」>「プライベート証明書のリクエスト」を選択
3. CA を選択し、ドメイン名を入力
4. 希望するキーアルゴリズムを選択し、更新権限を確認
5. 「リクエスト」を押下

図 1： AWS Certificate Manager からAWS Private Certificate Authorityへの新しい SSL/TLS 証明書リクエストの開始

サードパーティ CA 

既存のプライベート CA インフラストラクチャから証明書をインポートして、現在の証明書管理プロセスを維持しながら CloudFront mTLS 機能を利用できます（図2参照）

証明書をインポートするには：
1. ACM コンソールで「証明書のインポート」を選択
2. 証明書本文、秘密鍵、証明書チェーン（すべて PEM 形式）を入力
3. 「証明書をインポート」を押下

クライアント証明書には、mTLS 認証のための拡張キー使用法（clientAuth）が含まれている必要があります。

図 2：AWS Certificate Manager に既存のクライアント証明書と秘密鍵をアップロードして、AWS での mTLS 認証に使用される証明書を登録する画面

ステップ 2：オリジン設定で mTLS を有効化 

証明書ベースの検証を必要とする各オリジンに対して mTLS 認証を構成します（図3参照）：
1. CloudFront コンソールで、ディストリビューションの「オリジン」タブに移動
2. 構成するオリジンを選択し、「編集」を選択します。
3. オリジン設定で、「Enable origin mutual TLS」を「オン」に切り替えます。
4. ドロップダウンメニューからクライアント証明書を選択します。
5. 変更を保存します。

図 3：オリジンリクエストに対する mTLS 認証を有効にする CloudFront 設定。CloudFront がオリジンで証明書ベースの認証を強制できるようにします

オリジンごとの設定の柔軟性

mTLS はオリジンレベルで構成されるため、同じディストリビューション内の異なるオリジンに異なる証明書を割り当てることができます。これにより、オリジンごとに異なるセキュリティポリシーを適用できます。例えば、API エンドポイントには mTLS を使用し、静的コンテンツ配信オリジンには標準認証を適用できます（図4参照）。

図 4：CloudFront がオリジンとの相互 TLS を確立し、エッジからバックエンドサービスまでリクエストが認証・暗号化される構成

エンドツーエンド mTLS によるセキュリティとパフォーマンスのバランス

エンドツーエンド mTLS（エンドユーザーから CloudFront、CloudFront からオリジン）を有効にすると、接続確立時にいくらかのオーバーヘッドが発生します。これは、各セグメントで両者を認証するための証明書検証と暗号化処理が必要なためです。ただし、このオーバーヘッドは主にハンドシェイクフェーズに限定され、その後のアプリケーションデータの転送には影響しません。コネクションプーリングや持続的なキープアライブ接続などのコネクション再利用メカニズムにより、多くのエンドユーザーリクエストにわたってこのコストが削減されます。これにより、ほとんどのワークロードでレイテンシーとスループットへの影響が最小限に抑えられます。CloudFront はトラフィックの大部分をエッジでキャッシュするため、大半のリクエストはオリジンに到達せず、相対的なパフォーマンスへの影響がさらに軽減されます。TLS 1.3 と適切な証明書管理により、わずかに高い接続セットアップコストと強力なエンドツーエンド認証のトレードオフは十分に見合うものです。CloudFront を通じて配信されるアプリケーショントラフィックのセキュリティをさらに強化したい場合は、mTLS の実装が有効な選択肢となります。

証明書管理については、AWS Private CA が完全に自動化されたライフサイクル処理と、45 日、30 日、15 日、7 日、1 日前の更新通知によりプロセスを効率化します。サードパーティの証明書を使用している場合は、mTLS 接続の中断を避けるために、タイムリーな手動更新のプロセスを整備してください。

まとめ

Amazon CloudFront とオリジン間の mTLS は、最新のエッジアーキテクチャで最も見落とされがちな信頼のギャップの1つを解消します。パート1ではエンドユーザーと CloudFront 間の強力なアイデンティティと認証を確立しましたが、mTLS をオリジンに拡張することで、リクエストパスのすべてのホップが認証、暗号化、認可されることが保証されます。これにより、セキュリティは IP およびネットワークベースのモデルから暗号化ベースの信頼モデルへと移行し、オリジンは CloudFront を経由したことを証明できるトラフィックのみを処理します。アプリケーションが分散エッジ、プライベート API、ゼロトラスト原則にますます依存するようになるにつれ、CloudFront からオリジンへの mTLS は、オプションのセキュリティ強化策ではなく、基盤となるセキュリティ対策となります。エンドユーザー mTLS とオリジン mTLS を組み合わせることで、真のエンドツーエンドのアイデンティティ保証が提供され、攻撃対象領域の削減、コンプライアンスの効率化、回復力のあるアプリケーション境界の構築が実現します。

著者について