1. Security Guide for Oracle Exadata
  2. Security Features of Oracle Exadata Database Machine

2 Security Features of Oracle Exadata Database Machine

Oracle Exadata Database Machine hardware and software are hardened.

The following steps have been done to harden Oracle Exadata Database Machine:

  • Trimmed the list of installed packages so that unnecessary packages are not installed on the servers.

  • Turned on only essential services on the Oracle Exadata Storage Servers.

  • Enabled firewalls (iptables) on the storage servers.

  • Enabled auditing of the operating system user.

  • Enforced hardened password policies.

Oracle also provides recommended secure configurations for services such as NTP and SSH. In addition, the Oracle Exadata Database Machine architecture provides the following security capabilities to the core components. These security capabilities are most often applied by organizations seeking to deploy a layered security strategy.

2.1 Using Security-Enhanced Linux

Oracle Exadata System Software release 21.2.0 introduces support for Security-Enhanced Linux (SELinux) in Oracle Exadata.

SELinux is a Linux kernel security module that provides a mechanism for supporting access control security policies, including Mandatory Access Control (MAC).

Commencing with Oracle Exadata System Software release 21.2.0, every Linux installation on Oracle Exadata is equipped with a predefined SELinux policy that implements granular permissions for Exadata users, programs, processes, files, and devices. Each server also contains the host_access_control utility (/opt/oracle.cellos/host_access_control), which provides simple management and monitoring functions for SELinux on Oracle Exadata.

By default, every storage server, physical database server, virtual machine (VM) host, or VM database server contains the predefined Exadata security policy. However, SELinux is disabled by default.

You can choose to enable SELinux in permissive mode or enforcing mode. In permissive mode, SELinux actively monitors the system and records policy violations in the audit logs. However, no actions are blocked in permissive mode. When enforcing mode is enabled, SELinux actively blocks policy violations and records interventions in the audit logs.

Note the following regarding SELinux on Oracle Exadata:

  • If you choose to enable SELinux, it is strongly recommended to initially use permissive mode for some time to ensure that the predefined Exadata security policy works in conjunction with all the applications and procedures at your site. Additionally, you should test SELinux in permissive mode on an equivalent test system before using permissive mode on a production system.

    While the system is in permissive mode, you should use standard SELinux commands, such as ausearch, to monitor policy violations. If thorough system operation in permissive mode yields no policy violations, you can easily transition to enforcing mode.

  • The source files for the predefined Exadata security policy are located in /opt/oracle.SupportTools/selinux. The file context definitions are contained in /opt/oracle.SupportTools/selinux/Exadata.fc and the type enforcement definitions are contained in /opt/oracle.SupportTools/selinux/Exadata.te. You can view these files to understand the Exadata security policy.

  • Modifying the predefined Exadata security policy is not supported, and any unsupported modifications are overwritten the next time you upgrade the Oracle Exadata System Software.

  • You can implement additional security policies at your discretion. For example, you can hand-craft additional policies using standard SELinux operating system commands or use the audit2allow command to generate a policy definition that addresses policy violations recorded in the audit logs.

Use the following procedures to manage SELinux on Oracle Exadata:

Related Topics

Parent topic: Security Features of Oracle Exadata Database Machine

2.1.1 Enabling SELinux

You can enable SELinux on Exadata by using the host_access_control utility.

  1. Set the SELinux mode.

    You can configure SELinux to operate in permissive mode or enforcing mode:

    • In permissive mode, SELinux actively monitors the system and records policy violations in the audit logs. However, no actions are blocked in permissive mode.

      To specify permissive mode, use the following command:

      # /opt/oracle.cellos/host_access_control selinux --permissive

      It is strongly recommended to initially enable SELinux in permissive mode for some time to ensure that the predefined Exadata security policy works in conjunction with all of the applications and procedures at your site.

    • When enforcing mode is enabled, SELinux actively blocks policy violations and records interventions in the audit logs.

      To specify enforcing mode, use the following command:

      # /opt/oracle.cellos/host_access_control selinux --enforcing
  2. Command the system to perform relabeling.

    Under SELinux, each file is associated with a context, or security label, that governs its use. When SELinux is first enabled, you must relabel the system to ensure that the files are associated with the appropriate security context.

    The following command instructs the system to perform relabeling.

    # /opt/oracle.cellos/host_access_control selinux --relabel

    The command instructs the system to perform relabeling by touching the file located at /.autorelabel. However, the relabeling process occurs as part of the next system reboot.

  3. Reboot the system.

    A system reboot is required to perform relabeling and enable SELinux.

Parent topic: Using Security-Enhanced Linux

2.1.2 Changing the SELinux Mode

While SELinux is enabled, you can immediately transition between permissive mode and enforcing mode by using the host_access_control utility. In this case, no relabeling or reboot is required.

  • To change to permissive mode, use the following command:

    # /opt/oracle.cellos/host_access_control selinux --permissive

  • To change to enforcing mode, use the following command:

    # /opt/oracle.cellos/host_access_control selinux --enforcing

Parent topic: Using Security-Enhanced Linux

