Are your databases encrypted, private, audited, and backed up?
Database security for managed and self-hosted databases, checked against 310 posture rules and CIS engine benchmarks.
Database Security evaluates every managed and self-hosted database across your estate (RDS, Aurora, Azure SQL, Cloud SQL, DynamoDB, Redshift, OCI DB Systems and more) against 310 storage and database posture rules, plus CIS benchmarks for the database engines themselves.
- posture rules
- 9,853
- cloud providers
- 7
- cloud services
- 549
- compliance frameworks
- 78
Nobody intends to leave a database public.
It happens because a read replica inherits a subnet group nobody reviewed, or a snapshot gets shared to make a staging refresh easier and never gets unshared, or audit logging was on in the original instance but not the one restored from backup. Each step was reasonable. The result is a production database with customer data and a path in from the internet.
How Database Security works
- 01
Every database resource is discovered across AWS, Azure, GCP, OCI, IBM Cloud, Alibaba and Kubernetes through read-only APIs.
- 02
Cloud-level posture is evaluated against 310 storage and database rules covering encryption at rest and in transit, public accessibility, backup retention, deletion protection, and audit configuration.
- 03
Engine-level hardening is evaluated against CIS benchmarks for the database software itself: PostgreSQL, MySQL, MariaDB, MSSQL, Oracle, IBM Db2, MongoDB and Cassandra.
- 04
Database findings are joined with the labels DSPM assigns from metadata, so a public or unencrypted database labelled as holding PII is raised to critical, above the same misconfiguration on a scratch database.
- 05
Each database gets a posture score across six domains (access control, encryption, network, audit logging, backup and recovery, and configuration), so the weakest area is visible at a glance.
What you see in the console
- Complete database inventory
- managed services and self-hosted engines
- Encryption coverage at rest and in transit, per instance
- Public accessibility and network exposure detection
- Snapshot and backup exposure, including snapshots shared outside your account
- Audit logging configuration against CIS engine benchmarks
- Backup retention and point-in-time recovery compliance
- Privileged database account and grant review
- Sensitivity-weighted ranking
- databases holding regulated data ranked first
Database Security in the real console.
A recreation of the Onam console with sample data — the screens and finding types your team works with.
DSPM, Database Security and Encryption share one scan
They answer different questions about the same data. DSPM decides what is sensitive; the other two use that label to rank what they find.
What data do we hold, where, and how exposed is it?
- Covers:
- Every kind of store: buckets, databases, warehouses, streams, Kubernetes secrets.
- Gives you:
- Labels (PII, PHI, PCI, financial, confidential), public and cross-account exposure, lineage.
Is each database hardened, private, audited and backed up?
- Covers:
- Managed and self-hosted databases, down to CIS benchmarks for the engine itself.
- Gives you:
- A six-domain posture score per database, ranked higher where DSPM found sensitive data.
Is it encrypted, with a key we control, and who does the key let in?
- Covers:
- KMS keys, vaults, certificates and secrets managers across every cloud.
- Gives you:
- Coverage, key-policy reach, rotation and drift — and sensitive stores on weak keys.
How the labels pass between them is set out in the DSPM documentation.
Questions we get a lot
See Database Security on your own cloud
Book a 30-minute demo. We walk through it on sample data, or on one of your accounts if you want to connect it.