ネットワーク・アドレス情報の管理

3 ネットワーク・アドレス情報の管理

Oracle Net Servicesのネットワーク・アドレス情報を、ローカル・ファイルや集中化されたディレクトリ・サーバーに格納する方法について説明します。ネットワーク・アドレス情報は、ローカル管理を使用してネットワーク内の各コンピュータのtnsnames.oraファイルに格納されます。また、集中管理を使用して、集中化したディレクトリ・サーバーに格納されます。

親トピック: Oracle Net Servicesの理解

3.1 ローカル管理の使用

ローカル管理を使用するときは、ネットワーク・コンピュータは表3-1で説明されているファイルで構成されます。このファイルはローカルにコンピュータに格納されます。

表3-1 ローカル管理で使用されるOracle Net構成ファイル

構成ファイル	説明
`tnsnames.ora`	このファイルは、主にクライアント上にあり、接続記述子にマップされたネットワーク・サービス名を含んでいます。このファイルは、ローカル・ネーミング・メソッドに使用されます。
`sqlnet.ora`	このファイルは、クライアントとデータベース・サーバーのコンピュータに配置され、内容は次のとおりです。未修飾サービス名またはネットワーク・サービス名に追加するクライアント・ドメイン名前の解決時にクライアントが使用するネーミング・メソッドの順序使用するロギング機能とトレース機能接続のルート外部ネーミング・パラメータ Oracleセキュリティ・パラメータデータベース・アクセス制御パラメータ
`listener.ora`	このリスナーに関する構成ファイルは、データベース・サーバーに配置され、内容は次のとおりです。接続要求を受け付けるプロトコル・アドレスリスニングの対象とするデータベース・サービスと非データベース・サービスリスナーが使用する制御パラメータ
`cman.ora`	この構成ファイルは、Oracle Connection Managerが実行されるコンピュータ上にありますが、これには次のコンポーネントが含まれます。リスニング・エンドポイントアクセス制御ルール・リストパラメータ・リスト各Oracle Connection Manager構成は、1つの名前-値(NV)文字列内にカプセル化されており、その文字列は、前述のコンポーネントで構成されています。

構成ファイルは通常、読取り専用OracleホームのORACLE_HOME/network/adminディレクトリとORACLE_BASE_HOME/network/adminディレクトリに作成されます。ただし、構成ファイルは他のディレクトリに作成される可能性があります。Oracle Netは、他のディレクトリに構成ファイルがないか確認します。たとえば、tnsnames.oraファイルの確認順序は次のとおりです。

環境変数TNS_ADMINで指定されているディレクトリ。
TNS_ADMIN環境変数が設定されていないか、ファイルがTNS_ADMINディレクトリにない場合、Oracle NetはORACLE_HOME/network/adminディレクトリ内のファイルをチェックします。読取り専用Oracleホームの場合、Oracle NetはORACLE_BASE_HOME/network/adminディレクトリを確認します。

ノート:

Microsoft Windowsでは、TNS_ADMIN環境変数はプロセスの環境内で設定されている場合に使用されます。TNS_ADMIN環境変数が環境内で定義されていない場合、またはプロセスが環境を持たないサービスである場合、Microsoft WindowsではレジストリでTNS_ADMINパラメータがスキャンされます。

関連項目:

gsm.oraファイルの詳細は、Oracle Database Global Data Services概要および管理ガイドを参照してください。
オペレーティング・システム固有のドキュメント

親トピック: ネットワーク・アドレス情報の管理

3.2 集中管理用のディレクトリ・サーバーの使用

Oracleネットワークでディレクトリ・サーバーを使用すると、そのディレクトリ・サーバーは、ネットワーク内のOracle Databaseに対するグローバル・データベース・リンクをネットワーク・サービス名として管理します。ユーザーとプログラムは、グローバル・リンクを使用して、対応するデータベース内のオブジェクトにアクセスできます。

Oracle Net Servicesは、接続識別子を格納する主な方法の1つとして、集中化されたディレクトリ・サーバーを使用します。クライアントは、接続文字列の中で接続識別子を使用し、ディレクトリ・サーバーはこの接続識別子を接続記述子に解決して、クライアントに戻します。この機能は、ディレクトリ・ネーミングと呼ばれます。このようなインフラストラクチャによって、ネットワークでのリソースの管理および構成のコストが削減されます。

