Oracle Cloud Infrastructure Documentation
Try Free Tier

Overview of Oracle Operator Access Control

Learn how to control, audit, and revoke access of Oracle service staff to your infrastructure by using Oracle Operator Access Control.

What is Oracle Operator Access Control?

Oracle Operator Access Control enables you to grant, audit, and revoke the access Oracle has to your Exadata Infrastructure, Exadata Infrastructure hosting an Oracle Autonomous Database on Exadata Cloud@Customer, and Autonomous Exadata VM Cluster (client virtual machines deployed on Oracle Autonomous Database on Exadata Cloud@Customer) administered by Oracle, and to obtain audit reports of all actions taken by a human operator, in a near real-time manner.

Oracle Operator Access Control for Exadata Cloud@Customer

Oracle Exadata Cloud@Customer service is a shared responsibility system:
  • You are responsible for actions in your virtual machines, and day-to-day management of databases and applications that run on your virtual machines.
  • Oracle is responsible for the infrastructure components: power, bare-metal operating system, hypervisors, Exadata Storage Servers, and other aspects of the infrastructure environment.

However, if you have regulatory requirements to audit and control all aspects of your system management, then the shared responsibility model creates a problem. You have to prove to your regulators that you are in complete control of your systems, and you are operating your systems in compliance with those compliance regulations.

How can you control and audit all actions performed on infrastructure components by any operator or any software on your systems? How can you maintain the same level of audits and access control to your systems, and provide the audit records required for internal or external regulatory audits across your systems? To solve this problem, Oracle provides Oracle Operator Access Control as the solution to restrain Oracle operators' unfettered access to your systems.

Operator Access Control for Oracle Autonomous Database on Exadata Cloud@Customer

Operator Access Control has been expanded to provide controls for client virtual machines deployed on Oracle Autonomous Database on Exadata Cloud@Customer. Similar to Operator access control for Exadata Cloud@Customer Infrastructure, customers may now impose Oracle operator access controls on their Autonomous Virtual Machine clusters deployed on Exadata Cloud@Customer.

The delivery of the Autonomous Database on dedicated infrastructure (both in OCI and Cloud@Customer) is based on the tenet that the customer is the "user" of the database and Oracle is the "manager". By "manage" we mean the typical database admin or DBA tasks such as the following:
  • Provisioning Autonomous Database resources
  • Backing up databases
  • Recovering a database
  • Patching and upgrading
  • Scaling
  • Monitoring service health
  • Auditing
  • Alerts and Notifications

The customer has no access to the client operating system, sys/system access to their container databases, or access to system logs. And, the customer is limited to monitoring application health and performance and security of applications at all levels. Oracle operators, on the other hand, being the manager has complete, unrestrained access to all components including root access to hypervisor and client VMs.

The shared responsibility model for Autonomous database poses several operational challenges to regulated customers who are required to retain control of all data and infrastructure regardless of vendor and deployment model ( on-premise, hosted, or cloud). Regulated customers undergo their own compliance scrutiny and formulate their own security guidelines that may take years to harden and put into practice.

This is especially true of Oracle's enterprise customers that are highly regulated and run their most critical systems, their most security-sensitive applications on Oracle. To solve this problem, Oracle provides Oracle Operator Access Control as the solution to restrain Oracle operators' unfettered access to your systems.

Oracle Operator Access Control for Oracle Cloud Infrastructure

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 infrastructure.

Oracle Operator Access Control enables you to do the following:
  • Grant access to your infrastructure, including who can access the infrastructure, when the system can be accessed, and how long Oracle personnel can access the system.
  • View and save a near real-time report of all actions an Oracle operator performs on your system.
  • Limit access, including limiting what actions an Oracle operator can perform on your system.
  • Revoke access, including the access that you have granted previously.

Operator Access Control for Compute Cloud@Customer

The Compute Cloud@Customer infrastructure is based on the tenet that the customer is the 'user' of VMs and services they create and run on the infrastructure and Oracle is the 'manager' of the infrastructure itself. By 'manage' we mean typical tasks such as upgrading, patching, and monitoring for the infrastructure components.

The customer has no access to infrastructure virtual or bare-metal OS instances on infrastructure components nor management software that runs on these instances. Oracle Ops, on the other hand, being the manager, has complete, unrestrained access to all components including root access to hypervisor and Control Plane Servers.

This model poses several operational challenges to regulated customers who are required to retain control of all data and infrastructure regardless of vendor and deployment model (on-premises, hosted, or cloud) Regulated customers undergo their own compliance scrutiny and formulate their own security guidelines that may take years to harden and put into practice. This is especially true of Oracle's enterprise customers that are highly regulated and run their most critical systems, their most security-sensitive applications on Oracle.

Operator Access Control has been extended to support these customer compliance objectives and enable them to bring their mission-critical databases to Oracle Cloud such that customers are ultimately in control of access to their dedicated systems.

Terms Associated with Operator Access Control

Learn about what terms are used with Operator Access Control.

Operator: An Oracle employee that is a member of an operators group (Ops group) tenancy in Oracle Cloud Infrastructure (OCI). For example, an operator can be an Oracle employee in the Exadata Cloud@Customer_ops group or the ExaCS_ops group. The Ops group tenancy is a set of tenancies in OCI that are permitted to administer operation controls. The Ops groups, and the operators that are members of these groups, do not have any default privilege other than the ability to request access to infrastructure. The groups and membership in the operator groups is strictly controlled by Oracle.

User: An OCI user of the tenancy on whose Exadata Cloud@Customer system the controls are placed.

Exadata Infrastructure Layer: Multiple physical or operating system layers of the Exadata system. Currently, defined as Control Plane Server, Host, Guest VM, cell servers, switches, and ILOM.

Action: A named, predefined set of commands, files, or networks that can be accessed on a given layer. Oracle defines actions.

Operator Control: A customer-defined entity, which contains a grouping of pre-approved actions, and actions that require explicit approval from the approval-group to allow access. The approver group is a standard IAM user group that lists the set of users who have permissions to approve or revoke access.

Operator Attributes: In certain cases, the operator control can define criteria for the operators that are permitted to access the infrastructure.

Assignment of Operator Control: This is the process by which an Exadata Cloud@Customer system is attached to a named operator control. At any given point in time, only one operator control can be enforced on an Exadata Cloud@Customer system. The assignment can be permanent or for a specific duration. If an operator control is not assigned to an Exadata Cloud@Customer system, then the Exadata Cloud@Customer system runs with a default operator control that permits all access required for diagnostics and maintenance.

Access Request: Access request is the process by which an operator requests permission to access an identified Exadata infrastructure. The Exadata infrastructure is identified by OCID. The request identifies the action that the operator requires.

Access Request Approve/Reject: Access approve/reject is the process by which a competent user as determined by the operator control deployed on the Exadata infrastructure can grant or reject an access request.

Access Request Revoke: A competent user can revoke an access request at any given point in time. This removes the sessions of the operator connected to the Exadata infrastructure based on this access request immediately.

Access Request In Review: Acknowledge a Raised Oracle Operator Access Request and tell the requester that the access request is being reviewed.

What Control Options Does Oracle Operator Access Control Provide?

You create policies that specify which set of Actions operators can perform on your infrastructure.

