証明書を更新するときに秘密鍵を変更する必要がありますか？
私のセキュリティ部門は、私（システム管理者）がWebサーバー用のSSL証明書を更新するときに新しい秘密鍵を作成するように要求しています。彼らはそれがベストプラクティスだと主張していますが、私のグーグルでの試みは彼らの主張を検証することに失敗しました。正しい方法は何ですか？
私が見つけた最も近いものは 毎年新しいSSL秘密キーを再生成する必要がありますか？ ですが、キーを変更する必要がある理由は実際には説明されていません。
作業中にキーを変更することは大したことではないことはわかっていますが、適切な理由や説明なしに、言われたことを実行するだけではありません。
恐ろしく小さいキーサイズを使用している場合を除いて、それらの提案はそれほど確固としたものではないと思います。その場合、まったく別の問題が発生します。
ほとんどの見積もり による2048ビットの鍵は、少なくとも2020年まで、それより長くない場合でも安全です。 1024ビット以下のキーで実行している場合は、標準を下回っています。すぐに2048ビットに更新することをお勧めします。現在1536ビットのキーを使用している場合は、1〜2年は安全です。
もちろん、これはすべて学問的に言えます。誰かが1年以内に1024ビットSSLキーを解読できる（または傾倒する）可能性は非常に低いです。
リンクした質問で述べたように、利点と欠点があります。
メリット
- 攻撃者がキーをクラックする時間が短くなります。とにかく妥当なサイズのキーを使用している場合は、やや問題があります。
- 秘密鍵を危険にさらした可能性のある悪意のある者を停止します。可能性は低いですが、不明です。
- 鍵のサイズを大きくして、先行することができます。
欠点
- 非常に小さなキーを使用している場合を除き、キークラッキングに対する具体的な保護は実際には提供されません。
- ブラウザ用のSSLチェック/ Anti-MitMプラグインは、キーが変更されたことをユーザーに警告する場合があります。これは私の意見では弱い欠点です-ほとんどのユーザーはこれを使用しません。
- より厳密な [〜＃〜] hsts [〜＃〜] ポリシーと実装に関連して一時的な警告が発生する可能性があります。
- 仕事が必要です。あなたは何か他のことをしている可能性があります。
したがって、両側にいくつかの弱い理由があり、いくつかのケースを検討する必要があります。 2048ビット以上のキーを使用している限り、「必要なとき以外はやらない」という角度に少し傾けます。
最も重要なことは、質問することですthemなぜ彼らがそれが必要であると考えるのか-それは、私たちが知らないキーを更新するためのインフラストラクチャ関連の理由がある可能性があります。彼らが確固たる議論を思い付くことができない場合（「なぜそうでないのか」は実際には有効ではない）、彼らはおそらく彼らのアドバイスを再評価すべきである。
秘密鍵の変更はベストプラクティスではなく、widespreadプラクティスです。実際には、セキュリティとはほとんど関係がなく、一般的なCAが証明書の更新を処理する方法、つまりほとんどの場合、新しい秘密鍵の生成を伴う新しい証明書のように多くのことを行います。 CA側では、更新のために特別なことをしない方が簡単です。したがって、キーを変更する習慣があります。
同じシステム管理者は、セキュリティの観点から、状況は似ていますが、SSHサーバーの新しいキーを毎年生成することをしません。または、より正確には、SSHサーバーキーを変更すると、.ssh/known_hostsクライアントのファイル。したがって、SSHサーバー鍵の変更を避けるのが通例です。したがって、SSHサーバー鍵は長期間有効です。誰もそれについて本当にハートビートをスキップしません。なぜ彼らは同様の暗号強度のSSLキーについて心配する必要があるのですか？
ベストプラクティスは、一般的なパラノイア（「コンプライアンス上の理由で」と呼ばれることが多い）を考慮して、技術の進歩によりキーがやや脆弱になったときにキーを変更することです。そのため、2013年には、1024ビットのRSA鍵を長い鍵に置き換える必要がありますが、そのような鍵を破ることはまだ不可能です。 RSAキーが1536ビット以上の場合、新しいものを作成する暗号上の理由はありません（ただし、CA側で変更する方が便利な場合もあります）。
答えは技術的でも暗号でもありません、それは人々についてです。仕事の変更（不満を持つ管理者のことを聞いたことがありますか？）、サーバーの移行、DRテスト、バックアップなどの秘密鍵は、少し公開される可能性があります。
上記を踏まえると、キーの更新はセキュリティのベストプラクティスです。
RSAキーを誰かがファクタリングすることを心配しないでください。 1024ビットのRSA鍵を因数分解することは、州レベルの攻撃者にとっては可能かもしれませんが、それらにとってさえ、おそらく費用効果的ではありません。 2048ビットキーの因数分解は、数十年の間はおそらく不可能です。
主に、サーバーの侵害で秘密鍵が盗まれるのではないかと心配しています。攻撃者がサーバー上に永続的なマルウェアを持っている可能性があるため、過去の侵害の場合の利益は少し不明確です。したがって、新しいキーを保護するためにサーバーを再インストールする必要があります。
別の問題は、一部の弱いSSLスイート（主にRSA暗号化ベースのファミリー）が、認証だけでなく機密性のために長期キーを使用することです。これらを使用すると、サーバーキーの侵害により、そのような脆弱なスイートを使用していたサーバーとの過去のすべてのSSL通信の復号化が可能になります。新しいキーを使用し、古いキーを安全に削除することで、このような攻撃の影響を制限します。
したがって、サーバーでこれらのスイートが有効になっている場合は、定期的にキーを変更することを強くお勧めします。
- HeartBleedの後でキーを変更しましたか？
- データセンターの技術者は不良ハードドライブをどうしますか？
- 昨年、誰かが運用組織を辞めましたか？
- 最後に管理者パスワードとSSHキーをローテーションしたのはいつですか？
これらの質問はすべて、鍵の完全性について考えるきっかけとなるはずです。彼らが危険にさらされている可能性がある、または誰かがそれらを悪用できる可能性があると言っているのではありません。なぜそれらを回転させたいのかを考えさせようとしています。
キーのローテーションは非常に簡単で、安全性に優れています。難しいからやってないのなら、それは深刻な問題です。簡単にするためのツールとプロセスを構築します。そうしないと、はるかに重要なものを回転させることができなくなります。
キーを使うほど、攻撃者に与える時間が長くなります。現在のテクノロジーでは2048ビットを壊すことは不可能と考えられていますが、特に注意してキーを交換することは決して悪いことではありません。
さらに、あなたがそれを検出することができなくても、誰かがあなたの秘密鍵をなんとか入手できた可能性があります。彼が行動を繰り返すことができない場合、更新の利点は非常に明確です。
証明書を更新するたびに新しいキーを生成する技術的な理由はほとんどないことに同意しますが、セキュリティチームやマネージャーにすぐに異議を申し立てて、問題について電話することはしません。
新しいキーを生成するのと同じくらい有効な非技術的な理由が考えられます。たとえば、ITの集中化、スキル、手順、および適切な慣行のレベルがさまざまである大規模な組織では、一元化されたセキュリティ管理領域で、リスクの一部を軽減するためにそのような慣行が必要になる場合があります。扱いやすい。技術的な観点から見ると、より複雑な手順の方が正しい場合がありますが、文書化するのが難しく、スタッフが手順を正しく実行していることをスタッフが認識しにくくなります。練習によって大きなオーバーヘッドが発生しない場合は、より単純なalways Xアプローチを採用して維持する方が簡単な場合があります。
別の観点から考えてみてください。証明書の管理に責任を持つ組織内のすべての人が、問題と同じように認識し、理解していますか。また、それらは徹底的/専任ですか。従業員の離職率のレベルと、従業員がアクセスできる機密データの量などをどの程度懸念する必要があるか。
セキュリティを検討するときは常に、ヒューマンファクターは、技術的な側面だけでなく、ほぼ常に同じくらい重要です。ポリシーと手順では、人的要素を考慮し、これらのポリシーと手順が、必要な理由を十分に理解していない場合でも、スタッフが正しいことを実行できるように構成されていることを確認する必要があります。
SP 800-57パート1改訂、キー管理の推奨
RSA暗号化期間に関するNISTの推奨事項は、1〜2年のようです。
Sslホストキーがローテーションされないことの引数として、sshホストキーがローテーションされることはめったにないという事実を何人かが指摘しました。それは解決すべき別の問題のようです。 （少し話題から外れた回答をお詫びしますが、ここで数人がそれを述べたので適切と思われます）
なぜキーをローテーションしたいのかについては、上記の私の答えを参照してください。
以下は、コンプライアンス上の理由から、sshホストキーをローテーションする必要があるが、エンドユーザーへのユーザビリティの影響を心配するすべての人に特に役立ちます。
1）ssh_caをデプロイします（man ssh-keygenの非常に完全な手順）
ssh-keygen -f ssh_ca -b 4096
2）証明書をユーザーに配布します：〜/ .ssh/known_hostsに認証局の行を追加します
@cert-authority *.domain.name ssh-rsa AAAAB3[...]== Comment
3）ホストキーに署名します（それぞれを個別のホストに制限するようにしてください）
ssh-keygen -s ssh_ca -I Host.domain.name -h -n Host.domain.name -V +52w /etc/ssh/ssh_Host_rsa_key.pub
4）証明書を提示するようにサーバーを構成します（/ etc/ssh/sshd_config）：
HostCertificate /etc/ssh/ssh_Host_rsa_key-cert.pub
CAによって署名されたすべてのホストキーがクライアントによって信頼されるようになりました（初めて接続するときにキーsigを盲目的に受け入れることはなくなりました）。
ホストキーのローリングは、クライアントを中断することなく実行できるようになりました。キー署名は、ホストのビルド/オーケストレーションプロセスに組み込むことができます。
これ は良いリファレンスです。 このプロジェクト は、ssh_caを使用して自動期限切れユーザーアクセスを有効にするための便利なツールをいくつか作成しました。
実際にパスワードを変更するのと同じです。パスワードを変更するときに誰かがパスワードを解読している場合、そのユーザーは最初からやり直す必要があります。または、パスワードまたは秘密キーが盗まれた場合、更新によって盗まれたキーが無効になります（簡単に再度盗むことができないと想定）。
秘密鍵を毎年または数年ごとに変更するのはよい習慣かもしれません。変更する必要があるときに何も壊さないようにするためですが、証明書自体のセキュリティには必要ありません。