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

こんにちは、ヤマです。

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

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

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

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

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

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

失敗１）ALB（ACMによるSSL）→EC2（クライアント証明書）

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

Bad Gateway 502とかでます。

失敗２）ALB（外部SSL）→EC2（外部SSL＋クライアント証明書）

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

うまくいかなかった原因

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

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

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

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

１）TCPコネクション　→　２）TLSセッション　→　３）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

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