An Action places constraints on what an Oracle operator is permitted to do on infrastructure managed by Oracle. These constraints include control over running operating system shell commands, running and Oracle scripts. Actions also place constraints on the ability of Oracle operators to run binaries, shell scripts, and Perl or Python scripts that are beyond the scope of the function defined by the Action. When you grant permissions through an Action, every action an Oracle operator performs is logged. You can audit the logs as part of your MAC constraint requirements policy.

A policy is a set of actions that you specify to implement mandatory access control (MAC) constraints on the ability of Oracle operators to perform maintenance on your systems. To define your policies, these are a list of specific access controls that you can enforce through Actions:

  1. Configure operator controls for management of Oracle operators:
    • Operator controls to restrict access profiles on a given resource type in your tenancy. For example, you can set up separate policies for resources such as your virtual machine (VM), the Oracle infrastructure database server, the control plane server, or the InfiniBand network. In addition, you can configure polices to associate access controls to a group of resources in your tenancy.
    • Configure an administrator group of users associated with each operator control. Members of these groups can approve, change, or deny access requests on a resource where you have deployed an operator control.
    • Configure Actions for access to resources that you define as preapproved, without requiring either configuring a group of administrative users to control access.
  2. Specify mandatory request authorization before permitting any access to resources. For example:
    • When a set of actions are marked as pre-approved, any access request specifying only a subset of such actions will be automatically approved, and Oracle staff can access infrastructure components.
    • When an access policy is not set to pre-approved, Oracle staff are denied access to compartments until you explicitly grant access requests.
  3. Revoke access to your infrastructure that you have previously granted:
    • Automatic time limits revoke any access that you grant on a resource. When you grant an access request, an Oracle operator is granted a unique user ID for the access you grant for a limited time. When that time limit is reached, all Oracle access to your system related to the approved access request is revoked. If more time is needed, then an Oracle operator can submit an extension request.
    • Revoke access manually that was already granted to a resource before the access you previously granted has expired.
  4. Audit all actions a human operator performs on your resources:

    • All keyboard entries and commands run by the human actor are audited. You obtain full access to all Linux audit logs.

      You can request an audit of a specific Oracle human operator on your system.

      Note

      The human operator's identity is not available to you as an Oracle customer. However, the Oracle Operator Access Control system maintains service records of the human operator, so that Oracle can correlate the human operator with a specific access request that you have granted for service on your tenancy. If you suspect malicious action, and require an audit, then Oracle can use that request to review all actions of the specific human operator who performed the actions permitted by an access request.

Enforcement of Actions in Operator Access Control

Learn about enforcing controls on the operations an Oracle operator can perform in your environment.

Parent topic: Overview of Oracle Operator Access Control

What is Action Enforcement?

Operator Access Control, Actions limit the privileges the operator has in running commands, accessing resources, and changing the state of the system.

An Action defines the permissions, resource, and system change access an Oracle operator is granted to perform a given range of tasks for specific administrative functions on a Exadata infrastructure in an environment managed using Operator Access Control. The commands an Action permits can be Oracle Linux commands, or cell server commands.

Resources for which an Action grants access are files and network. System changes correspond to a state change in the operating system, or to a state change in the software running on those systems. The state change is a consequence of restarts or configuration modifications.

Action enforcement is based on approved Access Requests, which set up a time-limited policy of which changes you want to enable an Oracle operator to implement, as defined by a set of Actions granted to operators. Every access request creates a temporary user credential in the Exadata infrastructure. The policy of access that you define is based on the Actions you approve in the Access Request, which is attached to the temporary user created.

The Action enforcements are typically a function of the operating system. An Action enforcement policy is created for an instance of the operating system, such as in all hosts, cell servers, and Control Plane Servers. The Actions granted with a policy are removed after the Access Request becomes invalid, either because the Access Request is closed, because the administration task is completed, revoked, or expired.

Action enforcement can be applied to different infrastructure, such as an operating system, to other software, such as cellcli.

Operator Access Control Actions: Exadata Infrastructure

Actions define the operations an operator can perform on Exadata Cloud@Customer infrastructure that are limited to host, cell server, and Control Plane Servers.

Actions are applicable to the Exadata Cloud@Customer infrastructure as a whole. Actions control the Oracle operator actions on multiple layers of Exadata Cloud@Customer. The layers controlled in the current version are cell servers, Management Domain (host), and the Control Plane Servers. The actions are organized by the requirements, which leads to the request of actions and the critical impact these actions potentially generate.

The actions translate Oracle Linux permissions on the target Exadata Cloud@Customer system. The permissions are categorized into file system privileges, command execution privileges, and su or sudo privileges. The actions are categorized by the nature of the change that can be effected by the operator on the Exadata Cloud@Customer system.

  • Action: Control Plane Server (CPS) Only
    Control Plane Server (CPS) Only, which is identified as INFRA_CPS_ONLY is intended to be used for diagnosing and resolving CPS issues only. Oracle staff are prevented from accessing components beyond the CPS, including cell servers and host operating system (Dom0).
  • Action: System Diagnostics
    System Diagnostics, which is identified as INFRA_DIAG is intended to be used for diagnosing any issue in the Exadata Cloud@Customer infrastructure layer.
  • Action: System Maintenance with Restart Privileges
    System Maintenance with Restart Privileges, which is identified as INFRA_UPDATE_RESTART is intended to be used for operator access scenarios that require a system configuration change, or a restart of the system.
  • Action: System Maintenance with Data access / VM Control Privileges
    System Maintenance with Data access / VM control Privileges, which is identified as INFRA_HYPERVISOR is intended to be used for diagnostics and maintenance scenarios where VM management on the host is required.
  • Action: Full System Access
    Full System Access, which is identified as INFRA_FULL permits access to the root accounts on the infrastructure components.

Parent topic: Enforcement of Actions in Operator Access Control

Action: Control Plane Server (CPS) Only

Control Plane Server (CPS) Only, which is identified as INFRA_CPS_ONLY is intended to be used for diagnosing and resolving CPS issues only. Oracle staff are prevented from accessing components beyond the CPS, including cell servers and host operating system (Dom0).

Table 1-1 Actions Enabled with INFRA_CPS_ONLY

Action Name

Control Plane Server (CPS) Only
Action Identifier

INFRA_CPS_ONLY
Operator Privileges

Linux User Privilege: Non-root

Can su to root: No

chroot jail: Yes

Can su into: None

sudo user + command list: Limited to the list provided above

Cell server privileges: No

Host operating system (Dom0): No

Network Privileges: No

List of executable commands:

These commands can be run directly from the Bash prompt.

  • Alias:
    • sudols
    • sudocp
    • sudocat
    • sudotail
    • sudohead
    • sudovi
    • sudorm
    • systemctl
    • reboot
    • ifconfig
    • lsof
    • docker
    • ipmitool
    • dbmcli
    • traceroute
    • tcptraceroute
    • journalctl
    • exacloud
    • du
    • imageinfo
    • imagehistory
    • arping
    • curl
    • tcpdump
    • crontab
    • sundiag.sh
    • sosreport
    • ethtool
  • Special commands supported:
    • rootexec /root/alarm_detail.sh
    • rootexec /root/alerthistory.sh
    • rootexec /root/blackout.sh
    • rootexec /root/quarantine_ack.sh
    • rootexec /root/stateless_ack.sh
    • rootexec /root/stateless_alert.sh
    • rootexec /etc/keepalived/manual-switchover.sh

Directories and files with explicit Read and Write access:

  • Read and Write:
    • /u01/
    • /opt/oci/exacc/
  • Read-Only:
    • /var/log/
    • /opt/oracle.cellos/
    • /usr/local/nessus/results/
    • /opt/nessus/var/nessus/logs/

