ロードバランサ(LB )でリバースプロキシへ負荷分散をして、リバースプロキシ(Reverse Proxy)でSSLクライアント認証を行い、さらにWebサーバーへSSLでの通信を例です。今回は ロードバランサーでSSLを終端させずに、ロードバランス先のリバースプロキシやWebサーバーまでSSL通信を行い、常時SSL化でのSSLクライアント認証を行う構成例です。
SSLクライアント認証はリバースプロキシサーバー側で行います。ロードバランサーでSSLをオフロードしないため、クライアントからWebサーバーまでを SSL及びSSLクライアント認証での運用が出来ます。SSLクライアント認証のログも取得します。
構築方針
- ロードバランサーで、SSLをターミネートしない
- クライアントからWebサーバーまでの全経路で常時SSL通信(https)を行う
- リバースプロキシサーバーへCRL(失効リスト)を配布する
- SSLクライアント認証は、リバースプロキシサーバー側で行う
使用した機器
- KEMP LoadMaster (ロードバランサー管理IP) IP=192.168.100.60
- KEMP LoadMaster (Virtual IP) IP=192.168.100.63
- Powered BLUE Private CA (プライベートCA ) IP=192.168.100.54
- Powered BLUE Rev-Proxy ( リバースプロキシ / CRL) IP=192.168.100.58 / 73
- Powered BLUE Web Server IP=192.168.200.1 / 2 / 3
- 今回は各サーバーとも仮想アプライアンス(VMware版)を利用
- 各サーバともGUIから、LB/CA/リバースプロキシ/CRLの同期/SSLクライアント認証が簡単に設定出来ます
備考 AWS上でロードバランサー / リバースプロキシ / SSLクライアント認証を運用の場合
- KEMP ロードバランサはVirtual LoadMaster for AWS を選択
- Powered BLUE Private CAはAWSへ登録のAMIを選択
- Powered BLUE Web ServerはAWSへ登録のAMIを選択
AWSのELB / ロードバランサーでリバースプロキシ&SSLクライアン認証の場合は、こちらを参照
ロードバランサーの設定 ( KEMP ロードマスター )
- ロードバランサーの Virtual IP Address = 192.168.100.63 / load-balancer.mubit.com
- 負荷分散先のリバースプロキシ / CRL サーバー No1 = 192.168.100.58
- 負荷分散先のリバースプロキシ / CRL サーバー No2 = 192.168.100.73
ロードバランサー設定のポイント
- SSL Acceleration をオフ (SSL通信をロードバランサでオフロードしない)
- DNSサーバーに、192.168.100.63 / load-balancer.mubit.com を登録
- 外部からのアクセスは https://load-balancer.mubit.com
プライベートCA設定のポイント
CAからCRLの提供を許可するクライアントのリバースプロキシサーバーを指定します ( 許可するIPアドレス )
- 負荷分散先のリバースプロキシ / CRL サーバー No1 = 192.168.100.58
- 負荷分散先のリバースプロキシ / CRL サーバー No2 = 192.168.100.73
リバースプロキシサーバー側の設定のポイント
- CAからCRLを自動入手出来る設定 ( 取得先CA http://ca-server.mubit.com )
- crlの同期スケジュールを指定
- 負荷分散する2台のリバースプロキシサーバーに、同一のSSLサーバー証明書&秘密鍵を登録
SSLのサーバー証明書を作成します(1台目のリバースプロキシサーバー)
- 「自己署名デジタル証明書の作成」 または 「署名リクエストの作成」 で作成します
自己署名デジタル証明書の作成の場合
- 「自己署名デジタル証明書の作成」から必要事項を記入して、SSLを有効にします
PublicなSSLサーバー証明書の場合 / 署名リクエスト(CSR)の作成
公的なSSLサーバー証明書をインポートすると、ブラウザでWebページにアクセス時のワーニングを抑制することが出来ます
SSLのサーバー証明書は
- ドメイン認証証明書(DV:Domain Validation)
- 組織認証証明書(OV:Organization Validation)
- EV証明書(EV:Extended Validation)
が登録出来ます
- 必要事項を記入して、 「署名リクエストの作成」 ボタンを押します
- 作成された 「署名リクエスト」 ファイルを保存
- この 「署名リクエスト」 ファイル signig-request.txt を、公的なSSLサーバー証明書の発行機関へ送付
- 公的機関で発行された、サーバー証明書を 「インポート」 します
- 中間証明書も登録出来ます
サーバー証明書&秘密鍵のエクスポート(1台目のリバースプロキシサーバー)
- 1台目のリバースプロキシサーバーに登録されている、サーバー証明書&秘密鍵を「エクスポート」
サーバー証明書&秘密鍵のインポート(2台目以降のリバースプロキシサーバー)
- 1台目のリバースプロキシサーバーから取り出した証明書&秘密鍵を2台目のリバースプロキシサーバーへインポート
- 1台目のサーバー証明書と秘密鍵のコピーが2台目にインストールされます
SSLクライアント認証を設定
- 1台目、2台目ともWebアクセス時の 「SSLクライアント認証」 を有効にします
リバースプロキシ先を設定
1台目、2台目ともリバースプロキシからWebへのリバースプロキシ先を設定します
設定例 (複数のリバースプロキシ先を指定できます )
- activemail --->> https://192.168.200.2/activemail/
- cybozu --->> https://192.168.200.3/cybozu/
- dneo --->> https://192.168.200.1/dneo/
- mubit --->> http://www.mubit.co.jp/
アクセス例
ロードバランサー経由でのアクセスは
- https://load-balancer.mubit.com/activemail/
- https://load-balancer.mubit.com/cybozu/
- https://load-balancer.mubit.com/dneo/
- https://load-balancer.mubit.com/mubit/
リバースプロキシのメリット
リバースプロキシ先が他社のサービスを利用時にも、「URLを表示させない」とか リバース先のSSL証明書を「表示させない」など
- リバースプロキシ先のURLを隠ぺい出来る
- リバースプロキシ先のSSL証明書を隠ぺい出来る
SSLクライアント証明書の発行
- Powered BLUE Private CAでSSLクライアント証明書を作成して、配布します
ロードバランサー配下のWebサーバーでSSLクライアント認証を行う例は、こちら
SSLクライアント認証時のアクセスコントロール
有効なSSLクライアント証明書を有している場合でも、Webサイト毎に各種のアクセスコントロールが設定出来ます
失効リスト(CRL)に関わらず、ただちにWebへのアクセス禁止を設定できます
SSLクライアント証明書を失効させることなく、Webへのアクセスを禁止できます
- 組織や部門でのアクセス制限
- 曜日や時間帯でのアクセス制限
- 特定ユーザーでのアクセス制限
- 端末を紛失したので、ただちにAさんのSSLクライアント証明書でのアクセスを禁止
SSLクライアント認証のログ
SSLクライアント認証時のアクセスログの出力先を指定出来ます。Webサーバー側でアクセスログを取得出来ます。
Powered BLUEの デモサーバー
基本操作 / リバースプロキシ / SSLクライアント認証 / 添付ファイルZIP暗号化 / Web mail / グループウエア / ownCloud / 仮想サイト などのデモが出来ます
終わりに
SSLクライアント認証でWebサイトの認証を強化したい方、既存で運用のWebサイトへのアクセスに認証機能を導入したい方。デモ環境で試してみたい方や詳しい話を聞いてみたい方などは、ムービットの お問い合わせフォーム からご連絡ください。