Database change is gated by a stack of security tools. Bastion for connections. ITSM for approval. PAM for credentials. Each layer adds a control. Each adds a tool to maintain.
The stack leaves one gap — at execution, where approval, credential, and SQL meet without a system tying them together. This post walks the layers, names the gap, and shows what an integrated platform replaces.
For the automation-depth lens — how much of the change lifecycle runs without a human — see The 6 Levels of Database Automation.
Bastion / Jump Server
| Tool category | Examples |
|---|---|
| Bastion / Jump server | AWS Bastion Host, Azure Bastion, Teleport |
A bastion is a gateway between users and database servers. Connections are restricted to a known network path. Session activity is logged. Execution happens inside a controlled environment.
What it gates: network access. Every connection is identified and recorded.
Where it stops short: the bastion sees a connection, not a change. SQL is typed by hand. No review. No approval. No structured audit of what ran.
ITSM and CAB
| Tool category | Examples |
|---|---|
| ITSM | ServiceNow, Atlassian Jira, Freshworks |
| Change Advisory Board (CAB) | Usually piggybacked on the ITSM workflow |
ITSM formalizes the change request: who proposes, what runs, who approves. The CAB adds human governance — a cross-functional group that evaluates risk before sign-off.
What it gates: decision authority. No change proceeds without a recorded approval. The trail satisfies most compliance frameworks.
Where it stops short: approval is decoupled from execution. The CAB approves a script in a ticket; nothing prevents a different script from being run. And the workflow is slow for routine changes that don't warrant a CAB.
PAM (Privileged Access Management)
| Tool category | Examples |
|---|---|
| PAM | CyberArk, BeyondTrust, HashiCorp Vault |
PAM tools control how database credentials reach humans. Credentials are vaulted. Checkouts are time-bound. Every checkout is logged.
What it gates: credential exposure. No long-lived database password lives on a developer's disk. Access is requested, granted, revoked.
Where it stops short: PAM sees the credential, not the SQL. Once a developer holds it in a client, PAM has no view of what runs.
The stack in practice
With all three layers in place, a change runs like this:
- Developer files a change request in ITSM with the SQL attached.
- CAB reviews. CAB approves.
- Developer checks out credentials from PAM.
- Developer connects via the bastion and runs the SQL.
Three tools. Four hand-offs. One gap: the SQL that runs is not necessarily the SQL that was approved. The CAB approved a script in a ticket. The bastion saw a connection. PAM saw a credential checkout. Nothing tied them together at execution.
Other gaps the stack leaves open:
- No pre-execution validation. Schema checks and dry runs happen by hand, if at all.
- No rollback. DDL and DML aren't versioned; recovery means restoring from backup.
- No unified audit. The trail is split across three tools. None sees the full picture.
What an integrated platform replaces
An integrated database change platform consolidates the stack. One tool replaces three. Approval, credential, and execution share the same record.
How Bytebase maps to each layer:
- Bastion replaced. Connections happen through Bytebase's web UI. No direct database connection from a developer's laptop. No separate jump server to maintain.
- ITSM replaced. Change requests, approvals, and audit live in Bytebase. Existing ITSM (ServiceNow, Jira) plugs in when the ticket is the system of record.
- PAM replaced. Bytebase holds database credentials. Developers never see them. IAM authentication and secrets manager integration cover external-vault cases.
- Execution gap closed. Approval, validation, execution, and audit tie to the same record. The SQL that runs is the SQL that was approved. SQL review catches issues before deployment. 1-click rollback handles recovery.
Comparison
| Approach | Gates | Audit trail | Tools to maintain |
|---|---|---|---|
| Bastion / Jump Server | Network access | Session logs | 1 |
| ITSM + CAB | Decision authority | Ticket history | 1 |
| PAM | Credential exposure | Checkout logs | 1 |
| Stacked (all three) | Each layer separately | Fragmented across tools | 3+ |
| Integrated platform | All layers, tied at execution | Single, queryable trail | 1 |
The stack works. Bastion, ITSM, and PAM each gate a distinct risk. But it pushes integration onto the team — three tools to maintain, three audit trails to correlate, one gap at execution. An integrated platform owns all three layers and closes the gap.