アクセス制御の使用例

この節で示す例では、架空の ISP である Example.com 社が、アクセス制御ポリシーを決定していきます。

また、インストールに付属のサンプルの LDIF ファイルに、install_path/ds6/ldif/Example.ldif というサンプルの ACI もあります。

すべての例では、LDIF ファイルを使用して、与えられたタスクをどのように処理するかを説明しています。次の図で、example.com 社のディレクトリ情報ツリーを示します。

Example.com 社の業務は、Web ホスティングサービスとインターネットアクセスの提供です。Example.com の Web ホスティングサービスには、クライアント企業のディレクトリのホスティングが含まれます。Example.com は実際に 2 つの中規模企業のディレクトリ Company333 と Company999 をホストし、部分的に管理を行なっています。また、多数の個人加入者にインターネットへのアクセスを提供しています。

現在、Example.com 社は、次のようなアクセス規則を設定しようとしています。

• Example.com 社の社員に、Example.com ツリー全体を対象とした読み取り、検索、および比較のための匿名アクセス権を与える。「匿名アクセスの許可」を参照。

• Example.com 社の社員に、homeTelephoneNumber、homeAddress などの個人情報への書き込みアクセス権を与える。「個人のエントリへの書き込みアクセス権の許可」を参照。

• Example.com 社の契約者に、会社の連絡先情報のエントリ dc=example,dc=com の読み取り権限を与える。ただし、その下のエントリの読み取り権限は与えない。「特定のレベルへのアクセスの許可」を参照。

• Example.com 社の社員が個人のエントリにロールを追加するアクセス権を与える。ただし、一部の重要なロールは除く。「重要なロールに対するアクセスの制限」を参照。

• 特定の管理者に、サフィックスに関してディレクトリマネージャーと同じ権限を与える。 「サフィックス全体に対するすべてのアクセス権のロールへの許可」を参照。

• Example.com 社の人事部グループに、People 分岐のエントリを対象としたすべての権限を与える。「サフィックスに対するすべてのアクセス権のグループへの許可」を参照。

• Example.com 社のすべての社員に対し、ディレクトリの Social Committee エントリの下にグループエントリを作成し、社員が所有するグループエントリを削除するアクセス権を与える。「グループエントリの追加および削除権限の許可」を参照。

• Example.com 社のすべての社員に対し、Social Committee エントリの下のグループエントリに、自身を追加するアクセス権を与える。「ユーザー自身の操作によるグループへの参加とグループからの退会」を参照。

• 一定の条件付きで、ディレクトリツリーのそれぞれのエントリへのアクセス権を Company333 および Company999 のディレクトリ管理者 (ロール) に与える。これらの条件には、SSL 認証、日時の制約、位置の指定などが含まれる。「グループまたはロールへの条件付きアクセスの許可」を参照。

• 個人契約者に対し、個人のエントリへのアクセス権を与える。「個人のエントリへの書き込みアクセス権の許可」を参照。

• 個人契約者が個人のエントリ内の課金情報にアクセスできないようにする。「アクセスの拒否」を参照。

• 世界のユーザーに対し、個人契約者のサブツリーへの匿名アクセス権を与える。ただし、非公開を希望している契約者は除く。ディレクトリのこの部分は、必要に応じてファイアウォール外部から読み取り専用サーバーになることがあり、毎日 1 回更新される。「匿名アクセスの許可」および「フィルタを使用したターゲットの設定」を参照。

匿名アクセスの許可

ほとんどのディレクトリは、読み取り、検索、または比較を行うために、少なくとも 1 つのサフィックスに匿名でアクセスできるように設定されています。社員が検索できる電話帳のような、企業内の個人情報を収めたディレクトリを管理している場合、そのためのアクセス権の設定が必要になることがあります。これは Example.com 社内のケースであり、「ACI「Anonymous Example.com」」にその例が示されています。

Example.com 社では、ISP として、世界中からアクセス可能な公開電話帳を作成し、契約者全員の連絡先情報を公開することも計画しています。これについては、「ACI「Anonymous World」」で例を示しています。

ACI「Anonymous Example.com」

