This post was written for Salesforce Marketing Cloud Admins and developers who want to learn how to leverage Salesforce Marketing Cloud (SFMC) while keeping their instance safe. In this blog, we cover three common mistakes SFMC professionals make when it comes to security. Continue reading to understand how to avoid these pitfalls and keep your SFMC instance secure.
Salesforce Marketing Cloud
Before we dive into best practices, let’s look at what the Salesforce Marketing Cloud (SFMC) has to offer. SFMC is a powerful marketing automation platform. Highly customizable, SFMC doesn’t make assumptions about your use cases, data structure, or your MarTech stack. Out of the box, it is essentially a blank slate that can be designed to meet an organization’s specific needs. From storing sophisticated data structures in Data Extensions to developing custom Journey Builder activities, SFMC can handle almost every use case imaginable.
Unlike Sales Cloud, in SFMC, there are no sandboxes. Some organizations have access to a demo account or testing business unit. However, most SFMC professionals and users are learning and testing in a production environment. This is important because often, SFMC Admins don’t consider that making changes in a production environment can lead to an increase in security vulnerabilities.
User Permissions: Too Many Administrators
In Marketing Cloud, Admins can set very specific permissions on a per-user basis. However, the granularity available can be overwhelming. As a result, it’s common for the majority of users in an SFMC account to have Admin access. While it might save a few minutes when creating a new user account, granting Admin access broadly is not best practice.
If a user has Admin access, it means they can export customer data, alter data extensions, and access Installed Package credentials. They can even install their own packages, which is difficult to detect in SFMC and can easily go unnoticed. Here are two best practices to follow for a secure SFMC instance:
- Limit users with Admin access to 2 – 3 at the most, depending on the business case.
- Assign the appropriate Roles and Permissions to other users based on their responsibilities.
If the predefined Roles in SFMC don’t provide the access required, leverage custom roles to fit your users’ needs better.
Limit API Users
An API User is most frequently used to integrate SFMC with Sales or Service Cloud via Marketing Cloud Connect. When creating or editing users in Marketing Cloud, there is an “API User” checkbox option. As a best practice, both users and API Users in SFMC should not have this option enabled. This is a legacy HTTP Basic Authentication option that has since been replaced with OAuth 2.0 and can only be used with the Marketing Cloud SOAP API.
If you do need to create an API user for an integration, there may be select cases when the “API User” checkbox needs to be enabled. However, in general, all API access should instead be authenticated through OAuth2 (not by username/password). Only enable the “API User” setting for users in SFMC when absolutely necessary.
When creating an API User, they should also, whenever possible, be a Dedicated Integration User and not an actual user account. For more information on why this is important from a Sales Cloud perspective, read: Why You Need A Dedicated Salesforce Integration User.
Limiting the number of Admins and API users will ensure users can’t gain API access they should not have. This is important for two reasons. One, a user can knowingly exploit their API access. And two, security vulnerabilities and data loss can occur when users don’t fully understand the level of access they have.
How to Manage Installed Packages Securely
Marketing Cloud Packages are used to create API integrations, install custom apps, and add custom Journey Builder or Content Builder components. Each individual Installed Package has its own set of credentials and permission scope. While experimenting with and learning how to use the API, SFMC Admins will often quickly create new Installed Packages on the fly to test their integrations. As a result, these, often abandoned packages, are created with a very broad scope of permissions.
As mentioned previously, an SFMC Admin has access to all Installed Package credentials. The combination of having Admin access and having a broad permission scope of an Installed Package is particularly dangerous because it provides the credentials for access to your Marketing Cloud instance via the API.
Installed Package credentials are not tied to a specific user account. Which means, a former employee or contractor can retain back-door access to the SFMC account even after their user account has been disabled (S/O to Salesforce MVP Eliot Harper for sharing this). This is a security risk that many Admins overlook if they are only checking that all former employee user accounts are disabled. To prevent this from happening, do the following:
- Ensure that only essential users have access to Installed Packages.
- Only grant the required permission scope to Installed Packages.
- Regularly check for and remove Installed Packages that are no longer in use, or were used for testing.
Wrap Up
We hope you found this post valuable and are leaving with actionable insight on how to make your SFMC instance more secure. If you have questions about Salesforce Marketing Cloud, please reach out today!
Also, if you enjoyed this blog, you may like our free guide on How to Leverage the RFM Model to Drive your Marketing Cloud Strategy.