Special Operator Access Control commands:

Cage commands to view or modify (read, read/write) files or directories mentioned above:

  • sudols
  • sudocp
  • sudocat
  • sudotail
  • sudohead
  • sudovi
  • sudorm
Action: System Diagnostics

System Diagnostics, which is identified as INFRA_DIAG is intended to be used for diagnosing any issue in the Exadata Cloud@Customer infrastructure layer.

The diagnosis involves reading logs, running diagnostics, and monitoring commands. This action is also intended to fix issues with diagnostics agents in the Exadata Cloud@Customer system. The fix involves restarting diagnostic daemons with potentially modified parameters.

Note

System Diagnostics action poses no customer data exposure risks and low availability risks.
System Diagnostics action allows:
  • The operator to use cat, grep, and so on to read log files of the operating system, infrastructure software, and cloud orchestration software.
  • The operator to run Oracle Linux diagnostic commands such as top and netstat.
  • On cell servers, it additionally allows the operator to run cellcli commands to obtain diagnostic information.
  • The operator to access the manage the cloud orchestration infrastructure on the Control Plane Server with the capability to restart all daemons on the Control Plane Server.

Table 1-2 Actions Enabled with INFRA_DIAG

Action Name

System Diagnostics
Action Identifier

INFRA_DIAG
Operator Privileges

Oracle Linux user privilege: Non-root.

Can su to root: No

chroot jail: Yes

Can su into:
  • Cell: cellmonitor
  • Host: dbmmonitor
  • Control Plane Server:
    • ecra
    • exawatcher
    • dbmsvc
