3.15.5 それぞれのアクセス制御情報の特徴

ここでは,これまで説明してきたアクセス制御情報について,それぞれの特徴を説明します。アクセス制御情報は,アクセス権判定の順序や用途によって,それぞれ特徴を持っています。これらの特徴を考慮した上で,文書空間またはオブジェクトに適切なアクセス制御情報を設定してください。

<この項の構成>
(1) アクセス権判定の流れ
(2) アクセス制御情報の特徴
(3) アクセス制御情報の用途による使い分けの例

(1) アクセス権判定の流れ

ここでは,アクセス制御情報によって,どのようにオブジェクトに対するアクセス権が判定されるかについて説明します。

DocumentBrokerによるアクセス権の判定処理の流れについて,次の図に示します。

なお,メソッドをコールするユーザに関するユーザ情報は,ログインしたときにDocumentBrokerによって取得されています。このユーザ情報の詳細については,マニュアル「DocumentBroker Version 3 システム導入・運用ガイド」を参照してください。

図3-77 アクセス権の判定処理の流れ

[図データ]

  1. オブジェクトに対してメソッドがコールされます。
  2. アクセス制御機能が,ユーザがログインした時に取得されたユーザ情報を取得します。
    ユーザ情報には,ログインユーザに関する次の情報が設定されています。
    • ユーザ識別子
    • グループ識別子
    • 文書空間に対するユーザの特権(セキュリティ管理者であるかどうかの情報)
    • ユーザ権限
    メソッドをコールしたユーザがセキュリティ管理者である場合は,メソッドを実行します。セキュリティ管理者でない場合は,3.に進みます。
  3. ユーザがコールしたメソッドに必要なパーミッションの情報を取得します。
    各メソッドの実行に必要なパーミッションについては,マニュアル「DocumentBroker Version 3 クラスライブラリ C++ リファレンス 基本機能編」を参照してください。
  4. ユーザ権限定義ファイルに設定したパーミッション(ユーザ権限)を取得します。ユーザに設定されているパーミッションで,メソッドが実行できるか判定します。
    メソッドの実行が可能なパーミッションが設定されていた場合は,メソッドが実行されます。
    メソッドの実行が可能なパーミッションが設定されていなかった場合は,5.に進みます。
  5. ACFlagを取得します。メソッドをコールしたユーザがACFlagでパーミッションを与えられているユーザまたはグループかどうかを判定します。また,そのパーミッションでメソッドが実行できるかどうかを判定します。
    メソッドの実行が可能なパーミッションが設定されている場合,メソッドを実行します。
    ユーザにパーミッションが設定されていない場合,またはメソッドの実行が可能なパーミッションが設定されていない場合は,6.に進みます。
  6. オブジェクトにバインドされているパブリックACLを取得します。ユーザ情報に登録されているユーザが,パブリックACLでパーミッションを与えられているかを判定します。また,そのパーミッションでメソッドが実行できるか判定します。
    メソッドの実行が可能なパーミッションが設定されている場合は,メソッドを実行します。
    ユーザにパーミッションが設定されていない場合,またはメソッドの実行が可能なパーミッションが設定されていない場合は,7.に進みます。
  7. ローカルACLを取得します。ユーザ情報に登録されているユーザまたはグループが,ローカルACLでパーミッションを与えられているかを判定します。また,そのパーミッションでメソッドが実行できるかどうかを判定します。
    メソッドの実行が可能なパーミッションが設定されている場合は,メソッドを実行します。
    ユーザにパーミッションが設定されていない場合,またはメソッドの実行が可能なパーミッションが設定されていない場合は,DocumentBrokerはメソッドを実行せずに,エラー(ERR_DBR ERR_ACCESS_NOT_PERMITTED)を返却して,エラー終了します。

このように,例えば,ACFlagでユーザの操作に必要なパーミッションが設定されている場合は,DocumentBrokerはパブリックACLやローカルACLを参照しません。したがって,例えば,アクセスが多くなるユーザに対してはACFlagでパーミッションを与えるようにすることで,アクセス権判定の処理速度が向上します。

注意
メソッドをコールした時点で,アクセス権判定の前に,オブジェクトにはロックが設定されます。このロックは,アクセス権がないためにメソッドがアクセスエラーになった場合も解除されません。アクセスエラーが発生した場合は,ロールバックして,トランザクションを終了することで,ロックを解除してください。

