IBM Lotus Notes/Dominoでの [読者]フィールドの理解と活用

コンテンツ Lotus Notes/Dominoでのセキュリティー手法の概要 [読者]フィールドの実装 ロールの使用 複製、エージェント、およびビューでの[読者]フィールドの効果 トラブルシューティング まとめ リソース 筆者について ご意見ご要望をお寄せ下さい

Raphael Savir (info@lsdevelopment.com), Principal Developer, LS Development Corporation

レベル：中級
原文の掲載：2007年 1月 30日
原文はこちら (US)

IBM Lotus Notes/Dominoのたいへん役に立つセキュリティー機能である[読者]フィールドを実装し、活用しましょう。この機能が複製、エージェント、およびビューに与える影響と、[読者]フィールドに関する2つの一般的な問題のトラブルシューティング方法を理解します。

[読者]フィールド([読者および作成者のアクセス権]または[読者]とも呼ばれます)は、IBM Lotus Notes/Dominoデータベース内の文書へのアクセスを制限します。このセキュリティー機能は、望まない侵入を堅固に防御する一方、指定されたユーザーには、本来見ることができる文書への容易なアクセスを提供します。つまり、データ・アクセスを付与するためのインテリジェントできめ細かい方法といえます。この記事では、[読者]フィールドを実装するためのロードマップを示し、実装途中の問題を避けるために役に立つ多数のヒントを紹介します。

この記事はLotus Notes/Dominoアプリケーション開発者を対象としていますが、概念および例を理解する上で、特定のレベルの専門知識は必要ありません。

Lotus Notes/Dominoでのセキュリティー手法の概要

Lotus Notes/Dominoには、データベース内のデータをセキュアにする多数の方法が用意されています。[読者]フィールドの位置づけを理解するために、より一般的な方法の概要を以下に示します。

1. 物理的アクセス。ケーブル、ネットワーク接続、およびモデム・アクセスのない部屋にサーバーが置かれていると、その部屋に立ち入らない限り利用できないため、データに対する一定レベルのセキュリティーが自然に確保されます。理論的には良い試みかもしれませんが、通常、ほとんどのデータには適さないソリューションです。
2. サーバー・アクセス。Lotus Dominoサーバーは、サーバー文書内のアクセス・リストに基づいてユーザーのアクセスを許可/拒否します。これは、有効なIDファイルとネットワーク接続をまだ維持している退職社員からのアクセスを拒否するときによく用いられる方法です。
3. アクセス制御リスト(ACL)。各データベースにはそれぞれ固有のACLがあり、ユーザー名、所属するグループ、またはIDの階層に基づいてユーザーのアクセスを許可/拒否できます。
4. [読者]フィールド。この機能は、ACLで使用されているものと同じ条件に基づいて、個々の文書へのアクセスを許可/拒否できます。また、ACLで定義される[ロール]も使用できます。
5. 暗号化。この機能を使用すると、個々の文書内の個々のフィールドへのアクセスを許可/拒否できます。暗号化は、ユーザーの名前またはIDファイル間で物理的に共有されているシークレット・キーに基づいて使用できます。

これらのトピックはいずれも興味深く、考慮する価値がありますが、この記事では[読者]フィールドを使用してデータをセキュアにする方法に焦点を当てます。

Lotus NotesクライアントまたはWebブラウザーを使用するユーザーがデータベースにアクセス権を持っている場合、そのユーザーは上記リストの3番の方法を通じてアクセスが付与されたものと推測できます。これ以上のセキュリティー手法(たとえば、[読者]フィールド)が講じられない場合は、理論上、このユーザーは任意の文書にアクセスする方法を発見できます。たとえば、主要ビューに含めないことによってデータを非表示にしても(開発者の観点では、これは簡単に実現できます)、データを見つけようとしているユーザーからは、そのデータを保護できません。

長年にわたりLotus Notes/Dominoで利用できるさまざまなセキュリティー手法を研究、テスト、および使用してきた結果を表1にまとめます。この表は、さまざまな状況で最適のセキュリティー手法を決める際に役立ちます。

メモ:[非表示化]という用語は、公開ビューに表示しないことによってデータを隠す、または非表示式を使用してフォーム上のデータを隠すことを意味します。これは、真のセキュリティーではありませんが、特定の状況では役に立ちます。

