Oracle Exadata Database Service on Exascale Infrastructure is jointly managed by the customer and Oracle.

The Oracle Exadata Database Service on Exascale Infrastructure deployment is divided into two areas of responsibility:

Customer accessible services: components that the customer can access as part of their subscription to Oracle Exadata Database Service on Exascale Infrastructure

• Customer accessible virtual machines (VM)
• Customer accessible database services

Oracle Managed Infrastructure: components that are owned and operated by Oracle to run customer accessible services

• Power Distribution Units (PDUs)
• Out of band (OOB) management switches » InfiniBand switches
• Exadata Storage Servers
• Physical Exadata database servers
• Datacenter security which hosts Exadata Servers with customer information

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. See the Exadata Cloud Service Security Controls document, https://www.oracle.com/a/ocom/docs/engineered-systems/exadata/exadata-cloud-service-security.pdf, Exception Workflows .

Customers access Oracle databases (DB) running on Oracle Exadata Database Service on Exascale 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 Oracle Exadata Database Service on Exascale 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, and see Oracle Cloud Compliance.

• Operator access to customer systems

  Oracle access protocols include:

  • Physical access to facilities 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 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.
• 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 VMinstance, 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. We’ve implemented network virtualization as a highly customized hardware and software layer that moves cloud control away from the hypervisor and host, and puts it on its own network. This hardened and monitored layer of control is what enables isolated network virtualization. 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, it’s designed so they can’t reach other hosts in the cloud infrastructure. The attack is effectively contained to the one host. Isolated network virtualization is implemented in every data center in every region, which means that all Oracle Cloud Infrastructure tenants benefit from this reduced risk.

  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

  Figure 6-2 Multitenant’s Comprehensive Isolation Architecture

  
  

• Defense in Depth Oracle Exadata Database Service on Exascale Infrastructure offers a number of controls to ensure confidentiality, integrity, and availability throughout the service.

  First, Oracle Exadata Database Service on Exascale 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 Oracle Exadata Database Service on Exascale 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.

  Oracle Exadata Database Service on Exascale 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 Oracle Exadata Database Service on Exascale 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.

  Oracle Exadata Database Service on Exascale 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-XS 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 Oracle Exadata Database Service on Exascale Infrastructure. These users are required and may not be modified.

In all ExaDB-XS 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.

Learn about the default security settings used with Oracle Exadata Database Service on Exascale Infrastructure instances.

• 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

• Oracle Exadata Database Service on Exascale 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
  

Learn about the backup security policy for

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 in centralized storage by Oracle. 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 VM for lifecycle automation.

One specific use case is when a VM is unable to restart. In this case, customers must provide permission to access the VM for recovery. 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 VMs, authentication to access the VM, and authentication to access databases running in the VMs. Oracle controls and monitors access to Oracle-managed infrastructure components. Oracle staff are not authorized to access customer services, including 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-XS 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-XS 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.

Oracle Exadata Cloud Service (ExaCS) has integration with the OCI Vault service to protect data at rest for its databases. Users now have the control to create and manage TDE master keys within the OCI Vault that protect your Exadata databases.

With this feature, users have the option to start using the OCI vault service to store and manage the master encryption keys. The OCI Vault keys used for protecting databases are stored in a highly available,

durable, and managed service. OCI vault integration for ExaCS is only available after Oracle Database 11g release 2 (11.2.0.4).

In the published Oracle Advanced Security Guide (section Encrypting Columns in Tables the methodology to create a table to encrypt columns using a non-default encryption algorithm ids described.