月別アーカイブ: 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クライアント証明書を発行。クライアント証明書は、会社や部門全体での一括発行や、１ユーザーごとの個別の発行が出来ます。

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のＡレコードでアクセスします

例　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へのアクセスを禁止できます

  • 組織や部門でのアクセス制限
  • 曜日や時間帯でのアクセス制限
  • 特定ユーザーでのアクセス制限
  • 端末を紛失したので、ただちにＡさんの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クライアント認証でＷebサイトの認証を強化したい方、既存で運用のWebサイトへのアクセスに認証機能を導入したい方。デモ環境で試してみたい方や詳しい話を聞いてみたい方などは、ムービットの https://www.mubit.co.jp/sub/products/blue/img2/arrow-finger.gif お問い合わせフォーム からご連絡ください。