表1から、[読者]フィールドを使用すると、他のセキュリティー手法を上回る強力な利点を得られることがわかります。[読者]フィールドは真のセキュリティーを提供しますが、Lotus Notes クライアントまたはWebブラウザーのどちらを用いる場合でも、適切なアクセス権を持っていればこの機能を簡単に使用できます。特に、データがビューに表示される点と、エージェントがプログラマチックにデータにアクセスできる点が重要です。さらに、この機能は比較的実装が簡単で、将来、セキュリティーまたはビジネスのニーズが変更されても、容易に変更できます。

上に戻る

[読者]フィールドの実装

[読者]フィールドを使用するには、通常、[フィールド]プロパティー・ボックスでフィールドのタイプを[読者]に設定します(図1参照)。これだけで完了です。このフィールドにユーザー名、グループ、またはロール(後述します)を入力すると、指定されたユーザーだけが、このフォームに基づく文書を見ることができます。

図1. [フィールド]プロパティー・ボックス

複数の名前を追加できるようにするために、このフィールドは複数値フィールドにするとよいでしょう。このフォームで文書を保存してフィールドのプロパティーを見ると、[フィールドフラグ]に[SUMMARY READ-ACCESS NAMES]と表示されています(図1参照)。これは、データは[(SUMMARY)]ビューに表示でき、これが[読者]フィールド(READ-ACCESS NAMES)であることを示しています。[読者]フィールドを使用するときの一般的なミスとして、フィールドを正しいタイプに設定し忘れることがあります。文書プロパティーでこの簡単なチェックを行うと、正しく設定したことを確認できます(図2参照)。

図2. [文書]プロパティー・ボックス

複数の[読者]フィールドの使用

フォームには、複数の[読者]フィールドを配置できます。複数の[読者]フィールドがあるときは、それぞれの[読者]フィールドで指定されている名前を累積したものが、アクセス可能なユーザーとなります。また、文書の編集権限を持つユーザーは、[読者]リストを追加できます(文書プロパティーの最後のタブ)。これは、$Readersフィールドとして保存されます。このようなフィールドが追加された場合、文書アクセスの決定に関してこのフィールドは、他のすべての[読者]フィールドとまったく同じように扱われます。

[作成者]フィールドの使用

[作成者]フィールドを作成すると、そのプロパティーは[SUMMARY READ-WRITE ACCESS]となります。興味深いことに、文書内に1つの[作成者]フィールドだけがあって[読者]フィールドがない場合は、誰でもこの文書を見ることができます。しかし、この文書を編集できるのは、データベースで[作成者]のアクセス権を持ち、[作成者]フィールドでも指定されているユーザーだけです。また、ACLで[編集者]以上のアクセス権を持つユーザーは、[作成者]フィールドで指定されているかどうかにかかわらず、文書を編集できます。

ただし、[読者]フィールドもある場合、[作成者]フィールドは[読者]リストと[編集者]リストの両方として機能します。たとえば、ACLで[編集者]のアクセス権を持つユーザーがどちらのフィールドでも指定されていない場合は、データベース内のすべての文書に対して[編集者]の権限を持っているにもかかわらず、そのユーザーは文書を見ることができず、そのために文書を編集することもできません。ユーザー名が文書内のいずれかの[[読者]]フィールドまたは[作成者]フィールドで指定されていると(どちらのフィールドも任意の数だけ配置できます)、そのユーザーは文書の読み込みおよび編集ができます。

LotusScriptを使用すると、このようなフィールドをプログラマチックに文書に追加できます。コードは、リスト1のようになります。

Dim item as NotesItem
Set item = doc.ReplaceItemValue ( "RNames", NewValue )
Item.IsReaders = True
‘ Item.IsSummary = True

このコードでは、RNamesが[読者]フィールドの名前で、NewValueは文字列または文字列の配列です。また、最近のLotus Notes/Dominoのリリースでは、[Item.IsSummary = True]は不要です。初期のリリースでは、新規フィールドが要約データとして保存されることを保証するために、これが必要でした。

