1. エンタープライズ・ユーザー・セキュリティ管理者ガイド
  2. エンタープライズ・ユーザー・セキュリティの概要

1 エンタープライズ・ユーザー・セキュリティの概要

エンタープライズ・ユーザー・セキュリティは、Oracle Database 12cリリース1 (12.1) Enterprise Editionの重要なコンポーネントです。エンタープライズ・ユーザー・セキュリティを使用すると、多くのエンタープライズ・データベース・ユーザーの管理およびセキュリティ上の問題に対応できます。エンタープライズ・ユーザーとは、ディレクトリに定義されたユーザーを指します。ユーザー識別情報は、エンタープライズ内で常に一定です。エンタープライズ・ユーザー・セキュリティは、Oracle Identity Managementインフラストラクチャに依存しており、このインフラストラクチャは、LDAP準拠のディレクトリ・サービスを使用して、ユーザーを一元的に格納し管理します。

この章では、エンタープライズ・ユーザー・セキュリティの内容とその仕組みについて説明します。項目は次のとおりです。

1.1 エンタープライズ・ユーザー・セキュリティの概要

この概要では、組織にとってのエンタープライズ・ユーザー・セキュリティの利点、エンタープライズ・ユーザーが認証される仕組みおよび分散データベース・システム全体にわたるリソースにアクセスする仕組みについて説明します。次の項目が含まれます。

1.1.1 ユーザー管理の課題

管理者は、エンタープライズ全体のユーザー情報を最新かつセキュアな状態に保つ必要があります。このタスクはアプリケーションとユーザーの数が増えるにつれてますます難しくなっています。通常は、個々のユーザーが様々なデータベース上に複数のアカウントを持っており、各ユーザーは複数のパスワードを覚えておく必要があります。その結果、ユーザーはパスワードが多すぎて覚えられず、管理者はアカウント数が多すぎて効率的に管理できないという状態に陥っています。

何千ものユーザーがデータベース・アカウントにアクセスするため、ユーザー管理には多くのリソースが必要です。ユーザー名、電話番号、システム・ロール、システム権限など、複数のアプリケーションで使用される共通の情報は、多くの場合、エンタープライズ内に分散して存在しています。このように、冗長で一貫性のないデータが増えるため、データの管理が困難になっています。

ユーザーとアカウントの管理の問題に加えて、これらの状況によりセキュリティの問題も発生します。たとえば、あるユーザーが退職するか、職務が変更になった場合は、そのユーザーの権限が悪用されることを防ぐため、その日のうちにユーザーの権限を変更する必要があります。しかし、大規模な企業ではたいていの場合、複数のデータベースに分散したユーザー・アカウントが多く、管理者は適時に変更できないことがあります。

同様に、ユーザーがあまりにも多くのパスワードを持っている場合、それらのパスワードをメモに書き留めることで、他者がパスワードを簡単に書き写せるようになることがあります。また、覚えやすいパスワードを選択し、他者が簡単に推測できるようになる場合や、複数のアプリケーションに同じパスワードを使用し、パスワードが見破られてセキュリティ上のリスクが高まる場合もあります。複数のパスワードを覚えておくためのユーザーの工夫はすべて、エンタープライズ・セキュリティを危険にさらす可能性があります。

1.1.2 エンタープライズ・ユーザー・セキュリティ: 全体像

エンタープライズ・ユーザー・セキュリティでは、Oracle Internet Directoryで提供されるアイデンティティ管理サービス、およびLDAP準拠のディレクトリ・サービスを利用して、ユーザー、管理およびセキュリティに関する問題に対処します。アイデンティティ管理とは、組織でネットワーク・エンティティのセキュリティ・ライフ・サイクル全体を管理するプロセスです。通常、組織のアプリケーション・ユーザーの管理を指します。セキュリティ・ライフ・サイクルのステップには、アカウント作成、一時停止、権限変更およびアカウント削除が含まれます。

図1-1に、Oracle Identity Managementインフラストラクチャを基盤として使用するOracleセキュリティ・アーキテクチャに、エンタープライズ・ユーザー・セキュリティを組み込む仕組みを示します。

図1-1 エンタープライズ・ユーザー・セキュリティとOracleセキュリティ・アーキテクチャ

図1-1の説明が続きます
「図1-1 エンタープライズ・ユーザー・セキュリティとOracleセキュリティ・アーキテクチャ」の説明

ユーザーは、管理者が選択した構成に応じて、シングル・サイン・オン(SSO)または単一パスワード認証を通じてエンタープライズ・ユーザー・セキュリティを利用します。シングル・サイン・オンを使用する場合、ユーザーの認証が必要なのは1回のみであり、その後の認証は透過的に行われます。この機能ではSSLを必要とするため、Oracle Identity Managementインフラストラクチャの構成要素であるOracleAS Single Sign-Onと混同されることはありません。

単一パスワード認証を使用すると、ユーザーは1つのグローバル・パスワードを使用して複数のデータベースに対して認証を行うことができます。ただし、各接続に固有の認証が必要となります。パスワードは中央に位置するLDAP準拠のディレクトリに安全に格納され、暗号化や\などのセキュリティ・メカニズムで保護されます。この方式では、記憶および管理するパスワード数が減少し、SSLの設定に伴うオーバーヘッドが解消されるため、操作性が向上します。

エンタープライズ・ユーザー・セキュリティを使用するには、Oracle Internet Directory 10g (9.0.4)以上が必要です。その他のLDAP準拠のディレクトリ・サービスは、Oracle Directory Integration Platformを使用してOracle Internet Directoryと同期することによりサポートされます。別のディレクトリ・サービス製品であるOracle Virtual Directoryでは、LDAPプロトコルやXMLプロトコルを介して、複数のデータ・ソースへの動的な単一アクセス・ポイントを提供します。Oracle Virtual Directoryでは、Oracle Internet Directory、Microsoft Active Directory、Sun Java Systems Directoryなどのインスタンスに格納されているアイデンティティ・データのアプリケーション固有のビューが複数提供されており、Oracle Virtual Directoryを使用してアプリケーション固有のソースへのデータ・アクセスを保護し、既存データ・ソースに対する高可用性を向上させることができます。

関連項目:

Oracle Directory Integration PlatformとOracle Virtual Directoryを他のディレクトリとともに使用する方法は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』を参照してください。

注意:

Microsoft Active Directoryは、Windowsプラットフォーム上のOracleデータベースに対してのみサポートされます。

この項では、次の項目について説明します。
1.1.2.1 Oracle Internet DirectoryでID管理を実装する方法

Oracle Internet Directoryでは、アイデンティティ管理レルムの概念を使用して、情報をディレクトリ情報ツリー(DIT)内に整理します。DITは、ディレクトリ・オブジェクト・エントリから構成される階層ツリー型の構造です。ディレクトリ内にある、1つのオブジェクトに関する情報の集まりをエントリと呼びます。このオブジェクトは人の場合もありますが、構成情報などのネットワーク・デバイスに関する情報の場合もあります。DIT内のディレクトリ・オブジェクトの名前を指定し、場所を識別するために、各エントリには一意の識別名(DN)が割り当てられます。エントリのDNは、そのエントリ自体と親エントリから構成され、そのエントリからDITのルート(最上位)エントリまで昇順に連結されます。

この項では、次の項目について説明します。
1.1.2.1.1 ID管理レルムについて

アイデンティティ管理レルムは、ディレクトリ・エントリのサブツリーであり、そのすべてが同じ管理ポリシーによって管理されます。たとえば、イントラネットにアクセスできるエンタープライズ内のすべての従業員はある1つのレルムに属し、エンタープライズのパブリック・アプリケーションにアクセスするすべての外部ユーザーは他のレルムに属します。異なるレルムを使用することによって、ユーザー集団を分離し、各レルムで異なる管理ポリシー(パスワード・ポリシーやネーミング・ポリシーなど)を適用できます。ログインIDの識別に使用されるデフォルトのニックネーム属性はuidで、アイデンティティ管理レルムごとに設定されます。

