11 rootユーザーと特権サブシステムの理解
次の各トピックでは、rootユーザー・アカウントおよび特権サブシステムを説明します。
11.1 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
で解決されるため、ルート・ユーザーのみが管理ポートをバインドできますrootdn
を作成するには、「rootユーザーの作成」を参照してください。
11.2 特権サブシステムの理解
従来のディレクトリ内の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
権限を持つ場合、そのユーザーは、アクセス制御で許可されている構成の部分のみを参照することができます。原則として、ある操作が特権サブシステムとアクセス制御の両方の対象となっているときはいつでも、両方のメカニズムでその操作を許可する必要があります。
11.3 通常ユーザーへの権限の割当て
権限は、ユーザーのエントリにds-privilege-name
操作属性を追加することによって割り当てられます。デフォルトでは、いずれの権限も通常のユーザーには付与されません。したがって、ユーザーが、関連付けられた任意の操作を実行できるようにする場合は、適切な権限が付与されている必要があります。
ディレクトリ・サーバーに現在定義されている権限のセットの詳細は、「特権サブシステムの理解」を参照してください。
ノート:
modify-acl
などの値を持つ特権の追加は、ユーザーにACIの追加、置換または削除の権限を付与するには十分ではありません。ユーザーが別のエントリの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
に設定されています。
決定済のauthDN
によってバインドされるオープン接続の場合、import-ldif
コマンドを使用してdn: authDN
を持つエントリをインポートしても、接続が確立済のauthDN
のプロパティ(アクセス権や特権など)は変更されません。import-ldif
の結果によって指定されたauthDN
の新しいプロパティは、authDN
の新しいバインドのみに適用されます。このシナリオでは、maintain-authenticated-users:true
の設定は機能しません。
11.4 rootユーザーへの権限の割当て
デフォルトでは、いずれの権限もrootユーザーには付与されません。したがって、rootユーザーが、関連付けられた任意の操作を実行できるようにする場合は、適切な権限が付与されている必要があります。
次の各トピックでは、rootユーザーへの権限の割当て方法および・アカウントおよび主な特徴を説明します。
11.4.1 rootユーザーへの権限の割当てについて
権限サブシステムを導入した場合、サーバー内の他のアカウントと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
11.4.2 rootユーザーに割り当てられた権限の変更
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
権限も付与されます。