SugarCRM^(R)のセキュリティポリシーとその制御コンポーネントの概要

概要

SugarCRM^(R)内には、レコードにアクセス制御を加えるための制御コンポーネントが3種類用意されています。本文書では、この3種類のコンポーネントとそれらの相互作用について概略を解説します。

制御コンポーネント

Sugar Suite^(R)内のレコードにアクセス制御を加える制御コンポーネントは、以下の３つです。

• タブへのアクセス制御
• 行レベルのアクセス制御（Sugar Professional^(R)及びSugar Enterprise^(R)のみ）
• 役割レベルのアクセス制御リスト（ACLs）

タブレベルのアクセス制御は、Sugar Suite^(R)のあらゆるバージョンで利用できます。タブレベルのアクセス制御とは、個々のユーザがアクセスできるタブを制限するものです。ユーザがあるタブへのアクセス権限を持たない場合、ユーザは、そのタブに付随するあらゆるサブパネル、ショートカット、データを含め、そのタブを利用することができません。

行レベルのアクセス制御は、Sugar Professional^(R)とSugar Enterprise^(R)で利用できるコンポーネントです。行レベルのアクセス制御を適用すると、レコードは、1人あるいは、複数のユーザで構成されたチームによって所有されます。現在のバージョンでは、システム管理者のみがチームを作成することができます。行レベルのアクセス制御により、ユーザが閲覧できるレコードを制御することできます。

役割ベースのアクセス制御では、主に次の3つを設定します。

• タブへのアクセスを制限します。
• Sugar Professional^(R)とSugar Enterprise^(R)において、モジュール内の全ての行へのアクセス権限を与えます。（これは行レベルのセキュリティよりも優先されます。）
• データへのアクセスを制限したり、閲覧可能なレコードについてユーザが特定のアクションを実行する機能を制限します。

以下では、サポート部門のシンプルな利用事例を用い、タブレベル、行レベル、そして役割レベルのそれぞれのセキュリティレベルにおいて、各種制限を適切に設定する方法を説明します。
以下の例では、サポート部門に3段階のユーザが存在しています。それぞれ、システム内のアクティブなケースや組織内の活動の閲覧について完全に制御する権限を持つ管理者と、ケースや幾つかの活動の閲覧について標準的なアクセス権限を持つサポート担当者、そして、まだ研修中で、より厳しい制限が設定されているサポート担当者です。

タブレベルのアクセス制御

タブレベルのアクセス制御はSugarCRM^(R)で最も昔から利用されているセキュリティシステムの1つです。これにより、ユーザにセキュリティシステムの存在を意識させることなく、管理者はアクセスを制御することができます。システム全体のタブレベルのアクセス制御は管理パネルで設定することができます。個々のユーザにおけるタブレベルのアクセス制御は、ユーザの設定画面で設定されます。

ユーザはどのタブをどの順番で表示させるかを設定できます。また、管理者はユーザのタブへのアクセスを禁止することができます。現在のSugarCRM^(R)では、ユーザのタブへのアクセスを禁止する場合は、役割レベルのアクセス制御を適用することをお勧めします。タブレベルのアクセス制御は、主に、タブへのアクセス権限はあるもののアプリケーションを毎日使う中では非表示にしておきたいときや、ユーザーインターフェース上のタブの順番を変更できるようにしておきたいときに適用します。

ユーザ自身あるいは管理者によってタブが非表示に設定されている場合、そのタブはユーザーインターフェース上から削除されます。画面の最下部のタブへのリンクも削除され、また当該タブのモジュールに付随するあらゆるサブパネルも自動的に削除されます。そのため、そのモジュールにアクセスすることができなくなります。

このサポート部門の例では、タブレベルのアクセス制御は、サポート部門のユーザが日々の活動の重要度順に応じて、ユーザーインターフェース上でタブを並び替えるために利用できます。ユーザは、ホーム、ケース、電子メール、取引先、取引先担当者などのタブの中で好きなものをリストの先頭に設定することができます。

行レベルのセキュリティ（Sugar Professional^(R)及びSugar Enterprise^(R)のみ）

行レベルのアクセス制御はSugar Professional^(R)とSugar Enterprise^(R)のみで有効で、どのユーザがどのレコードに対するアクセス権を持つかを制御します。

個々のレコードはチームが所有しますが、管理者ユーザの役割、あるいは役割レベルのアクセス制御によって管理権限が与えられていない場合、ユーザは、レコードを所有するチームのメンバーである場合にのみ当該レコードを閲覧することができます。

レコードを所有するチームのメンバーになる方法は2つあります。最も直接的な方法は、手動でチームに追加するものです。手動でユーザをチームに加えるとすぐにそのチームが所有している全てのレコードにアクセスできるようになります（それでも他のセキュリティメカニズムは機能している状態です）。さらに、チームが所有している全てのレコードにアクセスできることに加え、チームに所属している全員がそのレコードにアクセスすることもできるようになります。

サポート部門の例では、チームにサポートの担当者を加えると、直ぐにそのチーム（またはその担当者の管理者）に管理者が加えられます。

