SSLクライアント証明書での認証：グループウェアのアクセス制限

こちらも以前少しだけサポートした件です。ある会社で使っているグループウェアを、これまでは社内からのみアクセスさせていたのですが、これを外出先からも見れるようにしたい、ということで話がありました。

普通に考えられるソリューションとしては「IPSec-VPN」や「SSL-VPN」が提供できるネットワーク機器を使う、ということかと思います。前に見たケースだと、ファイアウォール兼VPN装置（確かそのときはCheckpointかなんだったような・・・）を社内のゲートウェイとなる部分にいれて、外部からはVPNクライアントがインストールされたPCで接続する、という感じです。

VPNクライアントをいれるのが手間だから嫌だ、という場合には、SSL-VPNを使うケースもあるでしょう。この場合、DMZなどにSSL-VPN装置をおいて、そこから目的のサーバにポートフォワーディングする、というイメージです。もちろんその際に認証などのセキュリティもはいります。グループウェアもWebベースのものが多いはずなので、SSL-VPNとの親和性も高いはずです。

ある意味今回の件はSSL-VPNのほうに近いでしょうか。ただ、SSL-VPN装置ではなく、「グループウェア専用のプロキシサーバをDMZにたてて、そのサーバが社内LANのグループウェアから情報をひっぱってくる」という感じです。普通に使ってしまうとHTTPで暗号化をしないので、SSLくらいは使うことにします。

グループウェアもプロキシもWindowsベースです。プロキシ側にはIISをいれて、SSLもそこでさせることにします。最低限サーバ証明書は必要なので当然商用のCAでとりますが、問題はクライアントの認証です。

一応パスワード認証はするので最低限はOKなのですが、もうちょっとどうにかなるかな・・・ということで少し検討してみることにしました。で、その中で候補にあがったのがクライアント証明書での認証です。

もちろんこの場合も商用CAの証明書が望ましいのですが、社内のセキュリティが守られればいい、というのであれば、社内に独自CAをたててそこでクライアント証明書を発行し、それをクライアントに配る、という手があります。

携帯の場合だと独自CAをインポートができない（できるのもある？）ので、NTT DoCoMoさんのFirstPassとか使うことになるのかな・・・。こっちのほうが難しそうですねぇ・・・。こちらは従来どおりパスワードで認証に、「携帯のIPからだけパスワードでの認証を許可する」など憂いかのセキュリティも考えられますが、ひとまずはあとまわしにします。

IISの設定、Windowsでの独自CAの構築については

http://www.ipa.go.jp/security/fy14/contents/soho/html/chap4/httpd/IIS-SSL.html

（IE：Internet Explorerの設定によっては文字化けするので、その場合には[ツール]-[互換表示]を試してみてください）

http://msdn.microsoft.com/ja-jp/library/ff649247.aspx

などを見て設定してましたかね。

クライアント証明書の発行自体は、サーバ証明書とほとんど変わりません。これを発行してクライアントWebブラウザで適用します。IEへの適用だったら、ファイルをマスククリックしてそのまま指示にしたがえば適用できます。

独自CAをたててクライアント証明書を使う場合、クライアント証明書を検証するのはサーバ側です。つまり、サーバがクライアントの証明書のチェインをたどれないとだめなわけです。

だとすると、独自CAの証明書をダウンロードして、それをサーバ側に適用しないといけませんね。Windowsの[証明機関]であれば、

http://（証明機関サーバのIPアドレス）/certsrv/Default.asp

にアクセスし、[CA証明書、証明書チェイン、またはCRLのダウンロード]　-　[CA証明書のダウンロード]とかでよいはずです。エンコード方式はBase64にしました。

これをサーバ側で適用するわけですね。たとえばこんな方法です。確か証明書のダブルクリックだけではうまくいかなったはずです。

http://jp.globalsign.com/support/index.php?action=artikel&cat=32&id=396&artlang=ja

実際ぢろーらもが設定したわけではなく、このあたりの方法を案内したという感じですね。おいおい、「クライアントの認証するだけだからサーバ証明書はいらないでしょ？」って、それはほぼ必須なんだけどさ・・・。SSLのシーケンスを考えればわかりますよ。そりゃうまくいかんでしょう・・・。

このときはまだ「認証そのものはパスワードも使うので、クライアント証明書自体がユーザアカウントに結びついている必要はない。その組織が発行した証明書だとわかればいい」という感じなので、IISでクライアント証明書のマッピングまでは行ないませんでした。じゃあ、設定はとりあえずいいかな・・・。

おっと、クライアントによってうまくクライアント証明書使えたり使えなかったりするな・・・なんでかなぁ・・・と思って調べてみたら、情報がありました。

http://121ware.com/qasearch/1007/app/answerqa_main.jsp?010371

http://www.geocities.jp/knight_of_crusader/library/IE6_b.html

[既存のクライアント証明書が１つ、または存在しない場合の証明書の選択]を有効にする必要があるわけですね・・・。とりあえずこちらでできるようになりました。

実際に手伝えたのはここまででした。結局どうしたのかな・・・。なんだかんだで「SSL+パスワード認証」でもある程度のセキュリティは保たれる（もちろん、パスワードの長さ、複雑さ、有効期間などのポリシーは重要）から、実はクライアント証明までは使ってなかったりして・・・。

実際に運用になったら、証明書の有効期間をどうするか、とか、持ち出し用のPCが盗難された場合にクライアント証明書を使えないようにするにはどうするかなど、いろいろ考えることはあるでしょう。もちろん、予算との関係もあります。「どこまで対策をするか？」については、費用対効果のバランスを考えた上で実施する必要があります。

---

この記事が気に入りましたら、また、お役に立ちましたら、以下のアイコンをクリックしていただけると嬉しいです(^^)

---