ACL に受け入れ可能なエントリ

ACL に受け入れ可能なエントリは、次のとおりです。

• ワイルドカードを使用するエントリ
• ユーザー名、サーバー名、グループ名 (インターネットクライアントのユーザー名とグループ名も含む)
• LDAP ユーザー
• Anonymous (インターネットユーザーや HCL Notes® ユーザーからの匿名アクセスで使用)
• データベースレプリカ ID

ACL エントリの長さは、それぞれ最大 255 文字です。

階層名を使用して ACL に名前を追加すると、セキュリティを強化できます。例:

Sandra E Smith/West/Renovations/US

Randi Bowker/Sales/FactoryCo

ワイルドカードを使用するエントリ

データベースのアクセスに規則性を持たせるには、ACL でワイルドカード文字 (*) のある階層名を入力します。ワイルドカードは、共通名や組織単位の構成要素に使用できます。

ACL に特定のユーザー名やグループ名がまだ存在せず、階層名に含まれるコンポーネントにワイルドカードが含まれているユーザーやサーバーには、一致する各ワイルドカードエントリによって指定される最も高いレベルのアクセス権が与えられます。

ワイルドカードを使用した ACL エントリの例を次に示します。

*/Illustration/Production/Renovations/US

このエントリにより、次のユーザーには、指定したアクセスレベルが与えられます。

Mary Tsen/Illustration/Production/Renovations/US

Michael Bowling/Illustration/Production/Renovations/US

次のユーザーには、指定したアクセスレベルが与えられません。

Sandy Braun/Documentation/Production/Renovations/US

Alan Nelson/Renovations/US

ワイルドカードは、ACL エントリの左端の部分のみで使用できます。次は無効な指定の例です。

