1. Security Guide for Oracle Exadata
  2. Keeping the Oracle Exadata Secure
  3. Maintaining a Secure Environment

4.5 Maintaining a Secure Environment

After security measures are implemented, they must be maintained to keep the system secure.

Software, hardware and user access need to be updated and reviewed periodically. For example, organizations should review the users and administrators with access to Oracle Exadata Database Machine, and its deployed services to verify if the levels of access and privilege are appropriate. Without review, the level of access granted to individuals may increase unintentionally due to role changes or changes to default settings. It is recommended that access rights for operational and administrative tasks be reviewed to ensure that each user's level of access is aligned to their roles and responsibilities.

Organizations are encouraged to utilize tools to detect unauthorized changes, configuration drift, and prepare for security updates. Oracle Enterprise Manager provides an integrated solution for managing operational issues for hardware, deployed applications, and services.

Related Topics

Parent topic: Keeping the Oracle Exadata Secure

4.5.1 Maintaining Network Security

Follow these guidelines to ensure the security of local and remote access to the system:

  • Network switch configuration files should be managed offline, and access to the configuration file should be limited to authorized administrators. The configuration file should contain descriptive comments for each setting. Consider keeping a static copy of the configuration file in a source code control system.

    For more information on network switch configuration, refer to the vendor documentation for the network switch.

  • Review the client access network to ensure that secure host and Integrated Lights Out Manager (ILOM) settings are in effect. Review the settings periodically to ensure that they remain intact.

  • Create a login banner to state that unauthorized access is prohibited.

  • Use access control lists to apply restrictions where appropriate.

  • Set time-outs for extended sessions and set privilege levels.

  • Use authentication, authorization, and accounting (AAA) features for local and remote access to a network switch.

  • Use the port mirroring/switch port analyzer (SPAN) capability of the switch for intrusion detection system (IDS) access.

  • Implement port security to limit access based upon a MAC address (MAC ACL).

  • Limit remote configuration to specific IP addresses using SSH (IP ACL).

  • Disable auto-trunking on all ports for any switch connected to Oracle Exadata Database Machine.

  • Require users to use strong passwords by setting minimum password complexity rules and password expiration policies.

  • Enable logging and send logs to a dedicated secure log host.

  • Configure logging to include accurate time information, using NTP and timestamps.

  • Review logs for possible incidents and archive them in accordance with the organization's security policy.

  • Standard 140 of FIPS (Federal Information Processing Standards) relates to security and cryptography. FIPS 140 is a collection of standards published by NIST (National Institute of Standards and Technology), an agency of the United States federal government. FIPS 140 protects data during transit as well as at rest. It specifies security standards for cryptographic components within a computing environment. FIPS 140 is useful for organizations that need to document that their computing environment meets a published level of security. Many government agencies and financial institutions use FIPS 140 qualified systems.

    Configuring FIPS 140 at the Oracle Database level enables the use of FIPS 140 cryptographic modules in the Secure Sockets Layer (SSL), transparent data encryption (TDE), DBMS_CRYPTO PL/SQL package, and Exadata Smart Scan, which protects data while processing Smart Scan offload operations.

Related Topics

Parent topic: Maintaining a Secure Environment

4.5.2 Encrypting System Log Information

Management Server (MS) on database and storage servers supports the syslogconf attribute. Starting with Oracle Exadata System Software release 19.3.0, you can encrypt the log transfer.

In the following topics, syslog and rsyslog are used interchangeably. They both refer to the message logger.

Parent topic: Maintaining a Secure Environment

4.5.2.1 Overview of syslog File Encryption

You can use certificates and the syslogconf attribute to configure encryption of the syslog information.

The syslogconf attribute extends syslog rules for a database server. The attribute can be used to designate that syslog messages be forwarded to a specific remote syslogd service. On the MS, the forwarded messages are directed to a file, console, or management application, depending on the syslog configuration on the MS. This enables system logs from different servers to be aggregated and mined in a centralized logging server for security auditing, data mining, and so on.