2.1.3 Disabling SELinux

You can disable SELinux on Exadata by using the host_access_control utility.

  1. Set the SELinux mode to disabled.
    # /opt/oracle.cellos/host_access_control selinux --disabled
  2. Reboot the system.

    A system reboot is required to deactivate SELinux.

Parent topic: Using Security-Enhanced Linux

2.1.4 Displaying the SELinux Status

You can display the SELinux status by using the host_access_control utility. You can display the current status or the configured status:

  • The current status indicates the SELinux mode that is currently active on the system.

    To display the current status, use the following command:

    # /opt/oracle.cellos/host_access_control selinux --status

  • The configured status indicates the SELinux mode set by the most recent host_access_control command. The configured status differs from the current status after you change the SELinux mode setting but before you reboot the system to activate the new mode.

    To display the configured status, use the following command:

    # /opt/oracle.cellos/host_access_control selinux --config

Parent topic: Using Security-Enhanced Linux

2.2 Restricting the Binaries Used to Boot the System

Secure Boot supports a chain of trust that goes down to the kernel module level.

Secure Boot is a method used to restrict which binaries can boot the system. With Secure Boot, the system UEFI firmware will only allow boot loaders that carry the cryptographic signature of trusted entities. In other words, anything run in the UEFI firmware must be signed with a key that the system recognizes as trustworthy. With each reboot of the server, every component in the boot sequence is verified. This prevents malware from hiding embedded code in the boot sequence.

Loadable kernel modules must be signed with a trusted key or they cannot be loaded into the kernel.

The following trusted keys are stored in UEFI NVRAM variables:

  • Database (DB) - Signature database that contains well-known keys. Only binaries that can be verified against the DB are run by the BIOS.

  • Forbidden Database (DBX) - Keys that are blocked. Attempting to load an object with a key that matches an entry in the DBX will be denied. This is a list of keys that are bad.

  • Machine Owner Key (MOK) - User added keys for kernel modules you want to install.

  • Platform Key (PK) - The key installed by the hardware vendor. This key is installed by the vendor and is in the ILOM firmware. This key is not accessible from the host.

  • Key Exchange Key (KEK) - The key required to update the signature database.

The user must have physical access to the system console to add keys, modify keys, or enable and disable Secure Boot through the UEFI configuration menu. The default boot loader on most UEFI-enabled servers running Linux is grub2. With Secure Boot enabled, an additional shim boot loader is needed. When booting in Secure Boot mode, the shimloader is called first because it contains a trusted signature. The shimloader then loads grub2, which then loads the OS kernel, which is also signed.

The minimum system requirement for Secure Boot is Oracle Exadata X7-2 with Oracle Exadata System Software release 19.1.0. Secure Boot is enabled by default and supported only on Exadata storage servers, bare metal database servers, and KVM hosts. Secure Boot is not supported on KVM guests, Xen-based Oracle VM Servers (Dom0), and Oracle VM guests (DomU).

Parent topic: Security Features of Oracle Exadata Database Machine

2.2.1 Enabling and Disabling Secure Boot

Secure Boot is enabled by default on Exadata storage servers, bare metal database servers, and KVM hosts.

Note:

Secure Boot is not supported on KVM guests, Xen-based Oracle VM Servers (Dom0), and Oracle VM guests (DomU).

Oracle recommends that you leave the default Secure Boot option setting.

You can change the Secure Boot setting by pressing F12 during the boot process, navigating to the EFI boot menu and changing the Secure Boot setting.

To verify the status of the Secure Boot option, use the following command: 

# mokutil --sb-state
SecureBoot enabled

Parent topic: Restricting the Binaries Used to Boot the System

2.2.2 Managing Keys and Certificates Used with Secure Boot

You can use the mokutil command to manage the keys and certificates used with Secure Boot.

The certificates are signed by DigiCert. By default, a certificate is valid for one year from the date of signing. Even though a certificate may expire, the validation is based on the date on which the grub and kernel were signed and if the certificate was valid at that time.

To renew the certificates, you update the kernel, grub, and ILOM on the secured servers with a new, signed version.

  • To query the existing keys, use the command mokutil.
    [root@dbm0celadm03 ~]# mokutil --list-enrolled