Example.com 社の社員に Example.com ツリー全体を対象とした読み取り、検索、および比較アクセス権を与えるには、LDIF で次のような文を作成します。

aci: (targetattr !="userPassword")(version 3.0; acl "Anonymous
 example"; allow (read, search, compare)
 userdn= "ldap:///anyone") ;)

この例では、aci を dc=example,dc=com エントリに追加することを仮定しています。userPassword 属性は ACI の対象に含まれていません。

機密属性や表示すべきではない属性は、前の例でパスワード属性を保護しているのと同じように、「(targetattr !="attribute-name ")」の構文を用いて保護してください。

ACI「Anonymous World」

個人契約者サブツリーの読み取りおよび検索アクセス権を世界中に与え、非公開にする契約者の情報へのアクセスを拒否するには、LDIF で次のような文を作成します。

aci: (targetfilter= "(!(unlistedSubscriber=yes))")
 (targetattr="homePostalAddress || homePhone || mail")
 (version 3.0; acl "Anonymous World"; allow (read, search)
 userdn="ldap:///anyone";)

この例では、ACI を ou=subscribers,dc=example, dc=com エントリに追加することを仮定しています。また、各契約者のエントリには、yes または no の値を持つ unlistedSubscriber 属性が設定されているものとします。非公開契約者は、この属性値に基づいて、ターゲット定義のフィルタによって除外されます。フィルタ定義については、「フィルタを使用したターゲットの設定」を参照してください。

個人のエントリへの書き込みアクセス権の許可

多くの場合、内部ユーザーが個人で変更できるエントリの属性は、ディレクトリ管理者によって一部だけに制限されています。Example.com 社のディレクトリ管理者は、ユーザーが変更できる対象を、パスワード、自宅の電話番号、自宅住所だけに制限しようとしています。これについては、「ACI「Write Example.com」」で例を示しています。

また、Example.com 社には、契約者がディレクトリに対して SSL 接続を確立することを条件に、Example.com ツリー内にある個人情報を更新できるようにするというポリシーもあります。これについては、「ACI「Write Subscribers」」で例を示しています。

ACI「Write Example.com」

このアクセス権を設定することによって、ユーザーは属性値の削除アクセス権も与えられます。

Example.com 社の社員が、個人の自宅の電話番号、自宅住所を変更できるようにするには、LDIF で次のような文を作成します。

aci: (targetattr="homePhone ||
 homePostalAddress")(version 3.0; acl "Write Example.com";
 allow (write) userdn="ldap:///self" ;)

この例では、ACI を ou=People,dc=example,dc=comエントリに追加することを仮定しています。

ACI「Write Subscribers」

このアクセス権を設定することによって、ユーザーは属性値の削除アクセス権も与えられます。

Example.com 社の契約者が個人の自宅の電話番号を変更できるようにするには、LDIF で次のような文を作成します。

aci: (targetattr="homePhone")
 (version 3.0; acl "Write Subscribers"; allow (write)
 userdn= "ldap://self" and authmethod="ssl";)

この例では、aci を ou=subscribers,dc=example, dc=com エントリに追加し、ユーザーは SSL を使用してバインドする必要があると仮定しています。

Example.com 社の契約者は、その住所の属性を削除する可能性があるため、住所への書き込みアクセス権は与えられていません。住所は Example.com 社からの請求に重要な情報です。

特定のレベルへのアクセスの許可

ディレクトリツリー内のさまざまなレベルに影響を及ぼす ACI の範囲を設定して、許可するアクセスのレベルを微調整できます。対象の ACI の範囲は、次のいずれかに設定できます。

base

エントリ自体

onelevel

エントリ自体と 1 レベル下のすべてのエントリ

subtree

エントリ自体と、そのエントリの下のすべてのエントリ

ACI 「Read Example.com only」

Example.com 社の契約者に、会社の連絡先情報についてのエントリ dc=example,dc=com の読み取り権限は与えても、その下にあるエントリへのアクセスは許可しないようにするには、LDIF で次のような文を作成します。

aci: (targetscope="base") (targetattr="*")(version 3.0;
 acl "Read Example.com only";  allow (read,search,compare)
 userdn="ldap:///cn=*,ou=subscribers,dc=example,dc=com";)

