1. Oracle Internet Directoryの管理
  2. 拡張管理: セキュリティ
  3. ディレクトリ・アクセス制御の管理

31 ディレクトリ・アクセス制御の管理

この章では、Oracle Internet Directoryのアクセス制御ポリシーの概要について説明し、アクセス制御リスト(ACL)、アクセス制御項目(ACI)およびアクセス制御ポリシー・ポイント(ACP)の使用方法について説明します。具体的には、Oracle Directory Services Manager (ODSM)またはldapmodifyコマンド行ユーティリティを使用して、ディレクトリ・アクセス制御を管理する方法について説明します。

この章の内容は次のとおりです。

31.1 ディレクトリ・アクセス制御の概要

認可とは、オブジェクトまたはオブジェクトのセットへのアクセスのためにユーザー、プログラムまたはプロセスに与えられる権限です。

ディレクトリ・セッション中にディレクトリ操作が試行されると、ディレクトリ・サーバーによって、ユーザーにこれらの操作を実行するための権限があるかどうかが確認されます。ユーザーに権限がない場合、ディレクトリ・サーバーはこれらの操作を許可しません。ディレクトリ・サーバーはアクセス制御情報を使用して、ディレクトリ・ユーザーによる不正操作からディレクトリ・データを保護します。アクセス制御情報およびディレクトリ・アクセス制御機能について、次の各項で説明します

31.1.1 アクセス制御情報について

アクセス制御情報は、アクセス制御に関連する管理ポリシーを記録したディレクトリ・メタデータです。

アクセス制御情報は、ユーザーによる変更が可能な構成属性としてOracle Internet Directoryに格納され、アクセス制御項目(ACI)と呼ばれます。

通常、アクセス制御リスト(ACL)と呼ばれるこのACI属性値のリストは、ディレクトリ・オブジェクトと関連付けられています。このリストの属性値は、様々なディレクトリ・ユーザー・エンティティ(またはサブジェクト)が所定のオブジェクトに対して持っている権限を表します。

ACIは次のコンポーネントで構成されています。

  • アクセス権限を付与するオブジェクト

  • アクセス権限を付与するエンティティ(サブジェクト)

  • 付与するアクセス権限の種類

アクセス制御ポリシーは規定的です。つまり、そのセキュリティ・ディレクティブは、ディレクトリ情報ツリー(DIT)内のすべての下位エントリに適用されるように設定できます。アクセス制御ポリシーが適用される開始点は、アクセス制御ポリシー・ポイント(ACP)と呼ばれます。

ACIは、ディレクトリ内にテキスト文字列として記述され、格納されています。この文字列は、ACIディレクティブ書式と呼ばれる、明確に定義された書式に従う必要があります。ACI属性の各有効値は、個別のアクセス制御ポリシーを表します。

31.1.2 アクセス制御機能の概要

ホスティングされた環境で実行されているアプリケーションでは、ディレクトリ・アクセス制御の次の機能が使用できます。

  • 規定のアクセス制御

    サービス・プロバイダは、ディレクトリ・オブジェクトの集合に対してアクセス制御リスト(ACL)を指定できます。個々のオブジェクトごとにポリシーを設定する必要はありませんこの機能によって、アクセス制御の管理が簡素化されます。特に同じポリシーまたは同等のポリシーで管理されるオブジェクトが多数含まれる大きなディレクトリで有効です。

  • 階層的なアクセス制御管理のモデル

    サービス・プロバイダは、ホスティングされた企業にディレクトリ管理を委任できます。必要に応じて、レルムからさらに委任することもできます。

  • 委任ドメインに対する管理無効制御

    サービス・プロバイダは、アカウントの意図しないロックアウトやセキュリティの不慮の露見に対する診断とリカバリを実行できます。

  • アクセス制御エンティティの動的評価

    サブツリーの管理者は、サブジェクトとオブジェクトの双方を、そのネームスペースおよびディレクトリのその他のオブジェクトとの関連の点で識別できます。たとえば、あるレルムの管理者は、ユーザーの上司のみに、そのユーザーの給与属性の更新を認めることができます。他のレルムの管理者は、給与属性に関して、これと異なるポリシーを確立して適用できます。

アクセス制御ポリシーは、対応するエントリ内のACI属性の値を構成して管理します。そのためには、Oracle Directory Services Managerまたはldapmodifyのいずれかを使用します。

31.1.3 アクセス制御管理の構造体について

この項では、Oracle Internet Directoryでアクセス制御に使用される構造について説明します。

この項では、Oracle Internet Directoryでアクセス制御に使用される構造について説明します。

31.1.3.1 アクセス制御ポリシー・ポイント(ACP)について

ACPは、orclACI属性に値が指定されたエントリです。orclACI属性の値は、エントリのサブツリーによって継承されるアクセス・ポリシーを示します。エントリのサブツリーは、そのサブツリーのルートとなるACPから始まります。ディレクトリ・サブツリー内に複数のACPの階層が存在する場合、そのサブツリー内の従属エントリは、すべての上位ACPからアクセス・ポリシーを継承します。継承結果のポリシーは、そのエントリより上位のACP階層内のポリシーを集約したものです。

たとえば、HR部門のエントリにACPが設定されており、HR部門内に、Benefits、PayrollおよびInsuranceグループのエントリがある場合、この3つのグループ内のエントリはいずれも、HR部門のエントリに指定されたアクセス権を継承します。

ACPの階層内に競合するポリシーがある場合、ディレクトリは、集約したポリシーの評価には明確に定義された優先順位規則を適用します。

関連項目:

ACLの評価。

31.1.3.2 規定のアクセス制御のためのorclACI属性について

orclACI属性には、規定のアクセス制御リスト(ACL)ディレクティブが含まれています。つまり、このディレクティブは、この属性が定義されているACPより下位のサブツリー内にあるすべてのエントリに適用されます。ディレクトリ内のあらゆるエントリに、この属性の値を含めることができます。この属性自体へのアクセスは、他の属性に対するアクセスと同様に制御されます。

ノート:

単一のエントリ固有のACLディレクティブをorclACI属性で示すことができます。ただし、その場合には、「エントリ・レベルのアクセス制御のためのorclEntryLevelACI属性について」で説明する、管理が容易でパフォーマンス上のメリットもあるorclEntryLevelACIの使用をお薦めします。これは、orclACIを介して示されるディレクティブの数によってLDAP構成のオーバーヘッドが増加するためです。エントリ固有のディレクティブをorclACIからorclEntryLevelACIに移動すると、このオーバーヘッドを削減できます。

31.1.3.3 エントリ・レベルのアクセス制御のためのorclEntryLevelACI属性について

あるポリシーが特定のエンティティ(たとえば、特別のユーザー)のみに関係するとき、そのエンティティのエントリ内でACLディレクティブをメンテナンスできます。これは、orclEntryLevelACIと呼ばれるユーザーが変更可能な構成属性を使用して実行できます。この属性には、関連付けられたエントリにのみ適用されるACLディレクティブが含まれます。

いずれのディレクトリ・エントリにも、この属性の値をオプションで設定できます。それは、Oracle Internet Directoryが抽象型オブジェクト・クラス topを拡張し、オプション属性としてorclEntryLevelACIを組み込むためです。

orclEntryLevelACI属性は複数値の属性で、構造はorclACIと類似しています。

関連項目:

orclEntryLevelACI属性の構造については、「オブジェクトに対するアクセス制御」を参照してください

31.1.3.4 セキュリティ・グループについて

Oracle Internet Directory内のグループ・エントリは、groupOfNamesオブジェクト・クラスまたはgroupOfUniqueNamesオブジェクト・クラスのいずれかと関連付けられます。グループ内のメンバーシップは、それぞれmember属性またはuniqueMember属性の値として指定されます。

個人またはエンティティのグループにアクセス権を指定するには、セキュリティ・グループでそのグループを識別します。セキュリティ・グループには、ACPグループと権限グループの2つのタイプがあります。

31.1.3.4.1 ACPグループについて

個人がACPグループのメンバーである場合、ディレクトリ・サーバーは、そのACPグループに関連付けられている権限をその個人に単純に付与します。

