If your company is like most enterprises, you have a lot invested in your Salesforce. The platform makes it easy to customize your experience of Salesforce, but that also means you have to make constant enhancements to adjust the tools to your business processes. In systems of engagement, this can mean multiple times a day. Like the Moon Shot of 50 years ago, you have to get it right day after day and hour after hour. Unlike Apollo 11, your mission does not end after a week.
Security breaches have been in the news quite often recently. The Capital One hack was a typical example of how strong technology can be rendered useless if configured incorrectly. It is up to you and your team to ensure that the systems you rely on are set up properly, especially true of customer facing systems like Salesforce.
Getting the most out of your investment is a multifaceted job. In this article we focus on aspects related to the intersection of DevOps and Security, known as DevSecOps.
What is DevSecOps?
In the world of Salesforce, security is mostly managed through Profiles, Permission Sets, and Sharing Rules. These entities control:
- Access to the Service (Admin permissions and Login), and
- Access to Data at the Object, Field, and Record level
This type of security is important, but is not the full extent of what it takes to protect your investment. You also need to protect your Data, Settings, and Source Code from accidental overwrites and deletion. In fact, it is not simply a matter of being able to recover from these incidents – the time required to fully restore the lost items is important as well.
In this article we will look at 6 key elements that impact your DevSecOps practice on Salesforce with best practice recommendations for each.
#1: Single Source of Truth
Establishing a Single Source of Truth (SSoT) in other platforms is fairly obvious, but it is not so in Salesforce where changes can be made in Production and Sandbox environments in the blink of an eye.
Why is this important for DevSecOps? It’s all about lost work. Changes made in Production or Test can be wiped out easily by the next deployment. If changes are made strictly in Development environments and saved in a version control system like Git, the chances of overwrite are reduced. This allows both Admins and Developers to use the same source of truth to capture changes. It is also the first step in our next topic: Audit Trail.
#2: Audit Trail
When it comes to compliance and security, it is not just a matter of ensuring that you are making the right changes. Often you must be able to prove you did the right thing and prove the wrong thing was never done. That’s where the audit trail comes in.
Simply stated, an audit trail answers the following questions:
- Who made the Change?
- When was it made?
- What was changed?
- Why was the change made.
Establishing a Git Repo as the SSoT gives you a head start. It captures all of the changes to your Settings and Code. It can even be used to capture your configuration data changes, which is important for applications like CPQ. Capturing changes in Salesforce goes one step further and creates an audit record which is reportable using Salesforce standard reports.
Copado recommends User Stories as the unit of release for change management. The benefit to your Audit Trail is that User Stories not only capture the Who, What, and When, but also capture the Why. This is not typically done in a Git Repo.
#3: Quality Gates
Protecting your Salesforce Investment means protecting all of the functional enhancements that you have achieved to date. Some organizations have devoted thousands of person-hours worth of work to get their existing implementation working the way they want it. One wrong change can undo much of that investment. Quality gates are not just about ensuring the new features work as expected, but also to ensure that new features do not break the old.
Functional testing is the aspect of quality that ensures features work as expected. Selenium, Provar, and Fusion are tools that can help with that verification.
Source Code Quality is often overlooked. Why should you care if the source code is written according to some style guidelines? It’s like maintaining proper diet and exercise. Eating junk and skipping the gym for a few days won’t kill you right away, but long term watch out. Enterprise software development is a team sport. Writing code against a corporate style standard ensures that the next developer to work on it will understand what she sees. Static Code Analysis can do much more than enforce style however. It can discover bad practices like DML inside nested loops which impact performance of the code and can result in hitting Apex Limits on the Salesforce platform.
Unit tests are an easy way to ensure that code is working as expected. Apex Test Coverage may seem like a pain, but maintaining minimal coverage will pay off in the long run if engineers truly embrace the practise and do not try to game the system.
#4: Compliance
Automated compliance scans and monitoring is not widely used in the Salesforce world, but they should be.
Compliance scans are able to ensure that the following types of changes do not open up security holes in your Salesforce service:
- System Access Controls – IP Ranges, Login Hours
- Data Access Controls – Object & Field Level Security
- Record Access Controls – Sharing Rules
The key here is to ensure Least Privileged Access, meaning no single user has access to information they do not need to do their job. This is a difficult thing to do and is often inconvenient, but the consequences are often more … inconvenient.
A good compliance system can alert as well as prevent deployments that violate the rules. It can also be tuned to provide appropriate levels of control in each stage of the development pipeline. Creating a complete set of rules for your organization will take time, but it is an investment that may save your organization from the hundred million dollar fines experienced recently by Capital One, British Airways, and Marriott.
#5: Backups
Most organizations think of Backups as protecting Data. In Salesforce, protecting your Metadata is just as important. A recent issue with the loss of Profiles shone a spotlight on this. Many organizations were not prepared to restore the latest Profiles for all users simply because they did not have a saved copy of the latest profiles for all users. So back up not only your Data, but your Code and Configurations as well.
How often should you back up? The short answer for your Metadata is that you should put a release process in place that captures every change as it happens in every environment. Using Git as an SSoT with changes tied to User Stories will provide the necessary backups for Rollback and Restore.
Data Backups are more challenging due to the sheer size of the datasets involved. Taking a point in time snapshot is useful but not practical on an ongoing basis. Select a backup tool that can do continuous incremental backups and that easily enables you to restore your org to a point in time using those records.
#6: Promotion vs. Monitoring
The final thing to consider for your plan is the balance of performing tests during the Promotion of a change from one environment to another, versus scanning the entire environment on every change. Running all Apex tests and functional tests can take hours in an Enterprise environment. In a continuous delivery world where changes hit an environment multiple times an hour, a full test run would no sooner get started than it would have to start again due to another change.
In this scenario, companies are better off running tests scoped to the individual changes during promotion, and run environment-wide tests on a scheduled basis. In the best of all possible worlds, your DevOps tools could identify the scope of impact and perform only the tests required. The industry is not quite there yet, but stay tuned.
Summary
Protecting your Salesforce Investment is important, but like most security-related goals, it is at best a work in progress. You may never be done, but that does not mean you shouldn’t start. Take a step back and think through your priorities. If you work for a Financial Services or Health Care company, your data access controls may be your number one priority. For other companies, business continuity may be paramount. Whatever your situation, put together a prioritized plan and get started. Automate what you can and use approval processes where you can’t. Then get started. Slow and steady may not win the race, but it could certainly minimize your losses. Just ask Capital One.