@式言語を使用して新しい[読者]フィールドの追加を試みても、正しいタイプが割り当てられません。これは、テキスト・フィールドとみなされてしまいます。文書プロパティーを調べると、[SUMMARY READ ACCESS]ではなく、[SUMMARY]と表示されます。フィールドがすでに存在し、コンテンツを更新すると、@式言語は正しい[読者]属性を保持するようになります。

名前の書式設定

[読者]フィールドおよび[作成者]フィールドには、階層なし形式または正規形式で個人の名前を指定する必要がありますが、省略形式は使用できません。たとえば、[CN=Raphael Savir/OU=Boston/O=LSDevelopment]は正しく、[Raphael Savir]も正しいですが、[Raphael Savir/Boston/LSDevelopment]は機能しません。

これは、紛らわしい方法といえるでしょう。[読者]フィールドおよび[作成者]フィールドでは、読みやすくするために正規データが省略形式で表示されるからです。文書を開いて、このようなフィールドの値を見ると、[Raphael Savir/Boston/LSDevelopment]と表示されています。しかし、文書プロパティーを使用して背後にあるデータを見ると、実際には正規形式の[CN=Raphael Savir/OU=Boston/O=LSDevelopment]で保存されていることがわかります(図3参照)。正規名の表示をクリーンアップするこの機能はすべての[名前]フィールドに適用されますが、プレーン・テキスト・フィールドには適用されません。

図3. 正規形式で保存された[読者]フィールド

[読者]フィールドまたは[作成者]フィールドに階層なしの名前を入力した場合は、サーバーがユーザーと同じ階層を持つ限り、そのフィールドは機能します。たとえば、勤務先の会社が別の会社と合併し、異なる階層のサーバー間でデータを複製するケースを考えましょう。一方はApps/NorthEast/LSDevelopmentで、もう一方はHQ/ACMEだとします。ユーザーがそれぞれのレプリカにあるデータにアクセスを試みるとき、ユーザーのデータが階層なしの名前で[読者]フィールドに指定されている場合、このユーザーはサーバーApps/NorthEast/LSDevelopmentにのみアクセスできます。階層(名前の[ /O=]の部分)をこのサーバーだけと共有しているためです。相互認証によってサーバーHQ/ACMEにアクセスできるようになりますが、[読者]フィールドおよび[作成者]フィールドにより、データ自体へのアクセスは認められません。

ここでは、正規名が最も安全であることを学びました。省略名は使用できません。そして、会社またはドメインの境界を超えてデータが複製されないことが確かな場合に限り、階層なしの名前を使用できます。

上に戻る

ロールの使用

メモ:この記事では、業務上の役割（roles）を指すときは通常の[役割]と表記します。しかし、各Lotus NotesデータベースのACLにある機能を指すときは、ブラケットで囲み、[ロール]と表記します。

[読者]フィールドを初めて使用するときは、文書にアクセスする必要がある個々のユーザーの名前をフィールドに入力したくなります。しかし、これは実用的な方法ではありません。社内でそのユーザーの業務上の役割が変更されると、多数の文書、ときには数十万もの文書でそのユーザー名を置き換えなければなりません。これを正確に実行することは不可能でないとしても、別の方法があればこのような作業はしたくありません。多くの企業ではこのようなケースが頻繁に発生するため、この状況への対策を準備しておく必要があります。

また、[読者]フィールドが大規模なユーザー・グループを参照することがあります。たとえば、アプリケーション内で、30人の取締役と役員がすべての売上データを見る必要があるものとします。各文書でこれらの名前を繰り返すことはスペースの無駄です。もちろん、より多くの名前がある場合は、名前のリストを変更する頻度も増加します。また、あまり一般的ではありませんが、フィールドのSUMMARYデータは32Kを超えられないという制限があります。

代わりに、可能な限りグループまたは[ロール]を使用することをお勧めします。理論的にはどちらでもかまいませんが、実践的には、できる限り[ロール]を使用してください。グループと[ロール]の違いを考えるとき、グループはDominoディレクトリーで維持されているという点に注目するとよいでしょう。グループ名は何千もあり、他の会社と合併するとグループ名が変更されることがあります。また、ディレクトリーが壊れたり、ユーザー自身では解決できない問題がディレクトリーに発生する可能性が常にあります。ユーザー[Rafael Savir/Boston/LSDevelopment]にロールが割り当てられたACLを図4に示します。

図4. ユーザーに[ロール]が割り当てられたACL