ACPグループを使用して、ACPのレベルでアクセス権を解決します。たとえば、エントリを参照できるアクセス権を数百ものユーザーに付与すると仮定します。参照権限を各エントリに個別に付与することもできますが、この作業には相当な管理オーバーヘッドが必要となります。さらに、後日その権限の変更が決定した場合は、各エントリを個々に修正する必要があります。より効率的な解決策は、権限を集合的に割り当てることです。そのためには、グループ・エントリを作成してACPグループとして指定し、必要な権限をそのグループに割り当てた後、ユーザーをそのグループのメンバーに割り当てます。その後、アクセス権を変更する場合は、個々のユーザーに対してではなく、グループに対して1箇所で変更を行います。同様に、権限を削除する場合は、多数の各エントリにアクセスするのではなく、グループから権限を削除することによって、複数のユーザーから権限を削除できます。

ACPグループは、orclacpgroupオブジェクト・クラスに関連付けられています。

31.1.3.4.2 権限グループについて

権限グループは、上位レベルのアクセス・グループです。同様の権限を持つユーザーをリストする点では、ACPグループと類似しています。ただし、単一のACPとは異なり追加チェックも提供しています。たとえば、あるACPによってアクセスが否認される場合、ディレクトリ・サーバーは、アクセスを否認されたユーザーがいずれかの権限グループに属しているかどうかをユーザー・エントリの属性によって判断します。その場合、このユーザーには上位管理レベルで別途の権限があるため、DITで上位管理レベルすべてがチェックされます。リクエストしたオブジェクトへのアクセス権を権限グループに付与する上位ACPが見つかった場合、ディレクトリ・サーバーは、従属ACPによる否認を無視してアクセス権をユーザーに付与します。ただし、従属ACPのorclACIまたはorclEntryLevelACI属性にキーワードDenyGroupOverrideが含まれている場合、上位レベルのACPは従属ACPを無視しません。DenyGroupOverrideを使用すると、権限グループを使用してスーパーユーザーのアクセスを制限できます。

通常は、ACPグループのみを実装します。権限グループが提供する追加チェックは、パフォーマンスを低下させる可能性があります。下位レベルの標準的な制御よりも上位レベルのアクセス制御を優先させる権限が必要な場合にのみ、権限グループを使用します。

権限グループを使用して、DITの下位ACPでは認識されない管理者に対して、アクセス権を付与します。たとえば、ホスティングされた環境のグローバル管理者が、レルムで操作を行う必要があると仮定します。グローバル管理者のアイデンティティはホスティングされた企業のレルムでは認識されないため、ディレクトリ・サーバーは、そのレルムのACPのみに依存している場合、必要なアクセスを拒否します。ただし、グローバル管理者が権限グループのメンバーである場合、ディレクトリ・サーバーは、DITの上位で、そのサブツリーへのアクセス権をこの権限グループに付与しているACPを検索します。アクセス権を付与しているACPが見つかった場合、ディレクトリ・サーバーは、ホスティングされた企業のレルムにあるACPによる制限を無視します。

DenyGroupOverrideキーワードをACIに追加すると、権限が付与されたグループのメンバーに対してアクセスを拒否できます。

権限グループは、orclPrivilegeGroupオブジェクト・クラスに関連付けられています。

31.1.3.4.3 両方のタイプのグループに属するユーザーについて

ユーザーがACPグループと権限グループの両方のメンバーである場合、ディレクトリ・サーバーは、各タイプのグループについて評価を行います。DITで上位のACPに注目して、権限グループのアクセス権を解決します。

31.1.3.4.4 セキュリティ・グループの制約について

orclacpgroupオブジェクト・クラスとorclPrivilegeGroupオブジェクト・クラスの両方を含むセキュリティ・グループは作成しないでください。

ネストされているセキュリティ・グループの親グループと子グループは、常に同じオブジェクト・クラス(orclacpgroupまたはorclPrivilegeGroup)である必要があります。

これらの制約のいずれかに違反すると、ACIの評価が決定的ではなくなる可能性があります。

31.1.3.4.5 グループへのアクセス権の付与

アクセス権をユーザーのグループに付与する手順は、次のとおりです。

  1. 通常の方法でグループ・エントリを作成します。
  2. グループ・エントリをorclPrivilegeGroupオブジェクト・クラスまたはorclACPgroupオブジェクト・クラスに関連付けます。
  3. そのグループのアクセス・ポリシーを指定します。
  4. メンバーをグループに割り当てます。
31.1.3.4.6 セキュリティ・グループ・メンバーシップについて

エントリは、グループの直接のメンバーとなるか、またはグループをネストして権限グループの一群を形成し、他のACPまたは権限グループの間接のメンバーとなることができます。与えられたレベルで指定されているアクセス・ポリシーは、そのレベル以下のすべてのメンバーに直接的または間接的に適用されます。

Oracle Internet Directoryは、セキュリティ・グループのみをアクセス制御目的で評価するため、その他のタイプのグループに対してアクセス・ポリシーを設定できません。ユーザーが特定の識別名とバインドされると、Oracle Internet Directoryは、セキュリティ・グループ内でそのユーザーの直接のメンバーシップを算出します。指定した識別名の第1レベルのグループを認識すると、Oracle Internet Directoryは、この第1レベルのグループすべての、他のセキュリティ・グループへのネストを算出します。この処理は、評価対象のネストされたグループがなくなるまで行われます。

各セキュリティ・グループ(ネストされているかどうかに関係なく)は、セキュリティ・グループのオブジェクト・クラス(orclACPgroupまたはorclPrivilegeGroup)に関連付けられている必要があります。グループがセキュリティ・グループのメンバーの場合でも、セキュリティ・グループのオブジェクト・クラスに関連付けられていないかぎり、ディレクトリ・サーバーではアクセス制御目的のグループとはみなされません。セキュリティ・グループ内でユーザーのメンバーシップが判断された場合、ディレクトリ・サーバーでは、セッションの存続期間にわたってその情報を使用します。

31.1.3.4.7 セキュリティ・グループ・メンバーシップの算出

たとえば、表31-1のエントリのサンプル・グループについて考えてみます。group4以外は、それぞれ権限グループ(objectclass:orclprivilegegroup)として指定されています。group1、group2およびgroup3のメンバーに適用されるアクセス制御ポリシーを設定できます。

表31-1 サンプル・セキュリティ・グループ

グループ エントリ

group 1

 
dn: cn=group1,c=us
cn: group1
objectclass: top
objectclass: groupofUniqueNames
objectclass: orclPrivilegeGroup
uniquemember: cn=mary smith,c=us
uniquemember: cn=bill smith,c=us
uniquemember: cn=john smith,c=us

group 2

 
dn: cn=group2,c=us
cn: group2
objectclass: top
objectclass: groupofUniqueNames
objectclass: orclPrivilegeGroup
uniquemember: cn=mary jones,c=us
uniquemember: cn=joe jones,c=us
uniquemember: cn=bill jones,c=us
uniquemember: cn=john smith,c=us

group 3

 
dn:cn=group3,c=us
cn: group3
objectclass: top
objectclass: groupofUniqueNames
objectclass: orclPrivilegeGroup
uniquemember: cn=group2,c=us
uniquemember: cn=group1,c=us
uniquemember: cn=group4,c=us

group 4

 
dn: cn=group4,c=us
cn: group4
objectclass: top
objectclass: groupofUniqueNames
uniquemember: cn=john doe,c=uk
uniquemember: cn=jane doe,c=uk
uniquemember: cn=anne smith,c=us

group 3には、次のネストされたグループが含まれています。

  • cn=group2,c=us

  • cn=group1,c=us

  • cn=group4,c=us

group3のアクセス制御ポリシーは、group3、group1およびgroup2のメンバーに適用されます。これは、各グループが権限グループとしてマークされているためです。この同じアクセス制御ポリシーは、group4のメンバーには適用されません。これは、group4は権限グループとしてマークされていないためです。

たとえば、ユーザーが識別名cn=john doe,c=ukでgroup4のメンバーとしてOracle Internet Directoryにバインドされている場合を考えてみます。group3のメンバーに適用されるアクセス・ポリシーがこのユーザーに適用されることはありません。これは、このユーザーの唯一の直接メンバーシップが非権限グループに対するものであるためです。これに対して、ユーザーがcn=john smith,c=us、つまり、group1とgroup2のメンバーとしてバインドされている場合、そのアクセス権はgroup1、group2およびgroup3(group1とgroup2がネストされているため)のメンバーに対して設定されているアクセス・ポリシーで管理されます。これは、この3つのグループすべてがオブジェクト・クラスorclPrivilegeGroupと関連付けられているためです。

関連項目:

グループ・エントリを変更して、orclPrivilegeGroupまたはorclACPgroupオブジェクト・クラスと関連付ける方法または関連付けを解除する方法は、「Oracle Directory Services Managerを使用したグループ・エントリの管理」または「コマンド行を使用したグループ・エントリの管理」を参照してください