[key 1]
SHA1 Fingerprint: 5f:f4:35:5a:49:ec:8d:f1:56:d1:ee:9b:ac:f6:19:54:08:77:d3:59
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            21:b3:c1:01:19:dc:af:44:43:15:8b:0f:33:6b:18:be
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Symantec Corporation, OU=Symantec Trust Network, CN=Symantec Class 3 Extended Validation Code Signing CA - G2
        Validity
            Not Before: Jun 30 00:00:00 2020 GMT
            Not After : Jul  1 23:59:59 2021 GMT
        Subject: jurisdictionC=US/jurisdictionST=Delaware/businessCategory=Private Organization/serialNumber=2101822, C=US/postalCode=94065, ST=California, L=Redwood City/street=500 Oracle Parkway, O=Oracle America Inc., OU=Winqual, CN=Oracle America Inc.
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:8d:3e:e0:3b:35:99:fb:11:c0:2a:12:ac:07:40:
                    f7:90:d4:d3:62:5e:85:2d:ea:94:af:5f:26:33:98:
                    c8:03:33:0e:30:5e:4d:44:ca:fa:1a:3a:49:88:64:
                    89:16:5c:39:f3:35:86:ed:25:eb:0f:ca:fa:2c:3d:
                    d6:23:2a:b3:1e:62:fb:45:88:1a:05:be:95:d6:6a:
                    d9:c5:f2:81:7a:cc:63:71:3c:37:a0:23:1c:eb:20:
                    1a:3d:13:89:6a:9e:47:a0:eb:ca:64:21:3f:7a:f4:
                    e6:09:bf:47:63:c8:b3:6b:a5:c6:1b:de:f6:06:12:
                    56:eb:ab:24:00:01:c9:80:db:be:66:49:64:ac:c8:
                    ce:1e:da:7a:c1:42:21:85:f9:67:81:a4:f0:6d:14:
                    01:9b:45:1e:9f:08:e5:18:b7:c5:34:e5:55:e2:11:
                    dc:fe:0c:36:32:f4:bb:cb:34:00:37:b2:41:05:5f:
                    0a:69:68:55:cb:4e:ec:ca:cc:1b:67:dc:05:f1:98:
                    95:c4:14:35:41:01:fe:f5:bd:63:1a:8d:cc:8a:1f:
                    b6:87:ac:02:ea:e2:2e:29:d6:11:b9:bc:aa:d6:44:
                    3e:32:3c:a9:12:a4:aa:09:ec:6e:ba:99:08:58:36:
                    6b:ef:40:c5:3e:47:36:93:53:f1:c9:f2:79:f2:53:
                    c9:9b
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                Code Signing
            X509v3 Certificate Policies:
                Policy: 2.23.140.1.3
                  CPS: https://d.symcb.com/cps
                  User Notice:
                    Explicit Text: https://d.symcb.com/rpa

            X509v3 Subject Key Identifier:
                BC:59:71:95:4C:74:9D:3D:30:98:52:EF:0F:3C:23:6F:A4:98:E8:F6
            X509v3 Authority Key Identifier:
                keyid:16:66:DE:4A:34:E3:50:A7:11:86:03:B1:6C:A9:C6:AC:CD:59:6E:9B

            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://sw.symcb.com/sw.crl

            Authority Information Access:
                OCSP - URI:http://sw.symcd.com
                CA Issuers - URI:http://sw.symcb.com/sw.crt

    Signature Algorithm: sha256WithRSAEncryption
         38:4d:10:69:07:db:7c:ce:18:2b:1e:c5:89:1c:71:a9:b0:07:
         19:43:2d:a0:88:c5:f5:bf:82:a9:4b:f9:45:fa:2c:7c:00:cb:
         be:24:b0:a8:98:7d:f5:a3:c4:42:52:f4:75:fd:22:c5:0c:2e:
         a2:13:7f:b9:24:79:04:d5:ea:0e:1a:e6:e8:4c:61:48:65:5b:
         c7:30:81:90:fd:17:d5:39:d4:70:00:00:b8:c5:80:03:da:88:
         e0:f1:39:aa:d9:1d:ef:2f:bf:c3:06:18:2a:1b:1f:ce:30:a2:
         bb:dd:d0:46:0e:d5:e1:22:0c:a0:cc:df:00:fe:0a:99:d5:cc:
         16:76:4b:ab:dc:bb:80:4b:0e:1b:f5:5e:04:22:3e:a9:d0:70:
         56:87:9b:c1:2f:95:cf:36:34:e7:c7:2e:0c:56:f3:24:fa:7d:
         f7:25:54:50:34:f6:e5:30:76:8b:fd:65:25:19:8a:54:f9:f1:
         93:24:ad:22:25:4a:e0:a2:63:b6:d7:d1:82:4e:5a:fc:34:52:
         b4:9e:7d:1a:e2:b7:a1:92:13:0f:9d:7b:ae:42:6f:64:a2:02:
         47:c7:f9:11:12:e4:82:b9:f7:ed:ce:14:ac:c2:b4:e3:cc:c4:
         ef:f8:9f:78:23:91:89:b0:37:24:f1:c6:61:0c:2e:cf:af:29:
         e5:68:70:4d

Parent topic: Restricting the Binaries Used to Boot the System

2.2.2.1 Adding Keys for Secure Boot Using mokutil

You can import or add new keys for use with Secure Boot.

You can use the command mokutil --help to view additional options.
You must run these command as the root user.
  1. Create a DER-formatted X509 certificate file for the key you want to add.
  2. Check to see if the key is already active.
    # mokutil --test-key new_target_cert.cer
  3. If the key is not currently active, then import the key certificate.
    # mokutil --import new_target_cert.cer
2.2.2.2 Removing Keys for Secure Boot Using mokutil

You can delete or remove keys for use with Secure Boot.

You can use the command mokutil --help to view additional options.
You must run these command as the root user.
  • To delete a key, use the following command:
    mokutil --delete key_file