Oracle Internet Directoryによって、分散Oracleネットワークの管理および構成に関する集中化されたメカニズムが提供されます。このディレクトリ・サーバーによって、クライアント側とサーバー側にあるローカルのtnsnames.oraファイルを置換できます。

図3-1では、ディレクトリ・サーバーによって接続識別子を解決しているクライアントを示します。

クライアントは、ディレクトリ・サーバーに接続して接続識別子を接続記述子に解決します。
ディレクトリ・サーバーは、この接続識別子を解決して、クライアントに接続記述子を渡します。
クライアントは、この接続記述子を使用して、リスナーに接続要求を送信します。

図3-1 ディレクトリ・サーバーを使用して接続識別子を解決するクライアント

「図3-1 ディレクトリ・サーバーを使用して接続識別子を解決するクライアント」の説明

ノート:

Java Database Connectivity(JDBC)ドライバは、ディレクトリ・ネーミングをサポートしています。詳細は、『Oracle Database JDBC開発者ガイド』を参照してください。

この項では、次の項目について説明します。

ディレクトリ情報ツリーの理解
Oracleコンテキストの理解
Oracleコンテキストの下にあるエントリでは、ディレクトリ・ネーミングなど、ディレクトリで利用可能な様々な機能がサポートされています。
ネット・サービス別名エントリの理解
ディレクトリ・サーバーのエントリを追加または変更できるユーザー
ディレクトリ・ネーミングを使用したクライアント接続
ディレクトリ・サーバーで名前参照を実行する必要がある大半のクライアントは、匿名認証を使用してディレクトリ・サーバーにアクセスします。
ディレクトリ・サーバーを使用するときの考慮事項
Microsoft Active Directoryにおけるディレクトリ・ネーミング・サポートの制約

親トピック: ネットワーク・アドレス情報の管理

3.2.1 ディレクトリ情報ツリーの理解

ディレクトリ・サーバーは、ディレクトリ情報ツリー(DIT)と呼ばれる階層化されたネームスペース構造に情報を格納します。このツリーの各ノードは、エントリと呼ばれます。Oracle Net Servicesは、ツリー構造とツリー内の特定のエントリを使用します。DITは、一般にドメイン・ネーム・システム(DNS)構造などの既存のドメイン構造や地理的および組織的な構造と整合されます。

図3-2では、DNSドメイン・コンポーネントに従って構築されたDITを示します。

図3-2 DNSドメイン・コンポーネントDIT

「図3-2 DNSドメイン・コンポーネントDIT」の説明

図3-3では、国、組織および組織単位に従って構築されたDITを示します。この構造は、一般にX.500 DITと呼ばれています。

図3-3 X.500 DIT

「図3-3 X.500 DIT」の説明

たとえば、図3-4について考えます。cn=salesエントリとcn=db1エントリは、ネットワーク・サービス名とデータベース・サービスをそれぞれ表します。cn=salesとcn=db1の下に存在する別のエントリには、接続記述子情報が含まれます。それらのエントリは、この図では示されていません。cn=salesエントリとcn=db1エントリによって、クライアントは、接続文字列のCONNECT username@salesおよびCONNECT username@db1を使用してデータベースに接続できます。

図3-4 データベース・サービスとDITのネット・サービス・エントリ

「図3-4 データベース・サービスとDITのネット・サービス・エントリ」の説明

各エントリは、識別名(DN)によって一意に識別されます。DNは、ディレクトリ・サーバーの階層内に対象のエントリが存在する場所を正確に示します。db1のDNは、dn:cn=db1,cn=OracleContext,dc=jp,dc=example,dc=comです。salesのDNは、dn:cn=sales,cn=OracleContext,dc=jp,dc=example,dc=comです。DNの形式では、DITの最下位コンポーネントを左側に置いてから、DITを上方向に徐々に移動します。

各DNは、相対識別名(RDN)の列で構成されています。RDNは、cnなどの属性、db1またはsalesなどの値で構成されています。db1のRDNはcn=db1であり、salesのRDNはcn=salesです。属性とその値はエントリを一意に識別します。

ドメイン・コンポーネント・ネームスペースの完全修飾名
X.500ネームスペースの完全修飾名
エントリの相対名の使用
クライアントがデフォルトのレルムOracleコンテキストで構成されている場合、エントリを相対名で識別することが可能であり、サービスを共通名で参照できます。相対名を使用できるのは、クライアントのOracleホームでデフォルトのOracleコンテキストとして構成されたOracleコンテキスト内に、エントリがある場合です。
エントリの完全修飾名の使用

