Salesforce／Force.comのデータセキュリティ（レコードアクセス） - TECH BLOG

はじめに

今岡です。前回のブログでは、Force.comのオブジェクトアクセス（主にプロファイル）を取り上げましたが、データセキュリティを考えるうえで、レコードアクセスの検討も欠かすことができません。そこで今回は、レコードアクセスについて書いてみたいと思います。

レコードアクセスをコントロールする機能

プロファイルはユーザがオブジェクトに対して何を実行できるかを設定しますが、レコードセキュリティ（共有）ではユーザがどのレコードを参照できるかを設定します。レコードアクセスのコントロールは以下の機能で構成されます。

レコードアクセスの機能

- 組織の共有設定

- ロール階層

- テリトリー階層

- 共有ルール

- ロール階層や公開グループによる共有

- 条件ベースによる共有

- 取引先チーム（商談チーム、ケースチーム）

- 共有の直接指定

- Apex共有

組織の共有設定...最初に検討するポイント

レコードアクセスの最初の検討は「組織の共有設定」になります。組織の共有設定では、各オブジェクトが保持するレコードに対して、ユーザのアクセスレベルのベースを設定します。

組織の共有設定

● 非公開 ... あるオブジェクトに対してアクセスするユーザの中で、参照して良いレコード、参照させることの出来ないレコードが混在する場合に選択

● 公開／参照のみ ... あるオブジェクトに対してアクセスするユーザは全てのレコードを参照できるが、一部のユーザには更新は許可しない場合に選択

● 公開／参照・更新可能 ... あるオブジェクトに対してアクセスするユーザは全てのレコードを参照・更新できるに選択

組織の共有設定の検討ポイント

社外ユーザのアクセス

ポータルライセンスを使用する場合、社内ユーザだけでなく社外ユーザもオブジェクトにアクセスを行います。そのため特にアクセスコントロールには注意を払う必要があります。

共有ルールではアクセス権の追加のみ

組織の共有設定で決定したアクセスレベルより厳しくするこはできません。例えば、組織の共有設定で「非公開」に設定されているオブジェクトに対して、「公開／参照のみ」を一部のロールに追加することはできません。

主従関係のオブジェクトは注意する

主従関係の場合、「主」の設定が「従」のオブジェクトに継承される点に注意が必要です。そのため主従関係の場合、積み上げ集計項目が使えるといったメリットのみに着目するのではなく、アクセスレベルのコントロールを意識して、データモデル検討時から意識することが重要になります。

オブジェクト間のリレーションを検討する時、主従関係にするか参照関係にするかの判断は迷いやすいところです。よくある間違いとして主従関係の場合、積み上げ集計項目が使えるといった点にのみに着目して主従関係とするケースです。以下のサンプルシナリオで考えてみます。
【サンプルシナリオ】
テラスカイ商事では、ポータルライセンスを使用して、販売代理店からの注文をポータルから受け付ける仕組みを検討しています。
1.テラスカイ商事が扱う商品は、販売代理店を含むすべてのユーザが参照できます。
2.商品のメンテナンスは、テラスカイ商事のみが行います。
3.商品を参照した際に、商品の注文件数に応じたアイコンを表示したいと考えています。
4.注文情報は、販売代理店間では参照することはできません。
このシナリオから、商品マスタと注文トランの2つで管理するとします。
シナリオの1.より商品マスタは組織の共有設定で「公開／参照のみ」とします。
次に注文トランですが、3.の「商品の注文件数」を積み上げ集計項目を使うとした場合、商品マスタと主従関係にする必要が生じますが、その結果商品マスタの「公開／参照のみ」が注文トランに継承され、注文トランが販売代理店間で参照できる状態となってしまいます。そのため、注文トランは商品マスタへの参照を「参照関係」とし、注文トランの組織の共有設定は「非公開」とします。そして、3.の「商品の注文件数」の要件は
Apexトリガーによる実装とするのが良いでしょう。

ロール階層 ... レコードアクセスの重要な側面

レコードアクセスを検討する上で、ロール階層の定義は重要な側面を担います。ロール階層の上位ロールに属すユーザは、下位ロールに属すユーザが所有するレコードをデフォルトで参照可能です。（参照できないように設定することも可能です。）

ロール階層の設計上の重要な検討事項

ロール階層は必ずしも会社組織の組織図とする必要はない

