SSL証明書を保護する方法（Apache / CentOS）
私は現在、Apacheを無人で起動できるようにするために、パスフレーズなしでサーバーSSL証明書を使用しています。
SSL証明書をより安全に保護することを要求する顧客からの兆候があります。彼らが何を目指しているのかはまだわかりませんが、今のところ、彼らはディスク上に保護されていないSSL証明書を望んでいないと思います。私はそれをApacheのメモリ内のクリアに置くことを避けられないと思いますが、それは許容できると仮定しましょう。
パスフレーズを内部サーバー（つまり、最前線のWebサーバーではない）のプロセスのメモリに保持し、Apache SSLPassPhraseDialogを使用して最前線のサーバーに渡すための精巧なシステムを思いつきました（- http://httpd.Apache.org/docs/2.2/mod/mod_ssl.html#sslpassphrasedialog ）。内部サーバーは、起動時にパスフレーズを入力する必要があります。高可用性を実現するために、このようなサーバーを複数ロードバランシングします。
私の質問は：
- 「ビッグボーイ」はSSL証明書をどのように保護しますか？サーバーの再起動時にパスフレーズを入力するように強制するのでしょうか、それとも他の人と同じように暗号化しないでおくのでしょうか。
- オープンソースでの私の経験では、誰かが私が直面している問題をすでに解決している可能性が非常に高いです-そのようなシステムはすでに利用可能ですか？
- ビジネスレベルの観点から、証明書を暗号化せずに保持し、盗まれた場合に証明書を取り消すための迅速な手順があると言うのは合理的でしょうか？
階層型PKIモデルで、最初に公開鍵インフラストラクチャの基本を確認しましょう。
- 公開鍵は暗号化/ロッカーであり、認証局によって作成された証明書に埋め込まれています。
- 秘密鍵は、公開鍵と組み合わせて使用される復号化/ロック解除です。
- 公開鍵と証明書には機密性の要件はありません。
- 秘密鍵には機密保持要件があります
したがって、Apacheに関する懸念は、公開鍵ではなく秘密鍵にあるはずです。セキュリティエンジニアが秘密鍵を保護する一般的な方法は、ハードウェアセキュリティモジュールを使用することです。ハードウェアセキュリティモジュール（HSM）には、スマートカード、PCIeカード、PCIカード、USBドングル、USBスティック、ネットワークベースのHSMなど、さまざまなフォームファクタがあります。したがって、これらは大量の予算とセキュリティ機能をカバーできます。
レベル1（ソフトウェア一般）2物理（耐タンパー性）3物理（耐タンパー性と侵入応答）および4物理（改ざん防止）のFIPS 140-2）などのセキュリティ実装を検証したHSMがいくつかあります。耐タンパー性、侵入応答、およびキーのゼロ化）。
あなたのビジネスが何かをすべきかどうかを評価するために、私は費用便益分析と、ALE、ARO、およびSLEの計算を含むリスク評価を行うことを検討します。ただし、Webを介してビジネスを行っている場合は、Webセキュリティの専門家を招いてすべてのインフラストラクチャを評価し、脆弱性と弱点の統合リストを作成し、優先順位を付けた修復計画を立てることをお勧めします。あなたの管理。
「ビッグボーイ」は、クラスター化されたフロントエンドロードバランサーにSSLオフロードを実行します。これは、私が行っていることであり、「ビッグボーイ」の近くにはいないためです。
Httpd.Apache.orgでパスフレーズダイアログの削除について これらの手順 を見つけました。これは、問題をグーグルで検索した場合に見られる可能性があります。
失効の問題は、署名したCAに翻弄されて、急いで問題に対処していることです。あなたがあなたの証明書に多額のお金を払うならば、私は彼らのサービスが非常に前向きであると確信しています。一部の小規模卸売業者にとってはどうなるかはわかりません。多分誰か他の人がチャイムを鳴らすことができます。