Amazon Web Services ブログ
AWS Certificate Manager またはお客様が提供する証明書を使用して、AWS App Mesh のサービス間のトラフィック暗号化を可能に
本日、AWS Certificate Manager (ACM) またはお客様が提供する証明書を使用して、サービス間のトラフィック暗号化を可能にする AWS App Mesh 機能を一般公開しました。昨年、AWS App Mesh ロードマップの問題 #38 および #39 を通じてお客様からのフィードバックを求め、お客様が試用できるよう、AWS App Mesh Preview Channel で機能を利用できるようにしました。
メッシュアーキテクチャを構築するお客様は、サービス間のトラフィックの暗号化を要求するセキュリティおよびコンプライアンスのベースラインを有している場合があります。さらに、TLS の使用を強制し、アップストリームサービスからの証明書を検証することは、ゼロトラストネットワークの重要な側面です。この機能を使用すると、接続が安全であり、トラフィックが信頼できるサービスに送信されることを保証できます。
App Mesh では、仮想ノード間、そしてサービスメッシュの Envoy 間でトラフィック暗号化が行われます。これは、アプリケーションコードが TLS 暗号化セッションのネゴシエーションに責任を負わず、ローカルプロキシがアプリケーションに代わって TLS の交渉および終了を行うことを許可することを意味します。
図 1: 使用中の AWS インフラストラクチャのコンテキストでのサービス間のトラフィック暗号化フロー
仮想ノードの証明書ソース: ACM およびお客様が提供する証明書
GitHub ロードマップの問題 #38 では、ローカルファイルシステムから証明書を取得する機能を追加し、問題 #39 では、ACM から仮想ノードの証明書を取得する機能を追加しました。仮想ノードの証明書を設定する場合、お客様は、これらの利用可能なソースのいずれかを選択できます。
図 2: ACM 管理の証明書を使用した AWS App Mesh トラフィック暗号化
ACM を使用して証明書を管理することを好むお客様もいます。このオプションを使用すると、ACM は有効期限が近づいている証明書を自動的に更新し、App Mesh は更新された証明書を自動的に配布します。ウォークスルーの引例の 1 つを使用して、図 2 は、ACM を使用したゲートウェイと ColorTeller 仮想ノード (白と緑) の間のトラフィック暗号化を示しています。
注意: 上記の図 2 の引例は、GitHub で利用可能なサンプルウォークスルーを使用してテストできます。例へのリンクは、以下の「実践的なウォークスルーとドキュメント」セクションでも利用できます。
仮想ノードバックエンドの設定: クライアントポリシーおよびクライアントポリシーのデフォルト
接続されたサービス間の関係について考えるとき、クライアント (トラフィックを送信するエンティティ) とサーバー (そのトラフィックを受信するエンティティ) の標準的な用語でこの関係が議論されることが多くあります。App Mesh では、仮想ノードリソースに新たな要素を追加してこれらの概念を表しています。
App Mesh では、仮想ノードのバックエンドは、仮想ノードが通信するために必要な既知の宛先と考えることができます。このように、バックエンドは、クライアントとサーバーの関係におけるサーバーです。これらのバックエンドは、他のチームまたは組織がしばしば所有する App Mesh の仮想サービスとして表されます。仮想サービスの所有者が、再試行戦略やヘルスチェック設定など、クライアントに自動的に配布される設定を定義できるようにすることで、クライアントとサーバー間の復元力のある接続をできる限り容易にします。
ただし、多くの場合、サーバーが提供できない、または提供すべきでない設定をクライアントが指定する必要があります。TLS の場合、クライアントは、通信しているサーバー (バックエンド) が本物で信頼できることを検証するために、信頼する認証機関を示す必要があります。
クライアントの観点からさまざまな設定を指定するニーズをサポートするために、「ClientPolicy」と呼ばれる新しい概念を仮想ノードのバックエンドに追加しています。また、これらの設定は多くの場合、仮想ノードのバックエンドの多くまたはすべてで同じであることも認識しています。このニーズをサポートするため、仮想ノードにさらに「backendDefaults」の概念を導入し、お客様がすべてのバックエンドに適用されるデフォルト設定を提供できるようにします。バックエンドのデフォルトは、必要に応じてバックエンドごとにオーバーライドできます。
現在、Client Policy の設定は、TLS の発信および検証に固有の設定を追加しますが、将来的にはカスタムタイムアウトなどのクライアントの追加設定をサポートするために拡張される予定です。TLS 固有の設定の場合、お客様は、TLS を強制するかどうか (つまり、交渉が試行され、できない場合は接続が失敗することとするかどうか)、さらにオプションで、強制するポート、および証明書の検証時に使用する認証機関を指定できます。証明機関が使用するために、お客様は、以下の 2 つの選択肢から選択できます。
- ACM Private Certificate Authorities のセット
- 複数のルート認証機関 (つまり、トラストバンドル) がインストールされているローカルファイルシステムへの参照
ACM 認証機関 ARN を使用した仮想ノードバックエンドクライアントポリシーの強制
次の例は、仮想サービスの仮想ノードのバックエンドに設定されたクライアントポリシーを示しています。これは、信頼できる認証機関 (CA) として ACM のみを使用してポート 443 で TLS の使用を強制します。trust
acm
セクション内での ACM Private Certificate Authority (PCA) の使用に注意してください。
注意: 上記の例では、クライアントポリシーの TLS 設定の
強制
とポート
は、両方ともオプションです。指定しない場合、デフォルトですべてのポートに TLS が強制されます。
アップストリーム証明書を検証するときに使用する最大 10 個の ACM 認証機関 ARN を指定できます。認証機関の 1 つがアップストリーム証明書に署名している場合、それは有効とみなされます。
お客様が提供する証明書を使用した仮想ノードバックエンドクライアントポリシーの強制
TLS を強制する一般的なパターンは、ローカルファイルシステムでデフォルトの信頼チェーン (または他のローカルに保存されたチェーン) を使用して、アップストリームサービスの証明書を検証することです。ほとんどのオペレーティングシステムには、パブリックサービスの検証に使用できるルート認証機関のバンドルが付属しています。
次の例は、ローカルファイルシステムを使用してポート 443 で TLS を強制し、アップストリームサービスの証明書を検証するために使用される認証機関を導出するクライアントポリシーを示しています。
料金
ACM から取得した証明書を使用する場合、お客様は、各 AWS Certificate Manager Private Certificate Authority を削除するまで、それぞれについての操作に対して月額料金を支払います。お客様は、毎月発行されるプライベート証明書とエクスポートされるプライベート証明書についても支払います。詳細については、AWS Certificate Manager の料金表を参照してください。
実践的なウォークスルーとドキュメント
この機能を試すには、App Mesh サンプルリポジトリ内の GitHub ウォークスルーを使用して、以下にリンクされている両方の機能をテストできます。これらの例では、連続性および説明の容易さを企図して、以前に使用された Color App を使用しています。
- ACM ソース証明書のウォークスルー: https://github.com/aws/aws-app-mesh-examples/tree/master/walkthroughs/tls-with-acm
- お客様が提供する証明書のウォークスルー: https://github.com/aws/aws-app-mesh-examples/tree/master/walkthroughs/howto-tls-file-provided
これらの機能の詳細とガイダンスについては、AWS App Mesh ドキュメントの Transport Layer Security (TLS) セクションを参照してください。AWS App Mesh ロードマップチャンネルを通じてフィードバックをお寄せください。ぜひこの機能を使用して、安全でコンプライアントなメッシュアプリケーションを構築してください!