2.2.3 Troubleshooting Secure Boot

You might encounter the following problems when Secure Boot is enabled.

  • Secure boot violation: Invalid signature detected. Check Secure Boot Policy in Setup. — The grub loader has an invalid signature.

    Note:

    Even though a certificate may expire, the validation is based on the date on which the grub & kernel were signed and if the certificate was valid at that time.
  • error: file has invalid signature. error: You need to load the kernel first. — The grub loader is signed, but the kernel is unsigned.
  • ERROR: Verification failed: (15) Access Denied. Failed to load image: Access Denied.start_image() returned Access Denied — The ISO image being loaded to image the server is not signed.

Parent topic: Restricting the Binaries Used to Boot the System

2.3 Using Isolation Policies

Oracle Exadata Database Machine supports multiple isolation levels.

Organizations wanting to consolidate IT infrastructure, implement shared service architectures, and deliver secure multitenant services should isolate services, users, data, communications, and storage. Oracle Exadata Database Machine provides organizations the flexibility to implement the isolation policies and strategies based on their needs. The following are the secure isolation levels of Oracle Exadata Database Machine:

  • Isolating Network Traffic
    Oracle Exadata uses multiple networks to segregate network traffic.
  • Isolating Databases
    Use operating system controls and database features to enable database isolation.
  • Isolating Storage
    Oracle Exadata storage is isolated from the rest of the architecture through the use of a RDMA Network Fabric (InfiniBand or RDMA over Converged Ethernet (RoCE)).

Parent topic: Security Features of Oracle Exadata Database Machine

2.3.1 Isolating Network Traffic

Oracle Exadata uses multiple networks to segregate network traffic.

At the physical network level, client access is isolated from device management and inter-device communication. Client and management network traffic are isolated on separate networks. Client access is provided over a bonded Ethernet network interface that ensures reliable, high-speed access to services running on the system. Management access is provided over a physically separate Ethernet network interface. This provides a separation between operational and management networks.

Organizations may choose to further segregate network traffic over the client access network by configuring virtual LANs (VLANs). VLANs segregate network traffic based on their requirements. Oracle recommends the use of encrypted protocols over VLANs to assure the confidentiality and integrity of communications.

Inter-device communication is provided by a RDMA Network Fabric (InfiniBand or RDMA over Converged Ethernet (RoCE)). The RDMA Network Fabric is a high-performance, low-latency backplane for communication between Oracle Exadata Storage Servers and database servers. By default, Oracle Exadata Storage Servers include a configured software firewall. The database servers can also be configured with a software firewall.

Note:

Partitioning the InfiniBand private network does not protect an InfiniBand fabric. Partitioning only offers InfiniBand traffic isolation between machines.

Parent topic: Using Isolation Policies

2.3.2 Isolating Databases

Use operating system controls and database features to enable database isolation.

Physical separation by dedicating an entire environment to a single application or database is one of the best isolation methods. However, it is expensive. A more cost-effective isolation strategy uses multiple databases within the same operating system image. Multiple database isolation is achieved through a combination of database and operating system-level controls, such as dedicated credentials for users, groups, and resource controls.

All Oracle Database security options are available for Oracle Exadata Database Machine. Organizations wanting finer-grained database isolation can use software such as Oracle Database Vault, Oracle Virtual Private Database, and Oracle Label Security.

Oracle Database Vault includes a mandatory access control model to enforce isolation using logical realms within a single database. Logical realms form a protective boundary around existing application tables by blocking administrative accounts from having ad-hoc access to application data. Oracle Database Vault command rules enable policy-based controls that limit who, when, where, and how the database and application data is accessed. This creates a trusted path to application data. Oracle Database Vault can also be employed to restrict access based upon time, source IP address, and other criteria.

Oracle Virtual Private Database enables the creation of policies that enforce fine-grained access to database tables and views at the row and column levels. Oracle Virtual Private Database provides security portability because the policies are associated with database objects, and are automatically applied no matter how the data is accessed. Oracle Virtual Private Database can be used for fine-grained isolation within the database.

Oracle Label Security is used to classify data, and mediate access to that data based upon its classification. Organizations define classification strategies, such as hierarchical or disjoint, that best support their needs. This capability allows information stored at different classification levels to be isolated at the row level within a single tablespace.

Parent topic: Using Isolation Policies

2.3.3 Isolating Storage

Oracle Exadata storage is isolated from the rest of the architecture through the use of a RDMA Network Fabric (InfiniBand or RDMA over Converged Ethernet (RoCE)).

The storage managed by Oracle Exadata Storage Servers can be subdivided using Oracle Automatic Storage Management (Oracle ASM) to create individual disk groups. Each disk group can have its own security policies.

Parent topic: Using Isolation Policies

2.4 Network Access to Oracle Exadata Storage Servers

Oracle Exadata System Software includes the cellwall service, which implements an iptables firewall on each cell.

Additionally, the SSH server is configured to respond to connection requests only on the management network (NET0) and the RDMA Network Fabric.