1.1.2.1.2 ID管理レルム固有のOracleコンテキストについて

各アイデンティティ管理レルムには、そのレルムのOracle製品情報を格納するレルム固有のOracleコンテキスト(レルムOracleコンテキスト)があります。レルムOracleコンテキストには、アプリケーション・データ、ユーザーの命名と配置の方法、ユーザーの認証方法、グループの位置および権限の割当てが格納されますが、これらの情報はすべて、レルムOracleコンテキストが配置されている特定のアイデンティティ管理レルム固有の情報です。

関連項目:

1.1.2.2 エンタープライズ・ユーザーとデータベース・ユーザーの比較

通常、データベース・ユーザーは、次のようなCREATE USER文を使用してデータベースに定義されます。 

CREATE USER username IDENTIFIED BY password;

この文によって、ユーザー・スキーマに関連付けられたデータベース・ユーザーが作成されます。データベース・ユーザーは、次のようなCONNECTコマンドを使用してデータベースにアクセスし、パスワードを指定して認証されます。 

CONNECT username@database_service_name
Enter Password:

データベース・ユーザーは、アクセスする必要がある各データベースに作成する必要があり、データベースごとに異なるパスワードを選択できます。データベース・ユーザー権限は、各データベースのローカル・ロールによって制御されます。

これに対して、エンタープライズ・ユーザーは、データベース・アクセスについて、Oracle Internet DirectoryなどのLDAP準拠のディレクトリで一元的にプロビジョニングおよび管理されます。エンタープライズ・ユーザーは、ディレクトリ内に識別名(DN)と呼ばれる一意の識別情報を持っています。エンタープライズ・ユーザーがデータベースにログオンすると、データベースはDNを使用してこれらのユーザーを認証します。

エンタープライズ・ユーザーは、グローバル・ユーザーとしてデータベースに定義されます。グローバル・ユーザーは、独自のスキーマを持つことも、アクセスするデータベース内のグローバル・スキーマを共有することもできます。エンタープライズ・ユーザーは、次の2通りの方法でCREATE USER文のGLOBALLY句を使用して作成できます。

次の文に示すように、AS句を使用してユーザーのディレクトリDNを指定できます。 

CREATE USER username IDENTIFIED GLOBALLY AS '<DN of directory user entry>';

この場合は、エンタープライズ・ユーザーにそれぞれ専用のスキーマが割り当てられます。

または、次の文に示すように、AS句を使用してNULL文字列を指定することもできます。 

CREATE USER username IDENTIFIED GLOBALLY AS '';

AS句でNULL文字列を指定すると、認証ユーザーはディレクトリによって適切なデータベース・スキーマにマップされます。この場合は、Oracle Internet Directoryに設定および格納されているマッピング情報に基づいて、複数のユーザーを共有スキーマにマップできます。

注意:

次の構文を使用して、共有スキーマを作成することもできます。

CREATE USER username IDENTIFIED GLOBALLY;

これは、NULL文字列を指定した場合と同じです。

エンタープライズ・ユーザーがSSLを使用してデータベースに接続する場合、パスワードを使用しません。かわりに、次のCONNECTコマンドを使用しますが、このコマンドは、クライアントのsqlnet.oraファイル内の情報に基づいてウォレット・ロケーションを探します。 

CONNECT /@database_service_name

パスワード認証エンタープライズ・ユーザーは、通常のデータベース・ユーザーと同じCONNECT文を使用してデータベースに接続します。たとえば、パスワード認証エンタープライズ・ユーザーは、次の構文を使用してデータベースに接続します。 

CONNECT username@database_service_name
Enter password:

データベースは、エンタープライズ・ユーザーから接続リクエストを受信すると、ユーザー認証および認可(ロール)情報を確認するためにディレクトリを参照します。

関連項目:

1.1.2.3 エンタープライズ・ユーザー・スキーマについて

エンタープライズ・ユーザーは個別のデータベース・スキーマ(排他スキーマ)を保持できます。また、エンタープライズ・セキュリティ管理者がエンタープライズ・ユーザーを共有スキーマにマップしている場合は、共有スキーマを保持できます。

この項では、次の項目について説明します。
1.1.2.3.1 プライベートまたは排他スキーマ

ユーザーがアクセスするデータベースに個別のスキーマを保持する必要がある場合は、次のタスクを実行する必要があります。

  • ディレクトリにエンタープライズ・ユーザーを作成します。

  • ユーザーがアクセスする各データベースに、ユーザーごとにグローバル・ユーザー・スキーマを作成します。

アクセスする各データベースにエンタープライズ・ユーザーごとに個別のアカウントを作成すると、オーバーヘッドが大きくなります。かわりに、各データベース内の1つの汎用共有スキーマにアクセスするエンタープライズ・ユーザーを作成すると、エンタープライズ・ユーザー・ソリューションの効率が高まります。

1.1.2.3.2 共有スキーマ

エンタープライズ・ユーザー・ソリューションの真の利点を得るには、エンタープライズ・ユーザーに対して共有スキーマを使用します。この方法では、次のタスクを実行します。

  • ディレクトリにエンタープライズ・ユーザーを作成します。

  • 各データベースに共有スキーマを1つ作成します。

  • Oracle Internet Directoryに共有スキーマ・マッピングを1つ作成します。

エンタープライズ・ユーザーがアクセスする各データベース上の汎用共有スキーマにユーザーをマップすると、エンタープライズ・ユーザーごとに個別のスキーマを作成することで生じるオーバーヘッドが大幅に削減されます。

共有スキーマ・エンタープライズ・ユーザーは、そのユーザーがアクセスするすべてのデータベース上の汎用共有スキーマにマップできます。また、あるデータベースでは排他スキーマを持ち、別のデータベースでは共有スキーマを持つようにすることも可能です。共有スキーマ・マッピングはディレクトリに格納されます。

関連項目:

1.1.2.4 エンタープライズ・ユーザーがデータベース・リンクを使用してデータベース・リソースにアクセスする方法

データベース・リンクは、ローカル・データベースまたはネットワーク定義に格納されるネットワーク・オブジェクトであり、リモート・データベース、そのデータベースへの通信パス、および場合によってはユーザー名とパスワードを識別します。定義されると、データベース・リンクはリモート・データベースへのアクセスに使用されます。Oracle Databaseでは、接続ユーザー・リンク、固定ユーザー・リンクおよび現行ユーザー・リンクをサポートしています。

エンタープライズ・ユーザーは、次の3種類のデータベース・リンクをすべて使用できます。

  • 接続ユーザー・リンクには、リモート・サーバーにアカウントを持つローカル・ユーザーがアクセスします。

  • 固定ユーザー・リンクには、リンク定義の一部としてユーザー名とパスワードが含まれます。

  • 現行ユーザーのデータベース・リンクでは、エンタープライズ・ユーザーが、リンクの実行中に認証情報を渡したり、リンク定義に認証情報を格納したりせずに、リモート・データベースのオブジェクトにアクセスできます。

    このデータベース・リンクでは、データベース・ネットワーク接続にSSLを必要とし、したがって、データベースの公開キー・インフラストラクチャ(PKI)資格証明を取得および保持する必要があります。現行ユーザーのデータベース・リンクは、エンタープライズ・ユーザーとしてリモート・データベースに接続する場合にのみ使用できます。

関連項目:

1.1.2.5 エンタープライズ・ユーザーの認証方法

エンタープライズ・ユーザー・セキュリティでは、次の認証方式をサポートしています。

  • パスワードベースの認証

  • SSLベースの認証

  • Kerberosベースの認証

各認証方式にはそれぞれに長所と短所があります。表1-1に、エンタープライズ・ユーザー・セキュリティ実装に最適な認証方式を選択する基準をまとめます。

表1-1 エンタープライズ・ユーザー・セキュリティの認証: 選択基準

パスワード認証 SSL認証 Kerberos認証

パスワードベースの認証

SSLによる厳密認証を行う。

Kerberosバージョン5のチケットを使用した厳密認証を行う。

