Security Regime

Security Regime for a CRM Analytics Implementation (January 19, 2024)
User Story:
• Imagine you are tasked with implementing a robust security strategy for a Salesforce CRM environment. The organization deals with sensitive customer data and requires a secure analytics solution that balances data accessibility with stringent security measures. 

Assignment Task - Share how you would approach the following:
 • Data Access Control.
 • Audit Trail and Monitoring
 • External Data Source Security.



Proposed Solution:
Data Access Control  - can be achieved by utilizing varying methods or layers in the CRMA environment.
It would start with app level security where CRMA asset access can be restricted to a certain group of users. As an example, if business unit “A” should only have access to 3 dashboards, the 3 dashboards (and their underlying datasets) should be saved in an app which is then shared to that group of users.

The next aspect of CRMA security is object or field level security. This would involve modifying the object and field access of the integration user and the security user since any attempt to access object and fields not given permission would result in the dataflows failing. This layer can be implemented in place of or in combination with app access layer should the requirements call for object access with restrictions on certain fields for certain groups.

The next layer of CRMA is utilizing SFDC’s sharing rules in combination with security predicates. The use of one or both layers would depend on the size of the enterprise and the types of objects to be secured (due to the limitations of the sharing rules). In addition, performance issues might need to be considered since there are overhead costs to using the sharing rules.

In terms of security predicates, flatten transformations would be used to ingest the manager hierarchy, the role hierarchy, opportunity teams and other sharing hierarchies (ingested through csv’s) to enforce row-level security requirements.  

A sharing hierarchy dataset can also be curated. This dataset – which can be refreshed weekly contains the aforementioned hierarchies and ingested into new recipes – an efficient way to streamline the process and replace 4+ nodes with a single node. 

In addition to the layers above, a superuser category can also be created – achieved by 1) adding a ‘Dataset Access’ field in the user profile, set to let’s say “True”  and 2) adding to the recipe transformations a constant ‘ViewAllFlag’ field set to “True” . This would enable a certain category of users to bypass the security restrictions and have complete access to the CRMA datasets/assets. Examples of these personas would be external ad-hoc CRMA developers, or senior people that manages business units not adequately expressed by existing role hierarchies. 

An example of a security predicate which makes rows available only to opportunity leaders, opportunity owners, account owners, managers of the owners, users belonging in the roles hierarchy and superusers. 

'OpportunityId.Opportunity_Leader__c' == "$User.Id" || 'OwnerId.Id' == "$User.Id" || 'Account.OwnerId'   == "$User.Id" ||  'OwnerId.ManagerMulti' == "$User.Id" || 'OwnerId.UserRoleId.Roles'   == "$User.UserRoleId"  || 'ViewAllFlag' ==  "$User.Dataset_Access__c"


Once all these layers of CRMA get implemented, the CRMA admin will need to test the layers by assuming different identities and checking if the asset access, object/field  and row level controls work as defined.



Audit Trail and Monitoring - Monitoring the security regime discussed would involve subscribing to external tools to track changes in the security predicates.This is so because security predicate changes are not logged in the SFDC audit log. *  Change data capture (CDC) 3rd party tools are available which captures changes to SFDC data such as 

• Salesforce Change Data Capture (CDC)
  
• Datadog Change Data Capture (CDC)
  
• BMC Helix Change Data Capture (CDC)
  
• Change Auditor for Salesforce
  
• Salesforce Cloud Data Connector  *
  

*https://trailhead.salesforce.com/trailblazer-community/feed/0D54S00000HDtugSAD
In addition to monitoring changes to the predicates, the sharing hierarchy dataset has to be refreshed periodically to track users that have been activated / deactivated in the user object.



External Data Source Security - can be implemented by either pre-filtering the data rows before synching it into CRMA (using  connectors) or post-filtering them after it gets synched. 

There are performance issues and generalizability of use factors to be considered in deciding which method to use. 

• Prefiltering makes for a more efficient process since unneeded rows are not ingested and synched periodically. However this efficiency could compromise flexibility of data (ex: prefiltering out certain geographic regions means the process has to be redone again should there be a need to analyze those regions previously excluded). For csv files, a pre-filter would need to be created by adding its definition in the metadata schema file in the csv.  
  
  
  
• For post-synch filtering, one would need to create the filter in the output node of flows  or recipes or by editing the curated dataset. Converse to the pre-filtering issues, post-filtering can be less efficient (if care is not taken in the proper selection of rows) since unneeded rows are ingested and synch periodically.However, this approach would be more generalizable since it can fit a greater number of use-cases as more fields are already available in the CRMA object being synched.