Auditing Capabilities in Autonomous Database

Oracle Autonomous Database provides robust auditing capabilities that enable you to track who did what on the service and on specific databases. Comprehensive log data allows you to audit and monitor actions on your resources, which helps you to meet your audit requirements while reducing security and operational risk.

Related Topics

Auditing Service Level Activities

All actions Oracle Cloud users perform on the resources that make up your deployment of Oracle Autonomous Database on dedicated infrastructure are logged by the Audit service, regardless of the interface used: the Oracle Cloud Infrastructure Console, REST API, Command Line Interface (CLI), Software Development Kits (SDK) and so on.

You can use the Audit service to perform diagnostics, track resource usage, monitor compliance, and collect security-related events. For more information about the Audit service, see Overview of Audit in Oracle Cloud Infrastructure Documentation.

Additionally, when Oracle Autonomous Database performs operations on resources, it sends events to the Events service. Using the Events service, you can create rules to capture these events and perform actions such as sending you emails using the Notifications service.

For more information about how the Events service works and how to set up the rules and actions it uses, see Overview of Events. For listings of the Autonomous Database operations that generate events, see Events for Autonomous Database on Dedicated Exadata Infrastructure.

Tip:

To try out using the Events and Notifications services to create notifications, you can go through Lab11: OCI Notification Service in Oracle Autonomous Database Dedicated for Fleet Administrators.

Auditing Database Activities

Oracle Autonomous Database configures the autonomous databases you create to use the unified auditing feature of Oracle Database.

This feature captures audit records from the following sources and gathers them in a single audit trail in a uniform format:

  • Audit records (including SYS audit records) from unified audit policies and AUDIT settings
  • Fine-grained audit records from the DBMS_FGA PL/SQL package
  • Oracle Database Real Application Security audit records
  • Oracle Recovery Manager audit records
  • Oracle Database Vault audit records
  • Oracle Label Security audit records
  • Oracle Data Mining records
  • Oracle Data Pump
  • Oracle SQL*Loader Direct Load

Therefore, you can use the unified audit trail to perform a wide variety of diagnostic and security analysis activities on your database.

To keep the unified audit trail from growing too large, autonomous databases you create include an Oracle Scheduler job named MAINTAIN_UNIAUD_TRAIL that runs on a daily basis to remove unified audit records older than 90 days. You can, as the ADMIN database user, change this job's characteristics.

As a user with the AUDIT_ADMIN role, you can create or modify the audit policies. As a user with the AUDIT_VIEWER role, you can view the unified audit data by querying the following views:
  • AUDIT_UNIFIED_CONTEXTS
  • AUDIT_UNIFIED_ENABLED_POLICIES
  • AUDIT_UNIFIED_POLICIES
  • AUDIT_UNIFIED_POLICY_COMMENTS

Only an ADMIN user can grant the AUDIT_VIEWER or AUDIT_ADMIN roles to another user. Having the PDB_DBA role does not allow you to grant AUDIT_VIEWER or AUDIT_ADMIN to other users.

For more information about how unified auditing works and how to use it, see What Is Unified Auditing? in Oracle Database Security Guide.

Additionally, if your register your autonomous database with Oracle Data Safe you can use its extensive activity auditing and activity-based alerts features.

For information about these Data Safe features, see Activity Auditing in Using Oracle Data Safe. For information about registering your database with Data Safe, see Register or Deregister a Dedicated Database with Data Safe.

Auditing Autonomous VM Activities

Collection agents running on the control plane servers of Autonomous Database collect and send OS audit logs for all virtual machines and hypervisors running on the physical host, in addition to logs for anti-virus and host intrusion detection software. These logs are sent to a central System Information and Event Management (SIEM) service in OCI. Hundreds of alert rules on the SIEM scan for configuration changes, potential intrusions and unauthorized access attempts, among others.

A dedicated team of security analysts from the security incident Detection and Response Team (DART) is responsible for manning the security event dashboards 24 / 7 and processing alerts to filter true positives. If a true positive is detected, a suitable response is initiated based on the severity and impact of the event. This can include further analysis, a root cause assessment and fix with the service teams and customer communication.