31.1.4 アクセス制御情報のコンポーネントについて

アクセス制御情報とは、様々なエンティティまたはサブジェクトがディレクトリ内の指定されたオブジェクトに対して操作を行う必要がある権限を表します。

したがって、ACIは次の3つのコンポーネントで構成されています。

31.1.4.1 オブジェクトに対するアクセス制御

アクセス制御ディレクティブのオブジェクト部分により、そのアクセス制御が適用されるエントリおよび属性が決まります。エントリまたは属性のいずれかに適用できます。

ACIに関連付けられているエントリ・オブジェクトは、ACI自体が定義されているエントリまたはサブツリーによって暗黙的に識別されます。属性のレベルにおけるその他の条件は、ACL式で明示的に指定されます。

orclACI属性においては、ACIのオブジェクトのエントリ識別名コンポーネントは、暗黙的に、最上位のエントリのACPから始まるサブツリー内のエントリすべての識別名コンポーネントです。たとえば、dc=comがACPの場合、そのACIで管理されるディレクトリ領域は次のようになります。 

.*, dc=com.

ただし、ディレクトリ領域は暗黙的であるため、この識別名コンポーネントは不要で、構文的にも許可されません。

orclEntryLevelACI属性においては、ACLのオブジェクトのエントリ識別名コンポーネントは、暗黙的にエントリ自体の識別名コンポーネントです。たとえば、dc=example,dc=comにエントリ・レベルのACIが関連付けられている場合、そのACIが管理しているエントリはdc=example,dc=com自体です。ただし、これは暗黙的であるため、この識別名コンポーネントは不要で、構文的にも許可されません。

ACLのオブジェクト部分は、次のようにエントリ内の属性と一致させるフィルタによって、エントリをオプションで限定できます。

filter=(ldapFilter)

ldapFilterは、LDAP検索フィルタの文字列を表しています。特別なエントリ・セレクタ*は、全エントリの指定に使用されます。

エントリ内の属性をポリシーに組み込むには、次のようにカンマで区切られた属性名のリストをオブジェクト・セレクタに組み込みます。

attr=(attribute_list)

エントリ内の属性をポリシーから除外するには、次のようにカンマで区切られた属性名のリストをオブジェクト・セレクタに組み込みます。

attr!=(attribute_list)

アクセス制御ディレクティブのオブジェクト部分には、特別なキーワードが含まれている場合もあります。これらのツールは、次のとおりです。

  • DenyGroupOverride(上位レベルのACPによるアクセス権の無視を防止)

  • AppendToAll(評価時にACIのサブジェクトをそのACP内の他のすべてのACIに追加)

ノート:

エントリ自体に対するアクセス権は、特別なオブジェクト・キーワードENTRYを使用して、付与または否認する必要があります。属性に対してアクセス権を付与するのみでは不十分で、ENTRYキーワードを指定してエントリ自体にアクセス権を付与する必要があることに注意してください。

関連項目:

ACIの書式または構文の詳細は、「アクセス制御ディレクティブ書式」を参照してください

31.1.4.2 エンティティに対するアクセス制御

この項では、エンティティ、認証モードおよびオブジェクト制約について説明します。

31.1.4.2.1 エンティティについて

アクセス権は、エントリではなくエンティティに対して付与されます。エンティティ・コンポーネントは、アクセス権が付与されているエンティティを指定します。

直接または間接的にエンティティを指定できます。

エンティティの直接指定: この方法は、実際のエンティティ値の入力(たとえば、group=managers)を必要とします。次の要素を使用して値を入力します。

  • 任意のエントリと一致するワイルド・カード文字(*)

  • アクセス権によって保護されているエントリと一致するキーワードSELF

  • ディレクトリで指定されているSuperUser識別名と一致するキーワードSuperUser

  • エントリの識別名と一致する正規表現(たとえば、dn=regex)

  • 権限グループ・オブジェクトのメンバー(group=dn)

エンティティの間接指定: これはエンティティを動的に指定する方法です。アクセス権を付与しているエントリの一部である識別名値属性を指定する必要があります。識別名値属性には次の3つのタイプがあります。

  • dnattr: この属性を使用して、このエントリに対してアクセス権を付与または制限しているエンティティの識別名を指定します。

  • groupattr: この属性を使用して、このエントリに対してアクセス権を付与または制限している管理グループの識別名を指定します。

  • guidattr: この属性を使用して、このエントリに対してアクセス権を付与または制限するエントリのグローバル・ユーザー識別子(orclGUID)を指定します。

たとえば、Anne Smithのマネージャが彼女のエントリで給与属性を変更できるように指定する場合を想定します。マネージャの識別名を直接指定するかわりに、識別名値属性を指定します(dnattr=manager)。次に、John DoeがAnneの給与属性を変更しようとすると、ディレクトリ・サーバーでは次の処理が実行されます。

  1. 彼女のmanager属性の値を参照し、John Doeであることを確認します。

  2. バインド識別名とmanager属性が一致することを確認します。

  3. 適切なアクセス権をJohn Doeに付与します。

31.1.4.2.2 バインド・モード

バインド・モードは、サブジェクトが使用する認証と暗号化の方法を指定します。

認証には、次の4つのモードがあります。

  • MD5Digest

  • PKCS12

  • プロキシ

  • 簡易: パスワードベースの簡易認証

暗号化には、次の3つのオプションがあります。

  • SASL

  • SSL認証なし

  • SSL一方向

暗号化モードの指定はオプションです。未指定の場合は、選択した認証モードがPKCS12でないかぎり暗号化は使用されません。PKCS12を使用して送信したデータは、すべて暗号化されます。

認証の選択肢には次のような優先順位規則があります。

匿名<プロキシ<簡易<MD5ダイジェスト<PKCS12

この規則は次のことを意味します。

  • プロキシ認証は、匿名アクセスをブロックします。

  • 簡易認証は、プロキシおよび匿名アクセスの両方をブロックします。

  • MD5ダイジェスト認証は、簡易、プロキシおよび匿名アクセスをブロックします。

  • PKCS12認証は、MD5ダイジェスト、簡易、プロキシおよび匿名アクセスをブロックします。

バインド・モードの構文は次のとおりです。

BINDMODE =(LDAP_AUTHENTICATION_CHOICE + [ LDAP_ENCRYPTION_CHOICE ] ) 
LDAP_AUTHENTICATION_CHOICE = Proxy | Simple | MD5Digest | PKCS12 
LDAP_ENCRYPTION_CHOICE = SSLNoAuth | SSLOneway | SASL

LDAP_ENCRYPTION_CHOICEパラメータはオプションです。未指定の場合、ディレクトリ・サーバーでは、暗号化は使用されないとみなされます。

31.1.4.2.3 バインドIPフィルタ

標準LDAPフィルタを使用してorclipaddress属性で定義した、サブジェクトのIPアドレスまたはIPアドレス範囲です。サブジェクトのIPアドレスが定義したフィルタに一致すると、そのフィルタが定義されているACIが操作に適用できるようになります。

バインドIPフィルタの構文は次のとおりです。

BINDIPFILTER =(LDAPFILTER_FOR_ORCLIPADDRESS)

たとえば:

フィルタ(|(orclipaddress=1.2.3.*)(orclipaddress=1.2.4.*))は、サブジェクトのIPアドレスが1.2.3で始まるか、または1.2.4で始まる場合に適用されます。

フィルタ(&(orclipaddress!=1.2.*)(orclipaddress!=3.4.*))は、サブジェクトのIPアドレスが1.2で始まらない場合、および3.4で始まらない場合に適用されます。

31.1.4.2.4 オブジェクト追加制約

親エントリに追加アクセス権がある場合、階層内の下位エントリとしてオブジェクトを追加できます。オブジェクト追加制約は、ldapfilterを指定することによって、追加アクセス権を制限するために使用できます。

関連項目:

「アクセス制御ディレクティブ書式」および「LDAPフィルタ定義」

31.1.4.3 操作に対するアクセス制御

付与するアクセス権の種類は次のいずれかです。

  • なし

  • Compare/nocompare

  • Search/nosearch

  • Read/noread

  • Selfwrite/noselfwrite

  • Write/nowrite

  • Add/noadd

  • Proxy/noproxy

  • Browse/nobrowse

  • Delete/nodelete

各アクセス・レベルを個々に付与または否認できることに注意してください。noxxxという記述は、xxx権限が否認されていることを意味します。

エントリに関連付けられているアクセス権と、属性に関連付けられているアクセス権があることにも注意してください。