親トピック: 集中管理用のディレクトリ・サーバーの使用

3.2.1.1 ドメイン・コンポーネント・ネームスペースの完全修飾名

ドメイン・コンポーネント・ネームスペースの場合、クライアントに定義されたデフォルトのディレクトリ・エントリは、必ず次のいずれかの形式にする必要があります。

dc[,dc][...]
ou,dc[,dc][...]

前述の構文で、[dc]はオプションのドメイン・コンポーネントを表し、[...]は追加のドメイン・コンポーネント・エントリを表し、ouは組織単位エントリを表します。

クライアントが接続識別子で使用する完全修飾名は、必ず次のいずれかの形式である必要があります。

cn.dc[.dc][...]
cn[.ou]@dc[.dc][...]

前述の構文で、[cn]はOracle Netエントリを表しています。

例3-1 組織単位を使用した完全修飾名の使用

cn=sales,cn=OracleContext,dc=jp,dc=example,dc=comというDNを持つデータベース・オブジェクトsalesのエントリが格納されているディレクトリ・サーバーについて考えます。この例では、クライアントにsales.jp.example.comの接続識別子が必要です。

cn=sales,cn=OracleContext,ou=mktg,dc=jp,dc=example,dc=comというDNを持つデータベース・オブジェクトsalesを含んでいる同様のエントリについて考えます。

ドメイン・コンポーネントは必ず組織単位から分離されている必要があるため、クライアントはcn.ou@dc.dc.dcという形式を使用する必要があります。このクライアントは、接続識別子をsales.mktg@jp.example.comにする必要があります。

図3-5に前述の例を示します。

図3-5 ドメイン・コンポーネント・ネームスペースの完全修飾名

「図3-5 ドメイン・コンポーネント・ネームスペースの完全修飾名」の説明

親トピック: ディレクトリ情報ツリーの理解

3.2.1.2 X.500ネームスペースの完全修飾名

X.500ネームスペースの場合、クライアントに定義されたデフォルトのディレクトリ・エントリは、必ず次のいずれかの形式にする必要があります。

[ou],o
[ou],o,c

前述の形式で、[ou]はオプションの組織単位名を表し、oは組織を表し、cは国を表します。

クライアントが接続識別子として使用する完全修飾名は、必ず次のいずれかの形式である必要があります。

cn[.ou].o
cn[.ou].o.c

前述の形式で、cnはOracle Netエントリを表しています。

たとえば、ディレクトリにcn=sales,cn=OracleContext,ou=mktg,o=example,c=jpというDNを持つデータベース・オブジェクトsalesが格納される場合、クライアントは接続識別子sales.mktg.example.jpを必要とします。図3-6にこの例を示します。

図3-6 X.500ネームスペースの完全修飾名

「図3-6 X.500ネームスペースの完全修飾名」の説明

親トピック: ディレクトリ情報ツリーの理解

3.2.1.3 エントリの相対名の使用

クライアントがデフォルトのレルムOracleコンテキストで構成されている場合、エントリを相対名で識別することが可能であり、サービスを共通名で参照できます。相対名を使用できるのは、クライアントのOracleホームでデフォルトのOracleコンテキストとして構成されたOracleコンテキスト内に、エントリがある場合です。

図3-7に示すように、DNがdn:cn=sales,cn=OracleContext,o=example,c=usで、salesというデータベースのエントリが格納されているディレクトリ・サーバーについて考えます。クライアントがcn=OracleContext,o=example,c=usというデフォルトのレルムOracleコンテキストで構成されている場合の接続識別子は、salesです。

図3-7 相対ネーミング

「図3-7 相対ネーミング」の説明

ノート:

JDBC OCIドライバは、完全修飾ネーミングと相対ネーミングの両方をサポートしています。JDBC Thinドライバは、完全なDNが使用される場合にのみ、完全修飾ネーミングをサポートします。

関連項目

Oracle Database JDBC開発者ガイド

親トピック: ディレクトリ情報ツリーの理解

3.2.1.4 エントリの完全修飾名の使用

図3-7と同じディレクトリ構造について考えます(ただし、クライアントのOracleホームは、cn=OracleContext,o=example,c=jpというデフォルトのレルムOracleコンテキストで構成されています)。

クライアントは、ディレクトリ・サーバー内のsalesの位置とは一致しないデフォルトのOracleコンテキストで構成されているため、salesを使用する接続文字列は機能しません。そのかわりに、クライアントは必ず次のいずれかの方法を使用して、salesの位置を特定する必要があります。