ユーザーとパスワードを一元管理できる。

ユーザーとPKI資格証明/ウォレットを一元管理できる。

ユーザーとKerberos資格証明を一元管理できる。

各データベース接続に個別の認証が必要である。

SSLを使用したシングル・サインオン(SSO)をサポートする。

Kerberosバージョン5の暗号化チケットと認証子を使用したSSOおよび認証転送をサポートする。

ユーザーの現行の認証方式を保持する。

すべてのユーザーに対してPKI資格証明を生成する必要があるため、初期構成が難しくなる場合がある。(管理者のPKIに関する知識による)

データベース・ユーザーを認証するにはKerberosをインストールして構成する必要があるため、初期構成が難しくなる場合がある。

ユーザーIDを2層または多層アプリケーションで使用できる。OracleAS Single Sign-Onユーザーとエンタープライズ・ユーザーで同じ保管パスワードを使用する。

2層または多層環境のいずれかと互換性がある。

2層または多層環境のいずれかと互換性がある。

Oracle Database 10g以上でOracleリリース7.3以上のクライアントをサポートする。

Oracle Database 10g以上でOracle8i以上のクライアントをサポートする。

Oracle Database 10g以上でOracle Database 10g以上のクライアントをサポートする。

データベース間の接続にSSLが使用されている場合にのみ、現行ユーザーのデータベース・リンクをサポートする。

現行ユーザーのデータベース・リンクをサポートする。

データベース間の接続にSSLが使用されている場合にのみ、現行ユーザーのデータベース・リンクをサポートする。

Oracle Internet Directoryと同期される場合は、サード・パーティ・ディレクトリを使用してユーザーを格納できる。脚注 1

Oracle Internet Directoryと同期される場合は、サード・パーティ・ディレクトリを使用してユーザーを格納できる。脚注 2

Oracle Internet Directoryと同期される場合は、サード・パーティ・ディレクトリを使用してユーザーを格納できる。脚注 3

脚注1

サード・パーティ・ディレクトリがMicrosoft Active Directoryの場合は、ユーザー・パスワードを変更するときに、Active DirectoryとOracle Internet Directoryの両方でパスワードを変更する必要があります。

脚注2

ユーザーのPKCS #12属性を同期するには、Directory Integration Servicesエージェントを変更する必要があります。

脚注3

サード・パーティ・ディレクトリがMicrosoft Active Directoryの場合は、Windowsにログインすることによってデータベースへのシングル・サインオン・ログインが可能になります。ただし、他のサード・パーティ・ディレクトリのDirectory Integration Servicesエージェントを変更してKrbPrincipalName属性を同期する必要があります。この同期は、Microsoft Active Directoryに対して自動的に行われます。

注意:

エンタープライズ・ユーザー・セキュリティでは、3層環境がサポートされています。Oracle Databaseのプロキシ認証機能により、次の両方が可能になります。

(i) 多層でのユーザー名とパスワードのプロキシ

(ii) 多層でのX.509証明書および識別名のプロキシ

関連項目:

1.1.3 エンタープライズ・ユーザー・セキュリティのディレクトリ・エントリについて

ディレクトリでは、オブジェクトに関する情報の個々のコレクションをエントリと呼びます。エンタープライズ・ユーザー・セキュリティの場合、ユーザー、ロール、データベースなどの要素はディレクトリ・オブジェクトであり、これらのオブジェクトに関する情報はエントリとしてディレクトリに格納されます。

ディレクトリ内の各エントリは、DNによって一意に識別されます。DNによって、一般にディレクトリ情報ツリー(DIT)と呼ばれるディレクトリ・エントリ階層内のエントリの場所が正確にわかります。

注意:

Oracle Database 10g以上では、データベースをOracle Internet Directoryの完全なアイデンティティ管理レルムに登録する必要があります。

関連項目:

ディレクトリ・エントリの詳細は、Oracle Fusion Middleware Oracle Internet Directory管理者ガイドを参照してください。

次の各項では、エンタープライズ・ユーザー・セキュリティに関連するディレクトリ・エントリについて説明します。
1.1.3.1 エンタープライズ・ユーザー

エンタープライズ・ユーザーは、ディレクトリで定義および管理されるユーザーです。各エンタープライズ・ユーザーは、エンタープライズ全体で一意の識別情報を持ちます。エンタープライズ・ユーザー・エントリは、レルムOracleコンテキスト内を除き、アイデンティティ管理レルム内の任意の場所に配置できます。

注意:

9.0.4以上のOracle Internet Directoryにエンタープライズ・ユーザーを作成する場合は、9.0.4以上のOracle Internet Directoryに同梱されているDelegated Administration System (DAS)などのツールを使用してください。使用しているデータベースが9iまたは9iR2の場合でも、9.0.4以上のOracle Internet Directoryにユーザーを作成するときには、9iまたは9iR2のEnterprise Security ManagerのGUIツールを使用しないでください。

アイデンティティ管理レルムにエンタープライズ・ユーザーを作成する場合は、Oracle Application Server 10gに同梱されているOracle Internet Directoryセルフ・サービス・コンソールなどのDASベースのツールのみを使用してください。

次の各項で説明するエントリは、レルムOracleコンテキスト内にのみ配置できます。

1.1.3.2 エンタープライズ・ロール

エンタープライズ・ロールは、1つ以上のデータベース・グローバル・ロールを保持する、コンテナのように機能するディレクトリ・オブジェクトです。各グローバル・ロールは、権限が割り当てられている特定のデータベースに定義されますが、エンタープライズ・ロールを使用してディレクトリで管理されます。エンタープライズ・ユーザーにエンタープライズ・ロールを割り当てて、データベースに対するアクセス権限を決定できます。図1-3の例では、OracleDefaultDomainの下に「Manager」というエンタープライズ・ロールがあります。

たとえば、エンタープライズ・ロールsales_managerに、Customer Relationship Management (CRM)データベースに対する権限を持つグローバル・ロールmanage_leadsと財務データベースに対する権限を持つグローバル・ロールbonus_approvalが含まれるとします。図1-2に、この例を示します。

図1-2 エンタープライズ・ロールの例

図1-2の説明が続きます。
「図1-2 エンタープライズ・ロールの例」の説明

エンタープライズ・ロールは、1つ以上のエンタープライズ・ユーザーに割り当てることができます。たとえば、エンタープライズ・ロールsales_managerを、同じ職務の多くのエンタープライズ・ユーザーに割り当てることができます。この情報はディレクトリで保護され、ディレクトリ管理者のみがユーザーの管理とそのロールの割当てを行うことができます。ユーザーには、エンタープライズ・ロール以外に、接続先スキーマに対する権限に基づいて、データベース内のローカル・ロールや権限も付与することができます。

エンタープライズ・ロール・エントリは、エンタープライズ・ドメイン・サブツリーに格納されます。各エンタープライズ・ロールには、各データベース・サーバーに対応するグローバル・ロールと、関連付けられたエンタープライズ・ユーザーの情報が含まれます。エンタープライズ・ドメイン管理者は、Oracle Enterprise Managerを使用してエンタープライズ・ロールを作成および管理します。

関連項目:

Oracle Enterprise Managerを使用したエンタープライズ・ロールの作成方法と管理方法は、「エンタープライズ・ロールの構成」を参照してください。

注意:

データベースは、ログイン・プロセスの一環としてディレクトリからユーザーのグローバル・ロールを取得します。ディレクトリ内のユーザーのグローバル・ロールを変更しても、次にユーザーがデータベースにログインするまでその変更は反映されません。

1.1.3.3 エンタープライズ・ドメイン

エンタープライズ・ドメインは、データベースとエンタープライズ・ロールのグループです。ドメインの例には、企業の技術部門や小規模な企業などがあります。図1-3の例では、アイデンティティ管理レルムのOracleDBSecurityエントリの下に「Services」というエンタープライズ・ドメインがあります。エンタープライズ・ドメイン管理者が、Oracle Enterprise Managerを使用してユーザーにエンタープライズ・ロールを割り当て、エンタープライズ・セキュリティを管理するのは、このエンタープライズ・ドメイン・レベルです。

