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 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 Restricting the Binaries Used to Boot the System

Secure Boot is a method used to restrict which binaries can be executed to boot the system. With Secure Boot, the system UEFI firmware will only allow the execution of 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 executed component is verified. This prevents malware from hiding embedded code in the boot chain.

Secure Boot supports a chain of trust that goes down to the kernel module level. 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 executed by the BIOS.

  • Forbidden Database (DBX)—Keys that are blacklisted. 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.

Secure Boot is available on X7-2 and X7-2L servers.

2.1.1 Enabling and Disabling Secure Boot

Secure Boot is enabled by default in the BIOS.

Secure boot is configured in the BIOS and is enabled by default. You can disable secure boot by pressing F12 during the boot process, navigating to the EFI boot menu and disabling the Secure Boot option.

Oracle recommends that you leave the Secure Boot option enabled.

To verify that Secure Boot is enabled, use the following command:

# mokutil --sb-state
SecureBoot enabled

2.1.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 and are valid for three years 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@scaqae03celadm11 ~]# mokutil --list-enrolled
    [key 1]
    SHA1 Fingerprint: 17:62:e7:3b:f1:6c:d7:89:1f:cd:0c:49:0c:4c:02:0c:30:41:0c:d0
    Certificate:
     Data:
       Version: 3 (0x2)
       Serial Number:
         0f:2d:c0:56:d7:4b:e5:54:51:9d:ef:7e:c2:33:2e:d3
     Signature Algorithm: sha256WithRSAEncryption
      Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert EV Code Signing CA (SHA2)
            Validity
                Not Before: Nov 24 00:00:00 2015 GMT
                Not After : Nov 27 12:00:00 2018 GMT
            Subject: businessCategory=Private Organization/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/serialNumber=4028125/street=500 Oracle Parkway/postalCode=94065, C=US, ST=California, L=Redwood Shores, O=Oracle Corporation, CN=Oracle Corporation
         Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
               Public-Key: (2048 bit)
               Modulus:
                  00:b3:de:ff:b5:6c:6c:d1:7a:24:c5:44:de:03:e8:
                  29:22:be:0c:3b:06:4a:68:a9:a2:b4:1b:1d:2a:9d:
                  ...                    
               Exponent: 65537 (0x10001)
            X509v3 extensions:
              X509v3 Authority Key Identifier: 
                  keyid:8F:E8:7E:F0:6D:32:6A:00:05:23:C7:70:97:6A:3A:90:FF:6B:EA:D4
    
             X509v3 Subject Key Identifier: 
                    51:69:8E:C3:BE:0F:5E:B8:CB:A8:EC:19:7D:29:18:79:09:8F:AD:E4
             X509v3 Subject Alternative Name: 
                    othername: <unsupported>
             X509v3 Key Usage: critical
                    Digital Signature
             X509v3 Extended Key Usage: 
                    Code Signing
             X509v3 CRL Distribution Points: 
    
                 Full Name:
                   URI:http://crl3.digicert.com/EVCodeSigningSHA2-g1.crl
    
                 Full Name:
                   URI:http://crl4.digicert.com/EVCodeSigningSHA2-g1.crl
    
             X509v3 Certificate Policies: 
                 Policy: 2.16.840.1.114412.3.2
                   CPS: https://www.digicert.com/CPS
                 Policy: 2.23.140.1.3
    
             Authority Information Access: 
                 OCSP - URI:http://ocsp.digicert.com
                 CA Issuers - URI:http://cacerts.digicert.com/DigiCertEVCodeSigningCA-SHA2.crt
    
             X509v3 Basic Constraints: critical
                 CA:FALSE
       Signature Algorithm: sha256WithRSAEncryption
             6d:42:58:c7:f1:aa:db:e7:5c:7f:d3:47:29:0a:f4:b7:f7:c0:
             0e:55:29:5b:79:60:91:77:4f:f6:ec:b3:a7:9e:e1:5a:e1:79:
             ...
    

2.1.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.1.2.2 Removing Keys for Secure Boot Using mokutil

You can delete ore 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.1.3 Checking for Secure Boot Environment

You can use operating system commands to determine if Secure Boot is enabled.

  1. Log in as the root user.
  2. Use dmesg to see if Secure Boot is enabled.
    # dmesg | grep &quot;Secure boot&quot; 
    [ 0.000000] Secure boot enabled
    
  3. Alternatively, use the od command to determine if Secure Boot is enabled.
    $ od -An -t u1 /sys/firmware/efi/vars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c/data 
    

    This command returns a value of either 0 (not enabled) or 1 (enabled).

2.1.4 Troubleshooting Secure Boot

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

The certificates are signed by DigiCert and are valid for three years from the date of signing. 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
Cause
error: file has invalid signature. error: You need to load the kernel first.
The grub loader is signed, but the kernel is unsigned.
Secure boot violation: Invalid signature detected. Check Secure Boot Policy in Setup.
The grub loader has an invalid signature.
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.

2.2 Using Isolation Policies

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:

2.2.1 Isolating 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 redundant 10 Gbps Ethernet network that ensures reliable, high-speed access to services running on the system. Management access is provided over a physically separate 1 Gbps Ethernet network. This provides a separation between operational and management networks.

Organizations may choose to further segregate network traffic over the client access Ethernet 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 redundant InfiniBand network. The InfiniBand network is a high-performance, low-latency backplane for communication between Exadata Storage Servers and database servers. By default, 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.

2.2.2 Isolating Databases

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.

2.2.3 Isolating Storage

Oracle Exadata Database Machine storage is isolated from the rest of the architecture through the use of a private InfiniBand network. The storage managed by 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.

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

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

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

2.3.3 Controlling Storage Access

Oracle Exadata Storage Server 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 owner of the 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 CDB or non-CDB. Because of this, it is not possible to have database-scoped security per 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.

See Also:

Oracle Exadata System Software User's Guide

2.4 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. Oracle Exadata Database Machine includes network cryptographic services.

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 Managers (ILOMs). SSL/TLS can enable secure communications between applications and other services.

Databases cryptographic services are available from Oracle Advanced Security. Oracle Advanced Security encrypts information in the database using the transparent data encryption (TDE) functionality. TDE supports encryption of application table spaces, and encryption of individual columns within a table. Data stored in temporary table spaces, and redo logs are also encrypted. When the database is backed up, the data remains encrypted on destination media. This protects information at rest no matter where it is physically stored. For organizations concerned about the confidentiality of stored database content, database encryption, either at the table space level or column-level, Oracle Advanced Security should be considered.

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.

2.5 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 Database Machine 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.

2.5.1 Monitoring and Auditing Database Activity

Oracle Database support of fine-grained auditing allows organizations to establish policies that selectively determine when audit records are generated. This 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.

2.6 Maintaining Quality Service

There are many ways that applications can be attacked besides breaching a boundary or subverting an access control policy. Oracle Exadata Database Machine 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 Storage Server Software includes I/O Resource Manager (IORM) to manage interdatabase and intradatabase I/O resources. IORM allows different databases with different performance requirements to share a common 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 (Resource Manager), and instance caging support the ability to dynamically control access to CPU resources using fine-grained methods. 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.

2.7 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 Oracle ILOM.

Oracle 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, and IPMI v2.0 and SNMPv3 protocols.

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