2

現在、Java EE(より正確にはWebLogicサーバー)に基づくシステムの開発に参加しており、管理者から一部のプライベートデータを保護する方法を考えています。たとえば、システムの一部では、レガシーシステムの資格情報がプレーンテキストとして展開記述子に保存されますが、展開者はアプリケーション構成ファイル(ejb-jar.xmlたとえば)を読み取り、強力なアカウントのユーザー名とパスワードを盗むことができるため、これは不適切です。このセキュリティホールを閉じたいのですが、方法がわかりません。

今、私はこの種のデータを保護することに興味があります:

  1. ログイン
  2. パスワード
  3. 対称暗号化用の秘密鍵

ここから、JCEKSキーストアを使用してこの種の情報を保護できることを発見しましたが、その使用方法がわかりません。私のアプリケーションには、kestoreパスワードとそれにアクセスするためのキーパスワードが含まれている必要があります。したがって、デポイヤーはキーストアとキーのパスワードを盗み、私の安全なストレージを見つけ、資格情報を盗むことができます。明らかにread、デプロイヤーアカウントから特権を取り消すことができますが、その後、彼は私のアプリケーションを逆コンパイルして、安全なデータをファイルに印刷したり、電子メールで送信したりするだけの独自の同様のアプリを開発(または編集)できます...そして今、私は立ち往生しています...

管理者からシステムを保護する方法を説明できるリンクを誰かに教えてもらえますか?Weblogic関連のリンクが望ましいでしょう。すべての管理者から保護することは不可能でありsecurity administrator、キーストアの管理などを担当する管理者もいるはずですが、他のすべての人からすべての機密データを保護したいと思います。

結果

jtahlbornslimの両方の答えは正しいですが、slimの答えはもっと興味深いものです。私の場合、サーバーにインストールするために署名されたアプリケーションのみを受け入れることが適切だと思います。この決定により、管理者が行うアプリケーションの変更に関する問題を解決できます。管理者は、キーストアとすべてのキーのパスワードを使用できますが、キーストアファイルにアクセスすることはできません。キーストアファイルへのアクセスには、特別なセキュリティ管理者('rw')とサーバー('r')のみが含まれます。したがって、誰もがキーを持っていますが、誰も(セキュリティ管理者を除いて)ボックスにアクセスできません。

4

3 に答える 3

6

アプリケーションの起動時にログイン資格情報を入力しない限り、この問題の解決策はありません(管理者がアプリケーションのメモリにアクセスできないと仮定すると、安全な仮定ではない可能性があります)。 アプリケーションと同じ場所にキーを配置するソリューションでは、管理者(アプリケーションファイルシステムにアクセスできる)が、アプリケーションからアクセスできる機密データにアクセスできるようになります。これはDRMの問題に似ています(誰かにロックされたボックスとキーを渡して、ボックスを開けられないと期待することはできません)。

于 2012-08-30T16:02:20.340 に答える
3

この質問の要点は「admin」の定義にあると思います。

あなたは、キーストアにアクセスできる「セキュリティ管理者」に満足していると言っています。

従来、UNIXタイプは、「admin」を「root」ユーザー、つまりマシン上のすべてにアクセスできるユーザーと見なしていました。ルートは、アプリケーションメモリをのぞき見したり、rawディスクアドレスの読み取り/書き込みに至るまで、文字通り何でも実行できます。サーバーが秘密鍵を取得できる場合は、rootも取得できます。

アクセスが制限された「管理者」ロールを定義する場合は、そうです。そのようなユーザーが存在する場所に何かを設定できます。「管理者」が実行できないことがアプリで実行できる(秘密鍵を取得する)ことが少なくとも1つあるため、サーバーアプリケーション自体よりも少ない特権が必要になります。

このようなユーザーは、おそらくアプリをインストールすることもできません(可能であれば、秘密鍵を公開するバージョンのアプリを作成してインストールできるため)。したがって、「管理者」は秘密鍵で機能するコンポーネントを展開できませんでした。ただし、そのコンテナ内で実行されるモジュールをデプロイする可能性があります(コンテナがモジュールに秘密鍵を提供できない場合)。

ただし、保護したいのはキーだけではありません。本当の「秘密」は、キーを使用して暗号化されたデータです。したがって、上記のアプローチにはまだ問題があります。モジュールが暗号化されたデータを読み取ることができる場合、モジュールと同じ権限を持つ「管理者」も読み取ることができます。そして、それはモジュールをインストールできる人を含みます。

「管理者」が独自のバージョンを作成できないように、モジュールに署名する方法を調査できます。

ただし、信頼できない管理者を有効にするために必要な対策は、単に信頼できる管理者を使用するよりも(時間と労力の点で)費用がかかるという点があります。

したがって、いわゆる「管理者」が実行できることのリストを作成する必要があります。それらが何であるかに応じて、root以外のユーザーにそれらのことを許可することが可能かもしれません。UNIXでは、sudoなどのツールを使用して、root以外のユーザーがサーバーの起動/停止、ログの読み取り、ログのクリーンアップなどを実行できるようにすることができます。

于 2012-08-30T16:18:07.683 に答える
1

認証をアプリケーションの他の部分から分離できる可能性があります。

たとえば、TLSで保護されたソケットを介してレガシーシステムと通信する場合、アプリケーションからの暗号化されていない接続を受け入れ、安全で認証されたレガシーシステムへの接続を確立し、アプリケーションとレガシーシステム。基本的に、これは認証プロキシです。その場合、アプリケーションはこれらのキーを必要としません。キーを含むファイルを読み取る権限がないユーザーとしてアプリケーションをインストールして操作することはできますが、アプリケーションはレガシーシステムと通信できます。

もちろん、プロキシに対してアプリケーションを認証する方法の問題があります。プロキシがループバックインターフェイスでのみリッスンしている限り、マシンは十分に安全であるため、それを行う必要はまったくないと感じるかもしれません。そうでない場合は、代わりにUNIXドメインソケットを使用でき、ファイルシステムのアクセス許可を使用してアクセスを制御できます。特定のグループのユーザーとしてアプリケーションを実行し、ソケットへのアクセスをそのグループのメンバーに制限できます。Javaは標準ライブラリでunixドメインソケットをサポートしていませんが、 junixsocketまたはJUDSを使用して追加できます

于 2012-08-30T16:34:04.173 に答える