翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 相互 TLS 認証
**重要**
サポート終了通知: 2026 年 9 月 30 日、 AWS はサポートを終了します AWS App Mesh。2026 年 9 月 30 日以降、 AWS App Mesh コンソールまたは AWS App Mesh リソースにアクセスできなくなります。詳細については、このブログ記事[「 から Amazon ECS Service Connect AWS App Mesh への移行](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)」を参照してください。
相互 TLS (Transport Layer Security) 認証は、TLSのオプションコンポーネントで、双方向のピア認証を提供します。相互 TLS 認証は、TLS 上にセキュリティレイヤーを追加し、お客様のサービスが接続を行うクライアントを確認することを可能にします。
クライアントとサーバーの関係にあるクライアントは、セッションネゴシエーションプロセス中に X.509 証明書も提供します。サーバーは、この証明書を使用してクライアントを識別し、認証します。このプロセスは、証明書が信頼できる認証局 (CA) によって発行されたかどうか、また、証明書が有効な証明書であるかどうかを確認するのに役立ちます。また、証明書のサブジェクト別名 (SAN) を使用してクライアントを識別します。
でサポートされているすべてのプロトコルで相互 TLS 認証を有効にできます AWS App Mesh。TCP、HTTP/1.1、HTTP/2、gRPC があります。
**注記**
App Mesh を使用して、サービスからの Envoy プロキシ間の通信に対して相互 TLS 認証を設定できます。ただし、アプリケーションとEnvoy プロキシ間の通信は暗号化されません。
## 相互 TLS 認証証明書
AWS App Mesh は、相互 TLS 認証用に 2 つの可能な証明書ソースをサポートします。TLS クライアントポリシーのクライアント証明書とリスナー TLS 設定でのサーバー検証を、次のものからソースできます。
+ **ファイルシステム—**実行中の Envoy プロキシのローカルファイルシステムからの証明書。Envoy に証明書を配布するには、App Mesh API に証明書チェーンとシークレットキーのファイルパスを指定する必要があります。
+ **Envoy の Secret Discovery Service (SDS) —**SDSを実装し、証明書をEnvoyに送信できるようにする独自のサイドカーを持参してください。それらには、SPIFFE ランタイム環境(SPIRE)が含まれます。
**重要**
App Mesh は、相互 TLS 認証に使用される証明書またはシークレットキーを保存しません。代わりに、Envoy が、それらをメモリに保存します。
## メッシュエンドポイントの設定
仮想ノードやゲートウェイなど、メッシュエンドポイントの相互 TLS 認証を設定します。これらのエンドポイントは、証明書を提供し、信頼できる権限を指定します。
これを行うには、クライアントとサーバーの両方に X.509 証明書をプロビジョニングし、TLS 終了と TLS 発信の両方の検証コンテキストで信頼できる機関証明書を明示的に定義する必要があります。
**メッシュの内部を信頼する**
サーバー側の証明書は仮想ノードリスナー (TLS 終了) で設定され、クライアント側の証明書は仮想ノードサービスバックエンド (TLS 発信) で構成されます。この設定の代わりに、仮想ノードのすべてのサービスバックエンドに対してデフォルトのクライアントポリシーを定義し、必要に応じて特定のバックエンドに対してこのポリシーを上書きできます。仮想ゲートウェイは、そのすべてのバックエンドに適用されるデフォルトのクライアントポリシーでのみ設定できます。
両方のメッシュの仮想ゲートウェイでインバウンドトラフィックの相互 TLS 認証を有効にすることで、異なるメッシュ間で信頼を設定できます。
**メッシュの外側を信頼する**
TLS 終了の仮想ゲートウェイリスナーでサーバー側の証明書を指定します。仮想ゲートウェイと通信する外部サービスを設定して、クライアント側の証明書を提示します。証明書は、サーバー側の証明書が TLS 発信の仮想ゲートウェイリスナーで使用するのと同じ認定権限 (CA) の 1 つから取得する必要があります。
## 相互 TLS 認証にサービスを移行する
App Mesh内の既存のサービスを相互 TLS 認証に移行する場合は、これらのガイドラインに従って接続を維持してください。
**プレーンテキストで通信するサービスを移行する**
1. サーバーエンドポイントの TLS 設定の `PERMISSIVE` モードを有効にします。このモードでは、プレーンテキストトラフィックがエンドポイントに接続できるようになります。
1. サーバーの相互 TLS 認証を設定し、サーバー証明書、トラストチェーン、およびオプションで信頼できる SAN を指定します。
1. TLS 接続を介して通信が行われていることを確認します。
1. クライアントで相互 TLS 認証を設定し、クライアント証明書、トラストチェーン、およびオプションで信頼できるSANを指定します。
1. サーバーの TLS 設定に `STRICT` モードを有効にします。
**TLS 経由で通信するサービスの移行**
1. クライアントで相互 TLS 設定をし、クライアント証明書、そしてオプションで信頼された SAN を指定します。クライアント証明書は、バックエンドサーバーが要求するまでバックエンドに送信されません。
1. サーバーで相互 TLS 設定をし、トラストチェーン、およびオプションで信頼された SAN を指定します。このため、サーバーは、クライアント証明書をリクエストします。
## 相互 TLS 認証の検証
Envoy が具体的にどのように TLS 関連の統計を出すかは、「[Transport Layer Security: 暗号化の検証](https://docs.aws.amazon.com/app-mesh/latest/userguide/tls.html#verify-encryption)」ドキュメントを参照してください。相互 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) が、クライアントが信頼する SAN のいずれとも一致していません。
```
cluster.cds_egress_my-mesh_my-backend-node_http_9080.ssl.fail_verify_san: 5
```
## App Mesh 相互 TLS 認証のウォークスルー
+ [相互 TLS 認証のウォークスルー](https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/howto-mutual-tls-file-provided)：このウォークスルーでは、App Mesh CLIを使用して、相互 TLS 認証によるカラーアプリを構築する方法について説明します。
+ [Amazon EKS 相互TLS SDS ベースのウォークスルー](https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/howto-k8s-mtls-sds-based):このウォークスルーでは、Amazon EKSとSPIFFE ランタイム環境 (SPIRE) で、相互 TLS SDS ベースの認証を使用する方法を紹介します。
+ [Amazon EKS 相互 TLS ファイルベースのウォークスルー](https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/howto-k8s-mtls-file-based): このウォークスルーでは、Amazon EKS と SPIFFE ランタイム環境 (SPIRE) で、相互TLSファイルベース認証を使用する方法を紹介します。