ヘッダーをスキップ
Oracle Database Net Services管理者ガイド
11g リリース1(11.1)
E05725-04
  目次
目次
索引
索引

戻る
戻る
 
次へ
次へ
 

4 構成管理の概念

この章では、Oracle Net Servicesに関する構成情報を、ローカルの構成ファイルや集中化したディレクトリ・サーバーに格納する方法を説明します。

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

4.1 構成モデル

構成情報は、表4-1で説明するように、ローカルの構成ファイル、または集中化したリポジトリに格納できます。

表4-1 Oracle Net構成モデル

ネットワークの構成モデル 説明

ローカル管理

ネットワーク・アドレス情報は、ネットワーク上の各コンピュータにある、tnsnames.oraファイルに格納されます。

集中管理

ネットワーク・アドレス情報は、LDAP準拠のディレクトリ・サーバーなどの中央のディレクトリ・サービスに格納されます。


4.2 ローカライズされた構成ファイルのサポート

使用する構成モデルに基づいて、ネットワーク・コンピュータは表4-2で説明されているファイルで構成できます。

表4-2 Oracle Net構成ファイル

構成ファイル 説明

cman.ora

この構成ファイルは、Oracle Connection Managerが実行されるコンピュータ上にありますが、これには次のものが含まれます。

  • リスニング・エンドポイント

  • アクセス制御ルール・リスト

  • パラメータ・リスト

各Oracle Connection Manager構成は、1つのNV文字列内にカプセル化されており、その文字列は、前述のコンポーネントで構成されてます。

listener.ora

データベース・サーバーに配置されています。このリスナーに関する構成ファイルには、一般に次の情報が含まれています。

  • 接続要求を受け付けるプロトコル・アドレス

  • リスニングの対象とするデータベース・サービスと非データベース・サービス

  • リスナーが使用する制御パラメータ

sqlnet.ora

クライアントとデータベース・サーバーのコンピュータに配置されます。このファイルの内容は次のとおりです。

  • 修飾されていないサービス名またはネット・サービス名に付加されるクライアント・ドメイン

  • 名前の解決時にクライアントが使用するネーミング・メソッドの順序

  • 使用するロギング機能とトレース機能

  • 接続のルーティング

  • 外部ネーミング・パラメータ

  • Oracle Advanced Securityパラメータ

  • データベース・アクセス制御パラメータ

tnsnames.ora

このファイルは主にクライアント上にあり、接続記述子にマッピングされたネット・サービス名を持っています。このファイルは、ローカル・ネーミング・メソッドに使用されます。


構成ファイルは通常、UNIXオペレーティング・システムでは$ORACLE_HOME/network/adminに、Windowsオペレーティング・システムでは%ORACLE_HOME%\network\adminに作成されます。ただし、Oracle Netは様々な場所にある構成ファイルを検索できるため、構成ファイルは様々な場所に作成される可能性があります。

sqlnet.oraの検索順序は次のとおりです。

  1. 環境変数TNS_ADMINで指定されているディレクトリ。

  2. UNIXオペレーティング・システム上の$ORACLE_HOME/network/adminディレクトリ、Windowsオペレーティング・システム上の%ORACLE_HOME%\network\adminディレクトリ。

cman.oralistener.oraおよびtnsnames.oraの検索順序は次のとおりです。

  1. 環境変数TNS_ADMINで指定されているディレクトリ。

  2. UNIXオペレーティング・システム上のグローバル構成ディレクトリ。

    たとえば、Solaris Operating System上では、このディレクトリは、/var/opt/oracleです。

  3. UNIXオペレーティング・システム上の$ORACLE_HOME/network/adminディレクトリ、Windowsオペレーティング・システム上の%ORACLE_HOME%\network\adminディレクトリ。


    注意:


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


    関連項目:


    Oracleオペレーティング・システム固有のマニュアルを参照してください。

4.3 ディレクトリ・サーバーのサポート

