Exadata Cloud Infrastructure is jointly managed by the customer and Oracle, and is divided into two areas of responsibility.

Customers control and monitor access to customer services, including network access to their VMs (through OCI Virtual Cloud Networks and OCI Security Lists), authentication to access the VM, and authentication to access databases running in the VMs. Oracle controls and monitors access to Oracle Managed Infrastructure components and physical server security. Oracle staff are not authorized to access customer services, including customer VMs and databases except where customers are unable to access the customer VM.

Customers access Oracle Databases (DB) running on Exadata Cloud Infrastructure via client and backup VCNs to the databases running in the customer VM using standard Oracle database connection methods, such as Oracle Net on port 1521. Customer’s access the VM running the Oracle databases via standard Oracle Linux methods, such as token based ssh on port 22.

Secutrity features offered by Exadata Cloud Infrastructure.

• Oracle Cloud Physical Security

  Oracle Cloud data centers align with Uptime Institute and Telecommunications Industry Association (TIA) ANSI/TIA-942-A Tier 3 (99.982% Availability) or Tier 4 (99.995% Availability) standards and follow a N2 ('N' stands for Need) redundancy methodology for critical equipment operation. Data centers housing Oracle Cloud Infrastructure services use redundant power sources and maintain generator backups in case of widespread electrical outage. Server rooms are closely monitored for air temperature and humidity, and fire-suppression systems are in place. Data center staff are trained in incident response and escalation procedures to address security and availability events that may arise. For more information see: Oracle Cloud Infrastructure Security Guide. For further details on Oracle Cloud Infrastructure Data Center compliance, see Oracle Cloud Compliance. Also see: Oracle Corporate Security Practices: Data Security: Physical and Environmental Controls.

• Oracle Data Center Access Controls

  To provide secure systems, Oracle access protocols to physical data centers include the following:

  • Physical access to facilities to data centers is limited to certain Oracle employees, contractors, and authorized visitors.
  • Oracle employees, subcontractors, and authorized visitors are issued identification cards that must be worn while on Oracle premises.
  • Visitors are required to sign a visitor’s register, be escorted and/or observed when they are on Oracle premises, and/or be bound by the terms of a confidentiality agreement with Oracle.
  • Security monitors the possession of keys/access cards, and monitors the ability to access facilities. Staff leaving Oracle’s employment must return keys/cards, and key/cards are deactivated upon termination.
  • Security authorizes all repairs and modifications to the physical security barriers or entry controls at service locations.
  • Oracle use a mixture of 24/7 onsite security officers or patrol officers, depending on the risk/protection level of the facility. In all cases, officers are responsible for patrols, alarm response, and recording of security incidents.
  • Oracle has implemented centrally managed electronic access control systems with integrated intruder alarm capability. The access logs are kept for a minimum of six months. Furthermore, the retention period for CCTV monitoring and recording ranges from 30-90 days minimum, depending on the facility’s functions and risk level.

  For more details about Oracle site access controls, see: Oracle Corporate Security Practices: Oracle Access Control

• Hypervisor Customer Isolation

  The hypervisor is the software that manages virtual devices in a cloud environment, handling server and network virtualization. In traditional virtualization environments, the hypervisor manages network traffic, enabling it to flow between VM instances and between VM instances and physical hosts. This adds considerable complexity and computational overhead in the hypervisor. Proof-of concept computer security attacks, such as virtual machine escape attacks, have highlighted the substantial risk that can come with this design. These attacks exploit hypervisor complexity by enabling an attacker to “breakout” of a VM instance, access the underlying operating system, and gain control of the hypervisor. The attacker can then access other hosts, sometimes undetected. Oracle Cloud Infrastructure reduces this risk by decoupling network virtualization from the hypervisor.

  To address potential attacks, Oracle has implemented a security-first architecture using Isolated network virtualization, which is foundational element of Oracle Cloud infrastructure's architecture. This architecture stops malware in its tracks with a custom-designed SmartNIC to isolate and virtualize the network. Isolated network virtualization reduces risk by limiting the attack surface. Even if a malicious actor succeeds with a VM escape attack on a single host, the virtual architecture is designed so that actor can’t reach other hosts in the cloud infrastructure. The attack is effectively contained to the one host. Secure Isolated network virtualization architecture is implemented in every data center in every region. Every Oracle Cloud Infrastructure tenant is provided with the benefits of this security-first architecture.

  Figure 6-1 Isolated Network Virualization Reduces Risk in Oracle Generation 2 Cloud

  
  Description of "Figure 6-1 Isolated Network Virualization Reduces Risk in Oracle Generation 2 Cloud"
