Automating Sod
Automating SoD splits critical tasks between two or more people using system rules. You set up these rules so one user cannot both write and approve changes. Many teams start by grouping users into fixed identity roles across cloud accounts. They give developers read rights and give admins write rights on live databases. This basic setup breaks down when on-call engineers need fast fixes during outages. Teams often grant broad admin roles to save time during a crisis. Once one person holds that
Sod: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
Automating SoD splits critical tasks between two or more people using system rules. You set up these rules so one user cannot both write and approve changes. Many teams start by grouping users into fixed identity roles across cloud accounts. They give developers read rights and give admins write rights on live databases. This basic setup breaks down when on-call engineers need fast fixes during outages. Teams often grant broad admin roles to save time during a crisis. Once one person holds that broad role, the split between duties disappears.
How automating SoD works in native tools
Native platforms handle automating SoD through role bindings and group rules. First, you list every sensitive action inside your cloud or database system. Next, you split those actions into separate roles that do not overlap. One role lets an engineer draft a change or build a deployment package. A second role lets a reviewer approve and run that package in production. You then link your identity provider to check group memberships at login. If a user belongs to the builder group, the system blocks reviewer permissions. Some teams also run daily scripts to scan identity lists for toxic combinations. When the script finds a user in both groups, it alerts security teams. The security team then removes the extra role by hand or through tickets.
What identity roles solve and what they miss
Role rules work well for controlling who can log in to a system. They stop a junior developer from opening a production database console by mistake. They also give auditors a clean list of user groups to review quarterly. Still, login checks cannot see what an admin runs after opening a session. A database admin with write permissions can alter tables or read sensitive rows. The native role grants full session power once the login check passes. It does not require a second person to check each query in flight. Also, shared database users bypass group rules because everyone uses the same login. If five engineers share one admin login, you lose track of individual actions. If an admin reads raw customer rows, emails and card numbers appear in results. Role checks alone cannot rewrite those fields or pause a risky drop command.
Why manual ticket reviews create permission creep
To fill this gap, many teams put ticket queues in front of databases. An engineer files a ticket asking for temporary write permissions on a host. A manager reads the ticket and clicks approve inside the tracking tool. Then an automated script adds the engineer to the admin group for hours. This workflow slows down daily work and creates review fatigue for busy managers. Managers start approving every request because they lack context on the exact command. Over time, scripts fail to revoke roles, leaving engineers with standing admin rights. True separation requires checking the exact command or query before it runs. When one engineer sends a query and another approves that exact statement, risk drops.
Sod: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What does separation of duties mean for engineering teams?
It means splitting high-risk tasks so one person cannot make unapproved changes alone. One engineer proposes a command or query, and a second person approves it.
Why do static cloud roles fail separation checks during incidents?
On-call responders often need broad admin rights to fix broken production services fast. Once granted, a static role lets that responder run any command without peer review.
How does data masking support separation of duties?
Masking rewrites matched fields like phone numbers or national IDs in query results. This lets engineers fix database issues while keeping sensitive customer fields hidden.