今日では、ネットワーク情報は複数のシステムに複数のディレクトリ形式で格納されています。インターネット・コンピューティングや新しいE-Businessテクノロジの新しい要求によって、あらゆるデータやリソースの管理と構成の基盤として、共通のリポジトリ・インフラストラクチャが必要とされています。このような共通のインフラストラクチャによって、ネットワークでのリソースの管理および構成のコストが削減されます。

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

この項で説明する項目は、次のとおりです。

4.3.1 ディレクトリ・ネーミングの概要

Oracle Net Servicesは、接続識別子を格納する主な方法の1つとして、中央ディレクトリ・サーバーを使用します。クライアントは、それぞれの接続文字列の中で接続識別子を使用できます。このディレクトリ・サーバーは、この接続識別子を接続記述子に解決して、クライアントに戻します。この機能は、ディレクトリ・ネーミングと呼ばれます。

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

  1. クライアントは、接続識別子を接続記述子に解決するために、ディレクトリ・サーバーに接続します。

  2. ディレクトリ・サーバーは、この接続識別子を解決して、クライアントに接続記述子を渡します。

  3. クライアントは、この接続記述子を使用して、リスナーに接続要求を送信します。

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

図4-1の説明は次にあります。
画像の説明


注意:


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

4.3.2 ディレクトリ・サーバーでのネーミング構成の格納

ディレクトリ・サーバーは、ディレクトリ情報ツリー(DIT)と呼ばれるツリー構造に情報を格納します。このツリーの各ノードは、エントリと呼ばれます。Oracle Net Servicesは、ツリー構造とツリー内の特定のエントリを使用します。たとえば、図4-2について考えます。

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

図4-2の説明は次にあります。
画像の説明

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

各エントリは、識別名(DN)によって一意に識別されます。DNは、ディレクトリ・サーバーの階層内に対象のエントリが存在する場所を正確に示します。 db1のDNはdn:cn=db1,cn=OracleContext,dc=jp,dc=example,dc=comsalesのDNはdn:cn=sales,cn=OracleContext,dc=jp,dc=example,dc=comです。DNの形式では、DITの最下位コンポーネントを左側に置いてから、DITを上方向に徐々に移動することに注意してください。各DNは、相対識別名(RDN)の列で構成されています。これは、ディレクトリ・パスにディレクトリの列が格納されているのと似ています。db1のエントリでは、RDNはcn=db1です。エントリは一連の属性で構成されます。たとえば、cn=db1では、cnはエントリの属性の1つです。属性は、その値を伴って、エントリを一意に識別します。

db1salescn=OracleContextの下にあることに注意してください。このエントリは、Oracleコンテキストと呼ばれる特殊なRDNです。Oracleコンテキストの下にあるエントリは、ディレクトリ・ネーミングなど、ディレクトリで利用可能な様々な機能をサポートしています。

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

デフォルトのOracleコンテキストは、接続文字列に影響を与えます。 たとえば、クライアントがdb1salesのエントリに頻繁にアクセスする必要がある場合、デフォルトとして適切なOracleコンテキストは、dc=jp,dc=example,dc=comなどになります。cn=OracleContextは、接続文字列内で明示的に指定する必要はありません。クライアントのディレクトリ・エントリが、サービスの存在するディレクトリ・エントリと一致しない場合、クライアントは、「ディレクトリ・ネーミングを使用したクライアントの接続」で説明するように、接続文字列にエントリの絶対名を指定する必要があります。


関連項目:


アイデンティティ管理レルムの詳細は、『Oracle Internet Directory管理者ガイド』を参照してください。

4.3.3 ネット・サービス別名のエントリ

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

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

図4-3の説明は次にあります。
画像の説明

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

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

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

図4-4の説明は次にあります。
画像の説明

4.3.4 ディレクトリ・エントリ

DITは、一般的に次の構造によって構造化されています。

  • ドメイン・ネームスペース(DNS)構造

  • 地理的および組織的な構造

他の構造も使用できますが、オラクル社はこれらの構造をサポートします。

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

図4-5 ドメイン・コンポーネントDIT

図4-5の説明は次にあります。
画像の説明

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

