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.
The risk of not knowing
If it is not surfaced today, it is exposed today. Attackers do not wait for your quarterly review — and neither do auditors.
The mechanism, not the marketing
- 1
Every database resource is discovered across AWS, Azure, GCP, OCI, IBM Cloud, Alibaba and Kubernetes through read-only APIs.
- 2
Cloud-level posture is evaluated against 310 storage and database rules — encryption at rest and in transit, public accessibility, backup retention, deletion protection, and audit configuration.
- 3
Engine-level hardening is evaluated against CIS benchmarks for the database software itself: PostgreSQL, MySQL, MariaDB, MSSQL, Oracle, IBM Db2, MongoDB and Cassandra.
- 4
Database findings are joined with data classification from DSPM, so a misconfiguration on a store holding PII is ranked above the same misconfiguration on a scratch database.
- 5
Identity context from CIEM shows which principals can actually connect, read, snapshot, or delete each database.
Specific outputs, measurable outcomes
Database Security in the real console.
Not a mockup — the actual Onam console on a live demo account, showing exactly what your team sees.
Questions we get a lot
Ready to see Database Security in your cloud?
Connect a read-only role in three minutes. Your first findings surface in under five.