The high-level steps required to enable rsyslog encryption are:

  1. Setup a Certificate Authority (CA). This could be any node which has the certtool command. It is recommended to use a non-Exadata server. The CA creates a self-signed certificate. The certificate encryption key must be stored in a secure place. This certificate is used to sign other certificates.

  2. Generate certificates on each participating node. If you do not have a central CA, then the Exadata administrator can generate both the private and public key on the CA and distribute copies to each trusted server. If you have a central CA, then the Exadata administrator generates the private key for each server.

  3. If using a central CA, the Exadata administrator creates a certificate request. This request is then sent to the CA admin, which in turn generates the certificate (containing the public key). The CA admin then sends back the signed certificate to the Exadata administrator.

  4. Install the signed certificates on each participating node. If using a central CA, the Exadata administrator installs the certificate signed by the CA. If you are not using a central CA, then the Exadata administrator installs a copy of private and public keys that were generated on the CA.

  5. Setup a syslog central server. The central server needs syslog.conf setup. It also needs signed certificates.

  6. Enable or disable the encryption of syslog on each client by using CellCLI or DBMCLI.

After completing these steps, the syslog chosen to be transported will be encrypted.

Parent topic: Encrypting System Log Information

4.5.2.2 Configure CA Server and Central rsyslogd Server

Before you can encrypt the syslog transfer, you must generate certificates and sign them by a host that acts as Certificate Authority (CA). This procedure only needs to be completed once.

  1. On the CA server, create a private key and certificate.
    Follow step in rsyslog document for "Setting up the CA". The rsyslog document can be found at https://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html
    1. Generate a private key.
      # certtool--generate-privkey--outfile ca-key.pem --sec-param high
Generating a 3072 bit RSA private key...
    2. Create a self-signed certificate.

      When prompted, supply the requested information about your organization for the certificate. Each certificate is valid for a specified period of time, after which you need to recreate all certificates. So you might want to use a long period, for example 3650 days (10 years).

      To use this certificate to sign other certificates, when asked if this certificate belongs to an authority, you must specify Y. Also reply with a Y when asked:

      • Is this certificate is a TLS web client (or server) certificate?
      • Will the certificate be used for signing (DHE and RSA-EXPORT ciphersuites)?
      • Will the certificate be used for encryption (RSA ciphersuites)?
      • Will the certificate be used to sign other certificates?
      # certtool--generate-self-signed --load-privkey ca-key.pem --outfile ca.pem
Generating a self signed certificate...
Please enter the details of the certificate's distinguished name. Just press enter to ignore a field.
Common name: common_name_for_CA
UID:
Organizational unit name: Org_unit_name
Organization name: Org_name
Locality name: CountyName_or_Locale
State or province name: state_prov
Country name (2 chars): Country_code
Enter the subject's domain component (DC):
This field should not be used in new certificates.
E-mail: CA_user_email_address
Enter the certificate's serial number in decimal (default: 6722248921586908930):