会社組織の組織図は一般的に複雑であり、また組織変更等も起こりえます。そのため、データアクセスの要件を分析し、会社組織の組織図ではなく、上位ロールは下位ロールのレコードにアクセスできることをベースにできるだけ階層を複雑にせず簡素化した方が良いでしょう。ユーザは一つのロールにしか属すことはできませんが、日本企業の場合、組織上のあるポジションを「兼務」している場合があり、ロール階層を会社組織の組織図とした場合、ユーザにロールを設定することすら困難になるケースがあります。

テリトリー階層も知っておく

ロール階層とは別にテリトリー階層という階層を作りレコードアクセスをコントロールすることもできます。（SFDC社にリクエストして有効化します。）テリトリー階層は取引先を分類するロール階層のようなもので、取引先に対する条件（地域、国、業種、従業員数など）、あるいは手動により取引先が属すテリトリーを複数割り当てることができます。そしてユーザに対しても、テリトリー階層を複数割り当てることが可能です。テリトリー階層を使用する場合、取引先と参照関係を持つ標準オブジェクトや、主従関係を持つカスタムオブジェクトにセキュリティ設定が適用される点には注意をはらいましょう。

ポータルにもロール階層がある

社外ユーザが使用するポータルライセンスにもロール階層があります（ロール階層を定義できないポータルライセンスもある点には注意が必要です）。取引先責任者のポータルユーザを作成した場合、その取引先責任者が属す取引先のロール階層が自動的に作成されます。この取引先ロールの上位ロールは、取引先の所有者となっているユーザが属すロールとなることを知っておきましょう。さらに、ポータルを有効化しポータルユーザを作成すると、「ロール、ロール&内部下位ロール」、「ロール、内部&ポータル下位ロール」といったレコードの共有を設定する上での特別なルールが追加されます。社内ユーザのみに限定したデータ参照を行う上で重要なルールとなります。

共有ルール ... レコードアクセスの重要な設定

レコードアクセスを検討する上で、最も重要な設定になります。ユーザを公開グループ、ロール、キューなどでまとめ、オブジェクトごとに、レコードを共有する許可を設定します。

ユーザを共有のためにまとめる機能

- 公開グループ

- ロール

- テリトリー

- キュー

レコードの共有は、オブジェクトに持つ所有者をベースとするか、あるいは特定の条件に応じて設定することができます。そして、レコードを共有する際のレコードに対するアクセスレベル（参照のみ／参照・更新）を合わせて設定します。

レコードを共有するための設定手段

- レコードの所有者をベースに共有

- レコードが保持する項目の特定条件に応じた共有

手動による共有

レコードを共有するための共有ルールですが、個々のレコードに対して詳細に共有先を指定したいケースもあります。このような場合は、手動による共有設定で個別のレコードに対して共有するユーザなどの指定を行います。

共有の指定はユーザに負荷をかけないよう通常は自動設定が望まれます。手動共有により、より詳細な設定を行うことは可能になりますが、それを運用で実施するとした場合にはユーザへの運用負荷がかかる点には注意しましょう。また、ユーザによる設定となるため、誤った共有先を指定してしまう危険性がある点や、あるレコードを誰がアクセス可能な状態にあるかを把握し難くなる点には注意した方が良いでしょう。

Apexによる共有

Apex共有では、Apexコードを使用してレコードの共有ロジックを開発します。標準カスタマイズによる共有ルールの指定と比較して、より詳細かつ柔軟な共有を定義することが可能である一方、ユーザの組織変更やビジネスプロセスの変更等により共有のルールが変わった場合、開発者によるApexコードの修正が必要となり、その改修やテストを考えた場合にはデメリットとなるでしょう。

共有ルールの注意事項

アクセスを制限することはできない

共有ルールの考え方は、組織の共有設定で設定されたアクセス権に対して、アクセス制限を緩和することにあります。そのため、組織の共有設定でアクセス可能な状態にある時、レコードに対してアクセスを制限する設定はできないことに注意しましょう。

共有ルールはパフォーマンスに影響を与える

特に大容量データを扱う場合、ロール階層や公開グループの複雑さ、共有ルールの複雑さ、共有ルールの数はパフォーマンスに影響を与えます。そのため大容量データを扱う場合には、パフォーマンスも考慮した共有ルールの検討が重要になります。（基本的な考え方として、ロールや共有ルールはシンプルな状態を目指すのが良いと思います。）