エンタープライズ・ユーザー・セキュリティは、Oracle Database 11gリリース1(11.1)Enterprise Editionの重要なコンポーネントです。エンタープライズ・ユーザー・セキュリティを使用すると、多くのエンタープライズ・データベース・ユーザーの管理およびセキュリティ上の問題に対応できます。エンタープライズ・ユーザーとは、ディレクトリに定義されたユーザーを指します。ユーザー識別情報は、エンタープライズ内で常に一定です。エンタープライズ・ユーザー・セキュリティは、Oracle Identity Managementインフラストラクチャに依存しています。このインフラストラクチャは、LDAP準拠のディレクトリ・サービスを使用して、ユーザーを一元的に格納し管理します。
この章では、エンタープライズ・ユーザー・セキュリティの内容とその仕組みについて説明します。項目は次のとおりです。
この概要では、組織にとってのエンタープライズ・ユーザー・セキュリティの利点、エンタープライズ・ユーザーが認証される仕組みおよび分散データベース・システム全体にわたるリソースにアクセスする仕組みについて説明します。ここでは、次の項目について説明します。
管理者は、エンタープライズ全体のユーザー情報を最新かつセキュアな状態に保つ必要があります。このタスクはアプリケーションとユーザーの数が増えるにつれてますます難しくなっています。通常は、個々のユーザーが様々なデータベース上に複数のアカウントを持っています。これは、各ユーザーが複数のパスワードを覚えておく必要があることを意味します。その結果、ユーザーはパスワードが多すぎて覚えられず、管理者はアカウント数が多すぎて効率的に管理できないという状態に陥っています。
何千ものユーザーがデータベース・アカウントにアクセスするため、ユーザー管理には多くのリソースが必要です。ユーザー名、電話番号、システム・ロール、システム権限など、複数のアプリケーションで使用される共通の情報は、多くの場合、エンタープライズ内に分散して存在しています。このように、冗長で一貫性のないデータが増えるため、データの管理が困難になっています。
ユーザーとアカウントの管理の問題に加えて、これらの状況によりセキュリティの問題も発生します。たとえば、あるユーザーが退職するか、職務が変更になった場合は、そのユーザーの権限が悪用されることを防ぐため、その日のうちにユーザーの権限を変更する必要があります。しかし、大規模な企業ではたいていの場合、複数のデータベースに分散したユーザー・アカウントが多く、管理者は適時に変更できないことがあります。
同様に、ユーザーがあまりにも多くのパスワードを持っている場合、それらのパスワードをメモに書き留めることで、他者がパスワードを簡単に書き写せるようになることがあります。また、覚えやすいパスワードを選択し、他者が簡単に推測できるようになる場合や、複数のアプリケーションに同じパスワードを使用し、パスワードが見破られてセキュリティ上のリスクが高まる場合もあります。複数のパスワードを覚えておくためのユーザーの工夫はすべて、エンタープライズ・セキュリティを危険にさらす可能性があります。
エンタープライズ・ユーザー・セキュリティでは、LDAP準拠のディレクトリ・サービスであるOracle Internet Directoryで提供されるアイデンティティ管理サービスによって、ユーザー、管理およびセキュリティに関する問題に対応しています。アイデンティティ管理は、ネットワーク・エンティティのセキュリティ・ライフ・サイクル全体を組織で管理するプロセスです。通常、アイデンティティ管理は組織のアプリケーション・ユーザーの管理を指します。セキュリティ・ライフ・サイクルにおけるアイデンティティ管理の手順には、アカウントの作成、保留、権限の変更およびアカウントの削除が含まれます。
図1-1に、Oracle Identity Managementインフラストラクチャを基盤として使用するOracleセキュリティ・アーキテクチャに、エンタープライズ・ユーザー・セキュリティを組み込む仕組みを示します。
ユーザーは、管理者が選択した構成に応じて、シングル・サインオン(SSO)または単一パスワード認証を通じてエンタープライズ・ユーザー・セキュリティを利用します。シングル・サインオンを使用する場合、ユーザーの認証が必要なのは1回だけで、その後の認証は透過的に行われます。この機能ではSSLが必要です。Oracle Identity ManagementインフラストラクチャのコンポーネントであるOracleAS Single Sign-Onと混同しないようにしてください。
単一パスワード認証では、ユーザーは単一のグローバルなパスワードで複数のデータベースに対して認証されます。ただし、各接続では固有の認証を必要とします。パスワードは中央に位置するLDAP準拠のディレクトリに安全に格納され、暗号化やアクセス制御リスト(ACL)などのセキュリティ・メカニズムで保護されます。この方式では、記憶および管理するパスワード数が減少し、SSLの設定に伴うオーバーヘッドが解消されるため、操作性が向上します。
エンタープライズ・ユーザー・セキュリティを使用するには、Oracle Internet Directory 10g(9.0.4)以上が必要です。その他のLDAP準拠のディレクトリ・サービスは、Oracle Directory Integration Platformを使用してOracle Internet Directoryと同期することによりサポートされます。
この項では、次の項目について説明します。
関連項目: Oracle Directory Integration Platformを他のディレクトリとともに使用する方法は『Oracle Internet Directory管理者ガイド』を参照してください。 |
注意: Microsoft Active Directoryは、Windowsプラットフォーム上のOracleデータベースに対してのみサポートされます。 |
Oracle Internet Directoryでは、アイデンティティ管理レルムの概念を使用して、情報をディレクトリ情報ツリー(DIT)内に整理します。DITは、ディレクトリ・オブジェクト・エントリから構成される階層ツリー型の構造です。ディレクトリでは、オブジェクトに関する情報の個々のコレクションをエントリと呼びます。このオブジェクトは人の場合もありますが、構成情報などのネットワーク・デバイスに関する情報の場合もあります。DIT内のディレクトリ・オブジェクトの名前を指定し、場所を識別するために、各エントリには一意の識別名(DN)が割り当てられます。エントリのDNは、そのエントリ自体と親エントリから構成され、そのエントリからDITのルート(最上位)エントリまで昇順に連結されます。
アイデンティティ管理レルムは、ディレクトリ・エントリのサブツリーであり、そのすべてが同じ管理ポリシーによって管理されます。たとえば、イントラネットにアクセスできるエンタープライズ内のすべての従業員はある1つのレルムに属し、エンタープライズのパブリック・アプリケーションにアクセスするすべての外部ユーザーは他のレルムに属します。異なるレルムを使用することによって、ユーザー集団を分離し、各レルムで異なる管理ポリシー(パスワード・ポリシーやネーミング・ポリシーなど)を適用できます。ログインIDの識別に使用されるデフォルトのニックネーム属性はuidで、アイデンティティ管理レルムごとに設定されます。
各アイデンティティ管理レルムには、そのレルムのOracle製品情報を格納するレルム固有のOracleコンテキスト(レルムOracleコンテキスト)があります。レルムOracleコンテキストには、アプリケーション・データ、ユーザーの命名と配置の方法、ユーザーの認証方法、グループの位置および権限の割当てが格納されます。これらの情報はすべて、レルムOracleコンテキストが配置されている特定のアイデンティティ管理レルム固有の情報です。
関連項目:
|
通常、データベース・ユーザーは、次のような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つ作成します。
Oracle Internet Directoryに共有スキーマ・マッピングを1つ作成します。
エンタープライズ・ユーザーがアクセスする各データベース上の汎用共有スキーマにユーザーをマップすると、エンタープライズ・ユーザーごとに個別のスキーマを作成することで生じるオーバーヘッドが大幅に削減されます。
共有スキーマ・エンタープライズ・ユーザーは、そのユーザーがアクセスするすべてのデータベース上の汎用共有スキーマにマップできます。また、あるデータベースでは排他スキーマを持ち、別のデータベースでは共有スキーマを持つようにすることも可能です。共有スキーマ・マッピングはディレクトリに格納されます。
関連項目:
|
データベース・リンクは、ローカル・データベースまたはネットワーク定義に格納されるネットワーク・オブジェクトであり、リモート・データベース、そのデータベースへの通信パス、および場合によってはユーザー名とパスワードを識別します。定義されると、データベース・リンクはリモート・データベースへのアクセスに使用されます。Oracle Databaseでは、接続ユーザー・リンク、固定ユーザー・リンクおよび現行ユーザー・リンクをサポートしています。
エンタープライズ・ユーザーは、この3種類のデータベース・リンクをすべて使用できます。接続ユーザー・リンクには、リモート・サーバーにアカウントを持つローカル・ユーザーがアクセスします。固定ユーザー・リンクには、リンク定義の一部としてユーザー名とパスワードが含まれます。現行ユーザーのデータベース・リンクでは、エンタープライズ・ユーザーが、リンクの実行中に認証情報を渡したり、リンク定義に認証情報を格納したりせずに、リモート・データベースのオブジェクトにアクセスできます。このデータベース・リンクでは、データベース・ネットワーク接続にSSLが必要です。したがって、データベースの公開鍵インフラストラクチャ(PKI)資格証明を取得および管理する必要があります。現行ユーザーのデータベース・リンクは、エンタープライズ・ユーザーとしてリモート・データベースに接続する場合にのみ使用できます。
関連項目:
|
エンタープライズ・ユーザー・セキュリティでは、次の認証方式をサポートしています。
パスワードベースの認証
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 11gリリース1(11.1)のプロキシ認証機能により、次の両方が可能になります。(i) 多層でのユーザー名とパスワードのプロキシ (ii) 多層でのX.509証明書および識別名のプロキシ |
関連項目:
|
ディレクトリでは、オブジェクトに関する情報の個々のコレクションをエントリと呼びます。エンタープライズ・ユーザー・セキュリティの場合、ユーザー、ロール、データベースなどの要素はディレクトリ・オブジェクトであり、これらのオブジェクトに関する情報はエントリとしてディレクトリに格納されます。
ディレクトリ内の各エントリは、DNによって一意に識別されます。DNによって、一般にディレクトリ情報ツリー(DIT)と呼ばれるディレクトリ・エントリ階層内のエントリの場所が正確にわかります。
関連項目: ディレクトリ・エントリの詳細は、『Oracle Internet Directory管理者ガイド』を参照してください。 |
次の各項では、エンタープライズ・ユーザー・セキュリティに関連するディレクトリ・エントリについて説明します。
エンタープライズ・ユーザーは、ディレクトリで定義および管理されるユーザーです。各エンタープライズ・ユーザーは、エンタープライズ全体で一意の識別情報を持ちます。エンタープライズ・ユーザー・エントリは、レルム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の例では、OracleDefaultDomainの下に「Manager」というエンタープライズ・ロールがあります。
たとえば、エンタープライズ・ロールsales_manager
に、Customer Relationship Management(CRM)データベースに対する権限を持つグローバル・ロールmanage_leads
と財務データベースに対する権限を持つグローバル・ロールbonus_approval
が含まれるとします。図1-2に、この例を示します。
エンタープライズ・ロールは、1つ以上のエンタープライズ・ユーザーに割り当てることができます。たとえば、エンタープライズ・ロールsales_manager
を、同じ職務の多くのエンタープライズ・ユーザーに割り当てることができます。この情報はディレクトリで保護され、ディレクトリ管理者のみがユーザーの管理とそのロールの割当てを行うことができます。ユーザーには、エンタープライズ・ロール以外に、接続先スキーマに対する権限に基づいて、データベース内のローカル・ロールや権限も付与することができます。
エンタープライズ・ロール・エントリは、エンタープライズ・ドメイン・サブツリーに格納されます。各エンタープライズ・ロールには、各データベース・サーバーに対応するグローバル・ロールと、関連付けられたエンタープライズ・ユーザーの情報が含まれます。エンタープライズ・ドメイン管理者は、Oracle Enterprise Managerを使用してエンタープライズ・ロールを作成および管理します。
エンタープライズ・ドメインは、データベースとエンタープライズ・ロールをグループ化したものです。ドメインの例には、企業の技術部門や小規模な企業などがあります。図1-3の例では、アイデンティティ管理レルムのOracleDBSecurityエントリの下に「Services」というエンタープライズ・ドメインがあります。エンタープライズ・ドメイン管理者が、Oracle Enterprise Managerを使用してユーザーにエンタープライズ・ロールを割り当て、エンタープライズ・セキュリティを管理するのは、このエンタープライズ・ドメイン・レベルです。
ディレクトリのエンタープライズ・ドメイン・サブツリーは、そのドメインのエンタープライズ・ロール・エントリ、ユーザー・スキーマ・マッピングおよびエンタープライズ・ドメイン管理者のグループという3種類のエントリから構成されます。エンタープライズ・ドメインは、複数のデータベースに適用される情報の管理に使用されます。エンタープライズ・ドメインに含まれるすべてのユーザー・スキーマ・マッピング・エントリは、ドメイン内のすべてのデータベースに適用されます。個々のデータベースに異なるユーザー・スキーマ・マッピングを適用する必要がある場合は、次の項で説明するデータベース・サーバー・エントリを使用します。
前の項で説明したように、エンタープライズ・ロールはドメイン内の特定のデータベースに適用されます。エンタープライズ・ロール、ドメイン・レベルのマッピングおよびドメイン管理者グループは、すべてOracle Enterprise Managerを使用して管理されます。
データベース・サーバー・エントリ(図1-3では「Sales」として表されています)は、1つのデータベース・サーバーに関する情報を含むディレクトリ・エントリです。このエントリは、データベース登録時にDatabase Configuration Assistantによって作成されます。データベース・サーバー・エントリは、完全または部分的なユーザーDNとデータベース共有スキーマ名の間のマッピングを記述する、ユーザー・スキーマ・マッピングと呼ばれるデータベース・レベルのマッピング・エントリの親です。ユーザー・スキーマ・マッピング・エントリは、データベース管理者によってOracle Enterprise Managerを使用して作成されます。
データベース管理者は、Oracle Enterprise Managerで管理されるディレクトリ管理グループOracleDBAdminsに属します。OracleDBAdminsまたはOracleContextAdminsグループ・メンバーのみが、OracleDBAdminsグループに対してユーザーを追加または削除できます。ユーザーがディレクトリにデータベースを登録すると、Database Configuration Assistantによって、登録を実行したユーザーがOracleDBAdminsグループに自動的に追加されます。このグループのディレクトリ・エントリは、DITのデータベース・サーバー・エントリの下に位置します。
ユーザー・スキーマ・マッピングは、ユーザーのDNとOracleデータベース・スキーマの間のマッピング情報を含むディレクトリ・エントリです。マッピングで参照されるユーザーは、データベースへの接続時に指定されたスキーマに接続されます。ユーザー・スキーマ・マッピング・エントリは、レルムOracleコンテキスト内の場所に応じて、1つのデータベースのみ、またはドメイン内のすべてのデータベースに適用できます。
アイデンティティ管理レルムには、エンタープライズ・ユーザー・セキュリティに関連する管理グループが含まれます。図1-3では、「Groups」という三角形内に、レルムに含まれるこれらの管理グループが示されています。各管理グループには、グループ自体へのアクセスを制御するアクセス制御リスト(ACL)が含まれます。ディレクトリ内の別の場所にあるACLがこれらのグループを参照できるため、ディレクトリ管理者がアクセスして必要な管理タスクを実行できるようになります。レルムを作成した管理ユーザーは、自動的にこれらのグループそれぞれの最初のメンバーになるため、各グループに関連付けられている権限を取得します。ただし、このユーザーは削除できます。
レルム内の関連する管理グループを表1-2に示します。
注意: 次の点に注意してください。他の方法を使用すると、エンタープライズ・ユーザー・セキュリティ・オブジェクトのセキュリティ構成が無効になり、エンタープライズ・ユーザー機能も無効になる可能性があります。
|
表1-2 レルムOracleコンテキスト内の管理グループ
管理グループ | 説明 |
---|---|
DN: ( デフォルト所有者: アイデンティティ管理レルムを作成したユーザー。(インストール時に作成されたレルムの場合は、 OracleContextAdminsは、関連付けられたレルムOracleコンテキスト内のすべてのグループおよびエントリに対する完全なアクセス権を持ちます。 |
|
DN: ( デフォルト所有者: なし。Database Configuration Assistantによって、ディレクトリにデータベースを登録したユーザーが自動的にこのグループのメンバーになります。 このグループのメンバーは、このデータベース固有のユーザー・スキーマ・マッピングを管理します。すでにこのグループまたはOracleContextAdminsのメンバーであるユーザーのみが、OracleDBAdminsグループに対してユーザーを追加または削除できます。 |
|
DN: ( デフォルト所有者: OracleContextAdmins デフォルトのレルムOracleコンテキストの作成中に、Oracle Internet Directoryコンフィギュレーション・アシスタントにより、これらのグループ・メンバーに対して次のアクセス権/権限が設定されます。
OracleDBCreatorsは、Database Configuration Assistantを使用して新規データベースを作成し、ディレクトリに登録します。 |
|
DN: ( デフォルト所有者: すべてのグループ・メンバー。 デフォルトのレルムOracleコンテキストの作成中に、Oracle Internet Directoryコンフィギュレーション・アシスタントにより、これらのグループ・メンバーに対して次のアクセス権/権限が設定されます。
OracleDBSecurityAdminsは、エンタープライズ内のすべてのドメインに対する権限を持ち、次のタスクを実行します。
|
|
OracleDomainAdmins |
DN: (
デフォルト所有者: ドメインを作成または更新したユーザー。 新規コンテキストおよびOracleDefaultDomainが作成されると、初期メンバーがコンテキスト作成者になります。 OracleDomainAdminsグループのメンバーは、エンタープライズ・ドメインに対する完全な権限を持ちます。このグループのメンバーは、ドメイン全体に固有のマッピング、エンタープライズ・ロールおよびプロキシ権限を管理します。このグループのメンバーシップを変更するには、OracleDomainAdmins(ドメインの場合)、OracleDBSecurityAdminsまたはOracleContextAdminsのメンバーであることが必要です。 |
DN: ( デフォルト所有者: アイデンティティ管理レルムを作成したユーザー。 デフォルトでは、ACLは、関連する権限を設定するOracle Internet Directoryのディレクトリ・ルートに設定されるため、OracleSecurityAdminsはOracleユーザー・セキュリティを管理できます。 |
|
DN: ( デフォルト所有者: OracleDBSecurityAdminsと同じ。 グループ・メンバーは、パスワード認証されたエンタープライズ・ユーザーに対して有効なデータベースを含むエンタープライズ・ドメインです。 |
パスワード・ポリシーは、アイデンティティ管理レルム内のユーザー・パスワードすべてに適用されるルール・セットです。パスワード・ポリシーには、パスワードの複雑性、パスワードの最低文字数などの設定が含まれます。また、アカウントのロックアウトおよびパスワードの有効期限の設定も含まれます。
パスワード・ポリシー・エントリは、Oracle Internet Directoryでアイデンティティ管理レルムごとに定義されます。Oracle Internet Directory内のパスワード・ポリシーは標準のOracle Internet Directoryエントリで、Oracle Databaseでエンタープライズ・ユーザー・セキュリティに使用できます。
Oracle Internet Directoryでは、すべてのエンタープライズ・ユーザー・パスワードがレルムに対するパスワード・ポリシー・エントリで指定されたルールと一致していることを確認します。データベースは、エンタープライズ・ユーザーの認証時にOracle Internet Directoryと通信します。Oracle Internet Directoryに対して、パスワード・ポリシー違反をレポートするようにリクエストします。データベースは、Oracle Internet Directoryからポリシー違反レスポンスを受け取ると、適切な警告またはエラー・メッセージをユーザーに表示します。
データベースは次のイベントをレポートします。
ユーザー・パスワードがまもなく期限切れになる場合に警告を表示し、ユーザーが自分のパスワードを何日以内に変更する必要があるかを表示します。
パスワードが期限切れになった場合に警告を表示し、残っている猶予期間ログイン数についてユーザーに通知します。
ユーザー・パスワードが期限切れになり、ユーザーに猶予期間ログインが残っていない場合に、エラーを表示します。
ログイン試行に繰り返し失敗したためにユーザー・アカウントがロックされた場合に、エラーを表示します。
ユーザー・アカウントが管理者によって無効にされている場合に、エラーを表示します。
ユーザー・アカウントが非アクティブである場合に、エラーを表示します。
データベースでは、ユーザー・アカウント・ステータスをOracle Internet Directoryから読み取り、パスワード・ポリシー違反をチェックしますが、Oracle Internet Directoryでユーザー・アカウント・ステータスを更新することはありません。たとえば、失敗したエンタープライズ・ユーザーのデータベースへのログイン試行は、Oracle Internet Directoryでは更新されません。
関連項目: パスワード・ポリシーとその管理の詳細は、『Oracle Internet Directory管理者ガイド』を参照してください。 |
次の各項では、共有スキーマとその設定方法について説明します。
ユーザーは、個々のアカウントまたはスキーマを各データベースに設定する必要は必ずしもありません。かわりに、共有スキーマに接続して、ターゲット・アプリケーションに関連付けられているオブジェクトへのアクセス権を自身に付与できます。たとえば、Tom、DickおよびHarrietの3人のユーザーが財務データベース上の給与アプリケーションに対するアクセス権を必要としているとします。これらのユーザーは、データベースに固有のオブジェクトを作成する必要がないため、独自のスキーマを必要としません。ただし、給与スキーマのオブジェクトに対するアクセス権が必要です。
Oracle Databaseでは、エンタープライズ・ディレクトリに格納されている複数のユーザーを個々のデータベース上の共有スキーマにマップできます。このようにユーザーとスキーマを分離すると、データベース上のユーザー・アカウント数が減るため、管理コストが削減されます。つまり、ディレクトリ内でのユーザーの作成に加えて各ユーザー(ユーザー・スキーマ)のアカウントを作成する必要はありません。かわりに、エンタープライズ・ディレクトリにユーザーを作成し、そのユーザーを共有スキーマにマップできます。他のエンタープライズ・ユーザーをそのスキーマにマップすることもできます。
たとえば、Tom、DickおよびHarriet全員が売上データベースと財務データベースの両方にアクセスする場合は、それぞれのデータベースに各ユーザーのアカウントを作成する必要はありません。かわりに、3人のユーザー全員がアクセスできるGUEST
などの単一の共有スキーマを各データベースに作成できます。次に、エンタープライズ・ロールを使用して、売上データベースまたは財務データベース内のオブジェクトへの個々のアクセス権をこの3人のユーザーに付与します。一般的な環境では、最大5,000のエンタープライズ・ユーザーを1つの共有スキーマにマップして、各ユーザーにエンタープライズ・ロールのセットを割り当てることができます。
オブジェクトを含まない別の共有スキーマを作成して、エントリ・ポイントとして使用することをお薦めします。その後、エンタープライズ・ロールを介して他のスキーマのアプリケーション・オブジェクトに対するアクセス権を付与してください。アクセス権をこのように付与しないと、アプリケーション・オブジェクトが不注意または故意に削除または変更される可能性があります。
要約すると、共有スキーマには次の利点があります。
共有スキーマによって、各エンタープライズ・ユーザーに対してデータベースごとに専用のデータベース・スキーマを保持する必要がなくなります。
各エンタープライズ・ユーザーを、そのユーザーがアクセスする必要がある各データベース上の共有スキーマにマップできます。ユーザーは、データベースへの接続時に共有スキーマに接続します。
共有スキーマによって、エンタープライズ内のユーザー管理に必要なコストが削減されます。
共有スキーマを構成するには、ローカル・データベース管理者(DBA)がデータベースに1つ以上のデータベース・スキーマを作成する必要があります。エンタープライズ・ユーザーをこのスキーマにマップできます。
次の例では、管理者が共有スキーマを作成し、ユーザーをそのスキーマにマップします。
管理者は、EMPLOYEE
というグローバル共有スキーマおよびグローバル・ロールHRMANAGER
をHRデータベースに作成します。
管理者は、Oracle Internet Directoryセルフ・サービス・コンソールおよびOracle Enterprise Managerを使用して、ディレクトリでエンタープライズ・ユーザーとロールを作成および管理します。たとえば、管理者は、エンタープライズ・ユーザーHarrietと、MANAGER
というエンタープライズ・ロールを作成します。次に、HRデータベース・グローバル・ロールHRMANAGER
をエンタープライズ・ロールMANAGER
に割り当てます。
管理者は、エンタープライズ・ロールをディレクトリ内のエンタープライズ・ユーザーに割り当てます。たとえば、エンタープライズ・ロールMANAGER
をHarrietに割り当てます。
管理者は、Oracle Enterprise Managerを使用して、ディレクトリ内のユーザーHarrietをHRデータベース上の共有スキーマEMPLOYEEにマップします。
Harrietは、HRデータベースに接続すると、EMPLOYEE
スキーマに自動的に接続され、グローバル・ロールHRMANAGER
が付与されます。複数のエンタープライズ・ユーザーを同じ共有スキーマにマップできます。たとえば、エンタープライズ・セキュリティ管理者は、別のエンタープライズ・ユーザーScottを作成し、EMPLOYEE
スキーマにマップできます。この場合、HRデータベースに接続すると、HarrietとScottはいずれもEMPLOYEE
スキーマを自動的に使用することになりますが、それぞれ異なるロールを持つことができ、個々に監査されます。
関連項目: 監査の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
グローバル・スキーマ(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と次の優先ルールを使用します。
ローカル(データベース内)で排他スキーマを探します。
ローカルで排他スキーマが見つからない場合は、ディレクトリを探します。ディレクトリ内では、データベース・サーバー・エントリの下で、まずエントリ・レベル・マッピングを探し、次にサブツリー・レベル・マッピングを探します。
サーバー・エントリの下でマッピング・エントリが見つからない場合は、エンタープライズ・ドメイン・エントリの下で、まずエントリ・レベル・マッピングを探し、次にサブツリー・レベル・マッピングを探します。
ローカルで排他スキーマが見つからない場合またはデータベース内に適切なマッピング・エントリがない場合、データベースは接続を拒否します。それ以外の場合、データベースはユーザーを適切なスキーマに接続します。
たとえば、HarrietがHRデータベースに接続しようとしていて、Harrietの排他スキーマが(データベース内で)見つからないとします。この場合、次のイベントが発生します。
HRデータベースは、ディレクトリ内でHarrietのDNでユーザー・スキーマ・マッピングを探します。ディレクトリには、Harrietから共有スキーマEMPLOYEE
へのマッピングがあり、このスキーマが返されます。
データベースはHarrietのログインを許可し、HarrietをEMPLOYEE
スキーマに接続します。
データベースは、このデータベースに対するこのユーザーのグローバル・ロールをディレクトリから取得します。
また、ユーザーがマップされているデータベース・スキーマに関連付けられているローカル・ロールおよび権限をデータベース独自の表から取得します。
データベースは、グローバル・ロールとローカル・ロールの両方を使用して、ユーザーがアクセスできる情報を判断します。
引き続きこの例で、エンタープライズ・ロールMANAGER
にHRデータベース上のグローバル・ロールANALYST
と、給与データベース上のUSER
が含まれるとします。エンタープライズ・ロールMANAGER
を持つHarrietは、HRデータベースに接続するときに、そのデータベース上のスキーマEMPLOYEEを使用します。
HRデータベースに対するHarrietの権限は、次の内容によって判断されます。
グローバル・ロールANALYST
HRデータベース上のEMPLOYEE
スキーマに関連付けられているローカル・ロールと権限
Harrietが給与データベースに接続する場合、その権限は次の内容によって判断されます。
グローバル・ロールUSER
給与データベース上のEMPLOYEE
スキーマに関連付けられているローカル・ロールと権限
データベース・スキーマにロールおよび権限を付与することにより、指定したユーザー・グループに権限を付与できます。このようなスキーマを共有するすべてのユーザーは、個人のエンタープライズ・ロールに加えてこれらのローカル・ロールおよび権限を取得します。ただし、この共有スキーマにマップされるユーザーはすべて、このスキーマに割り当てられた権限を実行できるため、これを行う場合は十分な注意が必要です。このため、共有スキーマにロールおよび権限を付与することはお薦めしません。
エンタープライズ・ユーザーは、一時的にターゲット・ユーザーの認可と権限を取得して、別のユーザーとしてデータベースへの接続が必要になる場合があります。この機能は、様々なデータベースに対してエンタープライズ・ユーザーとして動作し、識別情報がOracle Internet Directoryのエントリとして設定されていることが多い中間層のツールまたはアプリケーションに特に役立ちます。このようなアプリケーションは、各エンド・ユーザーの識別情報を切り替えながら単一のデータベース接続を保持できるため、認可された各ユーザーの名前で動作することができます。
エンタープライズ・ユーザー・セキュリティ11gリリース1(11.1)では、シングル・セッション・モデルの導入によって、プロキシ・メカニズムの効率が強化されています。2セッション・プロキシ・モデルでは、プロキシ・ユーザーとターゲット・ユーザーに別個のセッションを保持する必要がありました。新しいモデルでは、1つのセッションのみがターゲット・ユーザーのセキュリティ・コンテキスト内で保持されます。これにより、パフォーマンスが向上します。
エンタープライズ・ユーザー・セキュリティ11gリリース1(11.1)を使用すると、エンタープライズ・ユーザーにプロキシ権限を細かく割り当てることができます。エンタープライズ・ユーザーには、ローカル・データベース・ユーザーのプロキシとして動作する権限を個別に付与できます。そのため、権限をデータベース内のユーザーの共有スキーマに関連付ける必要はありません。
エンタープライズ・ユーザーに個別にプロキシ権限を割当てできるということは、権限をより厳密に設定できることを意味します。それに対して、共有スキーマに権限を割り当てる場合は、スキーマにマップするすべてのユーザーに同じ権限を割り当てることになります。これによって、保証されていない権限が付与される可能性があります。
エンタープライズ・ユーザーのプロキシ権限は、Oracle Internet Directoryで作成および格納されます。1つの権限で、1つ以上のエンタープライズ・ユーザーまたはグループをターゲット・データベース・ユーザーのプロキシとして設定できます。権限は、エンタープライズ・ドメイン内の特定のデータベースまたはすべてのデータベースに適用できます。
デフォルトでは、ドメイン管理者はエンタープライズ・ドメインのディレクトリでプロキシ権限を管理できます。これらの権限は、Oracle Enterprise Managerを使用して構成および管理されます。
このようなプロキシを設定するには、次の手順に従います。
様々なデータベースに対するプロキシ権限が必要なすべてのエンタープライズ・ユーザーを特定します。
対象となる各データベース内のターゲット・ユーザーをすべて特定します。
対象となるターゲット・ユーザーごとに、次の形式で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プログラマーズ・ガイド』を参照してください。 |
各エンタープライズ・ユーザーに個別に、またはグループのメンバーとして、プロキシ権限を付与します。詳細は、「エンタープライズ・ユーザーへのプロキシ権限の付与」を参照してください。
注意: 同じデータベース・ユーザーのプロキシとして動作するエンタープライズ・ユーザーを表すグループを設定するには、Oracle Delegated Administration Servicesを使用します。詳細は、『Oracle Identity Management委任管理ガイド』を参照してください。 |
前述の4つの手順をすべて完了すると、特定したエンタープライズ・ユーザーを、特定して関連付けたすべてのローカル・データベース・ユーザーのプロキシとして設定できます。2つのバージョンのCONNECT
コマンドを使用できます。(1)の場合は、コマンドでエンタープライズ・ユーザーのパスワードを指定します。(2)の場合は、パスワードを指定しません。かわりに、sqlnet.oraファイルにその場所が記述されているウォレット内のパスワードを利用します。
エンタープライズ・ユーザーのプロキシ接続をデータベース・ユーザーとして確立するには、次のSQL*Plusコマンド構文を使用し、エンタープライズ・ユーザーのパスワードを指定します。
CONNECT joeproxy[targetuser]@database_service_name Enter Password:
ここで、joeproxy
をtargetuser
としてプロキシするエンタープライズ・ユーザーの名前に、targetuser
をターゲット・データベースの登録ユーザーの名前にそれぞれ置き換えます。大カッコは必須です。パスワードの入力を求められたら、エンタープライズ・ユーザーのパスワードを入力します。
これらの識別情報が検証されると、この接続リクエストによってシングル・セッションが生成されます。このセッションで、プロキシ・ユーザーはターゲット・データベースでターゲット・ユーザーとして動作します。元のユーザーの識別情報は、そのデータベースまで保持されるため、監査レコードはプロキシ・ユーザーとターゲット・ユーザーの両方の識別情報を取得できます。
パスワードを指定せずに、データベース・ユーザーに対するエンタープライズ・ユーザー・プロキシとして接続する場合は、sqlnet.ora
ファイルにそのユーザーのパスワードを保持するウォレットの場所が指定されていることを確認します。確認後、次のコマンド構文を使用します。
注意: OCIコールを使用する通常のプロキシ・ログイン・メカニズムも使用できます。CONNECT 構文は、新しい代替構文です。OCIコール・メカニズムの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
エンタープライズ・ユーザーのプロキシ権限はOracle Internet Directoryで割り当てられますが、データベース管理者は、エンタープライズ・ユーザーのプロキシ・ターゲットとして使用できるローカル・アカウントを決定できます。エンタープライズ・ドメイン管理者は、データベースのdba_proxiesビューで使用可能なターゲットに対してのみプロキシ権限を割り当てることができます。
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
ビューを使用します。
関連項目:
|
エンタープライズ・ユーザー・セキュリティをデプロイする前に、次の点について検討します。
エンタープライズ・ユーザーとそれに関連付けられた資格証明の一元管理には一般的な利点がありますが、検討が必要なセキュリティ関連の利点と危険性もたくさんあります。
管理を一元化すると、ユーザー、資格証明およびロールの管理が簡単かつ迅速になり、エンタープライズ全体のすべてのアプリケーションおよびデータベースに対するユーザーの権限を迅速に取り消すことができます。一元管理を行うと、管理者は1箇所でユーザーを削除してすべてのグローバル権限を取り消すことができるため、不要な権限が保持される危険性を最小限に抑えることができます。
管理を一元化すると、組織のセキュリティ技術を集中させることができます。セキュリティに詳しい専門知識のある管理者は、ディレクトリのセキュリティ、ユーザー・ロールと権限およびデータベース・アクセスなど、エンタープライズ・ユーザー・セキュリティに関するあらゆる側面を管理できます。これは従来のモデルよりも大幅に改善された点です。従来のモデルでは、通常DBAは、セキュリティを含め、管理するデータベース上のすべてに対して責任を負っていました。
Oracle Internet Directoryはセキュアなリポジトリですが、パブリックからアクセス可能なリポジトリで資格証明を一元管理する場合には、セキュリティ上の問題と固有のリスクがあります。一元化された資格証明は、少なくとも分散された資格証明と同程度には保護できますが、一元化の性質により、認可されていない第三者に資格証明が誤って公開される可能性が高まります。したがって、管理者の権限を制限し、ディレクトリ内に制限されたアクセス制御リスト(ACL)を設定するとともに、管理者が一時的にディレクトリから離れる場合にセキュリティ資格証明を保護する適切なセキュリティ・プラクティスを実装することが不可欠です。
すべてのセキュアなパスワードベースの認証方式では、サーバーはパスワード検証でクライアントを認証します。通常、パスワード検証はハッシュ・バージョンのパスワードであり、厳重な保護が必要です。Oracleデータベースに対するパスワードベースの認証もこれと同じです。ここでもパスワード検証が使用され、同じように保護する必要があります。これは、検証がデータベースにローカルに格納されている場合、またはディレクトリに一元的に格納されている場合に当てはまります。パスワード検証を使用して、元のパスワードを導出することはできません。
エンタープライズ・ユーザーのデータベース・パスワードは、複数のデータベースからアクセスできるように中央ディレクトリ・サービスに格納できます。このパスワードは、ユーザーがアクセス可能なすべての信頼できるデータベースから表示および共有できます。ディレクトリに格納されているパスワード検証は、クリアテキストのパスワードではありませんが、偶発的なアクセスや不正なアクセスから保護する必要があります。したがって、ディレクトリにパスワードに関連したACLを定義することが非常に重要になります。ACLは、必要なアクセスと操作性を確保しながら、可能なかぎりの制限を行います。(Oracle Databaseは、Oracle Internet Directoryによってサポートされるすべての検証タイプをサポートします。)
Oracleのツール製品を使用して、アイデンティティ管理レルムの作成時にこれらのパスワード検証を保護するためのACLをディレクトリに設定できます。お薦めする方式は、セキュリティと操作性の各考慮事項のバランスをとることを目的としています。最大限のセキュリティが必要であり、すべてのユーザーにウォレットを設定できる場合は、ユーザーからデータベースへの接続にSSLのみを使用します。SSLのみの方式を使用すると、ディレクトリ・パスワードの保護問題をそっくり回避することができます。
次の各項では、信頼できるデータベースについて、およびディレクトリ内でデータベース・パスワード検証を保護する方法について説明します。
SSLでは、厳密認証が行われるため、データベースでは相互の識別情報が確認されます。パスワード認証を使用するエンタープライズ・ユーザー・セキュリティでは、データベース・パスワード検証がディレクトリに一元的に格納され、複数のデータベース間で共有されますが、パスワード認証エンタープライズ・ユーザーにログインを許可する各データベースは信頼できるデータベースである必要があります。各データベースは共有パスワード検証にアクセスできるため、次のセキュリティ対策を順守する信頼できるデータベースであることが重要です。
各データベースは、サーバー・コードの改ざんからデータベース自体を保護する信頼できるデータベースであることが必要です。これにより、悪意のあるユーザーがデータベースの識別情報を悪用してディレクトリ内のパスワード検証にアクセスできなくなります。
各データベースは、データベース自体のPKIおよびその他の資格証明を盗用から保護する信頼できるデータベースであることが必要です。これにより、悪意のあるユーザーがPKIやその他の資格証明を使用してディレクトリに格納されているパスワード検証にアクセスできなくなります。
各アイデンティティ管理レルム内のOraclePasswordAccessibleDomainsグループは、レルムの作成時に自動的に作成され、Oracle Internet Directoryセルフ・サービス・コンソールなどのOracle Internet Directoryツールを使用して管理できます。このグループには、ディレクトリに格納されているユーザーのデータベース・パスワード検証を参照する必要があるメンバー・データベースを含むエンタープライズ・ドメインが配置されます。
選択したレルムに対して、パスワード認証接続を受け入れるデータベースを決定します。Oracle Internet Directoryセルフ・サービス・コンソールを使用して、これらのデータベースを含むドメインをOraclePasswordAccessibleDomainsグループに配置します。ユーザー・サブツリーのACLにより、データベースで使用するパスワード検証を保持するディレクトリ属性へのアクセスが許可されます。
他のすべてのユーザーは、この属性へのアクセスを拒否されます。パスワード検証の属性への匿名読取りアクセスを防止するACLは、ディレクトリ・ツリーのルートにあります。
操作性を考慮し、デフォルトでは、OracleDefaultDomainはOraclePasswordAccessibleDomainsグループのメンバーとなります。これは必要に応じて削除できます。
ドメインのデータベース・メンバーシップを定義する場合は、次の基準を考慮します。
現行ユーザーのデータベース・リンクは、1つのエンタープライズ・ドメイン内のデータベース間でのみ機能します。これらのリンクを使用するには、これらのデータベース間およびこれらを管理するDBA間に相互信頼が必要です。
エンタープライズ・ユーザーに適用される認証タイプは、ドメイン・レベルで定義されます。したがって、ドメイン内のデータベース・メンバーシップはそのタイプに応じて定義する必要があります。
注意: 1つ以上のデータベースでSSLベースの証明書認証のみをサポートする場合、それらのデータベースを同じドメイン内でパスワード認証のデータベースと組み合せることはできません。 |
エンタープライズ・ロールはドメイン・レベルで定義されます。複数のデータベース間でエンタープライズ・ロールを共有するには、データベースが同じドメインのメンバーであることが必要です。
エンタープライズ・ユーザー・セキュリティでは、クライアント、データベースおよびディレクトリ間の接続に対して、表1-3に示す認証タイプをサポートしています。
表1-3 エンタープライズ・ユーザー・セキュリティ: クライアント、データベースおよびディレクトリ間の接続に対してサポートされる認証タイプ
接続 | サポートされる認証タイプ |
---|---|
クライアントとデータベース間 |
パスワード、SSLおよびKerberos |
データベース間(現行ユーザーのデータベース・リンク) |
SSLのみ |
データベースとディレクトリ間 |
SSLおよびパスワード |
ただし、接続に対する認証タイプの組合せの中には、他の組合せに比べて妥当なものもあります。たとえば、すべてのユーザー接続に対してSSLを使用し、クライアントとデータベース間の接続に高レベルのセキュリティを設定しながら、ディレクトリに対する認証にパスワードを使用するようにデータベースを構成することは、通常ありません。この構成はサポートされますが、接続に一貫性のあるセキュリティは提供されません。データベースとディレクトリ間の接続には、ユーザーとデータベース間の接続と同じレベル以上の安全性を持たせることが理想的です。