ディレクトリのエンタープライズ・ドメイン・サブツリーは、そのドメインのエンタープライズ・ロール・エントリ、ユーザー・スキーマ・マッピングおよびエンタープライズ・ドメイン管理者のグループという3種類のエントリから構成されます。エンタープライズ・ドメインは、複数のデータベースに適用される情報の管理に使用されます。エンタープライズ・ドメインに含まれるすべてのユーザー・スキーマ・マッピング・エントリは、ドメイン内のすべてのデータベースに適用されます。個々のデータベースに異なるユーザー・スキーマ・マッピングを適用する必要がある場合は、次の項で説明するデータベース・サーバー・エントリを使用します。

前の項で説明したように、エンタープライズ・ロールはドメイン内の特定のデータベースに適用されます。エンタープライズ・ロール、ドメイン・レベルのマッピングおよびドメイン管理者グループは、すべてOracle Enterprise Managerを使用して管理されます。

関連項目:

「エンタープライズ・ドメインの管理」

1.1.3.4 データベース・サーバー・エントリ

データベース・サーバー・エントリ(図1-3では「Sales」として表されています)は、1つのデータベース・サーバーに関する情報を含むディレクトリ・エントリです。このエントリは、データベース登録時にDatabase Configuration Assistantによって作成されます。データベース・サーバー・エントリは、完全または部分的なユーザーDNとデータベース共有スキーマ名の間のマッピングを記述する、ユーザー・スキーマ・マッピングと呼ばれるデータベース・レベルのマッピング・エントリの親です。ユーザー・スキーマ・マッピング・エントリは、データベース管理者によってOracle Enterprise Managerを使用して作成されます。

関連項目:

「Oracle Enterprise Manager」

データベース管理者は、Oracle Enterprise Managerで管理されるディレクトリ管理グループOracleDBAdminsに属します。OracleDBAdminsまたはOracleContextAdminsグループ・メンバーのみが、OracleDBAdminsグループに対してユーザーを追加または削除できます。ユーザーがディレクトリにデータベースを登録すると、Database Configuration Assistantによって、登録を実行したユーザーがOracleDBAdminsグループに自動的に追加されます。このグループのディレクトリ・エントリは、DITのデータベース・サーバー・エントリの下に位置します。

関連項目:

図1-3 レルムOracleコンテキスト内の関連エントリ

図1-3の説明が続きます
「図1-3 レルムOracleコンテキスト内の関連エントリ」の説明
1.1.3.5 ユーザー・スキーマ・マッピング

ユーザー・スキーマ・マッピングは、ユーザーのDNとOracleデータベース・スキーマの間のマッピング情報を含むディレクトリ・エントリです。マッピングで参照されるユーザーは、データベースへの接続時に指定されたスキーマに接続されます。ユーザー・スキーマ・マッピング・エントリは、レルムOracleコンテキスト内の場所に応じて、1つのデータベースのみ、またはドメイン内のすべてのデータベースに適用できます。

関連項目:

1.1.3.6 管理グループ

アイデンティティ管理レルムには、エンタープライズ・ユーザー・セキュリティに関連する管理グループが含まれています。図1-3では、「Groups」という三角形内に、レルムに含まれるこれらの管理グループが示されています。各管理グループには、グループ自体へのアクセスを制御するアクセス制御リスト(ACL)が含まれます。ディレクトリ内の別の場所にあるACLがこれらのグループを参照できるため、ディレクトリ管理者がアクセスして必要な管理タスクを実行できるようになります。レルムを作成した管理ユーザーは、自動的にこれらのグループそれぞれの最初のメンバーになるため、各グループに関連付けられている権限を取得します。ただし、このユーザーは削除できます。

レルム内の関連する管理グループを表1-2に示します。

注意:

次の点に注意してください。他の方法を使用すると、エンタープライズ・ユーザー・セキュリティ・オブジェクトのセキュリティ構成が無効になり、エンタープライズ・ユーザー機能も無効になる可能性があります。

  • レルムOracleコンテキストに含まれるオブジェクトのACLは変更しないでください。変更されたレルムOracleコンテキスト・オブジェクトのACLはサポートされません。

  • エンタープライズ・ユーザー・セキュリティのディレクトリ・エントリを変更するには、Oracle Enterprise Manager、Oracle Internet Directoryセルフ・サービス・コンソール、Database Configuration AssistantなどのOracleのツール製品のみを使用してください。

表1-2 レルムOracleコンテキスト内の管理グループ

管理グループ 説明

OracleContextAdmins

DN: (cn=OracleContextAdmins,cn=Groups,cn=OracleContext)

デフォルト所有者: アイデンティティ管理レルムを作成したユーザー。(インストール時に作成されたレルムの場合は、orcladmin。)

OracleContextAdminsは、関連付けられたレルムOracleコンテキスト内のすべてのグループおよびエントリに対する完全なアクセス権を持ちます。

OracleDBAdmins

DN: (cn=OracleDBAdmins,cn=<database_entry_name>,cn=OracleContext)

デフォルト所有者: なし。Database Configuration Assistantによって、ディレクトリにデータベースを登録したユーザーが自動的にこのグループのメンバーになります。

このグループのメンバーは、このデータベース固有のユーザー・スキーマ・マッピングを管理します。すでにこのグループまたはOracleContextAdminsのメンバーであるユーザーのみが、OracleDBAdminsグループに対してユーザーを追加または削除できます。

OracleDBCreators

DN: (cn=OracleDBCreators,cn=OracleContext...)

デフォルト所有者: OracleContextAdmins

デフォルトのレルムOracleコンテキストの作成中に、Oracle Internet Directoryコンフィギュレーション・アシスタントにより、これらのグループ・メンバーに対して次のアクセス権/権限が設定されます。

  • レルムOracleコンテキストのデータベース・サービス・オブジェクトに対するAdd権限

  • デフォルト・ドメインに対するModify権限

OracleDBCreatorsは、Database Configuration Assistantを使用して新規データベースを作成し、ディレクトリに登録します。

OracleDBSecurityAdmins

DN: (cn=OracleDBSecurityAdmins,cn=OracleContext)

デフォルト所有者: すべてのグループ・メンバー。

デフォルトのレルムOracleコンテキストの作成中に、Oracle Internet Directoryコンフィギュレーション・アシスタントにより、これらのグループ・メンバーに対して次のアクセス権/権限が設定されます。

  • OracleDBSecurityサブツリーにおけるすべての権限

  • このグループのメンバーシップに対するModify権限

OracleDBSecurityAdminsは、エンタープライズ内のすべてのドメインに対する権限を持ち、次のタスクを実行します。

  • データベースとディレクトリ間のデフォルトの認証方式など、エンタープライズ・ユーザー・セキュリティ構成をレルムに設定します。

  • グループの所有者がOracleDBSecurityAdminsグループを管理します。

  • エンタープライズ・ドメインを作成および削除します。

  • エンタープライズ内のあるドメインから別のドメインへのデータベースを移動します。

OracleDomainAdmins

DN: (cn=OracleDomainAdmins,cn=<enterprise_domain_name>,

cn=OracleDBSecurity,cn=Products,cn=OracleContext....)

デフォルト所有者: ドメインを作成または更新したユーザー。

新規コンテキストおよびOracleDefaultDomainが作成されると、初期メンバーがコンテキスト作成者になります。

OracleDomainAdminsグループのメンバーは、エンタープライズ・ドメインに対する完全な権限を持ちます。このグループのメンバーは、ドメイン全体に固有のマッピング、エンタープライズ・ロールおよびプロキシ権限を管理します。このグループのメンバーシップを変更するには、OracleDomainAdmins (ドメインの場合)、OracleDBSecurityAdminsまたはOracleContextAdminsのメンバーであることが必要です。

OracleUserSecurityAdmins

DN: (cn=OracleUserSecurityAdmins,cn=Groups,cn=OracleContext...)

