Linux-UNIX: Inspection engine verification
S-TAP® verification confirms that the S-TAPs and their inspection engines in your environment are running and actively monitoring database activity. Understand verification, and define a schedule to regularly verify S-TAPs.
Verification checks the sniffer operation and communication between the Guardium system and the inspection engines. You can enable verification for all S-TAP clients on your system, or individual S-TAP clients, or individual inspection engines.
- MSSQL (for cluster configuration supports only advanced verification)
- Teradata (advanced verification only)
- Standard verification
- Checks the sniffer operation, and the communication between the S-TAP and the
inspection engine. During standard verification, Guardium®
attempts to log in to database defined in the inspection engine with user
resutlfd, based on the assumption that no such user exists on the target system. (If that user exists, use advanced verification instead.) Depending on the installed policy, failed login alerts might be triggered for that login attempt. Next, the verification process checks whether it can connect to the selected inspection engine on the database server. It expects to receive a response that indicates a failed login. If a different response is received, you might have to investigate further.
- Some error messages from individual databases do not indicate a specific problem. For example, on several supported databases, the error code that is returned for a wrong port can also mean that the database itself is not started.
- Advanced verification
- Use advanced verification to avoid failed login requests, and manage individual inspection
engines. During advanced verification, Guardium logs
into the database that is defined in the configured datasource. It runs
non_existent_table. Depending on the installed policy, this SQL might appear in reports or alerts.