表31-2 アクセスのタイプ

アクセス・レベル 説明 オブジェクトのタイプ

比較

属性値で比較操作を実行する権限。

属性

読取り

属性値を読み取る権限。属性に対して読取り権限が与えられている場合でも、エントリ自体に参照権限がないかぎり値は返されません。

属性

検索

検索フィルタで属性を使用する権限。

属性

自己書込み

識別名のグループ・エントリ属性のリスト内で、ユーザー自身の追加/削除あるいは自身のエントリの変更を行う権限。メンバーがリスト上の自分自身をメンテナンスできます。たとえば、次のコマンドを実行すると、グループ内のユーザーがmember属性上で、自分自身の識別名のみを追加または削除できます。

access to attr=(member) by dnattr=(member) (selfwrite)

dnattrセレクタは、member属性にリストされているエンティティにアクセス権が適用されるように指定します。selfwriteアクセス権セレクタは、そのメンバーが、属性上で自分自身の識別名のみを追加または削除できるように指定します。

属性

書込み

エントリの属性を変更/追加/削除する権限。

属性

なし

アクセス権なし。サブジェクトとオブジェクトの組合せにアクセス権を付与しない場合、サブジェクトにとってオブジェクトがそのディレクトリに存在しないかのように見えるという効果があります。

エントリおよび属性

追加

ターゲットのディレクトリ・エントリの下にエントリを追加する権限。

エントリ

プロキシ

別のユーザーの代理となる許可。

エントリ

参照

検索結果で識別名を返すための権限。X.500のリスト権限と同等です。この権限は、クライアントがエントリの識別名をldapsearch操作でベース識別名として使用するときにも必要です。

エントリ

削除

ターゲットのエントリを削除する権限。

エントリ

エントリ・レベルのアクセス・ディレクティブは、オブジェクト・コンポーネント内のキーワードENTRYで識別されます。

ノート:

デフォルトのアクセス制御ポリシーでは、エントリおよび属性の両方を対象に、すべての人に、エントリ内のすべての属性の読取り、検索、書込みおよび比較の各アクセス権が付与されており、自己書込み権限は未指定です。エントリが未指定の場合、アクセス権は、そのアクセス権が指定されている直近の上位レベルで判断されます。

31.1.5 LDAP操作のアクセス・レベル要件

この表に、LDAPのアクセス・レベル要件に関する情報を示します。

表31-3に、LDAP操作と、各操作の実行に必要なアクセス権を示します。

表31-3 LDAP操作および各操作の実行に必要なアクセス権

操作 必要なアクセス権

オブジェクトの作成

親エントリに対する追加アクセス権

変更

変更対象の属性に対する書込みアクセス権

識別名の変更

現行の親に対する削除アクセス権と新しい親に対する追加アクセス権

相対識別名の変更

ネーミング属性すなわち相対識別名属性に対する書込みアクセス権

オブジェクトの削除

削除対象のオブジェクトに対する削除アクセス権

比較

属性に対する比較アクセス権とエントリに対する参照アクセス権

検索

  • フィルタ属性での検索アクセス権およびエントリでの参照アクセス権(エントリ識別名が結果として返される必要がある場合)

  • フィルタ属性での検索アクセス権、エントリでの参照アクセス権および属性での読取り権(その値が結果として返される必要があるすべての属性について)

31.1.6 ACLの評価

ユーザーが指定されたオブジェクトで操作を実行しようとすると、ディレクトリ・サーバーは、そのオブジェクト上で操作を実行するための適切なアクセス権がユーザーにあるかどうかを判断します。オブジェクトがエントリの場合、ディレクトリ・サーバーは、エントリおよびその各属性に対するアクセス権を系統的に評価します。

オブジェクト(エントリの属性も含む)へのアクセス権の評価は、そのオブジェクトのACIディレクティブすべての検証を必要とする場合があります。これは、ACPに階層的な特性があり、上位ACPから従属ACPにポリシーが継承されるためです。

ディレクトリ・サーバーは、最初にエントリ・レベルACI(orclEntryLevelACI)のACIディレクティブを検証します。最も近いACPに進み、評価が完了するまで各上位ACPを次々に検討します。この項の内容は次のとおりです。

31.1.6.1 ACL評価時の属性の状態

ACLの評価時には、属性は表31-4に示すいずれかの状態になります。

表31-4 ACL評価時の属性の状態

状態 説明

権限による解決

属性に対して要求されたアクセスは、ACIで付与されています。

否認による解決

属性に対して要求されたアクセスは、ACIで明示的に否認されています。

未解決

対象の属性に対して、適用可能なACIがまだ見つかりません。

検索を除き、次の場合にはすべての操作の評価が停止します。

  • エントリ自体に対するアクセス権が否認される。

  • 属性のいずれかが「否認による解決」の状態になる。

この場合、操作は失敗し、ディレクトリ・サーバーはエラーをクライアントに返します。

検索操作の場合は、すべての属性が「Resolved」の状態になるまで評価が続けられます。「否認による解決」の属性は返されません。

31.1.6.2 ACLの評価に使用される優先順位規則の概要

LDAPの操作では、LDAPセッションのBindDN(つまりサブジェクト)に、そのオブジェクト(エントリ自体およびエントリの個々の属性を含む)で操作を実行するための特定の権限が必要です。

通常は、アクセス制御の管理認可の階層があり、ネーミング・コンテキストのルートから、継承する管理ポイント(またはアクセス制御ポリシー・ポイント)までが1つの階層になります。ACPは、orclACI属性の定義済の値を持つ任意のエントリです。また、単一のエントリ固有のアクセス情報をそのエントリ(orclEntryLevelACI)内で示すこともできます。

ACLの評価には、LDAP操作の実行に必要な権限がサブジェクトにあるかどうかを判別する処理が含まれています。通常、orclentryLevelACIまたはorclACIには、ACLの評価に必要な情報がすべて含まれているわけではありません。したがって、評価が完全に解決されるまで、使用可能なすべてのACL情報が、一定の順序で処理されます。

処理の順序は次の規則に従います。

  • エントリ・レベルのACIが最初に検証されます。orclACIのACIは、そのターゲット・エントリに一番近いACPから順に上位方向に検証されます。

  • 必要な権限が判別された時点で、評価は停止します。それ以外は評価が継続されます。

  • 単一のACI内では、セッションの識別名と関連付けられているエンティティが、by句で識別される複数の項目と一致している場合、有効なアクセス権が次のように評価されます。

    • 一致するby句の項目内で付与された全権限のUNION

      次の場合のAND検索

    • 一致するby句の項目内で否認された全権限のUNION

31.1.6.2.1 エントリ・レベルにおける優先順位

エントリ・レベルにおけるACIは、次の順序で評価されます。

  1. フィルタを使用している場合。たとえば:
    access to entry filter=(cn=p*)
    by group1 (browse, add, delete)
  2. フィルタを使用していない場合。たとえば:
    access to entry
    by group1 (browse, add, delete)
31.1.6.2.2 属性レベルにおける優先順位

属性レベルにおいては、属性が指定されているACIが未指定のACIよりも優先されます。

  1. 属性が指定されているACIは、次の順序で評価されます。

    1. フィルタを使用しているもの。たとえば: 

      access to attr=(salary) filter=(salary > 10000)
by group1 (read)

    2. フィルタを使用していないもの。たとえば:

      access to attr=(salary)
by group1 (search, read)

  2. 属性が未指定のACIは、次の順序で評価されます。

    1. フィルタを使用している場合。たとえば:

      access to attr=(*) filter (cn=p*)
by group1 (read, write)

    2. フィルタを使用していない場合。たとえば:

      access to attr=(*)
by group1 (read, write)
31.1.6.3 同一オブジェクトに対する複数ACIの使用

Oracle Internet Directoryでは、オブジェクトのACP内に複数のACIを定義できます。オブジェクトに関連付けられているACIを処理して、内部ACPキャッシュ内に単一ACIとして格納します。その後、ACP内に指定された複数のACIのすべての関連ポリシーを適用します。

この動作については、次のACPの例を参照してください。

Access to entry by dn="cn=john" (browse,noadd,nodelete)
Access to entry by group="cn=admingroup" (browse,add,nodelete)
Access to entry by dn=".*,c=us" (browse,noadd,nodelete)

このACPには、オブジェクト・エントリに対する3つのACIがあります。このACPをロードする場合、Oracle Internet Directoryは、内部ACPキャッシュ内でこの3つのACIを1つのACIとしてマージします。

