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.
- Maintaining Network Security
- Encrypting System Log Information
Management Server (MS) on database and storage servers supports thesyslogconf
attribute. Starting with Oracle Exadata System Software release 19.3.0, you can encrypt the log transfer. - 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. - Updating Software and Firmware
Effective and proactive software management is a critical part of system security. - 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.
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.
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.
- Overview of syslog File Encryption
You can use certificates and thesyslogconf
attribute to configure encryption of the syslog information. - 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. - 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. - Confirming Syslog Encryption is Enabled
After configuring rsyslog encryption, you can perform basic checks to verify the encryption is working.
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:
- 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. -
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.
-
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.
-
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.
-
Setup a syslog central server. The central server needs
syslog.conf
setup. It also needs signed certificates. -
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.
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.
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.
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.
- About Advanced Intrusion Detection Environment (AIDE)
AIDE helps to track down which file has been affected in case the system was compromised. - Managing AIDE Components
You can use theexadataAIDE
utility to manage AIDE. - 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 dailycron
check. - 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.
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
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.
/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.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.- 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.
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