Salesforce security encompasses several significant areas to provide security, access, and visibility of data across a given instance. Security is a foundational element of the overall Force.com design. You must understand the interworkings of system security and data sharing within the Salesforce platform.
In this chapter, we review three main areas of security architecture, including platform security, record-level access mechanics, and internal and external user visibility and sharing.
The importance of the Salesforce security architecture as it relates to visibility of and access to data within a Salesforce instance
How Salesforce grants access to data behind the scenes
The impact of the Salesforce license on the instance security
How to manage the platform to control security, access, and visibility
The use of public groups to expand and manage access and visibility
The declarative and programmatic platform security features that can be used to meet record-level security requirements
The use of teams and territories to extend sharing to broader groups of users
How implicit sharing can impact record sharing
Making the optimal sharing and visibility options available
Why Is Security Architecture Important?
In 2020, the world dynamics changed that forced virtually every business to adapt quickly to support remote workers and to grant access to systems and data from beyond the confines of the corporate private network. The role of the security architecture was tested like never before.
Security is often aligned along three principles: confidentiality, integrity, and availability, or CIA for short. Confidentiality is an evaluation of how well an organization keeps its data private. Salesforce manages confidentiality with organization-wide defaults, roles, profiles, and permission sets which limit who has access to data and, more importantly, who does NOT have access to given data. Integrity is the safeguards used to keep the data safe and reliable. Salesforce supports digital signatures and certificates, encryption, intrusion detection, hashing, auditing, version control, and strong access and authentication controls to maintain integrity. Availability looks at the reliability of the systems and the timely access given to authorized users. Salesforce has established a high standard for system reliability and uses countermeasures to protect its users against denial-of-service attacks, natural disasters, and general human error through deploying redundant systems, using well-managed update procedures, and using DR and DOS protection solutions.
Authentication , Authorization , and Access Control : Authentication, along with authorization, is the first line of defense for data security, and it protects the system against data breaches. Chapter 7 covers this topic in detail.
Backups and Recovery/Archive and Deletion : Developing a plan and using it to manage your data with backups and recoveries and clear archival and deletion will further protect your data against system failure, disaster, data corruption, or breach. When information is no longer useful or has lost its value, it must be removed and archived or deleted. It is essential to establish guidelines that support your legal requirements. Often, it is as necessary to delete data as it is to retain it. Work within company guidelines and legal regulations in your industry. Remember the process of deletion also requires erasure. Make sure you have made the information irretrievable.
Encryption : Salesforce offers two types of data encryption: classic encryption and shield platform encryption. Classic encryption uses a special kind of custom text field, which uses a 128-bit Advanced Encryption Standard (AES) algorithm. Classic encryption supports masking and uses permission-based access to read encrypted fields. Shield platform encryption offers a broad set of encryptions from the field level to processes and across standard objects. Shield platform encryption uses a 256-bit Advanced Encryption Standard algorithm. It also supports the management of encryption key permission and HSM-based key derivation.
The Advanced Encryption Standard or AES is a symmetrical algorithm that uses a series of rounds that include substitution, shiftrows, mixColumns, and addroundrows. AES is faster than traditional encryption with flexible key length to limit effectiveness of cyberattacks.
Tokenization: Tokenization substitutes confidential data with random characters that are not algorithmically reversible. The relationship between the field value and its token values is stored in a protected database lookup table instead of a mathematical algorithm.
Three Pillars of Salesforce Security Strategy
Salesforce uses three guiding principles to keep everyone on task when it comes to cybersecurity; nail the basics, engineering, and business agility, and raise the security bar.1
In the first pillar, Salesforce implements threat detection and vulnerability management and identity and access management. In the second pillar, Salesforce uses a secure development lifecycle that includes a security-focused framework. In the final pillar, Salesforce utilizes and innovates PKI and certificates, detection, and platform security. Salesforce also ties into the Salesforce ecosystem through its architects to keep security in front of the mind.
Security Infrastructure : Salesforce provides advanced technology for cybersecurity. Salesforce uses Transport Layer Security (TLS) technology to protect client data using server authentication and classic encryption.
Phishing and Malware : Salesforce continually monitors email attacks, including phishing and malware attacks. In addition to your internal security team, you can report incidences and obtain continuous updates in real time on [email protected]. Salesforce Trust is an inherent service.
Redirects to External URLs: Salesforce protects from malicious links by alerting users when an untrusted link redirects the URL outside the Salesforce domain. Your administrator can manage and update trusted URLs.
Auditing : Salesforce offers extensive auditing features, including user login history, field-level tracking, and metadata change history. This feature allows an administrator to monitor changes and potential security breaches.
Security Health Check : Health Check is a wizard that can be run to identify and fix potential vulnerabilities in your security settings. The Health Check tool presents a summary score showing how your instance compares to a security baseline.
Platform-Level Security: Access and Visibility
Salesforce created its security model to support a broad spectrum of security, access, and visibility requirements among its customers. The security model starts with controls associated with objects and associated fields and then the records created within a given object.
Object, Field, and Record Levels
The Salesforce object can be a standard object provided as part of the SaaS solution or a custom object created by the customer to support unique requirements on the platform. Salesforce controls access to an object with its organization-wide default settings and the profile and permission set given to a specific user or group of users.
Organization-wide default (OWD) settings classify how the users of the system access an object. The OWD should be set to support the most restrictive level of access you expect for the user with the least access. In other words, set the OWD to limit the most restricted user in the system. If you want everyone who uses the system to see every record on a given object, set the OWD to “Public” for that object. However, to restrict the data for any record in the object, set the OWD to “Private” for that object.
You cannot use sharing rules to restrict access. Sharing can only be used to grant more access to a broader group of users.
Salesforce offers three primary OWD settings: Public Read/Write , Public Read-Only , and Private for both standard and custom objects. The names are self-explanatory. Public Read/Write means that anyone can view and create records in those objects. Public Read-Only means anyone can view records in those objects, but not create new records. Private means that no one except for the owner of the record can view the record. Salesforce supports two additional options: Public Full Access for the standard campaign object and Read/Write/Transfer for the lead and case standard objects. The Salesforce standard price object uses no access and view only and uses OWD settings to support their use.
Record ownership can be either the user or queue assigned to have the right to access a record. Ownership privileges include (1) view and edit, (2) transfer, (3) changing ownership for a record, and (4) deleting a record.
- 1.
Which user or group of users has the most restriction on viewing and creating records of data in the object?
- 2.
Should the user from the first question be prevented from seeing any of the records in the object? If yes, set the OWD to Private.
- 3.
Should the user from the first question be prevented from editing a given record? If yes, set the OWD to Public Read-only; else, set the OWD to Public Read/Write.
An object comprises any number of records that include a defined set of standard and custom fields. The object OWD determines if a user has access and visibility to a given field defined for a given object. This is called field-level visibility. The object permissions control access at the object level and are managed in profiles and permission sets. The controls include allowing and not allowing each of the following: Read, Create, Edit, Delete, View All, and Modify All.
Access to individual records for a given object is controlled by the sharing model or the ownership of the record. As previously stated, a given record is visible based on either the OWD, ownership, or sharing rules applied.
Approach to Sharing – Access to Records Expands with Each Feature
Sharing
Salesforce facilitates the management of record sharing through a set of declarative and programmatic features and tools, as shown in Figure 5-1. It is essential to understand how sharing approaches can be applied to obtain an optimal solution. This section looks at how Salesforce builds access from the most restrictive OWD to the required solution. A sharing architecture can control both the precision and the access to a given set of data in your environment.
Record Owner
Record ownership is the starting point for visibility and sharing within Salesforce. Record ownership allows a given user to view the assigned record per the user profile and assigned permission sets. The entire record access infrastructure is built around record ownership.
Each record has an owner, except “detail records” in master-detail relationships.
Object share tables are used to define which users and groups should receive access to records.
Group membership tables grant users access to records through groups, queues, role hierarchy, and territory hierarchy.
The owner listed on the record is used to create an AccountShare record. We will talk about each of these components in more detail later in the chapter.
Record owners can be either a named user or a queue. Queues can prioritize, distribute, and assign records to groups of users. Queues are used to route lead, order, case, and custom object records to a group of users to perform the business process.
Record Ownership Considerations
Approach | Description and Considerations |
|---|---|
Record or queue ownership | • Must be a single user or queue. • Profile setting overrides access at field/object level. • Queue helps distribute and assign members. • Higher roles can take ownership of a record. |
If a user has more than 10,000 records, they should not have a role. (If needed, it should be the highest level.)
Permission Sets
A permission set extends “permissions” given to a user or group of users without extending the permission to all of the users associated with a profile. Creating a permission set provides access to objects, fields, and controls not included in the user’s profile. The permission set can include settings and permissions that give users access to various tools and functions like those found in the user profile.
Permission sets are managed, adding and removing, from the user detail page. Permission sets can be created with an associated license or without a license. Additionally, some permission set features require a permission set license to be created. This license typically adds functionality not included in the base Salesforce license.
Proximity: Access to information only when in the proximity of a room, building, location, or IP address.
Limited Authentication: Access to service only while remotely approved.
Private or Confidential Access While Using VPN: Activates when users authenticate into your environment using a token.
Occasional Access Required: Uses flow to confirm the running user and activate permission during runtime.
SOAP API Activation: Allows API to set permission.
Self-Activates Permissions: Uses flows to activate and deactivate permission.
Permission Set Considerations
Approach | Considerations |
|---|---|
Permission set | • Like profiles, but users can have more than one permission set. • Permission set group can improve performance. • Make sure the license limits are considered. • Every user profile is automatically associated with a permission set. This permission set stores the profile’s user, object, and field permissions. • Can be used to assign access to Apex class methods. • Salesforce will resolve “broken permissions,” where access to a parent record already exists. • Cannot assign Default App with a permission set. |
Profile
Profile Considerations
Approach | Major Considerations |
|---|---|
Profile | • CRUD rights on record/field. • View All or Modify All ignores sharing rules at an object level. • Preferable to add View All Data or Modify All Data at org level. • Field level available. • Manage permissions in permission set groups with a muting permission set. |
The profile is used to assign page layouts, record types, custom apps, connected apps, and tab settings associated with a set of users. It also defines the field-level security for each object and the administrative setting and general user permissions for the Salesforce instance.
Beyond that, a profile assigns many of the system-level permissions including login IP range, Visualforce page access, external data access, named credentials, custom metadata type access, custom settings, flow access, service presence status access, and custom permissions. The profile also establishes the session settings, password policies, and login hours.
Organization-Wide Defaults
OWD Considerations
Approach | Major Considerations |
|---|---|
Org-wide defaults | • Setting: Public Read/Write, Public Read, Controlled by Parent, and Private. • The default level of access to records : Set to the most restrictive level required and then add permissions to add access to other users. • OWD is the only way to restrict user access to a record. • Settings can be changed but require sharing recalculated. |
Salesforce requires OWD settings for both internal and external users. External OWDs are a separate group of settings for external users. Salesforce uses the design to simplify sharing rule configuration and improve recalculation performance. External settings cannot be more permissive than internal settings.
Role Hierarchy
Role Hierarchy Considerations
Approach | Major Considerations |
|---|---|
Role hierarchy | • Allows managers to have the same access to records as subordinates regardless of OWD settings. • Org limit is 500 roles, but this can be increased by Salesforce. The best practice is to keep them under 25,000 for non-portal roles and 100,000 roles for portal roles. • Best practice is to limit to no more than ten levels of branches. • Peers to not guarantee access to each other’s data: Peers require sharing rules, teams, or territory management. • Moving the user to another role requires sharing rule recalculation. • Custom objects have “Grant Access Using Hierarchies” to prevent inheriting access. |
The role assigned with reporting acts differently. It allows the users in the role access, but not the senior role in the hierarchy.
Spend the time to understand role hierarchy as it is the foundation of the entire sharing model.
Sharing (Criteria and Ownership)
Sharing Rule Considerations
Approach | Major Considerations |
|---|---|
Sharing (criteria and ownership) | Ownership-based sharing (OBS) rules: • Based on record owner only. • Private contact records do not apply. • Use case(s): Service needs access to sales data, but not in the role hierarchy, or peer access for those in the same role or territory or access to other groups (public groups, portals, roles, and territories). Criteria-based sharing (CBS) rules: • Sharing based on a field value (criteria) using the sharing record. • Record ownership is NOT considered. |
Sharing rules are not available if the OWD is set to Public Read/Write.
Ownership-Based Sharing (OBS) Rules
An ownership-based sharing rule opens access to records owned by specific users. For example, a company’s managers need to see records owned by managers in a different role hierarchy. The sharing rule could give the other role hierarchy manager access to the record owned by another manager using owner-based sharing.
Criteria-Based Sharing (CBS) Rules
A criteria-based sharing rule opens access to records based on field values. For example, you have a custom object with a custom picklist field. A criteria-based sharing rule could share all records in which the field is set to a specific value with all managers in your organization.
No more than 1,000 OBS rules per object.
No more than 50 CBS rules per object. These limits are restrictive and must be considered. Salesforce can increase this limit, but the requirement must be justified and not solved with other options.
Manual and Programmatic Sharing
Often, the business requirements related to sharing and visibility go beyond options available with ownership, permission sets, profiles, and sharing rules. When this happens, you will need to consider broad-based sharing such as teams and territories, or you will need to implement manual or programmatic sharing.
Manual Sharing
Manual sharing is used to grant users access to specific records when other automated methods are not available or if the sharing is a one-off action required by the record owner or role hierarchy user.
Manual sharing is available only in Salesforce Classic. Several AppExchange apps are available to add manual sharing in Lightning.
Care should be taken with manual sharing, as it can also grant access to a given record, including all of its associated records. For example, manually sharing an account record grants access to associated records in the opportunity and case objects. Salesforce limits manual sharing to (1) the record owner, (2) users higher in the role hierarchy (where it is allowed in OWD), and (3) a system administrator.
Manually created share records are deleted when the record owner changes, including shares associated with related object records.
Manual sharing allows the record owner to share records with other users and a broad selection of group types, including manager groups, manager subordinate groups, public groups, personal groups, roles, roles and subordinates, roles and internal subordinates, roles and internal and portal subordinates, territories, and territories and subordinates.
Programmatic or Apex-Managed Sharing
Apex-managed sharing allows developers to share records programmatically. Apex-managed sharing users can only use sharing with the “Modify All Data” permission. The sharing access is maintained across record owner changes. An Apex sharing reason is required to create an Apex sharing record. The Sharing reason is a developer note justifying the need for the apex sharing.
Manual and Programmatic Considerations
Approach | Major Considerations |
|---|---|
Manual and programmatic | Manual sharing: • Record owners can give read and edit permissions to other users and groups of users. • Manual sharing is removed each time the record owner changes. It does not add as it is already provided with the OWD. • Manual shares can be created programmatically. • The “row cause” uses “manual share.” • All share records with a row cause defined to “manual share” can be edited by the Share button (Classic only), even if created programmatically. Programmatic or Apex-managed sharing: • Programmatic sharing (Apex sharing) allows you to use code (Apex or other) to build sophisticated and dynamic sharing settings when it cannot be met by any other means. • If created programmatically with the row cause description as “manual share,” then the shared record is managed with the Share button. As such, it is deleted upon owner transfer. • The “Modify All Data” permission is required to add, edit, or delete sharing that uses an Apex sharing reason. • Deleting an Apex sharing reason will delete all sharing on the object that uses the reason. • Objects are limited to ten Apex sharing reasons. • Metadata API can create Apex sharing reasons. |
Teams
Team Considerations
Approach | Major Considerations |
|---|---|
Teams | • The group working on an account, opportunity, or case. • Gives read-only access or read/write access. • Owners, users higher in the hierarchy, and administrators can add team members. • Read/write access members can add other members. • Creating a team member creates two records: a team record and an associated share record. • Only one team per record (if more needed, use programmatic sharing). • A team object is not a first-class object, meaning you cannot create custom fields, validations rules, or triggers. |
Users with a high level of access will have that access regardless of the access given in the team role.
Territories
Territory management is an account object sharing system that grants access to accounts based on the characteristics of the account records. It is an advanced sharing strategy to extend further access to records not supported with other sharing options.
Territory sharing only supports accounts and master-detail related objects.
A territory is a collection of accounts that gives a user access to the account record regardless of who owns the account record. The access level is configured to grant read, read/write, or owner-like access to the account records in that territory. Account records and users can exist in multiple territories. Territories exist in a hierarchy that can set up with nested levels. Account records are added to a territory either manually or with assignment rules that assign account records to territories automatically. Account record assignments can be added via an API.
Territory Considerations
Approach | Major Considerations |
|---|---|
Territories | A single dimensional hierarchy which can be structured by business units in a hierarchical structure to grant access. • When enabled, both the role hierarchy and territory hierarchy must be managed. • Territories exist only on account, opportunity, and respective master/detail children. • The best practice is to have no more than ten levels of branches in the hierarchy. • If the assignment rules or membership for territory is changed, sharing rules using that territory as the source will be recalculated. Account territory sharing rules (when enabled): • Only available for accounts marked with the territory. |
Divisions
Division Considerations
Approach | Description and Major Considerations |
|---|---|
Division | • Must be enabled with a Salesforce service ticket. • Users are assigned a default division that is applied to newly created records. • User permissions impact divisional separation and each time a division is created, it needs to be assigned to each user manually. • Improves searching by limiting the result set to the division level. • Reduces LDV issues by segmenting data into smaller subsets. |
Access to Data Behind the Scenes
As a Salesforce architect, you should know how to grant users an appropriate level of access to the data in your Salesforce instance. Data access in Salesforce uses two main access categories: object-level access with field-level access and record-level access.
Salesforce does not have a field-level sharing rule. Rather, Salesforce uses OWD permissions for field-level access.
Object-level access verifies a user has access to a particular object, the specific actions the user can perform, and the specific fields the user can see. Object-level access is managed via the user profile or the given permission set. Object-level access can restrict users with object permissions, such as “Read,” “Create,” “Edit,” and “Delete,” and field-level security to limit visibility. It can also open up access for users with object settings such as “View All” and “Modify All” object permissions.
Record-level access is called “sharing” in Salesforce. Record-level access determines which records a given user can see for a particular object. As shown in the preceding text, sharing uses organization-wide defaults, role hierarchy, sharing rules, manual sharing, programmatic sharing, teams, and territory hierarchy.
It is crucial to understand how Salesforce calculates and grants access because sharing record access with users can quickly become complicated and changing your sharing configuration impacts the performance of the system.
Access Grants and Record Access Calculations
Salesforce determines record accessibility each time a user views a record to grant data visibility. Record access is granted using many different factors such as ownership, role hierarchy, sharing rules, implicit sharing, and so on. For enterprise-class Salesforce implementations, the sharing architecture is complex and requires extensive sharing calculations to maintain. Salesforce does not perform these calculations in real time. Instead, Salesforce calculates and populates a sharing record each time a record is changed.
Explicit Grants : Where the record is shared directly with the user of the group
Group Membership Grant : Based on membership
Inherited Grant : Gained through the hierarchy
Implicit Grant : Built-in sharing based on parent/child
Salesforce Access Grants Are Stored in Three Different Tables
Behind-the-Scenes Sharing and Group Tables
Table Type | Use of the Table Related to Sharing |
|---|---|
Object record table | The object tables store the actual records for a specific object. The object indicates which user, group, or queue owns each record. |
Sharing table | The sharing table stores the data that supports explicit and implicit grants. Most objects have an object sharing table. The exceptions include objects with Public Read/Write OWD, the detail side of a master-detail relationship, and select objects like activities and files. |
Group maintenance table | The group maintenance tables store supporting group membership and inherited access grants. Supporting group membership and inherited access grants are created for each user, group, or queue aligned to the record. These grants are established in advance when you create or change the group (or role or territory) members. |
Salesforce uses the three tables to determine if the accessing user has the proper grant to gain access. Salesforce begins with the object record ownership. It then looks at the sharing table. It then looks at the group maintenance table. Salesforce uses SQL statements that are subsequently appended to find the access grant. If a grant is found, the additional SQL statements are not completed. This process uses the available resource efficiently. The SQL statement begins with matching the record ID in the object and object sharing table. If that does not find a response, the SQL statement is amended to expend the search in the object sharing and group maintenance tables using the user ID or group ID.
The granting method is different between the two processes. The first SQL statement uses sharing rows to grant access. The process checks if the user ID that is seeking access is listed within any row of the object’s sharing table. The second SQL queries the group maintenance table, specifying who belongs to each group. These tables store membership data for every group, including system-defined groups. Salesforce creates two types of system-defined groups, role groups and RoleAndSubordinates groups. If the organization has external OWDs enabled, a third system-defined group, RoleAndInternalSubordinates, is created.
The Impact of License on Security
Unlike standard Salesforce licenses, high-volume community users are not in access grant tables with sharing rules because they do not have roles or public groups. Only users with licenses that support roles are included in sharing rules.
Full Sharing may not be turned on for all modules, but exists.
HVP does NOT utilize the sharing model. Instead, it uses a foreign key (FK) between HVP and the account/contact lookup. Customer Community users are included as HVP licenses, not Partner Community and Community Plus licenses.
Chatter Free: Collaboration-only, including Chatter, people, profiles, groups, files, chatter desktop, and limited Salesforce apps. No access to standard or custom object – so no sharing.
Platform Security
- 1.
Application-Level Security : Areas of security that can be managed, configured, and controlled at each Salesforce instance level, by any Salesforce administrator, and as per the security needs of the enterprise.
- 2.
Infrastructure-Level Security : Areas of security at an infrastructure level of Salesforce, which is exclusively controlled and managed by Salesforce. Salesforce provides this level of security to all customers equally as part of their multi-tenant architecture offering. Individual Salesforce users or Salesforce administrators do not have access to this level of security and cannot modify or configure these security options.
Salesforce Security Levels
To stay within the scope of this book, we will focus only on application-level security. We will not cover infrastructure-level security since an architect, or any end user, does not have much control over Salesforce’s infrastructure-level security.
For more details on infrastructure-level security, please refer to Salesforce’s infrastructure and sub-processor level documentation available at www.salesforce.com/content/dam/web/en_us/www/documents/legal/misc/salesforce-infrastructure-and-subprocessors.pdf.
- 1.
IP range restrictions and enforcement of VPN-based access
- 2.
Multiple user authentication options
- 3.
Organization-wide default settings
- 4.
Sharing rules
- 5.
Profiles and permission sets
- 6.
Objects and field-level security
- 7.
Field Audit Trail
- 8.
Setup Audit Trail
- 9.
Event monitoring
- 10.
Data encryption
Salesforce Security and Regulatory Compliance and Adherence
For more details, refer to www.salesforce.com/content/dam/web/en_us/www/documents/legal/misc/salesforce-security-privacy-and-architecture.pdf.
Standard (Out-of-the-Box) Salesforce Audit and Event Monitoring Capabilities
Salesforce provides several standard audit and event monitoring tools as part of its security infrastructure. Let’s look at a few crucial features.
User Login Monitoring
Salesforce administrators can monitor all login attempts for their orgs and any enabled portals or communities activated from their managed orgs. The login history page shows up to 20,000 records of user logins for the past six months and can also be downloaded in a CSV or zip file format. The downloadable file can contain more than 20,000 records, which is a limitation when viewing the login history page, which can only show 20,000 records at any given time.
Field History Tracking
With standard out-of-the-box capabilities, administrators can choose up to 20 fields for any standard or custom object to track and display the changes made to those fields in a history-related list of each object. Field history data is retained for 18 months from within the Salesforce org and up to 24 months when accessing the field history via the API.
Monitor Configuration and Setup Changes
Audit trails and debug logs can be set up to track all changes to configuration or code made by any user of the org. The debug logs are categorized into nine categories of functionalities within Salesforce and can provide seven debug levels.
For more details about standard debug logs in Salesforce, please refer to https://help.salesforce.com/articleView?id=code_setting_debug_log_levels.htm&type=5.
Transaction Monitoring and Policies
Transaction Security is a framework that intercepts real-time Salesforce events and applies appropriate actions and notifications based on security policies that an administrator has set up in the org. When any security policy is triggered, the administrator or any user can receive a notification.
Data Encryption and Data Security Options
Salesforce Data Encryption and Security Option
Option 1 | Encrypted Custom Fields |
|---|---|
Description | Standard functionality: Field contents are encrypted via 128-bit AES encryption; user perm required to view the actual data within Salesforce; keys are manageable within Salesforce. |
When to use | The exact data values are needed for the use of some functionality in salesforce.com and can be seen by select, logged-in end users. |
Pros | • Encryption and key management are native functionality. • Can be included in reports, search results, validation rules, Apex scripts. |
Cons | • Not available for standard fields. • No search, filtering, use in workflow, mobile. • Limited to 175 characters. • Fields still accessible by administrators. • ECFs are always editable, regardless of whether the user has the correct perm. |
Option 2 | Data Masking |
Description | Only part of a sensitive piece of data is stored in Salesforce (e.g., the last four digits of a SSN or credit card number). |
When to use | Typically with call centers: Some part of the sensitive information is needed in the case management or identity verification process for a caller; end users should never know the whole value. |
Pros | • Sensitive data is “de-sensitized” before it gets to Salesforce and rendered benign while still being able to support the business process. |
Cons | • None, if this is the proper use case and the unmasked values can still support their needed function. |
Option 3 | Data Transformation |
Description | Sensitive information is programmatically transformed before it is stored in Salesforce (e.g., credit ratings above 750 are translated to “Tier 1”). |
When to use | Some derived meaning of the original values is needed in Salesforce. |
Pros | • Sensitive data is “de-sensitized” before it gets to Salesforce and rendered benign while still being able to support the business process. |
Cons | • If the transformation changes often, this approach can present additional work to change the algorithm. ECFs are always editable, regardless of whether the user has the correct perm. |
Option 4 | Storing a Hashed Value in Salesforce |
Description | Sensitive data is hashed to a benign value by the customer before being stored in salesforce.com. |
When to use | The hashed value is needed for integration or to otherwise tie information in Salesforce back to the information stored elsewhere; users and business processes do not ever need to see the real values. |
Pros | • Customer can fully control/maintain the hash on their infrastructure. • Sensitive data never exists in Salesforce in any manner. |
Cons | • Requires implementation on customer infrastructure (hashing agent, hardware). • Real values are not leveraged via any Salesforce functionality. |
Option 5 | Mashups |
Description | Sensitive data remains inside the customer network or other approved platforms; UI rendered as needed using an iframe; data is never transmitted to or stored in Salesforce. |
When to use | Users only need to temporarily view sensitive data in the context of the business processes and screens implemented in Salesforce. |
Pros | • Data never leaves the customer or secure network/platform. • The customer has ultimate control of and responsibility for who sees the data and how they see it. |
Cons | • Real values are not leveraged via any Salesforce functionality. • Can require SSO or additional changes to these systems to be readily frame-able. • Usability and page load performance can take a hit. • The customer is fully responsible for DR, failover, scalability, performance, and so on. |
Option 6 | Web Service Callout |
Description | Sensitive data remains inside the customer network or other approved platforms; data only rendered as needed using Visualforce (to guarantee it is not persisted in Salesforce). |
When to use | The system storing the sensitive data has an externally callable web service and not a suitable mashup UI. |
Pros | • The customer has ultimate control of and responsibility for who sees the data and how they see it. • Possibly the best UI/UX. |
Cons | • The callout requires a custom in-line Visualforce component or page. • Real values are not leveraged via any Salesforce functionality. • Can require SSO or additional changes to these systems to be readily frame-able. • Usability and page load performance can take a hit. • The customer is fully responsible for DR, failover, scalability, performance, and so on. |
Option 7 | Encryption Appliance/DRO |
Description | An appliance whose primary function is to encrypt outbound data sits inside the customer network; all data passed over the Internet is encrypted before transmission. |
When to use | The loss of functionality/limitations with ECFs is not acceptable to the customer, and they are willing to host a solution. |
Pros | • Supported product (nee Navajo, not GA). • Data is fully encrypted when it gets to the Salesforce servers. |
Cons | • Additional hardware, setup, administration, and maintenance resources and costs. • Customer/partner is fully responsible for DR, failover, scalability, performance, and so on. • Some Salesforce functionality is still lost. |
Salesforce Shield
Platform encryption
Event monitoring with Transaction Security
Field Audit Trail
Platform Encryption
Shield platform encryption leverages an HSM-based key management service and AES encryption standards with 256-bit keys. With this level of encryption, an enterprise can encrypt any sensitive data at rest across the entire Salesforce org. The main distinction between standard Salesforce encryption and Shield platform encryption is that the Shield platform encrypted fields are available with most field types. Additionally, encrypted fields are searchable and can be used within any Salesforce automation tool such as workflow rules, validation rules, and so on.
You can learn more here:
https://help.salesforce.com/articleView?id=security_pe_overview.htm&type=5
Event Monitoring
Shield’s event monitoring capability enables an enterprise to monitor detailed performance, security, and usage across the Salesforce org. Shield tracks login history, transaction security, and event logs. Each interaction is tracked and accessible via the API. Event monitoring data can be also imported into any data visualization or application monitoring tool like Einstein Analytics or Splunk or New Relic.
Learn more here: https://trailhead.salesforce.com/content/learn/modules/event_monitoring.
Field Audit Trail
With Field Audit Trail , you can retain data history for forensic-level compliance and more significant operational insights into your business. Field Audit Trail available with Shield allows you to track up to 60 fields for each object of Salesforce, compared to the standard Salesforce audit trail, only allowing 20 fields to be tracked for any object. The field tracking history can be retained for up to 10 years using Shield.
Learn more here: https://help.salesforce.com/articleView?id=field_audit_trail.htm&type=5.
Security for External User Experiences and Salesforce Portals
In terms of security for external user interaction via Salesforce communities, Salesforce provides the following options out of the box.
Clickjack Protection in Communities
This feature secures the user’s browser interaction by disallowing any browser behavior that redirects the user from Salesforce to unauthorized or malicious websites.
Cross-Site Scripting (XSS) Prevention
Salesforce implements the Content Security Policy (CSP) standard, which is a W3C industry standard, allowing Salesforce to control the source of every content that can be loaded onto the community pages. Salesforce provides two different levels of CSP security, depending on the level of security vs. content flexibility needed.
Using Groups to Manage Access and Visibility
A group is a collection that can include individual users, other groups, or all the users in a particular role or territory. It can also contain the associated subordinate users in the role or territory hierarchy. Groups, by themselves, do not affect access and visibility. Instead, groups are used to improve sharing by creating a collection of users to be used by the sharing rules.
Public Group Considerations
Approach | Major Considerations |
|---|---|
Public groups | • Collection of users, roles, and territories that have functions in common. • Groups can consist of • Users, Customer Portal users, partner users • Roles, roles and internal subordinates, roles and internal and portal subordinates • Portal roles, portal roles and subordinates • Territories and territories and subordinates • No more than five nested public groups allowed. • No more than 100,000 public groups. • Groups plus sharing rules are needed for data access. • Grant Access Using Hierarchies can be used to support limiting role access to sensitive data. |
Personal groups are intended only to create and manually add to given records they want to be shared with a group.
Implicit Sharing Can Impact Record Sharing
Many sharing behaviors are built into the Salesforce design. This kind of sharing is called implicit sharing. It is not configured; it is defined and used by the system to support collaboration among different users. Implicit sharing automatically happens and cannot be changed or overcome. Parent and child implicit sharing are described as follows.
Parent implicit sharing gives read-only access to account records when a given user has access to a related record of the parent account. It applies for all records in the contacts, opportunities, and cases associated with that account record. This grant happens for all users with shared access to the child records; they do not have to own the child record.
Additionally, the privileged user will also see the account name in the shared related objects, but not the account details. The name visibility rolls up to the parent account as well. This implicit share happens on all other objects, including custom objects. The sharing table automatically saves all users with the sharing value with a RowCause equal to “ImplicitParent.”
Child implicit sharing gives access to the child records (contact, opportunity, and case objects) of a parent account record for the owner of the related account record. This implicit share is carried to both account sharing rules and account team access. If the parent account owner is changed, all of the implicit shares need to be recalculated. The “Controlled by Parent” feature removes this implicit sharing.
Community Sharing for External Users
Sharing information to external users extends the Salesforce instance to a large group of users. Creating deliberate sharing protocols will keep your information secure. External users are users, including authenticated website users, Chatter external users, community users, Customer Portal users, high-volume portal users, partner portal users, and Service Cloud Portal users. It can also include guest users and unauthenticated users. This section reviews different ways to manage the security of your instance.
External Organization-Wide Defaults
External organization-wide defaults facilitate the support for different sharing settings for internal and external users. External OWDs can simplify sharing rules and speed up sharing calculations. The external OWD is limited to a subset of objects, including account, contact, case, opportunity, lead, asset, campaign, individual, order, user, and custom objects.
External OWD must be equal to or more restrictive than Internal OWD. External OWD settings include Controlled by Parent, Private, Public Read-Only, and Public Read/Write. Sharing rules can extend the sharing model but are limited to 50 sharing rules per object. Sharing is ownership based by default. Sharing sets are used to give access to records owned by others.
Sharing Sets
A sharing set grants access to external users associated with a record using either the user’s account or contact ID. Sharing sets are only available for external users.
Sharing sets work differently than other Salesforce sharing methodologies. The sharing approach utilizes the created community user derived from a contact record connected to an account. Remember how to create a community user? A sharing set uses these variables: User.ContactID and Contact.AccountID. A sharing set creates the sharing table entry based on the assigned variable.
Sharing sets are limited to the core standard objects and custom objects. The option to create a sharing set is only available for custom objects that are related to a contact or account. The external OWD for the object must be private.
Share Groups (for Internal Users)
High Volume Portal (HVP) users do not have roles and cannot be added to the role hierarchy. Thus, the sharing of records owned by HVP users needs a unique sharing tool. This tool is the share group. A share group is associated with a sharing set, and there can only be one share group per sharing set. The grant creates full read/write access.
External Role Hierarchy
External users do not have the same role hierarchy as standard Salesforce users. The scope and type of role are controlled by the license type used. Let’s look at the license options and the related role options.
Customer Community licenses do not support roles, and role-based sharing will not work. Public groups and manual sharing are not allowed.
Customer Community Plus licenses have three role types: user, manager, and executive. Public groups and manual sharing are allowed.
Partner Community licenses have three role types: user, manager, and executive. Public groups and manual sharing are allowed.
Community user hierarchy is linked through an associated account record or ownership.
Role hierarchy visibility allows reporting and regular roll-up views.
External account roles are created with the creation of the first user associated with the account.
Community Plus and Partner Community have one default role. Up to three roles are available.
By default, 50,000 roles are creatable, with more available if needed .
Making Optimal Decisions
Potential Optimal Solutions for Various Security, Sharing, and Visibility Scenarios
Requirement | Environment Settings | Solution(s) |
|---|---|---|
Two in a box: A role-based user wants access to another role to assist | Private OWD, role based | Ownership-based sharing rule: Edge case, trusted user set. |
User needs access to different department data (records) | Private OWD, role based | Ownership-based sharing rule: Common use case, other teams needing access. |
Core team (a group of different roles) on account | Private OWD, role based | Teams: Only one team per account needed. |
Manager access to subordinates | Private OWD, role based | Role hierarchy: Supports access to subordinate records. |
Limited privilege: The team cannot modify team member | Team button access | Remove button from the layout. |
Buddy support: Allow access to the same profile | Private OWD, role based | Teams (notwithstanding the preceding text). |
Add specialist to an opportunity | Private OWD, role based | Teams: Manually added.Trigger: If always known. |
Two teams need access to the same account | Private OWD, role based | Territory management: Account team is too granular. |
Separate unit needs access to account for specific opportunity team. Unit is a shared resource | Private OWD, role based | Territory management: Unit of users is supported with a sub-territory if TM is used for teams. |
One-off-basis access to account | Private OWD, role based | Teams: A native aspect of teams. |
Department needs access to given business unit data | Private OWD, role based | Ownership-based sharing rule:Sharing rule using a group, a branch of role, or a role and subordinate. |
VIP customer directly managed by a manager and editable by the manager and above | Private OWD, role based | Ownership and role hierarchy. |
Only the manager can set account as VIP customer | Private OWD, role based | OWD private, profile with RecType. |
Only the given actor can set up and enable product | Private OWD | OWD: Permission set to add, create, and edit products. |
Only active products available for purchase by the customer | Community | OWD private, create PB, share using role. |
Customer can view own account and contact | Community | Customer can access their own account and contact records, based on implicit sharing. |
Customer can create and view cases | Community | Add the Case tab and set visibility to read, create, and edit with permission or permission set. |
Customer can view the shipment status | Community | Add the Shipment__c tab and set visibility to read with permission or permission set. Update Manage Community for tab. |
Only a given actor can create and manage leads and convert into opportunities | Private OWD, role based | Permission set (convert leads permission) with permission for account, contact, and opportunity. |
Lead only visible to the owner | Private OWD, role based | OWD private |
The lead owner can change the “Visible to All” flag to allow other CRs to manage | Private OWD, role based | OWD on lead is private.Profile.Criteria-based sharing rule on field. |
Sr. user wants a monthly summary report on shipment orders for all regions | Private OWD, role based | Role above shipment owners, running user settings. |
(a) Internal case created by an employee (b) Internal case visible only to VP and CIO and above (c) Internal case not visible by manager | Private OWD, role based | OWD private.Employee = create and edit.Manager = no access.VP/CIO = read. |
When needed, given actor involves partner manager or partner user on opportunity | Partner Community | External OWD = private.On-demand can use manual sharing of opportunity. |
Partner company wants to collaborate among partner teams on deals, shipments, and update opportunities owned by any member of the partner | Partner Community | External OWD.Create partner roles.Create a sharing set for a partner company and partner team. |
Global partner has franchises. The owner wants to see all customers managed by franchises | Partner Community | External OWD.Create partner roles.Create a sharing set for a partner company and partner team. |
All partner managers can see opportunities, cases, and shipments | Partner Community | External OWD.Create partner roles.Create a sharing set for a partner company and partner team. |
The internal actor creates opportunities they manage and wants to share with an external partner | Partner Community | External OWD = private.On-demand can use manual sharing of opportunity. |
Shipment data for a select customer must not be visible except for sr. leadership | Partner Community | Create a record type.Change profiles to limit/remove access to shipment object. Add permission set for sr. leadership. |
Partner managers in the United States to manage all users in their partner account | Partner Community | Enable Partner Super User access; assign to individual users; add the “Portal Super User” permission to a permission set. |
Global internal user can create and freeze users | System admin | Manage user “permission” or set up as delegated admin. |
Seasonally allow a partner to support cases of any customer | Partner Community | External OWD.Create partner roles.Create a sharing set for a partner company and partner team. |
User should be able to share opportunity in the sibling role for JUST ONE WEEK | Internal user | Criteria-based sharing ruleusing time-based trigger. |
Sr. user wants to be able to collaborate with individual customers | Community | Chatter. |
A senior user wants to collaborate with an external partner, individual, or business customer | Internal user | Private groups and Chatter. |
The price book should be visible to the customer via the community. Limit other views of price book | Community | OWD = No access.Sharing rule. |
Restrict access to cases created internally to internal users. No access to the customer portal | Community | Remove external OWD to price books. |
Support wants to share a case with sales agents, but not sales management | Internal | Sharing using private group.Remove hierarchy check. |
Sales user allowed to delete opportunities they own if less than $100,000. | Internal | Validation rule on an opportunity. |
Sr. leader wants access to CASES for customer with the sum of OPPORTUNITIES greater than $100,000 . | Internal | Criteria-based sharing rulewith opportunity roll-up value. |
The solutions are notional, as the full details of the scenarios are unknown.
Chapter Summary
The three pillars Salesforce uses to stay ahead of the ongoing cyberthreats, including nail the basics, engineering, and business agility
The security attributes Salesforce employs to safeguard data access, sharing, and visibility
The building blocks used to create a scalable and efficient security model, including an under-the-covers look at the system-level share tables and group maintenance tables used to manage sharing grants
How Salesforce uses ever-widening sharing features to expand access to business data from permission sets to territories
The impact of licenses and internal and external users on sharing within the Salesforce instance
That Salesforce provides both application-level and infrastructure-level security features
The eight options available to encrypt and secure your data
The features available with Salesforce Shield
The security available for Salesforce communities
How to use groups to streamline access and visibility
The types of implicit sharing grants created automatically by Salesforce
How to use external OWD, external role hierarchy, sharing sets, and share groups to extend sharing to external users
How to use the different sharing options to make good design decisions