Activation/Expiration time.
The certificate will expire in (days): 3650
Extensions.Does the certificate belong to an authority? (y/N): Y
Path length constraint (decimal, -1 for no constraint):
Is this a TLS web client certificate? (y/N): Y
Will the certificate be used for IPsec IKE operations? (y/N):
Is this a TLS web server certificate? (y/N): Y
Enter a dnsName of the subject of the certificate: CA_hostname
Enter a dnsName of the subject of the certificate:
Enter a URI of the subject of the certificate:
Enter the IP address of the subject of the certificate: CA_IP_Address
Will the certificate be used for signing (DHE and RSA-EXPORT ciphersuites)? (Y/n):  Y
Will the certificate be used for encryption (RSA ciphersuites)? (Y/n): Y
Will the certificate be used to sign OCSP requests? (y/N):
Will the certificate be used to sign code? (y/N):
Will the certificate be used for time stamping? (y/N):
Will the certificate be used to sign other certificates? (y/N): Y
Will the certificate be used to sign CRLs? (y/N):
Enter the URI of the CRL distribution point:
X.509 Certificate Information:
        Version: 3
        Serial Number (hex): 5d4a39c736f0bf02
        Validity:
                Not Before: Wed Aug 07 02:39:03 UTC 2019
                Not After: Sat Aug 04 02:39:03 UTC 2029
        Subject: CN=common_name_for_CA,OU=Org_unit_name,O=Org_name,L=CountyName_or_Locale,ST=state_prov,C=Country_code,CA_user_email_address
        Subject Public Key Algorithm: RSA
        Algorithm Security Level: High (3072 bits)
                Modulus (bits 3072):
                               00:a5:b2:d6:5d:33:2c:79:2d:9c:79:f4:7b:0b:27:ef
                               20:29:ff:21:0c:19:11:22:c1:17:26:fc:46:5c:bb:c0
                               f6:9d:d0:ff:0d:4d:9e:25:18:62:53:8b:c6:4e:8b:05
...
                               03:21:7d:87:af:2b:a2:0b:42:ee:45:36:d7:14:aa:e8
                               6e:c1:25:4d:5d:66:db:fc:82:0c:92:69:66:04:70:a7
                               5b
                Exponent (bits 24):
                        01:00:01
        Extensions:
                Basic Constraints (critical):
                        Certificate Authority (CA): TRUE
                Key Purpose (not critical):
                        TLS WWW Client.
                        TLS WWW Server.
                Subject Alternative Name (not critical):
                        DNSname: CA_host_name
                        IPAddress: CA_IP_Address
                Key Usage (critical):
                        Digital signature.
                        Key encipherment.
                        Certificate signing.
                Subject Key Identifier (not critical):
                               2b3c1e34e5a0347b6e62fd893430fa0b20d2d0a3
Other Information:
        Public Key ID:
                2b3c1e34e5a0347b6e62fd893430fa0b20d2d0a3
        Public key's random art:
                +--[ RSA 3072]----+
                |                 |
                | .               |
                |. o o . .        |
                | + o + +         |
                |E . = + S        |
                |o. . O . .       |
                |  o o @ .        |
                |   + = B .       |
                |    o.o o        |
                +-----------------+

Is the above information ok? (y/N): y
Signing certificate...
#
    3. Secure the ca-key.pem file.
      Place the file in a secure place. Ensure that no user except root can access the certificates (not even read permissions). 
      # chmod 600 ca-key.pem
  2. Generate the machine certificate.

    Follow the step in the rsyslog document for "Generating the machine certificate".

    # certtool --generate-privkey --outfile machine-key.pem --sec-param high
Generating a 3072 bit RSA private key...

    This command can be run by the Exadata administrator. The output file is sent to the CA.

    # certtool --generate-request --load-privkey machine-key.pem --outfile request.pem
Generating a PKCS #10 certificate request...
Common name: Trusted_server
Organizational unit name: Org_unit_name
Organization name: Org_name
Locality name: CountryName_or_Locale
State or province name: state_prov
Country name (2 chars): Country_code
Enter the subject's domain component (DC):
UID:
Enter a dnsName of the subject of the certificate: Trusted_server_hostname
Enter a dnsName of the subject of the certificate:
Enter a URI of the subject of the certificate:
Enter the IP address of the subject of the certificate: Trusted_server_IP
Enter the e-mail of the subject of the certificate:
Enter a challenge password:
Does the certificate belong to an authority? (y/N):
Will the certificate be used for signing (DHE and RSA-EXPORT ciphersuites)? (Y/n): Y
Will the certificate be used for encryption (RSA ciphersuites)? (Y/n): Y
Will the certificate be used to sign code? (y/N):
Will the certificate be used for time stamping? (y/N):
Will the certificate be used for IPsec IKE operations? (y/N):
Will the certificate be used to sign OCSP requests? (y/N):
Is this a TLS web client certificate? (y/N): Y
Is this a TLS web server certificate? (y/N): Y

    This command is run by the CA administrator, using the request generated by the previous command. Review this example to see how to answer each prompt.

    #certtool --generate-certificate --load-request request.pem --outfile machine-cert.pem 
 --load-ca-certificate ca.pem --load-ca-privkey ca-key.pem
