月別アーカイブ: 2016年1月

AWSのロードバランサ配下でWebのSSLクライアント認証&リバースプロキシ連携

AWS のロードバランサー(ELB) 配下のWebサーバーで

  • Webアクセス時のSSLクライアント端末認証
  • リバースプロキシ( Reverse Proxy )
  • クライアントから終端のWebサーバーまで、全経路での常時SSL通信

を行う場合の構成例です。

ELBではSSLを通過させてリバースプロキシーサーバー側で、SSLクライアント認証を実施。ロードバランスでは、SSLのサービスを通過させるだけでオフロードをしないため、AWSのELBに限らず一般的な ロードバランサーでも同様の構成が取れます。リバースプロキシにより、最終のEC2/Webサーバーまで全経路にわたり常時SSL/TLSでの通信を行う構成です。SSLクライアント認証のログも取得します。

CAとリバースプロキシを分離構成で運用の場合、リバースプロキシの負荷が高くなった際には

  • ロードバランサーの追加
  • リバースプロキシの追加

への変更が容易です

ca-crl-20

 

構築方針

  • ロードバランサーでSSLをターミネートしない(ELBではTCP 443からTCP 443への転送)
  • リバースプロキシサーバーへCAからCRL(失効リスト)を配布
  • プライベートCA構築(アプライアンスサーバー:AMI対応)
  • リバースプロキシ&SSLクライアント認証構築(アプライアンスサーバー:AMI対応)
  • Webサーバー構築(アプライアンスサーバー:AMI対応)
  • 設定は全てWeb GUIから実施

 

使用する機器

AWS上に登録のPowered BLUE シリーズのAMIを利用します

 

ネットワーク構成

IPアドレスは便宜的に表示 ( 実際の運用時には、適宜ゾーンなどを分離 )

  • 自己認証局 CA Server  http://ca-server.mubit.com  IP=10.0.0.X
  • SSLクライアント認証&リバースプロキシ B860-LB1 IP=10.0.10.1
  • SSLクライアント認証&リバースプロキシ B860-LB2 IP=10.0.10.2
  • https Web Server No1  B860-Web1  IP=10.0.20.1
  • https Web Server No2  B860-Web2  IP=10.0.20.2
  • https Web Server No3  B860-Web2  IP=10.0.20.3

 

プライベートCAの構築

Amazon AWSに登録のAMIから Powered BLUE プライベートCA をセットアップします

 

SSLクライアント証明書の発行

プライベートCAでSSLクライアント証明書を発行。クライアント証明書は、会社や部門全体での一括発行や、1ユーザーごとの個別の発行が出来ます。

SSLクライアント証明書のダウンロードも

  • 管理者側でのダウンロード
  • エンドユーザー側でのダウンロード

に対応しています

SSLクライアント証明書を個別発行の場合(1枚発行の場合)

例 suzuki@mubit.com ユーザーのクライアント証明書を作成

有効期限などを指定して発行します

SSLクライアント証明書をダウンロードします

SSLクライアント証明書のブラウザへのインストール(Firefoxの場合)

「証明書を表示」をクリック

「あなたの証明書」のインポートをクリック

SSLクライアント証明のパスワード入れてインストールします

正常にインポート時の表示

証明書マネージャーにインストールしたクライアント証明書が表示されます

 

プライベートCA設定のポイント

CRLを配布できるクライアントのIPを指定できます

例 SSLクライアント認証&リバースプロキシ

  • B860-LB1 IP=10.0.10.1
  • B860-LB2 IP=10.0.10.2

aws-lb-23

