WebサーバーのSSL秘密キー保護を管理する方法（パスワードとパスワードなし）
私の会社のセキュリティグループでは、SSL秘密キーを管理するための次のオプションの中で何が悪いのかについて話し合っています。
Webサーバーは、暗号化操作のために秘密鍵にアクセスする必要があります。このファイルは、不正アクセスから保護する必要があります。同時に、サーバーは人間の介入なしに自動的に起動するはずです（十分に安全であれば）。
3つのオプションについて説明します。
ファイルシステムの権限でキーを保護します。
パスワードで保護されたキーを使用し、再起動するたびにキーを手動で入力してください。
パスワードで保護されたキーを使用し、ファイルシステムにキーを保存して再起動を自動化します。
私たちの懸念は次のとおりです。
オプション1の場合、再起動は自動的に行われますが、セキュリティが侵害されると秘密キーがコピーされ、保護されていないため、通信の偽装やサーバーのなりすましに使用される可能性があります。
オプション2の方が安全と思われますが、人の介入が必要であり、営業時間外にシステム管理者が心配する場合があります。また、パスワードは複数のシステム管理者と共有する必要があり、共有シークレットはもはやシークレットではないことがわかります。
オプション3は、以前の両方のオプションの中で最も優れていますが、誰かがキーにアクセスできる場合は、パスワード:(にもアクセスできるため、まったく安全ではないようです。
サーバーの秘密鍵のセキュリティをどのように管理しますか？他の（より安全な）オプションはありますか？
オプション1は、受け入れられる標準だと思います。
ただし、本当に追加のセキュリティが必要な場合は、Webサーバーを監視するように（DMZにない）安全なサーバーを設定してみてください。Apacheがダウンした場合、自動的にできます。リモートでログインし、パスフレーズを指定してApacheを再起動します。
したがって、パスフレーズはコンピューター上に保持されますが、Apacheが実行されているものと同じではなく、DMZ内ではありません。パスフレーズを使用するというセキュリティが強化され、自動再起動の機能が維持されます。
キーを読み取るための十分なアクセス権がサーバーにある場合は、デバッガーを接続してメモリからキーを取得するための十分なアクセス権も持っている可能性があります。
深夜に起きてパスワードを入力するのが本当に好きな場合を除いて、オプション1を選択してください。サーバーが多数ある場合、障害時に自動再起動する必要があり、オプション2はそれを許可しません。
1.よりも高いが、2。よりもダウンタイムが短いセキュリティの1つの可能性は、有効期限の短い秘密鍵を作成し、それらを定期的にリサイクルすることです。そうすれば、パスフレーズなしでそれらを保存できますが、脆弱性のウィンドウを減らします。
ご存じのとおり、オプション3.は、1。よりもセキュリティを強化しません。
実用性により、ほとんどすべての状況でオプション（1）を使用することになります。ファイルシステムのアクセス許可は、ほとんどのセキュリティと実際のシナリオを比較するのに最適な方法です。
* nixシステムでは、秘密鍵をルートのみに制限できます。これは、Apacheなどの最も優れたWebサーバーはルートとして起動しますが、必要な特権ポート（80、443など）を取得すると、特権を制限されたユーザーにダウングレードします。 。
あなたが述べたように、オプション（3）はセキュリティの観点からはオプション（1）と同じです。