翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# App Mesh セキュリティのトラブルシューティング
**重要**
サポート終了通知: 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)」を参照してください。
このトピックでは、App Mesh セキュリティで発生する可能性のある一般的な問題を詳細に説明します。
## TLS クライアントのポリシーを使用してバックエンド仮想サービスに接続できない
**症状**
TLS クライアントのポリシーを仮想ノードの仮想サービスバックエンドに追加すると、そのバックエンドへの接続が失敗します。バックエンドサービスにトラフィックを送信しようとすると、リクエストは`HTTP 503` レスポンスコードとエラーメッセージ:`upstream connect error or disconnect/reset before headers. reset reason: connection failure` で失敗します。
**解決策**
問題の根本原因を特定するには、問題の診断に役立つ Envoy プロキシプロセスログを使用することをお勧めします。詳細については、「[本番稼働前の環境で、Envoy デバッグログを有効にする](troubleshooting-best-practices.md#ts-bp-enable-envoy-debug-logging)」を参照してください。次のリストを使用して、接続障害の原因を特定します。
+ [仮想サービスのバックエンドに接続できない](troubleshooting-connectivity.md#ts-connectivity-virtual-service-backend) で説明されているエラーを除外して、バックエンドへの接続が成功していることを確認します。
+ Envoy プロセスログで、次のエラー (デバッグレベルで記録される) を探します。
```
TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED
```
次の問題のいずれかが原因で、このエラーが発生します。
+ 証明書は、TLS クライアントのポリシーの信頼バンドルで定義されている認証局の 1 つによって署名されていませんでした。
+ 証明書は無効です(期限切れ)。
+ サブジェクト別名 (SAN) がリクエストされた DNS ホスト名と一致しません。
+ バックエンドサービスによって提供される証明書が有効であること、TLS クライアントポリシーの信頼バンドル内のいずれかの認証局によって署名されていること、および [Transport Layer Security (TLS)](tls.md) で定義されている基準を満たしていることを確認します。
+ 次のようなエラーが表示される場合は、リクエストが Envoy プロキシをバイパスしてアプリケーションに直接到達していることを意味します。トラフィックを送信しても、Envoy の統計は変化せず、Envoy がトラフィックを復号する経路上にいないことがわかります。仮想ノードのプロキシ設定で、`AppPorts` にアプリケーションがリッスンしている正しい値が含まれていることを確認してください。
```
upstream connect error or disconnect/reset before headers. reset reason: connection failure, transport failure reason: TLS error: 268435703:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER
```
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue-bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。セキュリティの脆弱性が見つかったと思われる場合、または App Mesh のセキュリティについて質問がある場合は、「[AWS 脆弱性レポートガイドライン](https://aws.amazon.com/security/vulnerability-reporting/)」を参照してください。
## アプリケーションが TLS を発信しているときにバックエンド仮想サービスに接続できない
**症状**
Envoy プロキシからではなく、アプリケーションから TLS セッションを開始すると、バックエンド仮想サービスへの接続が失敗します。
**解決策**
これは既知の問題です。詳細については、GitHub issue の「[機能リクエスト: ダウンストリームアプリケーションとアップストリームプロキシ間の TLS ネゴシエーション](https://github.com/aws/aws-app-mesh-roadmap/issues/162)」を参照してください。App Mesh では、TLS 発信は、現在 Envoy プロキシからサポートされていますが、アプリケーションからはサポートされていません。Envoy で TLS 発信 Support を使用するには、アプリケーションでの TLS 発信を無効にします。これにより、Envoy はアウトバウンドリクエストヘッダーを読み取り、TLS のセッションを介してリクエストを適切な宛先に転送できます。詳細については、「[Transport Layer Security (TLS)](tls.md)」を参照してください。
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。セキュリティの脆弱性が見つかったと思われる場合、または App Mesh のセキュリティについて質問がある場合は、「[AWS 脆弱性レポートガイドライン](https://aws.amazon.com/security/vulnerability-reporting/)」を参照してください。
## Envoy プロキシ間の接続が TLS を使用していることをアサートできません
**症状**
アプリケーションが仮想ノードまたは仮想ゲートウェイのリスナーで TLS 終了、またはバックエンド TLS クライアントのポリシーで TLS 発信を有効にしていますが、TLS ネゴシエートされたセッションで Envoy プロキシ間の接続が発生していることをアサートできません。
**解決策**
この解決法で定義されているステップは、Envoy 管理インターフェイスと Envoy 統計を使用します。これらの設定については、「[Envoy プロキシ管理インターフェイスを有効にする](troubleshooting-best-practices.md#ts-bp-enable-proxy-admin-interface)」と「[メトリクスオフロードの Envoy dogStatsD 統合を有効にする](troubleshooting-best-practices.md#ts-bp-enable-envoy-statsd-integration)」を参照してください。次の統計例では、簡単にするために管理インターフェイスを使用しています。
+ TLS 終了を実行する Envoy プロキシの場合:
+ 次のコマンドを使用して、TLS 証明書が Envoy 設定でブートストラップされていることを確認してください。
```
curl http://my-app.default.svc.cluster.local:9901/certs
```
返される出力には、TLSターミネーションで使用される証明書の `certificates[].cert_chain` の下に少なくとも1つのエントリが表示されます。
+ 次のコマンドと出力の例に示すように、プロキシのリスナーへの正常なインバウンド接続の数が、SSL ハンドシェイクの数に再利用された SSL セッションの数を加えたものと正確に同じであることを確認してください。
```
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep downstream_cx_total
listener.0.0.0.0_15000.downstream_cx_total: 11
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep ssl.connection_error
listener.0.0.0.0_15000.ssl.connection_error: 1
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep ssl.handshake
listener.0.0.0.0_15000.ssl.handshake: 9
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep ssl.session_reused
listener.0.0.0.0_15000.ssl.session_reused: 1
# Total CX (11) - SSL Connection Errors (1) == SSL Handshakes (9) + SSL Sessions Re-used (1)
```
+ TLS 発信を実行する Envoy プロキシの場合:
+ 次のコマンドを使用して、TLS 信頼ストアが Envoy 設定でブートストラップされていることを確認してください。
```
curl http://my-app.default.svc.cluster.local:9901/certs
```
TLS の発信中にバックエンドの証明書を検証する際に使用される証明書について、`certificates[].ca_certs` の下に少なくとも1つのエントリが表示されます。
+ 次のコマンドと出力の例に示すように、バックエンドのクラスターへの正常なアウトバウンド接続の数が、SSL ハンドシェイクの数に再利用された SSL セッションの数を加えたものと正確に同じであることを確認してください。
```
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep upstream_cx_total
cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.upstream_cx_total: 11
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep ssl.connection_error
cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.ssl.connection_error: 1
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep ssl.handshake
cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.ssl.handshake: 9
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep ssl.session_reused
cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.ssl.session_reused: 1
# Total CX (11) - SSL Connection Errors (1) == SSL Handshakes (9) + SSL Sessions Re-used (1)
```
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。セキュリティの脆弱性が見つかったと思われる場合、または App Mesh のセキュリティについて質問がある場合は、「[AWS 脆弱性レポートガイドライン](https://aws.amazon.com/security/vulnerability-reporting/)」を参照してください。
## Elastic Load Balancing を使用した TLS のトラブルシューティング
**症状**
仮想ノードへのトラフィックを暗号化するように Application Load Balancer または Network Load Balancer を設定しようとすると、接続とロードバランサーのヘルスチェックが失敗することがあります。
**解決策**
問題の根本原因を特定するには、次の点をチェックする必要があります。
+ TLS 終了を実行する Envoy プロキシでは、設定ミスを除外する必要があります。上記の「[TLS クライアントのポリシーを使用してバックエンド仮想サービスに接続できない](#ts-security-tls-client-policy)」の手順に従います。
+ ロードバランサーの場合は、`TargetGroup:` 設定を確認する必要がある
+ `TargetGroup` ポートが仮想ノードの定義済みリスナーポートと一致していることを確認してください。
+ HTTP を介してサービスへの TLS 接続を発信しているアプリケーションロードバランサーの場合、`TargetGroup` プロトコルが `HTTPS` に設定されていることを確認してください。ヘルスチェックを利用している場合は、`HealthCheckProtocol` が `HTTPS` に設定されていることを確認してください。
+ TCP を介してサービスへの TLS 接続を発信しているネットワークロードバランサーの場合、`TargetGroup` プロトコルが `TLS` に設定されていることを確認してください。ヘルスチェックを利用している場合は、`HealthCheckProtocol` が `TCP` に設定されていることを確認してください。
**注記**
`TargetGroup` へのすべての更新では、`TargetGroup` 名を変更する必要があります。
これが適切に設定されている場合、ロードバランサーは、Envoy プロキシに提供された証明書を使用して、サービスへの安全な接続を提供する必要があります。
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。セキュリティの脆弱性が見つかったと思われる場合、または App Mesh のセキュリティについて質問がある場合は、「[AWS 脆弱性レポートガイドライン](https://aws.amazon.com/security/vulnerability-reporting/)」を参照してください。