WebサーバーのSSL秘密キー保護を管理する方法（パスワードとパスワードなし）

私たちの会社のセキュリティグループでは、SSL秘密キーを管理する次のオプションの悪い点について議論しています。

Webサーバーは、暗号化操作のために秘密鍵にアクセスする必要があります。このファイルは不正アクセスから保護する必要があります。同時に、サーバーは人間の介入なしで自動的に起動するはずです（十分に安全な場合）。

次の3つのオプションについて説明しています。

1. ファイルシステムのパーマでキーを保護します。

2. パスワードで保護されたキーを使用し、再起動するたびにキーを手動で入力します。

3. パスワードで保護されたキーを使用し、ファイルシステムにキーを保存して、再起動を自動化します。

私たちの懸念は次のとおりです。

1. オプション1では、再起動は自動的に行われますが、妥協により秘密キーがコピーされ、保護されていないため、通信の解読やサーバーのなりすましに使用される可能性があります。

2. オプション2はより安全なように見えますが、人間の介入が必要であり、システム管理者はそれが営業時間外に発生するかどうかを心配しています。また、パスワードは複数のシステム管理者と共有する必要があり、共有シークレットはシークレットではないことがわかります。

3. オプション3には以前の両方のオプションがありますが、誰かがキーにアクセスできればパスワード:(にもアクセスできる可能性があるので、まったく安全ではないようです。

サーバーの秘密鍵のセキュリティをどのように管理しますか？他の（より安全な）オプションはありますか？

オプション1は、受け入れられている標準だと思います。

ただし、追加のセキュリティが本当に必要な場合は、Webサーバーを監視するために安全なサーバー（DMZではない）を設定して、Apacheがダウンした場合、自動的にリモートでログインし、Apacheを再起動してパスフレーズ。

そのため、パスフレーズはコンピューター上に保持されますが、DMZ内ではなく、Apacheが実行されているものと同じではありません。パスフレーズを使用することでセキュリティが強化され、自動再起動の機能が維持されます。

誰かがサーバーにアクセスしてキーを読み取ることができる場合、おそらくデバッガーを接続してメモリからキーを取得するのに十分なアクセス権も持っています。

真夜中に目を覚ましてパスワードを入力するのが本当に好きでない限り、オプション1に進みます。多くのサーバーがある場合は、失敗時に自動再起動する必要があり、オプション2はそれを許可しません。

1より高いセキュリティで2より短いダウンタイムの可能性の1つは、有効期間が短い秘密鍵を作成し、定期的にリサイクルすることです。そうすれば、パスフレーズなしでそれらを保存できますが、脆弱性の窓を減らします。

ご存知のように、オプション3は1を超える追加のセキュリティを提供しません。

実用性により、ほとんどすべての状況で、オプション（1）を使用することになります。ファイルシステムのパーマは、ほとんどのセキュリティシナリオと実際のシナリオで最適な方法です。

* nixシステムでは、プライベートキーをrootのみに制限できます。ほとんどの優れたWebサーバー（apacheなど）はrootとして起動しますが、必要な特権ポート（80、443など）を取得すると、権限を制限されたユーザーにダウングレードします。

前述のように、オプション（3）はセキュリティの観点からはオプション（1）と同じです。