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 connects | Desktop agent | How it reaches the gateway | How the user is identified |
|---|---|---|---|
| Database tools on employee PCs | Required | The agent intercepts the connection and sends it through an mTLS tunnel | Signed identity assertion |
| Contractor PCs, BI tools | Not required | Connects directly with an issued connection address | Name assigned to the address and allowed IP range |
| Batch servers | Not required | Connects directly with an issued connection address | Allowed 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
DELETEorDROP, 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
| customer | grade | ssn | phone |
|---|---|---|---|
| Jane Doe | VIP | 123-45-6789 | 415-555-0132 |
Result the user receives
| customer | grade | ssn | phone |
|---|---|---|---|
| ******** | 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.