相互TLS認証 - AWS App Mesh
相互TLS認証証明書メッシュエンドポイントの設定サービスを相互TLS認証に移行する相互TLS認証の検証App Mesh 相互TLS認証のチュートリアル

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

相互TLS認証

重要

サポート終了通知: 2026 年 9 月 30 日、 は のサポートを中止 AWS します AWS App Mesh。2026 年 9 月 30 日以降、 AWS App Mesh コンソールまたは AWS App Mesh リソースにアクセスできなくなります。詳細については、このブログ記事の「 から Amazon ECS Service Connect AWS App Mesh への移行」を参照してください。

相互 TLS (トランスポートレイヤーセキュリティ) 認証は、双方向ピア認証TLSを提供する のオプションコンポーネントです。相互TLS認証は、 にセキュリティレイヤーを追加TLSし、サービスが接続を行っているクライアントを検証できるようにします。

クライアントとサーバーの関係にあるクライアントは、セッションネゴシエーションプロセス中に X.509 証明書も提供します。サーバーは、この証明書を使用してクライアントを識別し、認証します。このプロセスは、証明書が信頼できる認証局 (CA) によって発行されたかどうか、また、証明書が有効な証明書であるかどうかを確認するのに役立ちます。また、証明書のサブジェクト代替名 (SAN) を使用してクライアントを識別します。

でサポートされているすべてのプロトコルで相互TLS認証を有効にできます AWS App Mesh。これらは TCP、HTTP/1.1、HTTP/2、g ですRPC。

注記

App Mesh を使用すると、サービスからの Envoy プロキシ間の通信の相互TLS認証を設定できます。ただし、アプリケーションとEnvoy プロキシ間の通信は暗号化されません。

相互TLS認証証明書

AWS App Mesh は、相互TLS認証用に 2 つの可能な証明書ソースをサポートします。クライアントポリシーのTLSクライアント証明書とリスナーTLS設定のサーバー検証は、以下から取得できます。

  • ファイルシステム—実行中の Envoy プロキシのローカルファイルシステムからの証明書。Envoy に証明書を配布するには、証明書チェーンのファイルパスと App Mesh へのプライベートキーを指定する必要がありますAPI。

  • Envoy's Secret Discovery Service (SDS) – Bring-your-own 証明書を実装SDSして Envoy に送信できるようにするサイドカー。これにはSPIFFE、ランタイム環境 () が含まれますSPIRE。

重要

App Mesh は、相互TLS認証に使用される証明書やプライベートキーを保存しません。代わりに、Envoy が、それらをメモリに保存します。

メッシュエンドポイントの設定

仮想ノードやゲートウェイなど、メッシュエンドポイントの相互TLS認証を設定します。これらのエンドポイントは、証明書を提供し、信頼できる権限を指定します。

これを行うには、クライアントとサーバーの両方に X.509 証明書をプロビジョニングし、TLS終了とオTLSリジンの両方の検証コンテキストで信頼された権限証明書を明示的に定義する必要があります。

メッシュの内部を信頼する

サーバー側の証明書は Virtual Node リスナー (TLS終了) で設定され、クライアント側の証明書は Virtual Nodes サービスバックエンド (TLSオリジン) で設定されます。この設定の代わりに、仮想ノードのすべてのサービスバックエンドに対してデフォルトのクライアントポリシーを定義し、必要に応じて特定のバックエンドに対してこのポリシーを上書きできます。仮想ゲートウェイは、そのすべてのバックエンドに適用されるデフォルトのクライアントポリシーでのみ設定できます。

両方のメッシュの Virtual Gateways のインバウンドトラフィックの相互TLS認証を有効にすることで、異なるメッシュ間で信頼を設定できます。

メッシュの外側を信頼する

Virtual Gateway リスナーでサーバー側の証明書を指定してTLS終了します。仮想ゲートウェイと通信する外部サービスを設定して、クライアント側の証明書を提示します。証明書は、サーバー側の証明書がTLS発信のために Virtual Gateway リスナーで使用するのと同じ認証機関 (CAs) のいずれかから取得する必要があります。

サービスを相互TLS認証に移行する

App Mesh 内の既存のサービスを相互TLS認証に移行する際に接続を維持するには、以下のガイドラインに従ってください。

プレーンテキストで通信するサービスを移行する

  1. サーバーエンドポイントTLSの設定でPERMISSIVEモードを有効にします。このモードでは、プレーンテキストトラフィックがエンドポイントに接続できるようになります。

  2. サーバーで相互TLS認証を設定し、サーバー証明書、信頼チェーン、およびオプションで信頼された を指定しますSANs。

  3. TLS 接続を介して通信が発生していることを確認します。

  4. クライアントで相互TLS認証を設定し、クライアント証明書、信頼チェーン、およびオプションで信頼された を指定しますSANs。

  5. サーバー上のTLS設定の有効化STRICTモード。

通信するサービスの移行 TLS

  1. クライアントで相互TLS設定を設定し、クライアント証明書とオプションで信頼できる を指定しますSANs。クライアント証明書は、バックエンドサーバーが要求するまでバックエンドに送信されません。

  2. サーバーで相互TLS設定を設定し、信頼チェーンとオプションで信頼された を指定しますSANs。このため、サーバーは、クライアント証明書をリクエストします。

相互TLS認証の検証

Transport Layer Security: Verify 暗号化ドキュメントを参照して、Envoy が TLS関連の統計を正確に出力する方法を確認できます。相互TLS認証については、次の統計を調べる必要があります。

  • ssl.handshake

  • ssl.no_certificate

  • ssl.fail_verify_no_cert

  • ssl.fail_verify_san

次の 2 つの統計例は、仮想ノードへの正常なTLS接続がすべて証明書を提供したクライアントから終了したことを示しています。

listener.0.0.0.0_15000.ssl.handshake: 3
listener.0.0.0.0_15000.ssl.no_certificate: 0

次の統計例は、仮想クライアントノード (またはゲートウェイ) からバックエンドの仮想ノードへの接続に失敗したことを表しています。サーバー証明書に表示されるサブジェクト代替名 (SAN) が、クライアントがSANs信頼する名前と一致しません。

cluster.cds_egress_my-mesh_my-backend-node_http_9080.ssl.fail_verify_san: 5

App Mesh 相互TLS認証のチュートリアル