この例では、ACI を dc=example,dc=com エントリに追加することを仮定しています。

重要なロールに対するアクセスの制限

ディレクトリ内のロール定義を使用して、ネットワークやディレクトリの管理などの業務に重要な機能を特定できます。

たとえば、国際的な企業のサイトで特定の時間と曜日に有効なシステム管理者のサブセットを指定する superAdmin ロールを作成する必要があるかもしれません。あるいは、特定のサイト上に、応急手当のトレーニングを受けたすべてのスタッフを含む First Aid ロールの作成が必要になることもあるかもしれません。ロール定義の作成については、「ロールの管理」を参照してください。

ロールによって、業務上あるいはビジネス上重要な機能に関するユーザー特権を与える場合は、そのロールに対するアクセス制限を考慮してください。たとえば、次の例で示すように、Example.com の社員は、superAdmin ロール以外の任意のロールを個人のエントリに追加できます。

ACI「Roles」

Example.com の社員が、superAdmin 以外の任意のロールを個人のエントリに追加できるようにするには、LDIF で次のような文を作成します。

aci: (targetattr="*") (targattrfilters="add=nsRoleDN:
 (nsRoleDN !="cn=superAdmin, dc=example, dc=com")")
 (version 3.0; acl "Roles"; allow (write)
 userdn= "ldap:///self" ;)

この例では、ACI を ou=People,dc=example,dc=comエントリに追加することを仮定しています。

サフィックス全体に対するすべてのアクセス権のロールへの許可

一部のユーザーに、サフィックスに対してディレクトリマネージャーと同じ権限を許可すると、便利な場合があります。Example.com 社の Kirsten Vaughan は Directory Server の管理者です。彼女は superAdmin のロールを持っています。このロールには、次のような利点があります。

• 管理者としてバインドし、SSL のような強力な認証を強制的に使用できることによって、セキュリティーが向上する

• ディレクトリマネージャーパスワードを知っている人が減ることによって、セキュリティーが向上する

• ログによる追跡容易性の向上

Kirsten Vaughan を cn=Administrators,cn=config グループに追加すると、ディレクトリマネージャーと同じ権限が与えられます。

サーバー全体に対してディレクトリマネージャーと同じ権限をユーザーに与える際は、「ルートアクセス権を持つ管理ユーザーを作成する」の手順に従ってください。

ACI「Full Access」

Kirsten Vaughan という管理者にディレクトリマネージャーと同じ権限を許可するには、LDIF で次のような文を使用します。

aci: (targetattr="*") (version 3.0; acl "Full Access";
 allow (all) groupdn= "ldap:///cn=SuperAdmin,dc=example,dc=com"
 and authmethod="ssl" ;)

この例では、ACI がルートエントリ "" (テキストなし) に追加されると仮定しています。

サフィックスに対するすべてのアクセス権のグループへの許可

ほとんどのディレクトリには、業務上の固有の職務を特定するためのグループがあります。グループには、ディレクトリのすべてまたは一部に対してアクセス権を与えることができます。グループにアクセス権限を与えることにより、グループメンバーに個別にアクセス権限を設定する必要がなくなります。代わりに、グループにメンバーを追加することで、アクセス権限をそのメンバーに与えることができます。

たとえば、Directory Server インスタンスを作成すると、ディレクトリへのすべてのアクセス権を持つ cn=Administrators,cn=config という管理者グループがデフォルトで作成されます。

Example.com 社の人事部グループには、ディレクトリの ou=People エントリへのすべてのアクセス権が許可されています。これによって、このグループのメンバーは、「ACI 「HR」」に示すように社員のディレクトリを更新できます。

ACI 「HR」

ディレクトリの employee エントリに対するすべての権限を HR のグループに与えるには、LDIF で次のような文を作成します。

aci: (targetattr="*") (version 3.0; acl "HR"; allow (all)
  groupdn= "ldap:///cn=HRgroup,ou=Groups,dc=example,dc=com";)

この例では、ACI を次のエントリに追加することを仮定しています。

ou=People,dc=example,dc=com

グループエントリの追加および削除権限の許可

一部の企業では、業務の効率化や企業全体の活力向上につなげるため、社員自身がツリー内にエントリを作成できるようにしています。たとえば、Example.com 社には、テニス、水泳、スキー、演劇などのさまざまなクラブが組織された社内委員会があります。

Example.com 社の社員はだれでも、「ACI「Create Group」」に示すように、新しいクラブを表すグループエントリを作成できます。

「ユーザー自身の操作によるグループへの参加とグループからの退会」に示すように、Example.com 社の社員であれば、これらのグループのどれか 1 つのメンバーになることができます。

「ACI「Delete Group」」に示すように、グループエントリの変更や削除ができるのは、グループの所有者のみです。

ACI「Create Group」

Example.com 社の社員が ou=Social Committee エントリの下にグループエントリを作成できるようにするには、LDIF で次のような文を作成します。

aci: (targetattr="*") (targattrfilters="add=objectClass: 
(|(objectClass=groupOfNames)(objectClass=top))") 
(version 3.0; acl "Create Group"; allow (read,search,add) 
userdn= "ldap:///uid=*,ou=People,dc=example,dc=com") 
and dns="*.Example.com";)

この例では、ACI を ou=Social Committee, dc=example,dc=com エントリに追加することを仮定しています。

• この ACI は、書き込みアクセス権を与えないので、エントリを変更できません。

• サーバーが top という値を追加するので、targattrfilters キーワードで objectClass=top を指定する必要があります。

• この ACI は、example.com ドメイン内のクライアントマシンにのみ適用されます。

ACI「Delete Group」

Example.com 社の社員が ou=Social Committee エントリの下に属しているグループエントリを変更または削除できるようにするには、LDIF で次のような文を作成します。

aci: (targetattr = "*") (targattrfilters="del=objectClass:
(objectClass=groupOfNames)")
 (version 3.0; acl "Delete Group"; allow (write,delete)
 userattr="owner#GROUPDN";)

この例では、aci を ou=Social Committee, dc=example,dc=com エントリに追加しています。

DSCC を使用してこの ACI を作成すると、手動編集モードでのターゲットフィルタの作成とグループ所有権の確認が必要なので、あまり効率的ではありません。

ユーザー自身の操作によるグループへの参加とグループからの退会

多くのディレクトリの ACI は、ユーザーがメーリングリストなどのグループへの参加とグループからの退会を自分で設定できるようになっています。

Example.com 社では、「ACI「Group Members」」に示すように、社員であれば ou=Social Committee サブツリーの下のどのグループエントリにも参加できます。

ACI「Group Members」

Example.com 社の社員が自分でグループへの参加を設定できるようにするには、LDIF で次のような文を作成します。

aci: (targettattr="member")(version 3.0; acl "Group Members";
 allow (selfwrite)
 (userdn= "ldap:///uid=*,ou=People,dc=example,dc=com") ;)

この例では、ACI を ou=Social Committee,dc=example,dc=com エントリに追加することを仮定しています。

グループまたはロールへの条件付きアクセスの許可

多くの場合、ディレクトリへのアクセス特権をグループやロールに与える場合、それらの特権が、特権ユーザーになりすました侵入者から保護されていることを確認する必要があります。したがって、多くの場合、グループまたはロールへの重要なアクセス権を与えるようなアクセス制御規則には、数多くの条件が付けられます。

たとえば、Example.com 社では、ホスティングサービスの提供先企業である Company333 および Company999 に対して、それぞれ Directory Administrator ロールを作成しました。Example.com 社では、侵入者からデータを保護するために、それぞれの企業が各自でデータを管理し、独自のアクセス制御規則を決定することを求めています。

このため、Company333 と Company999 は、ディレクトリツリーのそれぞれのエントリに関してすべての権限を持っていますが、このアクセス権を行使するには次の条件を満たす必要があります。

• 証明書を使用して、SSL 経由の接続が認証されること

• アクセス要求は月曜日から木曜日の午前 8 時から午後 6 時までの間に限ること

• それぞれの企業に割り当てられた特定の IP アドレスからアクセスが要求されること

これらの条件は、各社の ACI である「Company333」と「Company999」に示されています。これらの ACI の内容は同等なので、「Company333」という ACI だけを次に示します。

ACI「Company333」

Company333 に対して、前述した条件に従ったディレクトリの自社のエントリへのすべてのアクセス権を与えるには、LDIF で次のような文を作成します。

aci: (targetattr = "*") (version 3.0; acl "Company333"; allow (all)
 (roledn="ldap:///cn=DirectoryAdmin,ou=Company333,
 ou=corporate clients,dc=example,dc=com") and (authmethod="ssl")
 and (dayofweek="Mon,Tues,Wed,Thu") and (timeofday >= "0800" and
 timeofday <= "1800") and (ip="255.255.123.234"); )

この例では、ACI を ou=Company333,ou=corporate-clients,dc=example,dc=com エントリに追加することを仮定しています。

アクセスの拒否

サフィックスの大半の部分に対してのアクセスをすでに許可している場合に、既存の ACI の配下にあるサフィックスの限定された範囲に対してアクセスを拒否させることもできます。

アクセスを拒否すると、アクセス制御の振る舞いが予期しないものや複雑なものになる可能性があるため、可能な限り回避してください。アクセスは、範囲、属性リスト、ターゲットフィルタなどの組み合わせを使って制限してください。

また、アクセス拒否 ACI を削除しても、権限が削除されるのではなく、ほかの ACI で設定された権限の幅が広げられます。

Directory Server は、アクセス権限を評価するとき、最初に deny 権限を読み取り、次に allow 権限を読み取ります。

次の例で、Example.com 社では、すべての契約者に対し、契約者自身のエントリにある接続時間や料金内訳などの課金情報の読み取りアクセス権を与えています。また、Example.com 社では、その情報に対する書き込みアクセス権は拒否するようにしています。読み取りアクセス権については、「ACI「Billing Info Read」」で例を示しています。deny アクセス権については、「ACI「Billing Info Deny」」で例を示しています。

ACI「Billing Info Read」

個人のエントリ内にある課金情報の読み取りアクセス権を契約者に与えるには、LDIF で次のような文を作成します。

aci: (targetattr="connectionTime || accountBalance")
 (version 3.0; acl "Billing Info Read"; allow (search,read)
  userdn="ldap:///self";)

この例は、関連する属性がスキーマ内で作成済みであり、ACI を ou=subscribers,dc=example,dc=com エントリに追加しています。

ACI「Billing Info Deny」

各契約者に対し、契約者個人のエントリ内にある課金情報の変更アクセス権を拒否するには、LDIF で次のような文を作成します。

aci: (targetattr="connectionTime || accountBalance")
 (version 3.0; acl "Billing Info Deny";
 deny (write) userdn="ldap:///self";)

この例は、関連する属性がスキーマ内で作成済みであり、ACI を ou=subscribers,dc=example,dc=com エントリに追加しています。

プロキシ承認

プロキシ承認方式は、特殊な形式の認証です。自分のアイデンティティーでディレクトリにバインドしたユーザーに、プロキシ承認を使用して他のユーザの権限が与えられます。

プロキシ要求を許可するように Directory Server を設定するには、次のことを行う必要があります。

• 管理者には、ほかのユーザーとしてのプロキシ権限を与える。

• 一般ユーザーには、アクセス制御ポリシーで定義されている通常のアクセス権限を与える。

ディレクトリマネージャーを除く、ディレクトリのすべてのユーザーにプロキシ権限を与えることができます。また、ディレクトリマネージャーの DN をプロキシ DN として使用することはできません。プロキシ権限により、すべての DN (ディレクトリマネージャー DN を除く) をプロキシ DN として指定する権限が与えられるので、プロキシ権限を与える場合には十分な注意が必要です。同じ操作中に Directory Server が複数のプロキシ認証の制御を受け取った場合は、クライアントアプリケーションにエラーが返され、操作の試行は失敗します。

プロキシ認証の例

Example.com 社は、MoneyWizAcctSoftware としてバインドするクライアントアプリケーションに、Accounting Administrator と同じ LDAP データへのアクセス権限を与えようとしています。

次の条件が適用されます。

• クライアントアプリケーションのバインド DN は uid=MoneyWizAcctSoftware, ou=Applications,dc=example,dc=com。

• クライアントアプリケーションがアクセスを要求するターゲットサブツリーは ou=Accounting,dc=example,dc=com。

• ディレクトリ内に、ou=Accounting,dc=example,dc=com サブツリーへのアクセス権を持つ Accounting Administrator が存在する。

クライアントアプリケーションが Accounting サブツリーへのアクセス権を取得するには、Accounting Administrator と同じアクセス権を使用して、次の条件を満たす必要があります。

• Accounting Administrator は、ou=Accounting,dc=example,dc=com サブツリーへのアクセス権を持っている必要がある。たとえば、次の ACI は Accounting Administrator エントリに対するすべての権限を与えます。

  aci: (targetattr="*") (version 3.0; acl "allowAll-AcctAdmin"; allow (all) userdn="ldap:///uid=AcctAdministrator,ou=Administrators, dc=example,dc=com";)

• クライアントアプリケーションに対するプロキシ権限を与える次の ACI が、ディレクトリ内に存在する必要がある。

  aci: (targetattr="*") (version 3.0; acl "allowproxy- accountingsoftware"; allow (proxy) userdn= "ldap:///uid=MoneyWizAcctSoftware,ou=Applications, dc=example,dc=com";)

この ACI が設定されていれば、MoneyWizAcctSoftware クライアントアプリケーションがディレクトリにバインドしてから、プロキシ DN のアクセス権限を要求する ldapsearch や ldapmodify などの LDAP コマンドを送信できます。

この例で、クライアントが ldapsearch コマンドを実行する場合は、このコマンドに次の制御が含まれます。

$ ldapsearch -D "uid=MoneyWizAcctSoftware,ou=Applications,dc=example,dc=com" -w - \
 -Y "dn: uid=AcctAdministrator,ou=Administrators,dc=example,dc=com" ...

クライアントが ldapmodify コマンドを実行する場合は、このコマンドに次の制御が含まれます。

$ ldapmodify -h hostname -p port \
-D "uid=MoneyWizAcctSoftware,ou=Applications,dc=example,dc=com" -w - \
-Y"dn: uid=AcctAdministrator,ou=Administrators,dc=example,dc=com"
dn: uid=AcctAdministrator,ou=Administrators,dc=example,dc=com
changetype: modify
delete: userpassword
-
add: userpassword
userpassword: admin1

クライアントはそのままバインドしますが、プロキシエントリの特権が与えられます。クライアントには、プロキシエントリのパスワードは必要ありません。

フィルタを使用したターゲットの設定

ディレクトリ内に分散した多数のエントリに対して、アクセス制御の設定が必要な場合は、フィルタを使用してターゲットを設定することもできます。

フィルタを使って HR のすべてのユーザーに従業員エントリへのアクセスを許可するには、LDIF で次のような文を作成します。

aci: (targetattr="*") (targetfilter=(objectClass=employee))
 (version 3.0; acl "HR access to employees";
 allow (all) groupdn= "ldap:///cn=HRgroup,ou=People,dc=example,dc=com";)

この例では、ACI を ou=People,dc=example,dc=comエントリに追加することを仮定しています。

検索フィルタは、アクセス管理の対象となるオブジェクトを直接指定するわけではないので、誤ったオブジェクトへのアクセスを許可または拒否しないようにしてください。ディレクトリ構造が複雑になるほど、誤ったオブジェクトへのアクセスを許可または拒否してしまうリスクが大きくなります。さらに、フィルタによって、ディレクトリ内のアクセス制御に関する問題解決が難しくなる場合もあります。

コンマを含む DN のアクセス権の定義

DN にコンマが含まれている場合、LDIF ACI 文の中で特別な処理が必要です。ACI 文のターゲット部分とバインドルール部分で、1 つの円記号 (\) を使用して、コンマをエスケープする必要があります。次に、この構文の例を示します。

dn: o=Example.com Bolivia\, S.A. 
objectClass: top 
objectClass: organization 
aci: (target="ldap:///o=Example.com Bolivia\,S.A.") (targetattr="*") 
(version 3.0; acl "aci 2"; allow (all) groupdn = 
"ldap:///cn=Directory Administrators, o=Example.com Bolivia\, S.A.";)