Generating a signed certificate...
Enter the certificate's serial number in decimal (default: 6722252284267403216):

Activation/Expiration time.
The certificate will expire in (days): 3650

Extensions.
Do you want to honour the extensions from the request? (y/N):
Does the certificate belong to an authority? (y/N):
Is this a TLS web client certificate? (y/N): y
Will the certificate be used for IPsec IKE operations? (y/N):
Is this a TLS web server certificate? (y/N): y
Enter a dnsName of the subject of the certificate: Trusted_server
Enter a dnsName of the subject of the certificate:
Enter a URI of the subject of the certificate:
Enter the IP address of the subject of the certificate: Trusted_server_IP_addr
Will the certificate be used for signing (DHE and RSA-EXPORT ciphersuites)? (Y/n): y
Will the certificate be used for encryption (RSA ciphersuites)? (Y/n): y
Will the certificate be used to sign OCSP requests? (y/N):
Will the certificate be used to sign code? (y/N):
Will the certificate be used for time stamping? (y/N):
X.509 Certificate Information:
        Version: 3
        Serial Number (hex): 5d4a3cd6265117d0
        Validity:
                Not Before: Wed Aug 07 02:52:06 UTC 2019
                Not After: Sat Aug 04 02:52:06 UTC 2029
        Subject: OU=Org_unit_name,O=Org_name,L=CountryName_or_Locale,ST=state_prov,C=Country_code
        Subject Public Key Algorithm: RSA
        Algorithm Security Level: High (3072 bits)
                Modulus (bits 3072):
                               00:cf:f6:44:d4:e0:a8:b5:e6:48:8b:26:cb:59:c4:47
                               c5:f7:03:5f:99:88:ac:ed:94:d4:90:92:e4:61:75:4c
                               67:c4:16:c2:bf:31:40:f4:92:1e:94:73:08:d1:d5:3a
...
                               14:2f:08:02:74:f2:43:40:37:29:bd:6e:92:a6:07:6e
                               99:1e:e5:67:b8:0c:eb:a7:3d:9b:a5:35:46:8c:d3:e4
                               f7
                Exponent (bits 24):
                        01:00:01
        Extensions:
                Basic Constraints (critical):
                        Certificate Authority (CA): FALSE
                Key Purpose (not critical):
                        TLS WWW Client.
                        TLS WWW Server.
                Subject Alternative Name (not critical):
                        DNSname: Trusted_server
                        IPAddress: Trusted_server_IP_addr
                Key Usage (critical):
                        Digital signature.
                        Key encipherment.
                Subject Key Identifier (not critical):
                               7c343773a33cdbc6113fd05b3418ad129e9c4a64
                Authority Key Identifier (not critical):
                               2b3c1e34e5a0347b6e62fd893430fa0b20d2d0a3
Other Information:
        Public Key ID:
                7c343773a33cdbc6113fd05b3418ad129e9c4a64
        Public key's random art:
                +--[ RSA 3072]----+
                |             .+..|
                |         E . ..o.|
                |        o = B.=..|
                |       . o X *.+o|
                |        S o = .o.|
                |         o   = ..|
                |            . +  |
                |             .   |
                |                 |
                +-----------------+

