Secure Your Data in Community Cloud with Advanced Configuration

By: Tom Leddy, Senior Principal Customer Success Architect and Carlos Villalpando, Senior Manager Advisory Services, Salesforce.org

In our last blog post, we talked about three steps to secure your Salesforce data that can be accessed in your Salesforce Community. We focused on using features like object, field, and record level security to ensure data is available to the appropriate users. In this month’s blog, we’ll look into more advanced configuration and settings to further protect your data. Keep reading to learn how decisions you make around APIs, your Salesforce account model, and license types can have security implications in your Community.

Restrict Community Cloud Access via API

Users who have the API Enabled or APEX REST Services permissions can access your org’s data from outside of the Salesforce UI. This is very useful for integrations and connected applications, but you should assign these permissions sparingly because they can also inadvertently create vulnerabilities. Here are a few things to consider when working with them:

• Enable these permissions via the User Profile, but remember to disable them for Anonymous or Guest Profiles.
  
• Users with API Access can access any Salesforce API, so consider whitelisting the IP Addresses of the users you give it to in order to prevent access by unauthorized applications.

• APEX REST Services Access is more restrictive because it limits access to just REST Services without providing access to the SOAP API.
• Connected Apps integrate applications with Salesforce using APIs using standard SAML and OAuth protocols to authenticate, provide single sign-on, and provide tokens for use with Salesforce APIs. You can set policies to control who can use the corresponding apps, and it’s a good practice to set the OAuth Policy to “Admin approved users are pre-authorized,” which will allow you to limit access to ensure that only people with the profiles or permission sets you specify can access the app.

Understand the Security Implications of Your Salesforce Account Model

Account Models define how account, contact, and opportunity objects interact with each other in NPSP and EDA. There are three different types of account models.  You can see the one that your organization is currently using by going to People -> Account Model in your NPSP/EDA settings. Regardless of what model your organization leverages, pay attention to the way your sharing sets and profiles are set up in case you need to make adjustments to restrict access.

• In the Bucket Account Model, contacts without an account are all assigned to an overall “bucket” account. Since all contacts belong to the same account, they’ll be able to access each other’s data unless you explicitly restrict it by setting organization-wide
  defaults to Private and creating a sharing set that grants access to Community Users with a custom profile based on their Contact record.
• In the Household Account Model, contacts from the same household belong to the same account and can access to each others’ data in a community. Whether or not you want to allow this is a business decision (in some organizations it’s actually preferred). Just make sure you understand what the implications are though, and if you’d prefer to restrict this access, you can do it the same way we described for the Bucket Account Model above.

Use the Right Community License Type

Before you launch your community, check the documentation and thoroughly test each User or Profile to ensure they can only access the data you intended. Some Community License types, like Customer Community Plus Licenses, automatically grant access to certain records. For example, with Customer Community Plus Licenses, Case Sharing is turned on by default. This means that, if your organization was using cases prior to enabling Communities and you’re using this license type, then your users will be able to see all of the cases that they’re a contact on in Community Cloud. This can have privacy implications if a case has multiple contacts.  

For further reading, see:

• Salesforce Security Implementation Guide
• Lightning Communities Content Security Policy
• Trailhead: Share CRM Data with Partners

This blog is part of our larger “Ask an Architect” content series. To learn more about engaging a Salesforce.org Customer Success Architect in your organization, please contact your Account Executive.

About the Authors

Tom Leddy
Tom is a Senior Principal Customer Success Architect at Salesforce.org based in the Chicago area. He helps nonprofit and higher education organizations integrate Salesforce into their IT landscapes so they can serve their communities more effectively. He is also an author, public speaker, marathon runner and the president of Pawsitively Famous, Inc. You can connect with Tom on LinkedIn or Twitter.

Carlos Villalpando
Carlos is a Senior Manager Advisory Services at Salesforce.org based in the Twin Cities area. He has been working on IT strategy for the last several years architecting, developing and re-engineering processes to make them efficient and aligned with the business that they serve.