エントリの完全なDNを接続文字列に使用します。たとえば:
```
CONNECT username@"cn=sales,cn=OracleContext,o=example,c=us"
Enter password: password
```
JDBC Thinドライバは、完全なDNが使用される場合にのみ、完全修飾ネーミングをサポートします。ただし、多くのアプリケーションで、DNの使用はサポートされていません。
エントリは完全修飾DNSスタイル名で参照できます。完全修飾DNSスタイル名は、ディレクトリ・ネーミング・アダプタによってLDAPディレクトリにあるデータベース・オブジェクトの完全x.500 DNにマッピングされます。たとえば:
```
CONNECT username@sales.example.us
Enter password: password
```

ノート:

JDBC OCIドライバは、完全修飾ネーミングをサポートしています。JDBC Thinドライバは、完全なDNが使用される場合にのみ、完全修飾ネーミングをサポートします。詳細は、『Oracle Database JDBC開発者ガイド』を参照してください。

親トピック: ディレクトリ情報ツリーの理解

3.2.2 Oracleコンテキストの理解

Oracleコンテキストの下にあるエントリは、ディレクトリ・ネーミングなど、ディレクトリで利用可能な様々な機能をサポートしています。

図3-8で、エントリdb1とsalesはcn=OracleContextの下にあります。このエントリは、Oracleコンテキストと呼ばれる特殊なRDNです。

図3-8 DITのOracleコンテキスト

「図3-8 DITのOracleコンテキスト」の説明

ディレクトリの構成時にデフォルトのOracleコンテキストを設定します。クライアントは、このOracleコンテキストをデフォルトの場所として使用し、このディレクトリ・サーバー内で接続識別子を検索します。Oracle Internet Directoryでは、DNがdn:cn=OracleContextであれば、DITのルートにあるOracleコンテキストがアイデンティティ管理レルムにあるデフォルトのOracleコンテキストをポイントします。アイデンティティ管理レルムは、同じ管理ポリシーに基づいて集められたアイデンティティです。このOracleコンテキストは、レルムOracleコンテキストと呼ばれます。別のOracleコンテキストを使用するように設定されていないかぎり、クライアントはこのレルム固有のOracleコンテキストを使用します。

デフォルトのOracleコンテキストは、接続文字列に影響を与えます。たとえば、クライアントがdb1とsalesのエントリに頻繁にアクセスする必要がある場合、デフォルトとして適切なOracleコンテキストは、dc=jp,dc=example,dc=comなどになります。クライアントのディレクトリ・エントリが、サービスの存在するディレクトリ・エントリと一致しない場合、クライアントは、エントリの完全修飾名を接続文字列で指定する必要があります。詳細は、「ディレクトリ・ネーミングを使用したクライアントの接続」を参照してください。

ノート:

接続文字列で、RDN cn=OracleContextを明示的に指定する必要はありません。

関連項目

Oracle Fusion Middleware Oracle Internet Directoryの管理

親トピック: 集中管理用のディレクトリ・サーバーの使用

3.2.3 ネット・サービス別名エントリの理解

ディレクトリ・ネーミングでは、データベース・サービスとネットワーク・サービス名のエントリに加えて、ネットワーク・サービス別名のエントリを作成できます。ネットワーク・サービス別名は、ネットワーク・サービス名またはデータベース・サービスの代替名です。ネットワーク・サービス別名のエントリには、接続記述子情報は含まれていません。ネット・サービス別名が参照するのは、別名のエントリの場所です。クライアントがネットワーク・サービス別名のディレクトリ検索を要求すると、ディレクトリは、エントリがネットワーク・サービス別名であることを判断し、あたかも参照されたエントリであるかのように検索を完了します。たとえば、図3-9では、ネットワーク・サービス別名db1aliasがデータベース・サービスdb1に対して作成されています。db1alias(CONNECT username@db1alias)を使用してデータベース・サービスに接続する場合、実際にはdb1の接続記述子情報に解決されて使用されます。

図3-9 ディレクトリ・サーバーでのネット・サービス別名のdb1alias

「図3-9 ディレクトリ・サーバーでのネット・サービス別名のdb1alias」の説明

