Application Load Balancer の相互認証により、証明書ベースのクライアント ID が確実に検証されます

11月26日、Application Load Balancer に X509 証明書を提示する相互認証クライアントのサポートについてお知らせします。この新機能により、クライアント認証をロードバランサーにオフロードして、信頼できるクライアントだけがバックエンドアプリケーションと通信できるようになります。この新機能は、強力な暗号化とゼロデイ脆弱性からの保護を提供するAWSのオープンソース Transport Layer Security (TLS) 実装である S2N に基づいて構築されており、開発者はこれを信頼できます。

相互認証 (mTLS) は、オンラインバンキング、自動車、ゲームデバイスなどの企業間 (B2B) アプリケーションで、デジタル証明書を使用してデバイスを認証するためによく使用されます。企業は通常、データやサービスへのアクセスを許可する前に、プライベート認証局 (CA) とともにクライアントを認証します。

お客様は、自分で作成したソリューションまたはサードパーティのソリューションを使用して相互認証を実装しており、追加の時間と管理オーバーヘッドが必要です。これらの顧客は、エンジニアリングリソースを費やしてバックエンドに機能を組み込んだり、最新のセキュリティパッチに対応するようにコードを更新したり、証明書を作成および更新するためのインフラストラクチャに多額の投資を行ったりしています。

Application Load Balancer での相互認証により、完全に管理されたスケーラブルで費用対効果の高いソリューションが実現し、開発者リソースを他の重要なプロジェクトに集中できるようになります。ALB は失効チェックでクライアントを認証し、クライアント証明書情報をターゲットに渡します。この情報はアプリケーションによる承認に使用できます。

ALB での相互認証の開始方法
ALB で相互認証を有効にするには、Amazon EC2 コンソールの ALB ウィザードで [ Application Load Balancer の作成] を選択します。リスナーとルーティングのセクションで [HTTPS] を選択すると、セキュリティポリシー、デフォルトサーバー証明書、相互認証をサポートする新しいクライアント証明書処理オプションなど、その他の設定が表示されます。

相互認証 (mTLS) を有効にすると、クライアント証明書を提示するリクエストをリスナーがどのように処理するかを設定できます。これには、Application Load Balancer が証明書を認証する方法と、バックエンドターゲットに送信される証明書メタデータの量が含まれます。

相互認証には 2 つのオプションがあります。Passthrough オプションは、クライアントから受信したすべてのクライアント証明書チェーンを、HTTP ヘッダーを使用してバックエンドアプリケーションに送信します。MTLS 対応の Application Load Balancer は、ハンドシェイクでクライアント証明書を取得し、TLS 接続を確立して、HTTPS ヘッダーで取得したものをターゲットアプリケーションに送信します。アプリケーションは、クライアントを認証するためにクライアント証明書チェーンを検証する必要があります。

トラストストアで検証オプションを使用すると、Application Load Balancer とクライアントは互いの ID を検証し、TLS 接続を確立して両者間の通信を暗号化します。新しいトラストストア機能が導入されました。AWS Private Certificate Authority またはその他のサードパーティ CA によって生成されたルート証明書や中間証明書を含む CA バンドルを信頼するソースとしてアップロードして、クライアント証明書を検証できます。

既存のトラストストアを選択するか、新しいトラストストアを作成する必要があります。トラストストアには、CA、信頼できる証明書、およびオプションで証明書失効リスト (CRL) が含まれます。ロードバランサーはトラストストアを使用してクライアントとの相互認証を行います。

このオプションを使用して新しいトラストストアを作成するには、Amazon EC2 コンソールの左側のメニューで [トラストストア] を選択し、[トラストストアの作成] を選択します。

PEM 形式の CA 証明書バンドルを選択し、オプションで Amazon Simple Storage Service (Amazon S3) バケットから CRL を選択できます。CA 証明書バンドルは、トラストストアで使用される CA 証明書 (ルートまたは中間) のグループです。CRL は、侵害されたクライアント証明書を CA が取り消し、その失効した証明書を拒否する必要がある場合に使用できます。CA バンドルを置き換えたり、作成後に CRL をトラストストアに追加したり、トラストストアから削除したりできます。

Create-trust-store などの新しい API で AWS コマンドラインインターフェイス (AWS CLI) を使用して、CA 情報をアップロードしたり、Application Load Balancer リスナーで mutual-authentication-mode を設定したり、ユーザー証明書情報をターゲットに送信したりできます。

$ aws elbv2 create-trust-store --name my-tls-name \
    --ca-certificates-bundle-s3-bucket channy-certs \
    --ca-certificates-bundle-s3-key Certificates.pem \
    --ca-certificates-bundle-s3-object-version <version>
>> arn:aws:elasticloadbalancing:root:file1
$ aws elbv2 create-listener --load balancer-arn <value> \
    --protocol HTTPS \
    --port 443 \
    --mutual-authentication Mode=verify,
      TrustStoreArn=<arn:aws:elasticloadbalancing:root:file1>

AWS プライベート CA、サードパーティ CA、自己署名 CA など、独自のプライベート CA を既にお持ちの場合は、その CA バンドルまたは CRL を Application Load Balancer のトラストストアにアップロードして、相互認証を有効にすることができます。

Application Load Balancer で相互認証をテストするには、以下の手順に従って OpenSSL を使用して自己署名 CA バンドルとクライアント証明書を作成し、それらを Amazon S3 バケットにアップロードして、ELB トラストストアで使用します。

curl に --key および --cert パラメーターを使用すると、リクエストの一部としてクライアント証明書を送信できます。

$ curl--key my_client.key--cert my_client.pem https://api.yourdomain.com

クライアントが無効または期限切れの証明書を提示した場合、証明書を提示できなかった場合、トラストチェーンが見つからない場合、トラストチェーン内のリンクのいずれかが期限切れになっている場合、または証明書が失効リストに含まれている場合は、相互認証は失敗する可能性があります。

Application Load Balancer は、クライアントの認証に失敗するたびに接続を閉じ、ロードバランサーに送信されたリクエストに関する詳細情報をキャプチャする新しい接続ログを記録します。各ログには、クライアントの IP アドレス、ハンドシェイクの待ち時間、使用された TLS 暗号、クライアント証明書の詳細などの情報が含まれます。これらの接続ログを使用して、リクエストパターンを分析し、問題をトラブルシューティングできます。

詳細については、AWS ドキュメントの「Application Load Balancer での相互認証」を参照してください。

今すぐご利用いただけます
Application Load Balancer での相互認証は、Application Load Balancer が利用可能なすべての商用 AWS リージョン (中国を除く) で利用できるようになりました。初期費用や契約は必要ありません。お支払いいただくのは使用した分のみです。料金については、「Elastic Load Balancing の料金」ページを参照してください。

ぜひお試しいただき、AWS re:Post for Amazon EC2 宛てに、または通常の AWS サポートの連絡先を通じて、フィードバックをお寄せください。

詳細はこちら。
Application Load Balancer 製品ページ

– Channy

原文はこちらです。