web-dev-qa-db-ja.com

Amazon Elastic Load Balancerと相互認証

おそらくTLSを介して相互認証（つまり、サーバーとクライアントの両方を認証）するようにAWS ELB（Elastic Load Balancer）を構成した人がいますか？ REST SSHを使用したAPIと、特定のユーザー/クライアントを表す共有シークレットを公開しています。

PKIと相互認証（つまり、キーストアとトラスト）の使用に移行したいと思います。 Java TLSを使用して相互認証を実装しました。同じようにELBを構成する方法を知りたいのですが。

tlsauthenticationpublic-key-infrastructureaws
3
Toby Sarver

古い質問ですが、AWSで同様のアーキテクチャを検討しており、長い道のりでした。

最初に回答する質問はifが 相互TLS認証 を実行するようにAWSロードバランサー（当時はELB、現在はALBとNLB）を構成できる場合です。

これには、相互TLS認証が機能することを理解する必要があります。グーグル検索はあなたに千以上の単語を助けることができます。要約すると、通常のTLSフロー後の相互TLSでは、クライアントは証明書をサーバーに提示します。サーバーは、有効で信頼できる証明書を受け取ると、証明書からID情報を抽出します。

このモデルでは、TLS接続を終了するサーバーがユーザーを「認証」するサーバーです。

2番目の質問は、AWS LBを構成してそれを行う方法です。

TL; DR：できると思いますが、YMMVです。私はそのようなシステムを構築するのではなく、ドキュメンテーションを研究しただけです。

これを実現するには、いくつかの前提条件が必要です。

  • lBでTLS終了を実行できる
  • pROXY PROTOCOLをサポート（LBとバックエンドアプリケーションの両方）
  • 認証の識別子として証明書の共通名（またはSNI）を使用する

TLSの終了は、すべてのAWSロードバランサーでサポートされています（ Jan 2019 NLBもこれをサポートするため 以降）。

これにより、クライアントはLBに正常に接続し、TLSハンドシェイクを成功させることができます（もちろん有効な証明書を使用）。

この時点で、クライアントのIDはAWS LBに認識されています。
この情報を、アプリケーションがあるバックエンドサーバーに伝達する必要があります。

これが PROXY PROTOCOL です。私の理解では、フィールドPP2_TYPE_AUTHORITYのおかげで [〜＃〜] sni [〜＃〜] を取得でき、PP2_SUBTYPE_SSL_CNのおかげで証明書の共通名を取得できます。これらは、Proxy ProtocolドキュメントでType-Length-Value（TLVベクトル）と呼ばれ、2017/03/10リビジョン以降に利用可能です。

AWSドキュメントから、PROXY PROTOCOLを Classic LB および NLB Target Group に設定できます。

これにより、バックエンドがクライアントのIDに関する情報を受信できるようになります。その後、バックエンドは、プロキシプロトコルの情報を「信頼」して認証します。

また、LBに証明書と信頼チェーンを認識させる必要があります。 AWS Certificate Managerのおかげで、証明書（ボディ、プライベートキー、チェーン）をインポートできます。インポート後は、クラシックLBリスナーとNLBターゲットグループで証明書として使用できます。デバイスがサーバー証明書（つまり、クライアントの信頼できるストアに追加されたカスタムCA）を信頼している限り、ベンダーから入手することも、自分で生成することもできます。

この時点で、すべての部品が配置されているはずです。

  • lBでTLSを終了します
  • クライアントIDをバックエンドに転送しています（アプリケーションでクライアントを認証する必要があります）
  • 証明書とチェーンを使用しています（クライアント証明書を使用する必要があります）

それがお役に立てば幸いです。そして、私の推論で起こり得るエラーを指摘してください。特にAWS LBのProxy Protocolヘッダーに何が含まれているかに関するドキュメントが不足しているため、これが機能するかどうかはまだ100％わかりません。 Classic LB および [〜＃〜] nlb [〜＃〜] について文書化されていますが、SSLに関連するTLVに関する情報は提供されていません（プロキシプロトコルでサポートされている場合でも） v2）。

Aセキュリティ通知：バックエンドサーバーでTLSを終了するとき、デバイスからバックエンドへのトラフィックは暗号化されます。 LBでTLS終了を実行する場合（自分のものまたはAWSのもの）、バックエンドサーバーに到達する前に明らかに復号化しています。 LB Backend Authenticationon Classic LB を使用できますが、ALBまたはNLBでは使用できないようです。 ALBまたはNLBの同様の機能については知りません。
この2016年の回答 は、AWS開発者フォーラムの「Amazonian」から、VPCでのMITMは不可能であることを指摘して見つけることができました。理由は次のとおりです。

VPCにはブロードキャストがないため、ARPポイズニングは不可能であり、VPC内のIPスプーフィングも同様に不可能です（これは、インスタンスが、自身のものではないソースIPまたはMACでトラフィックを送信することを許可されていないためです）。

ウサギの穴を掘り下げたい場合は、詳細情報が確実に利用できます（つまり、このブログ投稿 PCIに関するAWSセキュリティDSSコンプライアンスとAWS VPC ））。

3
endorama