| Oracle® Fusion Middleware Oracle Virtual Directory管理者ガイド 11gリリース1(11.1.1) B55922-05 |
|
 前へ |
 次へ |
この章では、Oracle Virtual Directoryのセキュリティについて説明します。この章の内容は次のとおりです。
Oracle Virtual Directoryは、複数層のアクセス制御および認証をサポートしています。アダプタを介してアクセスされるリモート・ディレクトリの場合、Oracle Virtual Directoryではそれらのシステムに固有のセキュリティをサポートします。使用されるアダプタやその機能に応じて、passcredentialsオプションを設定し、認証およびアクセス制御を実行するためにエンド・ユーザーのバインディング資格証明をリモート・ディレクトリに渡すかどうかを判断できます(図6-1を参照)。
この項では、Oracle Virtual Directoryの認証について説明します。この項の内容は次のとおりです。
アダプタのパススルー・モードが有効化されていて、ユーザーがOracle Virtual Directoryに対して認証される場合、Oracle Virtual Directoryでは受け取ったユーザーIDおよびパスワード資格証明を使用して、ユーザーのかわりにリモート・ディレクトリにログインします(パスワード認証の場合のみ)。リモート・ディレクトリへの認証(バインド)に失敗すると、ユーザーの試行したバインドも失敗します。このモードでは、リモート・ディレクトリがユーザーの資格証明を確認する役割を果しています。
passcredentialsがneverに設定されている場合(または選択したアダプタでサポートされていない場合)は、Oracle Virtual Directoryでクライアントの認証を実行する必要があります。これを実行するためには、外部ディレクトリのパスワードをクリアテキストで保存するか、CRYPT、SHAまたはSSHAの一方向暗号化ハッシュを使用する必要があります。Oracle Virtual Directoryで使用されている暗号化ハッシュを判断するには、暗号化されたテキストに{crypt}という形式の接頭辞が適用されている必要があります。代替元のソースでこの形式が使用されていない場合は、マッピング・ルールを設定してこれを定義する必要があります。マッピング・ルールにより、Oracle Virtual Directoryに特定の暗号化書式の処理方法を伝達する接頭辞が追加されます。接頭辞が存在しない場合は、通常のテキスト比較が行われます。
passcredentialsのneverモードでは、ユーザーによって指定されたパスワードのハッシュ・アルゴリズム(アダプタから戻された値に指定されている)を実行し、アダプタから戻された値と結果を比較することで、Oracle Virtual Directoryによって認証が完了します。
|
注意: クライアントがクリアテキスト・パスワードを使用せずに(証明書などを使用して)バインドすると、サーバーはユーザーの資格証明を代替元のディレクトリに渡すことができません。Oracle Virtual Directoryでは、構成済のアダプタ・アカウントを使用して、バインド検証およびリクエストされたLDAPサービスを実行します。これは、passcredentialsがneverに設定されている場合の処理と同じです。 |
CRAM-MD5は、チャレンジ・レスポンス認証メカニズム(CRAM)で、128ビット・ハッシュ値を持つ幅広く使用されている暗号化ハッシュ関数であるHMAC-MD5 MACアルゴリズム(MD5)を基盤にしています。CRAM-MD5は、Oracle Virtual Directoryへの認証に使用されるSASL(Simple Authentication and Security Layer)バインド・メカニズムです。
クライアントでCRAM-MD5がサポートされている場合は、SSLを使用せずにネットワーク上でパスワードを保護するために使用できます。ただし、CRAM-MD5 SASLメカニズムでは、パスワード以外の情報の交換に使用するパスワードをサーバーが平文で保持している必要があります。これにより、サーバーは、LDAPクライアントによって指定されたパスワードが有効かどうかを判断できます。このモードを使用する場合、すべてのローカル(標準)ソースおよびプロキシ・ソースでパスワードをクリアテキストで保存する必要があります。
Oracle Virtual Directoryでは、使用可能なパスワードのないユーザーを認証する場合、バインドDNがアダプタのネームスペースの外にあるユーザーのかわりを行う場合、またはpasscredentialsがneverに設定されている場合にプロキシ(またはデフォルト)アカウントが使用されます。また、接続されたLDAPアダプタのディレクトリに対してOracle Virtual Directoryのルート管理者アカウントおよび匿名の両方を認証する際にも、アダプタのプロキシ・ユーザーIDおよびパスワードが使用されます。デフォルト・アカウントは、証明書を使用して認証するユーザーにも使用されます。そのため、passcredentialsモードが有効化されている場合には、リモート・ディレクトリでデフォルト・アカウントを権限のないアカウント(匿名など)に設定する必要があることの理解が重要です。これは、現行のアダプタにマップできないアカウントを処理するために、プロキシ・アカウントが必要な状況が数多くあるためです。
Oracle Virtual Directoryでは、X.509デジタル証明書を使用してクライアントが仮想ディレクトリに対して認証する機能がサポートされています。LDAPクライアントでは、X.509デジタル証明書を使用して仮想ディレクトリに対して認証するには、SSLおよびSASLがサポートされている必要があります。次に、SSL認証が機能する2つのモードを示します。
接続は保護するが実際のディレクトリに対しては認証しない方法としてクライアント証明書を使用
証明書を使用してOracle Virtual DirectoryをバインドするためにSASLを使用
次に、認証にクライアント資格証明を使用する場合のガイドラインのリストを示します。
Oracle Virtual Directoryへのバインドに証明書を使用している場合、証明書はバックエンドのデータ・ストアに対してではなく、Oracle Virtual Directoryに対する認証にのみ使用されます。クライアント証明書の認証に必要な秘密鍵へのアクセス権があるのはLDAPクライアントのみであるため、バックエンドのデータ・ストアに対する認証は公開鍵インフラストラクチャ(PKI)によって阻止されます。そのため、LDAPアダプタを使用している場合には、バックエンドのデータ・ストアに対するすべてのOracle Virtual Directory操作はプロキシDNアカウントとして実行されます。
証明書には独自の識別名(DN)が含まれます。これは、実際にバインディングしているユーザーのDNと一致しない場合もあります。その場合、アクセス制御リストが適切に機能するように、証明書のDNをOracle Virtual DirectoryのユーザーのDNにマップする必要が生じることがあります。このマッピングは、プラグインを使用して実行できます。
Oracle Virtual Directoryでは、keys.jksファイルに保存されている、ルートCAによって発行された証明書はすべて受け入れられます。
Oracle Virtual Directoryは、接続されたすべてのデータ・ストアに一様に適用できる詳細なアクセス制御を提供します。また、Internet Engineering Task ForceのRFC 2820「Access Control Requirements for LDAP」にも準拠しています。アクセス制御のルールは、IETFの「LDAP Access Control Model for LDAPv3」(2001年3月2日草稿)というタイトルのインターネット・ドラフトに基づいてモデル化されています。
|
注意: Oracle Virtual Directoryは、1つ以上のエンタープライズ・データ・ソースを1つのディレクトリ・ビューに仮想的に抽出します。そのため、アクセス制御リスト(ACL)およびアダプタ・ネームスペースはそれぞれ独立しています。エントリを削除すると、そのエントリに関連付けられているACLも削除されます。ただし、アダプタのルート値を変更しても、エントリに関連付けられているACLには影響しません。ACLおよびアダプタ・ネームスペースは、それぞれ独立させて構成する必要があります。 |
この項では、Oracle Virtual Directoryのアクセス制御について説明します。この項の内容は次のとおりです。
リモート・ディレクトリに対するクライアントとして、Oracle Virtual Directoryは、リモート・ディレクトリで実行されている認証ルールに従う必要があります。適用されるルールは、リモート・ディレクトリに渡されたユーザー・コンテキスト(Oracle Virtual Directoryが代替元のディレクトリへの接続にどのアカウントを使用しているかなど)によって異なります。
passcredentialsオプションを有効化した場合、リモート・ディレクトリでは、Oracle Virtual Directoryがリモート・ディレクトリに渡すユーザー・コンテキストに応じてルールが実行されます。Oracle Virtual Directoryにより、適切に変換されたデータの結果およびエラーがユーザーに戻されます。たとえば、「アクセスが拒否されました」というメッセージが戻された場合、Oracle Virtual Directoryによりそのメッセージがクライアントに戻されます。アクセス制御によりデータがフィルタ処理された場合には、Oracle Virtual Directoryによりフィルタ処理されたデータが取得され、構成済の任意の変換が適用されてユーザーにそのデータが渡されます。
passcredentialsオプションが有効化されていない場合、リモート・ディレクトリではすべてのリクエストのプロキシ・ユーザーのみが認識され、どのユーザーがOracle Virtual Directoryにバインドされているかにかかわらず同じ認証が適用されます。
passcredentialsオプションが有効化されているか無効化されているかに関係なく、Oracle Virtual Directoryの独自のアクセス制御および認証が提供されます。
Oracle Virtual Directoryでは、アクセス制御情報を保存することで、仮想ディレクトリのネームスペース全体でアクセス制御がサポートされています。この情報は、DITのエントリのDNまたはサブツリーのDNへの変更リクエストを捕捉することで、自動的にメンテナンスされます。Oracle Virtual Directoryのアクセス制御リスト(ACL)は、アダプタを使用して接続されているディレクトリではなく、仮想ディレクトリのネームスペースに定義されているため、単一のACLを、複数のアダプタ全体のデータに対するアクセス権を制御するように定義できます。
同じアクセス制御のドラフト標準を使用している代替元のLDAPディレクトリにエントリが属する場合、Oracle Virtual Directoryにより変更が捕捉され、その内容がエントリの独自のACI値に適用されるため、Oracle Virtual Directoryを使用してそのソース・ディレクトリ内のアクセス制御を変更することはできません。この場合、それらのエントリに対する変更は、ソース・ディレクトリに直接行う必要があります。他のベンダーのディレクトリ・サーバーではアクセス制御情報の保存に異なる属性が使用されているため、通常これは問題ではありません。
アクセス制御のサブジェクトとしてグループを使用している場合、グループの位置およびアダプタ変換によるグループへの影響を考慮することが重要です。定義されている各LDAPプロキシ・アダプタでは、DN属性リストの値が定義されていることを確認してください。この値により、エントリDNに加えて、仮想ディレクトリ・ツリーにマップする必要のある属性のリストが定義されます。DNを含む属性値に依存するアクセス制御の場合は、値が正しくマップされている必要があります。
複数のアダプタ(ローカル・ストア・アダプタおよびLDAPアダプタなど)のメンバーが含まれるグループを作成するには、グループをローカル・ストア・アダプタのアダプタ・ネームスペース(仮想ディレクトリのローカル・ストアなど)に配置する必要があります。グループが外部のLDAPディレクトリ内に配置されていて、そのディレクトリには存在しないメンバーが含まれている場合には、外部ディレクトリのネームスペースに存在しないエントリにはコンテキストがないため、変換は正常に実行されません。
この項では、Oracle Virtual Directoryのアクセス制御コンポーネントについて説明します。この項の内容は次のとおりです。
Oracle Virtual DirectoryのACLを作成するには、次のようにします。
アクセス制御ポイントを構成(つまり、ACLが適用される場所を指定)します。通常、アクセス制御は識別名ですが、ツリーのベースを表すルートにすることもできます。
仮想ディレクトリ・ツリーのエントリ全体である構造型アクセス項目と、エントリの属性であるコンテンツ・アクセス項目の両方にポリシーを構成します。
|
注意: Oracle Virtual Directoryサーバーのアクセス対象または変更対象のエントリがACLアクセス制御ポイントと同じまたはそれより下の場所に存在しない場合、指定されたACLはそれ以上評価されません。アクセス対象または変更対象のエントリがACLアクセス制御ポイントと同じまたはそれより下の場所に存在する場合は、ACLのスコープ設定が評価されます。 |
Oracle Virtual Directoryでは、アクセス制御にエントリとサブツリーという2種類の有効範囲が定義されています。図6-2に、これらの有効範囲コンポーネントがどのように機能するかを示します。
図6-2に示すように、場所と有効範囲は関連しており、場所は有効範囲が評価されるDITでの位置を示します。図6-2のエントリ部分では、アクセス対象または変更対象のディレクトリ・エントリ(DN)が、場所1で示されているのと同じDNである場合にのみACLが適用されます。図6-2のサブツリー部分では、場所1から始まり下に伸びているすべてのDNが、有効範囲がサブツリーであるACLの影響を受けます。指定されたACLの場合、サブツリー有効範囲の唯一のエンドポイントは、1つ目のACLよりも下の場所(場所2)で宣言された他のACLによって、1つ目のACLで定義されているルールが変更される場合に発生します。
エントリ有効範囲は、多くの場合、様々なサブジェクトおよび拒否の設定とともに使用されます。あるエントリに、同じレベルまたはそれより下のエントリよりも機密性の高い情報が含まれていて、プライベートにしておく必要がある場合に特に便利です。タイプのみが異なる2つの有効範囲のルールが存在する場合、エントリ有効範囲がサブツリー有効範囲より優先されます。
各権限に対するOracle Virtual Directoryのアクセス権には、付与と拒否の2種類があります。クライアントに特定情報の一部へのアクセス権を付与するか拒否するかは、アクセス制御ルールおよび保護されているエントリに関連する多くの要因に基づいて決定されます。決定プロセスでは、次のガイドラインが使用されます。
特性: より明確なルールが曖昧なルールより優先されます。たとえば、ACLの特定のクライアントDNはグループ参照よりも優先されます。
拒否: アクセス制御が有効化されている場合のデフォルトで、操作を承諾または拒否するアクセス制御情報はありません。
承諾: Oracle Virtual Directoryでアクセス制御が無効化されている場合のデフォルトです。
エントリとサブツリー: subjectおよびattributesの特性が同一の場合、エントリ有効範囲はサブツリー有効範囲よりも優先されます。
subjectのタイプのみが異なるACLの評価において、Oracle Virtual Directoryで使用される優先順位は次のとおりです。
特定のDNまたはIPアドレス
this
group
subtree
public
|
注意: 2つのACLの違いが承諾/拒否のプロパティのみの場合、ACLが追加される順序に関係なく、許可されるのは拒否です。たとえば、次の2つのACLでは、publicのすべての属性の検索(s)および読取り(r)は拒否されます。deny:s,r#[all]#public: grant:s,r#[all]#public: |
attributesコンポーネントは、エントリを選択することで権限をエントリ全体に適用するか、特定の属性を識別することで一部またはすべての属性に適用するかが決定されるため、permissionsコンポーネントと強力にリンクされています。
エントリ全体またはその属性に適用する権限は、実行可能なLDAP操作のタイプに対応しています。それぞれのLDAPアクセス権限は独立しており、ある権限を保持していても別の権限が付与されていることにはなりません。ACLを構成している場合、同じ場所に関連する2つのACLを保持することがよくあります。これは、個々の属性の権限(属性権限)と、エントリ自体の権限(エントリ権限)を分離する必要から生じます。属性権限には、*(すべての属性を表す)のattributeコンポーネント、または属性権限を適用するリスト属性が必要です。エントリ権限には、エントリのattributeコンポーネントが必要です。
構造型アクセス権限
構造型アクセス権限は、仮想ディレクトリ・ツリーのエントリ全体を対象としています。次に、各構造型アクセス項目権限のリストと説明を示します。
add (a): 指定より下の場所へのエントリの追加が許可されます。クライアント・アプリケーションがエントリを追加するには、少なくとも各objectclassの必須属性を追加するためのmake属性権限も付与されている必要があります。
delete (d): エントリ内の既存の属性権限にかかわらず、エントリをDITから削除することが許可されます。
rename DN (n): エントリの名前の変更または移動が許可されます。
browse DN (b): エントリの参照が許可されます。付与されている場合、エントリの名前が明示的に指定されていないディレクトリ操作を使用してエントリにアクセスできます。
return DN (t): エントリのDNをLDAP操作の結果で公開することが許可されます。
新規相対DN(RDN)で名前が変更されるエントリには、rename DNを付与する必要があります。ただし、下位エントリがある場合には、その識別名も間接的に変更されることを考慮する必要があります。エントリ名の変更では、RDN自体の属性など、含まれる属性の前提条件権限は不要です。
さらに、名前の変更を行うには2つの条件があることに注意してください。(1)上位DNの名前は変更されません(つまり、文字どおりRDNの名前が変更されます)。また、(2)名前の変更によりDNおよびDITの下位項目が移動され、エントリの上位DNが新しくなります(つまり移動されます)。
どのタイプの名前の変更の場合でも、移動されるDNにはrenameDN権限が必要で、(その下に新しいエントリが配置される)ターゲットDNにはaddおよびrenameDNの両方の権限が必要です。
その他の要件で禁止されていないかぎり、ディレクトリのデータを完全に取得できるよう大部分の場所にbrowseDNおよびreturnDNエントリ権限を指定するのが一般的です。同様に、データの変更が必要になる可能性がある場所には、writeおよびobliterate権限の両方を付与するのが一般的です。
コンテンツ・アクセス権限
コンテンツ・アクセス権限は、エントリ属性を対象としています。次に、各コンテンツ・アクセス項目権限のリストと説明を示します。
read: 読取りまたは検索操作で属性値を読み取ることが許可されます。
write: 変更操作で属性値を変更または追加することが許可されます。
obliterate: 変更操作で属性値を削除することが許可されます。
search: 検索操作で指定した値に関して属性を検索することが許可されます。
compare: 比較操作で属性を比較することが許可されます。
make/create: 指定されたエントリよりも下の新規エントリに新しい属性を作成することが許可されます。
make/create属性権限は、エントリの作成時にエントリのすべての属性に必要です。特に、addエントリ権限と関連付けられます。
その他の要件で禁止されていないかぎり、ディレクトリのデータを完全に取得できるよう大部分の場所にsearch、readおよびcompare属性権限を指定するのが一般的です。同様に、データの変更が必要になる可能性がある場所には、writeおよびobliterate権限の両方を付与するのが一般的です。
writeおよびobliterateには追加操作との関連はなく、makeには変更操作との関連はありません。新規エントリが存在しないため、その作成に必要なaddおよびmake権限を新規エントリの親に付与する必要があります。この点は、変更対象のエントリに付与する必要のあるwriteおよびobliterateとは異なります。make権限はwriteおよびobliterate権限とは異なるため、エントリへの新しい子の追加に必要な権限や、同じエントリの既存の子の変更に必要な権限との競合はありません。
変更操作を使用して属性値を置き換えるには、属性に対してエントリのwriteおよびobliterate権限の両方が有効化されている必要があります。
ACLのサブジェクトで、その適用対象が決定されます。Oracle Virtual Directoryでは、予期される様々なサブジェクト・タイプが利用されます。それによって、ユーザー指定であるかプロキシ・アカウント(binddnなど)からであるかに関係なくクライアント資格証明が使用され、次の条件で適用されます。
特定のDN: クライアントDNの資格証明を、ACL設定に指定した値と比較して一致した場合にACLが適用されます。
this: 資格証明がアクセス対象のエントリの資格証明と一致するクライアントに適用されます。
subtree: ACLは、クライアント資格証明の期限が切れた場合、またはサブジェクトで指定されたDNより下に適用されます。
グループ: subjectコンポーネントによって指定されたDNが検出され、クライアント資格証明がgroupOfUniqueNames、groupOfNames、groupOfUniqueURLsの3つのオブジェクト・クラスのいずれかによって決定されたグループのメンバーである場合にACLが適用されます。最初の2つのタイプのグループによって、ユーザーの静的なリストが指定されます。groupOfUniqueNamesでは、uniquemembers属性がクライアント資格証明に一致している必要があります。groupOfNamesでは、member属性がクライアント資格証明に一致している必要があります。3つ目のグループ・タイプgroupOfUniqueURLsでは、動的グループが処理され、memberurl属性の値によって指定された検索を実行して取得されたDNの少なくとも1つと、クライアント資格証明が一致している必要があります。
public: 認証されているかどうかにかかわらず、ACLはディレクトリに接続されているすべてのクライアントに適用されます。
IPアドレス: クライアントIPアドレスを、ACL設定に指定した値と比較して一致した場合にACLが適用されます。
次に、それぞれのACLサブジェクトの注意事項と例を示します。
特定のDN
特定のDNサブジェクトは、プロキシbinddnなどの特定のクライアントに、DITの一部に対するアクセス権を付与または拒否するために使用されます。ユーザーが匿名でバインドすると、サーバーにプロキシ資格証明が送信されるため、プロキシbinddnにDITの機密エントリや属性の表示または変更を許可するのは賢明ではありません。
次に例を示します(binddnがcn=serviceの場合)。
| ACL1 | ACL2 | |
|---|---|---|
| location | ou=security, o=oracle.com | ou=security, o=oracle.com |
| scope | サブツリー | サブツリー |
| rights | deny | deny |
| permissions | read, search, make, write, obliterate | add, delete, renameDN, browseDN, returnDN |
| attributes | [all] | [entry] |
| subject | specificDN=cn=service | specificDN=cn=service |
this
thisサブジェクトは、DIT内に配置されている指定された任意のクライアントに、userpassword、postaladdress、telephonenumberなど個人情報の読取りおよび変更の両方を行う権限を付与するために使用されます。通常、一般のpublicにそのようなアクセスを拒否するために、別のACLも使用されます。
次に例を示します。
| ACL1 | ACL2 | ACL3 | |
|---|---|---|---|
| location | o=oracle.com | o=oracle.com | o=oracle.com |
| scope | サブツリー | サブツリー | サブツリー |
| rights | deny | grant | grant |
| permissions | read, compare | read | write, obliterate |
| attributes | userpassword | userpassw | userpassword, postaladdress |
| subject | public | this | this |
subtree
subtreeサブジェクトは、クライアント資格証明がDITのサブツリー内のどこからでも検出される場合に便利です。subtreeには、関連性の強いブランチの特権アカウントのみが含まれている場合があります。
次に例を示します。
cn=jbowen, ou=eng_admins, ou=admins, ou=security, o=oracle.com
前にDNのあるadminを認証する必要があります。その他の同じような権限を持つadminsとともにこのadminを認証し、サブツリーを使用するACL実装の例は次のようになります。
| ACL1 | ACL2 | |
|---|---|---|
| location | o=oracle.com | o=oracle.com |
| scope | サブツリー | サブツリー |
| rights | grant | grant |
| permissions | read, search, make, write, obliterate | add, delete, renameDN, browseDN, returnDN |
| attributes | [all] | [entry] |
| subject | subtree=ou=admins, ou=security, o=oracle.com | subtree=ou=admins, ou=security, o=oracle.com |
group
groupサブジェクトは、認証を実行するエントリをDIT内のどこで検索すればよいかを指定する際の柔軟性が最も高いため、特定の権限および許可を様々なカテゴリのユーザーに付与する場合に最も多く選択されます。
たとえば、資格証明を持つadminの場合、cn=jbowen, ou=admins, ou=security, o=oracle.comを認証する必要があります。オブジェクト・クラスがgroupOfURLsで属性がmemberURLのGroupサブジェクトを使用してこのadminを認証する、ACLとエントリの組合せの例は次のようになります。
| ACL1 | ACL2 | |
|---|---|---|
| location | o=oracle.com | o=oracle.com |
| scope | サブツリー | サブツリー |
| rights | grant | grant |
| permissions | read, search, make, write, obliterate | add, delete, renameDN, browseDN, returnDN |
| attributes | [all] | [entry] |
| subject | group=ou=sales, ou=depts, o=oracle.com | group=ou=sales, ou=depts, o=oracle.com |
グループを指定するオブジェクト・クラスに対して調査されるsubjectコンポーネントのDNは、次のようになります。
dn: ou=sales, ou=depts, o=oracle.com objectclass: organizationalUnit objectclass: groupofurls ou=sales memberurl: ldap:///ou=admins,ou=security,o=oracle.com?sub?(objectclass=inetOrgPerson)
上のDNでは、memberurl属性によって指定されているLDAP検索には少なくとも、クライアント資格証明を認証する次のDNが含まれます。
dn: cn=jbowen, ou=admins, ou=security, o=oracle.com objectclass: inetOrgPerson cn: jbowen userpassword: xyz123
public
通常grantとともにPublicを使用するACLでは、考えられる最も広い範囲のクライアント・ベースに対してDITへのアクセス権が付与されます。通常、有効範囲がentryの場所[root]に対して実行されます。また、特に有効範囲がentryの別のACLおよび有効範囲がsubtreeのACLが適用されているツリーのベースに対しても実行されます。一般的に、ツリーの特定部分、およびuserpasswordなどの特定の属性がpublicによって表示または変更されるのを制限するために、その他のACLも追加されます。
次に例を示します。
| ACL1 | ACL2 | ACL3 | ACL4 | |
|---|---|---|---|---|
| location | [root] | [root] | o=oracle.com | o=oracle.com |
| scope | entry | entry | サブツリー | サブツリー |
| rights | grant | grant | grant | grant |
| permissions | search, read | browse, return | search, read | browse, return |
| attributes | [all] | [entry] | [all] | [entry] |
| subject | public | public | public | public |
IPアドレス
クライアントIPアドレスを、ACL設定に指定した値と比較して一致した場合にACLが適用されます。IPアドレスの値にはIPマスクを使用できます。
次に例を示します。
| ACL1 | ACL2 | |
|---|---|---|
| location | ou=security, o=oracle.com | ou=security, o=oracle.com |
| scope | サブツリー | サブツリー |
| rights | deny | deny |
| permissions | read, search, make, write, obliterate | add, delete, renameDN, browseDN, returnDN |
| attributes | [all] | [entry] |
| subject | specificIP=192.168.1.* | specificIP=192.168.1.* |
次に、Oracle Virtual DirectoryによりACLがどのように適用されるかをまとめます。
調査対象の属性に関連する最初のACLは、一致したACLと呼ばれます。一致したACLは、Oracle Virtual Directoryが順序を下げていくと最も優先度の高い適用を推測し、後続のACLをすべて評価します。
後続のACLに指定された有効範囲がより具体的である場合、つまりDITの階層がより深い場合、またはサブジェクト・タイプがpulicからthisに変更される場合など、一致したACLの適用が変更されるのはいくつかの条件のみです。
一致したACLおよび後続のACLの有効範囲が同一で、いずれかのACLで調査対象の属性に対する権限が拒否されている場合は、Oracle Virtual DirectoryによりACLのアクセスが拒否されます。
Oracle Virtual Directoryは、すべてのACLを評価して適用が決定されるまで、リストの最後のACLまで下がりながらリストされているすべてのACLを順番に評価します。
