2013年4月10日タグ:セキュリティ共有ルールはじめに今岡です。前回のブログでは、Force.comのオブジェクトアクセス(主にプロファイル)を取り上げましたが、データセキュリティを考えるうえで、レコードアクセスの検討も欠かすことができません。そこで今回は、レコードアクセスについて書いてみたいと思います。レコードアクセスをコントロールする機能プロファイルはユーザがオブジェクトに対して何を実行できるかを設定しますが、レコードセキュリティ(共有)ではユーザがどのレコードを参照できるかを設定します。レコードアクセスのコントロールは以下の機能で構成されます。組織の共有設定...最初に検討するポイントレコードアクセスの最初の検討は「組織の共有設定」になります。組織の共有設定では、各オブジェクトが保持するレコードに対して、ユーザのアクセスレベルのベースを設定します。組織の共有設定の検討ポイント社外ユーザのアクセスポータルライセンスを使用する場合、社内ユーザだけでなく社外ユーザもオブジェクトにアクセスを行います。そのため特にアクセスコントロールには注意を払う必要があります。共有ルールではアクセス権の追加のみ組織の共有設定で決定したアクセスレベルより厳しくするこはできません。組織の共有設定で「非公開」に設定されているオブジェクトに対して、「公開/参照のみ」を一部のロールに追加することはできません。主従関係のオブジェクトは注意する主従関係の場合、「主」の設定が「従」のオブジェクトに継承される点に注意が必要です。そのため主従関係の場合、積み上げ集計項目が使えるといったメリットのみに着目するのではなく、アクセスレベルのコントロールを意識して、データモデル検討時から意識することが重要になります。オブジェクト間のリレーションを検討する時、主従関係にするか参照関係にするかの判断は迷いやすいところです。ある間違いとして主従関係の場合、積み上げ集計項目が使えるといった点にのみに着目して主従関係とするケースです。以下のサンプルシナリオで考えてみます。【サンプルシナリオ】テラスカイ商事では、ポータルライセンスを使用して、販売代理店からの注文をポータルから受け付ける仕組みを検討しています。1.テラスカイ商事が扱う商品は、販売代理店を含むすべてのユーザが参照できます。2.商品のメンテナンスは、テラスカイ商事のみが行います。3.商品を参照した際に、商品の注文件数に応じたアイコンを表示したいと考えています。4.注文情報は、販売代理店間では参照することはできません。このシナリオから、商品マスタと注文トランの2つで管理するとします。シナリオの1.より商品マスタは組織の共有設定で「公開/参照のみ」とします。次に注文トランですが、3.の「商品の注文件数」を積み上げ集計項目を使うとした場合、商品マスタと主従関係にする必要が生じますが、その結果商品マスタの「公開/参照のみ」が注文トランに継承され、注文トランが販売代理店間で参照できる状態となってしまいます。そのため、注文トランは商品マスタへの参照を「参照関係」とし、注文トランの組織の共有設定は「非公開」とします。3.の「商品の注文件数」の要件はApexトリガーによる実装とするのが良いでしょう。レコードアクセスの重要な側面レコードアクセスを検討する上で、ロール階層の定義は重要な側面を担います。ロール階層の上位ロールに属すユーザは、下位ロールに属すユーザが所有するレコードをデフォルトで参照可能です。(参照できないように設定することも可能です。)ロール階層の設計上の重要な検討事項ロール階層は必ずしも会社組織の組織図とする必要はない会社組織の組織図は一般的に複雑であり、また組織変更等も起こりえます。そのため、データアクセスの要件を分析し、会社組織の組織図ではなく、上位ロールは下位ロールのレコードにアクセスできることをベースにできるだけ階層を複雑にせず簡素化した方が良いでしょう。ユーザは一つのロールにしか属すことはできませんが、日本企業の場合、組織上のあるポジションを「兼務」している場合があり、ロール階層を会社組織の組織図とした場合、ユーザにロールを設定することすら困難になるケースがあります。テリトリー階層も知っておくロール階層とは別にテリトリー階層という階層を作りレコードアクセスをコントロールすることもできます。(SFDC社にリクエストして有効化します。)、あるいは手動により取引先が属すテリトリーを複数割り当てることができます。ユーザに対しても、テリトリー階層を複数割り当てることが可能です。テリトリー階層を使用する場合、取引先と参照関係を持つ標準オブジェクトや、主従関係を持つカスタムオブジェクトにセキュリティ設定が適用される点には注意をはらいましょう。ポータルにもロール階層がある社外ユーザが使用するポータルライセンスにもロール階層があります(ロール階層を定義できないポータルライセンスもある点には注意が必要です)。取引先責任者のポータルユーザを作成した場合、その取引先責任者が属す取引先のロール階層が自動的に作成されます。この取引先ロールの上位ロールは、取引先の所有者となっているユーザが属すロールとなることを知っておきましょう。ポータルを有効化しポータルユーザを作成すると、「ロール、ロール&内部下位ロール」、「ロール、内部&ポータル下位ロール」といったレコードの共有を設定する上での特別なルールが追加されます。社内ユーザのみに限定したデータ参照を行う上で重要なルールとなります。レコードアクセスの重要な設定レコードアクセスを検討する上で、最も重要な設定になります。ユーザを公開グループ、ロール、キューなどでまとめ、オブジェクトごとに、レコードを共有する許可を設定します。キューレコードの共有は、オブジェクトに持つ所有者をベースとするか、あるいは特定の条件に応じて設定することができます。レコードを共有する際のレコードに対するアクセスレベル(参照のみ/参照・更新)を合わせて設定します。手動による共有レコードを共有するための共有ルールですが、個々のレコードに対して詳細に共有先を指定したいケースもあります。このような場合は、手動による共有設定で個別のレコードに対して共有するユーザなどの指定を行います。共有の指定はユーザに負荷をかけないよう通常は自動設定が望まれます。手動共有により、より詳細な設定を行うことは可能になりますが、それを運用で実施するとした場合にはユーザへの運用負荷がかかる点には注意しましょう。ユーザによる設定となるため、誤った共有先を指定してしまう危険性がある点や、あるレコードを誰がアクセス可能な状態にあるかを把握し難くなる点には注意した方が良いでしょう。Apexによる共有Apex共有では、Apexコードを使用してレコードの共有ロジックを開発します。標準カスタマイズによる共有ルールの指定と比較して、より詳細かつ柔軟な共有を定義することが可能である一方、ユーザの組織変更やビジネスプロセスの変更等により共有のルールが変わった場合、開発者によるApexコードの修正が必要となり、その改修やテストを考えた場合にはデメリットとなるでしょう。共有ルールの注意事項アクセスを制限することはできない共有ルールの考え方は、組織の共有設定で設定されたアクセス権に対して、アクセス制限を緩和することにあります。そのため、組織の共有設定でアクセス可能な状態にある時、レコードに対してアクセスを制限する設定はできないことに注意しましょう。共有ルールはパフォーマンスに影響を与える特に大容量データを扱う場合、ロール階層や公開グループの複雑さ、共有ルールの複雑さ、共有ルールの数はパフォーマンスに影響を与えます。そのため大容量データを扱う場合には、パフォーマンスも考慮した共有ルールの検討が重要になります。(基本的な考え方として、ロールや共有ルールはシンプルな状態を目指すのが良いと思います。よる違い、注意事項を説明しました。まとめると、以下の点が検討ポイントとなるでしょう。検索クラウドやるならテラスカイ。求む!Salesforce開発エンジニア。