ACIの構文は次のとおりです。

Access to OBJECT> by SUBJECT ACCESSLIST
OBJECT = [ entry | attr [EQ-OR-NEQ] ( * | ATTRLIST ) ]
[ filter = ( LDAFILTER ) ]

この構文は、次のオブジェクトのタイプを可能にします。

  • エントリ

  • Entry + filter = (LDAPFILTER)

  • Attr = (ATTRLIST)

  • Attr = (ATTRLIST) + filter = (LDAPFILTER)

  • Attr!= (ATTRLIST)

  • Attr!= (ATTRLIST) + filter = (LDAPFILTER)

  • Attr = (*)

  • Attr = (*) + filter = (LDAPFILTER)

前述のすべてのオブジェクトのタイプに対して、複数のACIを定義できます。ACPの初期ロード時に、ディレクトリ・サーバーは、定義されたオブジェクト・タイプに基づいてACIをマージします。ACI内のオブジェクト文字列が完全一致の文字列かどうかを比較することが、一致基準となります。

1つのACIでATTR=(ATTRLIST)が指定され、別のATTR!=(ATTRLIST)が指定されている場合、ATTR=(*)はエントリ内でACIとしては指定できません。また、ACIでATTR=(ATTRLIST)が指定されている場合に、ATTRLISTにはない属性に対するアクセス権限を指定するには、ATTR!=(ATTRLIST)ではなく、ATTR=(*)を指定する必要があります。ATTR=(*)は、ATTRLISTで指定されている属性以外のすべての属性を示します。

ノート:

同じ属性に対して同じフィルタを使用して複数のACIを定義する場合、Oracle Internet Directoryはそれらをマージし、実行時の構造として単一のACIを作成します。

同じ属性に対して異なるフィルタを使用して複数のACIを定義する場合、Oracle Internet Directoryではそれらを個別のACIとして処理します。このような場合、優先順位は決定的ではありません。

あいまいな動作を防ぐには、同じ属性に対して異なるフィルタを使用して複数のACIを定義する場合、フィルタにより重複する結果が生じないようにしてください。

31.1.6.4 ディレクトリ・オブジェクトに対する排他的アクセス権

指定したオブジェクトにACIが存在している場合は、そのオブジェクト以外のすべてのオブジェクトに対してアクセス権を指定できます。そのためには、アクセス権をすべてのオブジェクトに付与するか、または1つのオブジェクトに対するアクセス権を否認します。

次の例は、アクセス権をすべての属性に付与します。

access to attr=(*)  by group2 (read)

次の例は、userpassword属性に対するアクセス権を否認します。 

access to attr!=(userpassword) by group2 (read)
31.1.6.5 グループの場合のACL評価について

属性またはエントリ自体の操作が、DIT内の下位のACPで明示的に否認されている場合、通常、ACLによるそのオブジェクトの評価は、否認による解決とみなされます。ただし、そのセッションのユーザー(bindDN)がグループ・オブジェクトのメンバーの場合、評価はまだ解決されていないかのように継続されます。グループのサブジェクト・セレクタを介して、ツリー内の上位のACPでセッションのユーザーに権限が付与されている場合、この権限付与はDIT内の下位での否認よりも優先されます。

この例は、上位レベルのACPのACLポリシーが、DIT内の下位のACPポリシーよりも優先される唯一のケースです。

31.2 Oracle Directory Services Managerを使用したアクセス制御の管理

ACP内のアクセス制御情報は、Oracle Directory Services Managerまたはコマンド行ツールを使用して表示および変更できます。

この項では、Oracle Directory Services Managerでこれらのタスクを実行する方法について説明します。

ノート:

Oracle Internet Directoryをインストール後ただちに、デフォルトのセキュリティ構成をリセットしてください。

31.2.1 Oracle Directory Services Managerを使用したACPの表示

ACPを特定し、表示する手順は次のとおりです。

  1. 「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。
  2. タスク選択バーで、「セキュリティ」を選択します。
  3. 左側のペインで「アクセス制御」をクリックします。定義されているすべてのアクセス制御ポイント(ACP)が、左側のペインに相対識別名順に表示されます。完全識別名を表示するには、エントリ上にマウスを移動します。
  4. ACPを選択してその情報を右側のペインに表示します。
  5. ページのサブツリー・アクセス項目セクションには、エントリ・レベルの操作(エントリ自体に対する操作)に関してこのACPに対するアクセス制御が表示されます。

    ページの「コンテンツ・アクセス項目」セクションには、属性レベルの操作(エントリの属性に対する操作)に関してこのACPに対するアクセス制御が表示されます。

31.2.2 Oracle Directory Services Managerを使用したACPの追加

ACPは、規定の、すなわち継承可能なアクセス制御情報を含んだエントリです。この情報は、エントリ自体とその下位エントリすべてに影響を与えます。一般的に、サブツリー全体にわたる規模の大きいアクセス制御をブロードキャストするACPを作成します。

Oracle Directory Services Managerを使用してACPを追加するには、次の3つのタスクが必要です。

関連項目:

構造型アクセス項目またはコンテンツ・アクセス項目の削除

31.2.2.1 ACPにするエントリの指定

エントリをACPとして指定するには、次のステップを実行します。

  1. 「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。
  2. タスク選択バーで、「セキュリティ」を選択します。
  3. 左側のペインで「アクセス制御」をクリックします。定義されているすべてのACPが左側のペインに表示されます。
  4. 左側のペインで「アクセス制御ポリシー・ポイントを作成します。」アイコンをクリックします。「新規アクセス制御ポイント」画面が表示されます。
  5. 作成するエントリへのパスを入力するか、「参照」をクリックし、識別名を選択して、「OK」をクリックします。

    エントリがすでにACPとして定義されている場合、エラー・ダイアログが表示されます。

  6. また、既存のACPと同様のACPを作成するには、左側のペインの「アクセス制御管理」の下の既存のACPを選択し、類似作成アイコンをクリックします。「新規アクセス制御ポイント: 類似作成」画面が表示されます。
31.2.2.2 構造型アクセス項目の構成

構造型アクセス項目を構成するには、次のステップを実行します。

  1. 新規構造型アクセス項目(エントリに関係するACI)を定義するには、「新規アクセス制御ポイント」ペインまたは「新規アクセス制御ポイント: 類似作成」ペインの「構造型アクセス項目」セクションの新規アクセス項目の作成アイコンを選択します。「構造型アクセス項目」ダイアログ・ボックスが表示されます。

    また、既存の項目と同様の構造型アクセス項目を作成することもできます。既存の構造型アクセス項目を選択し、「新規アクセス制御ポイント」ペインまたは「新規アクセス制御ポイント: 類似作成」ペインの「構造型アクセス項目」セクションの「選択したアクセス項目のコピーを作成します。」アイコンを選択します。「構造型アクセス項目」ダイアログ・ボックスが表示されます。一部のタブには構成情報が移入されていますが、これらは必要に応じて変更できます。

    「構造型アクセス項目」ダイアログ・ボックスには、「エントリ・フィルタ」、「追加されたオブジェクト・フィルタ」、「責任者」および「アクセス権限」の4つのタブがあります。「エントリ・フィルタ」タブ・ページを使用して、ACIが関係するサブツリー・エントリを制限できます。「追加されたオブジェクト・フィルタ」、「責任者」および「アクセス権限」タブを使用して、アクセス制御を指定します。

  2. ACPのすべての下位エントリをACPで管理する場合は、「エントリ・フィルタ」タブ・ページには何も入力せず、次のステップに進みます。それ以外の場合は、このステップを実行します。

    エントリへのアクセスを、このエントリの1つ以上の属性に基づいて制限できます。たとえば、役職名がマネージャで組織単位がアメリカであるすべてのエントリへのアクセスを制限できます。

    既存のフィルタを使用するには、「フィルタ・タイプ」メニューから「既存」を選択します。

    新規フィルタを作成するには、「フィルタ・タイプ」メニューから「新規作成」を選択し、「LDAP問合せ」テキスト・フィールドに問合せ文字列を直接入力するか、検索基準バーのリストとテキスト・フィールドを使用して検索を絞り込みます。

    1. 検索基準バーの一番左のリストから、検索するエントリの属性を選択します。各エントリですべての属性が使用されているわけではないため、指定した属性が、検索しているエントリの属性に実際に一致していることを確認する必要があります。そうでない場合は、検索に失敗します。

    2. 検索基準バーの中央のリストから、フィルタを選択します。

    3. 検索基準バーの一番右のテキスト・ボックスに、選択した属性の値を入力します。たとえば、選択した属性がcnの場合は、検索する個々の一般名を入力します。

    4. 「+」をクリックし、この検索基準を「LDAP問合せ」フィールドに追加します。

    5. 検索基準をさらに詳細に指定するには、論理積(AND、OR、NOT ANDおよびNOT OR)のリストと、検索基準バーのリストとテキスト・フィールドを使用して、別の検索基準を追加します。「+」をクリックし、検索基準を「LDAP問合せ」フィールドに追加します。「X」をクリックし、検索基準を「LDAP問合せ」フィールドから削除します。

  3. 「追加されたオブジェクト・フィルタ」タブ・ページを選択します。

    ACIを指定して、ユーザーが追加できるエントリの種類を制限できます。たとえば、ユーザーがobjectclass=countryを持つエントリのみを追加できるように、DSEルート・エントリでACIを指定できます。その後、ディレクトリ・サーバーによって、新規エントリがこのフィルタの制限に適合するかどうかが検証されます。

    ユーザーが追加可能なエントリの種類を制限するには、「エントリ・フィルタ」タブ・ページと同じステップに従い、「LDAP問合せ」テキスト・フィールドに問合せ文字列を直接入力するか、検索基準バーのリストとテキスト・フィールドを使用して検索を絞り込みます。

  4. 「責任者」タブ・ページを選択します。

    1. 「責任者」フィールドで、アクセス権を付与するエンティティを指定します。

    2. 「バインド・モード」の下の「認証の選択」リストから、サブジェクト(アクセス権を要求しているエンティティ)が使用する認証のタイプを選択します。

      認証方式を選択しない場合は、どの種類の認証も受け入れられます。あるノードで指定されている認証方式は、通信先のノードで指定されている認証方式と一致している必要があります。

      「バインド・モード」の下の「暗号化の選択」リストで、使用される暗号化のタイプを選択します。

  5. 「アクセス権限」タブ・ページを選択します。

    付与する権限の種類を指定します。

    • 参照: サブジェクトにエントリの表示を許可します。

    • 追加: サブジェクトに、このエントリの下への他のエントリの追加を許可します。

    • 削除: サブジェクトにエントリの削除を許可します。

    • プロキシ: サブジェクトに、別のユーザーの代理となることを許可します。

  6. 「OK」をクリックします。作成した構造型アクセス項目がリストに表示されます。

