| Oracle Fusion Middleware Oracle Internet Directory管理者ガイド 11gリリース1（11.1.1） B55919-01 |
|
 戻る |
 次へ |
この章では、アクセス制御ポリシーの概要、およびOracle Directory Services Managerまたはコマンドライン・ツールldapmodifyを使用してディレクトリのアクセス制御を管理する方法について説明します。
この章の項目は次のとおりです。
|
関連項目:
|
認可とは、オブジェクトまたはオブジェクトのセットへのアクセスのためにユーザー、プログラムまたはプロセスに与えられる権限です。ディレクトリ・セッション中にディレクトリ操作が試行されると、ディレクトリ・サーバーによって、ユーザーにこれらの操作を実行するための権限があるかどうかが確認されます。ユーザーに権限がない場合、ディレクトリ・サーバーはこれらの操作を許可しません。ディレクトリ・サーバーはアクセス制御情報を使用して、ディレクトリ・ユーザーによる不正操作からディレクトリ・データを保護します。
アクセス制御情報は、アクセス制御に関連する管理ポリシーを記録したディレクトリ・メタデータです。この情報は、ユーザーによる変更が可能な構成属性としてOracle Internet Directoryに格納され、アクセス制御項目（ACI）と呼ばれます。
通常、アクセス制御リスト（ACL）と呼ばれるこのACI属性値のリストは、ディレクトリ・オブジェクトと関連付けられています。このリストの属性値は、様々なディレクトリ・ユーザー・エンティティ（サブジェクト）が各オブジェクトに対して所有している権限を表しています。
アクセス権限を付与するオブジェクト
アクセス権限を付与するエンティティ（サブジェクト）
付与するアクセス権限の種類
アクセス制御ポリシーは規定的です。つまり、そのセキュリティ・ディレクティブは、ディレクトリ情報ツリー（DIT）内のすべての下位エントリに適用されるように設定できます。アクセス制御ポリシーが適用される開始点は、アクセス制御ポリシー・ポイント（ACP）と呼ばれます。
ACIは、ディレクトリ内にテキスト文字列として記述され、格納されています。この文字列は、ACIディレクティブ書式と呼ばれる、明確に定義された書式に従う必要があります。ACI属性の各有効値は、個別のアクセス制御ポリシーを表します。
ホスティングされた環境で実行されているアプリケーションでは、ディレクトリ・アクセス制御の次の機能が使用できます。
規定のアクセス制御
サービス・プロバイダは、ディレクトリ・オブジェクトの集合に対してアクセス制御リスト（ACL）を指定できます。個々のオブジェクトごとにポリシーを設定する必要はありません。この機能によって、アクセス制御の管理が簡素化されます。特に同じポリシーまたは同等のポリシーで管理されるオブジェクトが多数含まれる大きなディレクトリで有効です。
階層的なアクセス制御管理のモデル
サービス・プロバイダは、ホスティングされた企業にディレクトリ管理を委任できます。必要に応じて、レルムからさらに委任することもできます。
委任ドメインに対する管理無効制御
サービス・プロバイダは、アカウントの意図しないロックアウトやセキュリティの不慮の露見に対する診断とリカバリを実行できます。
アクセス制御エンティティの動的評価
サブツリーの管理者は、サブジェクトとオブジェクトの双方を、そのネームスペースおよびディレクトリのその他のオブジェクトとの関連の点で識別できます。たとえば、あるレルムの管理者は、ユーザーの上司のみに、そのユーザーの給与属性の更新を認めることができます。他のレルムの管理者は、給与属性に関して、これと異なるポリシーを確立して適用できます。
アクセス制御ポリシーは、対応するエントリ内のACI属性の値を構成して管理します。そのためには、Oracle Directory Services Managerまたはldapmodifyのいずれかを使用します。
この項の項目は次のとおりです。
この項では、Oracle Internet Directoryでアクセス制御に使用される構造について説明します。次のポリシーが含まれます。
アクセス制御ポリシー・ポイント（ACP）
規定のアクセス制御のためのorclACI属性
エントリ・レベルのアクセス制御のためのorclEntryLevelACI属性
権限グループ
ACPは、orclACI属性に値が指定されたエントリです。orclACI属性の値は、エントリのサブツリーによって継承されるアクセス・ポリシーを示します。エントリのサブツリーは、そのサブツリーのルートとなるACPから始まります。
ディレクトリ・サブツリー内に複数のACPの階層が存在する場合、そのサブツリー内の従属エントリは、すべての上位ACPからアクセス・ポリシーを継承します。継承結果のポリシーは、そのエントリより上位のACP階層内のポリシーを集約したものです。
たとえば、HR部門のエントリにACPが設定されており、HR部門内に、Benefits、PayrollおよびInsuranceグループのエントリがある場合、この3つのグループ内のエントリはいずれも、HR部門のエントリに指定されたアクセス権を継承します。
ACPの階層内に競合するポリシーがある場合、ディレクトリは、集約したポリシーの評価には明確に定義された優先順位規則を適用します。
orclACI属性には、規定のアクセス制御リスト（ACL）ディレクティブが含まれています。つまり、このディレクティブは、この属性が定義されているACPより下位のサブツリー内にあるすべてのエントリに適用されます。ディレクトリ内のあらゆるエントリに、この属性の値を含めることができます。この属性自体へのアクセスは、他の属性に対するアクセスと同様に制御されます。
|
注意: 単一のエントリ固有のACLディレクティブをorclACI属性で示すことができます。ただし、その場合には、「エントリ・レベルのアクセス制御のためのorclEntryLevelACI属性」で説明する、管理が容易でパフォーマンス上のメリットもあるorclEntryLevelACIの使用をお薦めします。これは、orclACIを介して示されるディレクティブの数によってLDAP構成のオーバーヘッドが増加するためです。エントリ固有のディレクティブをorclACIからorclEntryLevelACIに移動すると、このオーバーヘッドを削減できます。 |
あるポリシーが特定のエンティティ（例: 特別のユーザー）のみに関係するとき、そのエンティティのエントリ内でACLディレクティブをメンテナンスできます。これは、orclEntryLevelACIと呼ばれるユーザーが変更可能な構成属性を使用して実行できます。この属性には、関連付けられたエントリにのみ適用されるACLディレクティブが含まれます。
いずれのディレクトリ・エントリにも、この属性の値をオプションで設定できます。それは、Oracle Internet Directoryが抽象型オブジェクト・クラスtopを拡張し、オプション属性としてorclEntryLevelACIを組み込むためです。
orclEntryLevelACI属性は複数値の属性で、構造はorclACIと類似しています。
Oracle Internet Directory内のグループ・エントリは、groupOfNamesオブジェクト・クラスまたはgroupOfUniqueNamesオブジェクト・クラスのいずれかと関連付けられます。グループ内のメンバーシップは、それぞれmember属性またはuniqueMember属性の値として指定されます。
個人またはエンティティのグループにアクセス権を指定するには、セキュリティ・グループでそのグループを識別します。セキュリティ・グループには、ACPグループと権限グループの2つのタイプがあります。
個人がACPグループのメンバーである場合、ディレクトリ・サーバーは、そのACPグループに関連付けられている権限をその個人に単純に付与します。
ACPグループを使用して、ACPのレベルでアクセス権を解決します。たとえば、エントリを参照できるアクセス権を数百ものユーザーに付与すると仮定します。参照権限を各エントリに個別に付与することもできますが、この作業には相当な管理オーバーヘッドが必要となります。さらに、後日その権限の変更が決定した場合は、各エントリを個々に修正する必要があります。より効率的な解決策は、権限を集合的に割り当てることです。そのためには、グループ・エントリを作成してACPグループとして指定し、必要な権限をそのグループに割り当てた後、ユーザーをそのグループのメンバーに割り当てます。その後、アクセス権を変更する場合は、個々のユーザーに対してではなく、グループに対して1箇所で変更を行います。同様に、権限を削除する場合は、多数の各エントリにアクセスするのではなく、グループから権限を削除することによって、複数のユーザーから権限を削除できます。
権限グループは、上位レベルのアクセス・グループです。同様の権限を持つユーザーを管理する点では、ACPグループと類似しています。ただし、権限グループは、単一のACP以外に追加チェックを提供します。たとえば、あるACPによってアクセスが制限される場合、ディレクトリ・サーバーは、アクセスを制限されるユーザーがいずれかの権限グループに属しているかどうかをユーザー・エントリの属性によって判断します。権限グループに属している場合、このユーザーには上位管理レベルで別途の権限があるため、DITで上位管理レベルすべてがチェックされます。リクエストしたオブジェクトへのアクセス権を権限グループに付与することを示す上位ACPが見つかった場合、ディレクトリ・サーバーは、下位ACPによる制限を無視してアクセス権をユーザーに付与します。ただし、下位ACPのorclACIまたはorclEntryLevelACI属性に、キーワードDenyGroupOverrideが含まれている場合、上位レベルのACPは下位ACPを無視しません。DenyGroupOverrideを使用すると、権限グループを使用してスーパーユーザーのアクセスを制限できます。
通常は、ACPグループのみを実装します。権限グループが提供する追加チェックは、パフォーマンスを低下させる可能性があります。下位レベルの標準的な制御よりも上位レベルのアクセス制御を優先させる権限が必要な場合にのみ、権限グループを使用します。
権限グループを使用して、DITの下位ACPでは認識されない管理者に対して、アクセス権を付与します。たとえば、ホスティングされた環境のグローバル管理者が、レルムで操作を行う必要があると仮定します。グローバル管理者のアイデンティティはホスティングされた企業のレルムでは認識されないため、ディレクトリ・サーバーは、そのレルムのACPのみに依存している場合、必要なアクセスを拒否します。ただし、グローバル管理者が権限グループのメンバーである場合、ディレクトリ・サーバーは、DITの上位で、そのサブツリーへのアクセス権をこの権限グループに付与しているACPを検索します。アクセス権を付与しているACPが見つかった場合、ディレクトリ・サーバーは、ホスティングされた企業のレルムにあるACPによる制限を無視します。
DenyGroupOverrideキーワードをACIに追加すると、権限が付与されたグループのメンバーに対してアクセスを拒否できます。
ユーザーがACPグループと権限グループの両方のメンバーの場合、ディレクトリ・サーバーは、各タイプのグループについて評価を行います。ディレクトリ・サーバーは、DITで上位のACPに注目して、権限グループのアクセス権を解決します。
orclacpgroupオブジェクト・クラスとorclPrivilegeGroupオブジェクト・クラスの両方を含むセキュリティ・グループは作成しないでください。
ネストされているセキュリティ・グループの親グループと子グループは、常に同じオブジェクト・クラス（orclacpgroupまたはorclPrivilegeGroup）である必要があります。
これらの制約のいずれかに違反すると、ACIの評価が決定的ではなくなる可能性があります。
アクセス権をユーザーのグループに付与する手順は、次のとおりです。
通常の方法でグループ・エントリを作成します。
グループ・エントリをorclPrivilegeGroupオブジェクト・クラスまたはorclACPgroupオブジェクト・クラスに関連付けます。
そのグループのアクセス・ポリシーを指定します。
メンバーをグループに割り当てます。
エントリは、グループの直接のメンバーとなるか、またはグループをネストして権限グループの一群を形成し、他のACPまたは権限グループの間接のメンバーとなることができます。与えられたレベルで指定されているアクセス・ポリシーは、そのレベル以下のすべてのメンバーに直接的または間接的に適用されます。
Oracle Internet Directoryは、セキュリティ・グループのみをアクセス制御目的で評価するため、その他のタイプのグループに対してアクセス・ポリシーを設定できません。ユーザーが特定の識別名とバインドされると、Oracle Internet Directoryは、セキュリティ・グループ内でそのユーザーの直接のメンバーシップを算出します。指定した識別名の第1レベルのグループを認識すると、Oracle Internet Directoryは、この第1レベルのグループすべての、他のセキュリティ・グループへのネストを算出します。この処理は、評価対象のネストされたグループがなくなるまで行われます。
各セキュリティ・グループ（ネストされているかどうかに関係なく）は、セキュリティ・グループのオブジェクト・クラス（orclACPgroupまたはorclPrivilegeGroup）に関連付けられている必要があります。グループがセキュリティ・グループのメンバーの場合でも、セキュリティ・グループのオブジェクト・クラスに関連付けられていないかぎり、ディレクトリ・サーバーではアクセス制御目的のグループとはみなされません。セキュリティ・グループ内でユーザーのメンバーシップが判断された場合、ディレクトリ・サーバーでは、セッションの存続期間にわたってその情報を使用します。
たとえば、表28-1のエントリのサンプル・グループを仮定します。group4以外は、それぞれ権限グループ（objectclass:orclprivilegegroup）として指定されています。管理者は、group1、group2およびgroup3のメンバーに適用されるアクセス制御ポリシーを設定できます。
表28-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を使用した静的および動的グループ・エントリの管理」または「コマンドラインを使用した静的および動的グループ・エントリの管理」を参照してください。 |
アクセス制御情報とは、様々なエンティティまたはサブジェクトがディレクトリ内の指定されたオブジェクトに対して操作を行う必要がある権限を表します。したがって、ACIは次の3つのコンポーネントで構成されています。
アクセス権限を付与するオブジェクト
アクセス権限を付与するエンティティ（サブジェクト）
付与するアクセス権限の種類
アクセス制御ディレクティブのオブジェクト部分は、そのアクセス制御が適用されるエントリと属性を決定します。エントリまたは属性のいずれかに適用できます。
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キーワードを指定してエントリ自体にアクセス権を付与する必要があることに注意してください。 |
この項では、次の項目について説明します。
アクセス権が付与されるエンティティ
バインド・モード（そのエンティティのアイデンティティの検証に使用される認証モード）
オブジェクト追加制約（アクセス権を付与されたユーザーが、親の下に追加できるオブジェクトの種類の制限）
アクセス権は、エントリではなくエンティティに対して付与されます。エンティティ・コンポーネントは、アクセス権が付与されているエンティティを指定します。
直接または間接的にエンティティを指定できます。
エンティティの直接指定: この方法は、実際のエンティティ値の入力（たとえば、group=managers）を必要とします。次の要素を使用して値を入力します。
任意のエントリと一致するワイルド・カード文字（*）
アクセス権によって保護されているエントリと一致するキーワードSELF
ディレクトリで指定されているSuperUser識別名と一致するキーワードSuperUser
エントリの識別名と一致する正規表現（たとえば、dn=regex）
権限グループ・オブジェクトのメンバー（group=dn）
エンティティの間接指定: これはエンティティを動的に指定する方法です。アクセス権を付与しているエントリの一部である識別名値属性を指定する必要があります。識別名値属性には次の3つのタイプがあります。
dnattr: この属性を使用して、このエントリに対してアクセス権を付与または制限しているエンティティの識別名を指定します。
groupattr: この属性を使用して、このエントリに対してアクセス権を付与または制限している管理グループの識別名を指定します。
guidattr: この属性を使用して、このエントリに対してアクセス権を付与または制限するエントリのグローバル・ユーザー識別子（orclGUID）を指定します。
たとえば、Anne Smithのマネージャが彼女のエントリで給与属性を変更できるように指定する場合を想定します。マネージャの識別名を直接指定するかわりに、識別名値属性を指定します（dnattr=manager）。次に、John DoeがAnneの給与属性を変更しようとすると、ディレクトリ・サーバーでは次の処理が実行されます。
Anneのmanager属性の値を参照し、John Doeであることを確認します。
バインド識別名とmanager属性が一致することを確認します。
適切なアクセス権をJohn Doeに付与します。
バインド・モードは、サブジェクトが使用する認証と暗号化の方法を指定します。
認証には、次の4つのモードがあります。
MD5ダイジェスト
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パラメータはオプションです。未指定の場合、ディレクトリ・サーバーでは、暗号化は使用されないとみなされます。
None
Compare/nocompare
Search/nosearch
Read/noread
Selfwrite/noselfwrite
Write/nowrite
Add/noadd
Proxy/noproxy
Browse/nobrowse
Delete/nodelete
各アクセス・レベルを個々に付与または否認できることに注意してください。noxxxという記述は、xxx権限が否認されていることを意味します。
エントリに関連付けられているアクセス権と、属性に関連付けられているアクセス権があることにも注意してください。
表28-2 アクセスのタイプ
| アクセス・レベル | 説明 | オブジェクトのタイプ |
|---|---|---|
|
Compare |
属性値で比較操作を実行する権限。 |
属性 |
|
Read |
属性値を読み取る権限。属性に対して読取り権限が与えられている場合でも、エントリ自体に参照権限がないかぎり値は返されません。 |
属性 |
|
Search |
検索フィルタで属性を使用する権限。 |
属性 |
|
Selfwrite |
識別名のグループ・エントリ属性のリスト内で、ユーザー自身の追加/削除あるいは自身のエントリの変更を行う権限。メンバーがリスト上の自分自身をメンテナンスできます。たとえば、次のコマンドを実行すると、グループ内のユーザーがmember属性上で、自分自身の識別名のみを追加または削除できます。 access to attr=(member) by dnattr=(member) (selfwrite)
|
属性 |
|
Write |
エントリの属性を変更/追加/削除する権限。 |
属性 |
|
None |
アクセス権なし。サブジェクトとオブジェクトの組合せにアクセス権を付与しない場合、サブジェクトにとってオブジェクトがそのディレクトリに存在しないかのように見えるという効果があります。 |
エントリおよび属性 |
|
Add |
ターゲットのディレクトリ・エントリの下にエントリを追加する権限。 |
エントリ |
|
Proxy |
別のユーザーの代理となる許可。 |
エントリ |
|
Browse |
検索結果で識別名を返すための権限。X.500のリスト権限と同等です。この権限は、クライアントがエントリの識別名をldapsearch操作でベース識別名として使用するときにも必要です。 |
エントリ |
|
Delete |
ターゲットのエントリを削除する権限。 |
エントリ |
エントリ・レベルのアクセス・ディレクティブは、オブジェクト・コンポーネント内のキーワードENTRYで識別されます。
表28-3に、LDAP操作と、各操作の実行に必要なアクセス権を示します。
表28-3 LDAP操作および各操作の実行に必要なアクセス権
| 操作 | 必要なアクセス権 |
|---|---|
|
オブジェクトの作成 |
親エントリに対する追加アクセス権 |
|
変更 |
変更対象の属性に対する書込みアクセス権 |
|
識別名の変更 |
現行の親に対する削除アクセス権と新しい親に対する追加アクセス権 |
|
相対識別名の変更 |
ネーミング属性すなわち相対識別名属性に対する書込みアクセス権 |
|
オブジェクトの削除 |
削除対象のオブジェクトに対する削除アクセス権 |
|
比較 |
属性に対する比較アクセス権とエントリに対する参照アクセス権 |
|
検索 |
|
ユーザーが指定されたオブジェクトで操作を実行しようとすると、ディレクトリ・サーバーは、そのオブジェクト上で操作を実行するための適切なアクセス権がユーザーにあるかどうかを判断します。オブジェクトがエントリの場合、ディレクトリ・サーバーは、エントリおよびその各属性に対するアクセス権を系統的に評価します。
オブジェクト（エントリの属性も含む）へのアクセス権の評価は、そのオブジェクトのACIディレクティブすべての検証を必要とする場合があります。これは、ACPに階層的な特性があり、上位ACPから従属ACPにポリシーが継承されるためです。
ディレクトリ・サーバーは、最初にエントリ・レベルACI（orclEntryLevelACI）のACIディレクティブを検証します。検証は最も近いACPに進み、評価が完了するまで各上位ACPを次々に検討します。
ACLの評価時には、属性は表28-4に示すいずれかの状態になります。
表28-4 ACL評価時の属性の状態
| 状態 | 説明 |
|---|---|
|
Resolved with permission |
属性に対して要求されたアクセスは、ACIで付与されています。 |
|
否認による解決 |
属性に対して要求されたアクセスは、ACIで明示的に否認されています。 |
|
Unresolved |
対象の属性に対して、適用可能なACIがまだ見つかりません。 |
検索を除き、次の場合にはすべての操作の評価が停止します。
エントリ自体に対するアクセス権が否認される。
属性のいずれかが「否認による解決」の状態になる。
この場合、操作は失敗し、ディレクトリ・サーバーはエラーをクライアントに返します。
検索操作の場合は、すべての属性が「Resolved」の状態になるまで評価が続けられます。「否認による解決」の属性は返されません。
この項の項目は次のとおりです。
LDAPの操作では、LDAPセッションのBindDN（つまりサブジェクト）に、そのオブジェクト（エントリ自体およびエントリの個々の属性を含む）で操作を実行するための特定の権限が必要です。
通常は、アクセス制御の管理認可レベルの階層があります。ネーミング・コンテキストのルートから、継承する管理ポイント（またはACP）までが1つの階層です。ACPは、orclACI属性の定義済の値を持つあらゆるエントリです。また、単一のエントリ固有のアクセス情報をそのエントリ（orclEntryLevelACI）内で示すこともできます。
ACLの評価には、LDAP操作の実行に必要な権限がサブジェクトにあるかどうかを判別する処理が含まれています。通常、orclentryLevelACIまたはorclACIには、ACLの評価に必要な情報がすべて含まれているわけではありません。したがって、評価が完全に解決されるまで、使用可能なすべてのACL情報が、一定の順序で処理されます。
処理の順序は次の規則に従います。
エントリ・レベルのACIが最初に検証されます。orclACIのACIは、そのターゲット・エントリに一番近いACPから順に上位方向に検証されます。
必要な権限が判別された時点で、評価は停止します。それ以外は評価が継続されます。
単一のACI内では、セッションの識別名と関連付けられているエンティティが、by句で識別される複数の項目と一致している場合、有効なアクセス権が次のように評価されます。
一致するby句の項目内で付与された全権限のUNION
次の場合のAND検索
一致するby句の項目内で否認された全権限のUNION
エントリ・レベルにおけるACIは、次の順序で評価されます。
フィルタを使用している場合。次に例を示します。
access to entry filter=(cn=p*)
by group1 (browse, add, delete)
フィルタを使用していない場合。次に例を示します。
access to entry
by group1 (browse, add, delete)
属性レベルにおいては、属性が指定されているACIが未指定のACIよりも優先されます。
属性が指定されているACIは、次の順序で評価されます。
フィルタを使用しているもの。次に例を示します。
access to attr=(salary) filter=(salary > 10000) by group1 (read)
フィルタを使用していないもの。次に例を示します。
access to attr=(salary) by group1 (search, read)
属性が未指定のACIは、次の順序で評価されます。
フィルタを使用している場合。次に例を示します。
access to attr=(*) filter (cn=p*) by group1 (read, write)
フィルタを使用していない場合。次に例を示します。
access to attr=(*) by group1 (read, write)
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
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を定義する場合、フィルタにより重複する結果が生じないようにしてください。 |
指定したオブジェクトにACIが存在している場合は、そのオブジェクト以外のすべてのオブジェクトに対してアクセス権を指定できます。そのためには、アクセス権をすべてのオブジェクトに付与するか、または1つのオブジェクトに対するアクセス権を否認します。
次の例は、アクセス権をすべての属性に付与します。
access to attr=(*) by group2 (read)
次の例は、userpassword属性に対するアクセス権を否認します。
access to attr!=(userpassword) by group2 (read)
属性またはエントリ自体の操作が、DIT内の下位のACPで明示的に否認されている場合、通常、ACLによるそのオブジェクトの評価は、否認による解決とみなされます。しかし、そのセッションのユーザー（bindDN）がグループ・オブジェクトのメンバーの場合、評価はまだ解決されていないかのように継続されます。グループのサブジェクト・セレクタを介して、ツリー内の上位のACPでセッションのユーザーに権限が付与されている場合、この権限付与はDIT内の下位での否認よりも優先されます。
この例は、上位レベルのACPのACLポリシーが、DIT内の下位のACPポリシーよりも優先される唯一のケースです。
ACP内のアクセス制御情報は、Oracle Directory Services Managerまたはコマンドライン・ツールを使用して表示および変更できます。この項では、Oracle Directory Services Managerでこれらのタスクを実行する方法について説明します。
|
注意: Oracle Internet Directoryのインストール直後に、デフォルトのセキュリティ構成のリセットに関する項の説明に従ってデフォルトのセキュリティ構成を必ずリセットしてください。 |
この項の項目は次のとおりです。
Oracle Directory Services Managerのデータ・ブラウザを使用したエントリ・レベルのアクセスの設定または変更
|
関連項目: コマンドライン・ツールの説明は、『Oracle Fusion Middleware Oracle Identity Managementユーザー・リファレンス』のOracle Identity Managementコマンドライン・ツールのリファレンスを参照してください。 |
ACPを特定し、表示する手順は次のとおりです。
「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。
タスク選択バーで、「セキュリティ」を選択します。
左側のペインで「アクセス制御」をクリックします。定義されているすべてのアクセス制御ポイント（ACP）が、左側のペインに相対識別名順に表示されます。完全識別名を表示するには、エントリ上にマウスを移動します。
ACPを選択してその情報を右側のペインに表示します。
ページのサブツリー・アクセス項目セクションには、エントリ・レベルの操作（エントリ自体に対する操作）に関してこのACPに対するアクセス制御が表示されます。
ページの「コンテンツ・アクセス項目」セクションには、属性レベルの操作（エントリの属性に対する操作）に関してこのACPに対するアクセス制御が表示されます。
ACPは、規定の、すなわち継承可能なアクセス制御情報を含んだエントリです。この情報は、エントリ自体とその下位エントリすべてに影響を与えます。一般的に、サブツリー全体にわたる規模の大きいアクセス制御をブロードキャストするACPを作成します。
Oracle Directory Services Managerを使用してACPを追加するには、次の3つのタスクが必要です。
タスク2: 構造型アクセス項目の構成（エントリに関係するACI）
タスク3: コンテンツ・アクセス項目の構成（属性に関係するACI）
「構造型アクセス項目またはコンテンツ・アクセス項目の削除」も参照してください。
「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。
タスク選択バーで、「セキュリティ」を選択します。
左側のペインで「アクセス制御」をクリックします。定義されているすべてのACPが左側のペインに表示されます。
左側のペインで、「アクセス制御ポリシー・ポイントを作成します。」アイコンをクリックします。「新規アクセス制御ポイント」画面が表示されます。
作成するエントリへのパスを入力するか、「参照」をクリックし、識別名を選択して、「OK」をクリックします。
エントリがすでにACPとして定義されている場合、エラー・ダイアログが表示されます。
また、既存のACPと同様のACPを作成するには、左側のペインの「アクセス制御管理」の下の既存のACPを選択し、類似作成アイコンをクリックします。「新規アクセス制御ポイント: 類似作成」画面が表示されます。
新規構造型アクセス項目（エントリに関係するACI）を定義するには、「新規アクセス制御ポイント」ペインまたは「新規アクセス制御ポイント: 類似作成」ペインの「構造型アクセス項目」セクションの新規アクセス項目の作成アイコンを選択します。「構造型アクセス項目」ダイアログ・ボックスが表示されます。
また、既存の項目と同様の構造型アクセス項目を作成することもできます。既存の構造型アクセス項目を選択し、「新規アクセス制御ポイント」ペインまたは「新規アクセス制御ポイント: 類似作成」ペインの「構造型アクセス項目」セクションの「選択したアクセス項目のコピーを作成します。」アイコンを選択します。「構造型アクセス項目」ダイアログ・ボックスが表示されます。一部のタブには構成情報が移入されていますが、これらは必要に応じて変更できます。
「構造型アクセス項目」ダイアログ・ボックスには、「エントリ・フィルタ」、「追加されたオブジェクト・フィルタ」、「責任者」および「アクセス権限」の4つのタブがあります。「エントリ・フィルタ」タブ・ページを使用して、ACIが関係するサブツリー・エントリを制限できます。「追加されたオブジェクト・フィルタ」、「責任者」および「アクセス権限」タブを使用して、アクセス制御を指定します。
ACPのすべての下位エントリをACPで管理する場合は、「エントリ・フィルタ」タブ・ページには何も入力せず、次の手順に進みます。それ以外の場合は、この手順を実行します。
エントリへのアクセスを、このエントリの1つ以上の属性に基づいて制限できます。たとえば、役職名がマネージャで組織単位がアメリカであるすべてのエントリへのアクセスを制限できます。
既存のフィルタを使用するには、「フィルタ・タイプ」メニューから「既存」を選択します。
新規フィルタを作成するには、「フィルタ・タイプ」メニューから「新規作成」を選択し、「LDAP問合せ」テキスト・フィールドに問合せ文字列を直接入力するか、検索基準バーのリストとテキスト・フィールドを使用して検索を絞り込みます。
検索基準バーの一番左のリストから、検索するエントリの属性を選択します。各エントリですべての属性が使用されているわけではないため、指定した属性が、検索しているエントリの属性に実際に一致していることを確認する必要があります。そうでない場合は、検索に失敗します。
検索基準バーの中央のリストから、フィルタを選択します。
検索基準バーの一番右のテキスト・ボックスに、選択した属性の値を入力します。たとえば、選択した属性がcnの場合は、検索する個々の一般名を入力します。
「+」をクリックし、この検索基準を「LDAP問合せ」フィールドに追加します。
検索基準をさらに詳細に指定するには、論理積（AND、OR、NOT ANDおよびNOT OR）のリストと、検索基準バーのリストとテキスト・フィールドを使用して、別の検索基準を追加します。検索基準を「LDAP問合せ」フィールドに追加するには、「+」をクリックします。検索基準を「LDAP問合せ」フィールドから削除するには、「X」をクリックします。
「追加されたオブジェクト・フィルタ」タブ・ページを選択します。
ACIを指定して、ユーザーが追加できるエントリの種類を制限できます。たとえば、ユーザーがobjectclass=countryを持つエントリのみを追加できるように、DSEルート・エントリでACIを指定できます。その後、ディレクトリ・サーバーによって、新規エントリがこのフィルタの制限に適合するかどうかが検証されます。
ユーザーが追加可能なエントリの種類を制限するには、「エントリ・フィルタ」タブ・ページと同じ手順に従い、「LDAP問合せ」テキスト・フィールドに問合せ文字列を直接入力するか、検索基準バーのリストとテキスト・フィールドを使用して検索を絞り込みます。
「責任者」タブ・ページを選択します。
「責任者」フィールドで、アクセス権を付与するエンティティを指定します。
「バインド・モード」の下の「認証の選択」リストから、サブジェクト（アクセス権を要求しているエンティティ）が使用する認証のタイプを選択します。
認証方式を選択しない場合は、どの種類の認証も受け入れられます。あるノードで指定されている認証方式は、通信先のノードで指定されている認証方式と一致している必要があります。
「バインド・モード」の下の「暗号化の選択」リストで、使用される暗号化のタイプを選択します。
付与する権限の種類を指定します。
参照: サブジェクトにエントリの表示を許可します。
追加: サブジェクトに、このエントリの下への他のエントリの追加を許可します。
削除: サブジェクトにエントリの削除を許可します。
プロキシ: サブジェクトに、別のユーザーの代理となることを許可します。
「OK」をクリックします。作成した構造型アクセス項目がリストに表示されます。
このACPの構造型アクセス項目を追加構成するには、「タスク2: 構造型アクセス項目の構成」を繰り返します。
コンテンツ・アクセス項目（属性に関係するACI）を定義するには、「新規アクセス制御ポイント」ペインまたは「新規アクセス制御ポイント: 類似作成」ペインの「コンテンツ・アクセス項目」セクションの新規アクセス項目の作成アイコンを選択します。「コンテンツ・アクセス項目」ダイアログ・ボックスが表示されます。
また、既存の項目と同様のコンテンツ・アクセス項目を作成することもできます。既存のコンテンツ・アクセス項目を選択し、「新規アクセス制御ポイント」ペインまたは「新規アクセス制御ポイント: 類似作成」ペインの「コンテンツ・アクセス項目」セクションの「選択したアクセス項目のコピーを作成します。」アイコンを選択します。「コンテンツ・アクセス項目」ダイアログ・ボックスが表示されます。一部のタブには構成情報が移入されていますが、これらは必要に応じて変更できます。
「コンテンツ・アクセス項目」ダイアログ・ボックスには、「エントリ・フィルタ」、「責任者」、「属性」および「アクセス権限」の4つのタブがあります。「エントリ・フィルタ」タブ・ページを使用して、ACIが関係するサブツリー・エントリを制限できます。「責任者」、「属性」および「アクセス権限」タブを使用して、アクセス制御を指定します。
ACPのすべての下位エントリをACPで管理する場合は、「エントリ・フィルタ」タブ・ページには何も入力せず、次の手順に進みます。それ以外の場合は、この手順を実行します。
ACPでは、アクセス権は、他のフィルタによりアクセスがそれ以上制限されないかぎり、このエントリおよびそのエントリのすべてのサブエントリに適用されます。適切な場合、「エントリ・フィルタ」タブ・ページを使用して、アクセスを指定するエントリを識別します。
エントリへのアクセスを、このエントリの1つ以上の属性に基づいて制限できます。たとえば、役職名がマネージャで組織単位がアメリカであるすべてのエントリへのアクセスを制限できます。
既存のフィルタを使用するには、「フィルタ・タイプ」メニューから「既存」を選択します。
新規フィルタを作成するには、「フィルタ・タイプ」メニューから「新規作成」を選択し、「LDAP問合せ」テキスト・フィールドに問合せ文字列を直接入力するか、検索基準バーのリストとテキスト・フィールドを使用して検索を絞り込みます。
検索基準バーの一番左のリストから、検索するエントリの属性を選択します。各エントリですべての属性が使用されているわけではないため、指定した属性が、検索しているエントリの属性に実際に一致していることを確認する必要があります。そうでない場合は、検索に失敗します。
検索基準バーの中央のリストから、フィルタを選択します。
検索基準バーの一番右のテキスト・ボックスに、選択した属性の値を入力します。たとえば、選択した属性がcnの場合は、検索する個々の一般名を入力します。
「+」をクリックし、この検索基準を「LDAP問合せ」フィールドに追加します。
検索基準をさらに詳細に指定するには、論理積（AND、OR、NOT ANDおよびNOT OR）のリストと、検索基準バーのリストとテキスト・フィールドを使用して、別の検索基準を追加します。検索基準を「LDAP問合せ」フィールドに追加するには、「+」をクリックします。検索基準を「LDAP問合せ」フィールドから削除するには、「X」をクリックします。
「責任者」タブ・ページを選択します。
「責任者」フィールドで、アクセス権を付与するエンティティを指定します。
「バインド・モード」の下の「認証の選択」リストから、サブジェクト（アクセス権を要求しているエンティティ）が使用する認証のタイプを選択します。
認証方式を選択しない場合は、どの種類の認証も受け入れられます。あるノードで指定されている認証方式は、通信先のノードで指定されている認証方式と一致している必要があります。
「バインド・モード」の下の「暗号化の選択」リストで、使用される暗号化のタイプを選択します。
アクセス権を付与するエンティティを指定します。
「属性」タブ・ページを選択します。
「属性」リストから、アクセス権を付与または否認する属性を選択します。
「演算子」リストから、属性に対して実行する一致操作を選択します。選択肢は「EQ」（=）と「NEQ」（!=）です。
たとえば、「EQ」とcnを選択した場合は、付与したアクセス権がcn属性に適用されます。「NEQ」とcnを選択した場合は、付与したアクセス権がcn属性に適用されません。
付与または否認する権限の種類を指定します。
読取り: サブジェクトに属性の読取りを許可します。
検索: サブジェクトに属性の検索を許可します。
書込み: サブジェクトに属性の変更を許可します。
自己書込み: エントリ自体に指定されたサブジェクトに属性の変更を許可します。
比較: サブジェクトに属性値と他の属性値の比較を許可します。
「OK」をクリックします。作成したコンテンツ・アクセス項目がリストに表示されます。
このACPのコンテンツ・アクセス項目を追加構成するには、「タスク3: コンテンツ・アクセス項目の構成」を繰り返します。
構造型アクセス項目またはコンテンツ・アクセス項目を削除するには、項目を選択し、「削除」アイコンをクリックします。
「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。
タスク選択バーで、「セキュリティ」を選択します。
左側のペインで「アクセス制御」をクリックします。定義されているすべてのACPが左側のペインに表示されます。
左側のペインで、リスト内のACPを選択します。そのACPに対応するタブ・ページが右側のペインに表示されます。
新規構造型アクセス項目（エントリに関係するACI）を定義するには、「エントリ」タブ・ページの「構造型アクセス項目」セクションの「作成」アイコンを選択します。「構造型アクセス項目」ダイアログ・ボックスが表示されます。
また、既存の項目と同様の構造型アクセス項目を作成することもできます。既存の構造型アクセス項目を選択し、「新規アクセス制御ポイント」ペインまたは「新規アクセス制御ポイント: 類似作成」ペインの「構造型アクセス項目」セクションの類似作成アイコンを選択します。「構造型アクセス項目」ダイアログ・ボックスが表示されます。一部のタブには構成情報が移入されていますが、これらは必要に応じて変更できます。
「構造型アクセス項目」ダイアログ・ボックスには、「エントリ・フィルタ」、「追加されたオブジェクト・フィルタ」、「責任者」および「アクセス権限」の4つのタブがあります。「エントリ・フィルタ」タブ・ページを使用して、ACIが関係するサブツリー・エントリを制限できます。「追加されたオブジェクト・フィルタ」、「責任者」および「アクセス権限」タブを使用して、アクセス制御を指定します。「タスク2: 構造型アクセス項目の構成」の手順2から始まる手順に従ってください。
既存の構造型アクセス項目を変更するには、項目を選択し、「編集」をクリックします。「構造型アクセス項目」ダイアログ・ボックスが表示されます。一部のタブには構成情報が移入されていますが、これらは必要に応じて変更できます。タブは、「エントリ・フィルタ」、「追加されたオブジェクト・フィルタ」、「付与先」および「アクセス権限」です。「エントリ・フィルタ」タブ・ページを使用して、ACIが関係するサブツリー・エントリを制限できます。「追加されたオブジェクト・フィルタ」、「責任者」および「アクセス権限」タブを使用して、アクセス制御を指定します。「タスク2: 構造型アクセス項目の構成」の手順2から始まる手順に従ってください。「OK」をクリックすると、構造型アクセス項目に加えた変更がリストに反映されます。
新規コンテンツ・アクセス項目（属性に関係するACI）を定義するには、「エントリ」タブ・ページの「コンテンツ・アクセス項目」セクションの「作成」アイコンを選択します。「コンテンツ・アクセス項目」ダイアログ・ボックスが表示されます。
また、既存の項目と同様のコンテンツ・アクセス項目を作成することもできます。既存のコンテンツ・アクセス項目を選択し、「新規アクセス制御ポイント」ペインまたは「新規アクセス制御ポイント: 類似作成」ペインの「コンテンツ・アクセス項目」セクションの類似作成アイコンを選択します。「コンテンツ・アクセス項目」ダイアログ・ボックスが表示されます。一部のタブには構成情報が移入されていますが、これらは必要に応じて変更できます。
「コンテンツ・アクセス項目」ダイアログ・ボックスには、「エントリ・フィルタ」、「責任者」、「属性」および「アクセス権限」の4つのタブがあります。「エントリ・フィルタ」タブ・ページを使用して、ACIが関係するサブツリー・エントリを制限できます。「責任者」、「属性」および「アクセス権限」タブを使用して、アクセス制御を指定します。「タスク3: コンテンツ・アクセス項目の構成」の手順2から始まる手順に従ってください。
既存のコンテンツ・アクセス項目を変更するには、項目を選択し、「編集」をクリックします。「コンテンツ・アクセス項目」ダイアログ・ボックスが表示されます。「エントリ・フィルタ」、「付与先」、「属性」および「アクセス権限」の4つのタブがあります。「エントリ・フィルタ」タブ・ページを使用して、ACIが関係するサブツリー・エントリを制限できます。「責任者」、「属性」および「アクセス権限」タブを使用して、アクセス制御を指定します。これらは、「エントリ・フィルタ」、「責任者」、「属性」および「アクセス権限」です。「エントリ・フィルタ」タブ・ページを使用して、ACIが関係するサブツリー・エントリを制限できます。「追加されたオブジェクト・フィルタ」、「責任者」および「アクセス権限」タブを使用して、アクセス制御を指定します。「タスク3: コンテンツ・アクセス項目の構成」の手順に従ってください。「OK」をクリックすると、変更がリストに表示されます。
構造型アクセス項目またはコンテンツ・アクセス項目を削除するには、項目を選択し、「削除」アイコンをクリックします。
「適用」をクリックして、変更を有効にします。
Oracle Directory Services Managerのデータ・ブラウザを使用してサブツリー・レベルのアクセスを設定する手順は、次のとおりです。
「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動します。
タスク選択バーで、「データ・ブラウザ」を選択します。
アクセスを設定するエントリにナビゲートします。
ナビゲータ・ペインで、エントリを選択して右側のペインにそのプロパティを表示します。
「サブツリー・アクセス」タブ・ページを選択して、「Oracle Directory Services Managerのアクセス制御管理を使用したACPの変更」での説明に従って、「構造型アクセス項目」タブと「コンテンツ・アクセス項目」タブでローカルACIを作成および編集します。
変更後、「適用」をクリックします。
|
注意: 入力した情報をディレクトリ・サーバーに送信するには、「適用」をクリックする必要があります。「適用」をクリックしない場合、情報はOracle Directory Services Managerのキャッシュに保持されるのみです。 |
Oracle Directory Services Managerを使用してエントリ・レベルのアクセス権を設定する手順は、次のとおりです。
「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動します。
タスク選択バーで、「データ・ブラウザ」を選択します。
アクセスを設定するエントリにナビゲートします。
ナビゲータ・ペインで、エントリを選択して右側のペインにそのプロパティを表示します。
「ローカル・アクセス」タブ・ページを選択して、「Oracle Directory Services Managerのアクセス制御管理を使用したACPの変更」での説明に従って、「構造型アクセス項目」タブと「コンテンツ・アクセス項目」タブでローカルACIを作成および編集します。
変更後、「適用」をクリックします。
|
注意: 入力した情報をディレクトリ・サーバーに送信するには、「適用」をクリックする必要があります。 |
「ディレクトリ・アクセス制御の管理の概要」で説明したように、ディレクトリのアクセス制御ポリシーの情報は、ユーザーが変更可能な構成属性で表されます。これらの属性の値の設定および変更にコマンドライン・ツール（ldapmodifyやldapmodifymtを含む）を使用することで、ディレクトリのアクセス制御を管理できます。
付録H「アクセス制御ディレクティブ書式」の説明に従ってACIを直接編集するには、ACIのディレクトリ表現の書式およびセマンティクスを理解する必要があります。
この項の項目は次のとおりです。
|
関連項目:
|
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)
この例では、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)
この例では、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とその属性のみに関係していることを意味します。 |
この例では、オブジェクトとサブジェクトの指定子にワイルド・カード（*）を使用しています。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)
属性の読取りを許可するには、エントリの参照権限を付与する必要があります。
この例では、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)
この例では、特定の属性に対するアクセス権を付与する属性セレクタ、および様々なサブジェクト・セレクタの使用方法を示します。この例は、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)
この例では、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)
この例では、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)
この例では、グループの無視を否認します。
ldapmodify -v -h myhost -D "cn=Directory Manager, o=IMC, c=US" -q -f my_ldif_file
この例では、次の識別名を使用します。
表28-5 例で使用される識別名
| コンテナ | DN |
|---|---|
|
グループ無視ポリシーを適用できないネーミング・コンテキスト |
|
|
ユーザー・コンテナ |
|
|
重要なデータ |
|
|
このネーミング・コンテキストのユーザー管理グループ |
|
|
セキュリティ管理グループまたはこのネーミング・コンテキスト |
|
|
パスワードをリセットするすべてのネーミング・コンテキストのグローバル・パスワード管理グループ |
|
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)
