最近、ドメイン用のワイルドカードSSL証明書を購入しました。すべての証明書をJavaキーストアに変換しましたが、ここで、後で使用するためにこれらの証明書をどこに保存するかを自問しています。
人々はこれらのタイプのファイルにBitBucketのようなソース管理を使用しますか、それともそれが必要とされるたびに、または何か他のものを生成しますか?
これらの証明書を将来使用するために保存することに関して、標準的な解決策や「ベストプラクティス」があるかどうか疑問に思っています。
複数の解決策があります:
1つの方法は、ハードウェアベースのアプライアンス、 ハードウェアセキュリティモジュール 、またはソフトウェアベースの同等の特定のキーボルトです。
もう1つは、状況が発生したときに単に古いキーを取り消し、新しい1つの秘密/公開キーペアを生成することです。これにより、キーのセキュリティの維持から、証明書プロバイダーと再発行のためのアカウントを使用したアカウントのユーザー名/パスワードの保護に問題が多少移行します。利点は、ほとんどの組織がすでに特権アカウント管理ソリューションを持っていることです。 12
オフライン保存には、パスワードを含む秘密鍵と公開鍵のペアのハードコピーを印刷する方法(ただし、復元するのは雌犬になります)から、長期保存用のデジタルメディアに保存する方法まで、さまざまな方法があります。 。
本当に悪いところは、GitHub、あなたのチームWiKi、またはネットワーク共有です(そしてあなたはそのアイデアを思いつきます)。
2015年4月29日更新:Keywhiz も興味深いアプローチのようです。
いいえ、SSL証明書はソース管理に含まれていません。少なくとも秘密鍵の部分は含まれていません。
パスワードと同じように扱います。パスワードはKeePassに、パスワードとまったく同じ方法で実際に保存されます。ファイルを添付することができ、暗号化されています。
秘密鍵をソース管理に置くと、それにアクセスできる人はだれでもサーバーを偽装できるようになります。 WebサーバーがPFS(完全転送秘密)を使用していない場合、Wiresharkなどの一般に利用可能なオープンソースツールを使用して、キャプチャされたSSLトラフィックを復号化することもできます。
キーは、DESまたはOpenSSLを使用してパスフレーズで暗号化するAESによって保護できます。OpenSSLは、Linux、OSX、およびWindowsで使用できます。
OpenSSLは、パスフレーズが不便な場合(たとえば、自動的に起動するがパスフレーズの自動入力をサポートしないWebサーバー上)に、パスフレーズを削除することもできます。
AES暗号化を使用してパスフレーズを追加する(DESよりも安全):-
openssl rsa -aes256 -in private.key -out encrypted.private.key
パスフレーズの削除(パスフレーズの入力を求められます):-
openssl rsa -in encrypted.private.key -out decrypted.private.key
KeyWhizについて読んだ後の別のオプションは、HashiCorpのVaultでした。これは単なるパスワードマネージャーではなく、シークレットストアです。 GOで記述されており、クライアントはサーバーとしても機能し、一連のバックエンドと認証方法にフックします。 Vaultもオープンソースで、Enterpriseオプションも付いています。
SSLキーと証明書は単なるテキストファイルなので、base64でエンコードして、文字列としてVaultに保存したり、テキストだけをVaultに保存したりすることもできます。 WebUI、またはGUI、そのすべてのコマンドライン、またはスクリプト駆動型ではなく、起動するための非常に優れた安定したWeb APIがあります。
秘密キーと証明書を保存するには、オフラインのHSM(ハードウェア暗号化トークンやCACなど)を調べることをお勧めします。これにより、秘密鍵が偶発的な侵害から保護されるだけでなく、基本的な暗号オフロードも提供されます。
管理する暗号化資産がさらにある場合は、更新の自動化、ライフサイクルの追跡、エンドポイントへのプロビジョニングの自動化などを行うことができるエンタープライズキーおよび証明書管理ソフトウェアを検討することをお勧めします。これらのほとんどは、保管時に暗号化された資産をデータベース内のCLOB。