Seeing Is Not Stopping: From Database Visibility to Database Security Enforcement

Executive summary

Knowing who queried sensitive data does not settle whether that request should proceed. Database privileges already restrict access; monitoring explains how people and applications use it. DataSunrise adds centrally managed, SQL-aware audit, security and dynamic masking policies across supported database environments. Teams can reuse definitions of queries, objects and users, choose which activity to restrict, and retain evidence of the action taken. This connects investigation with enforcement while keeping native database controls in place.

When an allowed connection needs a narrower policy

A database account may need access to a table for legitimate application work. That permission does not necessarily make every use of the account appropriate. Security teams may need additional restrictions based on the objects being accessed or the context of the session, without removing the account’s underlying access altogether.

Native controls are part of the answer. Privileges limit operations, and PostgreSQL’s row-security policies can restrict which rows a user reads or modifies. Those controls belong in a least-privilege design.

Across a mixed database environment, teams also need a practical way to manage additional policies and investigate their effects. DataSunrise provides a common place for that work. Its rules use conditions on database sessions, statements and objects to determine what to record, mask or block. A security team can manage those policies alongside audit evidence instead of treating enforcement and investigation as separate activities. The available conditions and actions depend on the database and deployment mode.

The same request, a different outcome

Consider an illustrative reporting account, reporting_app, whose database permissions include access to customer_records, a table containing customer names and email addresses. The security policy prohibits this account from selecting data from that table. A DataSunrise Security rule matches SELECT operations on customer_records by reporting_app, including the request SELECT * FROM customer_records;.

With the rule set to Allow and event logging enabled, the query runs, the application receives the requested customer rows, and the team gets a record to review. With the rule set to Block and Query Error selected as the blocking method in proxy mode, this query-level rule can reject the matching request before it executes. The application receives a query error instead of customer rows, and the blocked attempt is recorded when event logging is enabled.

Learn more about how the DataSunrise Database Firewall provides SQL-level access control, threat detection, and real-time query blocking.

The distinction matters to both teams. Security has an action tied to the policy, rather than an alert waiting for someone to intervene. The application owner knows which operation is refused and can handle the error appropriately. Repeatedly retrying the same forbidden query will not resolve it.

The rule’s scope is as important as its action. A restriction intended for one application’s access should not inadvertently interrupt a reporting job or maintenance session. Conditions make that distinction explicit; audit events let the owners review the requests that match.

Reuse policy definitions across audit and enforcement

Defining the same objects and users separately for every control creates repeated work. DataSunrise Learning Rules collect observed queries, objects and users into groups that teams can reuse in Audit, Security and Masking rules. Each rule has its own action and configuration, while shared groups provide reusable definitions of the activity in scope.

For example, a team can review observed object access before using the relevant group in a Security rule. It does not have to describe the same collection of objects again to change how matching activity is handled. That connection between observation and policy is useful when security and application owners need to agree on precisely what a restriction covers.

Learning does not make an approval decision. Recorded activity may include misuse as well as legitimate work, and a short observation period may miss a quarterly report. The group needs review before it becomes part of an enforcement policy. Reusing a definition saves repeated configuration; it does not remove responsibility for deciding whether the activity should be allowed.

Choose what changes when a rule matches

The diagram shows five capabilities, not a required implementation sequence: observe, audit, detect, mask and block. An application can need dynamic masking without anomaly detection. A clear access restriction can justify blocking without a learned model. Audit remains useful alongside either control.

Reject a request or interrupt a response

A query-level blocking rule can act before execution. A rule that needs to inspect returned data acts later: the database has already processed the query, and earlier rows may have reached the client before a matching value triggers interruption. These controls address different requirements. Preventing an operation and stopping the remainder of a response are not equivalent outcomes.

Use anomalies to trigger the appropriate response

Audit Behavior Analytics records anomalous activity and can send alerts. Security Behavior Analytics can disconnect a session when its blocking conditions are met. Both use a trained Behavior Model.

The Security decision occurs during database-response processing, after the triggering query has reached the database. Disconnection does not guarantee that no rows were delivered or reverse effects already committed. Separate Warning and Block thresholds let teams configure the response; a warning is not a required pause for human approval before blocking.

Keep access while concealing selected values

Sometimes a user needs the record but not all of its contents. Dynamic masking changes configured values in live results while leaving the stored originals unchanged. Unlike static masking, it does not prepare a separate modified dataset.

This gives teams an alternative to denying the entire request. The masked representation still needs to fit the application’s purpose: a concealed value may be suitable for display but unsuitable for a calculation or downstream workflow.

Cover the paths applications actually use

An enforcement policy needs to sit on the relevant access path. A proxy controls traffic routed through it; a direct connection that bypasses it remains outside that proxy’s control. Administrative connections, scheduled jobs and alternate application routes belong in the coverage discussion, alongside the main application connection.

Agent enforcement depends on the supported database and configuration, including modification support. Passive traffic copies and native audit-log collection provide visibility without changing the original request. The deployment choice therefore follows the action required, rather than simply whether activity appears in a console.

Coverage is a shared operational responsibility. Database and application owners need to know which connections the policy governs, how other routes are restricted, and what changes when a new client is introduced. Central policy management is useful only when the intended traffic reaches the control.

Put enforcement evidence back into investigation

Discovery helps identify sensitive objects that deserve protection. Identity context helps determine whose access a policy should govern. Together, they inform decisions about which objects to include in rules and whether access should be recorded, masked or blocked. Turning those findings into a policy remains a decision for the responsible team, rather than an automatic consequence of discovering sensitive data. Teams can use DSPM findings to configure DataSunrise SQL-level controls for business applications and AI services on supported access paths.

For shared database accounts, the login alone does not identify every application user. DataSunrise’s application-user attribution depends on the application supplying identity context. The same consideration applies to AI services using shared credentials: passing through a proxy does not by itself identify each agent behind the connection.

Existing monitoring still has a role. PostgreSQL exposes currently executing commands, and Aurora Database Activity Streams provide a near-real-time feed with a collection pipeline separated from DBA access. These sources help explain activity; enforcement determines what happens to matching requests.

DataSunrise supports CEF/syslog audit-event export, transfer to Elasticsearch for visualization in Kibana, and PDF/CSV reporting. Teams can carry database evidence into their investigation workflows and examine it alongside other security context. Blocking a request need not end the investigation: the recorded attempt may still need explanation, especially when a legitimate application account made it. The recorded SQL and database login give the investigator a starting point for deciding whether the attempt reflects misuse or an application change.

Introduce control without losing legitimate work

Application owners need a clear view of what an enforcement policy will affect. Allow with event logging provides a nonblocking way to inspect Security rule matches before changing the action. It helps establish scope, but application behavior under rejection or disconnection needs a separate check.

A focused rollout should include normal work and infrequent operations, with attention to retries, transaction handling and downstream use of masked values. Policy ownership and a way to restore the previous behavior matter just as much as the initial configuration. These arrangements let the team respond when a restriction catches legitimate work.

Production readiness also includes latency, throughput and availability. Representative workloads should establish the operational cost of the chosen controls, while recovery exercises establish how applications behave when the enforcement service is unavailable. That work belongs alongside security-policy approval, not after a wider rollout.

DataSunrise connects the definition of a policy with its action and audit evidence. Teams can use observed activity to define scope, apply an appropriate control, and investigate the recorded outcome through the same product. The objective is a specific restriction that the organization can operate, with clear coverage and a predictable application response.