デフォルト所有者: アイデンティティ管理レルムを作成したユーザー。

デフォルトでは、ACLは、関連する権限を設定するOracle Internet Directoryのディレクトリ・ルートに設定されるため、OracleSecurityAdminsはOracleユーザー・セキュリティを管理できます。

OraclePasswordAccessibleDomains

DN: (cn=OraclePasswordAccessibleDomains,cn=Groups,cn=OracleContext)

デフォルト所有者: OracleDBSecurityAdminsと同じ。

グループ・メンバーは、パスワード認証されたエンタープライズ・ユーザーに対して有効なデータベースを含むエンタープライズ・ドメインです。
1.1.3.7 パスワード・ポリシー

パスワード・ポリシーは、アイデンティティ管理レルム内のユーザー・パスワードすべてに適用されるルール・セットです。パスワード・ポリシーには、パスワードの難易度、パスワードの最低限の文字数などが含まれます。アカウントのロックアウトとパスワード有効期限の設定も含まれます。

パスワード・ポリシー・エントリは、Oracle Internet Directoryでアイデンティティ管理レルムごとに定義されます。Oracle Internet Directory内のパスワード・ポリシーは標準のOracle Internet Directoryエントリで、Oracle Databaseでエンタープライズ・ユーザー・セキュリティに使用できます。

Oracle Internet Directoryでは、すべてのエンタープライズ・ユーザー・パスワードがレルムに対するパスワード・ポリシー・エントリで指定されたルールと一致していることを確認します。データベースは、エンタープライズ・ユーザーの認証時にOracle Internet Directoryと通信します。Oracle Internet Directoryに対して、パスワード・ポリシー違反をレポートするようにリクエストします。データベースは、Oracle Internet Directoryからポリシー違反レスポンスを受け取ると、適切な警告またはエラー・メッセージをユーザーに表示します。

データベースは次のイベントをレポートします:

  • ユーザー・パスワードがまもなく期限切れになる場合に警告を表示し、ユーザーが自分のパスワードを何日以内に変更する必要があるかを表示します。

  • パスワードが期限切れになった場合に警告を表示し、残っている猶予期間ログイン数についてユーザーに通知します。

  • ユーザー・パスワードが期限切れになり、ユーザーに猶予期間ログインが残っていない場合に、エラーを表示します。

  • ログイン試行に繰り返し失敗したためにユーザー・アカウントがロックされた場合に、エラーを表示します。

    注意:

    SYSDBAエンタープライズ・ユーザーは、失敗ログイン数を使用でき、データベースの最新の状態(稼働または停止)を確認できます。

  • ユーザー・アカウントが管理者によって無効にされている場合に、エラーを表示します。

  • ユーザー・アカウントが非アクティブである場合に、エラーを表示します。

エンタープライズ・ユーザーのデータベースへのログイン試行により、Oracle Internet Directoryではユーザー・アカウント・ステータスが更新されます。たとえば、データベースへのログイン試行が連続して失敗すると、ディレクトリのパスワード・ポリシーに従って、そのアカウントはディレクトリでロックされます。

関連項目:

パスワード・ポリシーとその管理の詳細は、Oracle Fusion Middleware Oracle Internet Directory管理者ガイドを参照してください。

1.2 エンタープライズ・ユーザー・セキュリティにおける共有スキーマの使用方法

次の各項では、共有スキーマとその設定方法について説明します。

1.2.1 エンタープライズ・ユーザー・セキュリティで使用される共有スキーマの概要

ユーザーは、必ずしも各データベースに個々のアカウントまたはスキーマを設定する必要はありません。かわりに、共有スキーマに接続して、ターゲット・アプリケーションに関連付けられているオブジェクトへのアクセス権を自身に付与できます。たとえば、Tom、DickおよびHarrietの3人のユーザーが財務データベース上の給与アプリケーションに対するアクセス権を必要としているとします。これらのユーザーは、データベースに固有のオブジェクトを作成する必要がないため、独自のスキーマを必要としませんが、給与スキーマのオブジェクトに対するアクセス権が必要です。

Oracle Databaseでは、エンタープライズ・ディレクトリに格納されている複数のユーザーを個々のデータベース上の共有スキーマにマップできます。このようにユーザーとスキーマを分離すると、データベース上のユーザー・アカウント数が減るため、管理コストが削減されます。つまり、ディレクトリ内でのユーザーの作成に加えて各ユーザー(ユーザー・スキーマ)のアカウントを作成する必要はありません。かわりに、エンタープライズ・ディレクトリにユーザーを作成し、そのユーザーを共有スキーマにマップできます。他のエンタープライズ・ユーザーをそのスキーマにマップすることもできます。

たとえば、Tom、DickおよびHarriet全員が売上データベースと財務データベースの両方にアクセスする場合は、それぞれのデータベースに各ユーザーのアカウントを作成する必要はありません。かわりに、3人のユーザー全員がアクセスできるGUESTなどの単一の共有スキーマを各データベースに作成できます。次に、エンタープライズ・ロールを使用して、売上データベースまたは財務データベース内のオブジェクトへの個々のアクセス権をこの3人のユーザーに付与します。一般的な環境では、最大5,000のエンタープライズ・ユーザーを1つの共有スキーマにマップして、各ユーザーにエンタープライズ・ロールのセットを割り当てることができます。

オブジェクトを含まない別の共有スキーマを作成して、エントリ・ポイントとして使用することをお薦めします。その後、エンタープライズ・ロールを介して他のスキーマのアプリケーション・オブジェクトに対するアクセス権を付与してください。アクセス権をこのように付与しないと、アプリケーション・オブジェクトが不注意または故意に削除または変更される可能性があります。

要約すると、共有スキーマには次の利点があります。

  • 共有スキーマによって、各エンタープライズ・ユーザーに対してデータベースごとに専用のデータベース・スキーマを保持する必要がなくなります。

  • 各エンタープライズ・ユーザーを、そのユーザーがアクセスする必要がある各データベース上の共有スキーマにマップできます。ユーザーは、データベースへの接続時に共有スキーマに接続します。

  • 共有スキーマによって、エンタープライズ内のユーザー管理に必要なコストが削減されます。

1.2.2 エンタープライズ・ユーザーに対して共有スキーマを構成する方法

共有スキーマを構成するには、ローカル・データベース管理者(DBA)がデータベースに1つ以上のデータベース・スキーマを作成する必要があります。エンタープライズ・ユーザーをこのスキーマにマップできます。

次の例では、管理者が共有スキーマを作成し、ユーザーをそのスキーマにマップします。

  1. 管理者は、EMPLOYEEというグローバル共有スキーマおよびグローバル・ロールHRMANAGERをHRデータベースに作成します。

  2. 管理者は、Oracle Internet Directoryセルフ・サービス・コンソールおよびOracle Enterprise Managerを使用して、ディレクトリでエンタープライズ・ユーザーとロールを作成および管理します。たとえば、管理者は、エンタープライズ・ユーザーHarrietと、MANAGERというエンタープライズ・ロールを作成します。次に、HRデータベース・グローバル・ロールHRMANAGERをエンタープライズ・ロールMANAGERに割り当てます。

  3. 管理者は、エンタープライズ・ロールをディレクトリ内のエンタープライズ・ユーザーに割り当てます。たとえば、エンタープライズ・ロールMANAGERをHarrietに割り当てます。

  4. 管理者は、Oracle Enterprise Managerを使用して、ディレクトリ内のユーザーHarrietをHRデータベース上の共有スキーマEMPLOYEE にマップします。

Harrietは、HRデータベースに接続すると、EMPLOYEEスキーマに自動的に接続され、グローバル・ロールHRMANAGERが付与されます。複数のエンタープライズ・ユーザーを同じ共有スキーマにマップできます。たとえば、エンタープライズ・セキュリティ管理者は、別のエンタープライズ・ユーザーScottを作成し、EMPLOYEEスキーマにマップできます。この場合、HRデータベースに接続すると、HarrietとScottはいずれもEMPLOYEEスキーマを自動的に使用することになりますが、それぞれ異なるロールを持つことができ、個々に監査されます。

