1

組み込みの Jetty を使用して、Linux 上で実行されている既存の Java Web アプリケーションがあります。アプリケーションは、ルートとして実行され、ポート 443 でリッスンし、ポート 8443 で権限の低いユーザー「appname」の下で実行される Java アプリにリクエストを中継する jsvc を使用してロードされます。

現在、アプリケーションは「secrets.properties」と呼ばれるファイルから暗号化キーを読み取ります。これは、「root」によって書き込み可能であり、「appname」によって読み取り可能です (技術的には、「appname」グループのメンバーによって)。ただし、私の好みは、ファイルが「ルート」によってのみ読み取り可能であり、jsvc がファイルを読み取り、そのファイルの内容 (または単一のプロパティのみ) をアプリケーションに渡すことです。私の目標は、誰かがアプリを破壊し、アプリの「appname」アカウントでシステム アクセスを取得できたとしても、キーを取得できないようにすることです。

「ps -ex」を実行している誰かにキーが表示されなくても、それは可能ですか?

4

1 に答える 1

1

キーを取得できない場合もありますが、それでも使用できます。

攻撃者はアプリケーションを制御するようになったため、アプリケーションが危険にさらされていないと信じて、必要なメッセージを送信したり、署名/暗号化したりすることができます。アプリケーションからのデータを認証しようとしているだけの場合、これを行う意味はほとんどありません。

いずれにせよ、サーバーが危険にさらされた場合はキーを取り消すのが賢明なので、キーも保存されません。

さて、あなたが長命の鍵の侵害を心配して、攻撃者が以前に送信された（しかしもはやアプリに保存されていない）メッセージを読むことを可能にするなら、それは別の問題です。完全転送秘密を備えた暗号システムを使用することをお勧めします。TLS / SSLには、ECDHEまたはDHEを含むスキームである認証済みDiffie-Helmenキー交換を使用する場合にこれがあります（例：ECDHE-ECDSA-AES128-GCM-SHA256またはTLS-DHE-RSA-with-AES-256-CBC- SHA）

何らかの理由でキーが危険にさらされることをまだ心配している場合は、プロキシを作成できます。ルートとして実行することも、別のグループとして実行してキーを渡すこともできます。TLS / SSLの場合、これは簡単です。知っているいくつかのカスタム暗号化/署名システムの場合。しかし、繰り返しになりますが、これを実行したい理由はほとんどありません。

于 2012-05-02T06:25:46.807 に答える