図4-6 X.500形式DIT

図4-6の説明は次にあります。
画像の説明

4.3.5 ディレクトリ・サーバーでのエントリの追加または変更

Database Configuration Assistantによって、一部のモードでのインストール時またはインストール後にデータベース・サービス・エントリが作成されます。次にOracle Enterprise ManagerまたはOracle Net Managerを使用して、データベース・サービス・エントリのOracle Net属性を変更できます。また、これらのツールを使用すると、ネット・サービス名とネット・サービス別名のエントリを作成できます。

図4-7は、ツールがどのようにディレクトリ・サーバーとインタフェースを形成しているかを示しています。

図4-7 アプリケーションを使用したディレクトリ・サーバーのエントリの作成

図4-7の説明は次にあります。
画像の説明


注意:


Oracle Enterprise Managerはサポートされていますが、この図には表示されていません。

ディレクトリ・ネーミングについて構成されたクライアントは、「ディレクトリ・ネーミングを使用したクライアントの接続」で説明するように、これらの構成ツールによって作成されたエントリを使用して、データベースに接続できます。

これらの構成ツールを使用してエントリを追加するには、ルートOracleコンテキストを持つDIT構成とアイデンティティ管理レルムが存在する必要があります。ディレクトリ管理者は、Oracle Internet Directoryコンフィギュレーション・アシスタントを使用してこの構成を作成します。デプロイメントによっては、ディレクトリ管理者は、さらに別のOracleコンテキストを作成する必要があります。