関連項目:

監査の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

1.2.3 エンタープライズ・ユーザーをスキーマにマップする方法

グローバル・スキーマ(CREATE USER IDENTIFIED GLOBALLY AS ''で作成されるスキーマ)は、1人のエンタープライズ・ユーザーが所有すること(排他スキーマ)も、複数のエンタープライズ・ユーザーが共有すること(共有スキーマ)もできます。1人のエンタープライズ・ユーザーとその排他スキーマの間のマッピングは、ユーザーDNとスキーマ名の間の関連付けとしてデータベースに格納されます。エンタープライズ・ユーザーと共有スキーマの間のマッピングは、1つ以上のマッピング・オブジェクトを使用してディレクトリ内で行われます。マッピング・オブジェクトは、ユーザーの識別名(DN)を、ユーザーがアクセスするデータベース・スキーマにマップするために使用されます。マッピング・オブジェクトは、Oracle Enterprise Managerを使用して作成します。このマッピングは、次のいずれかです。

  • エントリ・レベル(完全DN)マッピング

    この方法によって、単一のディレクトリ・ユーザーのDNがデータベース上の特定のスキーマに関連付けられます。その結果、ユーザーごとに1つのマッピング・エントリが作成されます。

  • サブツリー・レベル(部分DN)マッピング

    この方法によって、複数のエンタープライズ・ユーザーがDNの一部を共有し、同じ共有スキーマにアクセスできます。この方法は、ディレクトリ・ツリー内の共通ルートの下に複数のエンタープライズ・ユーザーがすでにグループ化されている場合に役立ちます。これらのユーザーが共有するサブツリーは、データベース上の共有スキーマにマップできます。たとえば、技術部門のサブツリー内にあるエンタープライズ・ユーザーをすべて、バグ・データベース上の1つの共有スキーマBUG_APP_USERにマップできます。サブツリーのルートは、指定されたスキーマにマップされないことに注意してください。

    エンタープライズ・ユーザーがデータベースに接続すると、データベースは、ネットワーク(SSLの場合)またはディレクトリ(パスワード認証およびKerberos認証エンタープライズ・ユーザーの場合)からユーザーのDNを取得します。

    ユーザーの接続先となるスキーマを判断するとき、データベースはユーザーDNと次の優先ルールを使用します。

    1. ローカル(データベース内)で排他スキーマを探します。

    2. ローカルで排他スキーマが見つからない場合は、ディレクトリを探します。ディレクトリ内では、データベース・サーバー・エントリの下で、まずエントリ・レベル・マッピングを探し、次にサブツリー・レベル・マッピングを探します。

    3. サーバー・エントリの下でマッピング・エントリが見つからない場合は、エンタープライズ・ドメイン・エントリの下で、まずエントリ・レベル・マッピングを探し、次にサブツリー・レベル・マッピングを探します。

    4. ローカルで排他スキーマが見つからない場合またはデータベース内に適切なマッピング・エントリがない場合、データベースは接続を拒否します。それ以外の場合、データベースはユーザーを適切なスキーマに接続します。

たとえば、HarrietがHRデータベースに接続しようとしていて、Harrietの排他スキーマが(データベース内で)見つからないとします。この場合、次のイベントが発生します。

  1. HRデータベースは、ディレクトリ内でHarrietのDNでユーザー・スキーマ・マッピングを探します。ディレクトリには、Harrietから共有スキーマEMPLOYEEへのマッピングがあり、このスキーマが返されます。

  2. データベースはHarrietのログインを許可し、HarrietをEMPLOYEEスキーマに接続します。

  3. データベースは、このデータベースに対するこのユーザーのグローバル・ロールをディレクトリから取得します。

  4. また、ユーザーがマップされているデータベース・スキーマに関連付けられているローカル・ロールおよび権限をデータベース独自の表から取得します。

  5. データベースは、グローバル・ロールとローカル・ロールの両方を使用して、ユーザーがアクセスできる情報を判断します。

引き続きこの例で、エンタープライズ・ロールMANAGERにHRデータベース上のグローバル・ロールANALYSTと、給与データベース上のUSERが含まれるとします。エンタープライズ・ロールMANAGERを持つHarrietは、HRデータベースに接続するときに、そのデータベース上のスキーマEMPLOYEE を使用します。

  • HRデータベースに対する彼女の権限は、次の内容によって判断されます。

    • グローバル・ロールANALYST

    • HRデータベース上のEMPLOYEE スキーマに関連付けられているローカル・ロールと権限

  • Harrietが給与データベースに接続する場合、その権限は次の内容によって判断されます。

    • グローバル・ロールUSER

    • 給与データベース上のEMPLOYEEスキーマに関連付けられているローカル・ロールと権限

データベース・スキーマにロールおよび権限を付与することにより、指定したユーザー・グループに権限を付与できます。このようなスキーマを共有するすべてのユーザーは、個人のエンタープライズ・ロールに加えてこれらのローカル・ロールおよび権限を取得します。ただし、この共有スキーマにマップされるユーザーはすべて、このスキーマに割り当てられた権限を実行できるため、これを行う場合は十分な注意が必要です。このため、共有スキーマにロールおよび権限を付与することはお薦めしません。

関連項目:

1.3 エンタープライズ・ユーザー・プロキシ

エンタープライズ・ユーザーは、一時的にターゲット・ユーザーの認可と権限を取得して、別のユーザーとしてデータベースへの接続が必要になる場合があります。この機能は、様々なデータベースに対してエンタープライズ・ユーザーとして動作し、識別情報がOracle Internet Directoryのエントリとして設定されていることが多い中間層のツールまたはアプリケーションに特に役立ちます。このようなアプリケーションは、各エンド・ユーザーの識別情報を切り替えながら単一のデータベース接続を保持できるため、認可された各ユーザーの名前で動作することができます。

エンタープライズ・ユーザー・セキュリティ11gリリース1 (11.1)では、シングル・セッション・モデルの導入によって、プロキシ・メカニズムの効率が強化されています。2セッション・プロキシ・モデルでは、プロキシ・ユーザーとターゲット・ユーザーに別個のセッションを保持する必要がありました。新しいモデルでは、1つのセッションのみがターゲット・ユーザーのセキュリティ・コンテキスト内で保持されます。これにより、パフォーマンスが向上します。

エンタープライズ・ユーザー・セキュリティ11gリリース1 (11.1)以上を使用すると、エンタープライズ・ユーザーにプロキシ権限を細かく割り当てることができます。エンタープライズ・ユーザーには、ローカル・データベース・ユーザーのプロキシとして動作する権限を個別に付与できます。そのため、権限をデータベース内のユーザーの共有スキーマに関連付ける必要はありません。

エンタープライズ・ユーザーに個別にプロキシ権限を割当てできるということは、権限をより厳密に設定できることを意味します。それに対して、共有スキーマに権限を割り当てる場合は、スキーマにマップするすべてのユーザーに同じ権限を割り当てることになります。これによって、保証されていない権限が付与される可能性があります。

エンタープライズ・ユーザーのプロキシ権限は、Oracle Internet Directoryで作成および格納されます。1つの権限で、1つ以上のエンタープライズ・ユーザーまたはグループをターゲット・データベース・ユーザーのプロキシとして設定できます。権限は、エンタープライズ・ドメイン内の特定のデータベースまたはすべてのデータベースに適用できます。

デフォルトでは、ドメイン管理者はエンタープライズ・ドメインのディレクトリでプロキシ権限を管理できます。これらの権限は、Oracle Enterprise Managerを使用して構成および管理されます。

関連項目:

エンタープライズ・ユーザーのプロキシ権限の構成方法は、「プロキシ権限の構成」を参照してください。