一方、[ロール]はアプリケーションに特有のものです。ACLで数回クリックするだけで、1つのグループまたは複数のグループに[ロール]を適用できます。1つのグループから[ロール]を削除し、別のグループに適用できます。また、いざというときは、ACLに登録されている個人名に[ロール]を適用することも可能です。ディレクトリーが壊れたという危機的な状況が発生しても、ユーザーを一時的にACLに追加し、関連する[ロール]をそれらのユーザーに適用することにより、重要なデータへのアクセスを確保できます。もし、[読者]フィールドで[ロール]の代わりにグループが使用されていると、このような対応は不可能です。

このような方法で[ロール]を使用するには、保護された文書へのアクセスが必要なグループを把握します。たとえば、以下のようなグループだと仮定します。

• 執行委員会(Executive Committee)
• 人事部(HR Reps)
• 営業管理チーム(Sales Management Team)

これらの人々にどのようにアクセスを付与するのかという問題に、次の2つの方法でアプローチできます。1つは各グループ用の[ロール]を作成する方法、もう1つは3つのグループすべてに適用する1つの[ロール]を作成する方法です。どちらにするのかは実際の状況に応じて異なりますが、[ロール]は75個まで使用できるので、一般に、作成および適用方法は自由に考えてよいでしょう。私たちは、長年アプリケーション開発で[ロール]を使用し、[ロール]を使用する上で役に立つ以下のようなガイドラインを集めてきました。これらは絶対的なルールではありませんが、どのケースでも、アプリケーションの問題を防ぐ効果がありました。

1. ロールは短くしてください。これはディスク・スペースを節約するだけでなく、コード内で[ロール]を正しく入力しやすくなります。時間が経つにつれて、これが必要となります。
2. スペースまたは変な句読点を使用しないでください。そうすると、正しく入力しやすくなるだけでなく、全文検索での問題や、URLを介して[ロール]を渡す必要があるときに、Webアプリケーションでの潜在的な問題を避けられます。
3. グループ名を真似ることは良い方法です。ただし、時間の経過にともない、グループ名が変更されることがあります。
4. 常に、開発者およびシステム管理者用に少なくとも1つの[ロール]を予約しておいてください。つまり、Developmentというグループがある場合は、単に[Dev]または[Development]という[ロール]は作成しないでください。これらの[ロール]は、このアプリケーションで作業している実際のLotus Notes/Domino開発者のために使用されるべきものだからです。他のグループ用には、たとえば、[ProdDev]という[ロール]を使用します。

この例では、以下の[ロール]を持つ[読者]フィールドを作成します。

• [Execs]
• [HR]
• [SalesManagers]
• [Dev]
• [Admin]

最後の2つのロールは、すべての開発者およびシステム管理者がデータにアクセスできるようにするために追加しました。

上に戻る

複製、エージェント、およびビューでの[読者]フィールドの効果

[ロール]および[読者]フィールドのセットアップ方法が正確にわかったので、データにアクセスする他の方法についても少し考えてみましょう。特に、[読者]フィールドを文書に適用した後は、複製、エージェント、およびビューが予期せぬ動作を示す可能性があります。このセクションでは、これらの点について詳しく調べます。

複製

サーバー間でデータが複製されるときは、前述したように、すべてのサーバーを[Admin]ロールに含めることだけを考慮します。これは、LocalDomainServersグループを通じて行うことができ、ドメイン内のすべてのサーバーが、データベース内で[読者]が制限されたすべての文書を参照できます。

すべてのサーバーにすべてのデータを複製する必要がない場合は、このアプローチを変更します。この例として、パフォーマンスを良くするために、各地域がその地域のデータだけを維持する大規模な営業アプリケーションが挙げられます。このアプリケーションでは、[Servers-APAC]、[Servers-EMEA]などの[ロール]を使用し、地域に応じてこれらの[ロール]を文書に適用した後、ACL内で個々のサーバー名に適用します。LocalDomainServersまたは他のグループを通じてすべてのサーバーにすべての文書へのアクセスを不用意に付与しないように注意してください。このため、このようなモデルを構築した後は、慎重なテストが必要です。