• Multitenant Security

  Consistent with our security philosophy of Defense in Depth, Multitenant has a comprehensive isolation architecture.

  There are four major categories to this, with several important features in each category.

  1. Access Control Mechanism
  2. Prevent Unauthorized Admin Access
  3. Protect from direct access to Data Files
  4. Resource Isolation
  e

  Figure 6-2 Multitenant’s Comprehensive Isolation Architecture

  
  Description of "Figure 6-2 Multitenant’s Comprehensive Isolation Architecture"

• Defense in Depth Exadata Cloud Infrastructure offers a number of controls to ensure confidentiality, integrity, and availability throughout the service.

  First, Exadata Cloud Infrastructure is built from the hardened operating system image provided by Exadata Database Machine (https://docs.oracle.com/en/engineered-systems/exadata-database-machine/dbmsq/exadata-security-overview.html). This secures the core operating environment by restricting the installation image to only the required software packages, disabling unnecessary services, and implementing secure configuration parameters throughout the system.

  In addition to inheriting all the strength of Exadata Database Machine's mature platform, because Exadata Cloud Infrastructure provisions systems for customers, additional secure default configuration choices are implemented in the service instances. For example, all database tablespaces require transparent data encryption (TDE), strong password enforcement for initial database users and superusers, and enhanced audit and event rules.

  Exadata Cloud Infrastructure also constitutes a complete deployment and service, so it is subjected to industry-standard external audits such as PCI, HIPPA and ISO27001. These external audit requirements impose additional value-added service features such as antivirus scanning, automated alerting for unexpected changes to the system, and daily vulnerability scans for all Oracle-managed infrastructure systems in the fleet.

• Least privilege

  Oracle Secure Coding Standards require software processes run at the minimum privilege level to implement their functionality.

  Each process and daemon, must run as a normal, unprivileged user unless it can prove a requirement for a higher level of privilege. This helps contain any unforeseen issues or vulnerabilities to unprivileged user space and not compromise an entire system.

  This principle also applies to Oracle operations team members who use individual named accounts to access the Exadata Cloud Infrastructure for maintenance or troubleshooting. Only when necessary will they use the audited access to higher levels of privilege to solve or resolve an issue. Most issues are resolved through automation, so we also employ least privilege by not permitting human operators to access a system unless the automation is unable to resolve the issue.

• Auditing and accountability

  When required, access to the system is allowed, but all access and actions are logged and tracked for accountability.

  Exadata Cloud Infrastructure audit logs are controlled by Oracle and used for security monitoring and compliance purposes. Oracle can share relevant audit logs with customers per Oracle Incident Response Practices and the Oracle Data Processing Agreement.

  Auditing capabilities are provided at all infrastructure components to ensure all actions are captured. Customers also have ability to configure auditing for their database and guest VM configuration and may choose to integrate those with other enterprise auditing systems.

• Automating cloud operations

  By eliminating manual operations required to provision, patch, maintain, troubleshoot, and configure systems, the opportunity for error is reduced.

• Hardened OS image

  • Minimal package installation:

    Only the necessary packages required to run an efficient system are installed. By installing a smaller set of packages, the attack surface of the operating system is reduced and the system remains more secure.

  • Secure configuration:

    Many non-default configuration parameters are set during installation to enhance the security posture of the system and its content. For example, SSH is configured to only listen on certain network interfaces, sendmail is configured to only accept localhost connections, and many other similar restrictions are implemented during installation.

  • Run only necessary services:

    Any services that may be installed on the system, but not required for normal operation, are disabled by default. For example, while NFS is a service often configured by customers for various application purposes, it is disabled by default as it is not required for normal database operations. Customers may choose to optionally configure services per their requirements.

• Minimized attack surface

  As part of the hardened image, attack surface is reduced installing and running only the software required to deliver the service.

• Additional security features enabled (grub passwords, secure boot)

  • Leveraging Exadata image capabilities, ExaDB-D enjoys the features integrated into the base image such as grub passwords and secure boot in addition to many others.
  • Through customization, customers may wish to further enhance their security posture with additional configurations.
• Secure access methods
  • Accessing database servers via SSH using strong cryptographic ciphers. Weak ciphers are disabled by default.
  • Accessing databases via encrypted Oracle Net connections. By default, our services are available using encrypted channels and a default configured Oracle Net client will use encrypted sessions.
  • Accessing diagnostics via Exadata MS web interface (https).
• Auditing and logging
  • By default, auditing is enabled for administrative operations and those audit records are communicated to OCI internal systems for automated review and alerting when required.

Several user accounts regularly manage the components of Exadata Cloud Infrastructure. These users are required and may not be modified.

In all ExaDB-D machines, Oracle uses and recommends token-based SSH login.

There are three classes of users:

• Default Users: No Logon Privileges
  
• Default Users WITH RESTRICTED SHELL Access
  These users are used for accomplishing a defined task with a restricted shell login. These users should not be removed as the defined task will fail in case these users are deleted.
• Default Users with Login Permissions
  These privileged users are used for accomplishing most of the tasks in the system. These users should never be altered or deleted as it would have significant impact on the running system.

In addition to all of the Exadata features explained in Security Features of Oracle Exadata Database Machine, the following security settings are also applicable, to Exadata Cloud Infrastructureinstances.

• Custom database deployment with non-default parameters.
  The command host_access_control is to configure Exadata security settings:

  • Implementing password aging and complexity policies.
  • Defining account lockout and session timeout policies.
  • Restricting remote root access.
  • Restricting network access to certain accounts.
  • Implementing login warning banner.
• account-disable: Disables a user account when certain configured conditions are met.
• pam-auth: Various PAM settings for password changes and password authentication.
• rootssh: Adjusts the PermitRootLogin value in /etc/ssh/sshd_config, which permits or denies the root user to login through SSH.
  • By default, PermitRootLogin is set to no.
  • PermitRootLogin=without-password is required for the cloud automation to perform some lifecycle management operations, disabling root login will cause that service functionality to fail.
• session-limit: Sets the * hard maxlogins parameter in /etc/security/limits.conf, which is the maximum number of logins for all users. This limit does not apply to a user with uid=0.

  Defaults to * hard maxlogins 10 and it is the recommended secure value.

• ssh-macs: Specifies the available Message Authentication Code (MAC) algorithms.
  • The MAC algorithm is used in protocol version 2 for data integrity protection.
  • Defaults to hmac-sha1, hmac-sha2-256, hmac-sha2-512 for both server and client.
  • Secure recommended values: hmac-sha2-256, hmac-sha2-512 for both server and client.
• password-aging: Sets or displays the current password aging for interactive user accounts.
  • -M: Maximum number of days a password may be used.
  • -m: Minimum number of days allowed between password changes.
  • -W: Number of days warning given before a password expires.
  • Defaults to -M 99999, -m 0, -W 7
  • --strict_compliance_only-M 60, -m 1, -W 7
  • Secure recommended values: -M 60, -m 1, -W 7

A list of the processes that run by default on the customer VM, also called DOMU, or Guest VM and Guest OS

• Exadata Cloud Infrastructure VM agent:

  Cloud agent for handling database lifecycle operations.

  • Runs as opc user
  • Process table shows it running as a Java process with jar names - dbcs-agent-VersionNumber-SNAPSHOT.jar and dbcs-admin-VersionNumver-SNAPSHOT.jar.
• Oracle Trace File Analyzer agent:

  Oracle Trace File Analyzer (TFA) provides a number of diagnostic tools in a single bundle, making it easy to gather diagnostic information about the Oracle database and clusterware, which in turn helps with problem resolution when dealing with Oracle Support

  • Runs as root user
  • Runs as initd demon (/etc/init.d/init.tfa)
  • Process tables show a Java application (oracle.rat.tfa.TFAMain)
  • Runs as root and exawatch users.
  • Runs as backgroud script, ExaWatcher.sh and all its child process run as a Perl process.
  • Process table shows as multiple Perl applications.ExaWatcher:
• Database and GI (clusterware):
  • Runs as dbmsvc and grid users
  • Process table shows following applications:
    • oraagent.bin, apx_* and ams_* as grid user
    • dbrsMain, and Java applications - derbyclient.jar, weblogic.Server as oracle user.
• Management Server (MS):

  Part of Exadata image software for managing and monitoring the image functions.

  • Runs as dbmadmin.
  • Process table shows it running as a Java process.

• Guest VM Network Security
  
• Compliance Requirements
  

Default database security features enabled and used:

• Transparent Database Encryption (TDE) is used for database tablespaces created by Oracle Database Cloud tools.
  • CDB$ROOT: users tablespace is encrypted
  • PDBs: all tablespaces encrypted
  • Wallet password is provided during initial DB creation. Wallet passwords may be changed using dbaascli. Customers should change this password periodically.
• Users in the database
  • No additional users are created in the database.
  • After DB creation, all DB users are locked except for SYS, SYSTEM and DBSNMP.
  • Auditing is enabled for the following operations:
    • DATABASE LINK
    • PUBLIC DATABASE LINK
    • PUBLIC SYNONYM
    • DROP ANY PROCEDURE
    • PROCEDURE
    • ALTER SYSTEM
    • TRIGGER
    • CREATE DATABASE LINK
    • ALTER DATABASE LINK
    • CREATE PROCEDURE
    • ALTER SYSTEM
    • CREATE TRIGGER
    • CREATE ANY TRIGGER
    • SELECT ANY DICTIONARY
    • DB VERSION_11_2: EXEMPT REDACTION POLICY
    • DB VERSION_12_1 or DB VERSION_12_2: BECOME USER
    • DB VERSION_12_1: SESSION
    • DBAASSECURE profile is created and it is set as default profile for database user account.

• Native SQL*Net encryption for all network connections - Relevant sqlnet.ora parameters set in Exadata Cloud Infrastructure by default are:

  • SQLNET.ENCRYPTION_TYPES_SERVER = (AES256, AES192, AES128)

  • SQLNET.ENCRYPTION_SERVER = requested

  • SQLNET.CRYPTO_CHECKSUM_SERVER = accepted

  • SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA256, SHA384, SHA512)