このようなプロキシを設定するには、次の手順に従います。

  1. 様々なデータベースに対するプロキシ権限が必要なすべてのエンタープライズ・ユーザーを特定します。

  2. 対象となる各データベース内のターゲット・ユーザーをすべて特定します。

  3. 対象となるターゲット・ユーザーごとに、次の形式でALTER USERコマンドを発行します。

    • ALTER USER target_user GRANT CONNECT THROUGH ENTERPRISE USERS

    これにより、Oracle Internet Directoryでプロキシ権限を持つエンタープライズ・ユーザーが、target_userのプロキシとして動作できるようになります。プロキシ権限を取り消す場合は、同じ構文を使用し、GRANTをREVOKEで置き換えます。

    関連項目:

    完全なALTER USER構文は、『Oracle Database SQL言語リファレンス』を参照してください。

    Oracle Call Interfaceの使用方法は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。

  4. 各エンタープライズ・ユーザーに個別に、またはグループのメンバーとして、プロキシ権限を付与します。詳細は、「エンタープライズ・ユーザーへのプロキシ権限の付与」を参照してください。

    注意:

    同じデータベース・ユーザーのプロキシとして動作するエンタープライズ・ユーザーを表すグループを設定するには、Oracle Delegated Administration Servicesを使用します(『Oracle Identity Management委任管理ガイド』を参照)。

  5. 前述の4つのステップをすべて完了すると、特定したエンタープライズ・ユーザーを、特定して関連付けたすべてのローカル・データベース・ユーザーのプロキシとして設定できます。2つのバージョンのCONNECTコマンドを使用できます。(a)の場合は、コマンドでエンタープライズ・ユーザーのパスワードを指定します。(b)の場合は、パスワードを指定せず、かわりに、sqlnet.oraファイルにその場所が記述されているウォレット内のパスワードを利用します。

    1. エンタープライズ・ユーザーのプロキシ接続をデータベース・ユーザーとして確立するには、次のSQL*Plusコマンド構文を使用し、エンタープライズ・ユーザーのパスワードを指定します。

      • CONNECT joeproxy[targetuser]@database_service_name
Enter Password:

        ここで、joeproxyをtargetuserとしてプロキシするエンタープライズ・ユーザーの名前に、targetuserをターゲット・データベースの登録ユーザーの名前にそれぞれ置き換えます。大カッコは必須です。パスワードの入力を求められたら、エンタープライズ・ユーザーのパスワードを入力します。

      これらのIDが検証されると、この接続要求によって単一のセッションが生成され、このセッションでプロキシ・ユーザーはターゲット・データベースでターゲット・ユーザーとして動作します。元のユーザーのIDは、そのデータベースに対して保持されるため、監査レコードはプロキシ・ユーザーとターゲット・ユーザーの両方のIDを取得できます。

    2. パスワードを指定せずに、データベース・ユーザーに対するエンタープライズ・ユーザー・プロキシとして接続する場合は、sqlnet.oraファイルにそのユーザーのパスワードを保持するウォレットの場所が指定されていることを確認します。確認後、次のコマンド構文を使用します。 

      • CONNECT  [targetuser]/@database_service_name

        ここで、targetuserをターゲット・データベースの登録ユーザーの名前に置き換えます。大カッコは必須です。現行のエンタープライズ・ユーザーがtargetuserのプロキシとなります。

注意:

OCIコールを使用する通常のプロキシ・ログイン・メカニズムも使用できます。CONNECT構文は、新しい代替構文です。OCIコール・メカニズムの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

エンタープライズ・ユーザーのプロキシ権限はOracle Internet Directoryで割り当てられますが、データベース管理者は、エンタープライズ・ユーザーのプロキシ・ターゲットとして使用できるローカル・アカウントを決定できます。エンタープライズ・ドメイン管理者は、データベースのdba_proxiesビューで使用可能なターゲットに対してのみプロキシ権限を割り当てることができます。

1.4 エンタープライズ・ユーザー・セキュリティにおける現行ユーザーのデータベース・リンクの使用方法

Oracle Databaseは、SSL認証ネットワーク接続を介して現行ユーザーのデータベース・リンクをサポートします。現行ユーザーのデータベース・リンクを使用すると、ユーザー自身として、または別のユーザーが所有するストアド・プロシージャ内から使用される場合はそのユーザーとして、2つ目のデータベースに接続できます。このようなアクセスは、プロシージャの範囲内に制限されます。現行ユーザーのデータベース・リンクのセキュリティ上の利点は、別のユーザーの資格証明がデータベース・リンク定義に格納されず、データベース間のネットワーク接続を介して送信されないことです。かわりに、これらのリンクのセキュリティは、データベース間の相互信頼、相互認証およびセキュアなネットワーク接続に基づいています。

たとえば、現行ユーザーのデータベース・リンクをプロシージャ内から使用すると、財務データベースのユーザーであるHarrietは、エンタープライズ・ユーザーScottとして接続することによって買掛管理データベースにアクセスできます。

Harrietが現行ユーザーのデータベース・リンクにアクセスしてスキーマScottに接続するには、Scottが両方のデータベースで(IDENTIFIED GLOBALLYとして作成される)グローバル・スキーマであることが必要です。ただし、Harrietは、次の3つの方法のいずれかで識別されるユーザーとなります。

  • パスワード

  • GLOBALLY

  • EXTERNALLY

1つ目の財務データベースでScottをグローバル・ユーザーとして作成するには、次のように入力する必要があります。

CREATE USER Scott IDENTIFIED GLOBALLY as 'CN=Scott,O=nmt'

これにより、Scottは排他スキーマを持つことができます。そして、Scottは2つ目の買掛管理データベース内の共有スキーマにマップできます。現行ユーザーのデータベース・リンクが機能するために、1つ目のデータベースでScott用に作成されたスキーマを他のユーザーと共有することはできません。

現行ユーザーのデータベース・リンクは、1つのエンタープライズ・ドメイン内の信頼できるデータベース間でのみ機能します。ドメイン内のデータベースは相互に信頼してユーザーを認証します。エンタープライズ・ドメインを信頼できるものとして指定するには、Oracle Enterprise Managerを使用します。Oracle Enterprise Managerを使用して現行ユーザーのデータベース・リンクをドメインに対して有効にすると、それらのリンクはそのドメイン内のすべてのデータベースに対して機能します。ただし、ドメイン内の各データベースは独自のPKI資格証明を持ち、SSLを使用して他のデータベースに対して認証されます。信頼できるエンタープライズ・ドメインの一部であるデータベースを信頼できないものとして指定するには、PL/SQLパッケージのDBMS_DISTRIBUTED_TRUST_ADMINを使用します。信頼できるサーバーのリストを取得するには、TRUSTED_SERVERSビューを使用します。

注意:

Oracle Database Enterprise EditionのオプションであるOracle Advanced Securityでは、データベース・リンクを介したRADIUS認証をサポートしていません。

関連項目:

1.5 エンタープライズ・ユーザー・セキュリティのデプロイの考慮事項

エンタープライズ・ユーザー・セキュリティをデプロイする前に、次の点について検討します。

1.5.1 セキュリティ資格証明の集中化に関するセキュリティの問題

エンタープライズ・ユーザーとそれに関連付けられた資格証明の一元管理には一般的な利点がありますが、検討が必要なセキュリティ関連の利点と危険性もたくさんあります。次の各項では、これらの利点とリスクについて説明します。
1.5.1.1 集中化されたセキュリティ資格証明管理に関連するセキュリティ上の利点

管理を一元化すると、ユーザー、資格証明およびロールの管理が簡単かつ迅速になり、エンタープライズ全体のすべてのアプリケーションおよびデータベースに対するユーザーの権限を迅速に取り消すことができます。一元管理を行うと、管理者は1箇所でユーザーを削除してすべてのグローバル権限を取り消すことができるため、不要な権限が保持される危険性を最小限に抑えることができます。

管理を一元化すると、組織のセキュリティ技術を集中させることができます。セキュリティに詳しい専門知識のある管理者は、ディレクトリのセキュリティ、ユーザー・ロールと権限、データベース・アクセスなど、エンタープライズ・ユーザー・セキュリティに関するあらゆる側面を管理できます。これは従来のモデルよりも大幅に改善された点であり、従来のモデルでは、通常DBAは、セキュリティを含め、管理するデータベース上のすべてに対して責任を負っていました。

