Building Secure and Compliant SaaS Apps – Identity Security Best Practices

Originally published by CyberArk.

Written by Sam Flaster.

Do you need to secure high-risk access to the back end of your customer-facing apps? Yes, you do – assuming you care about cybersecurity risk, uptime or compliance with SOC II and NIST and AWS, Azure and GCP architecture frameworks.

To meet compliance requirements and grow your business, you must properly secure access to the cloud services and workloads powering your SaaS app. No matter the size and scale of your cloud-hosted app, addressing identity security-related compliance requirements is a necessary step to grow your business – especially when working with customers in highly regulated industries.

Sensitive data is sensitive data. Auditors assessing compliance with SOC II, NIST and other compliance standards don’t care if organizations are lifting and shifting apps to VM workloads or building on containers and serverless functions. Auditors don’t care which cloud providers a dev team uses to build their apps. And auditors definitely don’t care about the cool microservices architectures, design assessments and sprint deadlines top of mind for your engineering teams.

Auditors only care that companies properly secure all identities accessing sensitive data in their applications.

Here’s the good news: several identity security and privileged access management (PAM) best practices can help organizations reduce risk and build SaaS apps that comply with SOC II, NIST and other standards.

The following are several of these proven best practices.

Implement Least Privilege

Compliance frameworks require organizations to adhere to the principle of least privilege (PoLP), a foundational cybersecurity concept. Frameworks differ in their terminology – SOC II has requirements for “logical access control,” for example, while the NIST Cybersecurity Framework explicitly uses the term “least privilege.” But make no mistake – to build compliant SaaS applications, organizations need to ensure all identities have the minimum necessary entitlements to perform their duties.

Organizations must, in the words of the AWS Well-Architected Framework, “Implement the principle of least privilege and enforce separation of duties with appropriate authorization for each interaction with your AWS resources.”

Identity security programs can meet these requirements by:

• Removing local administrator rights on developer endpoints, reducing the risk of credential theft.
• Onboarding local admin credentials to PAM solutions for automatic rotation and role-based access control, further reducing the risk of stolen credentials.
• Reducing excessive permissions in multi-cloud environments with Cloud Infrastructure Entitlements Management (CIEM) CIEM is emerging as a core element of PAM programs that reduces the risk of lateral movement. This includes reviewing cloud IAM roles and removing access to protected information assets and services.

Aim for Zero Standing Privileges (ZSP) With All Operational Access

Once least privilege is in place, organizations must secure privileged access. To meet compliance, many organizations are embracing the emerging security philosophy of zero standing privileges (ZSP). This security principle’s methodologies build on the foundation of least privilege by elevating access just-in-time and minimizing the use of long-lived passwords and credentials to access cloud workloads and services.

Leading cloud service providers recommend using federated access models – not shared accounts – for access to workloads and services. Developers, site reliability engineers and data scientists are able to assume IAM roles without the use of standing credentials. As a result, most developer access can be considered operational; cloud users do not need persistent access to resources, they only need them for specific tasks.

Organizations can satisfy audit and compliance requirements for this operational access by embracing a ZSP approach. Key elements of ZSP include:

• Elevating console and CLI access to cloud services on a just-in-time basis, using roles scoped with the minimum necessary permissions for the task at hand. Examples include accessing CSP services to change networking, database and compute auto-scaling configurations.
• Elevating access to workloads running on the cloud on a just-in-time basis. Examples include operational access to Linux and Windows VMs for lift-and-shift apps, or Kubernetes and other containers for apps running cloud-native, microservices architectures.
• Integrating access request workflows with existing developer tools to avoid slowing velocity. Developers often need to request additional access to solve issues during outages or critical situations (aka critsits). Making it easy – and fully auditable – is essential for compliance.

Securely Manage and Rotate Credentials Used for Standing Access – Including Application Secrets

Even in the cloud, some long-lived, system-level access is inevitable. Common examples include the root and registration accounts required to establish a cloud footprint, DevOps secrets used by applications, service accounts and other machine identities – and administrative accounts for lift-and-shift software workloads running inside VMs, such as admin accounts for ERP, database or security systems.

Security and compliance strategies must account for the heightened risk these long-lived, system-level accounts represent. Long-established approaches to PAM and secrets management can help. Examples include:

• Discovering credentials used by administrators, service accounts and other identities and onboarding them to a PAM solution. This reduces the risk of credential theft.
• Centrally managing secrets used by developers, including through integration with CSP native secret stores. This approach to secrets management enables developers to use their preferred tools while enabling credential management and rotation that meets compliance objectives.
• Automatically rotating credentials at intervals aligned with organizational policy (which are often specified in compliance frameworks).
• Logging all usage of privileged accounts to deter insider threats. To maximize audit efficiency, centrally store audit trails for both sessions using shared privileged accounts or sessions using federated access with Zero Standing Privileges.
• Isolating usage of these accounts to prevent ransomware and other malware from reaching VMs and other cloud workloads.

Extend Identity Security to Your Third-Party Vendors

Internal employees aren’t the only human identities with access to the backend of your SaaS apps. Many organizations leverage remote, third-party vendors and contractors to set up or run the cloud workloads and services powering their apps.

Auditors assessing compliance with leading cybersecurity frameworks often zero in on this access. SOC II compliance in particular relies on specific requirements to manage remote access and all points of access to data. Organizations can demonstrate compliance with these requirements with familiar strategies. Examples include:

• Managing all points of remote access to data – for both internal and external identities like contract developers, IT contractors and other third-party vendors.
• Removing any standing privileged access for third-parties to cloud workloads and services. Excessive third-party access has been linked to several data breaches of cloud environments in recent years.
• Enforcing strong, biometric authentication on third-party access to the back end of SaaS apps.

Apply Strong Authentication and Monitoring for Defense-in-Depth

Access control is a powerful way to reduce risk. But embracing the Zero Trust paradigm requires organizations ‘never trust’ and ‘always verify’ access to their cloud environment.

This same Zero Trust philosophy can provide additional value to organizations as they strive to build secure, compliant applications. To strengthen compliance with SOC II and other frameworks, organizations should consider additional defense-in-depth controls such as:

• Enforcing strong, adaptive multi-factor authentication (MFA) and identity threat detection on all attempts to access the back end of SaaS apps. This should include authenticating third-party identities and applying controls like step-up and continuous authentication.
• Ensuring all machine-to-machine connections are authenticated.
• Monitoring all high-risk sessions to workloads and services, with full audit trails. To maximize insight, screen recording and video playback can help auditors and forensics teams streamline their tasks.
• Systematically reviewing and certifying access, removing entitlements to ensure access permissions align with job roles and responsibilities.
• Implementing capabilities to ensure prompt response to misuse of privileged accounts or any high-risk access.

These identity security best practices can strengthen your compliance initiatives. To learn more about building compliant SaaS apps, check out our whitepaper, “2024 Playbook: Identity Security and Cloud Compliance.”