ネットワーク・サービス別名の使用方法はいくつかあります。図3-9に示すように、ネットワーク・サービス別名は、クライアントがネットワーク・サービス名を別の名前で参照する方法として役立ちます。もう1つの使用方法は、データベース・サービスの1つのOracleコンテキストでネットワーク・サービス別名を使用し、別のOracleコンテキストでネットワーク・サービス名を使用する方法です。これにより、データベース・サービスまたはネットワーク・サービス名を一度ディレクトリ・サーバーに定義できますが、他のOracleコンテキストを使用するクライアントから参照できます。

図3-10では、データベース・サービスdb1はdc=jp,dc=example,dc=comに常駐しています。db1という名前のネットワーク・サービス別名がdc=us,dc=example,dc=com内に作成されます。これによって、日本と米国の両方のクライアントは接続文字列CONNECT username@db1を使用できます。ただし、米国のクライアントはCONNECT username@db1.jp.example.comと指定する必要があります。

図3-10 ディレクトリ・サーバーでのネット・サービス別名のdb1

「図3-10 ディレクトリ・サーバーでのネット・サービス別名のdb1」の説明

親トピック: 集中管理用のディレクトリ・サーバーの使用

3.2.4 ディレクトリ・サーバーのエントリを追加または変更できるユーザー

データベース・サービス・エントリは、インストール時またはインストール後に構成されます。次にOracle Enterprise Manager Cloud Controlまたは Oracle Net Managerを使用して、データベース・サービス・エントリのOracle Net属性を変更できます。また、これらのツールを使用すると、ネットワーク・サービス名とネットワーク・サービス別名のエントリを作成できます。

これらの構成ツールを使用するには、ルートOracleコンテキストを持つDIT構成とアイデンティティ管理レルムが存在する必要があります。ディレクトリ管理者は、Oracle Internet Directoryコンフィギュレーション・アシスタントを使用してこの構成を作成します。デプロイメントによっては、ディレクトリ管理者は、さらに別のOracleコンテキストを作成する必要があります。通常、その他のOracleコンテキストは大規模なサイトの細分化、またはテスト環境からの本番環境の分離に使用されます。

次に示すように、特定のツールは特定のグループによって使用されるため、ツールを使用するにはそのグループのメンバーである必要があります。

Database Configuration Assistantを使用してデータベース・サービスを作成するには:
- OracleDBCreatorsグループ (cn=OracleDBCreators,cn=OracleContext...)
- OracleContextAdminsグループ(cn=OracleContextAdmins,cn=Groups,cn=OracleContext...)
Oracle Net Managerを使用してネットワーク・サービス名またはネットワーク・サービス別名を作成するには:
- OracleNetAdminsグループ(cn=OracleNetAdmins,cn=OracleContext...)
- OracleContextAdminsグループ

OracleNetAdminsグループの所有者はグループ自体です。OracleNetAdminsグループのメンバーには、Oracle Netのオブジェクトと属性に対する作成、変更および読取りのアクセス権限があります。また、グループにメンバーを追加または削除したり、OracleNetAdminsグループの所有者となるグループを追加または削除したりすることもできます。

OracleNetAdminsグループのメンバーは、他のメンバーをOracleNetAdminsグループに追加したり、グループから削除できます。別のグループがOracleNetAdminsのメンバーを追加または削除できるようにする場合は、OracleNetAdminsグループの所有者属性を別のグループに変更します。所有者は、個別のユーザー・エントリではなく、グループ・エントリである必要があります。このグループ・エントリは、LDAPスキーマ・オブジェクト・クラスのGroupOfUniqueNamesとorclPriviledgeGroupで構成されたグループ・エントリです。

OracleContextAdminsグループは、Oracleコンテキストのスーパーユーザーのグループです。OracleContextAdminsグループのメンバーは、サポートされているすべてのタイプのエントリをOracleコンテキストに追加できます。

Oracleコンテキストを作成したディレクトリ・ユーザーは、これらのグループに自動的に追加されます。その他のユーザーは、ディレクトリ管理者によってこれらのグループに追加されます。

関連項目:

Oracle Net Managerの詳細は、「ディレクトリ・ネーミング・メソッドの構成」を参照してください
Database Configuration Assistantを使用してデータベース・サービスを登録する方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

親トピック: 集中管理用のディレクトリ・サーバーの使用

3.2.5 ディレクトリ・ネーミングを使用したクライアントの接続

ディレクトリ・サーバーで名前参照を実行する必要がある大半のクライアントは、匿名認証を使用してディレクトリ・サーバーにアクセスします。

