SSLアクセラレータについて

 前回リバースプロキシについて書きました。「SSLアクセラレータについても共通する部分がある」というようなニュアンスの記事を書きました。今回は共通する部分と、SSLアクセラレータに特化した部分の両方について書いてみることにします。

 「httpsでの接続要求を受けて、他のサーバへ中継する」は共通

 リバースプロキシの場合は、http–>httpの中継もありますから、https–>httpというケース限定ということになります。(https–>httpsというのは考えません。SSLサーバ証明書の問題もあります。このへんは別ネタで書いてみることにします。)
 SSL(今はTLSですが、以下便宜上SSLと呼ぶことにします)通信による暗号化/復号処理に際して、それなりのリソースを消費します。クライアントからSSLでの通信要求に対する対応や、Webサーバとしての処理や、データベース処理などを1台のサーバで処理していると、負担も大きくなります。
 そこで、そのうちのSSLによる通信処理を請け負う形にするというのがSSLアクセラレータの持つ機能のうちの1つでもあります。

 ハードウェアによる暗号化/復号処理がポイント

 ここまでならリバースプロキシと等価になってしまいます。SSLアクセラレータの大きな特徴として、「SSL暗号化/復号をハードウェア処理している」という点です。これで処理の高速化を実現させることが出来ます。ハードウェア処理で連想するのが、L3スイッチですね。(最近はL3スイッチ=ハードウェア処理、ルータ=ソフトウェア処理という区分も曖昧になってる感があります。)
 出来るだけWebサーバの負荷を軽くしようということと、SSLによる暗号化処理を外し、その後ろにロードバランサを配置して複数のWebサーバに処理を分散させるということも考えられます。さらにデータベースがある場合、Webサーバとは別にデータベースサーバが存在して、Webサーバからしかデータベースサーバへの通信が出来ないようにすることが出来ます。

 よって、セキュリティ面的にもメリットがあります。SSL暗号化/復号処理もWebサーバ機能もデータベースサーバ機能も1台で賄うとした場合、データベースサーバをインターネットに対して剥き出しで晒してしまう
(FWはありますが)ことになります。たいへん危険ですね。
 ここでSSLアクセラレータを用いれば、フロントエンドにhttpsでの通信部分のみを置いておけば良いことになります。その後ろにWebサーバ、さらに後ろにデータベースサーバをを別ネットワークで配置して、FWやルータでアクセスコントロールすれば、データベースサーバを守るこが出来ます。
 以下のようなイメージです。

[クライアント] —> [SSLアクセラレータ] —> [Webサーバ] —> [DBサーバ]
|<--- https ------->|<--------http-------->|<---DB通信--->|

  • [SSLアクセラレータ] —> [Webサーバ]の片方向通信は許可し、逆方向は拒否とします。
  • [Webサーバ] —> [DBサーバ]の片方向通信は許可し、逆方向は拒否とします。
  • [SSLアクセラレータ] —>[DBサーバ]の直接通信は拒否とします
  • [Webサーバ] 及び[DBサーバ]はプライベートネットワークに配置します。

 ハードウェアによる処理の高速化以外のメリットもあることが分かりますね。
SSLアクセラレータについて

  • このエントリーをはてなブックマークに追加

コメントをどうぞ