Salesforce Secruity Model Best Practice

7/31/2019 Salesforce Secruity Model Best Practice

1/16

opyright2011ClearTask,Inc. 1

Salesforce.com Security Model

Implementation Best Practices

and Considerations

May 22, 2011


2/16


Executive Summary

While the focus of many Salesforce implementations both the initial set-up

and ongoing evolution is on delivering the features needed to support a

companys business processes, varying degrees of attention are given to

ensuring that the solution is delivered in a manner where users have access to

a level of data and features appropriate to their job function.

It has been Clear Tasks experience that a thorough consideration of an

implementations security approach generally comes second to feature

function considerations, and that companies tend to under-estimate this

implementation aspect until one or more of the following occur:

1. Security Breach:

An unintended security breach where users (regular Salesforce users,

customer portal users, or partner portal users) access data not intended

for them

2. Company Growth:

The company grows to a size much larger than the original

implementation model took account for, and now a tiered security model

is needed to lock down certain data and features to users

3. Business Process Growth:

The company implements additional business processes than the

original implementation model made account for

4. Salesforce Maintenance Burden:

When the number of profiles, sharing rules, page layouts, and

management of an expanding role hierarchy starts to become an

administrative burden it may be a sign that the security model is ready

for a review and over-haul.

This document presents a set of best practices and implementation considerations to help

ensure that your implementation initial and ongoing maintenance will deliver the intended

value to your business users, while also protecting the data assets and integrity of the

system.


3/16


Security FrameworkWhile there is an array of Salesforce security configuration choices, many which are covered

in this document, Clear Task likes to use the following framework to conceptualize the two

main configuration categories that influence the extent to which a company can achieve asecure system meeting the functional needs of its users that also provides the appropriate

level of data security.

What people see What people can doWhat people get to

accomplish their jobs

Default security (OWD) Create/ read/ edit/ delete Appropriate data access

Role Hierarchy Key Profile Options: Appropriate feature access

Sharing rules Export Reports Analysis to manage

Object configuration API Access Limited to no admin rights

Apps & Tabs Lead Conversion

Folder & list view access Manage public reports/

folders/ documents etc.

Reports & dashboards Install AppExchange apps

The document addresses the most important items covered in the framework along with best

practices and considerations.


4/16


Where To Get Started?With such a large number of available configuration options many companies

are not clear on where to start. Clear Task comes across many of the following

type of questions and concerns. Should a private or a public sharing model be adopted?

How many system administrators should there be?

What is the right profile strategy?

Should the role hierarchy match the organization chart?

What is needed if partner or customer portal is being used?

How is delegated administration used?

How is the data protected if there are integrations to external systems?

Clear Tasks position is that the answers to these questions are found through a

business discovery exercise that reveals:

The business objectives of the Salesforce implementation

The business processes being supported

The organizational relationship between the various user and groups

While the scope of this document is beyond providing a complete business

discovery questionnaire the following questions provide directional information

on at least high-level security settings:

What are the primary business objectives for implementing Salesforce?

What Salesforce clouds are being implemented Sales, Service,

Custom, Jigsaw, Heroku, etc?

If Sales Cloud:

o What is the size of the sales team?

o Is it spread across geographies or some other meaningful

distinction?

o How is sales performance measured?

o Do all people within the sales organization get to see all data

(account, contacts, and opportunities) or are there divisions?

o Are there any 3rd party companies involved in activities such as

cold calling or lead qualification?

If Service Cloud:

o How the service organization structured?

If both Sales and Service Cloud:


5/16


o Can all team members see all data from each others groups?

Is the Salesforce Customer or Partner Portal being implemented?

What 3rd party integrations, if any, is part of the implementation?

What Salesforce edition is being deployed?

Build The Right Foundation

As stated previously the primary focus and time expended on an implementation is the

creation of user feature/ functions. Creating objects, fields, page layouts, reports,

dashboards, and potentially migrating data from another system. It is time consuming work

because of its nature.

Creating a sound security foundation by contrast (at least for easy to moderate complexity

environments) is relatively time efficient. There are a small number of key security settings

needed to ensure secure insight for your users.

Organization Wide Defaults (OWD):

Explanation:

OWD sets the default sharing model for each object. It is the baseline visibility model

before any exceptions are added. Options range from:

o Public Read/ Write

o Public Read Only