Execute as root:
  • cat
  • head
  • tail
  • cp for files inside /var/log/*
  • [CPS]: systemctl

Cell Server Privileges: Act as cell monitor.

Network Privileges: Can SSH into all hosts, cell servers, and Control Plane Servers. The user name is the same across all of these.

List of executable commands:

  • Control Plane Server (Alias): These commands can be run directly from the Bash prompt.
    • systemctl
    • reboot
    • ifconfig
    • lsof
    • docker
    • ipmitool
    • dbmcli
    • traceroute
    • tcptraceroute
    • journalctl
    • exacloud
    • du
    • imageinfo
    • imagehistory
    • arping
    • curl
    • tcpdump
    • crontab
    • sundiag.sh
    • sosreport
    • ethtool
  • Cell server (Alias): These commands can be run directly from the Bash prompt.
    • cellcli - read-only commands
    • sundiag.sh
    • sosreport
    • lspci
    • imageinfo
    • imagehistory
  • Host (Alias): These commands can be run directly from the Bash prompt.
    • dbmcli - read-only commands
    • sundiag.sh
    • sosreport
    • virsh - only list options
    • xm - only list options
    • docker
    • podman
    • imageinfo
    • imagehistory

Directories and files with explicit Read and Write access:

  • Control Plane Server:
    • Read and Write: /u01/
    • Read-Only:
      • /var/log/
      • /opt/oci/exacc/exacloud/log/
      • /opt/oracle.cellos/
      • /usr/local/nessus/results/
      • /opt/nessus/var/nessus/logs/
    • Special Operator Access Control commands: Cage commands to view or modify (read, read/write) files or directories mentioned above.
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead
      • sudovi
      • sudorm
  • Host:
    • Read and Write: None
    • Read-Only: /var/log/
    • Special Operator Access Control commands: Cage commands to view or modify (read, read/write) files or directories mentioned above.
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead
    The following directories are mapped in a read-write mode for the tools to run; however, Oracle operators are not granted direct access to them.
    • /var
    • /opt/oracle
  • Cell server:
    • Read and Write: None
    • Read Only: /var/log/
    • Special Operator Access Control commands: Cage commands to view or modify (read, read/write) files or directories mentioned above.
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead

    The following directories are mapped in a read-write mode for the tools to run; however, Oracle operators are not granted direct access to them.

    • /var
    • /opt/oracle
Action: System Maintenance with Restart Privileges

System Maintenance with Restart Privileges, which is identified as INFRA_UPDATE_RESTART is intended to be used for operator access scenarios that require a system configuration change, or a restart of the system.

The INFRA_UPDATE_RESTART scenarios are typically for maintenance. However, there can be diagnostics scenarios where this action is also required. System configuration changes involve network configuration changes, hardware configuration changes, operating system configuration changes such as mounts, inodes, ulimits, or cloud orchestration software configuration changes. System restart entitles the Oracle operator to restart the operating system (host, cell server), to restart specific sub-systems, such as the network, and to restart cell disks.

Caution:

Be aware that System Maintenance with Restart Privileges action permits restarts of infrastructure components (database servers, storage servers, and control plane servers) and prevents access to customer VMs, customer data, and the infrastructure audit service.
System Maintenance with Restart Privileges action:
  • Permits the Oracle operator to perform system maintenance activities with root privileges. The operator cannot become root, but can run maintenance commands as root.
  • Does not allow the operator to change the audit parameters, or access the audit logs. However, the action allows the operator to take the whole Exadata Cloud@Customer system offline.
  • Allows the operators to change the configuration of the operating system through permanent changes. For example, the Oracle operator is permitted to change /etc/ parameters.
  • Permits the Oracle operator to start daemon processes, and to manage the cell disks using the cell admin privilege of cellcli on cell servers.
  • Permits the Oracle operator to access the manage the cloud orchestration infrastructure on the Control Plane Server, with the capability to restart all daemons on the Control Plane Server.

Inheritance: All privileges of System Diagnostics

Table 1-3 Actions Enabled with INFRA_UPDATE_RESTART

Action Name

System Maintenance with Restart Privileges
Action Identifier

INFRA_UPDATE_RESTART
Operator Privileges

Same as System Diagnostics privilege + the following:

Can su to root: No

chroot jail: Yes

Can su into:
  • exawatcher
  • dbmsvc
  • dbmadmin
  • dbmmonitor on the host
Execute as root:
  • restart
  • ip
  • ifconfig
  • lspci

Cell server privileges: celladmin in cell server

Network Privileges: Can SSH into all hosts, cell servers, and Control Plane Servers. The user name is the same across all of these layers

List of executable commands:

  • Control Plane Server (Alias): These commands can be run directly from the Bash prompt.
    • systemctl
    • reboot
    • ifconfig
    • lsof
    • docker
    • ipmitool
    • dbmcli
    • traceroute
    • tcptraceroute
    • journalctl
    • exacloud
    • du
    • imageinfo
    • imagehistory
    • arping
    • curl
    • tcpdump
    • crontab
    • sundiag.sh
    • sosreport
    • ethtool
  • Cell server (Alias): These commands can be run directly from the Bash prompt.
    • reboot
    • sundiag.sh
    • cellcli - all commands
    • lspci
    • imageinfo
    • imagehistory
    • ethtool
    • ipmitool
    • ipmitool_interactive (same as ipmitool, can be used when tty is required)
  • Host (Alias): These commands can be run directly from the Bash prompt.
    • reboot
    • dbmcli - all commands
    • sundiag.sh
    • virsh - only list options
    • xm - only list options
    • docker
    • podman
    • imageinfo
    • imagehistory
    • ethtool
    • sosreport

Directories and files with explicit Read and Write access:

  • Control Plane Server:
    • Read and Write: /u01/
    • Read-Only:
      • /var/log/
      • /opt/oci/exacc/exacloud/log/
      • /opt/oracle.cellos/
      • /usr/local/nessus/results/
      • /opt/nessus/var/nessus/logs/
    • Special Operator Access Control commands: Cage commands to view or modify (read, read/write) files or directories mentioned above.
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead
      • sudovi
      • sudorm
  • Host:
    • Read and Write: None
    • Read-Only: /var/log/
    • Special Operator Access Control commands: Cage commands to view or modify (read, read/write) files or directories mentioned above.
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead
    The following directories are mapped in a read-write mode for the tools to run; however, Oracle operators are not granted direct access to them.
    • /var
    • /opt/oracle
    • /home/dbmadmin
  • Cell Server:
    • Read and Write: None
    • Read Only: /var/log/
    • Special Operator Access Control commands: Cage commands to view or modify (read, read/write) files or directories mentioned above.
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead
    The following directories are mapped in a read-write mode for the tools to run; however, Oracle operators are not granted direct access to them.
    • /var
    • /opt/oracle
    • /home/celladmin/
Action: System Maintenance with Data access / VM Control Privileges

System Maintenance with Data access / VM control Privileges, which is identified as INFRA_HYPERVISOR is intended to be used for diagnostics and maintenance scenarios where VM management on the host is required.

System Maintenance with Data access / VM Control Privileges action is intended to be used for diagnostics and maintenance scenarios where VM management on the host is required. Any data on the Guest VM is treated as customer data. As VM management involves the ability to access the VM data, this action potentially exposes data risk. However, this action does not give any access to the TDE keys of the data stored in cell servers. VM management is required in cases where there are problems with the VM software infrastructure or where a VM configuration needs to be modified. Configuration involves the external aspect of the VMs such as the networks attached, disks attached, or resources (CPU, Mem) allocated.

Note

System Maintenance with Data access/ VM control privileges prevents access to the infrastructure audit subsystem.
System Maintenance with Data Access / VM Control Privileges action:
  • Allows the operator to perform Xen/KVM management commands with root privileges. The operator cannot become root. This action is applicable only to the host.
  • Inherits the privileges from the "System Maintenance with Restart Privileges" action.
  • Does not allow the operator to change the operating system parameters of the host or cell servers. However, this allows the operator to shut down the Guest VM and significantly change the configuration of the Guest VM.

Inheritance: All privileges of System Maintenance with Restart.

Table 1-4 Actions Enabled with INFRA_HYPERVISOR

Action Name

System Maintenance with Data access / VM control Privileges
Action Identifier

INFRA_HYPERVISOR
Operator Privileges

Same as "System Maintenance with Restart" privileges + the following:

Oracle Linux user privilege: Non-root.

Can su to root: No

chroot jail: Yes

Can su into: celladmin in cell server

Execute as root:
  • /usr/sbin/xm
  • /usr/sbin/xentop
  • /usr/sbin/virsh

Cell Server Privileges: celladmin

Network Privileges: Can SSH into all hosts, cell servers, and Control Plane Servers. The user name is the same across all of these.

List of executable commands:

  • Control Plane Server (Alias): These commands can be run directly from the Bash prompt.
    • systemctl
    • reboot
    • ifconfig
    • lsof
    • docker
    • ipmitool
    • dbmcli
    • traceroute
    • tcptraceroute
    • journalctl
    • exacloud
    • du
    • imageinfo
    • imagehistory
    • arping
    • curl
    • tcpdump
    • crontab
    • sundiag.sh
    • sosreport
    • ethtool
  • Cell server (Alias): These commands can be run directly from the Bash prompt.
    • cellcli - all commands
    • lspci
    • imageinfo
    • imagehistory
    • ethtool
    • sosreport
    • reboot
    • sundiag.sh
    • ipmitool
    • ipmitool_interactive (same as ipmitool, can be used when tty is required)
  • Host (Alias): These commands can be run directly from the Bash prompt.
    • dbmcli - all commands
    • sundiag.sh
    • virsh - all options
    • xm - all options
    • virsh_interactive - all options (same as virsh, can be used when tty is required)
    • xm_interactive - all options (same as xm, can be used when tty is required)
    • xentop - all options
    • vm_maker - all options
    • docker
    • docker_interactive (same as docker, can be used when tty is required)
    • podman
    • podman_interactive (same as podman, can be used when tty is required)
    • imageinfo
    • imagehistory
    • ethtool
    • sosreport
    • ipmitool
    • ipmitool_interactive (same as ipmitool, can be used when tty is required)
    • ops_console.sh

Directories and files with explicit Read and Write access:

  • Control Plane Server:
    • Read and Write: /u01/
    • Read-Only:
      • /var/log/
      • /opt/oci/exacc/exacloud/log/
      • /opt/oracle.cellos/
      • /usr/local/nessus/results/
      • /opt/nessus/var/nessus/logs/
    • Special Operator Access Control commands: Cage commands to view or modify (read, read/write) files or directories mentioned above.
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead
      • sudovi
      • sudorm
  • Host:
    • Read and Write: None
    • Read-Only: /var/log/
    • Special Operator Access Control Commands: Cage commands to view or modify (read, read/write) files or directories mentioned above.
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead

    The following directories are mapped in a read-write mode for the tools to run; however, Oracle operators are not granted direct access to them.

    • /var
    • /opt/oracle
    • /home/dbmadmin
  • Cell server:
    • Read and Write: None
    • Read Only: /var/log/
    • Special Operator Access Control commands: Cage commands to view or modify (read, read/write) files or directories mentioned above.
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead

    The following directories are mapped in a read-write mode for the tools to run; however, Oracle operators are not granted direct access to them.

    • /var
    • /opt/oracle
    • /home/celladmin/
Action: Full System Access

Full System Access, which is identified as INFRA_FULL permits access to the root accounts on the infrastructure components.

Full System Access action is intended to be used when full access to the Exadata Cloud@Customer infrastructure is required. Access is always limited to non-Guest VM layers. Full access here means the root privileges on every operating system instance in the Exadata Cloud@Customer system, other than Guest VMs.

Note

Full System Access action permits the operator to become the root user on the infrastructure. This allows the operator to access and modify any memory register, any file, any device, and the audit subsystem.

Table 1-5 Actions Enabled with INFRA_FULL

Action Name

Full System Access
Action Identifier

INFRA_FULL
Operator Privileges

Linux User Privilege: Non-root

Can su to root: yes

chroot jail: No

Directories Readable: All

Files Readable: All

Directories Writeable: All

Files Writeable: All

List of commands executable: All

Can su into: root through sudo

sudo user + command list: No restriction

Cell server privileges: root and celladmin

Network Privileges: Can SSH into all hosts, cell servers, and Control Plane Servers. The user name is the same across all of these. Also, connect to root directly on the host, cell server to using exassh

Operator Access Control Actions: Autonomous VM Cluster

Besides Full System Access, use the limited access cages, Diagnostics and Maintenance, to view logs and perform service-related tasks.

Parent topic: Enforcement of Actions in Operator Access Control

Action: Autonomous Exadata VM Cluster Full System Access

Autonomous Exadata VM Cluster Full System Access, which is identified as AVM_FULL is to be used rarely if none of the lower access privileges can solve the issue.

Autonomous Exadata VM Cluster Full System Access action is intended to be used when full access to the Guest VMs is required. Full access here means the root privileges to the Guest VMs.

Note

Full System Access action poses extreme availability and data exposure risks, which can be persistent. The action also provides ability to bar export of audit logs from the system.

Table 1-6 Actions Enabled with AVM_FULL

Action Name

Full System Access
Action Identifier

AVM_FULL
Operator Privileges

Linux User Privilege: Non-root

Can su to root: yes

Chroot caged: No

Directories Readable: All

Files Readable: All

Directories Writeable: All

Files Writeable: All

List of commands executable: All

Can su into: root through sudo

sudo user + command list: No restriction

Action: Autonomous Exadata VM Cluster System Diagnostics

Autonomous Exadata VM Cluster System Diagnostics, which is identified as AVM_SYS_DIAG is to be used to view logs.

Autonomous Exadata VM Cluster System Diagnostics action is intended to be used to view logs. A read-only profile, which allows non-privileged read-only access to the system. This action is used to determine possible issues with the operating system and the software running on it. Most of the non-root commands would be available in this mode. No privileged commands are available in this action. Operators are not allowed to sudo as oracle, opc, or grid but will have a white-listed set of commands they can run as that dynamic operator user.

Table 1-7 Actions Enabled with AVM_SYS_DIAG

Action Name

Autonomous Exadata VM Cluster System Diagnostics
Action Identifier

AVM_SYS_DIAG
Scope

Guest VM
Operator Privileges

Linux User Privilege: Non-root

Can su to root, oracle, opc, grid: No

Chroot caged: Yes

Directories Readable:
  • /proc
  • /sys
  • /tmp
  • /usr/lib64
  • /usr/bin
  • /usr/etc
  • /usr/include
  • /usr/lib
  • /usr/libexec
  • /usr/local
  • /usr/share
  • /opt/nessus
  • /usr/java
  • /var
  • /u01
  • /u02
  • /acfs01
  • /opt/oracle/dcs/log
  • /opt/oracle.ExaWatcher/archive

Directories Writable: /tmp

Restricted application log readable locations:
  • /etc/oratab
  • /opt/oracle/dcs/log
  • /opt/oracle/dcs/idempotencytoken_jobid_db
  • /u02/oracle.ahf
  • /u02/app/oracle/diag/rdbms
  • /opt/oracle.ExaWatcher/archive
Config files readable:
  • /etc/oratab
  • /opt/oracle/dcs/idempotencytoken_jobid_db
  • /etc/hosts

Egress network access: None

Blacklisted operating system commands:
  • dd
  • kdumpctl
  • ipcrm
  • ipcmk

List of commands executable: ls, cat, and tail commands are supported in the locations where opctl dynamic user does not have read access

Limit Operator's Access to a Specific Customer-Approved Autonomous Container Database (ACD)

Restrict access to a specific ACD in an autonomous VM cluster in the diagnostics and maintenance cages.

Operators can specify if they need:

  • SSH-only access to the autonomous VM cluster without SQL access to the ACDs. In this case, all SQL access to the ACDs will be blocked.
  • SSH access to the autonomous VM cluster and SQL access to the ACDs. If they select both, they must select one or more ACDs.

The customer receives an approval request with the details that the operators are requesting access to. That way, the customer can be assured that the operators will have access to the right ACD. Once the customer approves the access request, the operators will get SQL access to only the ACDs they have been approved for.

The Request Reason attribute will display which ACDs the operators are requesting access to.

Action: Autonomous Exadata VM Cluster System Maintenance

Autonomous Exadata VM Cluster System Maintenance, which is identified as AVM_SYS_MAINT is to be used to do service related changes.

Autonomous Exadata VM Cluster System Maintenance action is intended to be used to do service related changes. This action is used to start and stop services, and run service health checks. Most of the service related commands are available in this mode. Operator will have access to the logs, but not allowed to su to oracle, opc, or grid.

Table 1-8 Actions Enabled with AVM_SYS_MAINT

Action Name

Autonomous Exadata VM Cluster System Maintenance
Action Identifier

AVM_SYS_MAINT
Scope

Guest VM
Operator Privileges

Linux User Privilege: Non-root

Can su to root, oracle, opc, grid: No

Chroot caged: Yes

Directories readable:
  • /proc
  • /sys
  • /tmp
  • /usr/lib64
  • /usr/bin
  • /usr/etc
  • /usr/include
  • /usr/lib
  • /usr/libexec
  • /usr/local
  • /usr/share
  • /opt/nessus
  • /usr/java
  • /var
  • /u01
  • /u02
  • /acfs01
  • /opt/oracle/dcs/log
  • /opt/oracle.ExaWatcher/archive

Directories writable: None

Restricted application log readable locations:
  • /etc/oratab
  • /opt/oracle/dcs/log
  • /opt/oracle/dcs/idempotencytoken_jobid_db
  • /u02/oracle.ahf
  • /u02/app/oracle/diag/rdbms
  • /opt/oracle.ExaWatcher/archive
Config files readable:
  • /etc/oratab
  • /etc/crontab
  • /opt/oracle/dcs/idempotencytoken_jobid_db
  • /etc/hosts

Egress network access: None

Blacklisted operating system commands:
  • dd
  • kdumpctl
  • ipcrm
  • ipcmk

Command aliases: {"job_manager" : "/var/opt/oracle/adbd/apps/job_manager/job_manager.py", "backup_api" : "/var/opt/oracle/bkup_api/bkup_api", "service_driver" : "/var/opt/oracle/pylib/DBAAS/service_driver.py"}

List of commands executable: Execution of service related commands are available as is but without switching to oracle or grid user. Execution of scripts are supported through aliases without switching to oracle or grid user.

Refer to the examples provided below.

  • crsctl status resource adbd_archive_log_ilkzdar1
  • crsctl check cluster -all
  • crsctl stat res -t
  • crsctl stat res ora.asm -t
  • srvctl status service -db ilkzdar1_cdg1hw
  • srvctl status database -d hr5zxn5l_cdg1bg
  • srvctl status instance -i hr5zxn5l1 -d hr5zxn5l_cdg1bg
  • tfactl blackout add -targettype host -timeout 2h -reason "Testing maint cage" -c
  • dgmgrl
  • asmcmd lsdsk -p

    (Not allowed due to possible access to system console)

  • sysresv

    (Not allowed due to options to remove ipc resources)

  • SQL*Plus is restricted to selected queries. Switching to oracle or grid is not supported.

    opctl_avm_maint_user01@atpd-exa-suzzm1:~$ execsql ORACLE_UNQNAME is required.Check /etc/oratab opctl_avm_maint_user01@atpd-exa-suzzm1:~$

    opctl_avm_maint_user01@atpd-exa-suzzm1:~$ cat /etc/oratab | grep -v '^\s*$\|^\s*\#' ownwdhci_iad2pn:/u02/app/oracle/product/19.0.0.0/db1916_0_wc139_cl_atksxzha_096_0105:Y +ASM1:/u02/app/19.0.0.0/grid1916_0_wc140_cl_atksxzha_096_1334:Y ay5sq1qf_iad2bp:/u02/app/oracle/product/19.0.0.0/db1916_0_wc141_cl_atksxzha_096_0214:Y dhb2br6k_iad22z:/u02/app/oracle/product/19.0.0.0/db1916_0_wc142_cl_atksxzha_096_0416:Y v001zhgm_iad2zs:/u02/app/oracle/product/19.0.0.0/db1916_0_wc143_cl_atksxzha_096_0419:Y drmgiyo6_iad277:/u02/app/oracle/product/19.0.0.0/db1916_0_wc138_cl_atksxzha_096_0033:Y fflilzax_iad2km:/u02/app/oracle/product/19.0.0.0/db1916_0_wc145_cl_atksxzha_096_0411:Y gytjhr9o_iad2tt:/u02/app/oracle/product/19.0.0.0/db1916_0_wc144_cl_atksxzha_096_0411:Y dqk29prh_iad2hc:/u02/app/oracle/product/19.0.0.0/db1916_0_wc146_cl_atksxzha_096_0416:Y utynogge_iad2p8:/u02/app/oracle/product/19.0.0.0/db1916_0_wc147_cl_atksxzha_096_1213:Y my06yvoe_iad2km:/u02/app/oracle/product/19.0.0.0/db1916_0_wc149_cl_atksxzha_096_1218:Y nfcteuzf_iad2j9:/u02/app/oracle/product/19.0.0.0/db1916_0_wc148_cl_atksxzha_096_1216:Y opctl_avm_maint_user01@atpd-exa-suzzm1:~$

    opctl_avm_maint_user01@atpd-exa-suzzm1:~$ execsql utynogge_iad2p8

    SQL*Plus: Release 19.0.0.0.0 - Production on Thu Oct 6 06:32:11 2022 Version 19.16.0.1.0 Copyright (c) 1982, 2020, Oracle. All rights reserved. Last Successful login time: Thu Oct 06 2022 06:29:09 +00:00 Connected to: Oracle Database 19c EE Extreme Perf Release 19.0.0.0.0 - Production Version 19.16.0.1.0 SQL> SELECT INSTANCE_NAME, STATUS, DATABASE_STATUS FROM V$INSTANCE; INSTANCE_NAME STATUS DATABASE_STATUS ---------------- ------------ ----------------- utynogge1 OPEN ACTIVE SQL> SELECT sys_context('userenv','instance_name') FROM dual; SYS_CONTEXT('USERENV','INSTANCE_NAME') -------------------------------------------------------------------------------- utynogge1 SQL> !whoami SP2-0738: Restricted command "! (HOST)" not available SQL> !ls -ltr SP2-0738: Restricted command "! (HOST)" not available SQL>

Scripts to be run as below with aliases.
  • /var/opt/oracle/adbd/apps/job_manager/job_manager.py --get_status adbd_archive_log_ilkzdar1

    To be run as: job_manager --get_status adbd_archive_log_ilkzdar1

  • /var/opt/oracle/pylib/DBAAS/service_driver.py --dbname=hr5zxn5l_cdg1bg

    To be run as: service_driver --dbname=hr5zxn5l_cdg1bg

  • /var/opt/oracle/bkup_api/bkup_api --dbname ilkzdar1 list jobs

    To be run as: backup_api --dbname ilkzdar1 list jobs

Limit Operator's Access to a Specific Customer-Approved Autonomous Container Database (ACD)

Restrict access to a specific ACD in an autonomous VM cluster in the diagnostics and maintenance cages.

Operators can specify if they need:

  • SSH-only access to the autonomous VM cluster without SQL access to the ACDs. In this case, all SQL access to the ACDs will be blocked.
  • SSH access to the autonomous VM cluster and SQL access to the ACDs. If they select both, they must select one or more ACDs.

The customer receives an approval request with the details that the operators are requesting access to. That way, the customer can be assured that the operators will have access to the right ACD. Once the customer approves the access request, the operators will get SQL access to only the ACDs they have been approved for.

The Request Reason attribute will display which ACDs the operators are requesting access to.

Operator Access Control Actions: Compute Cloud@Customer

Occasionally, authorized operators need to access resources to upgrade Compute Cloud@Customer, troubleshoot or help resolve an issue.

Parent topic: Enforcement of Actions in Operator Access Control

Action: Compute Cloud@Customer Infrastructure Full Access

Compute Cloud@Customer Infrastructure Full Access is identified as CCC_SYS_ADMIN_FULL_ACCESS.

Table 1-9 Actions Enabled with CCC_SYS_ADMIN_FULL_ACCESS

Action Name

Full System Access
Action Identifier

CCC_SYS_ADMIN_FULL_ACCESS
Operator Privileges

Linux User Privilege: Non-root

Can su to root: yes

Chroot caged: No

Directories Readable: All

Files Readable: All

Directories Writeable: All

Files Writeable: All

List of commands executable: All

Can su into: root through sudo and execute all commands as the root user

Limits for Operator Access Control

Operator Access Control is a solution designed for auditing and compliance of Oracle access, not a general purpose compliance solution.

Operator Access Control only audits authorized users created in the context of an access request associated with an Oracle Operator Access control. The following is a list of examples of compliance audit and control actions that Operator Access Control does not address.

  • Operator Access Control controls only the layers that Oracle owns. For example, Operator Access Control controls access to the physical Exadata Database Server and Exadata Storage Server.
  • Operator Access Control does not control automation actions, including the actions that are run as root, or other high privileged automation users, including proxy-based automation access.
  • Operator Access Control only offers controls at the level of defined Actions. The Actions themselves control access to an application at the operating system level.
  • Operator Access Control is not a general auditing service. It only audits authorized users created in the context of an access request associated with an Operator Control.
  • Operator Access Control only controls different layers in the Exadata Cloud@Customer systems. It doesn't offer controls on external entities of Oracle Cloud Infrastructure, such as switches, or other control plane software.

Customer Tenancy Job Roles for Operator Access Control

To establish operator access control, you set up access control policies, and establish user groups responsible for managing and monitoring access to your infrastructure.

Parent topic: Overview of Oracle Operator Access Control

Operator Control Creation for Policy Administrators

Policy administrators are the users who have permissions to set up operator control policies (called Operator Control).

To create operator access control over your infrastructure, the first step is to create Operator Control policy administrators that develop and create the set of operator controls that you want to use for your tenancy fleet administrators.

Typically, when you create operator controls, you divide the Exadata infrastructure into access control groups based on multiple dimensions:

  • Business Critical: Critical systems, less critical systems, development systems
  • Security or Compliance: Systems with specific compliance needs and others
  • User Groups: Which user groups (usually with fleet administrator role) you want to make responsible for a set of Exadata systems

Some examples of the user groups responsible for a set of Exadata systems:

  • Vertical departments, whose applications depend on a set of Exadata systems.
  • Systems shared across several departments, for which an IT department is responsible for administration.

Typically, you create compartments on your infrastructure based on criteria of criticality, regulatory compliance, and user group management, because compartments form the logical administrative boundaries in Oracle Cloud Infrastructure. Usually, each compartment has a user group that is granted management privileges on the compartment. For this reason, your Policy Administrator should create as many operator controls as there are compartments holding Exadata infrastructures.

In addition to specific operator controls for compartments, you must also create an additional policy, called DEFAULT_OPERATOR_CONTROL, that you can use to create new sets of Exadata systems in new compartments, for which you can create a different set of administrative users.

How Operator Access Requests Are Approved

See how you can manage operator control approvals by setting up an Identity and Access Management (IAM) regime using Oracle Operator Access Control policies.

Tenancy administrators for Operator Controls for an Oracle Cloud system are members of the operator control administrator group for Operator Controls. You receive operator control requests for access to Oracle Cloud Infrastructure. To support your regulatory compliance requirements, you can govern access to your infrastructure. You can specify that some actions are always in the status auto-approved, and specify that other actions must receive approval before Oracle can perform system maintenance operations in your tenancy. When you grant access to your system, that access is automatically limited to a standard time duration. You can also specify that operations must take place within a specific timeframe that you specify.

Example 1-1 Operator Controls for an Oracle Cloud Infrastructure IAM policy

You can set fine-grained controls on the permissions that you grant on your system.

For example, suppose you have two groups of Exadata Cloud systems in a compartment for which you are the tenancy administrator. As part of your IAM policy, you have created two separate sets of Exadata systems: The first group of systems has all Operator Policy configurations set to pre-approved, and the second group of systems has no Operator Policy configured to pre-approved.

You have also created two groups of users: PRE_APPROVED_POLICY_USERS, and EXPLICIT_APPROVED_POLICY_USERS. The Operator Control groups are identified by the tagging you provide: Namespace optctl has two Operator Control groups. One is identified by the tag pre-approved-exacc. The second group is identified by the tag explicit-approved-exacc. So, broadly, you have a set of servers where all actions are pre-approved, and a set of servers where no actions are pre-approved.

Next, In your compartment, suppose you have established a set of Exadata Cloud resources, each of which represents a level of actions permitted:

  • system_diag specifies permissions for actions to diagnose any issue in the Exadata Cloud@Customer infrastructure layer, such as reading logs, running diagnostic and monitoring commands. You grant members of this policy the INFRA_DIAG action.
  • system_main specifies permissions for actions to perform system diagnostics and maintenance, but also the option to restart the system. You grant members of this policy the INFRA_UPDATE_RESTART action, but the authorization is set specify authorization.
  • system_all grants full system administration privileges permissions on the system, including unrestricted use of sudo. You grant members of this policy the INFRA_FULL action. You have no policy group created with this Action.

For the resources where you have set up the system_diag policy, you have marked as pre-approved all administration activities permitted by that action. You have specified that members of the group PRE_APPROVED_POLICY_USERS is granted access to use system_diag with pre-approved status in the tenancy

Next, suppose an Oracle operator with PRE_APPROVED_POLICY_USERS group membership requests access to a server, but requests the action INFRA_UPDATE_RESTART because a maintenance action requires a restart. The Oracle operator must still request access for the Action that permits an operator to restart the system as part of a maintenance action. You grant access to the system_main policy, but all actions that require this policy access require approval.

Note that at any point in time, as an administrator, regardless of existing group memberships or approval, you can revoke the access to the operator. If you remove an Oracle operator from the group membership, then the operator will have no access to the system.

How Operator Access is Audited

Learn how logs are captured and how you can audit operator activities.

Note

The audit logs are collected using the auditd subsystem in the Linux kernel. To add Operator Access Control rules to collect the logs, you must reboot the Exadata system after assigning an Operator Control the first time. You need not reboot the Exadata system for the subsequent assignments.

Extent of Audit Logs Captured

Operator Access Control service logs the actions performed by the operator on a controlled system. The logs are captured for two broad categories.
  • Lifecycle event logs
  • Command logs

The first being lifecycle events and the second being commands run by the operator on the target hosts.

Lifecycle Event Logs

Operator Access Control service captures login and logout events only for the Operator Access Control service authorized users and it does not capture automation login events.

Command Logs

Operator Access Control service captures all commands run by the authorized users on a shell. It captures the command input without any redaction and it does not capture the command output. It also captures all shell commands run using shell scripts.

For example, Operator Access Control service captures the following command: 
netstat -an | grep 8080
Additionally, the commands run using the shell script searchlog.sh in this case are also captured.
./searchlog.sh –process "cellservice"
The command logs include commands run by a user even after an su has been done. For example, after logging in, if the authorized user auth_user_123 runs the following commands, then Operator Access Control service captures all of these commands.
su - celladmin
tail -n 10 /var/log/messages

Keyboard Logging

Additionally, the command logs can also be captured in the keyboard log format. Keyboard logging captures every keystroke the operators type on their computers. It does not serve a lot of practical purposes to capture keyboard logging, however, there are cases where regulatory requirements need to capture keystroke logging.

Items Not Logged

Operator Access Control service does not log automation commands or lifecycle events. While this service logs all commands issued to the shell either directly or through invocation of shell scripts, it does not log actions performed by the binary executables. Hence if an operator logs into the cell server and then gets into a cellcli shell, the logs will be limited to capturing the cellcli shell commands alone. Operator Access Control service does not log commands run inside the cellcli.

Format of Audit Logs

The audit logs are formatted as JSON text. Audit logs are categorized into two parts β€” the raw data and the interpreted data. The raw data is not comprehensible outside the context of a Linux machine where the log was captured. For example, the raw data does not refer to Linux user names, rather it refers to internal identifiers instead. Mapping the identifier to user can only be done on the Linux machine where the log was captured.

In addition to the interpretation, the format also sets the context by providing the "access request ID" in the logs.

Lifecycle Event Logs

The following two examples give the format of the audit log for lifecycle events. The examples show a login and a logout event. The username used for this login is "USERNAME".

Example 1-2 Login Event Log

{
"layer": "CPS",
"req_auth_id": "1",
"srchost": "dhcp-10-191-235-63.vpn.example.com",
"res": "success'",
"desthost": "10.191.235.63",
"pid": "89736",
"tty": "/dev/pts/2",
"host": "scaqae08dv0605m",
"time": "Thu Oct 29 03:20:22 2020",
"raw_data": "type=USER_LOGIN msg=audit(10/29/2020 03:20:22.091:10777414) : pid=89736 uid=root auid=USERNAME ses=75141 msg='op=login id=USERNAME exe=/usr/sbin/sshd hostname=dhcp-10-191-235-63.vpn.example.com addr=10.191.235.63 terminal=/dev/pts/2 res=success' \n",
"event": "login",
"loginid": "USERNAME"
}

Example 1-3 Logout Event Log

{
"layer": "CPS",
"req_auth_id": "1",
"srchost": "dhcp-10-191-235-63.vpn.example.com",
"res": "success'",
"desthost": "10.191.235.63",
"pid": "90456",
"tty": "ssh",
"host": "scaqae08dv0605m",
"time": "Thu Oct 29 03:20:35 2020",
"raw_data": "type=USER_LOGOUT msg=audit(10/29/2020 03:20:35.855:10777438) : pid=90456 uid=root auid=USERNAME ses=75142 msg='op=login id=USERNAME exe=/usr/sbin/sshd hostname=dhcp-10-191-235-63.vpn.example.com addr=10.191.235.63 terminal=ssh res=success' \n",
"event": "logout",
"loginid": "USERNAME"
}

Command Logs

The command logs are more elaborate. They provide information about the command, the parameters of the command the effective user executing the command. The commands also have a hierarchy in the sense that a shell script execution will first have a bash -c logged and then the script commands.

Example 1-4 Command Execution

{
"layer": "CPS",
"req_auth_id": "1",
"title": "ls\u0000/",
"raw_data": "type=PROCTITLE msg=audit(10/29/2020 03:20:29.418:10777424) : proctitle=ls / \ntype=PATH msg=audit(10/29/2020 03:20:29.418:10777424) : item=1 name=/lib64/ld-linux-x86-64.so.2 inode=1182648 dev=f9:00 mode=file,755 ouid=root ogid=root rdev=00:00 nametype=NORMAL \ntype=PATH msg=audit(10/29/2020 03:20:29.418:10777424) : item=0 name=/usr/bin/ls inode=1189225 dev=f9:00 mode=file,755 ouid=root ogid=root rdev=00:00 nametype=NORMAL \ntype=CWD msg=audit(10/29/2020 03:20:29.418:10777424) : cwd=/ \ntype=EXECVE msg=audit(10/29/2020 03:20:29.418:10777424) : argc=2 a0=ls a1=/ \ntype=SYSCALL msg=audit(10/29/2020 03:20:29.418:10777424) : arch=x86_64 syscall=execve success=yes exit=0 a0=0xfff6d0 a1=0xff42d0 a2=0xfff960 a3=0x7ffc1dd337e0 items=2 ppid=90474 pid=90764 auid=USERNAME uid=USERNAME gid=USERNAMg euid=USERNAME suid=USERNAME fsuid=USERNAME egid=USERNAMg sgid=USERNAMg fsgid=USERNAMg tty=pts2 ses=75141 comm=ls exe=/usr/bin/ls key=(null) \n",
"args": [],
"rec_id": "10777424",
"tty": "pts2",
"host": "scaqae08dv0605m",
"time": "Thu Oct 29 03:20:29 2020",
"loginid": "USERNAME"
}

The field title provides the command that was executed. The raw data provides much more information.

Frequency of Collection

Operator Access Control service collects the logs as and when the events happen, timestamps, and pushes the logs to the logging service periodically. It attempts to push the logs in every 30 second intervals.

Accessing Audit Logs

You can access audit logs through the logging service. For more information, see Logging Overview.

The JSON shown in section 2 is available in the logging service. Use your tenancy to access the logging service. The logs are posted to the compartment on which the Operator Control was created. The logs are tagged to the Operator Control.

Retention Policies of Audit Logs

The audit logs are retained in the user tenancy and therefore Operator Access Control service does not control the lifetime of audit logs. You can control control the duration of retention period. However, if this service could not push the logs to user tenancy, then it will try to retain the logs to the extent allowed by Exadata configurations. The retention period is considerable, that is, running into days or longer.

Forwarding Operator Access Control Audit Logs to SIEM Systems

You can choose to forward Operator Access Control audit logs directly from Exadata Cloud@Customer to the security information and event management (SIEM) systems in your data center.

To improve your security management, you can transmit audit logs to the OCI Logging service and to the SIEM systems in your data centers. To transmit these audit logs to SIEM systems, syslog over TCP is used.

Parent topic: Overview of Oracle Operator Access Control

Deploying a Syslog Server in Your Data Center

To receive audit logs from Exadata Cloud@Customer, deploy a Syslog server in your data center. The Syslog server can be of your choice. Most Linux systems ship with rsyslog.

You can forward audit logs to only one Syslog server for each target Exadata Cloud@Customer system. Oracle supports secure communication only, and uses TLS for transmission security. The Control Plane Server connects with the Syslog server, and delivers all audit logs over secure TCP. To establish trust between the Control Plane Server and the Syslog server, use a PEM format Syslog server CA certificate file. The file extension must be .pem, .cer, or .crt. For more information about configuration, see Example Syslog Server Configuration.

The log contains elements already described in the chapter Managing and Searching Logs with Operator Access Control. The format is ensured to be compatible with syslog and audit-d log parsers. See the example audit log.

Sending audit logs to SIEM systems is on a best effort basis. While the Control Plane Server retries sending logs on network failures, packets can drop silently on thresholds. In such cases, the logs surfacing through the OCI Logging service are the reference.

Note

To forward audit logs, you must assign at least one Operator Control to the Exadata Cloud@Customer system indefinitely (ALWAYS ASSIGNED).

Example Syslog Server Configuration

To see how you can configure a Syslog server of your choice, use this example.

Before you attempt to configure the Syslog server, you must be prepared to do the following:
  1. Open a network port for receiving remote logs.
    Note

    Egress rules for the Syslog server should be open for Syslog Port. For Example, if the 6514 port is used for Syslog, then the Egress Security rule should be in place to allow traffic to reach Syslog from Autonomous VM Cluster.
  2. Enable encryption on the Syslog server for remote communication.
  3. (Optional) Generate and transfer a root certificate for secure communication.
Note

The example given below is for configuring a rsyslog server (v 8.24) on a machine with Oracle Linux 7. The configuration is generally available at /etc/rsyslog.conf. Only the relevant sections are covered in this example.

For this example, the listening port is 10514. There are multiple sources available on the Internet to assist you with encrypting Syslog traffic. A good reference is Encrypting Syslog Traffic with TLS (SSL) [short version] β€” rsyslog 8.18.0.master documentation. 

# rsyslog configuration file (8.24.0 - /etc/rsyslog.conf - Oracle Linux 7)
# For more information see /usr/share/doc/rsyslog-*/rsyslog_conf.html
# If you experience problems, then see http://www.rsyslog.com/doc/troubleshoot.html