Oracle Enterprise ManagerまたはOracle Net Managerを使用してディレクトリ・ネーミング・エントリを作成する管理者は、次のグループのメンバーであることが必要です。

  • Database Configuration Assistantを使用してデータベース・サービスのエントリを作成する場合は、OracleDBCreatorsグループcn=OracleDBCreators,cn=OracleContext...)またはOracleContextAdminsグループ(cn=OracleContextAdmins,cn=Groups,cn=OracleContext...

  • Oracle Net Managerを使用してネット・サービス名またはネット・サービス別名を作成する場合は、OracleNetAdminsグループ(cn=OracleNetAdmins,cn=OracleContext...)またはOracleContextAdminsグループ

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

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


関連項目:


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

大半のクライアントが必要とするのは、ディレクトリ・サーバー内での名前参照のみです。参照を実行するには、対象のディレクトリ・サーバーで匿名認証が可能である必要があります。通常、ディレクトリ・サーバーでは、デフォルトで匿名認証が行われます。

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

  • DNSを使用した動的な方法。この場合、ディレクトリ・サーバーの場所に関する情報は、中央のドメイン・ネーム・サーバーで保存および管理され、クライアントは要求を処理するときに、DNSサーバーからこの情報を動的に取り出します。

  • 静的には、Oracle Internet Directoryコンフィギュレーション・アシスタントによって作成され、クライアント・ホストに保存されているディレクトリ・サーバー使用ファイル(ldap.ora)で検出します。

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

他のネーミング・メソッドを使用する場合と同様に、クライアントは、接続識別子を使用してデータベースに接続します。接続識別子には、データベース・サービス名、ネット・サービス名またはネット・サービス別名を使用できます。これらは、それぞれの共通名で参照できます。または、追加のディレクトリ位置情報が必要な場合があります。デフォルトのOracleコンテキストによって、接続識別子の指定方法が決まります。

エントリは、次のいずれかの方法で識別できます。

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

  • エントリの絶対名の使用


    注意:


    JDBC OCIドライバは、相対ネーミングと絶対ネーミングの両方をサポートしています。JDBCシン・ドライバは、完全なDNが使用される場合にのみ、絶対ネーミングをサポートします。詳細は、『Oracle Database JDBC開発者ガイドおよびリファレンス』を参照してください。


    関連項目:


    クライアントによるディレクトリの位置確認の詳細は、『Oracle Internet Directory管理者ガイド』を参照してください。

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

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

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

図4-8 相対ネーミング

図4-8の説明は次にあります。
画像の説明

4.3.6.2 エントリの絶対名の使用

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

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

  • エントリの完全なDNを接続文字列に使用します。例を次に示します。

    CONNECT username@"cn=sales,cn=OracleContext,o=example,c=us"
    Enter password: password
    

    多くのアプリケーションで、DNの使用はサポートされていません。

  • エントリは完全修飾名で参照できます。完全修飾名には、オブジェクトの名前とそのディレクトリ・サーバー内での位置が含まれます。次に例を示します。

    CONNECT username@sales.example.us
    Enter password: password
    

注意:


JDBCシン・ドライバは、完全なDNが使用される場合にのみ、絶対ネーミングをサポートします。


関連項目:


絶対名の詳細は、「ディレクトリ・ネーミングの絶対名指定」を参照してください。

4.3.7 Oracle Netの構成とディレクトリ・サーバー設計

ディレクトリ・ネーミングのディレクトリ・サーバーの設計を担当している場合は、次の問題について検討してください。

4.3.7.1 パフォーマンス

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

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

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


関連項目:


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

4.3.7.2 セキュリティ

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

4.3.7.2.1 認証方式

クライアントは、実行されるタスクに応じて2つの異なる認証方式を使用します。

  • ディレクトリ・サーバー内の情報について参照を実行するクライアントは、通常、匿名認証を使用します。

    Oracle Database 11gでは、名前参照時にLDAPバインドを認証するようクライアントを構成できます。ネット・サービス・データを保護するか、またはディレクトリへの匿名バインドを無効にする(あるいはその両方の)必要があるサイトは、名前参照時の認証にウォレットを使用するようクライアントを構成する必要があります。これらのクライアントは、sqlnet.oraファイルに含まれる次の2つの新規パラメータを設定する必要があります。

    names.ldap_authenticate_bind = TRUE
    wallet_location = location_value
    
  • ディレクトリのエントリの追加や変更を行うクライアントは、ディレクトリ・サーバーで認証を実行する必要があります。Database Configuration AssistantやOracle Net Managerを使用すると、エントリの追加や修正が可能です。適正な権限を持つ認証ユーザーのみがエントリを変更できます。次のいずれかの認証方式を使用します。

    • 簡易認証

      クライアントは、ネットワークでのDNおよびパスワードを使用して、クライアント自体をディレクトリ・サーバーに認証要求します。サーバーは、クライアントが送信したDNおよびパスワードが、ディレクトリ・サーバーに格納されているDNおよびパスワードと一致していることを確認します。

    • 厳密認証

      ディレクトリでは、Secure Sockets Layer(SSL)で公開鍵暗号を使用することによって、厳密認証が得られます。公開鍵暗号では、メッセージの送信者は受信者の公開鍵を使用してメッセージを暗号化します。メッセージが送付されると、受信者は受信者の秘密鍵を使用して、このメッセージを復号化します。

    • 認証済名前参照を必要とするシステム上の構成

4.3.7.2.2 アクセス制御リスト

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


関連項目:


ディレクトリ・エントリにおけるACLの設定方法については、ディレクトリ・サーバーのベンダーのマニュアルを参照してください。

ACLの指定内容は、次のとおりです。

  • ユーザーがアクセス可能なエントリ

  • エントリへのアクセスに使用する認証方式

  • アクセス権、またはユーザーがオブジェクトに対して可能な処理(読取り/書込み)

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

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

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

表4-3 LDAPディレクトリ・ユーザー・グループ

グループ ACL要件

匿名ユーザー

匿名ユーザーは、ディレクトリ・サーバー内のすべてのOracle Net属性とオブジェクトへの読取りアクセス権を持ちます。匿名ユーザーのこれらのオブジェクトに対する読取りアクセスは、Oracleコンテキストにも適用されます。これにより匿名ユーザーは、cn=OracleContextというRDN内に含まれるディレクトリ・ネーミング・エントリをブラウズできます。これには、エンタープライズ・ユーザー・セキュリティを対象とするオブジェクトは含まれていません。

Oracle Net Configuration Assistantは、クライアントのインストール時にこのアクセス権をセットアップします。

OracleContextAdminsグループ・ユーザー

OracleContextAdminscn=OracleContextAdmins,cn=Groups,cn=OracleContext,...)のメンバーには、すべてのディレクトリ・ネーミング・オブジェクトに対する作成、変更および読取りのアクセス権限があります。Oracle Net Configuration Assistantは、Oracleコンテキストの作成時に、このグループに対するこれらのアクセス権を作成します。

