JKS-キーストア保護および構成ファイル
Javaキーストアは、多くの場合、構成ファイルを使用してWebサーバーによって使用されます。JKSを開くパスワードが記述されており、パスワードが特定のエントリを保護しています。
それはどのように安全であると考えられますか？このスキームでは、「秘密の問題」がファイルに移動しました。ファイルがユーザー権限で保護されている場合でも、暗号化する必要がありますね。しかし、それは、Webサーバーが起動するたびに、管理者が対称キー（PBKDF2）を生成してファイルを復号化するためにパスワードを入力する必要があることを意味しますか？
これを安全に管理する方法について詳しく知りたい。
@whoamiが述べたように、問題を別の場所に移動するだけです。あなたが言及したように、それをコードの外に移動し（ハードコードした場合）、パスワードで保護し（もともとはPEMまたはディスク上のものだけの場合）、必要なアクセス許可にACLを適用できます。
問題は、ロックを解除するためのキーを知っている必要があること、そしてもちろんそれはある種の保護を必要とすることです、そしてまあ、カメはずっと下に落ちます。
あなたが基本的に行っていることは、攻撃者の足を引っ張って攻撃者がより多くの努力を払わなければならないことです。ある時点で、彼らはそれをねじ込むと言って、次に進みます。キーの生成に複雑さを導入することでさらに難しくすることができますが、攻撃者がこれがどのように機能するかを知っている場合は、十分簡単にそれを行うことができます。 OSがランダムキーを保護するメカニズムを提供する場合もありますが、この場合は、JVMに公開されるものが必要になります。
より実用的なソリューションには、より保護された領域にキーを移動することが含まれます。これは通常、何らかのハードウェアを意味します。場合によっては、TPM、HSM、または単にスマートカードについて話していることもあります（これらはすべて同じものですが、機能が異なります）。基本原則は、キーがハードウェアから出ることはないため、盗むことは不可能です。この副作用として、通常、すべての暗号化はハードウェア自体で行われるため、暗号化自体を気にすることなく、データを押し込んだり、データを取り出したりするだけです。
つまり、許可されたシステムのみがハードウェアと通信できるように、ハードウェアへのインターフェースを保護する必要があります。カメはもう見えましたか？
はい、そうです、問題は別の場所に移動するだけです。
PBKDF2を使用してキーストアのパスワードを保護する方法はいくつかあります。
- アプリケーションサーバーの起動時に必要なパスワードを使用する（ご説明のとおり）。
- デプロイメント環境について知っている「もの」からPBKDF2のパスワードを作成します。たとえば、ホスト名、ユーザー名、MACアドレスを連結します。
番号2には、誰もパスワードを覚える（またはメモする）必要がないという利点があります。また、パスワードがどのように構成されているかを理解していない限り、インサイダーによってキーストアがコピー/盗難された場合にも役立ちます。
2.を使用することの欠点は、たとえば、ネットワークカードに障害が発生して交換された場合、キーストアパスワードの復号化に必要なキーを取得できないことです。
上記の両方の方法は、私が個人的にそれが実装されているのを見てきました。