To review the firewall rules, run the following command as the root user: 

iptables --list

Note:

There is no firewall automatically configured for the database servers. You can implement an iptables firewall on each database server to meet your network security requirements.

Parent topic: Security Features of Oracle Exadata Database Machine

2.5 Controlling Access to Data

To protect application data, workloads, and the underlying infrastructure on which it runs, Oracle Exadata Database Machine offers comprehensive yet flexible access control capabilities for both users and administrators.

The control capabilities include network access, database access, and storage access.

  • Controlling Network Access
    Beyond simple network-level isolation, fine-grained access control policies can be instituted at the device level.
  • Controlling Database Access
    Separation of duties is critical at every layer of the architecture to reduce the risk of collusive behavior, and prevent inadvertent errors.
  • Controlling Storage Access
    Oracle Exadata System Software supports the access control modes of open security, Oracle ASM-scoped security, and database-scoped security.

Parent topic: Security Features of Oracle Exadata Database Machine

2.5.1 Controlling Network Access

Beyond simple network-level isolation, fine-grained access control policies can be instituted at the device level.

All components in Oracle Exadata Database Machine include the ability to limit network access to services either using architectural methods, such as network isolation, or using packet filtering and access control lists to limit communication to, from, and between components and services.

Parent topic: Controlling Access to Data

2.5.2 Controlling Database Access

Separation of duties is critical at every layer of the architecture to reduce the risk of collusive behavior, and prevent inadvertent errors.

For example, use different operating system accounts to ensure role separation for database and storage administrators, including administrators supporting Oracle Automatic Storage Management (Oracle ASM). Within Oracle Database, users can be assigned specific privileges and roles to ensure that users have access to only those data objects that they are authorized to access. Data cannot be shared unless it is explicitly permitted.

In addition to password-based authentication, Oracle Database also supports public key credentials, RADIUS, and Kerberos. Using Oracle Enterprise User Security, the database can be integrated with existing LDAP repositories for authentication and authorization. These capabilities provide higher assurance of the identity of users connecting to the database.

Oracle Database Vault can be used to manage administrative and privileged user access, controlling how, when and where application data can be accessed. Oracle Database Vault protects against misuse of stolen login credentials, application bypass, and unauthorized changes to applications and data, including attempts to make copies of application data. Oracle Database Vault is transparent to most applications, and day-to-day tasks. It supports multi-factor authorization policies, allowing for secure enforcement of policy without disrupting business operations.

Oracle Database Vault can enforce separation of duties to ensure that account management, security administration, resource management, and other functions are granted only to those users authorized to have those privileges.

Parent topic: Controlling Access to Data

2.5.3 Controlling Storage Access

Oracle Exadata System Software supports the access control modes of open security, Oracle ASM-scoped security, and database-scoped security.

  • Open security allows any database to access any of the grid disks.

  • Oracle ASM-scoped security allows multiple databases assigned to one or more Oracle ASM clusters to share specific grid disks.

    In addition to its overall access control mode, Oracle ASM supports access controls at the disk group and file level to ensure that access to content stored on disk is only available to authorized users.

    Note:

    • The /etc/oracle/cell/network-config/cellkey.ora file needs to be readable only by the software installation owner of Oracle Grid Infrastructure with its specific unique group, such as asmadmin.

    • Use the kfod utility in the Oracle Grid Infrastructure home to troubleshoot or verify which disks are accessible for your cluster.

  • Database-scoped security, the most fine-grained level of access control, ensures that only specific databases are able to access specific grid disks.

    Database-scoped security works on a container level. This means that grid disks must be made available to the DB_UNIQUE_NAME of the container database (CDB) or non-CDB. Because of this, it is not possible to have database-scoped security per pluggable database (PDB).

    Note:

    You should only set up database-scoped security after configuring and testing Oracle ASM-scoped security.

By default, SSH is enabled on storage servers. If required, you can "lock" the storage servers to block SSH access. You can still perform operations on the storage server using exacli, which runs on compute nodes and communicates using HTTPS and REST APIs to a web service running on the cell. At a high-level, this is accomplished by creating users and roles in CellCLI and then disabling remoteLogin.

Related Topics

Parent topic: Controlling Access to Data

2.6 Using Cryptographic Services

The requirement to protect and validate information at rest, in transit, and in use often employs cryptographic services. From encryption and decryption to digital fingerprint and certificate validation, cryptography is one of the most-widely deployed security controls in IT organizations.

Whenever possible, Oracle Exadata Database Machine makes use of hardware-based cryptographic engines on processor chips provided by Intel AES-NI and Oracle SPARC. Using hardware for cryptographic operations provides significant performance improvement over performing the operations in software. Both engines provide the ability to perform cryptographic operations in hardware, and both are leveraged by Oracle software on the database and storage servers.

Network cryptographic services protect the confidentiality and integrity of communications by using a cryptographically-secure protocol. For example, Secure Shell (SSH) access provides secure administrative access to systems and Integrated Lights Out Manager (ILOM). SSL/TLS can enable secure communications between applications and other services.