SugarCRMでは必要なだけチームを作ることができます。チームを作成して、ユーザをアサインすることも容易に行えます。また、システムにはGlobalと呼ばれる特別のチームが存在します。Globalチーム内では基本的に全てのレコードが組織全体に公開されます。例えば、ドキュメントのテンプレートは組織全体で共有したいものの一つですが、Globalチームでドキュメントを所有すると、ドキュメントを閲覧できるユーザは、すべてそのドキュメントへのアクセス権を所有することになります。

役割レベルのアクセス制御リスト（ACLs）

役割レベルのアクセス制御では、ユーザが実行するアクションと、アクセス権を持つモジュールやレコードを制御することができます。

役割には、主に以下のような特徴があります。

• 一部のモジュールへのアクセスを禁止します。
• 一部のモジュール内のレコードをすべて閲覧できるようにします。（Sugar Professional^(R)及びSugar Enterprise^(R)のみ）
• サブセットモジュール内で閲覧できるレコードに関してユーザが行えるアクションを制限したり、削除したりします。
• アサインされている各ユーザに作用します。ユーザはアサインされている役割にのみ作用されます。各ユーザは、ゼロか一かあるいは複数の役割がアサインされる可能性があります。各役割へは、ゼロか一かあるいは複数のユーザがアサインされる可能性があります。

SugarCRM^(R)をインストールした時点では、各ユーザは全てのモジュールにアクセスすることができます。役割を利用して、モジュールへのアクセスやモジュール内の特定のアクション、アクセスできるレコードを制限することができます。組織内の技術者が、商談モジュールにアクセスして欲しくない場合は、商談モジュールへのアクセスを禁止する役割を作成することができます。この役割を技術者にアサインすると、技術者は商談モジュールにアクセスできなくなります。新任の営業担当者に対しては、商談、取引先、取引先担当者を削除できないようにしたり、システム内からどんなデータもエクスポートできないようにしたりする役割を設定することが考えられます。

役割の設定・変更・取り消しなど、役割について行った変更は、ユーザが次回ログインした時点から有効となります。モジュールへのアクセスを禁止した場合、他のモジュールページで表示される関連サブパネルもまた削除されて、アクセスできなくなります。Sugar Professional^(R)及びSugar Enterprise^(R)では、行レベルのアクセス制御も有効です。

役割を作成する際には、アサインされたユーザがアクセスできるモジュールやエンドユーザ、管理者などのユーザタイプ、ユーザが行えるアクションを指定することができます。

権限は以下の通りです。

アクセスタイプの選択肢は以下の通りです。

ユーザタイプの選択肢は以下の通りです。

アクションの選択肢は以下の通りです。

同じアクションやアクセスレベルを持つ複数の役割をユーザにアサインした場合、最も制限の強い設定が有効とされます。例えば、ユーザが、あるモジュールに対する異なるアクセス設定を持つ役割にアサインされているとします。一つの役割では管理者としてのアクセス権限が与えられ、もう一つの役割ではエンドユーザとしての権限が与えられている場合、制限値の大きい方の役割が優先されます。（この場合は、制限のより強いエンドユーザとしてのアクセス設定の方が優先されます。）

このような矛盾を避けるため、Sugar Suite^(R)では、役割のデフォルト値を設定できます。デフォルト値を設定することより、ある役割が特定の設定に影響しないようにします。これにより単純な役割を作成でき、それらを組み合わせることにより理想的なセキュリティレベルを設定することが可能となります。

以下の例では、サポート部門の基本的な役割、サポート部門の管理者の役割、そしてサポート部門の研修者の役割を挙げています。管理者と研修者の役割は、基本の役割を変更する追加の役割となります。

役割：サポート部門の基本

• ケース、バグトラッカー、取引先、商談へのアクセスを許可。その他全てのモジュールへのアクセスを禁止。
• ユーザタイプの変更なし。（デフォルトの設定のまま）

役割：サポート管理者

• 全てのモジュールへのアクセスを許可。
• ユーザのタイプを管理者に変更。

役割：サポート研修者

• 閲覧可能な全てのモジュールについて、削除のアクションを「なし」に設定。
• 閲覧可能な全てのモジュールについて、エクスポートのアクションを「なし」に設定。
• 閲覧可能な全てのモジュールについて、編集のアクションを「オーナー」に設定。

サポートの技術者には次の役割を設定します。

• サポート部門の基本

サポートの管理者には次の役割を設定します。

• サポート部門の基本
• サポート管理者

サポートの研修者には次の役割を設定します。

• サポート部門の基本
• サポート研修者

このような役割の組み合わせにより、カスタマーサポート部門の担当者のアクセス権限をケース、バグトラッカー、取引先、商談モジュールに制限します。一方、管理者は、アサインされたチームに関わらず全てのケースのレコードを閲覧することができます。研修者は、サポート技術者と同じレベルで閲覧を行うことができますが、レコードを編集できるのみで、削除できるのは管理者か技術者となり、システムからレコードをエクスポートすることはできません。

●●