• TCPS protocol offered for network connection to the database on port 2484 (wallet configured at /var/opt/oracle/dbaas_acfs/grid/tcps_wallets). Relevant sqlnet.ora parameters set in Exadata Cloud Infrastructure by default are:

  • SSL_CIPHER_SUITES = (SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, 
    SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, 
    SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 
    SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384)

  • WALLET_LOCATION = (SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/var/opt/oracle/dbaas_acfs/grid/tcps_wallets)))

  • SQLNET.IGNORE_ANO_ENCRYPTION_FOR_TCPS = TRUE

  • SSL_VERSION = 1.2

• Remote listener registration - listeners run from GI home. Exadata Cloud Infrastructure deployments the Grid Infrastructure vresion speified in Oracle Support Document 2333222.1 (Exadata Cloud Service Software Versions). Exadata Cloud Infrastructure default configuration includes listener.ora parameter VALID_NODE_CHECKING_REGISTRATION_LISTENER=SUBNET combined with REMOTE_REGISTRATION_ADDRESS_<SCANLISTENER>=<value> to restrict remote listener registrations for security purposes.
• OCI Vault integration - TDE encryption key may be stored in OCI Vault (a Key Management System). For more information and instructions to configure principals, vaults, etc. see Customer-Managed Keys in Exadata Cloud Infrastructure. Both private vs shared vault types are supported for Exadata Cloud Infrastructure OCI Vault integration. DB user authentication is not integrated with OCI Vault.