より困難なのは、ローカル複製をどのようにすべきかという問題です。たとえば、20,000名の営業担当員がそれぞれラップトップを持ち、毎晩各自のデータをローカルに複製するケースを考えます。[読者]フィールドがなければ、複製/保存の競合が心配ですが、問題はそれだけです。しかし、[読者]フィールドがあると、ローカル・レプリカがサーバー・コピーと同期しなくなる可能性があります。つまり、ローカル・コピーとサーバー・コピーの両方で文書が変更され、サーバー側の編集によって、[読者]フィールドからユーザー名が削除されてしまうケースです。

言い換えると、2つのレプリカのいずれかで、該当する文書へのアクセスが同時に拒否されると、複製の競合は解決できません。その結果、サーバー側はサーバー自身の編集を保持し、ローカル・コピー側はそれ自身の編集を保持し、どちらも同期していないことに気付きません。この問題の簡単なソリューションはなく、全体のアーキテクチャーとワークフローを設計する際は、この点を考慮しなければなりません。

エージェント

[読者]セキュリティーに関しては、エージェントは非常に明快です。たとえば、ボタンのクリックによってエージェントが起動された場合は、そのユーザーがアクションを実行しているかのように、エージェントが実行されます。ユーザーが文書へのアクセス権を持っていると、エージェントもその文書にアクセスできます。ユーザーがその文書へのアクセス権を持っていない場合は、エージェントの実行時にエラーが表示されます(たとえば、[エントリが索引に見つかりません]または[その操作を試みる権限がありません]など)。

スケジュール設定されたエージェントの場合は、[代理で実行]フィールドに入力されていない限り、エージェントは、エージェントの署名者の権限で実行されます。[代理で実行]フィールドに入力されている場合は、そのユーザーの権限で実行されます(図5参照)。

図5. [エージェント]プロパティー・ボックス

ビュー

機能およびパフォーマンスの両面で、ユーザーへの影響が最も大きいのはビューと考えられます。

ビューがカテゴリー化されている場合は、三角アイコンをともなうカテゴリーがユーザーに表示されますが、ユーザーがそのカテゴリー内の文書を見られないことがあります。これは、ユーザーから寄せられる最も一般的なクレームです。1つの解決方法として、[単一カテゴリの表示]オプションを使用して埋め込みビューを作成します(図6参照)。そして、ユーザーがアクセス権を持つカテゴリーのリストを提示し、表示するカテゴリーをユーザーに選択してもらいます。この方法では、他のカテゴリーが表示されないため、ユーザーが空のビューを見つけることはありません。この機能はLotus Notesクライアントで使用できるだけでなく、Webブラウザーでもシームレスに動作します。もう1つの解決方法としては、空のカテゴリーができないようなカテゴリー構成を再検討します。

図6. 埋め込みビューでの単一カテゴリの表示

[読者]フィールドにより、ビューのパフォーマンスが非常に低下することがあります。これは、サーバーが各文書ごとに、その文書を表示すべきかどうかをチェックするためです。これを各ユーザーごとに行うので、同時にユーザーがたくさんいて、[読者]フィールドを持つ文書が多数あると、サーバー/アプリケーションの速度が極端に低下する可能性があります。営業または人事部のアプリケーションなど、多数のユーザーがビュー内の文書の小さなサブセットにアクセスする場合は、特にこれが顕著になります。この場合のソリューションも、[単一カテゴリの表示]を使用して埋め込みビューを作成することです。通常、この方法は、[読者]フィールドを持つ文書がまったくない状態でネイティブのビューを開くよりも、速くなります。

別の方法として、カテゴリー化して、最初にビューを省略しておくこともできます。この方法では、前述のような問題(カテゴリーは表示されるが、カテゴリー内の文書が表示されない問題)が生じる可能性がありますが、スピードは向上します。また、状況によっては、データをいくつかのビューに分割し、最も適したビューにユーザーを導く方法も意味があります。たとえば、ユーザーがナビゲーションで[地域売上]ボタンをクリックしたときに、@UserRolesをチェックする式を用意しておき、[全米売上]、[アジア太平洋地域売上]などユーザーに適したビューを開くことができます。

ビューのパフォーマンスの詳細については、developerWorks Lotusの記事[Lotus Notes/Domino 7 アプリケーションのパフォーマンス:第 2 部:データベースのビューの最適化]を参照してください。

上に戻る