参照を実行するには、対象のディレクトリ・サーバーで匿名認証が可能である必要があります。通常、ディレクトリ・サーバーでは、デフォルトで匿名認証が可能ですが、以前のリリースのOracle Internet Directoryなどの一部のディレクトリ・サーバーでは、匿名アクセスが可能になるようにディレクトリの構成が必要です。

エントリを検索するには、クライアントはエントリが常駐するディレクトリ・サーバーを見つける必要があります。クライアントは、次の2つのいずれかの方法でディレクトリ・サーバーを見つけます。

DNSを使用した動的な方法。この場合、ディレクトリ・サーバーの場所に関する情報は、中央のドメイン・ネーム・サーバーで保存および管理されます。クライアントは要求を処理するときに、DNSからこの情報を取り出します。
静的には、Oracle Internet Directoryコンフィギュレーション・アシスタントによって作成され、クライアント・ホストに保存されているディレクトリ・サーバー使用ファイル(ldap.ora)で検出します。

ディレクトリが見つかると、ルートにあるOracleコンテキストからクライアントは、レルムOracleコンテキストに送られます。

クライアントは、他のネーミング・メソッドを使用する場合と同様に、接続識別子を使用してデータベースに接続します。接続識別子は、データベース・サービス名、ネットワーク・サービス名、ネットワーク・サービス別名のいずれかです。デフォルトのOracleコンテキストがエントリの場所になる場合、これらは共通名(相対名)で参照できます。そうでない場合は、接続識別子に完全修飾名または識別名が必要になります。

親トピック: 集中管理用のディレクトリ・サーバーの使用

3.2.6 ディレクトリ・サーバーを使用するときの考慮事項

ディレクトリ・サーバーを使用するときは、次の考慮事項を検討する必要があります。

親トピック: 集中管理用のディレクトリ・サーバーの使用

3.2.6.1 パフォーマンスに関する考慮事項

接続識別子は、アクセス対象のすべてのクライアントに対して、1つのディレクトリ・サーバーに格納されます。クライアント数によっては、ディレクトリ・サーバーに大量の負荷がかかる場合があります。

接続識別子の参照時には、名前は特定のOracleコンテキストのもとで検索されます。ユーザーは比較的迅速なパフォーマンスで検索を実行できるため、データベースの接続時間は影響を受けません。参照の有効範囲を考慮すれば、参照時間が1秒を超えると、ユーザーは接続時間が長く感じるようになります。

ネットワーク・トポロジを変更したり、レプリケーションを実装すれば、パフォーマンスの問題を解決できます。

関連項目:

パフォーマンス問題の解決の詳細は、ディレクトリ・サーバーのベンダーのマニュアルを参照してください。

親トピック: ディレクトリ・サーバーを使用するときの考慮事項

3.2.6.2 セキュリティに関する考慮事項

管理クライアントはディレクトリ・サーバーのエントリを作成したり変更できるため、セキュリティは必要不可欠です。この項では、セキュリティに関連する項目を取り上げます。

認証方法
クライアントは、接続文字列名の解決やディレクトリ・エントリの管理など、実行されるタスクに応じて異なる認証方式を使用します。
アクセス制御リスト

親トピック: ディレクトリ・サーバーを使用するときの考慮事項

3.2.6.2.1 認証方式

クライアントは、接続文字列名の解決やディレクトリ・エントリの管理など、実行されるタスクに応じて異なる認証方式を使用します。

ディレクトリ・サーバー内の情報について参照を実行するクライアントは、通常、匿名認証を使用します。名前参照時にLDAPバインドを認証するようにクライアントを構成できます。ネットワーク・サービス・データを保護するか、またはディレクトリへの匿名バインドを無効にする必要があるサイトは、名前参照時の認証にウォレットを使用するようにクライアントを構成する必要があります。

これらのクライアントについて、sqlnet.oraファイルで次のパラメータを設定する必要があります。
```
names.ldap_authenticate_bind = TRUE
wallet_location = location_value
```
ディレクトリ・サーバー・エントリを管理するクライアントは、ディレクトリ・サーバーで認証を実行します。Database Configuration AssistantやOracle Net Managerを使用すると、エントリの追加や修正が可能です。適正な権限を持つ認証ユーザーのみがエントリを変更できます。次のいずれかの認証方式を使用します。
- 簡易認証
  
  クライアントは、DNおよびパスワードを使用して、クライアント自体をディレクトリ・サーバーに認証要求します。サーバーは、クライアントが送信したDNおよびパスワードが、ディレクトリ・サーバーに格納されているDNおよびパスワードと一致していることを確認します。
