How query rewrite works

Learn how Guardium® implements query rewrite functionality.

Overview

Once query rewrite has been enabled on the S-TAP for supported database servers (see Enabling query rewrite), query rewrite functionality is implemented through three policy rule actions:

These rule actions are installed as access policy rules. The access policy rules specify both query rewrite definitions that indicate how queries should be rewritten and a run time context that indicates when those definitions should be applied.

Once query rewrite rules have been specified, sessions are handled as follows:
  1. An SQL request triggers a QUERY REWRITE: ATTACH rule, and all subsequent activity in the session is watched by query rewrite.
  2. While sessions are being watched by query rewrite, traffic is held at the S-TAP and the session information is checked against access policy rules.
  3. If a query in the watched session matches a QUERY REWRITE: APPLY DEFINITION rule, the query is rewritten according to the definition and sent to the S-TAP.
  4. The S-TAP releases the rewritten query to the database server.
  5. When a QUERY REWRITE: DETACH rule is triggered, query rewrite stops watching activity for the remainder of the session or until another QUERY REWRITE: ATTACH rule is triggered.

Requirements and limitations

Query rewrite is intended to work with the following database servers:
  • Oracle
  • Db2
  • Microsoft SQL
Important: Query rewrite does not support encrypted traffic with Windows S-TAP. Active sessions may be terminated if they are encrypted.

For information about supported database servers and any associated restrictions, see System requirements. For detailed information about database client support for query rewrite, contact IBM Guardium support.

Note: When query rewrite is watching a session, the sniffer is required to send engine verdicts to the S-TAP for each SQL request in the session. This process is asynchronous and introduces latency between the sniffer and S-TAP. Create query rewrite rule conditions that avoid attaching to sessions for performance-sensitive or trusted applications.

Handling large SQL statements from an MSSQL Server database

Query rewrite does not mask the data when the overwritten SQL is larger then negotiated packet size. In these cases Guardium issues an alert. If the query is too long either a transport-level error occurs or the data in the query is shown as unmasked. If Guardium misses the login packet with the negotiated packet size, then Guardium uses the default packet size as 4K Use the predefined alert QWR Exceptions Alert to be notified of this situation. The alert fires once per session when the query returns more than the negotiated packet size. For more information, see Predefined alerts.

There is a default report QRW Exceptions that provides details of such sessions.