Change Intelligence is coming.

Get a First Look
  • Concept
  • Version · 1.0
  • Solution guides

Access controls & separation of duties best practices

Last updated: August 12, 2026

When preparing for SOC 2, SOX, HIPAA, or similar compliance audits, two requirements consistently come up: access controls and separation of duties. This guide explains what these mean for database change management and provides practical steps to demonstrate compliance. Organizations use Policy checks in conjunction with RBAC best practices to ensure that users only perform database changes appropriate for their role.

Why access control matters

Auditors want to ensure that your database changes undergo proper checks and balances. Common issues they flag include:

  • Developers who can deploy their own changes to production without approval

  • Missing documentation showing who approved the database changes

  • Shared credentials instead of individual user accounts

  • No clear separation between who creates changes and who deploys them

Resolving these issues before an audit helps you pass more quickly and enhances your overall security.

The core principle: No single person should be able to make a database change from start to finish without someone else reviewing it.

What this means for database changes

Developers can't approve their own changes. If you write a database migration script, someone else needs to review and approve it before it goes to production.

Developers can't deploy directly to production. Production changes should happen through automated pipelines or designated DBAs, not through individual connections.

Different people at different stages. The person who creates a change request shouldn't be the same person who approves it or deploys it.

Diagram showing four core best practices for access controls and separation of duties. First circle with lock icon: Principle of least privilege - Give people only the access they need to do their job and nothing more. Second circle with people icon: Role-Based Access - Developers can test in development/staging, but can't access production. Third circle with shield icon: Single Sign-On (SSO) and Multi-Factor Authentication (MFA) - SSO lets users access multiple applications with one set of credentials, while MFA requires users to verify their identity using two or more authentication methods. Fourth circle with grid icon: Separate Credentials - Use different database credentials for each environment, with production credentials tightly controlled.

Core best practices

Role-Based Access Control (RBAC)

The core principle: Assign permissions to roles (like "Developer" or "DBA"), then assign people to roles instead of managing permissions individually.

Liquibase Secure extends RBAC tooling by utilizing policy checks on top of traditional access controls. They act as guardrails, preventing authorized users from making risky changes even when they have technical access to do so. While RBAC answers "who can access the database," Liquibase Secure answers "who made a change, did it pass security policies, and can you prove it to an auditor?"

Common roles for database changes

  • Developer: Creates and tests database changes in non-production environments

  • Tech Lead: Reviews and approves changes from developers

  • DBA: Deploys approved changes to production

  • DevOps Engineer: Maintains CI/CD pipelines

  • Compliance Officer: Views audit logs and change history (read-only)

Why RBAC helps with audits: provides clear visibility into role permissions, ensures consistent access across users, simplifies onboarding through role assignment, and streamlines audit reviews of role definitions rather than individual permissions.

Common problems you'll want to avoid

  • Too many roles: Stick to 5-15 roles that cover your actual needs.

  • Role accumulation: Review access quarterly to remove old roles people don't need anymore.

  • Using RBAC alone: RBAC provides general access; you may still need additional controls for highly sensitive data.

Principle of least privilege

The core principle: Give people only the access they need to do their job and nothing more.

Why it matters

When users have more permissions than necessary:

  • Security breaches cause more damage

  • Compliance requirements aren't met

  • Auditors flag it as a finding

Who can have what access?

  • Developers should have full access to development/test databases, but no direct access to production

  • DBAs can access production, but through controlled processes with logging

  • Users only get access to specific Liquibase Secure features they need for their role

Diagram showing three key practices for implementing the principle of least privilege. First practice with lock icon - Use Secrets Management: Store database credentials in tools like HashiCorp Vault or AWS Secrets Manager instead of hardcoding them. These tools encrypt credentials, automatically rotate passwords, log who accesses what, and control who can retrieve credentials. Second practice with people icon - Connect to Your Identity Provider: Integrate Liquibase with your company's Single Sign-On (SSO) system. This ensures everyone uses their company credentials, multi-factor authentication is enforced, and access is automatically removed when people leave. Third practice with shield icon - Set Up Policy Checks: Use Liquibase Secure to automatically block risky changes like granting admin privileges without review, accessing tables with sensitive customer data, and creating new database users without approval.

Single Sign-On (SSO) and Multi-Factor Authentication (MFA)

Why SSO Matters

Single Sign-On connects all your tools to your company's identity system (like Okta, Azure AD, or Google Workspace). Benefits include:

SSO and MFA benefits: SSO provides centralized user management, automatic access removal upon departure, consistent security policies, and unified audit trails; MFA protects against compromised credentials, safeguards privileged accounts, meets compliance requirements, and mitigates insider threats.

Implementation Tips

  • Enforce MFA for everyone accessing database systems, not just admins

  • Use hardware keys for production access (like YubiKey) for the strongest security

  • Monitor authentication logs for suspicious patterns like failed login attempts or logins from unusual locations

Individual User Accounts - No Shared Credentials

The rule: Every person needs their own unique account. No sharing passwords.

Why Shared Accounts Fail Audits

  • No accountability: Can't tell who did what

  • Can't remove access selectively: If one person leaves, you have to change the password for everyone

  • Compliance violation: Every compliance framework prohibits shared accounts

How to implement individual user accounts: Onboarding: Create individual accounts when people join Role changes: Update access when people change teams Offboarding: Disable accounts immediately when people leave Regular reviews: Quarterly check that everyone still needs their current access

What This Means

  • Every team member has their own Liquibase Secure account with their own credentials.

  • Automated processes use service accounts (not shared user accounts)

  • Database connections use identifiable service accounts, not generic "liquibase_user" accounts

PreviousChange authorization best practicesNextDocument all database changes