Database cryptographic services are available by using transparent data encryption (TDE), a component of Oracle Advanced Security. TDE supports the encryption of entire tablespaces and individual columns within a table. TDE is woven into the architecture of Oracle Database, with data encryption being maintained in temporary tablespaces and redo logs. Data encryption is also maintained in database backups, which protects the data regardless of the storage device in use. On Exadata, TDE-encrypted data also remains encrypted when it resides in Exadata Smart Flash Cache or in Exadata RDMA Memory Cache.

In addition, Oracle Advanced Security can encrypt Oracle Net Services and JDBC traffic using either native encryption or SSL to protect information while in transit over a network. Both administrative and application connections can be protected to ensure that data in transit is protected. The SSL implementation supports the standard set of authentication methods including anonymous (Diffie-Hellman), server-only authentication using X.509 certificates, and mutual (client-server) authentication with X.509.

Parent topic: Security Features of Oracle Exadata Database Machine

2.7 Monitoring and Auditing of Oracle Exadata Database Machine

Whether for compliance reporting or incident response, monitoring and auditing are critical functions that organizations must use to gain increased visibility into their IT environment.

The degree to which monitoring and auditing is employed is often based upon the risk or criticality of the environment. Oracle Exadata has been designed to offer comprehensive monitoring and auditing functionality at the server, network, database, and storage layers ensuring that information can be made available to organizations in support of their audit and compliance requirements.

Parent topic: Security Features of Oracle Exadata Database Machine

2.7.1 Monitoring and Auditing of Oracle Exadata Database Machine

AIDE is a security feature that reports any malicious or unplanned change to the system.

Oracle Exadata System Software release 19.1.0 adds support for Advanced Intrusion Detection Environment (AIDE) to help guard against unauthorized access to the files on your Exadata system. AIDE creates a database of files on the system, and then uses that database to ensure file integrity and to detect system intrusions. To learn more about AIDE see https://en.wikipedia.org/wiki/Advanced_Intrusion_Detection_Environment

On Oracle Exadata, a Management Server (MS) alert is generated when AIDE identifies an unplanned change to the system (files or directories).

For non-production systems, or systems that are temporarily considered NON-PRODUCTION, where software installation or configuration is occurring, AIDE could generate a large number of alerts with false positives. While a system is in NON-PRODUCTION mode, the recommendation is to temporarily disable AIDE on each of the compute nodes by running the command /opt/oracle.SupportTools/exadataAIDE -disable.

For systems returned to PRODUCTION, after locking down software installation, one of the last steps should be the final update of the AIDE database, by executing following commands:

  • /opt/oracle.SupportTools/exadataAIDE -enable — If AIDE was previously disabled

  • /opt/oracle.SupportTools/exadataAIDE -u — To generate a new AIDE database baseline

If you must modify the configuration on any of the PRODUCTION database servers, then run an update of the AIDE database after the change, by executing the command /opt/oracle.SupportTools/exadataAIDE -u.

Note:

Updating the AIDE database clears all open AIDE MS alerts.

Parent topic: Monitoring and Auditing of Oracle Exadata Database Machine

2.7.2 Monitoring and Auditing Oracle Database Activity

Oracle Database support of fine-grained auditing allows organizations to establish policies that selectively determine when audit records are generated.

Establishing policies helps organizations focus on other database activities, and reduce the overhead that is often associated with audit activities.

Oracle Audit Vault centralizes the management of database audit settings and automates the consolidation of audit data into a secure repository. Oracle Audit Vault includes built-in reporting to monitor a wide range of activities including privileged user activity and changes to database structures. The reports generated by Oracle Audit Vault enable visibility into various application and administrative database activities, and provide detailed information to support accountability of actions.

Oracle Audit Vault enables the proactive detection and alerting of activities that may be indicative of unauthorized access attempts or abuse of system privileges. These alerts can include both system and user-defined events and conditions, such as the creation of privileged user accounts or the modification of tables containing sensitive information.

Oracle Database Firewall Remote Monitor can provide real-time database security monitoring. Oracle Database Firewall Remote Monitor queries database connections to detect malicious traffic, such as application bypass, unauthorized activity, SQL injection and other threats. Using an accurate SQL grammar-based approach, Oracle Database Firewall helps organizations quickly identify suspicious database activity.

Parent topic: Monitoring and Auditing of Oracle Exadata Database Machine

2.7.3 Operating System Activity Monitoring on Oracle Exadata Servers

Each Exadata server is configured with auditd to audit system-level activity.

To manage audits and generate reports use the auditctl command. The audit rules are in the /etc/audit/audit.rules file. Any changes are not preserved when applying a patch set.

Starting with Oracle Exadata System Software release 19.1.0 and Oracle Linux 7, the audit rules specific to Oracle Exadata are stored in the /etc/audit/rules.d/01-exadata_audit.rules file.