#### MODULES $ModLoad imuxsock # provides support for local system logging (e.g. via logger command)# Provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 10514

...# certificate files
$DefaultNetstreamDriverCAFile /var/gnutls1/ca.pem
$DefaultNetstreamDriverCertFile /var/gnutls1/cert.pem
$DefaultNetstreamDriverKeyFile /var/gnutls1/key.pem$ModLoad imtcp # load TCP listener$InputTCPServerStreamDriverMode 1 # run driver in TLS-only mode
$InputTCPServerStreamDriverAuthMode anon # client is NOT authenticated
#$InputTCPServerStreamDriverAuthMode x509/name # client is NOT authenticated
$InputTCPServerRun 10514 # start up listener at port 10514
...

Testing Connectivity Between CPS and the Syslog Server

Ensure that you have provided a valid IP address or host name for the Syslog server.

The Syslog server must be able to receive logs from a Syslog client, and it must be reachable from Exadata Cloud@Customer. To confirm your configuration, use this procedure.
  1. To validate that the Syslog server can receive logs, run the nc command towards the Syslog server and Syslog port from any host in your network having access to the Syslog server.
    nc syslog server host syslog port
  2. To ensure the path between Exadata Cloud@Customer and the Syslog server is valid, ping the Exadata Cloud@Customer Control Plane Server IP address. To obtain the Control Plane Server (CPS) IP address, contact your network administrator.

Example of Audit Logs

As an administrator, see examples of the audit logs received securely from the Control Plane Server.

When you transmit logs to the Syslog server, many headers and the JSON formatting are omitted. The following examples show the nature of data shipped through Syslog.

Example 1-5 1

Apr 12 07:38:22 scaqar05dv0511m opctl: type=USER_LOGIN msg=audit(04/12/2021 07:38:05.752:1742859) : 
pid=65327 
uid=root 
auid=830916abb78e4157b9e45b641e34fcf6 ses=32770 
msg='op=login id=830916abb78e4157b9e45b641e34fcf6 
exe=/usr/sbin/sshd 
hostname=localhost.localdomain 
addr=127.0.0.1 
terminal=/dev/pts/3 res=success'

Example 1-6 2

Apr 12 07:38:22 scaqar05dv0511m opctl: type=USER_LOGOUT msg=audit(04/12/2021 07:38:08.802:1742867) : 
pid=65327 
uid=root 
auid=830916abb78e4157b9e45b641e34fcf6 
ses=32770 
msg='op=login 
id=830916abb78e4157b9e45b641e34fcf6 exe=/usr/sbin/sshd 
hostname=? 
addr=? 
terminal=/dev/pts/3 res=success'

Was this article helpful?