Java 2 セキュリティーのアクセス制御例外

Java™ 2 セキュリティーの振る舞いは、それ自体のセキュリティー・ポリシーで指定されます。 セキュリティー・ポリシーとは、特定のコード・ベースがアクセスできるシステム・リソースを指定し、 そのシステム・リソースへの署名が必要なユーザーを指定するアクセス制御マトリックスです。 Java 2 セキュリティー・ポリシーは、java.security.AccessController.checkPermission メソッドによって実行される宣言です。

以下の例は、java.security.AccessController.checkPermission メソッドのアルゴリズムを表します。 アルゴリズムの詳細については『セキュリティー: 学習用リソース』の項目の Java 2 セキュリティー検査の許可アルゴリズムを参照してください。

i = m;
while (i > 0) {
if (caller i's domain does not have the permission)
throw AccessControlException;
else if (caller i is marked as privileged)
return;
i = i - 1;
};

このアルゴリズムでは、java.security.AccessController.checkPermission メソッドが実行されるときに、 呼び出しスタック上のすべてのクラス (呼び出し元) に許可があることが必要で、 許可がない場合には、その要求は拒否され、java.security.AccessControlException 例外が作成されます。 ただし、呼び出し元が特権とマークされていて、 そのクラス (呼び出し元) にその許可が付与されている場合、 アルゴリズムは戻り、呼び出しスタック全体が全探索されることはありません。 後続のクラス (呼び出し元) に、必要な許可が付与されている必要はありません。

java.security.AccessControlException 例外は、 java.security.AccessController.checkPermission メソッドの実行中に、 呼び出しスタック上の特定クラスに必要な許可が欠落している場合に作成されます。 以下に示すのは、java.security.AccessControlException 例外について考えられる 2 つの解決方法です。
  • アプリケーションが Java 2 セキュリティーで保護されているアプリケーション・プログラミング・インターフェース (API) を呼び出す場合は、アプリケーションの Java 2 セキュリティー・ポリシーに必要な許可を付与します。 アプリケーションが Java 2 セキュリティーで保護されている API を直接呼び出さない場合、必要な許可は、Java 2 セキュリティーで保護されているリソースにアクセスするサード・パーティー API の副次作用によりもたらされます。
  • 必要な許可がアプリケーションに付与されている場合、必要以上にアクセスが行われます。 この場合は、Java 2 セキュリティーで保護されているリソースにアクセスするサード・パーティー・コードへの、特権のマークが適切ではない可能性があります。

呼び出しスタックの例

これは呼び出しスタックの例で、 ここでは、アプリケーション・コードがサード・パーティーの API ユーティリティー・ライブラリーを使用して、 パスワードを更新しています。 以下の例では、ポイントを説明しています。 コードに特権とマークする場所を決めるのは、 アプリケーションに固有で、しかも状況によって異なります。 この決定について的確な判断を下すには、 かなり深いドメインについての知識とセキュリティーの専門的知識を持っている必要があります。 このトピックについては、詳しく解説した出版物や書籍が多数あります。 詳細については、このような資料を参照することを強くお勧めします。
このコール・スタックの例は、アプリケーション・コードが、どこでサード・パーティーの API ユーティリティー・ライブラリーを使用してパスワードを更新しているのかを示しています。次の例は、そのポイントを示すために提供されています。コードをどこで特権としてマークするのかを決定するのは、アプリケーションに固有であり、どのシチュエーションでも一意です。これを決定するには、正しい判断をするためのドメインに関する深い知識とセキュリティーに関する専門知識が必要です。

PasswordUtil ユーティリティー を使用すると、ユーザーのパスワードを変更できます。 ユーティリティーで旧パスワードと新規パスワード (こちらは 2 回) を入力して、正しいパスワードが確実に入力されるようにします。 旧パスワードがパスワード・ファイルに保管されているパスワードと一致した場合、 新規パスワードは保管され、パスワード・ファイルが更新されます。 スタック・フレームに、特権とマークされたものがないと仮定します。 java.security.AccessController.checkPermission アルゴリズムに従うと、 呼び出しスタック上のすべてのクラスにパスワード・ファイルへの書き込み許可が付与されている場合を除いて、アプリケーションは失敗します。 クライアント・アプリケーションには、パスワード・ファイルに直接書き込む許可、 およびパスワード・ファイルを任意に更新する許可がありません。

ただし、PasswordUtil.updatePasswordFile メソッドによって、 パスワード・ファイルにアクセスするコードに 特権のマークが付けられた場合、PasswordUtil クラスに 必要な許可が付与されているかぎり、 許可確認アルゴリズムは、 その許可のために PasswordUtil.updatePasswordFile メソッドを 呼び出すクラスから、 必要な許可を確認することはありません。 クライアント・アプリケーションは、パスワード・ファイルへの書き込み許可を付与しなくても、パスワードの更新を正常に実行できます。

コードに特権とマークする権限は、大変柔軟で強力です。 この権限は正しく使用されないと、 システムのセキュリティー全般が危険にさらされ、 セキュリティー・ホールが露出されることになる可能性があります。 コードに特権とマークする権限を使用する場合は十分に注意を払ってください。

java.security.AccessControlException 例外に対する解決方法

前述したように、java.security.AccessControlException 例外を解決する方法は 2 つあります。 これらの例外について以下の解決方法のどちらが最適であるかを個々に判断してください。
  1. 与えられていない許可をアプリケーションに付与する。
  2. 問題点とリスクを考慮した後、一部のコードに特権とマークする。

トピックのタイプを示すアイコン 概念トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_access
ファイル名:csec_access.html