Oracleコンテキストの作成者以外に、この他のユーザーも、ディレクトリ管理者がOracle Enterprise Managerを使用してこのグループに追加できます。

OracleDBCreatorsグループ・ユーザー

OracleDBCreatorscn=OracleDBCreators,cn=OracleContext,...)のメンバーには、データベース・サービスのオブジェクトと属性に対する作成と読取りのアクセス権限があります。Oracle Net Configuration Assistantは、Oracleコンテキストの作成時に、このグループに対するこれらのアクセス権を作成します。

Oracleコンテキストの作成者以外に、この他のユーザーも、ディレクトリ管理者がOracle Enterprise Managerを使用してこのグループに追加できます。

関連項目: OracleDBCreatorsグループの詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

OracleNetAdminsグループ・ユーザー

OracleNetAdminscn=OracleOracleNetAdmins,cn=OracleContext,...)のメンバーには、ディレクトリ・ネーミングのオブジェクトと属性に対する作成、変更および読取りのアクセス権限があります。Oracle Net Configuration Assistantは、Oracleコンテキストの作成時に、このグループに対するこれらのアクセス権を作成します。

Oracleコンテキストの作成者以外に、ディレクトリ管理者によってこの他のユーザーもこのグループに追加できます。

関連項目: ユーザーをOracleNetAdminsグループに追加する方法については、「OracleNetAdminsグループの管理」を参照してください。


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


関連項目:


名前参照に認証済バインドを使用するようクライアントを構成する方法については、「認証方式」を参照してください。

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

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

dn: cn=emn10,cn=oraclecontext,dc=stiger,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および一般的なディレクトリ・セキュリティを定義する機能があります。


関連項目:

  • 詳細は、『Oracle Internet Directory管理者ガイド』を参照してください。

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


4.3.7.3 スキーマ

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

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

オブジェクト・クラス 説明

orclDbServer

データベース・サービス・エントリの属性を定義します。

orclNetService

ネット・サービス名エントリの属性を定義します。

orclNetServiceAlias

ネット・サービス別名エントリの属性を定義します。


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

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

オブジェクト・クラス 説明

orclNetAddress

リスナー・プロトコル・アドレスを定義します。

orclNetAddressList

アドレスのリストを定義します。

orclNetDescription

データベースのプロトコル・アドレスおよびサービスに対する接続情報が記述されている接続記述子を指定します。

orclNetDescriptionList

接続記述子のリストを定義します。


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


関連項目:


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

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

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

  • Oracleがサポートするのは、Windowsオペレーティング・システム上のMicrosoft Active Directoryのみです。したがって、Microsoft Active Directoryのエントリへのアクセスまたはエントリの作成を行うには、クライアント・コンピュータとデータベース・サーバーもWindowsオペレーティング・システム上で実行する必要があります。

  • 次の機能は、Microsoft Active Directoryではサポートされていません。

    • 複数のOracleコンテキスト

      Microsoft Active DirectoryがサポートするOracleコンテキストは1つです。

    • ネット・サービス別名

      Microsoft Active Directoryでは、ネット・サービス別名を作成することはできません。ただし、ネット・サービス名を作成することはできます。

    • クライアントによるクライアント用ディレクトリ・サーバーの自動検出

      クライアントのディレクトリ・サーバー使用の構成を静的に行う必要があります。Oracle Internet Directory Configurationでは、Microsoft Active Directory向けのディレクトリ・サーバーの使用は提供されません。Oracle Net Configuration Assistantを使用してください。