| Oracle® Fusion Middleware Oracle Unified Directoryの管理 11g リリース2 (11.1.2.3) E61945-07 |
|
 前 |
 次 |
この章では、rootユーザー・アカウントおよび特権サブシステムについて説明します。
ほとんどのLDAPディレクトリ・サーバーでは、一般的に単一のスーパーユーザーを持っています。これは、従来のUNIXシステムのrootアカウントに似ています。このアカウントでは、通常のユーザーには適用されるアクセス制御や他の制限をバイパスすることができます。Oracle Unified Directoryでは、複数のrootユーザーおよびよりきめ細かいレベルで機能の制御を可能にする特権サブシステムを定義できます。
この章には次のセクションが含まれます:
rootユーザー・アカウントは、サーバー構成のcn=Root DNs,cn=config分岐の下に定義されます。各rootアカウントは、ds-cfg-root-dn-user補助オブジェクト・クラスが含まれることを除いて、通常のユーザー・エントリとして定義されます。rootユーザー・エントリは、ds-cfg-alternate-bind-dn属性に1つ以上の値を持つことができます。この属性では、代替DN(これを使用して、そのユーザーとして認証することが可能です)を指定します(たとえば、実際のエントリDNであるcn=Directory Manager,cn=Root DNs,cn=configを使用するかわりに、cn=Directory Managerとしてバインドできます)。
複数のrootユーザーをそれぞれ独自のエントリで定義できることによって次の利点が得られます。
ディレクトリ・サーバーへのルート・アクセスが必要な各管理者は、自身の資格証明が設定されている各自のアカウントを持つことができます。これは、すべての管理者が単一のrootアカウントを共有する場合よりも、ディレクトリ・サーバー内でだれが何をするかの監査証跡を保持することを容易にします。
各rootユーザー・アカウントは、自身の資格証明のセットを持っているため、1人のrootユーザーの資格証明は、他のrootユーザーへ影響を与えることなく変更することができます。各管理者は自身のアカウントを持っているため、すべての管理者の間でrootパスワードの変更を調整する必要はありません。管理者が異動または退職した場合、そのアカウントを非アクティブ化または削除するだけで済みます。
各rootユーザーは自身のエントリを持っていて、そのエントリ(ds-cfg-root-dn-user補助オブジェクト・クラスを持っている場合)に好きな属性およびオブジェクト・クラスを配置することができるため、rootユーザーは、EXTERNALやGSSAPI SASLメカニズムのような強力な認証を使用することができます。
rootユーザーは、パスワード・ポリシー適用の対象となります。これは、rootユーザーに定期的に自分のパスワードを変更させ、セキュアなメカニズムを使用してのみ認証やパスワードの変更を行えるようにし、強力なパスワードが選択されるようにすることを意味します。ディレクトリの他のユーザーとは異なるパスワード・ポリシー要件のセットの対象となるように、rootユーザーにカスタム・パスワード・ポリシーを使用することもできます。
通常のユーザーよりもrootユーザーのために異なるリソース制限を定義することができます。各rootアカウントは自身のエントリを持つため、ds-rlim-size-limit、ds-rlim-time-limitおよびds-rlim-lookthrough-limitなどの操作属性は、通常のユーザー・アカウントと同じようにrootユーザーに作用します。
cn=configのルートdnsで管理バインドが解決されるため、ルート・ユーザーのみが管理ポートにバインドできます。ルートdnを作成するには、第29.3.3項「ルート・ユーザーの作成」を参照してください。
前述したように、従来のディレクトリ内のrootユーザー・アカウントは、アクセス制御および他の制限をバイパスできるため特別であり、rootユーザーのみが実行できるいくつかの操作があります。これは、従来のUNIXオペレーティング・システムにおけるrootユーザーの概念に似ています。ただし、rootユーザーのみができることを通常のユーザーが実行する必要がある場合があります。rootアクセスを与えられているユーザーには、実際にジョブを実行するのに必要なパワーよりもはるかに大きなパワーが与えられます。システム管理者には、ユーザーがこのパワーを責任を持って使用し、故意であってもなくてもシステムの他の部分に影響を与えないようにすることが求められます。それに対して、ユーザーにrootアクセスが与えられないと、重要な機能を実行できないか、タスクを実行するためにシステム管理者に頼る必要がある場合もあります。
Solaris 10以降では、特権サブシステム(「プロセス権限管理」とも呼ばれます)を作成することで、UNIXシステムのこの問題に取り組んでいます。Solarisの開発エンジニアは、一つの特定のタスクを実行するだけのために誰かにrootアクセス権を与えざるを得ないことは、危険で望ましくないと気が付きました。たとえば、1024未満のポートでリスニングするプロセスを開始する必要があるといって、ユーザーはファイルシステム権限をバイパスできたり、ネットワーク・インタフェースの設定を変更できたり、また、ファイル・システムをマウントおよびアンマウントできる必要があるというわけではありません。Solaris 10の特権サブシステムを使用すると、ユーザーに必要な特定の機能のみを与えることが可能です(たとえば、完全なrootアクセス権を与えることなく権限ポートにバインドできるようにすることなど)。同様に、利用可能な権限を無効にすることも可能です。たとえば、特定のデーモンを実行するためにのみ使用されるアカウントは、システムの他のユーザーが所有するプロセスを参照することができるようにする必要はありません。
|
注意: 管理者は、最高のセキュリティ・レベルを達成するために、Oracle Privileged Account Managementシステムを検討する必要があります。 |
Oracle Unified Directoryは、ユーザーが必要とする可能性のある個別の機能を定義し、ユーザーが必要とするアクセスのレベルだけを与えることができる特権サブシステムも持っています。通常のユーザーは持たない権限を通常のユーザーに付与したり、rootユーザーの特定の権限を無効にしたりすることができます。ディレクトリ・サーバーに現在定義されている権限のセットは次のとおりです:
bypass-aclアクセス制御の評価のバイパスをユーザーに許可
modify-aclユーザーが、サーバーで定義されたアクセス制御に変更を加えることを許可します。
config-readサーバー構成の読取りアクセス権の保有をユーザーに許可
config-writeサーバー構成の書込みアクセス権の保有をユーザーに許可
jmx-readユーザーがJMX属性値を読み取ることを許可します。
jmx-writeユーザーがJMX属性値を更新することを許可します。
jmx-notify*ユーザーがJMX通知にサブスクライブすることを許可します。
ldif-importユーザーがLDIFインポート・タスクを要求することを許可します。
ldif-exportユーザーがLDIFエクスポート・タスクを要求することを許可します。
backend-backupユーザーがバックエンドのバックアップ・タスクを要求することを許可します。
backend-restoreユーザーがバックエンドのリストア・タスクを要求することを許可します。
server-shutdownユーザーがサーバーのシャットダウン・タスクを要求することを許可します。
server-restartユーザーがサーバーの再起動タスクを要求することを許可します。
proxied-authユーザーが、プロキシ設定された認可制御を使用すること、または代替SASL認可IDを要求することを許可します。
disconnect-clientユーザーが任意のクライアント接続を終了することを許可します。
cancel-request*ユーザーが任意のクライアント・リクエストを取り消すことを許可します。
unindexed-searchユーザーがインデックスを使用しない検索操作を要求することを許可します。
password-resetユーザーが他のユーザーのパスワードをリセットすることを許可します。
update-schemaユーザーがサーバー・スキーマを更新することを許可します。
privilege-changeユーザーが、ユーザーに割り当てられた権限のセットを変更するか、デフォルトのroot権限のセットを変更することを許可します。
現在アスタリスク(*)でマークされた権限は、まだサーバーに実装されていないので、有効ではありません。
特権サブシステムは、アクセス制御サブシステムにはほとんど依存しません。ユーザーがbypass-acl権限も持たないかぎり、操作はアクセス制御のチェックの影響下にある可能性があります。たとえば、ユーザーがconfig-read権限を持つ場合、そのユーザーは、アクセス制御で許可されている構成の部分のみを参照することができます。原則として、ある操作が特権サブシステムとアクセス制御の両方の対象となっているときはいつでも、両方のメカニズムでその操作を許可する必要があります。
デフォルトでは、前述の権限のいずれも通常のユーザーには付与されません。したがって、ユーザーが、関連付けられた任意の操作を実行できるようにする場合は、適切な権限が付与されている必要があります。これは、ユーザーのエントリにds-privilege-name操作属性を追加することで行うことができます。
|
注意: modify-aclなどの値を持つ特権の追加は、ユーザーにACIの追加、置換または削除の権限を付与するには十分ではありません。ユーザーが別のエントリのACIを変更するための適切なアクセス制御も必要です。詳細は、付録P「ACI構文」を参照してください。 |
ds-privilege-nameは複数値の属性であり、ユーザーが複数の権限を与えられる場合、単独の値がそれぞれに使用される必要があります。仮想属性サブシステムが所定の場所にあるとき、それらのユーザー・エントリでds-privilege-nameを仮想属性にすることで、自動的にユーザーのグループに権限を付与することが可能です。
ユーザーcn=Proxy User,dc=example,dc=comにproxied-auth権限を追加するのに使用される変更の例を次に示します:
dn: cn=Proxy User,dc=example,dc=com changetype: modify add: ds-privilege-name ds-privilege-name: proxied-auth
|
注意: 最初のバインドの後に、ユーザーの特権の変更をオープン接続に適用する場合は、maintain-authenticated-usersフラグtrueに設定する必要があります。デフォルトでは、falseに設定されています。
決定済の |
権限サブシステムを導入した場合、サーバー内の他のアカウントとrootユーザーを区別する主な特徴は、rootユーザーがユーザー・データ内ではなく構成内に存在すること、およびrootユーザーであるため権限の特定のセットを自動的に継承することです。rootユーザーに自動的に付与される権限のセットは、cn=Root DNs,cn=configエントリのds-cfg-default-root-privilege-name属性で定義されます。デフォルトでは、rootユーザーには次の権限が自動的に付与されます:
bypass-acl
modify-acl
config-read
config-write
ldif-import
ldif-export
backend-backup
backend-restore
server-shutdown
server-restart
disconnect-client
cancel-request
unindexed-search
password-reset
update-schema
privilege-change
rootユーザーに自動的に割り当てられる権限のセットを変更したい場合は、ds-cfg-default-root-privilege-name属性を編集することで行うことができます。さらに、特定のrootユーザーに異なる権限のセットを付与する場合は、通常のユーザーと同様に、rootユーザーのエントリ内のds-privilege-name属性を使用することでそれを行うことができます。たとえば、次の変更を使用して、特定のrootユーザー(この場合は、cn=Test Root User,cn=Root DNs,cn=config)がプロキシ認可を使用できるようにする一方で、ユーザー権限を変更したり構成にアクセスしたりすることはできないようにします。(権限の前のマイナス記号は、付与ではなく、削除されることを示します。)
dn: cn=Test Root User,cn=Root DNs,cn=config changetype: modify add: ds-privilege-name ds-privilege-name: proxied-auth ds-privilege-name: -config-read ds-privilege-name: -config-write
この場合、cn=Test Root User,cn=Root DNs,cn=configユーザーは、rootユーザーに自動的に付与されるすべての権限(ただしconfig-readおよびconfig-write権限は除きます)を継承します。さらに、proxied-auth権限も付与されます。