When the auditd service starts, it runs the augenrules utility. This utility merges all component audit rules files found in the audit rules directory, /etc/audit/rules.d, and places the merged results in the /etc/audit/audit.rules file. Component audit rule files, must end in .rules to be processed by augenrules. All other files in the /etc/audit/rules.d directory are ignored. The files are concatenated in order, based on their natural sort order and stripped of empty lines and comment (#) lines. Auditing rules not specific to Oracle Exadata should be placed in a separate audit rules file in the /etc/audit/rules.d directory, such as /etc/audit/rules.d/20-customer_audit.rules.

As in previous releases of Oracle Exadata System Software, the audit rules are immutable. A reboot is needed to effect changes to audit rules.

Parent topic: Monitoring and Auditing of Oracle Exadata Database Machine

2.8 Maintaining Quality of Service

There are many ways that applications can be attacked besides breaching a boundary or subverting an access control policy.

Oracle Exadata provides a number of capabilities to help detect and prevent resource exhaustion attacks, denial of service attacks, and accidental or intentional faults that can impact the availability of services and data.

Oracle Exadata System Software includes I/O Resource Management (IORM) to manage interdatabase and intradatabase I/O resources. IORM allows different databases with different performance requirements to share a common Oracle Exadata Storage Server pool. Multiple workloads within the same database can have their own resource policies. This flexible architecture allows organizations to ensure that critical workloads and databases share I/O resources when operating on a consolidated architecture.

Oracle Database includes tools to enable multiple databases to operate under the same operating system. Oracle Database Resource Manager, and instance caging support the ability to dynamically control access to CPU resources using fine-grained methods. Oracle Database Resource Manager can control the degree of parallelism, the number of active sessions, and other shared resources to protect one database from monopolizing resources needed in shared database architectures.

Oracle Database Quality of Service Management (Oracle Database QoS Management) is an automated, policy-based solution that monitors the workload requests of an entire system. Oracle Database QoS Management correlates accurate run-time performance and resource metrics, analyzes the data to identify bottlenecks, and produces recommended resource adjustments to maintain performance objectives under dynamic load conditions.

Parent topic: Security Features of Oracle Exadata Database Machine

2.9 Using Oracle ILOM for Secure Management

Collections of security controls and capabilities are necessary to properly secure individual applications and services.

It is equally important to have comprehensive management capabilities to sustain the security of the deployed services and systems. Oracle Exadata Database Machine uses the security management capabilities of ILOM.

ILOM is a service processor embedded in many Oracle Exadata Database Machine components. It is used to perform out-of-band management activities, such as the following:

  • Provide secure access to perform secure lights-out management of the database and storage servers. Access includes web-based access protected by SSL, command-line access using Secure Shell (SSH), and protocol access using TLS and SNMPv3.

  • Separate duty requirements using a role-based access control model. Individual users are assigned to specific roles that limit the functions that can be performed.

  • Provide an audit record of all logins and configuration changes. Each audit log entry lists the user performing the action, and a timestamp. This allows organizations to detect unauthorized activity or changes, and attribute those actions back to specific users.

Related Topics

Parent topic: Security Features of Oracle Exadata Database Machine

2.10 Considerations for a Secure Environment

Oracle Exadata Database Machine includes many layered security controls that can be tailored to meet an organization's specific policies and requirements.

Organizations must evaluate how to best utilize these capabilities and integrate them into their existing IT security architecture. Effective IT security must consider the people, processes, and technology in order to provide solid risk management and governance practices. Practices and policies should be designed and reviewed during the planning, installation, and deployment stages of Oracle Exadata Database Machine.

While many of the features integrated into Oracle Exadata Database Machine are configured by default for secure deployment, organizations have their own security configuration standards. It is important to review Oracle security information before testing any security setting changes to Oracle Exadata Database Machine components. In particular, it is important to identify where existing standards can be improved, and where support issues may limit what changes can be made to a given component.

Note:

To minimize the attack surface, Oracle Exadata Storage Servers do not support customization outside of their management interfaces. No custom users are permitted on the storage servers. The servers have been optimized and hardened for their specific purpose.

Parent topic: Security Features of Oracle Exadata Database Machine

2.10.1 Identity and Access Management Considerations

A unified approach should be used when integrating Oracle Exadata Database Machine components and deployed services with your organization's existing identity and access management architecture.

Oracle Database supports many open and standard protocols that allow it to be integrated with existing identity and access management deployments. To ensure application availability, unified identity and access management systems must be available, or the availability of Oracle Exadata Database Machine may be compromised.

Before Oracle Exadata Database Machine arrives, the following security considerations should be discussed. These considerations are based on Oracle best practices for Oracle Exadata Database Machine.

  • The ability to directly log in to common operating system accounts such as root, grid and oracle should be disabled. Individual user accounts should be created for each administrator. After logging in with their individual account, the administrator can use sudo to run privileged commands, when required.

  • The use of host-based intrusion detection and prevention systems for increased visibility within Oracle Exadata Database Machine. By using the fine-grained auditing capabilities of Oracle Database, host-based systems have a greater likelihood of detecting inappropriate actions and unauthorized activity.

  • The use of centralized audit and log repositories to aggregate the security-relevant information for improved correlation, analysis, and reporting. Oracle Exadata Storage Servers support this through the CELL attribute syslogConf. The database servers support centralized logging using the typical system configuration methods.

  • The use of encryption features such as transparent data encryption (TDE), Oracle Recovery Manager (RMAN) encryption for backups.

The security of the data and system is diminished by user access and password security. Oracle recommends the following guidelines to maximize your user security:

  • Create separate software owner accounts for Oracle Grid Infrastructure and Oracle Database software installations. These accounts should be used when deploying Oracle Exadata Database Machine. A separate software owner for Oracle Grid Infrastructure and Oracle Database software installations is required for implementing DB-scoped security.

  • Implement a user password policy that enforces password complexity beyond the minimum requirements.
  • Implement password aging and account locking. Starting with Oracle Exadata System Software release 19.1.0 you can use DBSERVER and CELL attributes to configure the following account security features:
    • A user's password expires after a specified number of days. The default user password expiration time is 0. 0 means passwords will not expire.

    • A user gets a warning message when logging in for a specified number of days before their password expires. The default user account password expiration warning time is 7 days.

    • The user is prompted to change their password when logging within a specified number of days after their password expires. If the remotePwdChangeAllowed attribute on the server indicates that a service request is not required to change the password, then the user can change the password immediately. Otherwise, the user must connect the server administrator to have their password changed.

    • A user account is locked a specified number of days after the password expires. The default user account lock time is 7 days. After the account is locked, the user must contact the server administrator to have the account unlocked.

Parent topic: Considerations for a Secure Environment

2.10.2 Network Security Considerations

Before Oracle Exadata arrives at your location, network security considerations should be discussed.

The following considerations are based on Oracle best practices for Oracle Exadata.

  • The use of intrusion prevention systems on database servers to monitor network traffic flowing to and from Oracle Exadata. Such systems enable the identification of suspicious communications, potential attack patterns, and unauthorized access attempts.

  • The use of application and network-layer firewalls to protect information flowing to and from Oracle Exadata. Filtering network ports provides the first line of defense in preventing unauthorized access to systems and services.

    Network-level segmentation using Ethernet virtual local area networks (VLANs) and host-based firewalls enforce inbound and outbound network policy at the host level. Using segmentation allows fine-grained control of communications between components of Oracle Exadata. Oracle Exadata Storage Servers include a configured software firewall by default. The database servers can be configured with a software firewall.

  • The use of encryption features such as Oracle Advanced Security to encrypt traffic to Oracle Data Guard standby databases.

The security of the data and system is diminished by weak network security. Oracle recommends the following guidelines to maximize your Ethernet network security:

  • Configure administrative and operational services to use encryption protocols and key lengths that align with current policies. Cryptographic services provided by Oracle Exadata benefit from hardware acceleration, which improves security without impacting performance.

  • Manage and separate switches in Oracle Exadata from data traffic on the network. This separation is also referred to as "out-of-band."

  • Separate sensitive clusters from the rest of the network by using virtual local area networks (VLANs). This decreases the likelihood that users can gain access to information on these clients and servers.

  • Use a static VLAN configuration.

  • Disable unused switch ports, and assign an unused VLAN number.

  • Assign a unique native VLAN number to trunk ports.

  • Limit the VLANs that can be transported over a trunk to only those that are strictly required.

  • Disable VLAN Trunking Protocol (VTP), if possible. If it is not possible, then set the management domain, password and pruning for VTP. In addition, set VTP to transparent mode.

  • Disable unnecessary network services, such as TCP small servers or HTTP. Enable only necessary network services, and configure these services securely.

  • Network switches offer different levels of port security features. Use these port security features if they are available:

  • Lock the Media Access Control (MAC) address of one or more connected devices to a physical port on a switch. If a switch port is locked to a particular MAC address, then super users cannot create back doors into the network with rogue access points.

  • Disable a specified MAC address from connecting to a switch.

  • Use each switch port's direct connections so the switch can set security based on its current connections.

Related Topics

Parent topic: Considerations for a Secure Environment

2.11 Understanding the Default Security Settings

Oracle Exadata System Software is installed with many default security settings.

Whenever possible and practical, secure default settings should be chosen and configured. The following default settings are used in Oracle Exadata Database Machine:

  • A minimal software installation to reduce attack surface.

  • Oracle Database secure settings developed and implemented using Oracle best practices.

  • A password policy that enforces a minimum password complexity.

  • Failed log in attempts cause a lockout after a set number of failed attempts.

  • All default system accounts in the operating system are locked and prohibited from logging in.

  • Limited ability to use the su command.

  • Password-protected boot loader installation.

  • All unnecessary system services are disabled, including the Internet service daemon (inetd/xinetd).

  • Software firewall configured on the storage cells.

  • Restrictive file permissions on key security-related configuration files and executable files.

  • SSH listen ports restricted to management and private networks.

  • SSH limited to v2 protocol.

  • Disabled insecure SSH authentication mechanisms.

  • Configured specific cryptographic ciphers.

  • Unnecessary protocols and modules are disabled from the operating system kernel.

Parent topic: Security Features of Oracle Exadata Database Machine