logo

サイト内検索
ココログ最強検索 by 暴想

最近のトラックバック

無料ブログはココログ

« 2011年8月 | トップページ | 2012年11月 »

2011年9月

force.com salesforceでのセキュリティー 共有設定のテストについて

前提

ロール階層を使用したレコードレベルセキュリティーをテストします。


組織のデフォルトで顧客カスタムオブジェクトを非公開

Default

これで、システム管理者以外のユーザは自身の所有する顧客レコード以外にアクセスできなくなる。


ロール階層(AdminRoleの配下にNormalRoleがある)

Role_3

これで、AdminRoleを付与されたユーザはNormalRoleを付与されたユーザの所有するレコードにアクセスできるように制限が緩和される。


ユーザ

User

securityneko@gmail.com(システム管理者)とsecuritynekoodu@gmail.comユーザーが存在する。


顧客レコード

Kokyarrecord


テストコード

@isTest
private class SecurityTest {

  public static testMethod void testRunAs() {
     // 通常全てのApexコードはシステムモードで実行される
     System.debug('Current User: ' + UserInfo.getUserName());
     List cs = [select id from customer__c];
     System.assertEquals(2,cs.size());

     // 1つ目と同じだが、明示的にシステム管理者ユーザを指定して実行みる
     User admin = [select id from User where username = 'securityneko@gmail.com'];
     System.runAs(admin) {
       System.debug('Current User: ' + UserInfo.getUserName());
       List cs1 = [select id from customer__c];
       System.assertEquals(2,cs1.size());
     }

     // ここはNormalRoleのsecuritynekoodu@gmail.comユーザで実行される
     User odu = [select id from User where username = 'securitynekoodu@gmail.com'];
     System.runAs(odu) {
       System.debug('Current User: ' + UserInfo.getUserName());
       List cs2 = [select id from customer__c];
       System.assertEquals(1,cs2.size());
     }

     //ロールを入れ替えてみる
     UserRole roleA = [select id from UserRole where name = 'AdminRole'];
     odu.UserRoleId = roleA.id;
     update odu;
     UserRole roleN = [select id from UserRole where name = 'NormalRole'];
     admin.UserRoleId = roleN.id;
     update admin;

     // さっきは1件のみ取得だったが、今回は2件取得できる
     System.runAs(odu) {
       System.debug('Current User: ' + UserInfo.getUserName());
       List cs2 = [select id from customer__c];
       System.assertEquals(2,cs2.size());
     }
   }
}


Apexコードは通常システムモードで起動しますが、runAs()の中では引数のユーザモードで実行されます。よって上述のように、「securitynekoodu@gmail.com」ユーザで実行した場合は取得できる顧客レコードは1件になります。



ロールを入れ替えることにより「securitynekoodu@gmail.com」ユーザーにAdminRoleが付与され、「securityneko@gmail.com」ユーザーがNormalRoleとなると「securitynekoodu@gmail.com」ユーザーでも取得できる顧客レコードは2件となるのが分かると思います。



レコードの共有ルールのテストはこのようにして作成できるのですが、
オブジェクトレベルや項目レベルセキュリティーのチェックはできません。

salesforce force.comでのセキュリティー設定基本

前提
1.用語の躓きとして、salesforceでのオブジェクトとはRDBのテーブルのことです。
  こんな前提もきちんと頭に入れておかないとマニュアル読んでいるうちに
  わからなくなってきます。
  オブジェクトってORマッパでは行を表したりしますから余計混乱しますが、
  RDBに慣れている人にとって、
  「オブジェクト」は「テーブル」と読み替えるのは大前提です。
  本記事では行のことは「レコード」と表現しています。

2.セキュリティー設定に関係なく、自分が保有するレコードはすべてCRUD可能である。
  それ以外の部分を設定するという方向でレコードレベルのセキュリティーは考える。

3.ロールとプロファイルがどういう関係になってるかを考えるときに
  どういう分け方が一番わかり易いかと考えたのですが、
  プロファイルで設定するものとプロファイルで設定しないものという分け方でまとめてみます。


プロファイルで設定するもの
1.オブジェクトレベルのセキュリティー
   どのオブジェクトへのCRUDを許可するか?

2.項目レベルセキュリティー
   どのカラムへのCRUDを許可するか?


プロファイルで設定しないもの
1.レコードレベルのセキュリティー
  (プロファイルで設定せずに何によって設定するのかが以下の4つになります)

  ①組織全体のデフォルト(セキュリティーのコントロール >> 共有設定 >> 組織の共有設定)
    ・ここで対象オブジェクトごとの基底レコードセキュリティーを設定する。
    ・他のレコードレベルセキュリティー(以下の3種)を実装することで、
     セキュリティーレベルを緩めることはできるが、上げることはできない。

  ②ロール階層(ユーザの管理 >> ロール)
    ・プロファイルとロールが混乱するのですが、
     ロールというのはレコードレベルセキュリティー設定方法のうちの一つである
     と考えれば少しは整理されるかも。
    ・ロールはユーザに付与するが、全ユーザに必ず付与しなくてならないものではない。
    ・一方、プロファイルはユーザ作成時に必ず設定しなければならない。
    ・ロールは階層構造になっており、上位ロールを付与されたユーザは、
     自ロール以下に位置ずけられたロールに参加しているユーザの所有レコードと
     共有レコードにアクセスできるようになる。
  
  ③共有ルール(セキュリティーのコントロール >> 共有設定 >> 共有ルール)
    ・特定のユーザ、ロール、公開グループに対して、例外を許可できます。
    
  ④共有の直接設定
    ・レコード所有者が画面上から共有ボタンを押して誰と共有するかを選択する。


プロファイル設定画面内にあるオブジェクト権限の
「すべて変更」「すべて表示」チェックボックスについて

1.上で書いたようにプロファイルではレコードレベルのセキュリティーを制御しないのですが、
  ここは例外で、この2つをチェックすると、
  チェックされたオブジェクトの全レコードにアクセスできます。
  セキュリティーの概要を掴もうと実際試してみたとき、
  システム管理者プロファイルユーザではこの2つのチェックが付いてまして
  レコードレベルのセキュリティーの確認がうまくいかずにハマりました。

2.オブジェクトの共有設定に関係なく、このプロファイルを持つユーザに、
  選択したオブジェクト種別の全レコードのフルアクセス権限を付与したい場合、
  「すべて変更」にチェック。

3.オブジェクトの共有設定に関係なく、このプロファイルを持つユーザに、
  選択したオブジェクト種別の全レコードの参照アクセス権限を付与したい場合、
  「すべて表示」にチェック。


余談
デフォルトロールはCEOを頂点にツリー階層で始めから存在しますが、
邪魔な時は以下のSOQLで全消しできます。

userrole[] roles = [select id from userrole];
delete roles;

« 2011年8月 | トップページ | 2012年11月 »