「構造型アクセス項目の構成」を繰り返して、このACPの構造型アクセス項目を追加構成します。

31.2.2.3 コンテンツ・アクセス項目の構成

コンテンツ・アクセス項目を構成するには、次のステップを実行します。

  1. コンテンツ・アクセス項目(属性に関係するACI)を定義するには、「新規アクセス制御ポイント」ペインまたは「新規アクセス制御ポイント: 類似作成」ペインの「コンテンツ・アクセス項目」セクションの新規アクセス項目の作成アイコンを選択します。「コンテンツ・アクセス項目」ダイアログ・ボックスが表示されます。

    また、既存の項目と同様のコンテンツ・アクセス項目を作成することもできます。既存のコンテンツ・アクセス項目を選択し、「新規アクセス制御ポイント」ペインまたは「新規アクセス制御ポイント: 類似作成」ペインの「コンテンツ・アクセス項目」セクションの「選択したアクセス項目のコピーを作成します。」アイコンを選択します。「コンテンツ・アクセス項目」ダイアログ・ボックスが表示されます。一部のタブには構成情報が移入されていますが、これらは必要に応じて変更できます。

    「コンテンツ・アクセス項目」ダイアログ・ボックスには、「エントリ・フィルタ」、「責任者」、「属性」および「アクセス権限」の4つのタブがあります。「エントリ・フィルタ」タブ・ページを使用して、ACIが関係するサブツリー・エントリを制限できます。「責任者」、「属性」および「アクセス権限」タブを使用して、アクセス制御を指定します。

  2. ACPのすべての下位エントリをACPで管理する場合は、「エントリ・フィルタ」タブ・ページには何も入力せず、次のステップに進みます。それ以外の場合は、このステップを実行します。

    ACPでは、アクセス権は、他のフィルタによりアクセスがそれ以上制限されないかぎり、このエントリおよびそのエントリのすべてのサブエントリに適用されます。適切な場合、「エントリ・フィルタ」タブ・ページを使用して、アクセスを指定するエントリを識別します。

    エントリへのアクセスを、このエントリの1つ以上の属性に基づいて制限できます。たとえば、役職名がマネージャで組織単位がアメリカであるすべてのエントリへのアクセスを制限できます。

    既存のフィルタを使用するには、「フィルタ・タイプ」メニューから「既存」を選択します。

    新規フィルタを作成するには、「フィルタ・タイプ」メニューから「新規作成」を選択し、「LDAP問合せ」テキスト・フィールドに問合せ文字列を直接入力するか、検索基準バーのリストとテキスト・フィールドを使用して検索を絞り込みます。

    1. 検索基準バーの一番左のリストから、検索するエントリの属性を選択します。各エントリですべての属性が使用されているわけではないため、指定した属性が、検索しているエントリの属性に実際に一致していることを確認する必要があります。そうでない場合は、検索に失敗します。

    2. 検索基準バーの中央のリストから、フィルタを選択します。

    3. 検索基準バーの一番右のテキスト・ボックスに、選択した属性の値を入力します。たとえば、選択した属性がcnの場合は、検索する個々の一般名を入力します。

    4. 「+」をクリックし、この検索基準を「LDAP問合せ」フィールドに追加します。

    5. 検索基準をさらに詳細に指定するには、論理積(AND、OR、NOT ANDおよびNOT OR)のリストと、検索基準バーのリストとテキスト・フィールドを使用して、別の検索基準を追加します。「+」をクリックし、検索基準を「LDAP問合せ」フィールドに追加します。「X」をクリックし、検索基準を「LDAP問合せ」フィールドから削除します。

  3. 「責任者」タブ・ページを選択します。

    1. 「責任者」フィールドで、アクセス権を付与するエンティティを指定します。

    2. 「バインド・モード」の下の「認証の選択」リストから、サブジェクト(アクセス権を要求しているエンティティ)が使用する認証のタイプを選択します。

      認証方式を選択しない場合は、どの種類の認証も受け入れられます。あるノードで指定されている認証方式は、通信先のノードで指定されている認証方式と一致している必要があります。

      「バインド・モード」の下の「暗号化の選択」リストで、使用される暗号化のタイプを選択します。

    3. アクセス権を付与するエンティティを指定します。

  4. 「属性」タブ・ページを選択します。

    1. 「属性」リストから、アクセス権を付与または否認する属性を選択します。

    2. 「演算子」リストから、属性に対して実行する一致操作を選択します。選択肢は「EQ」(=)と「NEQ」(!=)です。

      たとえば、「EQ」とcnを選択した場合は、付与したアクセス権がcn属性に適用されます。「NEQ」とcnを選択した場合は、付与したアクセス権がcn属性に適用されません。

  5. 「アクセス権限」タブ・ページを選択します。

    付与または否認する権限の種類を指定します。

    • 読取り: サブジェクトに属性の読取りを許可します。

    • 検索: サブジェクトに属性の検索を許可します。

    • 書込み: サブジェクトに属性の変更を許可します。

    • 自己書込み: エントリ自体に指定されたサブジェクトに属性の変更を許可します。

    • 比較: サブジェクトに属性値と他の属性値の比較を許可します。

  6. 「OK」をクリックします。作成したコンテンツ・アクセス項目がリストに表示されます。

「コンテンツ・アクセス項目の構成」 を繰り返して、このACPのコンテンツ・アクセス項目を追加構成します。

31.2.2.4 構造型アクセス項目またはコンテンツ・アクセス項目の削除

構造型アクセス項目またはコンテンツ・アクセス項目を削除するには、項目を選択し、「削除」アイコンをクリックします。

31.2.3 ODSMのアクセス制御管理を使用したACPの変更