1.5.1.2 集中化されたセキュリティ資格証明管理に関連するセキュリティ上のリスク

Oracle Internet Directoryはセキュアなリポジトリですが、パブリックからアクセス可能なリポジトリで資格証明を一元管理する場合には、セキュリティ上の問題と固有のリスクがあります。一元化された資格証明は、少なくとも分散された資格証明と同程度には保護できますが、一元化の性質により、認可されていない第三者に資格証明が誤って公開される可能性が高まります。したがって、管理者の権限を制限し、ディレクトリ内に制限されたアクセス制御リスト(ACL)を設定するとともに、管理者が一時的にディレクトリから離れる場合にセキュリティ資格証明を保護する適切なセキュリティ・プラクティスを実装することが不可欠です。

1.5.2 パスワード認証されたエンタープライズ・ユーザー・データベース・ログイン情報のセキュリティ

すべてのセキュア・パスワードベース認証方式では、サーバーは、パスワード・ベリファイアでクライアントを認証します。パスワード・ベリファイアは、通常は厳重に保護する必要のあるパスワードのハッシュ・バージョンです Oracleデータベースでのパスワード・ベースの認証もこれと同じです。パスワード・ベリファイアが用意されており、同様に保護する必要があります。これは、ベリファイアがデータベース内にローカルに格納されている場合、またはディレクトリで集中管理されている場合のどちらにも当てはまります。パスワード・ベリファイアを使用して、元のパスワードを取得することはできません。

エンタープライズ・ユーザーのデータベース・パスワードは、複数のデータベースからアクセスできるように中央ディレクトリ・サービスに格納できます。このパスワードは、ユーザーがアクセス可能なすべての信頼できるデータベースから表示および共有できます。ディレクトリに格納されているパスワード・ベリファイアは、クリアテキストのパスワードではありませんが、偶発的なアクセスや不正なアクセスから保護する必要があります。したがって、ディレクトリにパスワードに関連したACLを定義することが非常に重要になり、ACLには、必要なアクセスと操作性を確保しながら、可能なかぎりの制限を行います。(Oracle Databaseは、Oracle Internet Directoryによってサポートされるすべてのベリファイア・タイプをサポートします。)

Oracleのツール製品を使用して、アイデンティティ管理レルムの作成時にこれらのパスワード検証を保護するためのACLをディレクトリに設定できます。お薦めする方式は、セキュリティと操作性の各考慮事項のバランスをとることを目的としています。最大限のセキュリティが必要であり、すべてのユーザーにウォレットを設定できる場合は、ユーザーからデータベースへの接続にSSLのみを使用します。SSLのみの方式を使用すると、ディレクトリ・パスワードの保護問題をそっくり回避することができます。

次の各項では、信頼できるデータベースおよびディレクトリ内でデータベース・パスワード・ベリファイアを保護する方法の詳細について説明します。
1.5.2.1 信頼できるデータベースとは

SSLでは厳密認証が行われるため、データベースは各自の識別情報によって信頼性を確保します。パスワード認証を使用するエンタープライズ・ユーザー・セキュリティでは、データベース・パスワード検証がディレクトリに一元的に格納され、複数のデータベース間で共有されますが、パスワード認証エンタープライズ・ユーザーにログインを許可する各データベースは信頼できるデータベースである必要があります。各データベースは共有パスワード検証にアクセスできるため、次のセキュリティ対策を順守する信頼できるデータベースであることが重要です。

  • 各データベースは、サーバー・コードの改ざんからデータベース自体を保護する信頼できるデータベースであることが必要です。これにより、悪意のあるユーザーがデータベースの識別情報を悪用してディレクトリ内のパスワード検証にアクセスできなくなります。

  • 各データベースは、データベース自体のPKIおよびその他の資格証明を盗用から保護する信頼できるデータベースであることが必要です。これにより、悪意のあるユーザーがPKIやその他の資格証明を使用してディレクトリに格納されているパスワード検証にアクセスできなくなります。

1.5.2.2 データベース・パスワード・ベリファイアの保護

各アイデンティティ管理レルム内のOraclePasswordAccessibleDomainsグループは、レルムの作成時に自動的に作成され、Oracle Internet Directoryセルフ・サービス・コンソールなどのOracle Internet Directoryツールを使用して管理できます。このグループには、ディレクトリに格納されているユーザーのデータベース・パスワード検証を参照する必要があるメンバー・データベースを含むエンタープライズ・ドメインが配置されます。

選択したレルムに対して、パスワード認証接続を受け入れるデータベースを決定します。Oracle Internet Directoryセルフ・サービス・コンソールを使用して、これらのデータベースを含むドメインをOraclePasswordAccessibleDomainsグループに配置します。ユーザー・サブツリーのACLにより、データベースで使用するパスワード検証を保持するディレクトリ属性へのアクセスが許可されます。

他のすべてのユーザーは、この属性へのアクセスを拒否されます。パスワード検証の属性への匿名読取りアクセスを防止するACLは、ディレクトリ・ツリーのルートにあります。

操作性を考慮し、デフォルトでは、OracleDefaultDomainはOraclePasswordAccessibleDomainsグループのメンバーとなります。これは必要に応じて削除できます。

1.5.3 エンタープライズ・ドメインのデータベース・メンバーシップの定義に関する考慮事項

ドメインのデータベース・メンバーシップを定義する場合は、次の基準を考慮します。

  • 現行ユーザーのデータベース・リンクは、1つのエンタープライズ・ドメイン内のデータベース間でのみ機能します。これらのリンクを使用するには、これらのデータベース間およびこれらを管理するDBA間に相互信頼が必要です。

  • エンタープライズ・ユーザーに適用される認証タイプは、ドメイン・レベルで定義されます。したがって、ドメイン内のデータベース・メンバーシップはそのタイプに応じて定義する必要があります。

    注意:

    1つ以上のデータベースでSSLベースの証明書認証のみをサポートする場合、それらのデータベースを同じドメイン内でパスワード認証のデータベースと組み合せることはできません。

  • エンタープライズ・ロールはドメイン・レベルで定義されます。複数のデータベース間でエンタープライズ・ロールを共有するには、データベースが同じドメインのメンバーであることが必要です。

1.5.4 エンタープライズ・ユーザー・セキュリティのクライアント、データベースおよびディレクトリ間の認証タイプの選択に関する考慮事項

エンタープライズ・ユーザー・セキュリティでは、クライアント、データベースおよびディレクトリ間の接続に対して、表1-3に示す認証タイプをサポートしています。

表1-3 エンタープライズ・ユーザー・セキュリティ: クライアント、データベースおよびディレクトリ間の接続に対してサポートされる認証タイプ

接続 サポートされる認証タイプ

クライアントからデータベース

パスワード、SSLおよびKerberos

データベース間(現行ユーザーのデータベース・リンク)

SSLのみ

データベースからディレクトリ

SSLおよびパスワード

ただし、接続に対する認証タイプの組合せの中には、他の組合せに比べて妥当なものもあります。たとえば、すべてのユーザー接続に対してSSLを使用し、クライアントとデータベース間の接続に高レベルのセキュリティを設定しながら、ディレクトリに対する認証にパスワードを使用するようにデータベースを構成することは、通常ありません。この構成はサポートされますが、接続に一貫性のあるセキュリティは提供されません。データベースとディレクトリ間の接続には、ユーザーとデータベース間の接続と同じレベル以上の安全性を持たせることが理想的です。

次の項「標準構成」で標準構成について説明します。

1.5.4.1 標準構成

クライアント、データベースおよびディレクトリ間で使用する認証タイプの一般的な組合せは、次のとおりです。

  • 現行ユーザーのデータベース・リンクを必要としないすべての接続に対してパスワード認証を使用します。

  • すべての接続に対してSSL認証を使用します。

  • クライアントとデータベース間の接続にはKerberos認証を使用し、データベースとディレクトリ間の接続にはパスワード認証を使用します。