トラブルシューティング

このセクションでは、ユーザー・グループや会議でよく問題となる2つのトラブルシューティング・トピックを解決します。

複数値の[読者]フィールドの使用

フォームで[読者]フィールドを単一値にしたとき、値を追加する必要性が後で生じた場合は、値を追加するエージェントを書くことによってこれを行うことがあります。ここまでは良いのですが、ユーザーが文書を編集して保存すると、フォームはそのフィールドを複数値ではなく、単一値として扱い、[読者]フィールドが無効になることがあります。

たとえば、[読者]フィールドで[HR]ロールを指定したケースを考えます。1年後、[ProdDev]ロールも指定した方がよいことに気付きました。この値を追加するエージェントを作成し、[ProdDev]ロールを持つユーザーでテストしたところ([HR]ロールではテストしません)、すべてがうまくいきました。しかし、フォームでフィールド・プロパティーを変更しなかったため、誰かがそのフォームで文書を保存した後、[読者]フィールドの値が、"[HR]" "[ProdDev]"ではなく、"[HR], [ProdDev]"になっていました。つまり、この時点で、[読者]フィールドは[[HR], [ProdDev]]という名前のユーザーまたはグループを検索し(コンマは名前の一部で、区切り記号とはみなされません)、この文書へは誰もアクセスできません。

この種類の問題を避けるには、常に[読者]フィールドおよび[作成者]フィールドを複数値にすることです。

隠された文書の回復

文書で[読者]フィールドを使用し、誤ってどのユーザーからもアクセス不能にしてしまった場合は(たとえば、前述のように、複数のエントリーを単一の無効なエントリーとして入力した場合など)、[フルアクセスアドミニストレーション]モード(図7参照)を使用すると、データベースを開いて、これらの文書を回復できます。適切な[読者]値を適用するエージェントをあらかじめ作成しておき、[フルアクセスアドミニストレーション]モードの状態でこのエージェントを起動し、データを修復します。

ほとんどの組織では、システム管理者の一部のグループだけがこの[フルアクセスアドミニストレーション]モードを使用する権限を持つので、ユーザーは修復してもらうまで待たされることがあります。しかし、サーバーを操作しなくても、ローカルのLotus Notes クライアントを使用すれば、少なくとも[読者]セキュリティーを迂回することができます。

図7. [フルアクセスアドミニストレーション]オプション

上に戻る

まとめ

[読者]フィールドを立案および実装する際に、できるだけ容易かつ効率よく作業を進められるように、この記事が役立つことを望んでいます。[読者]フィールドは素晴らしい機能であり、優れたセキュリティー手法です。あらかじめすべてを構成しておけば、簡単に実装および維持することができます。大切なのは、あらかじめすべてを構成することです。これを行うことにより、Lotus Notes/Dominoの強力な機能を利用しながら、素晴らしい経験を得られるでしょう。

リソース

• developerWorks Lotusの記事[Lotus Notes/Domino 7 アプリケーションのパフォーマンス:第 1 部:データベース・プロパティーと文書コレクション]
• developerWorks Lotus の記事[Lotus Notes/Domino 7 アプリケーションのパフォーマンス:第 2 部:データベースのビューの最適化]
• developerWorks Lotusの記事[アプリケーション・パフォーマンスのトラブルシューティング: パート 1: トラブルシューティングの手法とコードのヒント]
• developerWorks Lotusの記事[アプリケーション・パフォーマンスのトラブルシューティング:パート 2: Lotus Notes/Domino 7 の新規ツール]
• developerWorks Lotusの記事[アプリケーションのパフォーマンス・チューニング第1回]
• developerWorks Lotusの記事[アプリケーションのパフォーマンス・チューニング第2回]
• Lotus Support technote[Documents with Readers Fields do not work as expected in Directory Catalog](US)

• developerWorksからLotus Dominoのトライアル・バージョン(US)をダウンロードできます。
• developerWorksからLotus Notesのトライアル・バージョン(US)をダウンロードできます。

• ディスカッション・フォーラム (US) にご参加ください。
• developerWorks Lotus Team ブログ(US) をご参照ください。

筆者について

		Corporation(http://www.lsdevelopment.com)を経営しており、連絡先はinfo@lsdevelopment.comです。

上に戻る