Is the above information ok? (y/N): y
Signing certificate...
  3. Configure the rsyslogd server.

    Install the certificates on the designated rsyslogd server. The server needs machine-cert.pem, machine-key.pem, and a copy of ca.pem. Add these certificates to the /etc/pki/rsyslog/rsyslog.conf file.

    Ensure that no user except root can access the certificates (not even read permissions). 

    # chmod 600 cert_name.pem

    Configure the server so that it accepts messages from all machines in your domain that have certificates from your CA. In this setup, you can use wildcards to ease adding new systems. Using wildcards permits the server to accept messages from systems whose names match *.domain. For example, if your domain is example.net, to allow permitted peers from different domain trees, you could use the following configuration: 

    $InputTCPServerStreamDriverPermittedPeer "*.example.net","*.example.com"

    The following example shows a sample /etc/pki/rsyslog/rsyslog.conf file for the rsyslogd central server. This example configures the rsyslogd server to accept messages from any server on port 10514. 

    $ModLoad imtcp
# make gtls driver the default and set certificate files
$DefaultNetstreamDriver="gtls"
$DefaultNetstreamDriverCAFile="/etc/pki/rsyslog/ca.pem"
$DefaultNetstreamDriverCertFile="/etc/pki/rsyslog/machine-cert.pem"
$DefaultNetstreamDriverKeyFile="/etc/pki/rsyslog/machine-key.pem")

$InputTCPServerStreamDriverAuthMode x509/name 
$InputTCPServerStreamDriverPermittedPeer * 
$InputTCPServerStreamDriverMode 1 # run driver in TLS-only mode 
$InputTCPServerRun 10514 # start up listener at port 10514
  4. Restart the rsyslogd process.
    #service rsyslog stop

#service rsyslog start

Parent topic: Encrypting System Log Information

4.5.2.3 Configure a Client for SYSLOG Encryption

Configure the client so that it checks the server identity and sends messages only if the server identity is known.

This configuration prevents malicious actors gaining access to the syslog data. These steps need to be performed on each server running the syslog client.

Before starting this task, you must have completed the steps in Configure CA Server and Central rsyslogd Server. You will need the IP address and port number for the rsyslogd central server in this procedure.

  1. Copy the ca.pem, machine-key.pem and machine-cert.pem certificates from the central rsyslogd server to the /etc/pki/rsyslog/ directory on the client server.
  2. Use CellCLI or DBMCLI to modify the syslogconf attribute on the client server.
    The CellCLI or DBMCLI command appends the value you specify for syslogconf to the rsyslog.conf file and restarts the syslogd process.

    For a storage server client, you would use a command similar to the following:

    ALTER CELL syslogconf=('$DefaultNetstreamDrivergtls',\
'$DefaultNetstreamDriverCAFile /etc/pki/rsyslog/ca.pem',\
'$DefaultNetstreamDriverCertFile /etc/pki/rsyslog/machine-cert.pem',\
'$DefaultNetstreamDriverKeyFile /etc/pki/rsyslog/machine-key.pem',\
'$ActionSendStreamDriverAuthMode x509/name',\
'$ActionSendStreamDriverPermittedPeer *',\
'$ActionSendStreamDriverMode 1','user.* @@rsyslogd_server_IP_address:port')

    If you are configuring syslog encryption for a database server, then use DBMCLI and replace ALTER CELL with ALTER DBSERVER in the above command.

  3. Verify the syslogconf attribute has been updated correctly.
    CellCLI> LIST CELL ATTRIBUTES syslogconf
      $DefaultNetstreamDriver               gtls
      $DefaultNetstreamDriverCAFile         /etc/pki/rsyslog/ca.pem
      $DefaultNetstreamDriverCertFile       /etc/pki/rsyslog/machine-cert.pem
      $DefaultNetstreamDriverKeyFile        /etc/pki/rsyslog/machine-key.pem
      $ActionSendStreamDriverAuthMode       x509/name
      $ActionSendStreamDriverPermittedPeer  * 
      $ActionSendStreamDriverMode           1  
      user.*                                @@rsyslogd_server_IP_address:port

    If you are configuring syslog encryption for a database server, then use DBMCLI and replace LIST CELL with LIST DBSERVER in the above command.

  4. Repeat these steps for each client server that needs to encrypt the syslog information.