- 厳密認証
  
  クライアントは、Transport Layer (TLS)で使用可能な公開キー暗号によって、ディレクトリ・サーバーに対して自分自身を識別します。公開キー暗号では、メッセージの送信側が受信側の公開キーを使用してメッセージを暗号化します。メッセージが送達されると、受信側は、受信側の秘密キーを使用して、メッセージを復号化します。

関連項目

TLSプロトコル付きTCP/IPについて

親トピック: セキュリティに関する考慮事項

3.2.6.2.2 アクセス制御リスト

クライアントがディレクトリ・サーバー内の情報に対して読取り、変更または追加をできるかどうかを判断するときは、認証とアクセス制御リスト(ACL)を併用します。ACLの指定内容は、次のとおりです。

ユーザーがアクセス可能なエントリ。
エントリへのアクセスに使用する認証方式。
アクセス権、またはユーザーがオブジェクトに対して可能な処理(読取り、書込みなど)。

ACLは、ユーザーのグループに対して作成されます。Oracleコンテキストの作成時には、OracleDBCreators、OracleNetAdminsおよびOracleContextAdminsの各グループが作成されます。

Oracle Net Configuration Assistantを使用してOracleコンテキストを作成するユーザーは、これらのグループの先頭に自動的に追加されます。

表3-2では、これらのグループ、匿名ユーザー、およびディレクトリ・サーバー内のOracle Netエントリに対する関連内容のACL要件に応じて説明します。

表3-2 ユーザー・グループのACL要件

グループ	ACL要件
匿名ユーザー	匿名ユーザーは、ディレクトリ・サーバー内のすべてのOracle Net属性とオブジェクトへの読取りアクセス権を持ちます。匿名ユーザーのこれらのオブジェクトに対する読取りアクセスは、Oracleコンテキストにも適用されます。これにより匿名ユーザーは、`cn=OracleContext`というRDN内に含まれるディレクトリ・ネーミング・エントリをブラウズできます。これには、エンタープライズ・ユーザー・セキュリティを対象とするオブジェクトは含まれていません。 Oracle Net Configuration Assistantは、クライアントのインストール時にこのアクセスをセットアップします。
`OracleContextAdmins`グループ・ユーザー	`OracleContextAdmins`(`cn=OracleContextAdmins,cn=Groups,cn=OracleContext,...`)のメンバーには、すべてのディレクトリ・ネーミング・オブジェクトに対する作成、変更および読取りのアクセス権限があります。Oracle Net Configuration Assistantは、Oracleコンテキストの作成時に、このグループに対するこれらのアクセス権を作成します。 Oracleコンテキストの作成者以外に、この他のユーザーも、ディレクトリ管理者がOracle Enterprise Manager Cloud Controlを使用してこのグループに追加できます。
`OracleDBCreators`グループ・ユーザー	`OracleDBCreators`(`cn=OracleDBCreators,cn=OracleContext,...`)のメンバーには、データベース・サービスのオブジェクトと属性に対する作成と読取りのアクセス権限があります。Oracle Net Configuration Assistantは、Oracleコンテキストの作成時に、このグループに対するこれらのアクセス権を作成します。 Oracleコンテキストの作成者以外に、この他のユーザーも、ディレクトリ管理者がOracle Enterprise Manager Cloud Controlを使用してこのグループに追加できます。
`OracleNetAdmins`グループ・ユーザー	`OracleNetAdmins`(`cn=OracleNetAdmins,cn=OracleContext,...`)のメンバーには、ディレクトリ・ネーミングのオブジェクトと属性に対する作成、変更および読取りのアクセス権限があります。Oracle Net Configuration Assistantは、Oracleコンテキストの作成時に、このグループに対するこれらのアクセス権を作成します。 Oracleコンテキストの作成者以外に、ディレクトリ管理者によってこの他のユーザーもこのグループに追加できます。

Oracle Net Services名および関連データに対する参照または読取りアクセスについて高度なセキュリティが必要とされる場合、管理者はデータの一部またはすべてについて追加の読取りアクセス制御を定義できます。こうしたACL定義を使用して、匿名ユーザーによるOracle Net Servicesデータの読取りを禁止できます。Oracle Net Servicesデータに対する読取りアクセスが制限されている場合、クライアントは名前参照を実行する際に認証済バインドを使用する必要があります。

