Skip to content

Roles and separation of duties

Edition: Community and Enterprise

sealfix has five built-in roles. An administrator gives them to groups from your directory, everywhere or for one project (a group of target databases).

Role Typical people Does
Requester Developers, operations Writes fixes, submits values, executes approved fixes, asks for rollbacks
DBA reviewer Database administrators Gives the technical approval: the SQL, the dry run, the plans
Business approver Business operations, product owners Gives the business approval on masked values
Auditor Internal audit, compliance, security Reads every request and the audit log; changes nothing
Administrator Information security, IT platform Sets sealfix up; never approves

The rules no configuration can switch off

flowchart TB
    R1["The requester never approves<br/>their own request"]
    R2["One person approves<br/>a request once"]
    R3["Every execution needs<br/>a technical approval"]
    R4["An administrator never<br/>holds an approving role"]
    classDef rule fill:#DCE3EE,stroke:#13202D,stroke-width:2px,color:#13202D
    class R1,R2,R3,R4 rule
  • The requester never approves their own request, in any role they hold.
  • One person approves a request once. Someone who holds both approving roles gives one approval per revision. While a technical approval is still needed, they count as the technical reviewer and are never shown the values.
  • Every execution needs a technical approval, whatever the policy or the risk rules say. So together with the first rule, nothing runs without someone other than the requester.
  • An administrator never holds an approving role. sealfix refuses a binding that would give one person both, or let anyone change their own access.

Projects

Projects group targets. A DBA bound to the cards project reviews the cards databases only and sees no other requests. Everything starts in the default project.

Choosing who is who

  • Give administration to information security or the IT platform team: people who run systems, not people who change data.
  • Give business approval to the people who own the business process, scoped to their project.
  • Keep auditors outside every team they audit.