キーストアファイル(.jks
)をソース管理に保存する際のベストプラクティスについて質問があります。このキーストアは、SAMLアサーションに署名する目的で秘密鍵を取得するスタンドアロンJavaコンポーネントによって呼び出されます。
セキュリティ上の理由から、このキーストアをJavaコードと同じgitプロジェクトに含めないでください。このソースコードは、使用するさまざまなツールのさまざまな場所にプッシュされます。(コードレビューツール、ソースコードスキャナー)と、キーストアファイルをこれらすべての場所に配置することで何か良いことができるとは思いません。
そのため、このファイルをソース管理に含めるのに最適な場所はどこですか?私はインターネットの周りを掘り下げたがまだ良い答えを見つけることができなかったので、ここに私の考えを述べる。
プランA
ロックされたプライベートリポジトリにキーストアファイルを配置する予定です。これは非常に限られた聴衆だけがアクセスできます。キーストアは、デプロイメントプロセスによる依存関係として、ビルド時にスタンドアロンコンポーネントに追加されます。
-長所
-短所
プランB
静的キーストアを保持する代わりに、ビルドプロセスが開始されるたびに、疑似ランダムキーを使用して新しいキーストアがビルドされます。その後、キーはビルドプロセスのZipの一部として追加されます。次に、証明書をキーストアに追加する必要があります。このJava=モジュールのインスタンスのほとんどは一意の証明書を持っているため、静的参照を維持しなくても大量のビジーな作業が発生することはありません。
-長所
攻撃者が利用できる静的キーストアはありません
キーストアの各インスタンスには独自のパスワードがあります
-短所
ビルドプロセスの複雑さを増す
このモジュールの複数のインスタンスで同じ証明書を使用する場合は、それぞれに証明書を追加する必要があります。
私のより良いオプションはどれですか?また、これで正しい道を進んでいますか?
私が働いていたすべての組織は、資格情報または同様に機密情報を、アプリケーションの展開ディレクトリの外のよく知られた場所に格納し、環境ごとに保護されています。開発者は開発者の資格情報を使用してファイル自体を作成しますが、本番のファイルはopsによって作成され、アプリケーションのみがアクセスできるように保護されます。
チェックアウト後にアプリケーションを設定なしで実行したい場合は、既知の場所にファイルが見つからない場合にのみ使用されるダミーのコピーを埋め込むことができます。
私のより良いオプションはどれですか?また、これで正しい道を進んでいますか?
状況によります。
アプリケーションの種類、アプリケーションの脅威モデル、およびビジネス攻撃プロファイルによって、適切なオプションが決まります。ベストプラクティスについて質問がある場合は、HSMデバイス 開発環境用と本番用を使用することをお勧めします。これらのデバイスは、安全なキー管理のために意図的に構築されています。他のカスタムオプションには、1つ以上のセキュリティ上の欠陥、不必要な複雑さ、または未知の攻撃ベクトルがあります。
明らかに、HSMデバイスによって提供されるセキュリティにはコストがかかります。他の実用的なオプションは、ソフトウェアベースの内部PKIインフラストラクチャを実装することです。サーバースタック(MS、Unixなど)によって異なりますが、実装方法はさまざまです。たとえば、pki.io 、オープンソースのX.509証明書管理プロジェクトですが、若いプロジェクトなので、内部キー管理を簡略化できます。