*/Illustration/*/Renovations/US 

次のようなユーザーを表すものとして、上のエントリを使用することはできません。

Michael Bowling/Illustration/West/Renovations/US

Karen Richards/Illustration/East/Renovations/US

ACL エントリでワイルドカードを使用する場合は、ユーザーの種類を [指定なし]、[混在グループ]、[ユーザーグループ] のいずれかにしてください。

ユーザー名

ACL には、認証された Notes® ユーザー ID を持つ任意のユーザー名や、名前とパスワードまたは SSL クライアント認証を使用して認証するインターネットユーザー名を追加できます。

• Notes® ユーザーの場合は、データベースのあるサーバーとそのユーザーが階層上同じ組織に属するかどうかには関係なく、各ユーザーの階層名付きの完全な名前 (John Smith/Sales/Renovations など) を入力します。
• インターネットユーザーの場合は、ユーザー文書の [ユーザー名] フィールドの先頭エントリとして表示される名前を入力します。
  注: [ユーザー名] フィールドに複数の別名を入力して、それらを認証で使用できます。ただし、セキュリティ認証のチェックを実行する際に使用されるのは、リスト内の先頭の名前です。これは、すべての HCL Domino® データベース ACL、サーバー文書のセキュリティに関する設定、.ACL ファイルで使用する名前です。

サーバー名

ACL にサーバー名を追加すると、レプリカが行うデータベースの変更を制御できます。セキュリティを強化するために、追加するサーバーの名前がデータベースのあるサーバーと階層上別の組織に属するかどうかには関係なく、サーバーの階層付きの完全な名前 (Server1/Sales/Renovations など) を入力します。

グループ名

同じアクセス権が必要な複数のユーザーやサーバーがある場合は、ACL にグループ名 (Training など) を追加します。ユーザーをグループに登録する場合、1 次階層名で登録する必要があります。グループのメンバーとしてワイルドカードを使用するエントリを指定することもできます。ACL にグループ名を追加する前に、HCL Domino® ディレクトリ内、またはディレクトリアシスタントデータベースでグループ認証用に設定されている 2 次 Domino® ディレクトリか外部 LDAP ディレクトリ内のいずれかに、グループをあらかじめ作成しておく必要があります。

グループを使用すると、データベース ACL を管理しやすくなります。ACL でグループを使用することには、次の利点があります。

• ACL に多数の名前を個々に追加するのではなく、グループ名を 1 つ追加できます。1 つのグループが複数の ACL に登録されている場合は、それぞれのデータベースで名前の追加や削除を行うのではなく、Domino® ディレクトリか LDAP ディレクトリ内でグループ文書を変更するだけで済みます。
• 複数のユーザーやサーバーのアクセスレベルを変更する場合は、グループ全体を一括変更できます。
• グループ名を使用すると、グループメンバーの役割分担や、部門や会社の組織を反映できます。

[Terminations] グループ

社員が退職するときは、Domino® ディレクトリにあるすべてのグループからその社員の名前を削除し、サーバーへのアクセスを拒否するために使用する [アクセス不可グループのみ] グループに追加します。サーバー文書内の [アクセス不可グループ] には、Domino® サーバーへのアクセス権を失った Notes® ユーザーとグループの名前が格納されます。また、組織内のすべてのデータベースの ACL から退職した社員の名前が削除されていることを確認する必要もあります。Domino® ディレクトリからユーザーを削除する際には、[削除済みユーザーをアクセス禁止グループに追加] オプションを選択することができます (このようなグループが作成済みの場合)。(そのようなグループが存在しない場合は、「アクセス禁止グループが未選択または有効ではありません」とダイアログボックスに表示されます。)

LDAP ユーザー

2 次 LDAP ディレクトリを使用してインターネットユーザーを認証できます。そして、これらのインターネットユーザー名をデータベースの ACL に追加し、ユーザーのデータベースへのアクセスを制御できます。

インターネットユーザー名を含む 2 次 LDAP ディレクトリを使用してグループを作成し、Notes® データベースの ACL エントリとしてそのグループを追加することもできます。例えば、インターネットユーザーが Domino® Web サーバー上のデータベースにアクセスを試みたとします。Web サーバーがそのユーザーを認証し、ACL に「Web」という名前のグループがあると、1 次 Domino® ディレクトリ内の検索に加えて外部の LDAP ディレクトリにある「Web」グループ内のインターネットユーザー名もサーバーによって検索できます。このケースが正しく処理されるためには、Web サーバー上のディレクトリアシスタントデータベースに、LDAP ディレクトリ用の LDAP ディレクトリアシスタント文書が格納されていて、文書の [グループの追加] オプションで [はい] が選択されていなければなりません。この機能は、データベース ACL のチェックで、外部 LDAP ディレクトリグループに格納されている Notes® ユーザー名を検索する場合にも利用できます。

LDAP ディレクトリユーザー名やグループ名をデータベース ACL に追加するとき、名前の形式には LDAP 形式を使用し、区切り文字にはカンマ (,) ではなくスラッシュ (/) を使用してください。例えば LDAP ディレクトリのユーザー名が次のような場合は、

uid=Sandra Smith,o=Renovations,c=US

データベース ACL には次のように入力します。

uid=Sandra Smith/o=Renovations/c=US

LDAP ディレクトリの非階層グループ名を入力するには、属性名ではなく、属性値だけを入力します。例えば、LDAP グループの非階層名が次のような場合は、

cn=managers

ACL エントリは次のようになります。

managers

グループの階層名を入力するには、LDAP の属性名を ACL エントリに含めます。例えば、グループの階層名が次のような場合は、

cn=managers,o=acme

ACL エントリは次のようになります。

cn=managers/o=acme

ただし、指定する属性名が Notes® で使用している属性名 (cn、ou、o、c) と完全に同じ場合は、ACL では属性名が表示されません。

例えば、次のような名前を ACL に追加すると、

cn=Sandra Smith/ou=West/o=Renovations/c=US

属性名が Notes® で使用している属性名と完全に同じであるため、ACL には次のように表示されます。

Sandra Smith/West/Renovations/US

LDAP ユーザーで受け入れ可能な ACL エントリ

cn=Scott Davidson+ id=1234, ou=Sales,o=Renovations

cn=Scott Davidson+id=1234/ou=Sales/o=Renovations

cn=Scott Davidson,o=Renovations\, Inc

cn=Scott Davidson/o=Renovations, Inc

uid=smd12345,dc=Renovations,dc=Com

uid=smd12345/dc=Renovations/dc=Com

uid=Sandra Smith,o=Renovations,c=US

uid=Sandra Smith/o=Renovations/c=US

匿名

最初に認証を受けずにサーバーにアクセスするユーザーやサーバーは、サーバーでは [Anonymous] という名前で処理されます。サーバーで認証されていないインターネットユーザーや Notes® ユーザーには、データベースに対する [Anonymous] のアクセス権が与えられます。

一般的に、[Anonymous] のアクセス権は、一般公開されるサーバー上のデータベースで使用されます。匿名ユーザーや匿名サーバーからデータベースへのアクセスのレベルを制御するには、アクセス制御リストに [Anonymous] という名前を入力し、適切なレベルのアクセス権を割り当てます。通常、[Anonymous] のユーザーには、データベースに対して [読者] のアクセス権を与えます。

すべてのデータベーステンプレート (.NTF) ファイルに対する [Anonymous] の ACL エントリは、デフォルトでは [読者] のアクセスレベルを持ちます。そのため、ユーザーやサーバーは、テンプレートに基づいて .NSF ファイルの作成や更新を実行する際、そのテンプレートから読み込みを正常に実行できます。

データベースファイル (.NSF ) ファイルに対する [Anonymous] の ACL エントリは、デフォルトでは [なし] のアクセス権になります。

匿名ユーザー ([Anonymous] エントリによってデータベースへのアクセス権が付与されているユーザーと、[-Default-] エントリによってアクセス権が付与されているユーザー) は、自分のアクセスレベルで許可されていない処理をデータベース内で実行しようとすると、認証を得るよう求められます。例えば、[Anonymous] のアクセス権として [読者] が設定されている場合、匿名ユーザーが文書を新規作成しようとすると、名前とパスワードで認証を得るよう求められます。

Domino® サーバーでグループ名 [Anonymous] が使用されるのは、アクセス制御を検査するときだけです。例えば、データベース ACL で [Anonymous] に [作成者] のアクセス権を設定してある場合、文書の [作成者] フィールドには本当のユーザー名が表示されます。ただし、Domino® サーバーで文書の [作成者] フィールドに本当の名前が表示できるのは、匿名 Notes® ユーザーの場合だけです。匿名インターネットユーザーの本当の名前は表示できません。匿名アクセスが使用されているかどうかにかかわらず、[作成者] フィールドはセキュリティの対象とはなりません。作成者名の有効性をチェック対象とする必要がある場合は、署名入り文書にしてください。

レプリカ ID

データベース内のエージェントが @DbColumn や @DbLookup を使用して別のデータベース内のデータを取得できるようにするには、取得対象のデータが含まれるデータベースの ACL に、そのエージェントを含むデータベースのレプリカ ID を入力します。エージェントを含むデータベースは、取得対象のデータが含まれるデータベースに対して [読者] 以上のアクセス権を持っていなければなりません。どちらのデータベースも、同一のサーバー上に存在している必要があります。データベース ACL 内で、レプリカ ID は 85255B42:005A8fA4 のように表示されます。レプリカ ID には小文字と大文字の両方を使用できますが、引用符で囲まないでください。

取得先データベースの [-Default-] のアクセスレベルが [読者] 以上に設定されている場合、このデータベースは、アクセス制御リストにレプリカ ID が含まれていなくてもデータを取得できます。

ACL エントリの評価順序

ACL エントリは、決まった順序で評価されます。その結果によって、データベースにアクセスしようとする認証済みユーザーに付与されるアクセスレベルが決まります。ユーザーがサーバーでの認証に失敗すると、サーバーは、ユーザー名が [Anonymous] であるものとしてアクセス権を計算し、その結果に従ってアクセスを許可します。

• ACL は、まずユーザー名が ACL 内の明示的なエントリに一致するかどうかをチェックします。一致するすべてのユーザー名をチェックします。例えば、Sandra E Smith/West/Renovations は、Sandra E Smith/West/Renovations/US と Sandra E Smith という複数のエントリと一致する場合もあります。同一人物のエントリが 2 つ存在し、それらのアクセスレベルが異なっている場合 (アクセスレベルが別々の管理者によって別々の時期に適用された場合など)、データベースにアクセスしようとするユーザーには、該当ユーザーの ACL 内における 2 つのエントリのアクセス権限のうちで最上位レベルのアクセス権と、それらのエントリに指定されたアクセス権限のすべてが付与されます。
  注: ACL に共通名 (Sandra E Smith など) だけを入力した場合は、そのユーザーの名前とデータベースサーバーが同一のドメイン階層に存在している場合に限り、エントリが一致します。例えば、ユーザーが Sandra E Smith で、その階層名が Sandra E Smith/West/Renovations、データベースサーバーが Manufacturing/FactoryCo の場合、エントリ Sandra E Smith は、サーバー Manufacturing/FactoryCo 上の ACL では正しいアクセスレベルを取得できません。ユーザーが他のドメイン内のサーバー上の ACL で正しいアクセスレベルを取得できるようにするには、完全な階層名で名前を入力する必要があります。
• ユーザー名が一致しない場合、ACL は一致する可能性があるグループ名エントリが存在しているかどうかをチェックします。データベースにアクセスしようとするユーザーが複数のグループエントリに一致する場合 (そのユーザーが Sales のメンバーであり、Sales に Renovations Sales と Sales Managers という 2 つのグループエントリがある場合など)、ユーザーには、該当グループの ACL 内における 2 つのエントリのアクセス権限のうちで最も高いレベルのアクセス権と、それらのエントリに指定されたアクセス権限のすべてが付与されます。
  注: ユーザーが、ACL 内の明示的なエントリと一致し、ACL にリストされているグループのメンバーでもある場合、そのユーザーは明示的なエントリに割り当てられているアクセスレベルを常に取得します。これは、グループのアクセスレベルのほうが高い場合でも当てはまります。
• グループ名が一致しない場合、ACL は一致する可能性があるワイルドカードエントリが存在しているかどうかをチェックします。データベースにアクセスしようとするユーザーが複数のワイルドカードエントリに一致する場合、そのユーザーには、一致するすべてのワイルドカードエントリのアクセス権限のうちで最も高いレベルのアクセス権と、それらのエントリに指定されたアクセス権限のすべてが付与されます。
• グループエントリとワイルドカードエントリの両方が、データベースへのアクセスを試みるユーザーに適用された場合、ユーザーは、グループエントリに割り当てられたアクセス権を付与されます。例えば、グループ Sales が [読者] のアクセス権を持ち、ワイルドカードエントリ */West/Renovations が [管理者] のアクセス権を持っている場合に、両方のエントリがユーザーに適用されると、ユーザーはデータベースへの [読者] のアクセス権を持ちます。
• これらのチェックをすべて行っても、データベースの ACL エントリ内で一致するものが得られない場合、そのユーザーには [-Default-] エントリで定義されているアクセスレベルが付与されます。