←  Back to DBSheriff ◆  Security & Architecture

How DBSheriff is
built secure.

Written for the people who have to answer for this decision: security engineers, architects, and auditors evaluating whether a database threat-detection product can itself be trusted with a privileged view into your data estate. This is the engineering substance behind the trust claims — not a marketing summary of them.

Design principle

You are not adding
a new attack surface

The core design constraint, stated plainly: DBSheriff must reduce your risk, not add to it. Every architectural decision below traces back to that constraint.

🔒
Nothing leaves your network
Every component runs inside infrastructure you control. No outbound telemetry, no cloud dashboard, no vendor API that your query data or credentials pass through.
👁
Out-of-band, not in-line
DBSheriff reads from each engine's own monitoring and audit interfaces. It is never a proxy in your application's connection path — if DBSheriff stops running, your databases keep serving traffic exactly as before.
🔑
Least privilege by construction
Each function — monitoring, termination, account locking, classification — uses its own narrowly-scoped credential. There is no single "DBSheriff superuser" account on any monitored database.
📋
Every action is opt-in and reversible
Enforcement (terminate, revoke, lock) is a switch your team turns on per server. Nothing acts on your data, roles, or settings until you explicitly enable it — and every action taken is logged and reversible.
Network & deployment architecture

Runs inside your perimeter.
Not the other way around.

DBSheriff is a set of containers on a single Linux host that you provision and control — on-premises, or a VM inside your own AWS, GCP, or Azure account. There is no multi-tenant DBSheriff cloud service in the data path at all.

⚠  What this means for compliance scope

Because query text, identities, schema names, and event records never leave your perimeter, DBSheriff does not become a data processor under GDPR, does not require a HIPAA Business Associate Agreement, and does not expand PCI-DSS network scope. These are direct, structural consequences of the architecture, not a policy promise layered on top of it.

Credential handling

Narrow, purpose-built
service accounts — never one superuser

On every monitored database, DBSheriff uses several distinct credentials, each scoped to exactly what its job requires, rather than one broad administrative login.

FunctionTypical scope
MonitoringRead access to the engine's own monitoring/audit views only. On most engines, this credential cannot read the contents of your actual data tables — it observes query metadata, not query results.
TerminationJust enough privilege to cancel or terminate a specific running statement or session — not general administrative rights.
Account lockingJust enough privilege to disable a login and restore it — a separate, narrower credential than the one used for termination.
Classification & posture scanningRead access scoped to what's needed to sample table/column metadata and check configuration — not a standing grant to read sensitive rows.

Where a platform supports it, DBSheriff uses key-pair or token-based authentication in preference to a static password. Every stored credential is encrypted at rest using industry-standard symmetric encryption, decrypted only in-memory at the moment it's needed, and never logged or written to disk in plaintext.

Data handling

Captured statement text is scanned and redacted for embedded secrets — passwords, tokens, connection strings that happen to appear inline in a query — before it is ever written to DBSheriff's own audit storage. What's stored is evidence for your team, not a second place your secrets can leak from.

Integrity & audit trail

An audit trail
even an administrator can't quietly edit

A security product's own evidence is only as good as your ability to trust it hasn't been tampered with. DBSheriff's decision records — every kill, every lock, every posture finding — are written to database tables with append-only enforcement at the storage layer itself, not just as an application-level convention.

Secure release process

What you install
is what was actually reviewed

Common questions

Questions a security review
usually asks first

Does DBSheriff ever read the actual contents of our sensitive data?
The monitoring credential used for real-time detection observes query metadata — who ran what, against which table, for how long — not the result rows themselves, on most engines. Data classification uses cheap, bounded sampling (never a full table read) specifically to propose what's sensitive, and that sampling is scoped to a separate, dedicated credential you approve.
What happens to our databases if the DBSheriff host goes down or is compromised?
Your databases are unaffected either way. DBSheriff is out-of-band: it is not a proxy or driver in your application's connection path, so its own availability has no bearing on your database's availability. A compromised host would, at worst, expose the narrowly-scoped credentials DBSheriff itself holds — which is exactly why those credentials are deliberately minimal rather than broad, and why enforcement actions are opt-in and fully audited.
Is the detection model shared across your customers?
No. The behavioral model is trained on and runs against your own historical traffic inside your own deployment. There is no shared, cross-customer model, and no mechanism by which one customer's query patterns could influence another's baseline.
How do we know a kill or lock action actually happened, and wasn't just logged?
Every automatic action is independently re-verified against the database engine's own state before being reported as successful — DBSheriff checks that a terminated session is actually gone, not just that a termination command was sent. That verification, and the original decision, are both part of the same immutable audit record.
Can DBSheriff make a change to our environment we didn't approve?
No. Detection and scoring always run. Enforcement — terminating a query, revoking access, locking an account — is a setting your team explicitly enables per server. New installations start in detect-only mode by design, so you see exactly what DBSheriff would have done before it's ever allowed to do it.
How does this fit our existing compliance program?
Findings are mapped to PCI DSS 4.0, SOC 2, NIST 800-53, and the relevant CIS benchmark for each engine, with the exact query or check that established each result. Because no data leaves your perimeter, DBSheriff does not expand the scope of any of these programs the way a SaaS monitoring tool typically would.
Responsible disclosure

Found something?
Tell us directly.

If you find a security issue in DBSheriff, we want to know before anyone else does. Report it to info@sunaidata.com with as much detail as you can provide. We take every report seriously, will work with you to understand and reproduce the issue, and will keep you informed as we address it. Please give us a reasonable window to fix a genuine issue before any public disclosure.

Talk to an engineer, not a sales deck

We'll walk your security team through the architecture against your actual environment and answer what's specific to your review.

Request a Technical Review → See What It Detects →