Parent topic: Encrypting System Log Information

4.5.2.4 Confirming Syslog Encryption is Enabled

After configuring rsyslog encryption, you can perform basic checks to verify the encryption is working.

  1. Validate the Syslog configuration.

    For a database server, use the following command:

    DBMCLI> ALTER DBSERVER VALIDATE SYSLOGCONF 'kern.info'

    For a storage server, use the following command:

    CellCLI> ALTER CELL VALIDATE SYSLOGCONF 'kern.info'
  2. Check the message in /var/log/messages.
  3. Check for rsyslog error messages in /var/log/messages.
  4. To verify the messages are transmitted in encrypted form, use the tcpdump utility.

    From the target server, use the following command:

    % tcpdump -A src source-server-IP-address

    The output from the tcpdump command should not be readable text.

Parent topic: Encrypting System Log Information

4.5.3 Guarding Against Unauthorized Operating System Access

AIDE is a utility that creates a database of files on the system, and then uses that database to ensure file integrity and to detect system intrusions.

Parent topic: Maintaining a Secure Environment

4.5.3.1 About Advanced Intrusion Detection Environment (AIDE)

AIDE helps to track down which file has been affected in case the system was compromised.

AIDE runs a daily cron job that monitors the system for changes to files in specific directories. It takes a snapshot of all files in the system defined by rules specified in its configuration file. AIDE compares the current file with the snapshot of files taken previously. If any content changes in the snapshot file, AIDE automatically raises CRITICAL software alerts. AIDE uses the default alerting destination email and sends the alert email to the configured SMTP email address. The results of the daily AIDE scan are written to /var/log/aide/aide.log.

The file snapshot database created by AIDE is stored at /var/lib/aide/aide.db.gz. You can backup this file daily if you want to audit what happened on a given system on daily basis.

Parent topic: Guarding Against Unauthorized Operating System Access

4.5.3.2 Managing AIDE Components

You can use the exadataAIDE utility to manage AIDE.

AIDE comes pre-configured with Exadata System Software release 19.1; you do not have to perform any setup tasks to use this feature.

exadataAIDE Syntax

The utility is located at /opt/oracle.SupportTools/exadataAIDE. 

exadataAIDE [-s|-status] [-e|enable] [-d|disable] [-u|-update] [-h|help]

Description of syntax options:

  • -s[tatus] : Print the current status of the AIDE daily cron job
  • -e[nable] : Enable the AIDE daily cron job
  • -d[isable] : Disable the AIDE daily cron job
  • -u[pdate] : Update the AIDE database metadata and run the daily scan
  • -h[elp] : Print the command syntax and help information
  • Get the current status of the aide cron job.
    exadataAIDE –status
  • Disable the daily AIDE scan.
    exadataAIDE –disable
  • Enable the daily AIDE scan.
    exadataAIDE –enable
  • Update the AIDE database after making changes to the system.
    exadataAIDE –update

Parent topic: Guarding Against Unauthorized Operating System Access

4.5.3.3 Adding Custom AIDE Rules

You can instruct AIDE to not check for changes in specific directories during AIDE the metadata initialize step and also during the daily cron check.

  1. Log in to the server or virtual machine as the root user.
  2. Edit the file /etc/aide.conf.
    Add the directories you want AIDE to skip during its scan. Prefix the directory path with an exclamation point.
    # Ignore /opt/myapp directory content
!/opt/myapp
  3. Update the AIDE database metadata.
    # /opt/oracle.SupportTools/exadataAIDE -u
AIDE will not raise any alerts for /opt/myapp directory content changes going forward.

Parent topic: Guarding Against Unauthorized Operating System Access

4.5.3.4 Managing AIDE Alerts when Updating Exadata Software