(2) アクセス制御情報の特徴

それぞれのアクセス制御情報の特徴を,次の表に示します。

表3-19 それぞれのアクセス制御情報の特徴

アクセス制御情報の種類処理順序特徴
文書空間に対する特権1
  • アクセス制御情報のうち,最初に参照されます。この特権を持つユーザに対してはアクセス権判定処理が実行されません。
  • 文書空間内のセキュリティに関する保守を行うために登録されたセキュリティ管理者に与えられた権限です。
ユーザ権限2
  • アクセス権判定のとき,最初に参照される情報なので,最も早い段階でアクセス権が判定されます。
  • あるユーザに対して,文書空間内で同一の操作を許可する場合に使用すると便利です。
  • ユーザ権限を多数定義すると,起動処理および文書空間への接続処理に時間が掛かることがあります。
ACFlag3
  • 所有者,プライマリグループの情報と組み合わせて判定されます。
  • ユーザ権限の次に参照される情報なので,ローカルACLやパブリックACLに比べて早い時点で判定されます。
  • データベース上ではトップオブジェクトのプロパティと同じテーブルに存在するプロパティなので,処理が高速です。
  • 所有者,プライマリグループまたはすべてのユーザに対して許可する操作だけ設定できます。
パブリックACL4複数のオブジェクトに対して共通のアクセス制御情報が設定できます。
ローカルACL5そのオブジェクト固有のアクセス制御情報が設定できます。
注※
DocumentBrokerがアクセス権を判定する場合に,処理する順序です。

(3) アクセス制御情報の用途による使い分けの例

ユーザ権限,ACFlag,パブリックACLおよびローカルACLの使い分け方について例を使用して説明します。なお,セキュリティ管理者が持つ特権については,文書空間全体のアクセス制御情報を保守するユーザの権限ですので,ここでは説明しません。文書空間のセキュリティについて考慮した上で,別に設定してください。

ここでは,次の図のような組織でのアクセス制御機能を使用した文書管理について説明します。

図3-78 アクセス制御情報の使い分けの例で使用する組織の構成

[図データ]