In addition, vulnerability scanning software sends its findings to OCI Security Central, which automatically generates tickets for service teams to resolve findings within a time-period depending on the CVSS score. In addition, audit events for operation actions are sent to the logging service and a customer-provided syslog for systems enrolled in the Operator Access Control Service.

Oracle retains the following logs for Autonomous VMs on Exadata Cloud@Customer X8M and later hardware:

  • /var/log/messages
  • /var/log/secure
  • /var/log/audit/audit.log
  • /var/log/clamav/clamav.log
  • /var/log/aide/aide.log

Oracle retains the following infrastructure audit logs for Exadata Cloud@Customer X8M and later hardware:

  • Integrated Lights-Out Management (ILOM)
    • ILOM syslog redirected to the syslog of the physical infrastructure component
    • syslog
  • Physical Exadata Database Server
    • /var/log/messages
    • /var/log/secure
    • /var/log/audit/audit.log
    • /var/log/clamav/clamav.log
    • /var/log/aide/aide.log
  • Exadata Storage Server
    • /var/log/messages
    • /var/log/secure
    • /var/log/audit/audit.log

Auditing Oracle Operator Activities

Oracle Autonomous Database provides robust auditing capabilities that extend the existing auditing capabilities to include those activities performed by Oracle operators with a primary focus on enabling regulatory requirements for control and audit of all aspects of system management.

Tip:

For step by step guidance on how to create and manage operator control access to Exadata Infrastructure and Autonomous Exadata VM Cluster resources, see Lab 15: Operator Access Control in Oracle Autonomous Database Dedicated for Fleet Administrators Workshop.

Autonomous Database on Dedicated Exadata Infrastructure works in a shared responsibility model, where:
  • You, the customer are responsible for the data and the database application.
  • Oracle is responsible for the infrastructure components: power, bare-metal operating system, hypervisors, Exadata Storage Servers, and other aspects of the infrastructure environment.
  • Oracle is responsible for the DBMS software and for the overall health of the database.

In this model, Oracle has unfettered access to the components it is responsible for. This can be a problem if you have regulatory requirements to audit and control all aspects of your system management.

Oracle Operator Access Control is a compliance audit system that enables you to maintain close management and audit trails of all actions that an Oracle operator performs on the Exadata Infrastructure, Exadata Infrastructure hosting an Autonomous Database, and Autonomous Exadata VM Cluster (client virtual machines deployed on Oracle Autonomous Database) administered by Oracle. In addition, customers can control and limit operator's access to a specific customer-approved Autonomous Container Database (ACD).

Oracle Operator Access Control lets you:
  • Control who can access the system, when the system can be accessed, and how long Oracle personnel can access the system.
  • Limit access, including limiting what actions an Oracle operator can perform on your system.
  • Revoke access, including previously scheduled access that you have granted.
  • View and save a near real-time report of all actions an Oracle operator performs on your system.
You can use Oracle Operator Access Control to:
  • Control and audit all actions performed by any operator or system software on the following Autonomous Database resources:
    • Exadata Infrastructure
    • Autonomous Exadata VM Cluster (AVMC)
    • Autonomous Container Database (ACD)
    See Enforcement of Actions in Operator Access Control to know more about enforcing controls on the operations an Oracle operator can perform in your environment.
  • Provide controls for client virtual machines deployed on Oracle Autonomous Database. Like Operator access control for Exadata Cloud@Customer Infrastructure, customers can impose Oracle operator access controls on their Autonomous Virtual Machine clusters deployed on Exadata Cloud@Customer or Oracle Public Cloud. See Operator Access Control Actions: Autonomous VM Cluster for further information.
  • Maintain the same level of audits and access control to your systems. See How Operator Access is Audited for more information.
  • Provide the audit records required for internal or external regulatory audits across your systems. See Managing and Searching Logs with Operator Access Control for more details.

While creating an Operator Control, you can choose either Exadata Infrastructure or Autonomous Exadata VM Cluster depending on the resource that you want to audit for operator access. See Create Operator Control for more details.