Cloud database service protection with native audit

Cloud database protection provides classification, vulnerability assessment, and object auditing on cloud databases, using the native audit.

After you set up the Guardium® connection with the cloud, you can:
  • Discover database instances, and catalog them in Guardium.
  • Assign cataloged data sources to a Classification process or create a new process: Classification runs on the cloud databases and identifies objects according to the defined rules
  • Assign cataloged data sources to a Vulnerability Assessment (VA) process or create a new process (requires a valid VA license): VA runs on the cloud databases and uses the data in Guardium reports.
  • Enable DB auditing: Oracle Standard Auditing data is pulled from the cloud for Guardium reports, depending on installed policies. For more information, see the Oracle documentation about Database Auditing.
  • Enable object auditing (Oracle's audit trail):
    • Review the Classification results and select objects for object auditing. (DB auditing must be enabled.) Object auditing tracks all activities that are performed on the objects. Guardium uses this data in reports, the investigation dashboard, and other areas.
    • Configure Guardium to add objects automatically, per data source.
    • Set a default per account, inherited by all of its data sources. Setting a default is especially useful for databases whose objects need auditing without any further evaluation. Set a high but reasonable limit of what you expect the classification process to find. You also want to prevent an overflow of objects if there is a mistake in your classification, so don't set it too high. (An overflow can affect the database performance.)
Note: AWS permissions are required to perform Guardium functions on the cloud DB. See Define AWS IAM for native audit.

In on-premises databases, the S-TAP® installed in the database sends all database traffic to the Guardium system. In the cloud environment, Guardium pulls log files from the cloud DB, and processes the data similar to S-TAP data. The difference is that the S-TAP records all database activity, whereas in the cloud environment, only the tables that you select are audited. Another difference is that there can be a slight delay in data retrieval from the cloud.

Activity on audited databases and objects is written to the database logs. The volume of log activity increases with the number of monitored items. High volume log activity can impact the database performance. You need to ensure that you are capturing all relevant data, while not overloading the system.

You can run cloud database service protection in a central manager environment and on a stand-alone Guardium collector.

In the context of cloud DB service protection, database refers to the database on the cloud, and data source refers to the Guardium cataloged database.

Only one Guardium system can own the DB audit and object audit of any one DB. Other Guardium systems can access the same cloud account and see the DB details, but cannot disable the DB audit or access the object audit data. You can move ownership from one Guardium system to another, for example if one goes down without expectation of recovery.

Discovery, Classification, and VA are supported for all Amazon RDS database engines.

Limitations:
  • You must keep the RDS definition updated, for example, DB instance deletions, or changes in credentials.
  • Guardium supports Oracle V.11, V.12, V.18, V.19 databases on an AWS cloud. (Since Oracle 12 audit does not contain login records, the client IP is not available.)
  • Extrusion rules are not supported, including redaction and testing for patterns in the returned data.
  • Return data is not supported, including records affected and logging of bind variable values.
  • Rule actions that interact with S-TAP are not supported; for example, S-GATE Terminate, Ignore, and query rewrite.
  • Failed logins are not captured by the Oracle audit, and therefore are not forwarded to Guardium.
  • Statements not captured by the Oracle audit, for example Statements with syntax errors, cannot be monitored.
  • Audit data has bind variable values but not type, for example, 123, so when it is replaced in SQL, surrounding quotation marks are always added.
  • When variable values contain ASCII control character, for example, '\001' or multiple byte characters, the audit file is not downloadable.
  • Blob bind variable values are not supported.