ODSMでアクセス制御管理を使用してACPを変更するには、次のステップを実行します。

  1. 「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。
  2. タスク選択バーで、「セキュリティ」を選択します。
  3. 左側のペインで「アクセス制御」をクリックします。定義されているすべてのACPが左側のペインに表示されます。
  4. 左側のペインで、リスト内のACPを選択します。そのACPに対応するタブ・ページが右側のペインに表示されます。
  5. 新規構造型アクセス項目(エントリに関係するACI)を定義するには、「エントリ」タブ・ページの「構造型アクセス項目」セクションの「作成」アイコンを選択します。「構造型アクセス項目」ダイアログ・ボックスが表示されます。

    また、既存の項目と同様の構造型アクセス項目を作成することもできます。既存の構造型アクセス項目を選択し、「新規アクセス制御ポイント」ペインまたは「新規アクセス制御ポイント: 類似作成」ペインの「構造型アクセス項目」セクションの「類似作成」アイコンを選択します。「構造型アクセス項目」ダイアログ・ボックスが表示されます。一部のタブには構成情報が移入されていますが、これらは必要に応じて変更できます。

    「構造型アクセス項目」ダイアログ・ボックスには、「エントリ・フィルタ」、「追加されたオブジェクト・フィルタ」、「責任者」および「アクセス権限」の4つのタブがあります。「エントリ・フィルタ」タブ・ページを使用して、ACIが関係するサブツリー・エントリを制限できます。「追加されたオブジェクト・フィルタ」、「責任者」および「アクセス権限」タブを使用して、アクセス制御を指定します。「構造型アクセス項目の構成」のステップ2から始まるステップに従ってください。

  6. 既存の構造型アクセス項目を変更するには、項目を選択し、「編集」をクリックします。「構造型アクセス項目」ダイアログ・ボックスが表示されます。一部のタブには構成情報が移入されていますが、これらは必要に応じて変更できます。タブは、 「エントリ・フィルタ」、「追加されたオブジェクト・フィルタ」、「付与先」および「アクセス権限」です。「エントリ・フィルタ」タブ・ページを使用して、ACIが関係するサブツリー・エントリを制限できます。「追加されたオブジェクト・フィルタ」、「責任者」および「アクセス権限」タブを使用して、アクセス制御を指定します。「構造型アクセス項目の構成」のステップ2から始まるステップに従ってください。「OK」をクリックすると、構造型アクセス項目に加えた変更がリストに反映されます。
  7. 新規コンテンツ・アクセス項目(属性に関係するACI)を定義するには、「エントリ」タブ・ページの「コンテンツ・アクセス項目」セクションの「作成」アイコンを選択します。「コンテンツ・アクセス項目」ダイアログ・ボックスが表示されます。

    また、既存の項目と同様のコンテンツ・アクセス項目を作成することもできます。既存のコンテンツ・アクセス項目を選択し、「新規アクセス制御ポイント」ペインまたは「新規アクセス制御ポイント: 類似作成」ペインの「コンテンツ・アクセス項目」セクションの「類似作成」アイコンを選択します。「コンテンツ・アクセス項目」ダイアログ・ボックスが表示されます。一部のタブには構成情報が移入されていますが、これらは必要に応じて変更できます。

    「コンテンツ・アクセス項目」ダイアログ・ボックスには、「エントリ・フィルタ」、「責任者」、「属性」および「アクセス権限」の4つのタブがあります。「エントリ・フィルタ」タブ・ページを使用して、ACIが関係するサブツリー・エントリを制限できます。「責任者」、「属性」および「アクセス権限」タブを使用して、アクセス制御を指定します。「コンテンツ・アクセス項目の構成」のステップ2から始まるステップに従ってください。

  8. 既存のコンテンツ・アクセス項目を変更するには、項目を選択し、「編集」をクリックします。「コンテンツ・アクセス項目」ダイアログ・ボックスが表示されます。これには、「エントリ・フィルタ」、「付与先」、「属性」および「アクセス権限」の4つのタブがあります。「エントリ・フィルタ」タブ・ページを使用して、ACIが関係するサブツリー・エントリを制限できます。「付与先」、「属性」および「アクセス権限」タブを使用して、アクセス制御を指定します。これらは、「エントリ・フィルタ」、「追加されたオブジェクト・フィルタ」、「付与先」および「アクセス権限」です。「エントリ・フィルタ」タブ・ページを使用して、ACIが関係するサブツリー・エントリを制限できます。「追加されたオブジェクト・フィルタ」、「責任者」および「アクセス権限」タブを使用して、アクセス制御を指定します。「コンテンツ・アクセス項目の構成」のステップに従ってください。「OK」をクリックすると、行った変更がリストに表示されます。
  9. 構造型アクセス項目またはコンテンツ・アクセス項目を削除するには、項目を選択し、「削除」アイコンをクリックします。
  10. 「適用」をクリックして、変更を有効にします。

31.2.4 ODSMのデータ・ブラウザを使用したACPの追加または変更

Oracle Directory Services Managerのデータ・ブラウザを使用してサブツリー・レベルのアクセスを設定するには:

  1. 「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動します。
  2. タスク選択バーで、「データ・ブラウザ」を選択します。
  3. アクセスを設定するエントリにナビゲートします。
  4. ナビゲータ・ペインで、エントリを選択して右側のペインにそのプロパティを表示します。
  5. 「サブツリー・アクセス」タブ・ページを選択して、「ODSMのアクセス制御管理を使用したACPの変更」での説明に従って、「構造型アクセス項目」タブと「コンテンツ・アクセス項目」タブでローカルACIを作成および編集します。
  6. 変更後、「適用」をクリックします。

    ノート:

    入力した情報をディレクトリ・サーバーに送信するには、「適用」をクリックする必要があります。そうしないと、情報はOracle Directory Services Managerのキャッシュに保持されるのみです。

31.2.5 ODSMのデータ・ブラウザを使用したエントリ・レベルのアクセスの設定または変更

Oracle Directory Services Managerを使用してエントリ・レベルのアクセス権を設定するには:

  1. 「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動します。
  2. タスク選択バーで、「データ・ブラウザ」を選択します。
  3. アクセスを設定するエントリにナビゲートします。
  4. ナビゲータ・ペインで、エントリを選択して右側のペインにそのプロパティを表示します。
  5. 「ローカル・アクセス」タブ・ページを選択して、「ODSMのアクセス制御管理を使用したACPの変更」での説明に従って、「構造型アクセス項目」タブと「コンテンツ・アクセス項目」タブでローカルACIを作成および編集します。
  6. 変更後、「適用」をクリックします。

    ノート:

    入力した情報をディレクトリ・サーバーに送信するには、「適用」をクリックする必要があります。

31.3 コマンドライン・ツールを使用したアクセス制御の管理

これらの属性の値の設定および変更にコマンドライン・ツール(ldapmodifyやldapmodifymtを含む)を使用することで、ディレクトリのアクセス制御を管理できます。

「ディレクトリ・アクセス制御の管理の概要」で説明したように、ディレクトリのアクセス制御ポリシーの情報は、ユーザーが変更可能な構成属性で表されます。これらの属性の値の設定および変更にコマンド行ツール(ldapmodifyやldapmodifymtを含む)を使用することで、ディレクトリのアクセス制御を管理できます。

「アクセス制御ディレクティブ書式」の説明に従ってACIを直接編集するには、ACIのディレクトリ表現の書式およびセマンティクスを理解する必要があります。次の各項では、コマンド行ツールを使用したアクセス制御の管理について説明します。

関連項目:

31.3.1 ユーザーが追加できるエントリの種類の制限

ACIを指定して、ユーザーが追加できるエントリの種類を制限できます。たとえば、ユーザーがobjectclass=countryを持つエントリのみを追加できるように、DSEルート・エントリでACIを指定できます。

これを行うには、added_object_constraintフィルタを使用します。その後、ディレクトリ・サーバーによって、新規エントリがこのフィルタの制限に適合するかどうかが検証されます。

次の制限を指定する例を示します。

  • サブジェクトcn=admin,c=usは、organizationエントリの下を参照、追加および削除できます。

  • サブジェクトcn=admin,c=usは、organizationエントリの下のorganizationalUnitオブジェクトを追加できます。

  • その他はすべて、organizationエントリの下を参照できます。 

access to entry filter=(objectclass=organization)  
by group="cn=admin,c=us"
          constraintonaddedobject=(objectclass=organisationalunit)
          (browse,add,delete) 
by * (browse)

31.3.2 ldapmodifyを使用した継承可能なACPの設定

この例では、my_ldif_fileという名前のLDIFファイルを使用して、ルートDSEでorclACIにサブツリーのアクセス権を設定します。

この例はorclACI属性を参照しているため、このアクセス・ディレクティブはDITのエントリすべてを制御します。 

ldapmodify -v -h myhost -D "cn=Directory Manager, o=IMC, c=US" -q -f my_ldif_file

LDIFファイルmy_ldif_fileは次のようになります。 

