Monopam · Database access

Production data,
without the shared password.

Database access management (DAM) the way your DBAs already work: they keep psql, DBeaver, and SSMS while Monopam brokers the connection — credentials injected from the vault, every statement policy-checked and audited, sensitive columns masked on the way out.

  • PostgreSQL · MySQL · MSSQL
  • SQL-level policy & audit
  • Dynamic data masking
What you get

The database is where the data lives. Guard the door.

Server PAM stops at the shell. Monopam continues into the wire protocol — so access to the data itself is brokered, filtered, masked, and attributable.

Their tools, your broker

DBAs connect with psql, DBeaver, or SSMS — straight to the Monopam proxy. The vault injects the real database credential; the user carries an opaque, short-lived handle.

  • Native clients: psql, DBeaver, SSMS, and more
  • PostgreSQL, MySQL, and MSSQL wire protocols
  • Real DB password injected by the proxy, never shown
  • Short-lived, per-session proxy secrets

Policy that reads the SQL

Rules evaluate the statement itself — commands, tables, patterns — and decide allow, block, or send to approval before the query reaches the database.

  • Command, table, and regex-based rules
  • Require-WHERE and max-rows guardrails
  • Work-hours and source-IP conditions
  • Allow / block / approval per rule, risk-tiered

Masking for the data you must protect

Dynamic data masking transforms sensitive columns on the way out — the DBA does their job, the customer data stays covered.

  • Dynamic masking with 8 transformer types
  • PII auto-detection on result sets
  • Turkish national ID, IBAN, and card transformers
  • Per-user, per-policy masking decisions

An audit trail at the SQL level

Regulators ask who ran what against production data. Monopam answers with the statement, the identity, and the timestamp — for years, not weeks.

  • SQL command-level audit logging
  • Sessions tied to the human, not the shared account
  • Long-term retention for banking-grade audits
  • One trail across servers, clusters, and databases
How it works

Three steps to governed database access.

01

Vault the accounts

Database credentials move into the vault with rotation. Shared DBA passwords stop circulating.

02

Write SQL policy

Decide which statements run, which need approval, and which columns leave masked — per user, per database.

03

Broker every query

Users connect through the proxy with their own tools. Every statement is evaluated, audited, and attributable.

Ready to start managing
identities the right way?

Spin up a fully-loaded trial tenant in under five minutes. No credit card. No sales gate.