Oracleの構成ツールには、このデータに対する読取りアクセス制限を定義するための事前定義済グループまたはプロシージャがないため、管理者は、ディレクトリ・システムの標準オブジェクト管理ツールを使用して、必要なグループおよびACLを手動で作成する必要があります。

ldapmodifyおよびLDIF形式ファイルを使用して、ACLをOracle Net Servicesオブジェクトに追加できます。例3-2に、ユーザーcn=user1のすべてのアクセスを制限する方法を示します。

例3-2 アクセス制御リストを使用したユーザー・アクセスの制限

dn: cn=sales,cn=oraclecontext,dc=example,dc=com
replace: orclentrylevelaci
orclentrylevelaci: access to attr=(*)
by dn="cn=user1" (noread,nosearch,nowrite,nocompare)

前述の例は、単一オブジェクトのACLの基本的な形式を示しています。この方法は、必ずしもアクセスを定義するための最適な方法ではありません。オブジェクトのアクセス定義は複雑であり、DITの親ノードから継承されるセキュリティ・プロパティに影響する場合があるためです。管理者はディレクトリ・システムのマニュアルを参照し、Oracle Net Servicesオブジェクトのアクセス管理をディレクトリ全体のポリシーおよびセキュリティ実装に統合することをお薦めします。

Oracle Internet Directoryディレクトリの場合、oidadminには、ユーザーおよびグループを作成し、オブジェクトに対するACLおよび一般的なディレクトリ・セキュリティを定義する機能があります。

関連項目

親トピック: セキュリティに関する考慮事項

3.2.6.3 オブジェクト・クラス

Oracleコンテキスト、データベース・サービスまたはネットワーク・サービス名のエントリを作成する前に、ディレクトリが適切なバージョンのOracleスキーマとともに移入されている必要があります。Oracleスキーマは、オブジェクト・クラスと呼ばれるオブジェクト・タイプを定義します。これは、ディレクトリ・サーバーおよびその属性に格納できます。表3-3は、データベース・サービス・エントリ、ネットワーク・サービス名エントリおよびネットワーク・サービス別名エントリのオブジェクト・クラスを示しています。

表3-3 Oracle Net Services LDAPの主要なオブジェクト・クラス

Objectクラス	説明
`orclDbServer`	データベース・サービス・エントリの属性を定義します。
`orclNetService`	ネットワーク・サービス名エントリの属性を定義します。
`orclNetServiceAlias`	ネットワーク・サービス別名エントリの属性を定義します。

表3-4に、orclDbServer、orclNetServiceおよびorclNetServiceAliasが使用するオブジェクト・クラスを示します。

表3-4 Oracle Net Services LDAPの導出オブジェクト・クラス

Objectクラス	説明
`orclNetAddress`	リスナー・プロトコル・アドレスを定義します。
`orclNetAddressList`	アドレスのリストを定義します。
`orclNetDescription`	データベースのプロトコル・アドレスおよびサービスに対する接続情報が含まれた接続記述子を指定します。
`orclNetDescriptionList`	接続記述子のリストを定義します。

これらのオブジェクト・クラスは、接続記述子の内容を指定する属性を使用します。

関連項目:

オブジェクト・クラスとその属性に関する詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

親トピック: ディレクトリ・サーバーを使用するときの考慮事項

3.2.7 Microsoft Active Directoryにおけるディレクトリ・ネーミング・サポートの制約

Oracle Internet Directoryのみではなく、ディレクトリ・ネーミング・サポートも、Microsoft Active Directory で提供されていますが、次の制約があります。

Microsoft Active Directoryは、Microsoft Windowsオペレーティング・システム上でのみサポートしています。したがって、Microsoft Active Directoryのエントリへのアクセスまたはエントリの作成を行うには、クライアント・コンピュータとデータベース・サーバーもMicrosoft Windowsオペレーティング・システム上で実行する必要があります。
次の機能は、Microsoft Active Directoryではサポートされていません。
- 複数のOracleコンテキスト
  
  Microsoft Active DirectoryがサポートするOracleコンテキストは1つです。
- ネット・サービス別名
  
  Microsoft Active Directoryではネットワーク・サービス別名を作成できません。ただし、ネットワーク・サービス名の作成は可能です。

関連項目:

Microsoft固有の情報については、Microsoft Active Directoryのマニュアルを参照してください。

親トピック: 集中管理用のディレクトリ・サーバーの使用