.svg){kind=small}
.svg)
.avif)
.avif)
.avif)
Security & Governance
Language
Articles
8/12/2022
10 minutes
Salesforce Data Security Best Practices for Low-Code Development
.svg)
.svg)
Low-code development is a high-agility, democratized process. But although the process is agile, it should never be chaotic. Low-code development should facilitate innovation and speed — but never put quality or security at risk.
Today, we’ll outline some key Salesforce data security best practices. Salesforce already has strict security controls and compliance measures, but organizations still have to maintain their DevSecOps and CI/CD processes internally.
In a low-code environment, issues of security and compliance must be strictly enforced at all levels. While developers need to move their commits through the pipeline quickly, they also need to test, validate, and control them. Follow these best practices for scalability at speed.
An end-to-end platform naturally protects your organization’s data from infiltration — while also boosting efficiency. Most organizations find that their vulnerabilities crop up when their data is incorrectly transferred from system to system, or by using third-party applications or APIs that have vulnerabilities.
Salesforce’s end-to-end low-code development platform maintains data security and integrity within a single, consolidated system.
Defining clear policies is the first step to ensuring that data is handled securely in a low-code environment. Organizations should determine who needs access to which data, and under what circumstances. They should also put procedures in place for managing and securing that data.
Organizations should use role-based access controls (RBAC) to restrict data access to only authorized users. RBAC can help organizations granularly control who has access to which data, and under what circumstances. Marry this to a system of “least privilege,” under which individuals only have access to the systems they absolutely need to access.
Below, you can see that CSRs can read, create, and edit accounts—but they can’t delete them. While they can use the price book, they can’t edit them. They can modify anything on their calendar, but they can’t do anything but read their user data.
Customer Sales Representative
Read
Create
Edit
Delete
Accounts
✔️
✔️
✔️
❌
Assets
✔️
✔️
✔️
❌
Campaigns
✔️
✔️
✔️
❌
Users
✔️
❌
❌
❌
Price Book
✔️
❌
❌
❌
Calendar
✔️
✔️
✔️
❌
Data encryption is a critical security control for protecting data at rest and in transit. Organizations should encrypt all sensitive data, including personally identifiable information, and protected health information. Further, companies must store comprehensive audit logs and traceable metadata—information regarding the changes made to the data while protected within the system.
Salesforce comes with built-in encryption for privileged data. But it’s not enough to rely on Salesforce’s internal encryption. Any data external to Salesforce must also be encrypted, and any platform interacting with Salesforce must enforce encryption standards.
Organizations should monitor and audit data usage regularly. They should also put mechanisms in place to detect and investigate unauthorized access. Frequently, vulnerabilities are introduced through third-party systems like APIs.
If the initial vulnerability is not caught, the company must be ready to catch the results — such as privileged data being accessed when it shouldn’t be.
Your entire team needs to be educated on proper data security practices in a cross-functional, low-code development team. This education never ends. As new tools and processes are introduced, your team needs to update their usage.
Salesforce sandboxes isolate potentially breaking changes until they can be thoroughly tested. Organizations can quickly test new commits by isolating instances without putting the rest of their system at risk.
Use a system of automated checks, balances, and testing to plan for human error. Employees will make mistakes. Developers will cause vulnerabilities. Ideally, your system should support your human staff through automation and testing — which will identify vulnerabilities not otherwise caught.
The DevSecOps (and broader DevOps) philosophy is designed, at its heart, to protect product quality. Security is a part of this. You can further improve security without sacrificing innovation by developing your DevOps processes.
Platforms like Salesforce offer strict security controls and a commitment to customer privacy. But low-code platforms built on Salesforce shouldn’t rely solely on Salesforce’s native security measures — they need to maintain their own DevSecOps.
There are many ways low-code platforms can show their commitment to security:
Rather than relying upon Salesforce’s security, the Copado platform works to create a complete DevSecOps infrastructure from the ground up — building layers of security on top of Salesforce’s already industry-leading controls.
Still, no matter how secure a low-code platform is, your organization is only as secure as your weakest link. A low-code development team needs to be just as diligent about security and compliance as any other software development team.
In a low-code environment, security and compliance must be strictly enforced at all levels. Boost your low-code security through better policies and better controls. Pay careful attention to data privacy, access controls, and user education.
Copado is a complete, end-to-end DevOps solution built for Salesforce and security. Our 5 Steps to DevOps Success acknowledges that you need to secure your product and its quality before you can start to innovate.
Copado helps dev teams build and test applications quickly and efficiently while still ensuring compliance with corporate security policies and data governance.
With Copado, you can:
Don’t build your organization’s technology on anything but the best.
Level up your Salesforce DevOps skills with our resource library.
.svg)
.svg)
.svg)