OS/VM backups:

Oracle does a full backup of guest VM weekly and maintains one or more backup copies. These backups are full disk snapshots of the guest VM (local OS filesystems, not ASM disk groups which reside on Exadata storage). This backup is triggered at a preset time every week. The backups are stored locally in the dom0. Customers can request Oracle to restore the guest VM image from the most recent backup by filing a My Oracle Support (MOS) Service Request (SR). Oracle cannot restore specific files from the image backup. Customers should perform file level backups in the guest VM if they require the ability to perform single-file restore.

Managed DB backups:

• Weekly full backup (level 0)
• Daily rolling incremental backup (level 1) on seven day cycle
• Automatic backups daily at a specific time set during the database deployment creation process

Retention period for backups vary from 30 days (on Object Storage) to 7 days (on local storage)

Encryption:

• Both Object Storage and local storage: All backups to cloud storage are encrypted.
• Object Storage only: All backups to cloud storage are encrypted.

All backups can be configured via CP UI or CP API.

All backups are encrypted with the same master key used for Transparent Data Encryption (TDE) wallet encryption.

Only automated tooling is permitted to access guest VM for purposes of lifecycle automation.

One specific use case is when guest VM is unable to boot. In this case, customers must provide permission to access the guest VM for recovery purposes. Details to handle this scenario are described in section "Exception Workflows" of Exadata Cloud Service Security Controls.

