アクセス制御の使用例

この項の例では、架空のISP会社Example.comが会社のアクセス制御ポリシーを実装する様子を示します。

またACIの例は、インストールinstall_path/resources/ldif/Example.ldifに用意されているサンプルのLDIFファイルの中にもあります。

すべてのサンプルでは、LDIFファイルを使用して特定のタスクを実行する方法を説明しています。次の図は、example.comのディレクトリ情報ツリーをグラフィカルに示したものです。

Example.comでは、Webホスティング・サービスおよびインターネット・アクセスを提供します。Example.comのWebホスティング・サービスでは、クライアント企業のディレクトリをホストします。Example.comは、Company333とCompany999という2つの中規模企業のディレクトリを実際にホストし、部分的に管理しています。Example.comは、多数の個人サブスクライバにインターネット・アクセスも提供しています。

Example.comは、次のアクセス・ルールを設定しようとしています。

• Example.comの従業員に対して、Example.comツリー全体に対する匿名の読取り、検索および比較アクセスを許可する。「匿名アクセスの許可」を参照してください。

• Example.comの従業員に対して、homeTelephoneNumberやhomeAddressなどの個人情報への書込みアクセスを許可する。「個人エントリへの書込みアクセスの許可」を参照してください。

• Example.comサブスクライバに対して、エントリdc=example,dc=comの企業問合せ情報を読み取る権限を付与する(その下のエントリは読めない)。「特定のレベルへのアクセス権の付与」を参照してください。

• Example.comの従業員に対して、特定の重要なロール以外の任意のロールを自身のエントリに追加する権限を付与する。「キー・ロールへのアクセス権の制限」を参照してください。

• 特定の管理者に対して、接尾辞のディレクトリ・マネージャと同じ権限を付与する。「ロールに対する接尾辞全体への完全アクセスの許可」を参照してください。

• Peopleブランチのエントリに対するすべての権限をExample.comのHuman Resourcesグループに付与する。「グループに対する接尾辞への完全アクセスの許可」を参照してください。

• 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 entryに追加されることを前提としています。userPassword属性は、ACIの範囲に含まれていません。

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";)

この例では、ou=subscribers,dc=example, dc=comエントリにaciが追加され、ユーザーは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 entryエントリに追加されることを前提としています。

キー・ロールへのアクセス権の制限

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

たとえば、世界規模の企業サイトで特定の曜日の特定の時間に対応できるシステム管理者のサブセットを特定して、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のような強力な認証を強制的に使用できることによって、セキュリティが向上する

• ディレクトリ・マネージャのパスワードを知るユーザーを少数に抑えられるため、セキュリティが向上する

• ロギングによりトレーサビリティが向上する

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

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インスタンスを作成する場合、ディレクトリへの完全なアクセス権を持つAdministratorsグループcn=Administrators,cn=configがデフォルトで作成されます。

Example.comのHuman Resourcesグループは、ディレクトリのou=Peopleブランチへの完全なアクセスが許可され、このグループのメンバーは、「ACI "HR"」に示すように、従業員ディレクトリを更新できます。

ACI "HR"

HRグループに対して、ディレクトリのemployeeブランチへのすべての権限を付与するには、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の従業員はだれでも、「ユーザーに対するグループへの自身の追加または削除の許可」に示すように、これらのいずれかのグループのメンバーになれます。

「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 "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を設定しています。

Example.comでは、従業員はou=Social Committeeサブツリーの下の任意のグループ・エントリに自身を追加できます(「ACI "Group Members"」を参照)。

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:00～18:00にアクセスがリクエストされること。

• 各会社の指定されたIPアドレスからアクセスがリクエストされること。

これらの条件は、各会社のACI (ACI "Company333"およびACI "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の下で接尾辞の一部へのアクセスを拒否できます。

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

次の例で、Example.comは、すべてのサブスクライバが自身のエントリの下で接続時間やアカウント残高などの課金情報を確認できるようにしたいと考えています。また、その情報への書込みアクセスについては明示的に拒否したいと考えています。readアクセスについては、「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エントリに追加されることを前提としています。

プロキシ認可

プロキシ認可方式は、認証の特殊な形式です。自身のIDを使用してディレクトリにバインドするユーザーは、プロキシ認可により別のユーザーの権限が付与されます。

プロキシ・リクエストを許可するようにDirectory Serverを構成するには、次を実行する必要があります。

• 管理者に別のユーザーとしてのプロキシ権限を付与する。

• 一般ユーザーに対して、アクセス制御ポリシーで定義される通常のアクセス権を付与する。

プロキシ認可の例

Example.comでは、MoneyWizAcctSoftwareとしてバインドするクライアント・アプリケーションに、LDAPデータに対してAccounting Administratorと同じアクセス権を与えたいと考えています。

次のパラメータが適用されます。

• クライアント・アプリケーションのバインド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.";)