o Private

o Controlled By Parent (for child objects in a master-detail relationship) where

the child inherits the setting of its parent

The Salesforce factory setting is Public Read/ Write, which is the most open model

meaning all users potentially (assuming their profile allows it) have full access to all

records

Many companies incorrectly do not consider to change from the factory setting to a

setting more appropriate for their implementation

Clear Task Recommendations & Best Practices:

The OWD decision is largely driven by the intent of the implementation and the size

of the company. For example:


6/16


o A small company (


7/16



Clear Task has seen a trend where the role hierarchy is under-utilized by small and

medium sized companies, either because the companies do not understand the full

power of the hierarchy or these companies have a more open data model so theargument for using the role hierarchy to secure data is not as strong

Larger companies tend to be more enlightened about how to structure the role

hierarchy, but also many large companies struggle with the construct usually because

of the size the hierarchy can grow to, which is only compounded by periodic territory

realignment.

Clear Task recommends:

o Building out the role hierarchy from the start, regardless of organization size or

prevailing OWD. Organizations changes, OWD evolve and generally become

less open as more users are added to the system. And lastly there arereporting advantages to having users assigned to a role, namely being able to

report by role, and have users select my teamss opportunities,

o Balancing between granularity and system manageability. Do not create a role

for each title or person. Do not blindly mimic the organization chart.

Under-utilized Features

While the standard understanding of the role hierarchy is that users above me can

see my records and users at my level cannot see my records, there is addedgranularity available to handle access/ view/ edit rights on opportunities and cases as

the following screenshots demonstrate. Many companies forget this added granular

access available from the edit link next to the given roles name.


8/16


Sharing Rules:

Explanation:

Sharing rules provide a powerful way to create exceptions to OWD. These exceptions

can be targeted at a single point in the role hierarchy or broadly to an entire branch ofthe hierarchy. Sharing rules also provide the flexibility to determine the nature of the

sharing exception read only or read/ write.

There are many examples of why sharing rules are used including:

o The Lead OWD may be Private so partners cannot see all lead records, but a

company may want to have an internal/ non-partner open/ public model.

Create a simple sharing rule to open up all leads to the internal users only

o A marketing group, represented by an identifiable node in the role hierarchy,

will benefit from a single sharing rule to share all accounts and contacts with

that role hierarchy node.o Similarly the service group may need to see all accounts in order to get details

on what level of support companies are entitled, and to access contact details.


While sharing rules provide a tremendous amount of flexibility there is cause for

concern when there is a large number of sharing rules in any given object. Large in

this context varies based on the number of deployed users but Clear Task has been

introduced to environments where there are 20 or more sharing rules per object.

From an administration perspective a large number of sharing rules generally resultsin one or more of the following:

o Un-intended sharing or records

o Redundant rules, especially prevalent over time with multiple administrators

o Misunderstanding of the impact of choosing Internal & Subordinates and

Internal and Portal Subordinates

o A poor role hierarchy design which the sharing rules are trying to counter

balance


9/16


The example to the

right demonstrates how

to create effectively apublic read write model

(for accounts,

opportunities and

cases) for all internal

users, by sharing all

accounts owned by

internal or portal users

with all internal users

Clear Task recommend that sharing rules be:

o Used sparingly and only after the OWD decision and role hierarchy design is

complete. No pun intended, but sharing rules should be the exception not the

rule!

o Reviewed periodically to ensure there is no redundant or un-intended sharing.

A restructuring of the role hierarchy, or simply the passage of time (every 6 to

12 months) warrants a review of implemented sharing rules.

Under-utilized Features

The Spring 11 release introduced the concept ofcriteria-basedsharing rules for

accounts, cases, contacts, opportunities, and custom objects. These rules determine

whom to share records with based on field values in the records themselves. For

example, create an account rule to share all accounts where Billing Country=

Germanywith the Role EMEA Marketing

The feature is a compelling field value based approach to sharing records. Note,

however, that normal role hierarchy rules apply in that users above the shared user in

the hierarchy can still access the records.

Object Configuration:

Explanation:

This covers the process of creating new objects and of customizing both standard

and custom objects by creating new fields. The focus for this document is on:

o Page layouts


10/16


o Field level security

o Portal options

Clear Task Recommendations & Best Practices: Clear Task has observed an over-reliance on the Page layout as the construct to

hide fields from users. While conceptually excluding a field from a page layout

removes the users ability to see the field when viewing a record, there are many

other application areas where the field can surface, including:

o Report creation user interface, or when viewing canned reports

o List views

o Search results page

o Related list from a parent/ referenced record

o Etc. Using field level security, while administratively more involved and time consuming is

a more effective way to guarantee that a particular user profile does not have access

to a specific field.

Clear Task recommends weighing the risk of a given field being exposed somewhere

other than a record page layout. It may be low for many fields but highly important for

sensitive data like salary, date of birth, or social security numbers. Take a more

conservative approach and use field level security when in doubt.


11/16


The document to date has been focused on the primary ways to manage Salesforce data

visibility. The focus now shifts to examining effective way to manage permissions both

data access level permissions, and Salesforce feature level permissions.

While OWD, sharing rules, profiles, and the role hierarchy are (correctly) thought of as the

main influencers of system security, being too open in user profile definition can cause a lot

of harm to data quality and integrity.

This section reviews some of the top security related profile permission settings.

Standard & Custom Object Permissions:

Explanation:

While OWD, sharing rules, and the role hierarchy control whatrecords users see if

they are granted access to a given object, the Object Permissions settings control the

access level(i.e., Read, Create, Edit, Delete) to these records.

Object permissions are a very useful complement to the visibility settings since they

are more granular in nature as they are administered at a profile level, and in theory

there is no limit (other than a practical one) to the number of profiles.

Salesforce provides two important overrides View Alland Modify All that when

checked allow users assigned to the given profile the ability to view and modify

respectively all records of that objects type regardless of the sharing setting for that

object.


Clear Task has experienced one of two extremes, either:

o Companies are not as diligent as they should be with object permissions, and

only change them when there is some unintended sharing or data update.

Many companies simply Clone the Standard Userprofile, which has full

access for practically all objects.

o Companies go overboard and define too many profiles in order to have

extreme granular control over object permissions.

Other object permission bad practices include:


12/16


o When dealing with portal user profiles, the profile (and portal definition) may

not expose a tab for a given object but the object permission itself may grant

the user access to the record. This brings the possibility that records will be

visible to the portal user through the search function or through a report, andthat the portal user may be able to change that data.

o Excessive granting of the View Alland Modify Allpermission to the point

where the security model has become effectively internally open regardless of

the OWD setting, since granting the permission opens up permission also to

users above the assigned users through the role hierarchy definition.

Clear Task recommends the following best practices:

o Just as some upfront design consideration and thought is required for OWD

and sharing rules, devise a profile design approach upfront that groups the

major user groups into a manageable set of profiles.o Manageable will vary by the number of deployed Salesforce users and the

range of deployed processes/ clouds, but suffice to say try to avoid derivations

of the same profile with a small number of changes between them. Make some

hard choices, weigh the benefit of added profile to cater to perceived

exceptions.

[There is an upcoming Salesforce feature called Permission Sets, which aims

to help prevent an increasing number of profiles]

o Grant the View Alland Modify Allpermission sparingly. While there are

legitimate instances for its use, it should be the exception rather than the rule.An over use likely indicates that its time to rethink the OWD/ sharing rules/ and

role hierarchy.

o Pay special attention to portal user profiles to ensure that they do not have

unnecessary access to objects.

Administrative & General User Permissions

Explanation:

Administrative and general user permissions grant access to features as opposed to

data. That said, the permissions granted can have a tremendous impact on thesystem data and usability. As such thought needs to be given to what permissions

are granted.

At a high level:

o Administrative Permissions are very system feature centric and control what

system features other users can manage, such as managing list view, content

categories, public reports, users etc.


13/16


o General User Permissions are most data centric in that they control what users

can do with certain types of data. E.g., Convert leads, override forecasts,

import leads, approve contracts, etc.


Avoid System Administrator assignment creep! Many companies, especially smaller

ones that may not have a full time Salesforce administrator, have the tendency to

grant the System Administrator profile to too many people in order to empower the

to make the changes they need. Bad idea! The result will be a system:

o That does not have a consistent look and feel

o Redundant and duplicate field definitions

o Little to no customization of the user experienceo Poor data quality

Grant Administrative permissions sparingly. These are extremely powerful

permissions that can impact how a Salesforce instance is configured and should be

reserved for quasi administrators.

Of note, any permission starting with the word Manage gives the user great control

over what they can do in the system.

Exercise care when granting Manage PublicDocuments/ List Views/ Reports as

anything created by users with this permission becomes public unless the user

remembers to lock security down using the objects security settings. Grant View All Data and Modify All Data permissions sparingly/ on an exception

basis.

From a security perspective the case and lead related general administration

permissions (e.g., Convert Leads, Import Leads, Manage Leads, Manage Cases,

etc.) have the most impact on data quality and should be looked at in the overall

context of your organization/ team structure, business process definition, and data

strategy.

For example, should partners be allowed to convert leads? What impact does this

have on data quality? Will there be duplicate accounts created as a result? Or shouldlead conversion be centralized in order to minimize duplicates?

Consider creating a profile for employees that have given notice but have not left yet.

In that profile lock down permission such as:

o Export and Import permissions (e.g. Export Reports)

o API Enabled (so they cannot use the Salesforce Data Loader)

o Manage anything


14/16


Additionally:

Consider locking down the IP range (such as from corporate IP ranges) from

which they can log in.

Monitor the hours and IP ranges periodically before they leave the company

Institute turning off Salesforce access as part of the employee exit process

Managing For Exceptions

There are times when on an individual record a user (typically the record owner) wants to

make an exception to the previously discussed visibility and permission settings. For

example:

A sales executive that owns an opportunity may want to collaborate on the deal with a

user from a different node in the role hierarchy

An account executive may want to include a support user on an account

A user may want to share a custom object that is set up as private with another user

Salesforce provides the following constructs to open up sharing for individual records, where

the aforementioned exceptions occur.

Account Teams

Allow users to give other users access, or increased access

from the prevailing security model, to an account and its

related opportunities and cases.

Sales Teams

The sales team allows users to give other users access, or

increased access from the prevailing security model, to a


15/16


specific opportunity

Manual Sharing

When an object OWD is set as Private there is an optional

Sharing button that when placed on the layout brings up an

interface to include additional users/ public groups/ roles, etc.

to access the record in a read only or read write mode.

Clear Task has also created a free application called Multi-Tier visibility which allows

companies to automatically create manual sharing rules based on user entered data

http://appexchange.salesforce.com/listingDetail?listingId=a0N30000001tN5WEAU

Many companies use PRM have deployed this application as way to increase collaboration

between partner accounts in a secure way.

Advanced Visibility Topics

Territory Management

No discussion of data security would be completed without touching on territory

management, a native and powerful alternative to the standard role hierarchy.

Territory management uses a rules based approach to share access to accounts (and their

associated contacts, opportunities, and cases) based on the characteristics of the accounts

such as zip code, industry, revenue, or a custom field that is relevant to the customers

business.

There are pros and cons to using Territory Management, which is beyond the scope of this

document, but for organizations that need a private sharing model and have a complex/


16/16

16

matrixed sales model based on account attributes an investigation of territory management

feature is warranted. There are several public resources available on this topic including:

http://www.salesforce.com/customer-resources/learning-

center/details/best-practices/steps-to-deciding-if-territory-management-is-right-for-you.jsp

http://www.google.com/search?q=salesforce+territory+management

Multiple Salesforce Instances

There are rare cases where, unfortunately, the security model and related Salesforce

features do not simultaneously meet the needs of all of the organization business

constituents sales, HR, procurement, etc. meaning the model cannot be constructed in

such a way to simultaneously provide the visibility, permissions, and reporting required by thedifferent type of users and use cases.

Clear Task has observed that in these cases companies may choose to have multiple

instances of Salesforce, with each one optimized for their given business process. The down

sides are:

Multiple logins for users that need access to more than one system, although this can

be mitigated with SSO

Consolidated reporting across instances

Syncing important data between instances, although this can be mitigated by using

Salesforce to Salesforce or other 3rd party data integration solutions

This scenario is best considered when the instances are relatively autonomous of each other

and there is a compelling security reason to separate instances, such as for a HR system

where the data is extremely sensitive.

ClosingClear Task hopes that this document was helpful and highlighted best practices, common

mistakes, and unknown product features that will help make your Salesforce instance more

secure, user friendly, and helping achieve your business objectives.

Date post:	05-Apr-2018
Category:	Documents
Upload:	bc2255
View:	223 times
Download:	0 times