以降,ユーザ権限,ACFlag,パブリックACLおよびローカルACLを設定する場合の考え方を,アクセス権判定の順に説明していきます。なお,セキュリティACLは,アクセス権判定の処理とは無関係に設定するアクセス制御情報です。

  1. ユーザ権限定義ファイルの指定によるユーザ権限の設定
    ユーザ権限定義ファイルでは,文書空間内で共通で利用するアクセス制御情報を設定できます。
    • オブジェクト作成権限の設定
      アクセス制御機能を使用している文書空間では,オブジェクトを作成できるユーザを設定する必要があります。この設定は,ユーザ権限定義ファイルで定義します。
      例えば,図3-78の組織の場合に,ユーザA,ユーザCにオブジェクト作成権限を設定します。これによって,ユーザAおよびユーザCは,文書空間に文書やコンテナが作成できるようになります。
    • オブジェクト操作権限の設定
      ユーザ権限定義ファイルには,特定のユーザおよびすべてのユーザに,文書空間内のすべてのオブジェクトに対して許可する操作が設定できます。例えば,すべてのユーザに対してすべての文書またはコンテナを参照する権利を与える場合など,このファイルで設定できます。
    ユーザ権限定義ファイルの具体的な定義方法については,マニュアル「DocumentBroker Version 3 システム導入・運用ガイド」を参照してください。
  2. ACFlagの設定
    アクセス制御機能に対応している文書空間でオブジェクトを作成すると,オブジェクトには「所有者」として,オブジェクトを作成したユーザが設定されます。また,オブジェクトには,プライマリグループが設定されている場合があります。プライマリグループは,連携しているユーザ管理システムによって,オブジェクト作成時に設定される場合と,ユーザが明示的に設定する場合があります。プライマリグループを設定する場合は,運用によって,オブジェクトを作成したユーザが所属するグループを設定したり,オブジェクトに対してアクセスが多いと考えられるユーザのグループを設定したりできます。
    図3-78の組織の場合,ユーザAがオブジェクトを作成すると,オブジェクトの所有者としてユーザAが設定されます。また,プライマリグループには,企画部を明示的に設定したとします。
    ACFlagでは,この所有者およびプライマリグループに対して,許可する操作が設定できます。
    例えば,ユーザAが作成した文書に対して,「所有者はすべての操作が可能で,プライマリグループは参照と編集,バージョンアップが可能」としたい場合,所有者に許可する操作として「すべての操作」を設定して,プライマリグループに対して許可する操作として「参照と更新およびバージョンアップ」と設定できます。
    ACFlagに設定したアクセス制御情報は,アクセス権判定時にパブリックACLやローカルACLよりも先に処理されます。このため,ACFlagによって所有者やプライマリグループに適切なアクセス権を設定しておけば,アクセス権判定処理が高速で実行されるため,オブジェクトへのアクセスを速くできます。
    また,ACFlagでは,すべてのユーザに対して許可する操作も設定できます。例えば,「この文書はすべてのユーザに対して参照を許可する」などの設定もできます。
  3. パブリックACLの設定
    パブリックACLには,複数の文書やコンテナに対して共通して設定したいアクセス制御情報を設定します。
    例えば,図3-78の組織で,「ユーザA,ユーザCが作成した文書を,グループ『企画部』およびグループ『設計部』内のすべてのユーザが参照,更新できるようにしたい」場合があるとします。このとき,この条件を設定したパブリックACLを作成します。「グループ『企画部』に対して参照,更新する許可を与える」というACEと「グループ『設計部』に対して参照,更新する許可を与える」というACEを作成し,これらを構成要素としたACLを,パブリックACLに設定します。ユーザAおよびユーザCが作成したすべての文書に対してこのパブリックACLをバインドさせれば,すべての文書に同じアクセス制御情報が設定できます。
    なお,パブリックACLは複数のオブジェクトで共有されますので,作成時に明確な運用方法を決めてからアクセス制御情報を設定してください。複数のオブジェクトからのバインドを設定したあとはできるだけアクセス制御情報を変更しない運用をお勧めします。
    例えば,「文書の作成時には『企画部』および『設計部』に参照,更新させたいが,一度公開したあとでは『営業部』内の特定のユーザ(ユーザD)だけにすべての操作をする権利を与え,ほかのユーザには更新させないようにしたい」というような場合は,公開後にパブリックACLの内容を変更するのではなく,作成時用のパブリックACLと,公開後用のパブリックACLを複数作成しておく運用が考えられます。ある文書を公開したら,その文書からバインドするパブリックACLを「作成時用」のものから「公開後用」のものにバインドし直すことで,アクセス制御情報は変更できます。パブリックACLの運用例を,次の図に示します。

    図3-79 パブリックACLの運用例

    [図データ]

  4. ローカルACLの設定
    ローカルACLには,個々のオブジェクト固有のアクセス制御情報を設定します。
    例えば,「ユーザAが作成した文書Xは,企画部,設計部のユーザ以外に,営業部のユーザDにも,参照,更新させたい」という場合,文書XにACFlag,パブリックACLの設定のほかに「ユーザDに参照,更新を許可する」というローカルACLを設定します。
  5. セキュリティACLの設定
    セキュリティACLには,オブジェクト(パブリックACLを含む)のアクセス制御情報を操作することを許可するユーザを設定します。これは,それぞれのオブジェクトごとに設定します。
    例えば,「ユーザAが作成した文書Xは,ユーザBの承認を得たあとで公開する。ユーザBが承認した段階で,バインドするパブリックACLを『作成時用』から『公開後用』に変更したい」という場合,文書XのセキュリティACLに,ユーザBを設定しておきます。これによって,ユーザBは承認後,文書XからバインドするパブリックACLを変更できます。
    ただし,文書の所有者は,常に所有するオブジェクトのすべてのアクセス制御情報変更権を持ちます。このため,「ユーザBの承認後,ユーザAからはアクセス制御情報変更権を無くしたい」という場合は,ユーザAまたはセキュリティ管理者によって,ほかのユーザ(例えばユーザB)に所有者を変更する必要があります。
    また,パブリックACLに設定されているアクセス制御情報は,バインドしているオブジェクトのセキュリティACLを持つユーザでは変更できません。つまり,図3-79の場合,文書Xに対してアクセス制御情報変更権を持つユーザAによって,文書XからバインドするパブリックACL「作成時用」に設定されている内容を変更することはできません。
    パブリックACLのアクセス制御情報は,それぞれのパブリックACLの所有者およびセキュリティACLに設定されたユーザによって変更できます。