証明書管理：Netflix Lemurフレームワークによる秘密鍵の配布
私のチームは現在の内部PKI管理ツールでいくつかの課題を抱えており、他のソリューションを探しています。チームメンバーの1人が、Netflixのオープンソースフレームワークである Lemur に関するページへのリンクを転送してくれました。
それはかなりよく書かれた記事であり、議論されていることのほとんどは私が見て、経験した闘争に関連しているようですが、私が混乱していることが1つあります。
次の図は、「一般的な調達プロセス」を示しています。
私が通常行うことは、 Java keytool のようなものを使用して、ホスト上に新しいキーペアを生成することです。これにより、キーが生成され、キーストアに格納されます。次に、CSRが作成され、CAによって署名されます。次に、署名された証明書がストアにインポートされます。この図は、このプロセスを説明するために解釈できると思いますが、秘密鍵が「展開ターゲット」から出ないことを明確に示していません。
提案された新しい調達プロセスは次のようになります。
この図から、秘密鍵は別のサーバーで生成され、（おそらく安全な手段を介して）「展開ターゲット」に配信されるように見えます。
CSRを生成し、秘密鍵を移動することなく公開鍵に署名する機能は、私にはかなり洗練されているようです。なぜかこのように設計されていると思いました。利便性の観点からは利点を確認できますが、この秘密キーをプッシュするアプローチは、本質的に秘密キーが公開されるリスクを増やすのではないですか？
記事の本文には、他の場所で生成された証明書をサポートできると書かれていますが、これはLemurを使用して証明書を生成する方法への移行に役立つことを意味しています。それが一歩前進であると私は確信していません。何か不足していますか？
うん、それは私もそれを読む方法です。
Netflixのような大規模なクラウドベースの会社の場合、Lemurサーバーは仮想化された製品環境クラスターの一部であり、したがって製品環境の他のすべてと同じレベルのネットワークセキュリティに保持されると思います。たとえば、展開ターゲットが実際にVMホストのクラスターであり、ロードバランサーの背後にある場合（またはロードバランサー自体がTLS接続を終了している場合）、プライベートキーのコピーはある程度行われます。 Lemurサーバーをクラスターに追加しても、大規模なクラウドデプロイメントにすでに備わっているもの以外の追加の攻撃面が開かれることはありません。
Prodサーバーが1台のマシンである小規模なデプロイメントの場合、懸念は正当化されると思います。秘密鍵のコピーの追加コピーについて質問することは価値があると思います。
一般的に、過去にNetflixは、コードのベイクされたAMI（VMイメージ）を展開することを伝えていました。これは通常、必要に応じて起動するAmazonの自動スケーリンググループを使用していることも意味します。これはコンテナによって変わりますが、同じ一般的な原則が成り立ちます。 1
これは通常、秘密鍵などの秘密に大きな影響を与えます。サービスを実行するホスト上でそれらを生成しておらず、アプリケーションアーティファクトに秘密を焼き付けていません。実行時にそれらをプルダウンするか、ロードバランサーにロードします。
Lemurが念頭に置いている第2のビットであり、HashiCorpのVaultと呼ばれる別の製品が強くプッシュしていることは、シークレットを生成/保存する場所を集中化することで、シークレットの場所が限定的に広がることです。また、証明書の生成のために余分なものをプロダクションイメージに焼き付けていないことも意味します。それはあなたがおそらくいくつかのジューシーなターゲットを持っていることを意味しますが、私がこれらの多くのプレイヤーから見てきた要点は、爆風半径によって隔離されたいくつかのものを集中的に保護する方が、数百または数千のものを不十分に保護するよりも簡単であるということです。通常、これは有効期間の短いシークレットを使用して行われるため、物事が危険にさらされた場合にそれを変更するだけで、それを実践することができるため、被害は限定されます。