dn:  
changetype: modify
replace: orclaci
orclaci: access to entry 
 by dn="cn=directory manager, o=IMC, c=us" (browse, add, delete) 
 by * (browse, noadd, nodelete)
orclaci: access to attr=(*) 
 by dn="cn=directory manager, o=IMC, c=us" (search, read, write, compare) 
 by self (search, read, write, compare) 
 by * (search, read, nowrite, nocompare)

31.3.3 ldapmodifyを使用したエントリ・レベルのACIの設定

この例では、my_ldif_fileという名前のLDIFファイルを使用して、orclEntryLevelACI属性にエントリ・レベルのアクセス権を設定します。

この例はorclentrylevelACI属性を参照しているため、このアクセス・ディレクティブは、それが存在しているエントリのみを制御します。 

ldapmodify -v -h myhost -D "cn=Directory Manager, o=IMC, c=US" -q -f my_ldif_file

LDIFファイルmy_ldif_fileは次のようになります。 

dn: 
changetype: modify
replace: orclentrylevelaci
orclentrylevelaci: access to entry 
 by dn="cn=directory manager, o=IMC, c=us" (browse, add, delete) 
 by * (browse, noadd, nodelete)
orclentrylevelaci: access to attr=(*)
 by dn="cn=directory manager, o=IMC, c=us" (search, read, write, compare) 
 by * (search, read, nowrite, nocompare)

ノート:

この例では、識別名の値が指定されていません。このことは、このACIがルートDSEとその属性のみに関係していることを意味します。

31.3.4 ldapmodifyを使用したLDIFファイルでのワイルド・カードの使用方法

この例では、オブジェクトとサブジェクトの指定子にワイルド・カード(*)を使用しています。

example.comドメイン内のすべてのエントリに対して、すべてのユーザーが、すべての属性の読取り権限と検索権限およびすべてのエントリの参照権限を持つことになります。 

ldapmodify -v -h myhost -D "cn=Directory Manager, o=IMC, c=US" -q -f my_ldif_file

dc=comのACP内のorclACI属性は、次のように指定されています。 

access to entry by * (browse)
access to attr=(*) by * (search, read)

属性の読取りを許可するには、エントリの参照権限を付与する必要があります。

31.3.5 識別名によるエントリの選択

この例では、2つのアクセス・ディレクティブで識別名を使用してエントリを選択する際の正規表現の使用方法を示します。

この例では、dc=example,dc=comアクセス権より下位のアドレス帳属性に対するの読取り専用アクセス権をすべての人に付与します。 

ldapmodify -v -h myhost -D "cn=Directory Manager, o=IMC, c=US" -q -f my_ldif_file

dc=example,dc=comのorclACI属性は、次のように指定されています。 

access to entry by * (browse) 
access to attr=(cn, telephone, email) by * (search, read)

dc=us,dc=example,dc=comのorclACI属性は、次のように指定されています。 

access to entry by * (browse) 
access to attr=(*) by dn=".*,dc=us,dc=example,dc=com" (search, read)

31.3.6 属性セレクタとサブジェクト・セレクタの使用方法

この例では、特定の属性に対するアクセス権を付与する属性セレクタ、および様々なサブジェクト・セレクタの使用方法を示します。

この例は、dc=us,dc=example,dc=comサブツリー内のエントリに適用されます。このACIによって施行されるポリシーは次のとおりです。

  • 管理者はサブツリー内のすべてのエントリに対する追加、削除および参照権限を所有しています。dc=usサブツリー内のその他のユーザーは、サブツリーの参照が可能ですが、サブツリー外部のユーザーはそのサブツリーにアクセスできません。

  • salary属性は、そのマネージャによる変更が可能で、本人は参照できます。その他のユーザーはsalary属性にアクセスできません。

  • userPassword属性は、パスワードの所有者と管理者による表示および変更が可能です。その他のユーザーは、この属性の比較のみ可能です。

  • homePhone属性は、本人による読取りおよび書込みが可能で、すべてのユーザーが参照できます。

  • その他のすべての属性は、管理者のみ値の変更が可能です。その他のすべてのユーザーは、比較、検索、読取りは可能ですが、属性値の更新はできません。 

ldapmodify -v -h myhost -D "cn=Directory Manager, o=IMC, c=US" -q -f my_ldif_file

dc=us,dc=example,dc=comのorclACI属性は、次のように指定されています。 

access to entry 
by dn="cn=admin, dc=us,dc=example,dc=com" (browse, add, delete) 
by dn=".*, dc=us,dc=example,dc=com" (browse) 
by * (none) 

access to attr=(salary) 
by dnattr=(manager) (read, write) 
by self (read) 
by * (none) 

access to attr=(userPassword) 
by self (search, read, write) 
by dn="cn=admin, dc=us,dc=example,dc=com" (search, read, write) 
by * (compare) 

access to attr=(homePhone) 
by self (search, read, write) 
by * (read) 

access to attr != (salary, userPassword, homePhone) 
by dn="cn=admin, dc=us,dc=example,dc=com" (compare, search, read, write) 
by * (compare, search, read)

31.3.7 読取り専用アクセス権の付与

この例では、dc=example,dc=comより下位のアドレス帳属性に対する読取り専用アクセス権をすべての人に付与します。

さらに、dc=us,dc=example,dc=comサブツリー内のみのすべての属性に対する読取りアクセス権をすべての人に付与します。 

ldapmodify -v -h myhost -D "cn=Directory Manager, o=IMC, c=US" -q -f my_ldif_file

dc=example,dc=comのorclACI属性は、次のように指定されています。 

access to entry by * (browse)
access to attr=(cn, telephone, email) by * (search, read)

dc=us,dc=example,dc=comのorclACI属性は、次のように指定されています。 

access to entry by * (browse) 
access to attr=(*) by dn=".*,dc=us,dc=example,dc=com" (search, read)

31.3.8 グループ・エントリへの自己書込みアクセス権の付与

この例では、USドメイン内のユーザーに、特定のグループ・エントリのmember属性に対して自分自身の名前(識別名)の追加または削除のみを行うアクセス権を許可します。

この例では、USドメイン内のユーザーに、特定のグループ・エントリ(たとえば、mailing list)のmember属性に対して自分自身の名前(識別名)の追加または削除のみを行うアクセス権を許可します。 

ldapmodify -v -h myhost -D "cn=Directory Manager, o=IMC, c=US" -q -f my_ldif_file

グループ・エントリのorclEntryLevelACI属性は、次のように指定されています。 

access to attr=(member) 
by dn=".*, dc=us,dc=example,dc=com" (selfwrite)

31.3.9 ポリシーの無視を禁止する完全な自律型ポリシーの定義

この例では、グループの無視を否認します。

この例では、グループの無視を否認します。

ldapmodify -v -h myhost -D "cn=Directory Manager, o=IMC, c=US" -q -f my_ldif_file

この例では、次の識別名を使用します。

表31-5 例で使用される識別名

コンテナ DN

グループ無視ポリシーを適用できないネーミング・コンテキスト

c=us

ユーザー・コンテナ

cn=users,c=us

重要なデータ

cn=appdata

このネーミング・コンテキストのユーザー管理グループ

cn= user admin group, cn=users,c=us

セキュリティ管理グループまたはこのネーミング・コンテキスト

cn= security admin group, cn=users,c=us

パスワードをリセットするすべてのネーミング・コンテキストのグローバル・パスワード管理グループ

cn=password admin group

c=usのポリシー要件は次のとおりです。

  • ユーザーはその情報を参照および読取りできる。

  • ユーザー・セキュリティ管理は、パスワードとACPを除く、c=usの下の情報を変更できる。

  • セキュリティ管理グループは、c=usの下のポリシーを変更できる。

  • グローバル・パスワード管理とユーザーは、パスワードをリセットできる。

  • 他のすべてのユーザーに権限は付与されない。

  • このポリシーはオーバーライドできません。

必要なACPは次のとおりです。

Access to entry DenyGroupOverride 
by dn=".*,c=us" (browse,noadd,nodelete)
by group="cn=User admin group,cn=users,c=us" (browse,add,delete)

Access to attr=(orclaci) DenyGroupOverride
by group="cn=security admin group,cn=users,c=us" (search,read,write,compare)
by * (none)

Access to attr=(userpassword) DenyGroupOverride
by self (search,read,write,compare)
by group="cn=password admin group" (search,read,write,compare)
by * (none)

Access to attr=(*) DenyGroupOverride
by self (search,read,nowrite,compare)
by group="cn= User admin group,cn=users,c=us" (search,read,write,compare)
by * (none)