DAC · Database-aware Security Gateway

The security gateway that understands databases deeply

The gateway parses the database wire protocol directly to decide who runs which statement on which database. It identifies the person even behind a shared account, masks personal data in query results and records everything. With the desktop agent, users keep the database tools and connection addresses they already use.

  • MySQL
  • MariaDB
  • PostgreSQL
  • Oracle
  • SQL Server

What is DAC (database access control)?

Database access control (DAC) is a category of security products that control and audit connections to databases from the middle of the path. Its core functions are user authentication, command control, masking and auditing.

BeeHind's DAC parses the database wire protocol directly. That lets it control SQL statements without changes to your databases or applications, and mask sensitive columns even when they hide behind aliases or functions.

Because it is an inline proxy that sits between clients and databases, it can reject connections, block statements and mask results, unlike monitoring-only approaches. Configure the database firewall to accept connections only from the gateway, and the gateway becomes the only way in.

Connection paths

Two paths, depending on who connects

Database tools on employee PCs connect through the desktop agent. Where the agent cannot be installed, clients connect with a connection address issued by an administrator. The same policies and audit apply to both paths.

Who connectsDesktop agentHow it reaches the gatewayHow the user is identified
Database tools on employee PCsRequiredThe agent intercepts the connection and sends it through an mTLS tunnelSigned identity assertion
Contractor PCs, BI toolsNot requiredConnects directly with an issued connection addressName assigned to the address and allowed IP range
Batch serversNot requiredConnects directly with an issued connection addressAllowed IP range

With the agent, you enter the real database address and your usual database account in your database tool. Interception turns on automatically when you sign in to the agent.

Control

Decisions at every step, from connection to statement

Connections without a matching rule are rejected. When rules overlap, the most restrictive one applies.

  • Access rules

    For each combination of user or group, service and database account, choose allow, deny or approval required.

  • Connection restrictions

    Set the allowed IP ranges, days of the week and hours. When the allowed time ends, open sessions are closed too.

  • Database account control

    Define which database accounts each service may use. Any other account is rejected before it reaches the database.

  • SQL control

    Block execution by statement type, such as DELETE or DROP, or by regular expression pattern. Test a rule against sample statements before you save it.

  • Approval

    Accept access requests, route them through multi-step approval and allow access only for the requested period. Sessions are closed when the period ends.

  • Session management

    View open sessions and force them to close per session or per person. Disabling a departing employee's account closes their sessions as well.

Data protection

Masks columns even behind aliases and functions

The gateway masks sensitive values in the results the database returns before passing them to the user. Your databases and applications stay unchanged.

SELECT name AS customer, grade, ssn, phone FROM customers WHERE id = 1024;

Result from the database

customergradessnphone
Jane DoeVIP123-45-6789415-555-0132

Result the user receives

customergradessnphone
********VIP***-**-****415-555-****
DELETE FROM customers WHERE id = 1024;

DELETE statements are not allowed on the production database (SQL control).

Sensitive fields

For values without a fixed format, such as names and addresses. Select customers.name as a sensitive field, and the gateway follows the result back to the source column (lineage) to mask it, even if it is aliased as customer or wrapped in a function.

Value patterns

Values with a fixed format, such as national ID numbers, card numbers and phone numbers, are found and masked in any column. Twelve built-in patterns cover personal data and credentials, and you can add your own as regular expressions.

  • A statement whose source columns cannot be worked out is not executed; it is rejected with a reason. Values that should be masked are never let through.
  • Who sees masked values is set per user and group. Masked characters are replaced with *, and the length stays the same.

Controls encrypted connections by inspecting their content

The gateway sets up TLS separately on the client side and the database side. The gateway cluster's certificate authority (cluster CA) issues the certificates and rotates them automatically before they expire. Connections whose content cannot be inspected are rejected by default.

Audit

Records who did what, by name

Gateways write directly to the audit store. Recording continues even if Management stops.

  • What is recorded

    Session start and end, executed statements, allow and deny decisions, row counts, masked items, and the user's name along with where that name came from.

  • Storage

    Records go to OpenSearch, Elasticsearch or a relational database. If the store does not respond, records are buffered on disk and sent again later.

  • Integrity

    Records are linked in a hash chain and verified in the admin console. Changing or deleting a record in the middle shows up.

  • Access to audit data

    Personal data is masked on the audit screens too. People with permission open the original one record at a time after entering a reason, and that access is recorded as well.

  • SIEM integration

    Copies are sent over syslog (RFC 5424) and Splunk HEC.

Supported databases

As of October 2026

MySQL
Agent, agentless (dedicated port per service)
MariaDB
Agent, agentless (dedicated port per service)
PostgreSQL
Agent, agentless (shared port)
Oracle
Agent, agentless (shared port), TLS (TCPS)
SQL Server
Agent, agentless (shared port)

Known limitations

  • Connections that use Oracle Native Network Encryption cannot be inspected, so they cannot be controlled. Configure clients to connect over TLS (TCPS) instead.
  • Results cannot be masked in sessions from Oracle OCI-based clients. In those sessions, queries that require masking are blocked.
  • SQL Server TDS 8.0 strict encryption is not supported yet.
  • The gateway becomes the only way in only after the database firewall closes all other sources.

See BeeHind in your own environment

Tell us which databases, servers and AI services you need to protect and how your network is laid out. We will recommend a setup and a rollout order. You can start with a single server.