ELB(Elastic Load Balancer)でバランサしながらクライアント証明書で認証するWEBアプリ

NO IMAGE

こんにちは、ヤマです。

記事を書いているのは2020/12/28、もう年末、 色々あった1年でした、

来年は健康で、皆さまにとってよりよい1年になりますように。

1年の締めくくりに、AWSに関する投稿です。

クラウドサービスは、あらゆる場面ですでに当たり前のものになっていますが、同時にセキュリティの高さが常に求められます。

弊社のクラウドサービスでは、セキュリティ対策としてクライアント証明書を導入していますが、バランサを設置して負荷分散をする環境下でも、クライアント証明書による認証をさせたいです。どうしたらいいでしょうか。

やってはいけない失敗談を残します。

失敗1)ALB(ACMによるSSL)→EC2(クライアント証明書)

ELBの一種である、Application Load Balancer(ALB)の配下にEC2を設置、ALBでSSL処理のうえ、ALB→EC2間もSSLとしました。ご存知の通り、うまくいきません。

Bad Gateway 502とかでます。

失敗2)ALB(外部SSL)→EC2(外部SSL+クライアント証明書)

失敗1を受けて、この構成にしましたが、そもそも根本的に勘違いしているので、これもうまくいきません。

うまくいかなかった原因

大変恥ずかしい話ですが、ELBの種類の違いを理解していないことが、根本的な原因でした。

Elastic Load Balancing の特徴
参照:https://aws.amazon.com/jp/elasticloadbalancing/features/
Application Load Balancer
ALB
Network Load Balancer
NLB
ロードバランサーの種類レイヤー7レイヤー4
プロトコルリスナーHTTP、HTTPS、gRPCTCP、UDP、TLS

AWSのドキュメントによると、ALBはレイヤー7「アプリケーション層」で動作し、NLBはレイヤー4「トランスポート層」で動作します。

つまり、根本的に使用目的が違います。

クライアントがWEBアプリへアクセスする時には、

1)TCPコネクション → 2)TLSセッション → 3)HTTPS通信

の順番で動作します。HTTPS(暗号化通信)を始める前のTLSセッション構築時に、鍵交換など暗号化通信に関する取り決めの確認が、クライアントとサーバ間で実施されます。

つまりALBはHTTPS通信開始後に動作するため、クライアント証明書での認証が必要な、トランスポート層での機能には対応していないことになります。(と、AWSドキュメントにも書いてある)

ということで、この要件に対する正解は、NLB(TCP/443)→ ターゲット(TCP/443)で、構築する、でした。

NLBの負荷分散アルゴリズム

ALBであれば、スティッキーセッションを設定していない限り、キレイにラウンドロビンで負荷分散してくれます

しかしNLBでは、「フローハッシュアルゴリズム」で負荷分散のターゲットを決めているそうで、一方のサーバへアクセス集中したかと思えば、次は別のサーバへアクセス、といった感じで、負荷分散としてNLBを採用していいのか、疑問が残りました。

出典:https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/network/introduction.html

もう少し、検証が必要ですね。