前回はSSL証明書の配備と監視の設定を行いました。今回は監視結果によって送出されるアラートメールを確認、また前回行わなかったFTPを使った証明書の送付方法を検証します。最後に、CertMgrの運用上のセキュリティについて考えます。
CertMgrからのアラートメール
CertMgrはWebコンソール以外に、Eメールを使ってアラート（警報）をあげることができます。
証明書の配備に関するアラートと証明書の取得に関するアラートに大別できます。前者は、サーバー上に正しく証明書がインストールされていない場合などに上げられます。後者は例えば、証明書の有効期限が2ヶ月を切ったのにまだ更新取得の手続きを始めていない場合などに上げられます。
配備に関するアラート
証明書の配備に関して、CertMgrは下記の２つのケースで証明書アラートをメールで通知してきます。
1. 証明書のステータスは「配備確認済み」（すなわち配備プロセスは完了している）であるのに、1日1回の配備チェックが失敗した。
2. 証明書のステータスは「配備要求中」（すなわち配備プロセスは進行中）で、1日1回の配備チェックが成功した。
１の状況は、一度正しく証明書がインストールされたのに、何らかの原因で証明書がおかしくなったというものです。
２の状況は、配備プロセスにおいてサーバー管理者に証明書のインストール依頼を行い、その結果サーバー管理者が証明書のインストールを正しく完了したということです。
管理下のSSL証明書のうちどれか一つが１か２の状況になったと検知されると、CertMgr管理者宛にアラートメールが送信されます。また１の場合は、該当サーバーのサーバー管理者にもアラートメールが送信されます。
では、実際にどのようなアラートメールが送信されるのか、テストをしてみます。
Apacheの証明書 www.example.com を最初に自動生成された自己署名証明書で上書きします。誤って古い証明書に戻したことを想定しています。
# cp /etc/ssl/certs/ssl-cert-snakeoil.pem /etc/apache2/ssl/certs/www.example.com.crt
# cp /etc/ssl/private/ssl-cert-snakeoil.key /etc/apache2/ssl/private/www.example.com.key
# /etc/init.d/apache2 restart
またもう一つ、vsftpdは単にサービスを落としておきます。
これで、証明書の定期監視が動くのを待ちます。定期監視の間隔はデフォルト24時間ですが、ここではテストのため1時間に変更します。しばらくすると下記メールを受信しました。
CertMgr管理者が受信するアラートメール
まだ日本語化はされていませんが以下のような、誤った証明書を使っているサーバーや稼動していないサーバーの一覧と、CertMgr管理者として取るべきアクションが記載されたメールが送信されてきます。
SSL Server Certificates Status Monitor
(This is sent from Kousec Server Certificate Manager)
As of 2009/10/16 12:00:41 (UTC: 2009-10-16 03:00:41+00:00)
Certificates and servers that need your immediate attention
-----------------------------------------------------------
These servers previously had correct certificates installed, but at the time
of our daily certificate checking, they are not correctly installed.
[下記に、配備確認済みであるが、配備チェックが失敗した証明書が列挙されている]
Cert-CommonName Server
Name
Status Check Server-Admin
www2.example.com server1
Deploy-Confirmed
NG svr-admin@xxxx.com
www.example.com server1
Deploy-Confirmed
NG svr-admin@oxxxx.com
What you need to do: Open the certificate screen for each certificate on Kousec
Server
Certificate Manager and do a deploy check again to determine if the failure is
persistent.
If the deploy check still fails, follow the “Re-install Certificate” section on
the same page.
[CertMgr上の各証明書へのリンクが列挙されている]
Cert-CommonName Link to Kousec CertMgr
www2.example.com http://PC2:23456/cake/cm/certificates/edit/1
www.example.com http://PC2:23456/cake/cm/certificates/edit/2
Certificates and servers that need your attension
-------------------------------------------------
You are requesting server administrators of these servers to
install the certificates, and at the time of our daily certificate checking,
they have been found to have the certificate installed.
[下記に、インストール依頼中の証明書のうち、配備チェックが成功した証明書が列挙されている]
[今回は対象の証明書はない]
[以下省略]
メール内にあるURLをクリックしKousec CertMgrにログインした後、証明書オブジェクトの画面が開きます。「証明書の再インストール」セクション上で、自動インストールの再実行やインストール依頼メールの再送信が行なえます。
ただし、サーバーが一時的に落ちていたり、何らかの理由でバックアップからリストア途中であったりする可能性があるので、まずはサーバー管理者に確認してみることがベストでしょう。上記アラートメールと同時刻に、サーバー管理者にもCertMgrからアラートメールが送られています。
各サーバー管理者へ送信されるアラートメール
まだ日本語化はされていませんが以下のような、証明書の配備チェックが失敗しサーバーそれぞれに対して、そのサーバー管理者に以下のようなメールが送信されてきます。
SSL Server Certificate Alert
As of 2009/10/16 15:00:52 (UTC: 2009-10-16 06:00:52+00:00)
We have detected that the SSL server certificate on the the server below
is not installed correctly.
SSL certificate common name : www.example.com
Server Name : server1
Host checked : www.example.com
Port checked : 443
You are receiving this email because your email address is registered
as the server administrator for this server.
The following is the result of certificate checking on the server.
[配備チェックの各ステップの結果が掲載されている]
check_result | NG |
Resolved Hostname | OK | Hostname www.example.com resolved to 1|192.168.239.91|443
Connected to Host | OK | Connected to host
Connected via SSL | OK | Established SSL connection (Over-SSL)
Certs Matched | NG | Received certificate is not the one in CertMgr
Note: "1|xx.xx.xx.xx|nnn" indicates that it is an IPv4 TCP endpoint
with
IP address of xx.xx.xx.xx and port number of nnn.
Please correct this problem and let our certificate administrator
(cmadmin@xxxx.com) know when it's corrected or the
problem needs
attention from him/her
The certificate administrator has also been notified of this issue.
サーバー管理者はこのメールを受け取り、必要あれば証明書の問題を修正します。
FTPサーバーを経由した証明書パッケージの送信
前回の配備プロセスの回では取り上げなかったFTPサーバーを使って証明書パッケージをサーバー管理者に送信する方法を紹介します。次章の運用ベストプラクティスで本方法を推奨しています。
FTPサーバーの設定は、Applications > Settings画面から行います。
FTP Upload Directoryに証明書インストールパッケージをアップロードするディレクトリのパスを入力します。例えば/home/myadmin/certs/を入力した場合、/home/myadmin/certs/c<証明書内部番号>/cert.zipにアップロードされます。
各サーバー管理者が本FTPサーバーにログインできるようにアカウントを用意する必要があります。
CertMgrがFTPサーバーに証明書パッケージをアップロードするタイミングは、証明書インストール依頼メールを送信する直前です。
CertMgr運用のベストプラクティス
ここではKousec CertMgrの運用法について考えてみます。
CertMgrマシンへのアクセス
CertMgrの証明書リポジトリーには、管理対象のサーバー証明書の秘密鍵が格納されています。さらに自動インストールで使用する対象サーバーの管理権限ユーザーのパスワードや、証明書を購入するCAのシステム上のアカウントなども格納できます。
万が一悪意を持った者に侵入されるとこれら全てが漏洩しかねません。
そこで、まずCertMgrのインストール環境の基本的なセキュリティを固める必要があります。一般的ですが以下のようなことを実施します。
·
CertMgrのウェブインターフェースは非SSLを禁止する。
今回評価を行ったのはベータ版でCertMgr自体はSSLが有効にはなっていませんでしたがリリースされるものはSSLも有効になります。
· ユーザーadminのパスワードを変更する。複数の人間でCertMgrを使用する場合は、かならず新しいユーザーを作成する。
· CertMgrのウェブインターフェースをIPアドレスで制限し、さらにOSのファイアウォールを有効にする。
· 他のサーバーアプリケーションと同居させない。
· CertMgrのバックアップはかならず暗号化を実施する。
CertMgrの運用で検討すべきこと
次に、CertMgrの運用に関していくつか決めなければならないことがあります。
A)
証明書の自動インストールを使うか否か。
自動インストールを使う場合、対象サーバー上で管理権限を持つユーザーのユーザー名・パスワードをCertMgr内に記録することになります。
B) 自動インストールを使わない場合の、証明書パッケージのサーバー管理者への送信方法のうち、どれを選ぶか。
C) 証明書監視（配備チェック）を行うために、インターネットへのアクセスを許すか。
D) CertMgrのメール送信などのネットワークアクセス自体を許すべきか。
それぞれについて検討した結果をベストプラクティスとして記します。
証明書の自動インストールを使うか
自動インストールを使うにはCertMgrに対象サーバーの管理権限ユーザーのパスワードを記録しておく必要が出てきます。
必要以上の機密情報を保持するのを避けながら運用の効率化とバランスを取るために以下のような運用方法にします。
Webサーバーのような台数が多いサーバーについては自動インストールを使用します。LDAPサーバーのようにユーザー認証の根幹に関わるようなサーバーの証明書については、自動インストールではなくワンクリックインストーラーでインストールを行います。
証明書パッケージのサーバー管理者への送信方法
CertMgrが提供する方法は、メールに添付、FTPサーバーにアップロード、そしてCertMgrのウェブサーバーから直接ダウンロードする方法です。そのほかには、ネットワークを使用せずUSBメモリなどで運ぶということも考えられます。
まず除外できるのはCertMgrのウェブサーバーから直接ダウンロードする方法です。これは複数のサーバー管理者がさまざまな場所からCertMgrのウェブサーバーにアクセスすると侵入されるリスクが高まるからです。メールに添付する方法もzipパスワードと一緒に送信されるという問題だけでなく、いつ誰によって開封されるか分からないという点からも懸念があります。
FTPサーバーなどの別のサーバー証明書パッケージを置き、zipパスワードだけをメールで送付するのがより安全でしょう。
また、証明書パッケージの作成はzipではなくより強固な暗号化を持つ7zipを使うように設定したほうが安全です。インストール依頼メールにも7zipアーカイブの展開方法も記載します。
証明書パッケージの送付用に1台FTPサーバーを用意します。この送付用サーバーにはサーバー管理者がそれぞれ自分のアカウントでログインできるようにします。CertMgrはこのFTPサーバーに証明書パッケージをアップロードするようにします。またアップロードしたファイルは1週間で消すなどの運用を行うほうがよいでしょう。
証明書パッケージは標準のzipではなく7zipを使うようにCertMgrを設定します。
証明書監視（配備チェック）のためにインターネットへのアクセスを許すか
配備チェックはCertMgrから監視対象サーバーへの外向きの通信であり、さらにウェブブラウザを使うのではなく専用のツールが必要最低限のアクセスだけを行います。従ってインターネット経由での配備チェックはセキュリティの低下をもたらすものではありません。しかしCertMgrマシンをよりインターネット接続ができないよりセキュアなネットワーク内に配置したいユーザーもいるでしょう。
ネットワークセキュリティ上の理由からCertMgrマシンを、インターネットに接続できないネットワーク内に配置する場合は、配備チェック用のサーバー名を証明書のコモンネームではなく内部サーバー名に設定し、内部ネットワークからの監視を行います。それでも配備チェックが出来ないサーバーについてはCertMgr上では定期監視を無効にします。
CertMgrのメール送信などのネットワークアクセス自体を許すべきか
仮にCertMgrマシンをネットワークから切り離しオフラインで運用すると、CertMgrを使用して得られる効用自体が大きく制限されてしまいます。
メールの送受信が行えるネットワークにCertMgrマシンを配置します。
SSL証明書の運用におけるセキュリティの考察
さて、みなさんはSSLサーバー証明書の秘密鍵をどのくらい厳重に保管すべきだと考えていますでしょうか。
SSL証明書の秘密鍵管理の実情
暗号化を行う如何なるアプリケーションで暗号鍵の管理はそのセキュリティの根幹となります。SSL証明書の秘密鍵も、鍵の保護を他のいかなることよりも重要視するのであれば、HSM（ハードウェア・セキュリティ・モジュール）をサーバーに搭載しその中に秘密鍵を閉じ込めて運用することになります。
しかし、SSLの適用範囲の拡大と汎用CPUの高性能化から、SSLサーバーマシンの数が大きく増加しました。その結果、多数のサーバーマシンのひとつずつにSSL用秘密鍵を紐づけることが不可能になり、秘密鍵を１か所で生成・維持し、サーバーに配布するという管理手法が出てきています。また各サーバーでは無人リブートを可能にするため秘密鍵は暗号化しない、暗号化してもそのパスワードもファイルに書き込んでおくといった使用方法がとられています。
通信暗号化とディスク暗号化における鍵管理の重要性の違い
また誤解を恐れずに言えば、SSLは通信の暗号化であり、ディスク暗号化における鍵管理の要求レベルより一段、要求レベルが低いことも、秘密鍵を配布するという管理手法が出てきた一つの原因かと考えます。通信暗号化とディスクの暗号化を比較します。
l 通信暗号化：鍵が漏えいした場合、その鍵を使った全通信セッションを終了し、CAが証明書を失効させる。また使用しなくなった鍵は保存しなくてもよい。
l ディスク暗号化：鍵が漏えいした場合、その鍵でそれまで暗号化したすべてのデータを再暗号化しなければならない。また使用しなくなった鍵はその鍵で暗号化したデータを保持する限り安全に保持し続けなければならない。
すなわち、SSL証明書の秘密鍵が漏えいした場合、CAが即座に該当証明書を失効させ、新しい鍵で証明書を再発行すればいいと認識されがちです。
SSL証明書の秘密鍵漏えい時のコストは？
しかし、この認識に問題はないのでしょうか。
ディスク暗号用の秘密鍵がデータセンターの奥深くで使用されているのに対し、SSL用秘密鍵は、インターネットと企業内部ネットワークとの境界で使用されています。すなわち鍵が漏えいすれば誰にでも簡単に侵入するチャンスがあります。さらに侵入といってもSSLが保護しているサーバー内部に侵入するのではなく、クライアントPCとSSLサーバーとの間に入り込み、自社のシステムを使用するエンドユーザーの重要な個人情報を盗みます。
実際の漏えい時点から漏えいしたと認識するまでの期間が長ければリスクが高くなる
SSLの秘密鍵さえ入手できれば、ホテルやその他公共の場所での無線LAN環境で簡単にこのようなことが可能になります。そして自社のシステムには何の痕跡も残しません。
したがって秘密鍵が漏えいしたかなどは実際に被害などが報告されてからでないと分かりません。実際に鍵が漏えいしてから自社システムの管理者が漏えいに気づくまでにかなりの時間が掛かりえます。
秘密鍵を頻繁に替えることが現実的な対処
SSL証明書の秘密鍵もディスク暗号化の秘密鍵と同等レベルの保護をすることで、漏えいのリスクが小さくなりますが、現実的にはサーバー数が多い・無人リブートが必須・サーバーソフトウェアが対応していないといった理由から、ほとんどの場合現実的ではありません。
現実的な対処は、秘密鍵を頻繁に替えることでしょう。定期的な鍵の変更に加えて漏えいする可能性が高いイベント発生後に替えたほうがよいでしょう。
たとえば以下のようなイベントが考えられます。」
A) SSLサーバーへ侵入された可能性が発見された場合即座に新しい鍵に切り替える。（これは当然です）
B) システム構築においてテスト後、秘密鍵・証明書を切り替える。
C) サーバーの移動・入れ替えなどの後に、秘密鍵・証明書を切り替える。
このように鍵の漏えいリスクが高まるイベント後に鍵を変更することが重要だと考えます。
最近は複数年の有効期間を持つSSL証明書も販売されていますが、そのような証明書でも一度設置してしまえば契約年数は大丈夫というわけではなく、rekeying（秘密鍵を変更して証明書を再発行すること）をすることで漏えいリスクを軽減すべきでしょう。
まとめ
SSLサーバー証明書の現状の設置方法を考慮すると、rekeying（秘密鍵を変更して証明書を再発行すること）を運用に取り入れることが鍵の漏えいリスクを軽減する最も有効な手段である。長期の有効期間を持つSSL証明書を利用している場合でも鍵の漏えいの恐れがあるイベントの後にはかならずrekeyingを行い、証明書を切り替えるようにする。
今回がこのシリーズの最終回となります。SSLサーバー証明書を使用するサーバーアプリケーションは多数存在し、その設定・運用方法はさまざまです。今回の検証ではLinux上のメール・ウェブ・FTPサーバーといったメジャーなソフトウェアへの証明書設置を通じてKousec Server Certificate Managerの使い勝手と運用上の注意点をレポートいたしました。