Customers control and monitor access to customer services, including network access to their guest VMs (through layer 2 VLANs and firewalls implemented in the guest VM), authentication to access the guest VM, and authentication to access databases running in the guest VMs. Oracle controls and monitors access to Oracle-managed infrastructure components. Oracle staff are not authorized to access customer services, including guest VMs and databases.

PII ( Personally Identifiable Information ) This information is considered confidential and sensitive, and must be protected to prevent unauthorized use of personal information for the purposes of legal regulation, financial liability, and personal reputation.

You must configure a set of explicit rules to prevent Personally Identifiable Information (PII) from being displayed in your data.

The default Application Performance Monitoring rules hide PII in URLs by recognizing monetary values, bank-account numbers, and dates. However, the default rules only catch obvious PII and are not exhaustive. You must evaluate the default rules and further configure rules to ensure correct reporting in your environment and ensure that PII is not displayed in your data.

For more information, see Hide Personally Identifiable Information and Security and Personally Identifiable Information

Backup Retention

When you enable the Automatic Backup feature, the service creates daily incremental backups of the database to Object Storage. The first backup created is a level 0 backup. Then, level 1 backups are created every day until the next weekend. Every weekend, the cycle repeats, starting with a new level 0 backup.

If you choose to enable automatic backups, you can choose one of the following preset retention periods: 7 days, 15 days, 30 days, 45 days, or 60 days. The system automatically deletes your incremental backups at the end of your chosen retention period.

For more information, see Manage Database Backup and Recovery on Oracle Exadata Database Service on Dedicated Infrastructure

Audit Log Retention Period

The OCI Audit service provides records of API operations performed against supported services as a list of log events. By default, Audit service records are retained for 365 days.