リバースプロキシサーバー側の設定のポイント

  • CAからCRLを自動入手出来る設定 ( 取得先CA  http://ca-server.mubit.com )
  • crlの同期スケジュールを指定
  • 負荷分散する2台のリバースプロキシサーバーに、同一のSSLサーバー証明書&秘密鍵を登録

SSLのサーバー証明書を作成します(1台目のリバースプロキシサーバー)

  • 「自己署名デジタル証明書の作成」 または 「署名リクエストの作成」 で作成します

Publicなサーバー証明書をインポートすると、ブラウザでWebページにアクセス時のワーニングを抑制することが出来ます。Let’s EncryptのSSLサーバー証明書にも対応しています(自動更新に対応)。

自己署名デジタル証明書の作成の場合

  • 「自己署名デジタル証明書の作成」から必要事項を記入して、SSLを有効にします

署名リクエスト(CSR)の作成の場合

SSLのサーバー証明書は

  •  ドメイン認証証明書(DV:Domain Validation)
  •  組織認証証明書(OV:Organization Validation)
  •  EV証明書(EV:Extended Validation)

が登録出来ます

利用のインスタンスがEC2のため、ACM (AWS Certificate Manager)でのSSLサーバー証明書の組込は利用できません

  • 必要事項を記入して、 「署名リクエストの作成」 ボタンを押します

  • 作成された 「署名リクエスト」 ファイルを保存
  • この 「署名リクエスト」 ファイル signig-request.txt を、公的なSSLサーバー証明書の発行機関へ送付

公的機関で発行された、サーバー証明書を 「インポート」 します

サーバー証明書&秘密鍵のエクスポート(1台目のリバースプロキシサーバー)

  • 1台目のリバースプロキシサーバーに登録されている、サーバー証明書&秘密鍵を「エクスポート」

サーバー証明書&秘密鍵のインポート(2台目以降のリバースプロキシサーバー)

  • 1台目のリバースプロキシサーバーから取り出した証明書&秘密鍵を2台目のリバースプロキシサーバーへインポート
  • 1台目のサーバー証明書と秘密鍵のコピーが2台目にインストールされます

SSLクライアント認証を設定

  • 1台目、2台目のリバースプロキシはどちらもWebアクセス時の 「SSLクライアント認証」 を有効にします

リバースプロキシ先を設定

1台目、2台目ともリバースプロキシからWebへのリダイレクト先を設定します

設定例 (複数のリダイレクト先を指定できます )

  • activemail   --->> https://10.0.20.1/activemail/
  • cybozu   --->> https://10.0.20.2/cybozu/
  • dneo   --->> https://10.0.20.3/dneo/
  • mubit   --->> http://www.mubit.com/dir/
  • proself --->> https://10.0.20.3/proself/

aws-lb-22

Powered BLUE Webサーバーの設定

Amazon AWSに登録のAMIからPowered BLUE サーバーをセットアップします。VPCなどで3台のWebサーバーを構築します

  • B860-Web1
  • B860-Web2
  • B860-Web3

 

Webサーバーの設定

それぞれのWebサーバーへホームページやWebアプリケーションを入れます

B860-Web1 ( https Web サーバーNo1 )

B860-Web2 ( https Web サーバーNo2 )

B860-Web3 ( https Web サーバーNo3 )aws-lb-21

 

SSLのサーバー証明書を作成します(1台目のhttpsサーバー)

  • 「自己署名デジタル証明書の作成」 または 「署名リクエストの作成」 で作成します

自己署名デジタル証明書の作成の場合

  • 「自己署名デジタル証明書の作成」から必要事項を記入して、SSLを有効にします

2台目、3台目のWebサーバーにも同様の操作で、SSLのサーバー証明書を組み込みます

 

AWS ELB (Elastic Load Balancing ) の作成

  • ロードバランサ名の設定 (例 LB-80 )
  • ロードバランサの運用ゾーンを選択(例 VPC-19fdd9 (10.0.0.0/16)
  • ロードバランサのプロトコル選択(例 プロトコル TCP / ポート443 )
  • インスタンスのプロトコル選択(例 プロトコル TCP / ポート443 )
  • サブネットの選択(適用するサブネット)

セキュリティグループの設定

ELBからリバースプロキシ(443)のヘルスチェックの設定

  • TCP 443へのping

 

ELBで負荷分散させるEC2インスタンスの選択

  • B860-LB1 ( リバースプロキシ サーバーNo1 )
  • B860-LB2 ( リバースプロキシ サーバーNo2 )

ヘルスチェックの状況

  • ヘルスチェック TCP=443
  • ステータス InService ( https サーバーの正常動作)
  • アベイラビリティ-ゾーン 正常?(はい)

ELB経由でのアクセス

Webサーバーには、ELBのDNSのAレコードでアクセスします

例 https://LB-80-209694.ap-xxxxxxx.com/

SSLクライアント認証例

Webへアクセス

  • https://LB-80-209694.ap-xxxxxxx.com/
  • https://LB-80-209694.ap-xxxxxxx.com/activemail/
  • https://LB-80-209694.ap-xxxxxxx.com/cybozu/
  • https://LB-80-209694.ap-xxxxxxx.com/dneo/
  • https://LB-80-209694.ap-xxxxxxx.com/proself/
  • https://LB-80-209694.ap-xxxxxxx.com/mubit/

OKボタンを押すと、SSLクライアント認証後にWebのアクセス画面が表示されます.有効なSSLクライアント証明書の無い場合には、この時点でアクセスが拒否されます

SSLクライアント認証例 (承認されない場合)

有効なSSLクライアント証明書が無いクライアントからのアクセスの場合 ( IPhone )

 

SSLクライアント認証時のアクセスコントロール

有効なSSLクライアント証明書を有している場合でも、Webサイト毎に各種のアクセスコントロールが設定出来ます
失効リスト(CRL)に関わらず、ただちにWebへのアクセス禁止を設定できます
SSLクライアント証明書を失効させることなく、Webへのアクセスを禁止できます

  • 組織や部門でのアクセス制限
  • 曜日や時間帯でのアクセス制限
  • 特定ユーザーでのアクセス制限
  • 端末を紛失したので、ただちにAさんのSSLクライアント証明書でのアクセスを禁止

https://www.mubit.co.jp/pb-blog/wp-content/uploads/2015/12/ssl-access-3-1.png

SSLクライアント認証のログ

SSLクライアント認証時のアクセスログの出力先を指定出来ます。Webサーバー側でアクセスログを取得出来ます。

https://www.mubit.co.jp/pb-blog/wp-content/uploads/2015/12/ssl-access-2.png

 

リバースプロキシのメリット

リバースプロキシ先が他社のサービスを利用時にも、「URLを表示させない」とか、リンク先の他社のSSL証明書を「表示させない」などの使い方が出来ます

  • リバースプロキシ先のURLを隠ぺい
  • リバースプロキシ先のSSL証明書を隠ぺい

 

AWS/ELB配下のWebサーバーでSSLクライアント認証を行う構成例

一般的なロードバランサーでのSSLクライアント認証&リバースプロキシの構成例

一般的なロードバランサーでのSSLクライアント認証の構成例

 

デモサイト

https://www.mubit.co.jp/sub/products/blue/img2/arrow-finger.gif Powered BLUE 870 のデモサイト

 

終わりに

SSLクライアント認証でWebサイトの認証を強化したい方、既存で運用のWebサイトへのアクセスに認証機能を導入したい方。デモ環境で試してみたい方や詳しい話を聞いてみたい方などは、ムービットの https://www.mubit.co.jp/sub/products/blue/img2/arrow-finger.gif お問い合わせフォーム からご連絡ください。