はじめに――なぜオリジン mTLS が必要なのか
私たちRagateでは、AWS CloudFrontを活用したCDN構成のプロジェクトを多数支援しています。これまでCloudFrontからオリジン（API GatewayやALBなど）へのアクセスを制限するには、カスタムヘッダーの共有シークレットやIPアドレス許可リストを管理するという「間接的な認証」に頼るしかありませんでした。
しかし2026年2月、Amazon CloudFrontがオリジン向けの相互TLS（mTLS）認証をサポートしました。これにより、ビューワー→CloudFront→オリジンというリクエストパス全体を、証明書ベースの暗号化された相互認証でつなぐことが可能になりました。
今回は、この新機能を実際に試しながら、ゼロトラストアーキテクチャの観点からその意義を解説します。
mTLS（相互TLS）とは？
通常のTLSでは、クライアントはサーバーの証明書を検証してサーバーの身元を確認します。これに対してmTLS（Mutual TLS）では、サーバーもクライアントの証明書を検証し、両者が互いに身元を証明し合います。
- クライアント証明書による暗号的なID証明
- 認証情報ベースの攻撃（なりすまし、中間者攻撃）の防止
- 分散システム全体でのゼロトラスト原則の実現
金融サービス（PCI DSS・PSD2準拠）、IoTデバイス、エンタープライズのマイクロサービス間通信など、高い信頼性が求められる場面で広く採用されています。
CloudFront オリジン mTLS の全体像
今回のアップデートで実現したのは、エンドツーエンドの完全な相互認証パスです。
- ビューワー→CloudFront: ビューワーmTLS（2025年11月24日リリース済み）
- CloudFront→オリジン: オリジンmTLS（2026年2月リリース）← 今回の機能
CloudFrontはACM（AWS Certificate Manager）にインポートしたクライアント証明書を使って、オリジンとのTLSハンドシェイクを行います。オリジン側でこの証明書を検証することで、CloudFront以外からの直接アクセスを防ぐことができます。
対応オリジン: Application Load Balancer、API Gateway、オンプレミスサーバー、カスタムオリジン（追加料金なし）
実際にやってみた――API GatewayをオリジンとしたmTLS設定
今回は、カスタムドメインで相互TLS認証を有効にしたAPI Gatewayをオリジンとして構成してみます。
1. 証明書の準備
まずOpenSSLでルートCAとクライアント証明書を作成します。
# ルートCAの秘密鍵を生成
openssl genrsa -out RootCA.key 4096
# ルートCA証明書を生成（有効期間: 10年）
openssl req -new -x509 -days 3650 -key RootCA.key \
-out RootCA.pem -subj "/C=JP/ST=Tokyo/O=Ragate/CN=RagateRootCA"
# クライアントの秘密鍵を生成
openssl genrsa -out my-client.key 2048
# CSRを生成（EKU拡張領域の設定を忘れずに）
openssl req -new -key my-client.key -out my-client.csr \
-subj "/C=JP/ST=Tokyo/O=Ragate/CN=cloudfront-client" \
-addext "basicConstraints = CA:FALSE" \
-addext "keyUsage = digitalSignature" \
-addext "extendedKeyUsage = clientAuth"
# ルートCAで署名（有効期間: 1年）
openssl x509 -req -days 365 \
-in my-client.csr -CA RootCA.pem -CAkey RootCA.key \
-CAcreateserial -copy_extensions copyall -out my-client.pem2. トラストストアの準備とS3へのアップロード
API Gatewayが信頼するCA証明書をS3に配置します。
# ルートCA証明書をトラストストアとしてコピー
cp RootCA.pem truststore.pem
# S3にアップロード
aws s3 cp truststore.pem s3://your-bucket-name/truststore.pem3. ACMへのクライアント証明書インポート
CloudFrontがオリジンに提示するクライアント証明書をACMに登録します。重要：リージョンはus-east-1（CloudFrontの要件）にしてください。
aws acm import-certificate \
--certificate fileb://my-client.pem \
--private-key fileb://my-client.key \
--certificate-chain fileb://RootCA.pem \
--region us-east-1 \
--query 'CertificateArn' --output text4. CloudFrontディストリビューションの設定
AWSコンソールでCloudFrontディストリビューションのオリジン設定を開き、mTLSを有効化してACMにインポートしたクライアント証明書を選択します。
設定項目 | 値 |
|---|---|
オリジンタイプ | カスタムオリジン（Other） |
オリジン設定 | mTLSを有効化 |
クライアント証明書 | ACMからインポートした証明書を選択 |
オリジンリクエストポリシー |
|
AWS CLIやCDK、CloudFormationでも設定可能です。
ハマったポイント・注意点
- CSRのEKU拡張（extendedKeyUsage = clientAuth）が必須: これを忘れるとAPI Gateway側でクライアント証明書の検証が失敗します
- ACMのリージョンはus-east-1固定: CloudFrontはus-east-1のACM証明書のみ参照できます
- 証明書の有効性検証はオリジン側の責務: CloudFrontはTLSハンドシェイクでクライアント証明書を提示しますが、失効確認などの詳細な検証はオリジン側で実装が必要です（API Gatewayは自動検証、カスタムオリジンは自前実装が必要）
- CRLは非サポート: ビューワーmTLSのトラストストアはCRL（証明書失効リスト）非対応。失効証明書の制御はConnection FunctionとKeyValue Storeを組み合わせる必要があります
実際に運用してみた結果
この設定を導入することで、以下のメリットが得られました。
- カスタムヘッダーの管理が不要に: シークレット文字列のローテーションや管理が不要。証明書の有効期限管理に集約
- オリジンへの直接アクセスをTLSレベルでブロック: IP制限では対応できないシナリオでも確実に防御
- 監査・コンプライアンス対応が容易に: コネクションログで接続ごとにconnectionId・証明書情報・TLSハンドシェイク時間が記録される
まとめ――ゼロトラストへの一歩
Amazon CloudFrontのオリジンmTLSサポートは、「エッジでのパフォーマンスを維持しながらゼロトラストを実現する」という難しい課題に対する明確な答えです。
ビューワーmTLS（2025年12月）とオリジンmTLS（2026年2月）の組み合わせにより、クライアント→CloudFront→オリジンの全経路で証明書ベースの相互認証が実現しました。暗黙の信頼を排除し、すべての接続を明示的に検証する——このゼロトラストの原則をCDNレイヤーで実装できるようになったことは、金融・IoT・ヘルスケアなど高セキュリティ要件のシステムにとって大きな前進です。
私たちRagateも、クライアントのセキュリティ要件に応じてこの機能を積極的に提案・導入していきます。ご相談はお気軽にどうぞ。