For more information, see Audit Log Retention Period

Service Log Retention

Oracle Cloud Infrastructure services, such as API Gateway, Events, Functions, Load Balancing, Object Storage, and VCN Flow Logs emit service logs. Each of these supported services has a Logs resource that allows you to enable or disable logging for that service. By default, Log retention is 1 month, but it can be set until 6 months.

Logs groups can be used to limit access to sensitive logs generated by services using IAM policy. You don't have to rely on complex compartment hierarchies to secure your logs. For example, say the default log group in a single compartment is where you store logs for the entire tenancy. You grant access to the compartment for log administrators with IAM policy as you normally would. However, let's say some projects contain personally identifiable information (PII) and those logs can only be viewed by a select group of log administrators. Log groups allow you to put logs that contain PII into a separate log group, and then use IAM policy to restrict access to all but a few log administrators.

For more information, see Service Logs and Managing Logs and Log Groups

There are situations where some problems can only be resolved by Oracle logging into the customer guest VM.

Below are situations where customer's guest VM access is require and recommended procedures for accessing guest VM:

1. Situations where the starter database is not yet created and customer do not have ssh access to their guest VM yet. An example would be SR opened by customer to troubleshoot why customer is unable to create a starter database. In this situation, customer never had access to guest VM and no database have yet been created and hence no customer data exists in guest VM.

   As per the security policy associated with ExaDB-D service, Oracle personnel are prohibited to access customer guest VM without customer’s explicit permission. To comply with this policy, Oracle requires to get Customer permission to access guest VM by asking the following question.

   “In order for Oracle to resolve the issue described in this SR, we need customer’s explicit permission allowing us to login to customer guest VM. By giving us explicit permission to access guest VM, you are confirming that there is no confidential data that is stored in customer guest VM or associated databases and customer security team is authorizing Oracle to have access to customer guest VM in order for Oracle to help fix this issue. Do I have your explicit permission to access guest VM?"

   After affirmative response by customer, Oracle support staff can login to customer guest VM to resolve the issue.

2. Situations where a number of databases exist in customer system and customer have access to guest VM but now support needs to login to guest VM to resolve one of the many situations

   We have encountered ( Nodes doesn’t start because of changes on guest VM, eg. Non-existing mounts in fstab, need to run fsck, Hugepage / sysctl conf modification or lvm backup not completed successfully, fstab has wrong entries for non-existing mounts, customer changed the sshd configurations or permissions in /etc/ssh/sshd_config file, etc.) or simply because customer wants Oracle to help resolve the issue they are facing.

   This case is more serious than the first one as there could be some sensitive data in customer guest VM file system or database. In this case, our support staff will be required to ask the customer to open a new explicit SR specifically to get this permission with the following SR title and content.

   As per the security policy associated with ExaDB-D service, Oracle personnel are prohibited to access customer guest VM without customer’s explicit permission. For Oracle to comply with this policy, We are required to ask you to open a new SR with exact language as shown below granting Oracle an explicit permission to access guest VM.Please note any modification to the language below may delay resolution of your SR.

   New SR Title: SR granting Oracle explicit permission to access DomU of ExaDB-C@C with AK serial number AK99999999

   New SR Content: We are opening this SR to grant explicit permission to Oracle to access our DomU in order for support to help resolve issue described in SR# 1-xxxxxxxx.

   We acknowledge that by providing this permission, we understand that Oracle will have access to ALL FILES in DomU and agree that there are no confidential

   files stored in any of the file systems in DomU. In addition, we also agree that customer security team has authorized Oracle to have access to customer DomU

   in order to resolve the issue described in the above SR.

   After affirmative response by customer in the above SR, Oracle support staff can login to customer guest VM to resolve the issue.

A list of Oracle Cloud Operations responsibilities and customer responsibilities for various operations by components

• KMS Integration (HSM keys)
  
• Using Non-default Encryption Algorithms for TDE Tablespace Encryption