| Oracle Access Managerアクセス管理ガイド 10g（10.1.4.3） B55477-01 |
|
 戻る |
 次へ |
アクセス・システムにより、ポリシー・ドメインを定義することで、Webコンテンツや従来のアプリケーションなどのリソースにどのユーザーをアクセスできるようにするかを制御できます。ポリシー・ドメインは、通常、Web上のリソースを識別するURL接頭辞を1つ以上含みます。ポリシー・ドメインには認証および認可ルールが含まれ、どのユーザーがいつリソースにアクセスできるかを決定します。また、ポリシー・ドメインは、非Webベースのリソースを保護できます。
さらに、ポリシー・ドメイン内にポリシーを作成して、リソースに対するより詳細な保護、たとえば、特定のWebページまたはページ・セットを保護するよう定義できます。
ポリシー・ドメインおよびポリシーごとに監査ルールを定義して、システム・イベント、ユーザー認証の成功と失敗、ユーザーの認可の成功と失敗などを監視および記録できます。
この章では、ポリシー・ドメイン、ポリシーおよび監査ルールの構成方法を説明します。この章の内容は次のとおりです。
『Oracle Access Managerインストレーション・ガイド』の手順に従ってOracle Access Managerがインストールされ、実行されている必要があります。
ポリシー・ドメインを作成する前に、次の説明をお読みください。
第3章「WebGateおよびアクセス・サーバーの構成」: アクセス・ゲートおよびアクセス・サーバーの構成方法について説明しています。構成は、作成したポリシー・ドメインを有効にする前に行う必要があります。
第5章「ユーザー認証の構成」: ポリシー・ドメインに含める認証ルールおよびスキームの作成方法が記載されています。
第6章「ユーザー認可の構成」: ポリシー・ドメインに含める認可ルールの作成方法が記載されています。
また、マスター管理者は、ポリシー・ドメインを作成するには、最初に次のタスク概要に示すタスクを実行する必要があります。
ポリシー・マネージャの設定時にポリシー・ベースを定義します（「ポリシー・ベースの概要」を参照）。
ポリシー・ベースを確認するには、アクセス・システム・コンソールで「システム構成」→「サーバー設定」の順にクリックします。「サーバー設定の表示」ページの「ポリシー・データ構成」セクション内に、コンピュータ名、ポート、ルートDN、ディレクトリ・サーバー・セキュリティおよびポリシー・ベースが表示されます。
ポリシー・マネージャの設定時にポリシー・ドメイン・ルートを定義します（「ポリシー・ドメイン・ルートの概要」を参照）。
ポリシー・ドメイン、リソース・タイプおよびアクセス制御スキームを作成し、ポリシー・ドメインの委任管理者のロールを他のユーザーに割り当てるマスター・アクセス管理者を作成します。
「マスター・アクセス管理者の構成」を参照してください。
「ポリシー・ドメイン管理の委任」を参照してください。
ポリシー・マネージャのインストール時に、マスター管理者は、ポリシー・データを保存する場所を指定します。ポリシー・マネージャの設定時に、ポリシー・ベースも作成されます。ポリシー・ベースとは、ポリシー・ドメインとそのポリシーのオブジェクト・クラス用のディレクトリ・ツリーの最上位ノードです。
ポリシー・ドメインに関するすべての情報は、ポリシー・ベースとの関連において格納されます。ポリシー・ドメインに関するすべての情報は、ルールおよび保護対象のリソースも含め、ポリシー・ベースの下に同じレベルで格納されます。
ポリシー・ドメインまたはポリシーを構成するには、最初にマスター管理者がポリシー・ルートを定義する必要があります。「ポリシー・ドメイン・ルートの概要」を参照してください。
WebPassおよびポリシー・マネージャURLの保護: WebPassおよびポリシー・マネージャ・インスタンスをWebGateで保護することをお薦めします。これを行うには、これらのWebコンポーネント・インスタンスを同じWebサーバーにインストールし、ポリシー・マネージャの設定時にIdentityドメインとAccessドメインのデフォルトのポリシーを有効にします。WebPassおよびポリシー・マネージャURLをさらに保護するには、URLへのアクセスを管理ユーザーのみに制限するポリシーを作成します。
ポリシー・マネージャの設定時に、マスター管理者はポリシー・ドメイン・ルートを指定します。ポリシー・ドメイン・ルートはURL接頭辞であり、この下にあるすべてのリソースが保護されます。デフォルトのポリシー・ドメイン・ルートは、すべてのリソースを網羅する広範なものである必要があります。デフォルトのルートは「/」です。
|
関連項目: URLの詳細は、「リソースのURLの構成」を参照してください。ポリシー・マネージャ設定時のポリシー・ドメイン・ルートの定義の詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。 |
リソースを保護するには、ポリシー・ドメインを作成します。ポリシー・ドメインは次のもので構成されます。
保護対象のリソース
Webページ、サイト・ドメイン（Webリソースのコレクション）、サーバー、ファイル、アプリケーション、その他の実行可能プログラムなど、Webベースと非Webベースの両方のリソースを保護できます。
ポリシー・ドメインにリソースを追加するには、リソースが格納されているURLを特定のレベルに指定します。単一のリソース（アプリケーションなど）のURLを指定することも、フォルダ、ファイルおよび実行可能プログラムのディレクトリ全体を1つのURLで保護することもできます。
認証、認可および監査ルール
認可条件式
ポリシー・ドメイン内のリソースのサブセットを保護するためのポリシー
ポリシーは、リソースのセット、認証、認可、監査ルールおよび認可条件式で構成されます。
様々な管理者に与える、ポリシー・ドメインの作成権限および変更権限
この項の残りの内容は次のとおりです。
|
注意: リソースを保護するには、マスター管理者がポリシー・ドメイン・ルートおよびポリシー・ベースを事前に定義する必要があります（「前提条件」を参照）。また、マスター管理者は、マスター・アクセス管理者も定義する必要があります（「マスター・アクセス管理者の構成」を参照）。 |
マスター・アクセス管理者は、ポリシー・ドメイン・ルートの定義後に最初のポリシー・ドメインを作成する必要があります。これにより、最初のポリシー・ドメインの下にURL用の各ポリシー・ドメインを作成し、これらのポリシー・ドメインの管理をその他の管理者に委任できます。
ポリシー・ドメイン・ルートの詳細は、「ポリシー・ドメイン・ルートの概要」を参照してください。
デフォルトでリソース・タイプが未定義のドメイン追加対象リソースに対して、リソース・タイプを定義します。
詳細は、「リソース・タイプの構成」を参照してください。
マスター監査ルールを作成します。
詳細は、「マスター監査ルールの概要」を参照してください。
ポリシー・ドメインの認証スキームを作成します。
詳細は、「認証と認証スキームの概要」および「認証ルールの管理」を参照してください。
ポリシー・ドメインの認可スキームを作成します。
アクセス・システム付属の認可スキームの使用方法の詳細は、「認可ルールの構成」を参照してください。
カスタム・スキームの詳細は、「カスタム・プラグインの認可スキームの概要」を参照してください。
最初のポリシー・ドメインのリソースのURLを構成します。
詳細は、「リソースのURLの構成」を参照してください。
ポリシー・ドメインの認証ルールを作成します。
詳細は、「認証ルールの管理」を参照してください。
認証ルールのアクションを作成します（オプション）。
詳細は、「認証アクションの管理」を参照してください。
1つ以上の認可ルールを作成します。
詳細は、「認可ルールの概要」を参照してください。
認可ルールのアクションを作成します。
詳細は、「認可ルールのアクションの設定」を参照してください。
1つ以上の認可ルールが含まれるポリシー・ドメインの認可条件式を作成します。
詳細は、「認可条件式の概要」を参照してください。
ポリシー・ドメインの監査ルールを作成します。
詳細は、「ポリシー・ドメインの監査ルールの作成」を参照してください。
ポリシー・ドメインをテストします。
詳細は、「アクセス・テスターの使用方法」を参照してください。
ドメインの管理を委任アクセス管理者に委任します。
詳細は、「ポリシー・ドメイン管理の委任」を参照してください。
委任アクセス管理者は、管理権限が付与されたポリシー・ドメインを管理できます。
次のタスク概要に、委任アクセス管理者として実行できるタスクを示します。必要に応じてこれらのタスクを実行してください。必須のタスクはありません。
ポリシー・ドメインまたはそのポリシーの認証ルールを置き換えます。
このタスクを行うには、最初にポリシー・ドメインまたはポリシーの既存の認証ルールを削除する必要があります。
認証ルールを作成するには、マスター・アクセス管理者によって作成された認証スキームを選択し、ルールのアクションを構成します。詳細は、「認証ルールの管理」を参照してください。
ポリシー・ドメインまたはそのポリシーの認可条件式を置き換えます。
このタスクを行うには、最初にポリシー・ドメインまたはポリシーの既存の認可条件式の内容を削除する必要があります。
ポリシー・ドメインまたはそのポリシーに認可条件式を作成するには、ポリシー・ドメイン・レベルで作成された1つ以上の認可ルールを組み合せます。「認可条件式の概要」を参照してください。
監査ルールをマスター監査ルールから導出して作成します。
「ポリシー・ドメインの監査ルールの作成」および「ポリシーの監査ルールの定義」を参照してください。
ポリシー・ドメインをテストします。
「アクセス・テスターの使用方法」を参照してください。
委任アクセス管理者がポリシー・ドメインを作成できるのは、特定の権限セットを付与された場合です。詳細は、表4-4を参照してください。
次のタスク概要に、ポリシー・ドメインの作成手順をまとめます。
ポリシー・ドメインのリソースのURLを構成します。
詳細は、「リソースのURLの構成」を参照してください。
ポリシー・ドメインの認証ルールを作成します。
詳細は、「認証ルールの管理」を参照してください。
認証ルールのアクションを作成します。
詳細は、「認証アクションの管理」を参照してください。
ポリシー・ドメインの認可ルールを1つ以上作成します。
詳細は、「認可ルールの概要」を参照してください。
認可ルールが失敗または成功した場合に、そのルールで取るアクションを定義します。
詳細は、「認可アクションの概要」を参照してください。
1つ以上の認可ルールを含むポリシー・ドメインの認可条件式を作成します。
詳細は、「認可条件式の概要」を参照してください。
認可条件式の評価結果（成功、失敗、未確定）に応じて取るアクションを作成します。
詳細は、「ルールと式に対するアクションの概要」を参照してください。
ポリシー・ドメインの監査ルールを作成します。
詳細は、「ポリシー・ドメインの監査ルールの作成」を参照してください。
ポリシー・ドメインをテストします。
詳細は、「アクセス・テスターの使用方法」を参照してください。
ポリシー・ドメインに対してポリシーを構成します（ポリシーがある場合）。
詳細は、「ポリシーの構成」を参照してください。
|
注意: 構成できるのは、管理権限のある別のポリシー・ドメインのリソース定義にすでに含まれているポリシー・ドメイン・リソースURLです。詳細は、「リソースのポリシー・ドメインまたはポリシーの設定方法」を参照してください。 |
ポリシー・ドメインとは、同じ方法で保護するリソース用に定義された論理構造のことです。特定のポリシーにより、ポリシー・ドメインのリソースのサブセットを個別に特定的な方法で保護します。
ユーザーがポリシー・ドメインによって保護されたリソースへのアクセスをリクエストすると、そのリクエストはドメインの認証ルールとその認可条件式に基づいて評価されます。
ユーザーがポリシー・ドメインで保護されたリソースにアクセスを試みるには、たとえば、ブラウザへのURLの入力、アプリケーションの実行、その他の外部ビジネス・ロジックのコールなど、いくつかの方法があります。
この項の残りの内容は次のとおりです。
ポリシー・ドメインは、次の構成要素からなります。
ドメインの認証ルールと認可条件式で保護されたリソースのパスを定義するURL
ポリシー・ドメインには、相互に独立したURLを複数含めることができます。あるURLに含まれるリソースが、同じポリシー・ドメインにある別のURLに含まれるリソースとは異なるホストにあってもかまいません。ポリシー・ドメインのデフォルトのルールは、特定のポリシーによって保護されているリソースを除いて、そのポリシー・ドメインに含まれるすべてのリソースに適用されます。
ポリシー・ドメインに追加するすべてのリソースは、リソースの置かれているホストとリソースのURLによって指定します。ホストは、複数の名前で識別できます。アクセス・システムは、リソースのURLを認識できるよう、そのリソースのホスト・コンピュータを参照するために使用される様々な方法を認識できる必要があります。
ホスト識別子機能により、ホストの正式名と、ユーザーがホストの参照に使用する他のすべての名前を入力しておくことができます。このリストの特定のアドレスに送信されるリクエストは、正式ホスト名にマップされます。ホスト識別子の詳細は、第3章「WebGateおよびアクセス・サーバーの構成」を参照してください。
ホスト識別子機能を使用して、複数のコンピュータにある同じポリシー・ドメインにリソースを追加するためのホスト・コンテキストを設定できます。ホスト・コンテキストの概要と用途の詳細は、「ホスト識別子とホスト・コンテキストの使用方法」を参照してください。
認証ルールでは、リソースにアクセスしようとするユーザーの本人証明を行う方法を決定します。認証ルールには、認証スキームが含まれます。認可ルールでは、リソースにアクセスする権限がユーザーにあるかどうかを判定します。認可ルールには認可スキームが含まれ、認可ルール自体は認可条件式に含まれます。認可条件式には、1つ以上の認可ルールを含めることができます。監査ルールでは、ポリシー・ドメインまたはポリシーに関する操作の監査ログに記録する情報（監査）を決定します。監査ルールは、マスター監査ルールから導出されます。詳細は、次の情報を参照してください。
認証ルールおよび認証スキームについては、第5章「ユーザー認証の構成」。
認可スキーム、認可ルールおよび認可条件式については、第6章「ユーザー認可の構成」。
監査ルールおよびマスター監査ルールについては、「ルールと式の概要」および「マスター監査ルールの概要」。
URLパターン用のポリシーとパターンを適用するリソース・タイプに許可する操作
ポリシー・ドメイン内のリソース用ポリシーにより、ドメイン内の特定のリソースを保護するための、よりきめの細かい方法を作成できます。URLパターンを指定することも、リソースを識別する明示的なURLを指定することもできます。リソースのタイプに応じて独自の操作があります。指定できるのは、各タイプのリソースで使用できる操作（リクエスト・メソッドともいう）です。パターンに一致するURLを持つリソースのリクエストは、さらにポリシーのルールに照合して処理されます。
ポリシーの詳細は、「ポリシーの構成」を参照してください。
図4-1に、ポリシー・ドメインの構成要素の概念図を示します。この図では、Webベースのリソースのみが表示されています。ただし、アクセス・システムのポリシー・ドメインは、非Webベースのリソースも保護できます。
ポリシー・ドメインには、次のような各種のリソースを含めることができます。
外部Webサイト全体
Webサイトの特定のページ
パートナのポータル
部品発注アプリケーション
請求書アプリケーション
多国籍企業のWebサーバー上の利益計上アプリケーション
リソース・タイプの詳細は、「リソース・タイプの構成」を参照してください。
1つのリソースが、複数のポリシー・ドメインの定義に適合する場合があります。このようなリソースは、/mydomainなどの大きなポリシー・ドメインに含めることができます。また、/mydomain/myresourcesなど、下位のポリシー・ドメインに含めるのが適切な場合もあります。アクセス・サーバーは、すべてのポリシー・ドメイン定義をチェックして、リソースのURLに最も近いURL接頭辞を検出します。
アクセス・サーバーは、ポリシーをチェックするとき、ポリシー・ドメインのチェック方法とは異なり、ポリシーの構成時に指定された順序で行います。つまり、最初に一致したポリシーが使用され、残りのポリシーは無視されます。前のポリシーが一致したために、リクエストされたリソースに最も近い一致がチェックされないことがあります。目的とするポリシーが使用されるようにするため、また、処理の効率化のため、ポリシーを割り当てる順序に注意してください。
インストール時に、アイデンティティ・システムとポリシー・マネージャのリソース（URL）を保護するようにポリシー・ドメインを構成できます。インストール時に作成されるポリシー・ドメインとは次のものです。
これらのポリシー・ドメインのWebGateとアクセス・サーバーを構成した後、それとともに有効化または無効化する必要があります。
|
ヒント: インストール時の認証スキームとポリシーの構成の詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。 |
ポリシー・ドメインの管理の委任を使用すると、管理を拡張して、リソースに一番近い、リソースについて熟知している管理者がリソースを管理できるようになります。ポリシー・ドメインの作成と管理は、様々な管理者の間で分担できます。または、ポリシーの作成を一元化し、その管理と強制を分散化することもできます。マスター・アクセス管理者がいくつかのポリシー・ドメインを作成し、その管理を委任アクセス管理者に委任できます。委任アクセス管理者は、ドメインを管理し、ドメインのURLより特定性の高いURLを持つリソース用にポリシー・ドメインを作成できます。
例
企業のWebサイトを管理するWebマスターに、リソースのポリシー・ドメインの委任アクセス管理者のポジションを割り当てます。ポリシー・ドメインには、Webマスターが管理するその他のリソースも含まれます。
委任アクセス管理者は、エンタープライズ・レベルのアプリケーションなど、特定のリソースを管理することがあります。このようなアプリケーションの一例として、航空機の搭乗手続き検査システムがあります。アプリケーションの各インスタンスは多くのサーバーで実行されます。
アップグレードと呼ばれる関連の小規模アプリケーションは、同じ保護を要求するため同じ管理者によって管理されるので、両方のアプリケーションが同じポリシー・ドメインに属することになります。また、各アプリケーションのすべてのインスタンスは、同じポリシー・ドメインによって保護することもできます。
組織では、様々な目的と方法でポリシー・ドメインおよびポリシーを使用します。
人事管理およびマーケティング用ポリシー・ドメイン: この例では、ポリシーを使用して、ポリシー・ドメイン内のリソースに対する認可の拡張を提供します。ポリシー・ドメインでは、従業員とマーケティングのWebサイト部門に公開された人事管理情報を保護します。両方のリソース・セットには同じ種類の保護が必要とされます。
次の2つのURLでポリシー・ドメインの論理構造を定義します。
/AreteAirlines/marketing/reports/
/AreteAirlines/HR/
ポリシー・ドメインのどちらかの組織のリソースが、ポリシー・ドメインのデフォルトのルールより詳細な保護ルールを必要とする場合は、そのようなリソースを保護するためのポリシーを定義できます。たとえば、次のようにします。
/AreteAirlines/HR/のデフォルトの認可ルールでは、すべてのユーザーに平日のみのアクセスを許可します。
週末に作業する傾向のある人事マネージャについて、週末アクセス制限を人事管理ファイルのセットから解除するよう、ポリシーを定義することもできます。
同じポリシー・ドメインのprivateディレクトリには、正社員のみが参照できるリソース、たとえばアナリスト・レポートなどを含めます。
privateディレクトリは、reportsディレクトリの下位にあります。privateディレクトリのリソースは、ポリシーを使用して異なる方法で保護している場合を除いて、ポリシー・ドメインのデフォルト・ルールによって保護されます。privateディレクトリのリソースへのアクセスを制限するポリシーが1つあります。正社員のみが次のprivateディレクトリのレポートを参照できると規定されています。
/AreteAirlines/marketing/reports/private/
ポリシー・ドメインのURLは、リソースとして、badgitという名前のアプリケーションを含んでいます。人事管理部門の従業員はこのアプリケーションを使用して、アクセス権の取得のために、組織の従業員を登録できます。このメイン・アプリケーションは、リクエストを処理して、バックエンド・アプリケーションから情報を取得します。メイン・アプリケーションのみを保護するようにポリシーを使用します。このポリシーは次のURLに適用されます。
/AreteAirlines/HR/badges/badgit.exe
大学のポリシー・ドメイン: この例では、ポリシー・ドメインのリソースに対する緩やかな認証要件を提供するポリシーの使用を示します。大学では学生に情報を提供しますが、学外には提供しません。リソースを保護するポリシー・ドメインのURLは、次のとおりです。
/GlobalUniv/
下位のURLを持つポリシー・ドメインを2つ作成して、/GlobalUniv/ポリシー・ドメインでは保護されないリソースを追加します。
これらのポリシー・ドメインの1つには、URL /GlobalUniv/physics/が含まれています。
もう1つのポリシー・ドメインには、/GlobalUniv/philosophy/が含まれています。
ポリシー・ドメイン/GlobalUniv/physics/では、物理学専攻の学生のみポリシー・ドメインのリソースにアクセスできます。
物理学専攻のすべての学生が/GlobalUniv/physics/feynman/diagrams/ディレクトリのリソースにアクセスできます。/GlobalUniv/physics/ポリシー・ドメインのデフォルト・ルールが適用され、これらのリソースに適用される特別なポリシーがないためです。
ポリシーを作成して、testResults.htmlページを保護するポリシーの認可基準を満たす学生のみが、このページを参照できるようにします。簡単な質問に答えられた学生が次のWebページを参照できるようにします。
/GlobalUniv/physics/feynman/diagrams/testResults.html
この大学では、ブラック・ホールの世界を動画で見せるアプリケーション・スイートを提供します。これらのアプリケーションは物理学専攻の学生のみでなく、すべての学生が利用できます。これらのEnterprise JavaBean（EJB）アプリケーションの1つに対するURLは、/GlobalUniv/physics/wheeler/blackHoles/explore/styx.ejbです。
このアプリケーションはphysicsディレクトリの下位のwheelerというディレクトリにあるため、ポリシーを使用して、すべての学生用のリソースを公開しているwheelerディレクトリへのアクセスを禁止する必要があります。
管理ロールを割り当て、同一または異なるホスト上の同種または異種のリソース用のポリシー・ドメインを管理する職責を管理者に与えることができます。ポリシー・ドメインは、保護対象のリソースに適合するよう、また、その管理者の方針に従って定義することが重要です。リソースに誰がアクセスできるかは、ポリシー・ドメインのアクセス制御ルールを介して定義できるため、あまり重要ではありません。
次の例は、リソースの管理を分散することが有効である理由を示しています。
より高速および高品質のオンライン・アプリケーション・サービスを従業員に提供できます。
たとえば、サービスの向上によって、アプリケーションがより高速に起動されて使用可能になり、ホスト・システムの障害が発生した場合も容易に回復できるようになります。
従業員への通知用のWebサイトが、障害ができるだけ少なく、常に稼働して最新であるように保たれます。
保護するリソースの種類（リソースに関連付ける操作を含む）を定義します。リソースに関連付ける操作は、リソース・タイプによって限定されます。
リソース・タイプ、および保護するリソースに関連付ける操作を定義した後でのみ、ポリシー・ドメインにリソースを追加できます。
アクセス・システムには、いくつかのデフォルト・リソース・タイプが用意されています。マスター・アクセス管理者は、アクセス・システム・コンソールで、他のリソース・タイプを定義できます。
アクセス・システムでは、デフォルトで付属しているリソース・タイプより多くのリソース・タイプを定義する機能が提供されているため、Webベースでないリソースも保護できます。
この項の残りの内容は次のとおりです。
|
注意: カスタム・アクセス・ゲートを構成して非Webリソースを保護できます。詳細は、『Oracle Access Manager開発者ガイド』を参照してください。 |
Access Managerでは、リソースがディレクトリまたはファイル・レベルのリソースであるものと想定しています。次に例を示します。
http://server.domain.com:port/this/path/to/the/app?param1=x¶m2=y
問合せ文字列を含んだURLはエスケープされ、URL全体がディレクトリまたは名前付きリソースであるものとみなされます。前述の例では、文字列app?param1=X¶m2=Yは、エスケープされるため、通常のタイプのURLとは異なる方法で処理されます。たとえば、ユーザーが次のリソースをリクエストしたとします。
http://server.domain.com:port/this/path/to/the/app?param2=y¶m1=x
理論上は、これは前述のリソースと同じリソースです。ところが、アクセス・システムによって実行されるポリシー・ドメイン評価では、このリソースが見逃がされるため保護できません。同様に、次のURLがユーザーによってリクエストされた場合も、アクセス・システムでは、このリソースが見逃されるため保護できません。
http://server.domain.com:port/this/path/to/the/app?param1=x¶m2=y¶m3=z
この場合、リソースのポリシー・ドメインはURLパス・レベルで定義する必要があります。たとえば、次のようにします。
http://server.domain.com:port/this/path/to/the/app
下位のURLを扱えるよう、ポリシー・ドメインに1つ以上のポリシーを追加できます。ポリシーには、*param1=X¶m2=Y*という問合せ文字列パターンを含めることも、個別の問合せ文字列値のペアを含めることもできます。
アクセス・システムには、次のリソース・タイプが提供されています。
Enterprise JavaBeans（EJB）: EJBリソース・タイプは必須ではありません。
EJBリソースを保護する予定がない場合は、削除してもかまいません。
HTTP（HTTPS）: HTTPリソース・タイプ定義は、このタイプのリソースを保護するかどうかに関係なく必須です。
HTTPリソース・タイプを削除することや、それに対する操作を変更することはできません。
保護する他の種類のリソースについてタイプを定義する必要があります。
ポリシー・ドメインでは、次のリソース・タイプとその操作を保護できます。
EJBリソース
EXECUTE
HTTPリソース
GET、POST、PUT、TRACE、HEAD、CONNECT、OPTIONSなど
各操作を保護するには、ポリシーを定義します。
RDBMSリソース
ADD、DELETEおよびUPDATE
サーブレット・リソース・タイプ
表4-1に、HTTPリソース、Java 2 Enterprise Edition（J2EE）リソースおよび、URLによって識別されるその他のオンライン・アプリケーション・リソースの例を示します。
表4-1 アプリケーション・リソースおよびそのURL
| リソース・タイプ | 例 |
|---|---|
|
HTTPリソース |
|
|
|
|
その他のリソース |
|
リソース・タイプを定義するには、「新規リソース・タイプの定義」ページを使用します。
アクセス・システムのランディング・ページで、「アクセス・システム・コンソール」リンクをクリックします。
「ポリシー・マネージャ」で作業している場合は、ページの最上部にある「アクセス・システム・コンソール」のリンクをクリックします。
アクセス・システム・コンソールで、「アクセス・システム構成」タブをクリックし、左側のナビゲーション・ペインにある「共通情報の構成」リンクをクリックします。
「リソース・タイプ定義」サブタブをクリックします。
「すべてのリソース・タイプをリスト」ページが表示されます。
「すべてのリソース・タイプをリスト」ページで、「追加」をクリックします。
「新規リソース・タイプの定義」ページが表示されます。
「リソース操作」フィールドで、このリソース・タイプで実行できる操作を指定します。
カスタム操作が定義できますが、HTTPリソース・タイプには定義できません。
必要に応じてフィールドを追加または削除するには、プラス（+）またはマイナス（-）のアイコンをクリックします。
変更内容を保存する場合は、「保存」をクリックします。または、保存しないでページを終了する場合は、「取消」をクリックします。
アクセス・システムを使用してリソース（ビジネス・アプリケーションとそのコンテンツなど）を保護するには、URL接頭辞とURLパターンでリソースが識別されるポリシー・ドメインを作成する必要があります。
URL接頭辞: URL接頭辞を使用してポリシー・ドメインの内容を定義します。ポリシーの場合は、URLパターンを使用して、ポリシーによって保護するリソースを指定します。
広範なコンテンツを対象にできるURL接頭辞を作成できます。たとえば、次のようにします。
//sales/humanresources
このポリシー・ドメインの例では、保護対象のリソースは3つの異なるホスト上にあります。URL接頭辞に含まれるすべてのリソースは、次のようにポリシー・ドメインのデフォルト・ルールによって保護されます。
ポリシー: ポリシー・ドメイン内にリソースのポリシーを作成できます。たとえば、「/」の下に別の2つのグループのリソースがあるとします。その2つとはengineeringとmarketingです。
/engineeringにはポリシーが定義されていないため、そのリソースは現時点ではポリシー・ドメインのデフォルト・ルールによって保護されています。デフォルト・ルールはmarketingにも適用されます。
管理者が/engineeringに含まれるリソースのポリシーを作成すると、このengineeringのリソースは、ポリシー・ドメインのデフォルト・ルールによってではなく、ポリシーによって指定されたルールによって保護されます。
URLパターン: 限定性を高めるURLパターンを使用して、ポリシーを作成できます。たとえば、次のようなURLパターンがあります。
/.../update.html
このURLパターンは次のリソースに一致します。
/humanresources/benefits/update.html/corporate/news/update.htmlupdate.html
図4-2に、どのようにURL接頭辞とURLパターンを使用してポリシー・ドメインとそのポリシーに対してリソースを定義するかを示します。
詳細は、次のトピックを参照してください。
URL接頭辞は、ポリシー・ドメインのリソースの開始点です。また、URL接頭辞は、ポリシー・ドメインの最初の境界を定義することで、最初のリソースを定義します。URL接頭辞は、アプリケーション・サーバーまたはWebサーバーのいずれかにあるファイルシステムのディレクトリにマップされます。
URL接頭辞に含まれるすべてのリソースは、ポリシーを介してより個別性の高いルールが適用されている場合を除いて、ポリシー・ドメインのデフォルト・ルールによって保護されます。1つ以上のURL接頭辞をポリシー・ドメインに割り当てることができますが、各URL接頭辞が属することができるポリシー・ドメインは1つのみです。
限定性が高いポリシー・ドメインを多数作成すると、セキュリティが強化されるかわりに、オーバーヘッドの増大という負担が発生します。この負担が発生するのは、アクセス・サーバーがすべてのポリシー・ドメインを評価して、リソースを特定できるポリシー・ドメインを検出する必要があるためです。ポリシーを使用すると、同じ効果をオーバーヘッドなしで得られます。
次に示すのは、リソースの1番目のURL接頭辞を定義しているページのスクリーン・ショットです（「ポリシー・ドメインにリソースを追加する手順」を参照）。このスクリーン・ショットには、アイデンティティ・システムを保護するポリシー・ドメインが表示されています。
エンドユーザーは、ブラウザにリソースのURLを指定して、リソースをリクエストします。
たとえば、ユーザーはブラウザに次のURLを入力して、特定の提携先に関する情報を表示するデータ・ページへのアクセスをリクエストします。
www.AreteAirlines.com/Partners/mycorp.html
リソース（およびそのURL）を表すリンクを選択できるよう、ユーザー自身のWebサイトをあらかじめ設定しておくこともできます。
リクエストされたリソースが、アクセス・システムにより検出されます。
アクセス・サーバーでは、すべてのポリシー・ドメインを評価して、リソース用に入力されたURLに最も一致するURL接頭辞を持ったURLを突き止めます。（アクセス・サーバーでは、リソースがドメイン内のポリシーによって保護されるかどうかを判別します。保護される場合は、そのポリシーのルールが適用されます。）
ポリシーが適用されない場合、アクセス・システムでは、ポリシー・ドメインのルールを使用して、HTMLページへのユーザーのアクセスを許可するかまたは拒否するかを設定します。
ポリシー・ドメインではWebベースのコンテンツ以外のコンテンツを保護できます。ただし、図4-2のポリシー・ドメインでは、Webベースのリソースが保護されています。
URLパターンに一致したURLを持つ指定タイプのリソースに、個別のポリシーを指定できます。また、リソースに対して行うことができる操作の種類を指定することもできます。
URLパターンはアクセス・システムでサポートされているメカニズムで、1つのポリシーによって保護される特定タイプのリソースを1つ以上指定するためのものです。URLパターンには、ディレクトリ、問合せ文字列パターンまたは問合せ文字列変数を指定できます。完全修飾された明示的URLである場合は、1つのリソースを参照します。
多くのリソースを網羅するURLパターンの例は、部門のWebサイトの全HTMLページ（*.html）のURLです。この場合、ポリシーからは、ポリシー・ドメインのデフォルト・ルールでは課されている制限を削除できます。特定ファイルのURLパターンの例は、アプリケーションのシングル・インスタンスの完全修飾された明示的パス（URL）です。構成する各リソース・タイプで利用できる機能を、リソース操作と呼びます。たとえば、HTTPにはGET、POST、PUTなどの操作があります。
次に示すのは、詳細なポリシーにURLパターンを構成するページのスクリーン・ショットです（「ポリシーの追加」を参照）。内容としては、アイデンティティ・システムのロスト・パスワード管理アプリケーションを保護するポリシーが表示されています。このポリシーは、Identityドメイン用に構成されています。
/identityのURL接頭辞に、前出の画面のフォームに表示されているURLパターンを追加すると、次のURLパスにあるリソースを保護するパターンとなります。
/identity/oblix/apps/lost_pwd_mgmt/.../*
次に、ポリシー・ドメインに対して複数のURLパターンが定義されている画面を示します。内容としては、IdentityドメインにおけるポリシーとそのURLパターンがリスト表示されています。これらのURLパターンでは、アイデンティティ・システム内の様々なアプリケーションとデータ・ディレクトリを保護しています。
ポリシーのURLでは、リソースのネームスペースの詳細部分を指定します。URLを完全に識別するため、ポリシー・ドメインのホスト識別子とURL接頭辞が、ポリシーのURLパターンと連結されます。
ユーザーが、リクエストするリソースのURLを指定します。
アクセス・サーバーでは、ポリシー・ドメインのホストとURL接頭辞の情報に基づいて、URLパターンを含んだ完全修飾URLを作成します。
アクセス・サーバーでは、リクエストされたリソース用に入力されたURLを、ポリシー・ドメイン情報およびポリシーのURLパターンから作成された完全修飾URLと比較します。
一致がある場合、ポリシーの様々なルールが評価され、リクエストしたユーザーがリソースへのアクセスを許可されるか拒否されるかが判定されます。
リクエストしたユーザーがアクセスを許可された場合、リソースがユーザーに提供されます。
図4-1には、次のURLパターンが含まれる、Partnersというポリシー・ドメインの構造が示されています。
/Ace/.../*
ポリシーのURLパターンに対し、完全修飾名を取得するため、その前にポリシー・ドメインのURL接頭辞/Partnersが追加されます。ポリシー・ドメインのリソースがあるホストの名前は、URL接頭辞の前に指定するので、URLは次のようになります。
myhost/Partner/Ace/.../*
ポリシーとそのURLパターンの構成については、「ポリシーを追加する手順」を参照してください。
アクセス・システムでは、URLパターンを表現するためにグロビングという種類のフィルタリングを使用します。このフィルタリング方法は、UNIXの各種シェル（sh、csh、tcsh）でサポートされているファイル名パターンとアクセス・システム付属のパターン（たとえば、複数のディレクトリにまたがることができる「...」）を組み合せたものです。
表4-2に、サポートされているパターンを示します。
表4-2 サポートされているパターン
| パターン | 説明 | 例 |
|---|---|---|
|
? |
「/」以外の任意の1文字に一致します。 |
a?bは、aabとazbには一致しますが、a/bには一致しません。 |
|
* |
0以上の一連の文字に一致します。「/」には一致しません。 |
a*bは、ab、azb、azzzzzzbには一致しますが、a/bには一致しません。 |
|
[set] |
文字集合の1つに一致します。集合は、リテラル文字列または文字範囲として指定できます。文字範囲とは、ハイフン（-）で結ばれた任意の2文字間のすべての文字です。スラッシュ（/）は、集合に入れることができない無効な文字です。文字集合は、/を含んだ範囲が指定されている場合でも、/には一致しません。 |
|
|
{pattern1,pattern2,...} |
パターン集合の1つに一致します。中カッコ内部のパターン自体には、中カッコを除くその他の特殊文字を含めることができます（パターン集合はネストできません）。 |
|
|
/.../: |
スラッシュ（/）で囲まれた1つ以上の文字の連続に一致します。 |
|
|
\ |
円記号は、特殊文字をエスケープするために使用します。 前に円記号を付けた任意の1文字は、その文字自体に一致します。 |
|
URLパターンはアクセス・システムでサポートされているメカニズムで、1つのポリシーによって保護される特定タイプのリソースを1つ以上指定するためのものです。次の属性のあるパターンは無効です。
次の属性のあるパターンは無効です。
終了の「]」のない「[」
終了の「}」のない「{」
「{}」の内部にあるエスケープされていない「{」
「[]」の内部にあるエスケープされていない「/」
{}内に含まれる次のURLパターンは認識されません。
{pattern_1, pattern_2, /.../cleanup.asp}
次のURLパターンは、{}なしで使用される場合のみ認識されます。
/.../cleanup.asp
{}内のURLパターンは、次のように式を単純化するように設計されています。
a{ab,bc}b matches aabb and abcb
a{x*y,y?x}b matches axyb, axabayb, ayaxb, etc
{}内のURLパターンには、先頭に「/」が付くような複雑なサブ式を含めないでください。次に例を示します。
{/.../cleanup.asp OR /c*/webservice/webservice.asp}
そのかわりに、次のように3つのポリシーを個別に作成するようにします。
??/admin/* /c*/webservice/webservice.asp /.../cleanup.asp
ポリシーとそのURLパターンの構成については、「ポリシーを追加する手順」を参照してください。
ポリシーでは、次のパターン・タイプを1つ以上含むことができます。1つのポリシーに複数のパターンが指定された場合、入力されるURLは、それらのパターンのすべてに一致する必要があります。一致しないURLは、そのポリシーで保護されません。
次のように入力されたURLを使用する例で説明します。
http://www.myserver.com/oblix/sales/index.html?user=J.Smith&dept=sales
ポリシーには次のURLパターンが含まれます。
URLの絶対パスに対するパターン
このパターンは、スキーム（http）、ホストおよびドメイン（www.myserver.com）と疑問符（?）文字の間にあるURLの部分です。この例では、絶対パスは/oblix/sales/index.htmlです。
URL内の名前/値ペアに対するパターン
このペアのセットはパターンとして構成できます。操作がGETの場合は、このペアは、URLの疑問符（?）文字の後にある問合せデータに適用されます。操作がPOSTの場合は、問合せデータがPOSTデータの後に表示されます。ペアが1つの場合、名前には、パターンではなく名前の値を指定します。ペアの値要素はパターンとして構成されます。次に例を示します。
| 名前 | パターン |
|---|---|
| user | *Smith |
| dept | *sales* |
複数の名前/値ペアを指定した場合、入力されたURLはそれらすべてのペアに一致する必要があります。したがって、次のURLはパターンに一致しません。
http://www.myserver.com/oblix/sales/index.html?user=J.Smith &dept=engg
このような名前/値ペアに対する優先度がないため、次のパターンは、このパターンとは大きく異なってきます。すなわち、次のURLはこのパターンに一致します。
http://www.myserver.com/oblix/sales/index.html?dept=sales&user=J.Smith
deptとuserの順序が逆になっている点に注目してください。これは便利で重要なポイントです。GET/POST問合せデータ内で名前/値ペア間の順序を制御するのは通常、困難なためです。
問合せ文字列全体でのパターン
これは、問合せ文字列上における順序を要求する場合に使用できます。たとえば、次のようなパターンは、次の問合せ文字列に一致します。
user=*Smith*sales*
user=J.Smith&dept=sales
スキームにより、マスター・アクセス管理者は、ユーザーを認証し、リソースへのユーザーのアクセス権を検証する方法を定義できます。スキームとは、再利用可能なテンプレートです。スキームは、アクセス・システム・コンソールの「アクセス・システム構成」領域で作成します。
認証スキームは1つ以上のステップで構成され、各ステップには1つ以上のプラグインを含めることができます。ポリシー・ドメインには、少なくとも1つの認証ルール、したがって、少なくとも1つの認証スキームを設定することが必要です。
認可スキームは認可ルールに含めます。デフォルトの認可スキームを使用することも、カスタム認可スキームを提供することもできます。ポリシー・ドメインには、少なくとも1つの認可ルールを含んだ認可条件式を設定する必要があります。
スキームを定義すると、別のポリシー・ドメインの委任アクセス管理者が、各自のドメインのルール内で、または各自のドメイン内のポリシーのルール内で、このスキームを使用できるようになります。
自分と委任アクセス管理者がポリシー・ドメインとポリシーで必要とするスキームを、自分で一度にすべて定義できるのです。あるいは、必要に応じてスキームを定義することもできます。
プラグインとは、認証および認可プロセスを行うために実行される共有の動的ロード・ライブラリのことです。プラグインは、スキームに組み入れられ、ユーザーの認証やユーザーのリソースへのアクセス認可のために必要な情報をリクエストまたは処理します。
プラグインは特定のタスクを実行します。次に例を示します。
認証スキームの場合: 認証スキームには1つ以上のステップがあります。認証スキームの各ステップには、プラグインを組み入れます。アクセス・システム付属のデフォルトのプラグインを組み入れることも、カスタム・プラグインを組み入れることもできます。たとえば、すべての連鎖認証スキームには、ユーザーから取得した情報（ユーザー資格証明）をユーザー・プロファイル情報にマップするプラグインを組み入れる必要があります。
また、すべての認証スキームには、チャレンジ・メソッド・プラグインとパスワード検証プラグインを組み入れます。アクセス・システムには、このような目的のプラグインも用意されています。付属のプラグインをこの目的に使用しない場合は、同じ機能を備えたプラグインに置き換える必要があります。
付属のプラグインをカスタム・プラグインに置き換える場合は、プラグインの設計に、必須タスクの実行、必須パラメータの受入れと引渡し、定義済の機能コードの出力を含める必要があります。詳細は、「認証のプラグイン」を参照してください。
認可スキームの場合: 認可ルールでは、アクセス・システム付属のデフォルト認可スキームを使用することも、カスタム認可スキームを使用することもできます。カスタム認可スキームを使用する場合は、スキーム用に独自のプラグインを用意する必要があります。詳細は、「ユーザー認可の構成」を参照してください。
次のサポート対象プラットフォームのプラグインを作成できます。
カスタム・プラグインを作成する方法については、『Oracle Access Manager開発者ガイド』を参照してください。
ルールには、ポリシー・ドメインのリソースを保護する次のような方法を定義したスキームを含めます。
ユーザー認証をどのように実行するか。
ドメイン・リソースへのアクセス権およびアクセス権を限定する条件をユーザーが持っているかどうか。認可ルールは、認可条件式に含めます。ポリシー・ドメインには、認可条件式を1つのみ含める必要があります。
ポリシー・ドメインまたはポリシーに関する監査対象イベント。
認可条件式を作成するには、1つ以上の認可ルールを組み入れます。ルールには、ユーザー情報をルールの指定内容と照合して評価した結果に応じて実行するアクションを指定できます。
ポリシー・ドメインにはポリシーを組み入れ、ポリシーには独自のルールと認可条件式を追加できます。したがって、ポリシー・ドメインには次のように2つのレベルのルールを組み入れることができます。
デフォルトでポリシー・ドメインのすべてのリソースに適用されるルール。
ポリシーの構成要素であり、ドメイン内の特定のリソースに適用されるルール。ポリシーのこれらのルールは、それらが保護するリソースのポリシー・ドメインのデフォルト・ルールをオーバーライドします。
認可条件式には、認可ルールおよび、認可ルール同士を結合する演算子を含めます。式内でルールを結合することで、保護されたリソースへのアクセスを誰に許可または拒否するかを指定するための方法を、単純なものから複雑なものにいたるまで作成できます。
認可ルールは、ポリシー・ドメイン内で再利用可能です。同じルールを認可条件式内で複数回使用できます。また、同じルールをポリシー・ドメインの式内で、またポリシー・ドメインの任意のポリシーの式内で使用することもできます。
表4-3で、ポリシー・ドメインとポリシーのための、4つのタイプのルールを定義します。
| ルール | 説明 |
|---|---|
|
保護されたリソースへのアクセスをリクエストするユーザーに対する情報要求および認証に使用するメソッドを指定します。 認証が成功または失敗した場合に取るアクションを指定できます。 注意: ポリシー・ドメインに指定できるデフォルト認証ルールは1つのみです。ただし、各ポリシーには独自の認証ルールを設定できます。 |
|
|
ポリシー・ドメインまたはポリシー内のリクエストされたリソースへのユーザーのアクセスを許可または拒否します。 認証が成功または失敗した場合に取るアクションを指定できます。 認可ルールは認可条件式に含めます。 注意: 式に複数のルールがある場合、ルールの評価順序は、式の作成時に指定したロジックによって決まります。 アクセスの条件を指定することもできます。 注意: ポリシー・ドメインに指定できるデフォルト認可ルールは1つのみです。ただし、各ポリシーには独自の認可ルールを設定できます。 |
|
|
認可ルールを含めます。ポリシー・ドメインには、認可条件式を1つのみ設定する必要があります。 注意: ドメイン内の各ポリシーに設定できる認可条件式も、1つのみです。認可条件式をポリシーに設定しない場合、ポリシーのリソースは、ポリシー・ドメインの認可条件式によって保護されます。 |
|
|
ポリシー・ドメインに関連する特定のイベントに関する属性と情報を捕捉します。
|
|
注意: 認証ルールは認可ルールより先に適用されます。ユーザーがリソースへのアクセス権を付与される前に、自分の身元を証明する必要があるためです。 |
図4-3に示すのは、ポリシー・ドメインと、そのリソースに適用されるドメインのデフォルトのルール・セットとデフォルトの認可条件式です。ポリシーによって定義されたリソースの場合、デフォルトのルールと式はポリシーのルールと式によってオーバーライドされます。
ポリシー・ドメインのルールまたはポリシーでは明示的に保護されていないリソースへのアクセスは、アクセス・システムではデフォルトで許可されてしまいます。ポリシー・ドメインの作成は、この「すべてのリソースが保護されていない」という状態から開始することになります。逆に、最初から「すべてのリソースが保護される」ようにデフォルトの状態を裏返すという方針を取ることもできます。
すべてのリソースが保護されていない状態からポリシー・ドメインの作成を開始する場合は、リソースに対してアクセス制御を適用する必要があります。これは、多少の制限が付いているデフォルト・ルールを使用してポリシー・ドメインを作成することで、大まかに行うことができます。
ドメインのすべてのリソースを厳格に制御する、厳格なデフォルト・ルールを使用する場合、ポリシーを使用することで、リソースのサブグループに対する制限を削除または変更できます。
開始点として緩やかなデフォルト・ルールを使用する場合、ポリシーを使用してドメイン内のリソースのサブグループを厳密かつ限定的に制御できます。
すべてのリソースが保護されている状態から開始するには、パラメータ「保護されていない場合に拒否」を設定します。この「保護されていない場合に拒否」というスイッチをtrueに設定すると、ポリシー・ドメインのルールまたはポリシーで明示的に許可されていないすべてのリソースへのアクセスが拒否されます。
すべてのリソースが保護されている場合、ポリシー・ドメインとポリシーを作成する際に、様々なユーザーに利用させるリソースに対する保護を削除する必要があります。これは、一部のリソースを公開する、ということです。
これは、ポリシー・ドメインにデフォルト・ルールを適用することで、大まかに行うことができます。
ポリシー・ドメインのすべてのリソースに対する制御を緩和する、緩やかなデフォルト・ルールを使用する場合、ポリシーを使用することで、リソースのサブグループに対して特定の制限を適用できます。
開始点として厳格な方のデフォルト・ルール（おそらく、アクセスの完全拒否である現在のデフォルト状態ほど厳格でないルール）を使用する場合、ポリシーを使用することで、リソースのサブグループに対するアクセス制御を様々な方法で緩和できます。
|
注意: スイッチ「保護されていない場合に拒否」をfalseに設定すると、ポリシー・ドメインのルールまたはポリシーで明示的に拒否されていないすべてのリソースへのアクセスが許可されます。 |
「保護されていない場合に拒否」スイッチの使用方法の詳細は、第3章「WebGateおよびアクセス・サーバーの構成」を参照してください。
この項では、ポリシー・ドメインの作成、その有効化または無効化およびそのリソースの管理を行うための方法について説明します。次の一連のタスクを扱います。
マスター・アクセス管理者と委任アクセス管理者の両方がポリシー・ドメインを作成できます。マスター・アクセス管理者は、どのレベルのポリシー・ドメインでも作成できます。委任アクセス管理者は、管理するように委任されたポリシー・ドメインの下位にのみ、ポリシー・ドメインを作成できます。
ポリシー・マネージャを使用して、認証ルール、認可ルールおよび認可条件式により、ポリシー・ドメインの作成、ドメインへのリソースの追加、リソースの保護を行うことができます。
アクセス・システムのランディング・ページで、「ポリシー・マネージャ」リンクをクリックします。
アクセス・システム・コンソールで作業している場合は、ページの最上部にある「ポリシー・マネージャ」のリンクをクリックします。
「ポリシー・マネージャ」で、左側のナビゲーション・ペインにある「ポリシー・ドメインの作成」をクリックします。
「ポリシー・ドメインの作成」ページが表示されます（次の図を参照）。
一般: 名前とオプションの説明を入力します。
「名前」フィールドに、ドメインを指定する短い英数字の文字列を入力します。
このフィールドではスペースを使用できます。
「説明」フィールドで、このポリシー・ドメインの簡単な説明を入力します。
この「名前」と「説明」は、ポリシー・ドメインのリストを表示する各ページに表示されます。説明はオプションです。
「保存」をクリックします。
ポリシー・ドメインに関して現在定義済の情報を表示するには、「ページとして表示」をクリックします。
「一般」ページに戻るには、「ページとして表示」ページの左上の部分にあるドメインの名前をクリックします。
リソース: このポリシー・ドメインにリソースを追加する手順については、次を参照してください。
|
関連項目: このポリシー・ドメインに新しいリソース・タイプを追加する必要がある場合は、「リソース・タイプの定義」を参照してください。アクセス・システム・コンソールを使用してリソース・タイプを定義する必要があります。次に、ポリシー・マネージャに戻ってそれをポリシー・ドメインに追加します。 |
認可ルール: このタブから、後で認可条件式で使用するルールを追加および有効化できます。各ルールには、一般情報、タイミング条件、アクションおよびアクセス（「許可」または「拒否」）が含まれます。詳細は、「ルールと式の概要」を参照してください。
デフォルト・ルール: このタブから、このポリシー・ドメインの認証ルール、認可条件式および監査ルールを追加できます。
認証ルール: ポリシー・ドメインには、1つの認証スキームと認証アクションを指定する、少なくとも1つの認証ルールが必要です。詳細は、「認証ルールの管理」を参照してください。
認可条件式: 認可ルールおよび認可ルール同士を結合する演算子を含みます。詳細は、「認可条件式の概要」を参照してください。
監査ルール: マスター監査ルールが定義されていない場合は、アクセス・システム管理者にお問い合せください。
ポリシー: このタブから、ポリシー・ドメイン内のリソースを保護するポリシーを追加できます。
ポリシーを設定する前に、保護するURLに必要なアクセス制御のレベルを決定します。作成するポリシーごとに、特定の認証ルール、認可条件式および監査ルールを割り当てることができます。ルールを定義しない場合は、ポリシー・ドメインのデフォルト・ルールが有効になります。限定性を高めるURLパターンを使用して、ポリシーを作成できます。
委任アクセス管理: 「ポリシー・ドメイン管理の委任」
「ポリシー・ドメイン」の有効化: 新しいポリシー・ドメインを有効化する準備ができたら、「ポリシー・ドメインの有効化または無効化」を参照してください。
ポリシー・ドメインは作成後変更できます。ポリシー・ドメインの変更には、その任意の要素の変更、つまり、リソースの追加または削除、およびルールの変更、削除または追加が含まれます。
ポリシー・ドメインを変更する際は、必ず事前に無効にしてください。ポリシー・ドメインの有効化および無効化の詳細は、「ポリシー・ドメインの有効化または無効化」を参照してください。
「ポリシー・マネージャ」で、左側のナビゲーション・ペインにある「ポリシー・ドメイン」をクリックします。
「ポリシー・ドメイン」ページが表示され、ポリシー・ドメインのリストが示されます。
変更するポリシー・ドメインの名前の前のチェック・ボックスを選択し、ドメイン名をクリックします。
「一般」ページで、最下部にある「変更」をクリックします。
変更する値を変更した後、「保存」をクリックします。
ポリシー・ドメインは、最初にそのリソースやルールを削除しなくても、まとめて削除できます。ドメインを削除するには、その前に無効にします。詳細は、「ポリシー・ドメインの有効化または無効化」を参照してください。
「ポリシー・マネージャ」で、「ポリシー・ドメイン」を選択します。
「ポリシー・ドメイン」ページが表示され、ポリシー・ドメインのリストが示されます。
削除するポリシー・ドメインの名前の前のチェック・ボックスを選択します。
ページの最下部にある「削除」をクリックします。
ポリシー・ドメインを使用するには、その前に有効化する必要があります。また、ポリシー・ドメインの構成を変更するには、事前にポリシー・ドメインを無効化する必要があります。
アクセス・システムでは、/identityと/accessのURLを保護する、2つのデフォルト・ポリシー・ドメインを備えています。アクセス・システムが正常に動作するには、両デフォルト・ポリシー・ドメインを有効化する必要があります。無効化するのは、変更するデフォルト・ドメインのみにしてください。変更の終了後、再度有効化します。
|
重要: ドメインを無効にしてから、そのルールやポリシーを変更してください。 |
「ポリシー・マネージャ」で、「ポリシー・ドメイン」を選択します。
「ポリシー・ドメイン」ページで、有効化するドメインの隣にあるチェック・ボックスを選択します。
「有効化」をクリックします。
「有効化」列に「はい」が表示されます。
「ポリシー・マネージャ」で、「ポリシー・ドメイン」を選択します。
「ポリシー・ドメイン」ページで、無効化するドメインの隣にあるチェック・ボックスを選択します。
「無効化」をクリックします。
「有効化」列に「いいえ」が表示されます。
既存のポリシー・ドメインとポリシーを検索して表示できます。マスター・アクセス管理者は、すべてのポリシー・ドメインとポリシーを検索して参照できます。委任アクセス管理者が参照できるのは、管理権限を委任されたポリシー・ドメインのみです。委任されたポリシー・ドメインでは、マスター・アクセス管理者によって定義されたポリシーに沿って自分で定義したポリシーも参照できます。
ポリシー・ドメインとポリシーの検索には、「検索」機能を使用します。
「ポリシー・マネージャ」で、左側のナビゲーション・ペインにある「検索」をクリックします。
検索ウィンドウが表示されます。
ページの左上の「検索」リストから、ポリシー・ドメイン名またはポリシーを選択します。
中央の検索基準リストからエントリを選択して、左の列にテキスト文字列を入力します。
選択した検索基準に一致するエントリをすべて検索するには、右の列を空白のままにします。
「実行」をクリックします。
結果がページに表示されます。
ポリシー・ドメインのリストを表示して、各ドメインの構成済情報を表示できます。「ポリシー・ドメイン」ページには、管理権限のあるドメインのリストが表示されます。マスター・アクセス管理者は、すべてのポリシー・ドメインに関する情報を参照できます。委任アクセス管理者が参照できるのは、管理を委任されたポリシー・ドメインのみです。
「ポリシー・マネージャ」で、左側のナビゲーション・ペインにある「ポリシー・ドメイン」をクリックします。
ドメインのリンクをクリックして、ドメインの構成設定を表示します。
「一般」ページに、ポリシー・ドメインの名前、説明および有効か無効かが表示されます。他のタブをクリックした場合も、構成済の情報が表示されます。
アクセス・システムには、いくつかのデフォルト・リソース・タイプが定義されています。マスター・アクセス管理者は、この他にもリソース・タイプを定義できます。リソース・タイプの定義後は、マスター・アクセス管理者と委任アクセス管理者の両方が、管理対象のポリシー・ドメインにそのタイプのリソースを追加できます。委任アクセス管理者がドメインにリソースを追加できるのは、ポリシー・ドメインの管理権限を付与されてからです。
マスター・アクセス管理者は、「すべてのホスト識別子をリスト」ページ（アクセス・システム・コンソール→「アクセス・システム構成」→「ホスト識別子」リンク）でホスト識別子を定義します。詳細は、「ObPERM Cookie」を参照してください。
ポリシー・ドメインにリソースを追加する際に、そのリソースをホストするコンピュータのホスト識別子を選択します。マスター・アクセス管理者がコンピュータのホスト識別子を構成し終わった時点で、リソース（追加）ページの「ホスト識別子」と記載されているリストから適切なホスト識別子を選択できます。
「ホスト識別子」機能を使用すると、ホスト・コンテキストを作成できます。ホスト・コンテキストは、1つの名前、ホスト・コンテキスト名で識別される複数のホストで構成されます。マスター・アクセス管理者は、1つのホストを参照する様々な方法を1つのホスト識別子名に追加するのではなく、複数のホストの対応する情報を追加した、これらのホストのすべてが共有するコンテキストを作成できます。
ホスト・コンテキストは、複数のコンピュータ上に同じURLパスを持つポリシー・ドメイン・リソースを追加する場合に有益です。同じポリシー・ドメイン内のこのようなリソースを、すべて同じ方法で保護する必要がある場合です。この場合、あるリソース・セットを別のリソース・セットと識別する唯一の変数が、リソース・セットのホスト・コンピュータの識別子です。ホスト・コンテキストの使用は、すべてのホストのリソースを一度にポリシー・ドメインに追加できる効率的な方法です。「ホスト識別子」のリストから、ホスト・コンテキスト名を選択します。その他に入力する情報は、すべてのリソース・セットで同じなので、一度指定するのみで済みます。
ポリシー・ドメインの作成後、「リソース」タブ・ページを使用してドメインにリソースを追加します。
「ポリシー・マネージャ」で、左側のナビゲーション・ペインにある「ポリシー・ドメイン」をクリックし、次に、そのポリシー・ドメインのリンクをクリックします。
「リソース」タブをクリックします。
このドメインにリソースが追加されている場合は、このページに表示されます。そうでない場合は、「リソースが定義されていません。」のメッセージが表示されます。
「追加」ボタンをクリックします。
「リソース」ページが表示されます（次の図を参照）。
「リソース・タイプ」フィールドで、エントリを選択します。
アクセス・システムには、2つのデフォルト・リソース・タイプ、HTTPとEJBがあります。これらの他にも、管理者がシステム・コンソールを使用して定義したリソース・タイプがあれば利用できます。
|
注意: HTTPでは、HTTPとHTTPSの両方のリソースに対応しています。 |
各サーバーでホスト識別子が作成された場合は、「ホスト識別子」フィールドが表示されます。「ホスト識別子」が定義されていない場合は、このページにはこのフィールドは表示されません。
「ホスト識別子」フィールドが表示された場合は、リソースに対するホスト識別子を選択します。
ホスト識別子により、アクセス・システムでは、異なるホストに存在している以外は同じである、リソースのURL接頭辞同士を識別できます。
新規のURLのベースとして、既存のURL接頭辞を選択します。
既存のリソースのURL接頭辞を参照できるのは、マスター・アクセス管理者である場合か、URL接頭辞を表示または管理する権限のある委任アクセス管理者である場合のみです。
オプションで個別のURL接頭辞の文字列を入力することもできます。
使用可能な書式でリソースのURL接頭辞を入力します。個別のリソースを追加するには、フィールドにそのリソースのURLの残りの部分を入力します。次に、例を示します。
ディレクトリ（/marketing/.../）
ワイルドカード付きのディレクトリ（subfolder/*.html）
特定のファイル（marketing/subfolder/marketing.html）
次に続くフィールドに、URL接頭辞に追加するリージョンの名前を入力します。
たとえば、前のステップで選択した接頭辞が/your_companyである場合は、このフィールドに/salesと入力します。
|
注意: 設定時にポリシーのルートとして「/」を指定した場合以外は、エントリの前に「/」を追加する必要があります。 |
後で同じ接頭辞を再利用できますが、必ず別のリージョンを追加してください。次に、例を示します。
/your_company/marketing
新たに定義したリージョンを保存すると、「URL接頭辞」フィールドに表示されます。
|
注意: アクセス・システムでは、デフォルトでURL接頭辞とリージョンを大/小文字区別なしで読み取ります。大/小文字を区別するように変更するには、アクセス管理者が、アクセス・システム・コンソール内の「共通情報の構成」/「リソース・タイプ定義」機能のリソース一致機能を使用します。この設定を変更した場合は、アクセス・サーバーおよびアクセス・ゲートを再起動する必要があります。 |
「説明」フィールドに、保護するリージョン（ポリシー・ドメインまたはポリシー）の説明を入力します。
このフィールドへの入力はオプションです。
「保存」をクリックします。
「リソース」ページが再表示され、新規リソース名が示されます。
「OK」をクリックして変更を確定します。
このポリシー・ドメインにさらにリソースを追加するには、これらのステップを繰り返します。
マスター・アクセス管理者のみがリソースの説明を変更できます。
変更できるのはリソースの「説明」フィールドのみです。リソース自体を変更する場合は、削除して新たに作成する必要があります。
「ポリシー・マネージャ」で、「ポリシー・ドメイン」を選択します。
「ポリシー・ドメイン」ページで、ポリシー・ドメインのリンクをクリックします。
ポリシー・ドメインの「一般」ページが表示されます。
「リソース」タブをクリックします。
このポリシー・ドメインに含まれているリソース・タイプがリストされた「リソース」ページが表示されます。
リソースのリンクをクリックします。
次のページに、リソースのタイプと接頭辞が表示されます。
「変更」をクリックします。
新規のページが表示されます。
「説明」を希望どおりに変更します。
「保存」をクリックします。
マスター・アクセス管理者のみがリソースを削除できます。
「ポリシー・マネージャ」で、「ポリシー・ドメイン」を選択し、ポリシー・ドメインのリンクを選択します。
「一般」ページに、ドメインの「名前」、「説明」および「有効」ステータスが表示されます。
「リソース」をクリックします。
「リソース」ページが表示されます。
削除するリソースのチェック・ボックスを選択して、「削除」をクリックします。
決定の確認を求めるメッセージが表示されます。
「キャッシュの更新」チェック・ボックスを選択または選択を解除します。
接頭辞を削除する場合は、「OK」をクリックします。または、保存しないでページを終了する場合は、「取消」をクリックします。
アクセス・システムにより、保護対象リソースに対するユーザー・アクティビティを捕捉および記録できます。これには、ユーザーID情報および様々な認証および認可アクティビティに関する情報が含まれます。監査情報を使用して、特定のポリシー・ドメインのアクティビティを監視できます。
アクセス・システムにはマスター監査ルールが用意されていますが、これはマスター・アクセス管理者が構成できます。委任アクセス管理者は、マスター監査ルールを使用して、ポリシー・ドメインとポリシーに対して独自の監査ルールを作成できます。マスター管理者またはマスター・アクセス管理者がマスター監査ルールを作成するまでは、アクセス・システムでは監査情報が監査ログ・ファイルに記録されません。
マスター監査ルールには、次の情報を指定します。
監査するユーザーID属性（cn、uidなど）
監査するイベント（認証の成功や失敗など）
日付書式の選択
監査ログの形式とイベント・マッピング
マスター管理者とマスター・アクセス管理者は、アクセス・システム・コンソールを使用して、「マスター監査ルールの追加」ページでマスター監査ルールを構成します。
この項の残りの内容は次のとおりです。
|
注意: 大部分のパラメータを変更不能にすると、共通の監査パラメータがすべてのアクセス・サーバーに適用されます。 |
次の手順では、サーバーに対するマスター監査ルールの構成について説明します。マスター・アクセス管理者がこのルールを構成します。
アクセス・システム・コンソールで、「アクセス・システム構成」タブをクリックし、左側のナビゲーション・ペインにある「共通情報の構成」リンクをクリックします。
「マスター監査ルール」サブタブをクリックします。
「マスター監査ルールが見つかりませんでした」ページの「追加」ボタンをクリックして、マスター監査ルールを作成します。
「マスター監査ルールの追加」ページが表示されます（次の図を参照）。
「プロファイル属性」フィールドで、捕捉するIDプロファイル属性を入力します。
この属性は、そのイベントが発生するとログ・ファイルに書き込まれます。通常は、cnを選択するのが最善です。
プラス（+）またはマイナス（-）のアイコンをクリックして、属性フィールドを追加または削除します。
マスター・アクセス管理者は、このフィールドに属性を追加することはできますが、選択した属性の削除はできません。
「監査イベント」フィールドで、捕捉するイベントを選択します。
イベントは、マスター・アクセス管理者と委任アクセス管理者がポリシー・ドメインの構成時に追加または削除できます。
「監査イベント・マッピング」フィールドで、イベントのたびに記録する文字列を入力します。
たとえば、認証成功にはAUTHENT_SUCCESSをマップします。
「監査エスケープ文字」フィールドで、フィールドを区切る文字を入力し、記録された情報がレポートに正確に表示されるようにします。
エスケープ文字を指定しなかった場合、監査レコードはエスケープされません。
「監査レコード・フォーマット」フィールドで、認証および認可アクティビティに関連するデータ型を入力します。
|
注意: ファイルへの出力でサポートされるデータ型については、後続のリストを参照してください。データベースへの出力が必要な場合があります（audit-2-dbを使用する場合など）。その場合は、監査出力のフォーマット文字列を変更する必要があります（詳細は、『Oracle Access Manager IDおよび共通管理ガイド』の監査情報を参照）。 |
ob_datetime: 日付および時刻に対応します。日付は、マスター監査ポリシーに指定された書式で記録されます。時刻はhh:mm:ssとして記録されます。時刻は常に、ホストがリクエストを受信したGMT時刻、およびGMTからのホストの時差で構成されます。
ob_event: 発生したイベントに対応する文字列。このイベントとは、認証成功、認証失敗、認可成功、認可失敗のいずれかです。
ob_userid: ユーザーの識別名が含まれます（ユーザーが正常に認証された場合）。
ユーザーが認証されてディレクトリに識別名以外のエントリを持つ場合、アクセス・サーバーの認証モジュールが監査するように構成されている追加の情報がログに含まれます。そのディレクトリにこのユーザーが存在しない場合は、監査される唯一の情報はそのユーザー名です。ユーザーがディレクトリに存在していても不適切なパスワードを入力した場合、ユーザーのIDは確認できません。そのため、この情報は監査されません。パスワードは、匿名でログインしないユーザーの場合、監査ログには書き込まれません。
ob_wgid: リクエストを受信したアクセス・ゲートのID。
ob_time: ホスト上でイベントが発生したGMT時刻に対応します。時刻は常に、hh:mm:ss+/-<GMTからのホストの時差>として記録されます。
ob_time_no_offset: アクセス・ゲートのGMT時刻に対応しますが、GMTとの時差は記録されません。時刻はhh:mm:ssとして記録されます。マスター・アクセス管理者と委任アクセス管理者は、この設定を変更できません。
ob_reason: 認証成功、認証失敗、認可成功、認可失敗の各イベントの情報を戻します。全般的な理由は、ALLOW（成功の場合）またはDENY（失敗の場合）です。ただし、DENYの場合、次のいずれかの理由（マイナー・ステータス・コードで提示）がアクセス拒否の原因となることがあります。また、イベントが認証成功または認可成功のときは、理由がないことを示すコードが表示されます。
これらの理由は、拒否の原因を明確にするために戻され、次の整数で表されます。
40: 認証プロセスへの入力として無効なパスワードが提示されました。
68: 認可条件式の評価の全体的結果が未確定でした。
2: 理由の提示なし。このコードは、認証成功または認可成功イベントで戻されます。
アクセス・サーバーのキャッシュをいつ更新するかを設定します。
即時: 「キャッシュの更新」を選択すると、アクセス・サーバーのすべてのキャッシュがこの監査情報を使用して即時に更新されます。
後で: 「キャッシュの更新」を選択しなかった場合、アクセス・サーバーのキャッシュは、タイムアウトになってディレクトリ・サーバーから新しい監査情報を読み取ったときに更新されます。
変更を実施する場合は、「保存」をクリックします。または、保存しないでこのページを終了する場合は、「取消」をクリックします。
マスター管理者とマスター・アクセス管理者は、アクセス・システム・コンソールを使用して、マスター監査ルールを変更します。「マスター監査ルール」の構成を変更するには、「マスター監査ルールの変更」ページを使用します。
アクセス・システム・コンソールで、「アクセス・システム構成」タブをクリックし、左側のナビゲーション・ペインにある「共通情報の構成」リンクをクリックします。
「マスター監査ルール」タブをクリックします。
「マスター監査ルール」ページの「変更」ボタンをクリックします。
「マスター監査ルールの変更」ページが表示されます。
必要なパラメータ変更を行います。
「保存」をクリックします。
ポリシーにより、ドメイン内のリソースのサブセットを保護する方法を調整できます。ポリシーを使用して、ポリシー・ドメインのリソースのサブグループに対し、より厳格またはより緩やかな保護を設定できます。
ポリシーには次のものを指定できます。
1つ以上のリソース
リソース・タイプに対して許可する操作（リクエスト・メソッド）
特定ファイル、ディレクトリ、問合せ文字列パターンまたは問合せ文字列変数のURLパターン
詳細は、「URL接頭辞の概要」を参照してください。
リソースがポリシーの保護対象になっていない場合は、ドメインのデフォルト・ルールが適用されます。
次のポリシー・ドメインの例には、2つのポリシーが含まれています。Boggle Games社では、正社員、パートタイム従業員、契約社員の3つの人員カテゴリに対して人事管理情報を提供します。ポリシー・ドメインには1つのURL/mycompany/HRが含まれます。ポリシーのその他の詳細は次のとおりです。
この会社には、すべてのユーザー・グループに公開している情報があります。すべてのユーザーは、ビルへの入館証をどこでどのように入手するかを知っています。
入館証情報のリソースは、下位にある入館証ディレクトリ/mycompany/HR/badgesにあります。
ただし、入館証ディレクトリのリソースはポリシーで保護されていないため、ポリシー・ドメインのデフォルト・ルールの保護を受けます。
この会社には、正社員にのみ公開している情報があります。すなわち、正社員は休日、休暇および株利益に関する情報を参照できます。
ポリシーを使用して従業員の福利厚生のリソースを保護します。これは/mycompany/HRの下位の各ディレクトリにあります。
この会社には、マネージャにのみ公開している情報があります。すなわち、マネージャは、Boggle Games社に契約社員を提供している日頃からの取引先業者のリストを参照できます。
この項の残りの内容は次のとおりです。
複数のポリシーが重複するパターンを持っている場合、ポリシー・ドメイン内でのポリシーの順序が重要になります。この場合、ポリシーは、指定されている詳細が多い方から少ない方へと並べる必要があります。
ポリシーをポリシー・ドメインのリソースに追加するには、「ポリシー」タブ・ページを使用します。この項は、次の2つの必須タスクを実行済であることを前提としています。
「ポリシー・ドメインを作成する手順」に従って、ポリシー・ドメインを作成
Added a resource to the policy domain, as explained in 「ポリシー・ドメインにリソースを追加する手順」に従って、ポリシー・ドメインにリソースを追加
|
注意: 一部のディレクトリ・サーバーでは、大量のポリシーとリソースを追加することでサイズ制限のエラーが発生することがあります。開発時の条件では、何千ものリソースがポリシーに追加されて初めてこの最大値に到達しました。 |
URLパターンを追加する前に、「リソースのURLの構成」を参照してください。
「ポリシー・マネージャ」で、左側のナビゲーション・ペインにある「ポリシー・ドメイン」をクリックします。
ポリシーを追加するポリシー・ドメインをクリックします。
「ポリシー」サブタブを選択して「追加」をクリックします。
ポリシー構成ページが表示されます。
ポリシーの一般情報を入力し、「保存」をクリックします。
ポリシーの名前をクリックし、このポリシーのサブタブを表示します。
認証ルール: このサブタブをクリックし、「追加」（または「デフォルトの表示」）をクリックします。このポリシーの認証ルールを作成（または編集）します。このルールのガイドラインは、ポリシー・ドメインのガイドランと同じです。
認可条件式: このサブタブをクリックし、「追加」（または「デフォルトの表示」）をクリックします。このポリシーの認可条件式を作成（または編集）します。この式のガイドラインは、ポリシー・ドメインのガイドランと同じです。
監査ルール: このサブタブをクリックします。定義済のマスター監査ルールがなく、このポリシーに監査ルールを追加する場合は、アクセス・システム管理者にお問い合せください。
ポリシーの変更には、「ポリシー」ページを使用します。
「ポリシー・マネージャ」で、左側のナビゲーション・ペインにある「ポリシー・ドメイン」をクリックします。
変更するポリシーがあるポリシー・ドメインのリンクをクリックします。
「ポリシー」タブを選択し、ポリシーを選択して、「変更」をクリックします。
「ポリシー」タブの「変更」ページで、ポリシー情報を変更します。
「保存」をクリックします。
複数のポリシーを作成した場合、アクセス・サーバーでチェックする順序を指定できます。デフォルトでは、新規のポリシーが最後にチェックされます。
「ポリシー・マネージャ」で、「ポリシー・ドメイン」を選択し、当該のポリシー・ドメインのリンクをクリックします。
「ポリシー」タブを選択します。
「順序」をクリックします。
現在の順序内を移動させるポリシーの名前を選択します。
「上へ」および「下へ」の矢印をクリックして、ポリシーを再配置します。
順序を変更するポリシーごとに、このプロセスを繰り返します。
アクセス・サーバーのキャッシュをいつ更新するかを設定します。
即時: 「キャッシュの更新」を選択すると、アクセス・サーバーのすべてのキャッシュがこの監査情報を使用して即時に更新されます。
後で: 「キャッシュの更新」を選択しなかった場合、アクセス・サーバーのキャッシュは、タイムアウトになってディレクトリ・サーバーから新しい監査情報を読み取ったときに更新されます。
ポリシーのリストの順序が納得できたら、「保存」をクリックします。
ポリシーは、所属するポリシー・ドメインのポリシーのリストから直接削除します。
「ポリシー・マネージャ」タブで、「ポリシー・ドメイン」を選択し、特定のポリシー・ドメインのリンクを選択して、「ポリシー」タブを選択します。
削除するポリシーの名前の前のチェック・ボックスを選択します。
「削除」をクリックします。
管理するポリシー・ドメインをテストして、リソース保護が計画したとおりに機能していることを確認したら、ドメインを本番用にデプロイできます。ポリシー・ドメインをデプロイするには、有効化します。
なお、ポリシー・ドメインの有効化はテスト時にも必要です。ポリシー・ドメインをテストする方法については、「アクセス・テスターの使用方法」を参照してください。
監査とは、ポリシー・ドメインまたはそのポリシーのリソースに関連するユーザー・アクティビティについての情報を収集するプロセスです。アクセス・システムでは、キャッシュからの情報のクリアなど、管理イベントを自動的に監査します。何を追跡するかは、「マスター監査ルール」に設定する監査ポリシーとそのルールから導出する監査ルールによって決定します。
次のものに対する監査ポリシーを構成できます。
監査出力をカスタマイズしてユーザー・プロファイル属性を含めることができます。レポートや履歴、あるいは適切であると判断した目的に対して監査証跡を使用できます。たとえば、ユーザー・プロファイルのcnやその他の属性を収集して、ポリシー・ドメインの使用状況に関する詳細情報を管理できます。この情報は、検索することも、レポートの生成に使用することもできます。
この項の残りの内容は次のとおりです。
ポリシー・ドメインの監査ルールを作成できます。ポリシー・ドメインの監査ルールは、ドメインのいずれかのポリシーに監査ルールが定義されている場合を除いて、ドメインのすべてのリソースのデフォルト・ルールとして機能します。
このルールは、マスター・アクセス管理者によって作成されたマスター監査ルールから導出する必要があります。マスター監査ルールの作成の詳細は、「マスター監査ルールの概要」を参照してください。
アクセス・システム・コンソールで、「ポリシー・マネージャ」→「ポリシー・ドメイン」の順に選択し、特定のポリシー・ドメインのリンクを選択します。
「一般」タブが選択された状態で、選択したポリシー・ドメインが表示されます。
「デフォルト・ルール」タブをクリックします。
「デフォルト・ルール」タブを選択すると、「認証ルール」、「認可条件式」および「監査ルール」の各サブタブが表示されます。
「監査ルール」サブタブをクリックします。
ポリシー・ドメインの定義済監査ルールを示すページか、定義済ルールがないことを報告するページが表示されます。マスター監査ルールが定義されていないことを示すページが表示された場合は、マスター・アクセス管理者は、ユーザーがポリシー・ドメインの監査ルールを定義できるよう、マスター監査ルールを作成する必要があります。
「追加」をクリックして、監査ルールの作成を開始します。
「監査ルール」ページが表示されます。マスター監査ルールが存在する場合は、その値がデフォルトとして表示されます。
監査するイベントと、監査プロファイル属性を選択します。
「保存」をクリックします。
ポリシー・ドメインの既存の監査ルールを変更できます。このルールはマスター監査ルールから導出されたものです。
アクセス・システム・コンソールで、「ポリシー・マネージャ」→「ポリシー・ドメイン」の順に選択し、特定のポリシー・ドメインのリンクを選択します。
選択したポリシー・ドメインの「一般」ページが表示されます。
「デフォルト・ルール」→「監査ルール」の順に選択します。
「一般」ページが表示されます。
「デフォルト・ルール」→「監査ルール」タブの順にクリックします。
「監査ルール」ページが表示されます。
変更する監査ルールを選択します。
ルールの情報が含まれるページが表示されます。
「変更」をクリックします。
編集可能なテキスト・フィールドのあるルールのページが表示されます。
情報を変更して「保存」をクリックします。
ポリシーの監査ルールを定義すると、ポリシー・ドメインに対して定義されているデフォルトの監査ルールがオーバーライドされます。ポリシーの監査ルールを定義するには、事前にマスター・アクセス管理者によってマスター監査ルールが作成されている必要があります。
アクセス・システム・コンソールで、「ポリシー・マネージャ」→「ポリシー・ドメイン」の順に選択し、特定のポリシー・ドメインのリンクを選択します。
選択したポリシー・ドメインの「一般」ページが表示されます。
「ポリシー」タブをクリックします。
監査ルールを作成するポリシーを選択します。
「監査ルール」をクリックします。
ポリシー・ドメインの定義済監査ルールを示すページか、定義済ルールがないことを報告するページが表示されます。マスター監査ルールがないことを示すページが表示された場合は、マスター・アクセス管理者は、ユーザーがポリシーの監査ルールを定義できるよう、マスター監査ルールを作成する必要があります。
「追加」をクリックして監査ルールの定義を開始します。
「監査ルール」ページが表示されます。マスター監査ルールが存在する場合は、その値がデフォルトとして表示されます。
監査するイベントと、監査プロファイル属性を選択します。
「保存」をクリックします。
ポリシー・ドメインのポリシーの監査ルールを変更できます。このルールは、マスター・アクセス管理者によって作成されたマスター監査ルールから導出されたものです。
アクセス・システム・コンソールで、「ポリシー・マネージャ」→「ポリシー・ドメイン」の順に選択し、特定のポリシー・ドメインのリンクを選択します。
選択したポリシー・ドメインの「一般」ページが表示されます。
「ポリシー」タブをクリックします。
監査ルールを作成するポリシーを選択します。
「監査ルール」をクリックします。
「監査ルール」ページが表示されます。
監査ルールの1つを選択します。
ルールの情報が含まれるページが表示されます。
「変更」をクリックします。
編集可能なテキスト・フィールドにルールの情報が含まれたページが表示されます。
情報を変更して「保存」をクリックします。
監査ルールにより、イベント・ベースのデータが監査ログ・ファイルに書き込まれます。アクセス・サーバーごとに1つの監査ログ・ファイルがあります。各サーバーに対して監査ログ・ファイルのサイズとローテーション間隔を構成できます。記録するイベントによっては、監査ログ・ファイルに重複する監査エントリが含まれることがあります。
|
注意: audit-2-dbなどの使用によって監査をデータベースに出力する場合、監査出力の書式を設定する文字列を置換する必要があります（ 『Oracle Access Manager IDおよび共通管理ガイド』を参照）。また、アクセス・システムに、サポートされているデータベースをインストールし、特定の構成を行っておく必要があります。 |
アクセス・テスターを使用して、ポリシー・ドメイン用に作成した認証ルール、認可ルールおよび認可条件式が期待した結果を生成していることを検証します。ポリシー・ドメインは、本番用に提供する前にテストする必要があります。ルールの様々なパラメータを選択し、その結果を期待内容と比較した後、必要に応じてルールを調整します。
カスタム認可またはカスタム認証のプラグインを構成している場合にアクセス・テスターを使用するには、まず特定のファイルを使用可能にする必要があります。次の手順では、アクセス・テスターの使用について説明します。カスタム認証またはカスタム認可のプラグインを使用しない場合は、手順1をスキップしてかまいません。
カスタム認証またはカスタム認可のプラグイン: 次のアイテムをWebサーバーの/binディレクトリにコピーします。
たとえば、WebサーバーがOracle HTTP Serverであれば、次のファイルを$ORACLE_HOME/binにコピーします。
カスタム・プラグインのdll
カスタム・プラグインのコンパイルに使用したmanaged_plugin_interface.dll
次のディレクトリ・パスにあるmanaged_plugin_impl.dll
PolicyManager_install_dir/webcomponent/access/oblix/apps/common/bin
「ポリシー・マネージャ」で、左側のナビゲーション・ペインにある「アクセス・テスター」をクリックします。
「アクセス・テスター」ページの「URL」フィールドで、チェックするアプリケーションまたはコンテンツのフルパスを入力します。
パス（http://またはhttps://接頭辞を追加したもの）は、ブラウザに入力したときに、ランディング・ページを起動するものである必要があります。
「リソース・タイプ」フィールドで、リストからエントリを選択します。
アクセス・システム・コンソールで定義されているタイプのみを選択できます。
「リソース操作」フィールドで、このURLに対してテストするリクエスト・メソッドを選択します。
|
注意: このフィールドで選択できる操作は、前のステップで選択したリソース・タイプによって異なります。 |
いずれも選択しなかった場合は、すべてがテストされます。
特定のコンピュータがリソース（URL）にアクセスできるかどうか調べるには、「開始IPアドレス」フィールドにそのコンピュータのIPアドレスを入力します。
IPアドレス全体を入力する必要があります。このフィールドではワイルドカードを使用できないためです。
「アクセスの日付/時間」リストで、次のいずれかの操作を行います。
「任意」の横のボタンをクリックして、時間制限なしでこのリソースをテストします。
「特定の日時」の横のボタンをクリックして、表示される「日付」および「時間」フィールドに入力します。
「次のユーザーのアクセス権をチェック」フィールドで、次のいずれかの操作を行います。
「すべてのユーザー」の横のボタンをクリックします。
「すべてのユーザー」を選択したことで、「アクセス・テスター」ではすべてのユーザーの認証および認可情報が処理されます。データベースに非常に多くのユーザー・エントリがある場合、この処理にはかなりの時間がかかります。
「選択されたユーザー」の横のボタンをクリックし、次に「ユーザーの選択」ボタンをクリックして、部門ページを表示します。このページで特定のユーザーを選択できます。
|
注意: グループは選択しないでください。「アクセス・テスター」がテストできるのは個々のユーザーのみで、グループはテストできません。また、グループを個人レベルに分解することもありません。 |
「管理者の表示」フィールドで、一度に表示するエンドユーザーの数を選択します。
リストから、必要なユーザー・アクセス権が表示された、オプションの横のボタンを選択します。
許可されたユーザーのみ表示
拒否されたユーザーのみ表示
両方を表示
「ポリシー」と「ルール」のオプションもリストされます。
一致ポリシーの表示: このリソース（URL）をポリシーによって保護し、そのポリシーを表示する場合は、「一致ポリシーの表示」の横のボタンを選択します。
一致ルールの表示: このリソース（URL）の認可ルールを表示する場合は、「一致ルールの表示」の横のボタンを選択します。
「送信」をクリックします。
結果が表示されます。
マスター・アクセス管理者はポリシー・ドメインを作成した場合、デフォルトの委任アクセス管理者としてのロールを担います。このデフォルトの委任アクセス管理者には、ドメインにおけるすべての管理権限があり、そのドメインの管理を次に委任アクセス管理者になるユーザーに委任できます。
委任アクセス管理者には、次の3つのレベルの権限があります。
委任: 付与権限または基本権限を他のユーザーに委任します。
付与: 基本権限を他のユーザーに委任します。
基本: 委任されたタスクを実行しますが、この権限を他のユーザーに委任できません。
特定ドメインに対する権限を持つ委任アクセス管理者（またはマスター・アクセス管理者）のみが、ポリシー・ドメインを表示できます。
委任アクセス管理者は、委任されたポリシー・ドメインを管理できます。また、委任されたポリシー・ドメインのURL接頭辞に含まれるリソースに対して、ポリシー・ドメインを作成することもできます。
表4-4に、各種の管理者の権限を示します。
| 管理者のタイプ | ポリシー・ドメインの権限 |
|---|---|
|
マスター管理者 |
|
|
マスター・アクセス管理者 |
|
|
委任された権限を持つ委任アクセス管理者 |
委任された権限を持つ委任アクセス管理者は、委任されたポリシー・ドメインについてのみ、次の操作ができます。
重要: 委任アクセス管理者は、マスター監査ルールの属性を再定義することはできません。 |
|
付与権限を持つ委任アクセス管理者 |
マスター・アクセス管理者または委任権限を持つ委任アクセス管理者によって作成されます。 付与権限を持つ委任アクセス管理者は、委任されたポリシー・ドメインについてのみ、次の操作ができます。
|
|
基本権限を持つ委任アクセス管理者 |
マスター・アクセス管理者あるいは委任または付与権限を持つ委任アクセス管理者によって作成されます。 基本権限を持つ委任アクセス管理者は、ポリシー・ドメインを作成または削除できません。指定されたポリシー・ドメインに対して、この管理者は次の操作ができます。
|
マスター・アクセス管理者と委任アクセス管理者の両方がポリシー・ドメインを管理できます。マスター・アクセス管理者の作成の詳細は、「アクセス管理者の構成」を参照してください。ポリシー・ドメインの委任アクセス管理者の作成および表示手順、ならびに委任権限の変更手順は、以降の段落を参照してください。
「ポリシー・マネージャ」で、「ポリシー・ドメイン」を選択し、ポリシー・ドメインをクリックします。
「委任アクセス管理」タブを選択します。
「委任アクセス管理」ページの「管理者の表示」フィールドで、「権限の委任」、「権限の付与」または「基本権限」ラジオ・ボタンを選択します。
ページがリフレッシュされ、このポリシー・ドメインの選択された管理権限を持つ現在のユーザーとグループが表示されます。この権限を持つユーザーがいない場合は、「この権限のある委任アクセス管理は使用できません。」のメッセージが表示されます。
管理者のリンクをクリックして、ユーザーまたはグループのプロファイルを表示します。
「ポリシー・マネージャ」で、「ポリシー・ドメイン」を選択し、ポリシー・ドメインをクリックします。
「委任アクセス管理」を選択します。
付与する権限の種類のラジオ・ボタンをクリックします。
「委任アクセス管理」ページの最下部の「変更」ボタンをクリックします。
「ユーザーの選択」をクリックします。
「検索」プロセスを使用して選択対象のユーザー・リストを表示し、「完了」をクリックします。
「保存」をクリックします。
「ポリシー・マネージャ」で、「ポリシー・ドメイン」を選択します。
ポリシー・ドメインをクリックします。
「委任アクセス管理」タブを選択します。
「変更」をクリックします。
変更する権限のフィールド値を変更します。
「保存」をクリックします。