Software and hardware updates and installs tend to change the size and nature of operating system files. Therefore, you should re-generate the AIDE database after making changes.

Use the following steps to reduce false alarms when updating software:

Note:

Oracle Exadata Deployment Assistant (OEDA) has intelligence built-in to avoid false alerts when installing or updating software.
  1. Disable AIDE monitoring.
    exadataAIDE –disable
  2. Update the software on your system.
  3. Re-enable AIDE monitoring.
    exadataAIDE –enable
  4. Update the AIDE database with the recent file changes.
    exadataAIDE –update

Parent topic: Guarding Against Unauthorized Operating System Access

4.5.4 Updating Software and Firmware

Effective and proactive software management is a critical part of system security.

Security enhancements are introduced through new releases and software updates. Oracle recommends installing the latest release of the software, and all necessary security updates on the equipment. The application of Oracle recommended and security updates is a best practice for the establishment of baseline security.

Operating system and kernel updates for Oracle Exadata database servers and storage servers are delivered with Oracle Exadata System Software updates. Power distribution unit (PDU) firmware updates are handled separately from the software and other firmware updates. Ensure that the PDU is running the latest approved firmware for Oracle Exadata. As PDU firmware updates are not issued frequently, it is usually sufficient to check the PDU firmware release when upgrading Oracle Exadata System Software.

Note:

Devices such as network switches that contain firmware may require patches and firmware updates.

Related Topics

Parent topic: Maintaining a Secure Environment

4.5.4.1 Regenerate SSH Keys for ILOM Version 5

On systems with ILOM version 5, you can create an SSH key with a key size of 3072 bits.

Previous versions of Integrated Lights Out Manager (ILOM) support a 1024 bit SSH key, while ILOM version 5 supports a 3072 bit SSH key.

If you upgrade an existing Exadata system to ILOM version 5, then the upgraded system preserves the original 1024 bit SSH key. To use a 3072 bit SSH key, you must manually regenerate the SSH key in the ILOM service processor by using the following command: 

-> set /SP/services/ssh generate_new_key_type=rsa generate_new_key_action=true

After you regenerate the SSH key, you can query ILOM to report the public key value.

-> show /SP/services/ssh/keys/rsa

/SP/services/ssh/keys/rsa 
          Targets: 
 
          Properties:     
            fingerprint = hex-id     
            fingerprint_algorithm = SHA1     
            length = 3072     
            privatekey = (Cannot show property)
            publickey = public-key-value

Note:

Systems originally deployed with ILOM version 5 use 3072 bit keys by default.

Parent topic: Updating Software and Firmware

4.5.5 Ensuring Data Security Outside of Oracle Exadata Database Machine

It is important to protect data stored outside of Oracle Exadata Database Machine, on backups or removed hard drives.

Data located outside of Oracle Exadata Database Machine can be secured by backing up important data. The data should then be stored in an off-site, secure location. Retain the backups according to organizational policies and requirements.

When disposing of an old hard drive, physically destroy the drive or completely erase all the data on the drive. Deleting the files or reformatting the drive removes only the address tables on the drive. The information can still be recovered from a drive after deleting files or reformatting the drive. The Oracle Exadata Database Machine disk retention support option allows the retention of all replaced hard drives and flash drives, instead of returning them to Oracle.

The CellCLI command DROP CELLDISK includes an option to securely erase data by overwriting the data. If Oracle Exadata Storage Server drives contain sensitive data that needs to be erased for redeployment or another purpose, then the secure erase feature should be used on the storage cell. The ERASE option ensures that all data is overwritten with random data, and erased up to seven times. This ensures that the data cannot be recovered, and that the data is permanently erased.

Starting with Oracle Exadata System Software release 19.1.0, if you use DROP CELLDISK and select to erase disks using 1pass, 3pass, or 7pass method, Oracle Exadata System Software uses the better and faster Secure Eraser if supported by the underlying hardware.

Parent topic: Maintaining a Secure Environment