1. Security Guide for Oracle Exadata
  2. Keeping the Oracle Exadata Secure

4 Keeping the Oracle Exadata Secure

This chapter describes policies and procedures to keep Oracle Exadata secure.

4.1 Securing the Hardware

After installation of Oracle Exadata Database Machine, the hardware should be secured.

Hardware can be secured by restricting access to the hardware and recording the serial numbers. Oracle recommends the following practices to restrict access:

  • Install Oracle Exadata Database Machine and related equipment in a locked, restricted-access room.

  • Lock the rack door unless service is required on components within the rack.

  • Restrict access to hot-pluggable or hot-swappable devices because the components can be easily removed by design. See

  • Store spare field-replaceable units (FRUs) or customer-replaceable units (CRUs) in a locked cabinet. Restrict access to the locked cabinet to authorized personnel.

  • Limit SSH listener ports to the management and private networks.

  • Use SSH protocol 2 (SSH-2) and FIPS 140-2 approved ciphers.

  • Limit SSH allowed authentication mechanisms. Inherently insecure methods are disabled.

  • Mark all significant items of computer hardware, such as FRUs.

  • Keep hardware activation keys and licenses in a secure location that is easily accessible to the system managers in the case of a system emergency.

  • Record the serial numbers of the components in Oracle Exadata Database Machine, and keep a record in a secure place. All components in Oracle Exadata Database Machine have a serial number.

Related Topics

Parent topic: Keeping the Oracle Exadata Secure

4.1.1 Getting the Rack Serial Number

Use the ipmitool utility to get the serial number for the rack.

When interacting with Oracle Support Services, the CSI number for a rack is based on the rack serial number.

  1. Log in to one of the servers in the rack as the root user.
  2. Use ipmitool to get the serial number for the rack.
    # ipmitool sunoem cli "show /SP system_identifier"
Connected. Use ^D to exit.
-> show /SP system_identifier

 /SP
    Properties:
        system_identifier = Exadata Database Machine X2-8xxxxAKyyyy


-> Session closed
Disconnected

Parent topic: Securing the Hardware

4.1.2 Getting the Serial Numbers for Rack Components

The CheckHWnFWProfile command can be used to display the serial number of most of the system components.

  1. Log in to one of the servers in the rack as the root user.
  2. On each server in the rack, use CheckHWnFWProfile with the -S option to display the serial number of the components for that server.
    # /opt/oracle.SupportTools/CheckHWnFWProfile -S > /tmp/CheckHWnFWProfile_hostname.txt

    The result is specific to each server, so the command must be performed on every node. The following is a partial example of the output:

    Server_Model=ORACLE_SERVER_X8-2L
====START SERIAL NUMBERS====
==Motherboard, from dmidecode==
--System serial--
1904XCA000
--Motherboard serial--
469996N+0000RD01RN
--Chassis serial--
1900XCA000
--Rack serial--
AK00400000
==Infiniband HCA==
ID:      CX354A - ConnectX-3 QSFP
PN:      7046442
EC:      XX
SN:      465000K-1800000000
V0:      PCIe Gen3 x8
==Motherboard, RAM etc from ipmitool==
FRU Device Description : Builtin FRU Device (LUN 0 ID 0)
...
 Product Name          : ILOM
 Product Version       : 4.0.4.38.a

FRU Device Description : BMC
...
 Product Name          : ILOM
  Product Version       : 4.0.4.38.a

FRU Device Description : /SYS (LUN 0 ID 3)
...
 Product Part Number   : 8200669
 Product Serial        : 1900XCA000

FRU Device Description : DBP (LUN 0 ID 210)
 
 Board Part Number     : 7341141
 Board Extra           : Rev 09

FRU Device Description : HDD0 (LUN 0 ID 47)
 Device not present (Requested sensor, data, or record not found)

FRU Device Description : HDD1 (LUN 0 ID 48)
 Device not present (Requested sensor, data, or record not found)

...

FRU Device Description : MB (LUN 0 ID 4)
 Board Mfg Date        : Sun Jan 20 16:57:00 2019
 Board Mfg             : Oracle Corporation
...

FRU Device Description : MB/BIOS (LUN 0 ID 5)
...

FRU Device Description : MB/CPLD (LUN 0 ID 8)
 Product Manufacturer  : Oracle Corporation
 Product Name          : Power Control FPGA
 Product Version       : FW:3.9

FRU Device Description : M2R0/SSD0 (LUN 0 ID 211)
 Device not present (Requested sensor, data, or record not found)

FRU Device Description : M2R1/SSD0 (LUN 0 ID 212)
 Device not present (Requested sensor, data, or record not found)

FRU Device Description : MB/NET0 (LUN 0 ID 43)
 Product Manufacturer  : INTEL
 Product Name          : 1G Ethernet Controller
...

FRU Device Description : MB/P0 (LUN 0 ID 16)
 Product Manufacturer  : Intel
 Product Name          : Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz
...

FRU Device Description : MB/P0/D0 (LUN 0 ID 24)
 Product Manufacturer  : Samsung
 Product Name          : 16384MB DDR4 SDRAM DIMM
...

FRU Device Description : MB/P0/D1 (LUN 0 ID 25)
 Device not present (Requested sensor, data, or record not found)

FRU Device Description : MB/P0/D2 (LUN 0 ID 26)
 Product Manufacturer  : Samsung
 Product Name          : 16384MB DDR4 SDRAM DIMM
...


FRU Device Description : MB/P1 (LUN 0 ID 17)
 Product Manufacturer  : Intel
 Product Name          : Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz
...

FRU Device Description : MB/P1/D0 (LUN 0 ID 36)
 Product Manufacturer  : Samsung
 Product Name          : 16384MB DDR4 SDRAM DIMM
...
FRU Device Description : PS0 (LUN 0 ID 63)
...
FRU Device Description : PS1 (LUN 0 ID 64)
...
FRU Device Description : SP/NET0 (LUN 0 ID 1)
...
FRU Device Description : SP/NET1 (LUN 0 ID 2)
...
FRU Device Description : /UUID (LUN 0 ID 6)
...
FRU Device Description : TOP_LEVEL_CH (LUN 0 ID 251)
 Chassis Type          : Rack Mount Chassis
 Chassis Part Number   : 8200669
 Chassis Serial        : 1900XCA0000
 Chassis Extra         : chassis_name:ORACLE SERVER X8-2L

FRU Device Description : TOP_LEVEL_PROD (LUN 0 ID 250)
 Product Manufacturer  : Oracle Corporation
 Product Name          : Exadata X8-2
 Product Part Number   : Exadata X8-2
 Product Serial        : AK00430000

====END SERIAL NUMBERS====

Parent topic: Securing the Hardware

4.1.3 Getting the Rack Serial Number for a Cisco 9336C or 9348 Switch

Use the show license host-id command on the switch to get the serial number.

  1. Connect to the switch from a server with SSH equivalency configured, or log in as the admin user.
  2. Obtain the serial number for the switch by entering the show license host-id command.

    The host ID is also referred to as the device serial number.

    # switch# show license host-id
License hostid: VDH=FLA12345678

    Use the entire ID that appears after the equal sign (=). In this example, the host ID is FLA12345678.

Parent topic: Securing the Hardware

4.1.4 Getting the Rack Serial Number for a Sun Datacenter InfiniBand Switch 36

Use the showfruinfo command on the switch to get the serial number.

  1. Log in to the switch as root.
    $ ssh root@switch_name
  2. Use the showfruinfo command to view the serial number for the switch.
    root@ib-switch-> showfruinfo 
Sun_Man1R:
UNIX_Timestamp32 : Fri Mar 19 16:29:59 2010
Sun_Fru_Description : ASSY,NM2-GW
Vendor_ID_Code : 11 E1
Vendor_ID_Code_Source : 01
Vendor_Name_And_Site_Location : 4577 CELESTICA CORP. SAN JOSE CA US
Sun_Part_Number : 5111402
Sun_Serial_Number : 0110SJC-1010NG0040
Serial_Number_Format : 4V3F1-2Y2W2X4S
Initial_HW_Dash_Level : 03
Initial_HW_Rev_Level : 50
Sun_Fru_Shortname : NM2 gateway
Sun_Hazard_Class_Code : Y
Sun_SpecPartNo : 885-1655-01 
Sun_FRU_LabelR:
Sun_Serial_Number : AK000XXXX2
FRU_Part_Dash_Number : 541-4188-01

Parent topic: Securing the Hardware

4.1.5 Getting the Serial Number for a Cisco 4948 Ethernet Switch

Use the sh inventory command on the switch to get the serial number.

  1. Log in to the Cisco Ethernet switch.
  2. Obtain the serial number for the switch and its components by entering the sh inventory command.
    # Switch# sh inventory
NAME: "Switch System", DESCR: "Cisco Systems, Inc. WS-C4948 1 slot switch "
PID:                   , VID:      , SN: FOX0000G0B6
NAME:  "Linecard(slot 1)", DESCR: "10/100/1000BaseT (RJ45), 1000BaseX (SFP) 
 Supervisor with 48 10/100/1000BASE-T ports and 4 1000BASE-"
PID: WS-C4948          , VID: V09  , SN: FOX0000G0B6
NAME: "Power Supply 1", DESCR: "Power Supply ( AC 300W )"
PID: PWR-C49-300AC     , VID:      , SN: QCS0000B1XR
NAME: "Power Supply 2", DESCR: "Power Supply ( AC 300W )"
PID: PWR-C49-300AC     , VID:      , SN: QCS0000B1X5

Parent topic: Securing the Hardware

4.2 Securing the Software

Frequently, hardware security is implemented through software measures.

Implement the following guidelines to protect hardware and software:

  • Change all default passwords when the system is installed at the site. Oracle Exadata Database Machine uses default passwords for initial installation and deployment that are widely known. A default password could allow unauthorized access to the equipment. Devices such as the network switches have multiple user accounts. Be sure to change all account passwords on the components in the rack.

  • Limit use of the root super user account. Create and use Integrated Lights Out Manager (ILOM) user accounts for individual users to ensure a positive identification in audit trails, and less maintenance when administrators leave the team or company.

  • Ensure Oracle Exadata Database Machine is deployed with separate software owner accounts for Oracle Grid Infrastructure and Oracle Database software installations.

    Note:

    Separate software owner accounts for Oracle Grid Infrastructure and Oracle Database software installations are required for enabling DB-scoped security.

  • Disable unnecessary protocols and modules in the operating system.

  • Restrict physical access to USB ports, network ports, and system consoles. Servers and network switches have ports and console connections, which provide direct access to the system.

  • Restrict the capability to restart the system over the network.

  • Refer to the documentation to enable available security features.

Oracle Exadata Database Machine can leverage all the security features available with Oracle Database releases installed on legacy platforms. Oracle Database security products and features include the following:

  • Oracle Advanced Security

  • Oracle Audit Vault

  • Data Masking

  • Oracle Database Firewall

  • Oracle Database Vault

  • Oracle Label Security

  • Oracle Secure Backup

  • Oracle Total Recall

Using the Oracle privileged user and multi-factor access control, data classification, transparent data encryption, auditing, monitoring, and data masking, customers can deploy reliable data security solutions that do not require any changes to existing applications.

Related Topics

Parent topic: Keeping the Oracle Exadata Secure

4.3 Disabling SSH on Storage Servers

If required, you can lock the storage servers to block SSH access. By default, SSH is enabled on storage servers.

If SSH access is blocked, you can still perform operations on the storage server using ExaCLI, which runs on the database servers and communicates using HTTPS and REST APIs to a web service running on the storage server.

When you need to perform operations that require you to log in to the storage server, you can temporarily unlock the storage server. After the operation is complete, you can relock the storage server.

Two CELL attributes control storage server locking:

  • accessLevelPerm: This attribute specifies the access level at which the cell runs by default. It is either remoteLoginEnabled or remoteLoginDisabled.

    • remoteLoginEnabled: SSH service is enabled. You can access the cell using SSH or ExaCLI. This is the default value for accessLevelPerm.

    • remoteLoginDisabled: SSH service is disabled. You can access the cell only through ExaCLI.

  • accessLevelTemp: The access level can be changed temporarily for a specified duration. After the duration has expired, the access level reverts back to the accessLevelPerm value. You typically change the cell's access level when the cell needs a software update.

The access level persists across storage server reboots.

Parent topic: Keeping the Oracle Exadata Secure

4.3.1 Locking a Cell

You lock a cell by setting its accessLevelPerm attribute to remoteLoginDisabled.

You must use a user that has the privilege to alter the accessLevelPerm attribute.

  1. Grant the necessary privileges to a user.

    On the storage server, run these commands:

    cellcli> create role administrator
cellcli> grant privilege all actions on all objects all attributes with all options to role administrator
cellcli> create user celladministrator password=*
cellcli> grant role administrator to user celladministrator
  2. Run ExaCLI as the celladministrator user and run the ALTER CELL command:
    $ exacli -l celladministrator -c exam08cel01
Password=********

exacli> alter cell accessLevelPerm = remoteLoginDisabled

Parent topic: Disabling SSH on Storage Servers

4.3.2 Unlocking a Cell Temporarily

You can unlock a locked storage server, or cell, for a short period of time to perform operations such as maintenance or upgrades that require SSH log in to the storage server.

You can specify the start time of a temporary access window and how long it should last by using the ALTER CELL command to modify the cell's accessLevelTemp attribute.

Note the following:

  • Only one temporary access window is allowed at any time. You will get an error message if you try to create a new temporary access window when one is already in effect. If the temporary access window is not yet active and is in the future, the newly created temporary access window will replace the one that is in the future.
  • To modify a temporary access window that is in the future and not yet active, simply run the ALTER CELL command again with the new values.
  • To modify a temporary access window that is already in progress (for example, to extend the duration or to change the reason), run the ALTER CELL command again with the updated duration or reason. The command must provide the exact start time of the existing temporary access window to modify. The (start time + duration) must be in the future.

The accessLevelTemp attribute has the following properties:

  • accessLevel: (Mandatory) Specifies whether SSH is enabled (remoteLoginEnabled) or disabled (remoteLoginDisabled). You must provide a value for this attribute; there is no default value.

  • startTime: Specifies when the specified access level starts. The time is specified in the ISO 8601 format: "yyyy-MM-ddTHH:mm:ssZ". You can also specify the keyword now to indicate that the specified access level should start immediately. The default value for this attribute is now.

  • duration: Specifies how long the access level should last. The default value is 2h (2 hours). The duration is specified in the following format:

    • [any number of digits, followed by d (for days)]. To specify 1 day, use 1d.
    • [any number of digits followed by h (for hours)]. To specify 1 hour, use 1h.
    • [any number of digits followed by m (for minutes)]. To specify 90 minutes, use 90m.

    You can use combinations of duration values. For example, to specify 1 day and 12 hours, use 1d12h.

  • reason: Specifies a reason for changing the access level, for example: performing an upgrade. The default value is none.

Example 4-1 Creating a Temporary Access Window

The following example creates a two-hour temporary access window that starts immediately. The command uses the default values for start time and duration.

exacli> ALTER CELL accessLevelTemp=((accessLevel="remoteLoginEnabled", -
        reason="Quarterly maintenance"))

Example 4-2 Creating a Temporary Access Window in the Future

The following example creates a 30 minute temporary access window that will begin on June 20, 2023, at 1:01 AM.

exacli> ALTER CELL accessLevelTemp=((accessLevel="remoteLoginEnabled", -
        startTime="2023-06-20T01:01:00-07:00",                         -
        duration="30m",                                                -
        reason="Quarterly maintenance"))

Example 4-3 Extending a Temporary Access Window

The following example extends the temporary access window created in the previous example to 5 hours. Note that the start time has to match the window that is being adjusted.

exacli> ALTER CELL accessLevelTemp=((accessLevel="remoteLoginEnabled", -
        startTime="2023-06-20T01:01:00-07:00",                         -
        duration="5h",                                                 -
        reason="Quarterly maintenance window extended to 5 hrs - Joe"))

Example 4-4 Deleting a Temporary Access Window

The following example deletes the temporary access window. If the temporary access window is currently active, it is closed immediately and the access level will be set back to the permanent access level. If the temporary access window is in the future and not yet active, it is canceled.

exacli> ALTER CELL accessLevelTemp=''

Parent topic: Disabling SSH on Storage Servers

4.3.3 Unlocking a Cell Permanently

You can unlock a cell by setting its accessLevelPerm attribute to remoteLoginEnabled.

You must use a user that has the privilege to alter the accessLevelPerm attribute.

  1. Start ExaCLI as a user that has the privilege to alter the accessLevelPerm attribute.

    For example:

    $ exacli -l celladministrator -c exam08cel01
Password=********

exacli>
  2. Run the ALTER CELL command to set the accessLevelPerm attribute to remoteLoginEnabled.

    For example:

    exacli> alter cell accessLevelPerm=remoteLoginEnabled
Cell exam08cel01 successfully altered

Parent topic: Disabling SSH on Storage Servers

4.3.4 Checking the Current Access Level for a Cell

View the accessLevelPerm and accessLevelTemp attributes for a cell to determine the current access level.

  • To see what the current access level is, use the LIST CELL command.
    exacli> LIST CELL ATTRIBUTES name,accessLevelPerm,accessLevelTemp

Parent topic: Disabling SSH on Storage Servers

4.3.5 Access Level Alerts from the Management Server

A stateless alert is generated when the accessLevelPerm attribute is modified.

A stateful alert is generated when the accessLevelTemp window is created. An alert email is sent out when the accessLevelTemp window is activated. The alert is cleared when the window expires.

Parent topic: Disabling SSH on Storage Servers

4.4 Configuring Data Security for Exadata Storage Servers

Data security for Oracle Exadata Storage Servers is implemented by controlling which Oracle Automatic Storage Management (Oracle ASM) clusters and Oracle Database clients can access specific grid disks on storage cells.

By default, all Oracle Database and Oracle ASM instances have access to all grid disks on the storage servers. The storage for each database is provided by Oracle ASM. You can have multiple clustered or unclustered databases running in your Oracle Exadata Database Machine. You can also have more than one Oracle ASM cluster. An Oracle ASM cluster is a collection of interconnected nodes, each with an Oracle ASM instance, operating as a unified cluster. An Oracle ASM cluster presents a shared pool of storage to one or more Oracle Database instances that are also operating on the nodes.

Parent topic: Keeping the Oracle Exadata Secure

4.4.1 About Exadata Storage Server Security Modes

Oracle Exadata System Software security allows open security, ASM-scoped security, or DB-scoped security.

Open Security

The default security mode is open security, where any database client has access to all the grid disks. Open security mode is useful for test or development databases where there are no security requirements. This is the default security mode after creating a new storage cell.

ASM-Scoped Security

Using ASM-scoped security you can restrict access to only the grid disks used by the Oracle ASM disk groups associated with a Oracle ASM cluster. All Oracle Database instances associated with that Oracle ASM cluster have access to the disk groups and underlying grid disks. Grid disks used in disk groups belonging to a different Oracle ASM cluster are not be accessible to these instances.

Use ASM-scoped security when you want all databases and Oracle ASM instances in a cluster to have access to the grid disks that comprise the Oracle ASM disk groups used by the cluster. This includes the case when there is only one database in an Oracle ASM cluster.

Figure 4-1 ASM-Scoped Security

Description of Figure 4-1 follows
Description of "Figure 4-1 ASM-Scoped Security"

DB-Scoped Security

Using DB-scoped security, you can restrict access for an Oracle Database instance to a specific set of grid disks. The database instance must have access to all the grid disks used by the Oracle ASM disk groups for the database. The grid disks used by these Oracle ASM disk groups cannot be used by any other Oracle ASM disk group.

DB-scoped security mode is appropriate when multiple databases are accessing the grid disks. DB-scoped security allows you to limit database access to only the grid disks that are used by the Oracle ASM disk groups associated with the database.

Description of sagug_031-db-scoped-security.eps follows
Description of the illustration sagug_031-db-scoped-security.eps

Parent topic: Configuring Data Security for Exadata Storage Servers

4.4.2 Best Practices for ASM-Scoped Security and DB-Scoped Security

While setting up security, it is imperative that the configuration is the same across all the storage servers.

To have consistent Oracle Exadata System Software security, ensure the following:

  • Configure the same cell-side grid disk security for all grid disks that belong to the same Oracle ASM disk group to avoid confusion and errors.
  • Ensure that all Oracle Real Application Clusters (Oracle RAC) servers in an Oracle ASM cluster have the same content, ownership, and security for the Oracle ASM cellkey.ora file.
  • Ensure that all Oracle RAC servers in a database cluster have the same content, ownership, and security for the database cellkey.ora file.
  • If DB-scoped security is implemented, then ensure it is implemented for all databases accessing the grid disks. Do not mix ASM-scoped security and DB-scoped security for any grid disks.
  • Use the dcli utility to make configuration changes to ensure consistency and eliminate potential user errors.

Related Topics

Parent topic: Configuring Data Security for Exadata Storage Servers

4.4.3 About Security Keys

Oracle Exadata System Software uses keys to identify clients and determine access rights to the grid disks.

To determine which clients have access to a grid disk, a key is generated using CellCLI and stored in a read-only file that is accessible only by the clients. The CellCLI CREATE KEY command generates a random hexadecimal string for use as a security key. This key is stored in a cellkey.ora file on the client side, and assigned to the targets on the storage servers using the ASSIGN KEY command.

Note:

The client name or Oracle ASM cluster name not case-sensitive. For example, ASM1 and asm1 are treated as the same value.

The CREATE KEY command can be run on any cell. You should only run this command when you need to create a new unique key. If you are configuring ASM-scoped security, then only a single security key is needed for each Oracle ASM cluster. If you are configuring DB-scoped security, then one key is needed for each Oracle ASM cluster and an additional security key is needed for each database client.

For ASM-scoped security, the cellkey.ora file is only accessible by the Oracle ASM cluster and its database clients. For DB-scoped security multiple security keys are used. One key is assigned to the Oracle ASM cluster, and one key is assigned to each database client. These security keys are stored in separate cellkey.ora files, and each file is accessible only by the client.

The cellkey.ora file contains entries that configure security among Oracle ASM, database clients and cells. The key and asm values in the cellkey.ora files on the Oracle ASM and database host computers must match the values assigned to the clients on the cells.

The cellkey.ora file contains the following fields:

  • key — This field is required.

    • For ASM-scoped security, this key must match the value of the key assigned to the Oracle ASM cluster with the CellCLI ASSIGN KEY command.

    • For DB-scoped security, this key must match the value of the key assigned to the database client with the CellCLI ASSIGN KEY command.

  • asm — This field is required.

    This field contains a unique identifier for each Oracle ASM cluster. This value must be unique among all the clusters that access the storage servers in the storage grid. This value is used in the ASSIGN KEY command run on each cell, and the ALTER GRIDDISK and CREATE GRIDDISK commands used to configure grid disks to allow access from only a specific Oracle ASM cluster.

    Note:

    The asm field is used when configuring both ASM-scoped security and DB-scoped security.

Access to the cellkey.ora file is controlled by operating system privileges.

  • For Oracle ASM clients, the file is stored in the /etc/oracle/cell/network-config directory, and is readable by the Oracle Grid Infrastructure software owner and the group to which the user belongs.

  • For DB-scoped security, there is a cellkey.ora for Oracle ASM, readable only by the Oracle Grid Infrastructure software owner, and additional cellkey.ora files for each database client. For the database clients, the file is stored in the pfile directory of the Oracle home directory for each database. The cellkey.ora file for a database is readable only by the operating system user that owns the Oracle Database software installation.

    Note:

    The Oracle Grid Infrastructure and Oracle Database software must by owned by different operating system users to implement DB-scoped security.

Figure 4-2 Security Keys and cellkey.ora Files

Description of Figure 4-2 follows
Description of "Figure 4-2 Security Keys and cellkey.ora Files"

On the storage servers, you use the ASSIGN KEY command to store the security keys in an access control list (ACL) for the cells. You use the ALTER GRIDDISK command to set the access rights for individual grid disks with the AvailableTo attribute. In order to access a grid disk, the security key of the cell ACL must match the security key of the client and the unique name of the client must be included in the AvailableTo attribute of the grid disk.

The identifying names used for the Oracle ASM and database must be unique. However, in some environments, there is more than one database with the same value for the DB_UNIQUE_ID. Each database uses a different Oracle ASM cluster for storage. Starting with Oracle Exadata System Software release 12.2.1.1.0, you can define ASM-scoped security based on Oracle ASM clusters. You use the ASMCLUSTER keyword with the ASSIGN KEY command. When you use the ASMCLUSTER keyword, the database name is qualified by the Oracle ASM unique identifier, creating a unique ID for each database, even if they have the same DB_UNIQUE_ID. Within each Oracle ASM cluster, the database names still have to be unique.

If you configure ASM-scoped security or DB-scoped security, then you also need to configure security keys to enable cell-to-cell operations. You create a key for each storage server, or cell, and assign that key as a local key for the cell using the ASSIGN KEY FOR LOCAL CELL command. You then assign the keys for the other cells that perform cell-to-cell operations with the current cell using the ASSIGN KEY FOR REMOTE CELL command.

Example 4-5 Creating a Security Key for Exadata Storage Security

Use the following command on any storage server to generate a unique security key. This key will be used to configure ASM-scoped security or DB-scoped security. 

CellCLI> CREATE KEY
         66e12adb996805358bf82258587f5050

Example 4-6 cellkey.ora File Entries

This example shows the entries for the cellkey.ora file. 

key=66e12adb996805358bf82258587f5050
asm=cluster1

Related Topics

Parent topic: Configuring Data Security for Exadata Storage Servers

4.4.4 Setting Up ASM-Scoped Security on Oracle Exadata Storage Servers

Configuring ASM-scoped security requires actions to be performed on both the database servers and storage servers.

The steps here are for configuring ASM-scoped security for a single Oracle ASM cluster and the databases that are clients of that Oracle ASM cluster. The examples in these steps assume that the Oracle ASM software owner is the user grid.
  1. Shut down the Oracle Database and Oracle ASM instances.
  2. On one of the storage servers, use the CellCLI CREATE KEY command to generate a random hexadecimal string. The command can be run on any storage server.
    CellCLI> CREATE KEY

66e12adb996805358bf82258587f5050
  3. Copy the key to the cellkey.ora file on one of the database servers.
    1. Create a cellkey.ora in the home directory of the software owner, for example, /home/grid/cellkey.ora.
    2. Using the format shown below, where cluster1 is an alias for the Oracle ASM cluster, add the key to the cellkey.ora file.

      The alias must be unique among all the clusters that access the storage servers. The Oracle Clusterware cluster name can be used if the clusters have unique names. 

      key=66e12adb996805358bf82258587f5050
asm=cluster1
  4. Use the ASSIGN KEY command to assign the security key to the Oracle ASM cluster client on all the storage servers that you want the Oracle ASM cluster to access, for example:
    CellCLI> ASSIGN KEY FOR ASMCLUSTER 'cluster1'='66e12adb996805358bf82258587f5050'

    The above command must be repeated on all storage servers that you want the Oracle ASM cluster to access, or you can use a dcli command, as shown here: 

    dcli -g cell_group -l celladmin "cellcli -e \"ASSIGN KEY FOR ASMCLUSTER 'cluster1'=
'66e12adb996805358bf82258587f5050'\""
  5. Configure security on the grid disks on all the storage servers that you want the Oracle ASM cluster to access.
    You can configure the security key either when creating grid disks, or with the ALTER GRIDDISK command.

    • To create new grid disks with security configured, use a command similar to the following where cluster1 is the unique name for the Oracle ASM client: 

      CellCLI> CREATE GRIDDISK ALL PREFIX=sales, size=75G, -
         availableTo='cluster1'

    • To change security on existing grid disks, use a command similar to the following on every storage server. In the following example, cluster1 is the unique name for the Oracle ASM client. The grid disks specified in this command must include all the grid disks used by the Oracle ASM disk groups. 

      CellCLI> ALTER GRIDDISK sales_CD_01_cell01, sales_CD_02_cell01,           -
         sales_CD_03_cell01, sales_CD_04_cell01, sales_CD_05_cell01,      -
         sales_CD_06_cell01                                               -
         availableTo='cluster1'

    In the preceding commands, the alias used, for example, cluster1, is a unique and consistent value on all the storage servers and among all the clusters. When you specify a value for availableTo, then only the clients configured with the same alias in the cellkey.ora file have access to the grid disks. If there is no value for the availableTo attribute, then any client has access to those grid disks.

  6. Verify the key assignment on the storage servers.
    CellCLI> LIST KEY
    CellCLI> LIST GRIDDISK ATTRIBUTES name,availableTo
  7. Copy the cellkey.ora file created in Step 3 to the /etc/oracle/cell/network-config directory on each database server.

    In the following command, dbs_group is a file that contains the names of the database servers that are clients of the Oracle ASM cluster. 

    dcli -g dbs_group -l grid -f /home/grid/cellkey.ora -d /etc/oracle/cell/
network-config/cellkey.ora
  8. On each database server, configure the permissions for the cellkey.ora.

    • If you use role-separated management for all Oracle software, then set the permissions on the file to be read-only by the owner and the group. Change the group ownership for the file to the oinstall group that contains the installation users for both Oracle Grid Infrastructure (grid) and Oracle Database (oracle).

      You can use dcli to configure the file on multiple servers with a single command. 

      dcli -g dbs_group -l root chown grid:oinstall /etc/oracle/cell/
network-config/cellkey.ora 

dcli -g dbs_group -l grid chmod 440 /etc/oracle/cell/network-config/cellkey.ora

    • If you use a single installation user for all Oracle software, then set the permissions on the file to be read-only by the software owner (for example, oracle). 

      chown oracle:oinstall /etc/oracle/cell/network-config/cellkey.ora
chmod 400 /etc/oracle/cell/network-config/cellkey.ora
  9. On the database servers, restart Oracle Clusterware, the Oracle ASM instances, and the Oracle Database instances.

    The commands to stop and start Oracle Clusterware are: 

    # crsctl stop crs
# crsctl start crs

    Then restart the Oracle ASM and Oracle Database instances if they are not started automatically.

  10. Remove the temporary cellkey.ora file created in Step 3.

Related Topics

Parent topic: Configuring Data Security for Exadata Storage Servers

4.4.5 Setting Up DB-Scoped Security on Oracle Exadata Database Machine

When configuring DB-scoped security, you perform actions on both the database and storage servers.

These steps are for configuring DB-scoped security for a single Oracle ASM cluster and the databases that are clients of that Oracle ASM cluster. The examples in these steps assume that the Oracle ASM software owner is the user grid and each Oracle Database home is owned by a different operating system user.

To configure DB-scoped security, the following conditions must exist:
  • The combination of the Oracle Database client unique name and the Oracle ASM Cluster used by the database client must be unique in your environment.
  • The Oracle Grid Infrastructure software installation and each Oracle Database software installation must be owned by different operating system users.
  • Each database client must have distinct Oracle ASM disk groups. The grid disks used by Oracle ASM disk groups can only be assigned to one Oracle ASM disk group.
  1. Get the DB_UNIQUE_NAME for each database. Names are case-sensitive.
    SQL> SELECT db_unique_name FROM V$DATABASE;
  2. Shut down the databases and Oracle ASM instances for the Oracle ASM cluster.
  3. On one of the storage servers, use the CellCLI CREATE KEY command to generate a key for Oracle ASM and a key for each Oracle Database client.

    The command can be run on any storage server.

    CellCLI> CREATE KEY
        66e12adb996805358bf82258587f5050

CellCLI> CREATE KEY
        f3f21c625ff41ef479a1bb033e0839e5

CellCLI> CREATE KEY
        cf03b74de32a67a6c1ec87b9da72bd47
  4. Copy the key for Oracle ASM to the cellkey.ora file on one of the database servers.
    1. Create a cellkey.ora in the home directory of the Oracle Grid Infrastructure software owner, for example, /home/grid/cellkey.ora.
    2. Using the format shown below, where asm1 is an alias for the Oracle ASM cluster, add the key to the cellkey.ora file.

      The alias must be unique among all the clusters that access the storage servers. The Oracle Clusterware cluster name can be used if the clusters have unique names. 

      key=66e12adb996805358bf82258587f5050
asm=asm1
  5. Copy the key for each Oracle Database client to a cellkey.ora file in the user directory of the Oracle home software owner on one of the database servers.
    1. Create a cellkey.ora in the home directory of each Oracle Database software owner, for example, /home/db1user/cellkey.ora and /home/db2user/cellkey.ora.
    2. Add the security key for each database client to the cellkey.ora file.

      Using the format shown here, where asm1 is an alias for the Oracle ASM cluster used by the database client. In this example, each database client uses the same Oracle ASM cluster. 

      $ cat /home/db1user/cellkey.ora
key=f3f21c625ff41ef479a1bb033e0839e5
asm=asm1
$ cat /home/db2user/cellkey.ora
key=cf03b74de32a67a6c1ec87b9da72bd47
asm=asm1

    Note:

    The asm field is used for both ASM-scoped security and DB-scoped security.
  6. Use the ASSIGN KEY command to assign the security key for the Oracle ASM client on all the storage servers that you want the Oracle ASM cluster to access, for example:
    CellCLI> ASSIGN KEY FOR 'asm1'='66e12adb996805358bf82258587f5050'

    The above command must be repeated on all storage servers, or you can use a dcli command, as shown here: 

    dcli -g cell_group -l root "cellcli -e \"ASSIGN KEY FOR 'asm1'=
'66e12adb996805358bf82258587f5050'\""
  7. Use the ASSIGN KEY command to assign the security key for each Oracle Database client on all the storage servers that contain grid disks used by the Oracle ASM disk groups of that database, for example:
    CellCLI> ASSIGN KEY FOR 'db1'='f3f21c625ff41ef479a1bb033e0839e5'

CellCLI> ASSIGN KEY FOR 'db2'='cf03b74de32a67a6c1ec87b9da72bd47'

    The above command must be repeated on all storage servers, or you can use a dcli command, as shown here, where cell_group_db1 contains a list of the storage servers used by the first database and cell_group_db2 contains the list of storage servers used by the second database: 

    dcli -g cell_group_db1 -l root "cellcli -e \"ASSIGN KEY FOR 'db1'=
'f3f21c625ff41ef479a1bb033e0839e5'\""

dcli -g cell_group_db2 -l root "cellcli -e \"ASSIGN KEY FOR 'db2'=
'cf03b74de32a67a6c1ec87b9da72bd47'\""
  8. Configure security on the grid disks on all the storage servers that you want the database clients to access.
    You can configure the security key either when creating grid disks, or with the ALTER GRIDDISK command.

    • To create new grid disks with security configured, use a command similar to the following where asm1 is the unique name for the Oracle ASM client, and db1 and db2 are the unique names for the database clients: 

      CellCLI> CREATE GRIDDISK data1_CD_00_cell01,data1_CD_01_cell01, -
data1_CD_02_cell01 size=75G, availableTo='asm1,db1'

CellCLI> CREATE GRIDDISK reco1_CD_00_cell01,reco1_CD_01_cell01, -
reco1_CD_02_cell01 size=75G, availableTo='asm1,db1'

CellCLI> CREATE GRIDDISK data2_CD_00_cell01,data2_CD_01_cell01, -
data2_CD_02_cell01 size=75G, availableTo='asm1,db2'

CellCLI> CREATE GRIDDISK reco2_CD_00_cell01,reco2_CD_01_cell01, -
reco2_CD_02_cell01 size=75G, availableTo='asm1,db2'

    • To change security on existing grid disks, use a command similar to the following on every storage server. In the following example, asm1 is the unique name for the Oracle ASM client, and db1 and db2 are the unique names for the database clients. The grid disks specified in this command must include all the grid disks used by the Oracle ASM disk groups for each database client. 

      CellCLI> ALTER GRIDDISK data1_CD_00_cell01, data1_CD_01_cell01, -
data1_CD_02_cell01, reco1_CD_00_cell01, reco1_CD_01_cell01, reco1_CD_02_cell01, -
availableTo='asm1,db1'

CellCLI> ALTER GRIDDISK data2_CD_00_cell01, data2_CD_01_cell02, -
data2_CD_02_cell01, reco2_CD_00_cell01, reco2_CD_01_cell01, reco2_CD_02_cell01, -
availableTo='asm1,db2'

    When you specify a value for availableTo, then only the clients configured with the same key assigned to that alias in their cellkey.ora file have access to the grid disks. If there is no value for the availableTo attribute, then any client has access to those grid disks.

  9. Verify the key assignment on the storage servers.
    CellCLI> LIST KEY
        asm1    66e12adb996805358bf82258587f5050
        db1     f3f21c625ff41ef479a1bb033e0839e5
        db2     cf03b74de32a67a6c1ec87b9da72bd47
    CellCLI> LIST GRIDDISK ATTRIBUTES name,availableTo WHERE availableTo=!''
         DATA1_CD_00_cell01     asm1,db1
         DATA1_CD_01_cell01     asm1,db1
         DATA1_CD_02_cell01     asm1,db1
         DATA2_CD_00_cell01     asm1,db2
         DATA2_CD_01_cell01     asm1,db2
         DATA2_CD_02_cell01     asm1,db2
...
  10. Copy the cellkey.ora file created in step 4 to the /etc/oracle/cell/network-config directory on each database server.

    In the following command, dbs_group is a file that contains the names of the database servers that are clients of the Oracle ASM cluster. 

    dcli -g dbs_group -l grid -f /home/grid/cellkey.ora -d /etc/oracle/cell/
network-config/cellkey.ora
  11. On each database server, set the permissions for the cellkey.ora file for Oracle ASM to be read-only by the file owner and the group.

    You can use dcli to configure the file permissions multiple servers with a single command. In the following example, dbs_group is a file that contains a list of all the database servers that are clients of the Oracle ASM cluster. 

    dcli -g dbs_group -l grid chmod 640 /etc/oracle/cell/network-config/
cellkey.ora
  12. Copy each cellkey.ora file created in step 5 to its $ORACLE_HOME/admin/db_unique_name/pfile directory on each database server.

    In the following command, db1_group is a file that contains the names of the database servers that host the database instances for the db1 database, and dbuser1 is the operating system user that owns the $ORACLE_HOME/admin/db1 directory. 

    dcli -g db1_group -l dbuser1 -f /home/dbuser1/cellkey.ora 
-d $ORACLE_HOME/admin/db1/pfile/cellkey.ora

    In this example, db2_group is a file that contains the names of the database servers that host the database instances for the database with the unique database name of db2, and dbuser2 is the operating system user that owns the $ORACLE_HOME/admin/db2 directory. 

    dcli -g db2_group -l dbuser2 -f /home/dbuser2/cellkey.ora 
-d $ORACLE_HOME/admin/db2/pfile/cellkey.ora
  13. On each database server, set the permissions the permissions for the cellkey.ora file in each Oracle database home to be accessible by only the file owner.

    You can use dcli to configure the file permissions multiple servers with a single command. In the following example, db1_group is a file that contains the names of the database servers that host the database instances for the database with the unique database name of db1, and dbuser1 is the operating system user that owns the $ORACLE_HOME/admin/db1 directory. 

    dcli -g db1_group -l dbuser1 chmod 600 $ORACLE_HOME/admin/
db1/pfile/cellkey.ora

    In this example, db2_group is a file that contains the names of the database servers that host the database instances for the database with the unique database name of db2, and dbuser2 is the operating system user that owns the $ORACLE_HOME/admin/db2 directory. 

    dcli -g db2_group -l dbuser2 chmod 600 $ORACLE_HOME/admin/db2/pfile/
cellkey.ora
  14. On the database servers, restart Oracle Clusterware, the Oracle ASM instances, and the Oracle Database instances.

    The commands to stop and start Oracle Clusterware are: 

    # crsctl stop crs
# crsctl start crs

    Then restart the Oracle ASM and Oracle Database instances if they are not started automatically by Oracle Clusterware.

  15. Remove the temporary cellkey.ora files created in step 4 and step 5.

Related Topics

Parent topic: Configuring Data Security for Exadata Storage Servers

4.4.6 Changing Security Keys for ASM-Scoped Security or DB-Scoped Security

You can change the keys used with ASM-scoped security or DB-scoped security.

Parent topic: Configuring Data Security for Exadata Storage Servers

4.4.6.1 Upgrading ASM-Scoped Security Key for ASMCLUSTER

Starting with Oracle Exadata System Software release 12.2.1.1.0, you can define ASM-scoped security based on Oracle ASM clusters.

The identifying names used for the Oracle ASM and database instances must be unique. However, in some environments, there is more than one database with the same value for the DB_UNIQUE_ID. If each database uses a different Oracle ASM cluster for storage, then you can use the ASMCLUSTER keyword when assigning the security key to specify that access should be limited to the specified Oracle ASM cluster.

When you use the ASMCLUSTER keyword, the database name is qualified by the Oracle ASM unique identifier, creating a unique ID for each database, even if they have the same DB_UNIQUE_ID. Within each Oracle ASM cluster, the database names still have to be unique.

Note:

Do not use the ASMCLUSTER keyword when assigning keys if you are using DB-scoped security. Only use the ASMCLUSTER keyword for ASM-scoped security.

If you have ASM-scoped security configured, but want to change the keys to be ASMCLUSTER keys, perform the following steps:

  1. Obtain the key value that you want to upgrade to an ASMCLUSTER key.
    $ dcli -c dm01cel01,dm01cel02,dm01cel03 cellcli -e list key
dm01cel01:      asm1   118af47c57ab8da650ab67d5587fe728
dm01cel02:      asm1   118af47c57ab8da650ab67d5587fe728
dm01cel03:      asm1   118af47c57ab8da650ab67d5587fe728
  2. Re-issue the ASSIGN KEY command using the same key value but adding the ASMCLUSTER keyword.
    $ dcli -c dm01cel01,dm01cel02,dm01cel03 "cellcli -e assign key for ASMCLUSTER
 \'asm1\'=\'118af47c57ab8da650ab67d5587fe728\'"

    The name and key are removed from the ASM-scoped security list, and added as an Oracle ASM cluster client. Grid disks with this Oracle ASM client in their ACL can remain online for this operation.

  3. Verify the keys have been upgraded to ASMCLUSTER keys.
    $ dcli -c dm01cel01,dm01cel02,dm01cel03 cellcli -e list key
dm01cel01:      asm1   118af47c57ab8da650ab67d5587fe728      ASMCLUSTER
dm01cel02:      asm1   118af47c57ab8da650ab67d5587fe728      ASMCLUSTER
dm01cel03:      asm1   118af47c57ab8da650ab67d5587fe728      ASMCLUSTER
4.4.6.2 Changing the Assigned Key Value for ASM-Scoped Security

You can change the key value used for an Oracle ASM client configured to use ASM-scoped security.

  1. Shut down the Oracle Database and Oracle ASM instances for which you are changing the security configuration.
  2. Use the CellCLI CREATE KEY command to generate a random hexadecimal string. The command can be run on any cell.
    CellCLI> CREATE KEY

          f3d15c0c5e854345bcb3c2b678b1de45
  3. Update the cellkey.ora file.
    1. On one of the database servers, copy the /etc/oracle/cell/network-config/cellkey.ora file to the grid owner home directory, for example, /home/grid/cellkey.ora,
    2. Update the file to use the new key for the Oracle ASM client.
      key=f3d15c0c5e854345bcb3c2b678b1de45
asm=asm1
  4. Copy the cellkey.ora file to /etc/oracle/cell/network-config on each database server, overwriting the existing file.

    In the following command, dbs_group is a file that contains the names of the database servers that are clients of the Oracle ASM cluster, and grid is the software owner for the Oracle ASM installation. 

    dcli -g dbs_group -l grid -f /home/grid/cellkey.ora -d /etc/oracle/cell/
network-config/cellkey.ora
  5. Make sure the permissions for the cellkey.ora in /etc/oracle/cell/network-config are configured so that only the Oracle Grid Infrastructure software owner has access to the file.

    Make sure the owner of the file is the Oracle Grid Infrastructure software owner. If the current file permissions are not rw------- (600), then modify the permissions, as shown in the following command: 

    dcli -g dbs_group -l grid chmod 600 /etc/oracle/cell/network-config/cellkey.ora
  6. Use the ASSIGN KEY command to update the security key assigned to the Oracle ASM cluster client on all the cells that contains grid disks used by the Oracle ASM cluster.

    Use the same identifier and key value for the Oracle ASM client that is used in the cellkey.ora file on the database servers. 

    dcli -g cell_group -l root "cellcli -e \"ASSIGN KEY FOR 'asm1'='f3d15c0c5e8543
45bcb3c2b678b1de45'

    Starting with Oracle Exadata System Software release 12.2.1.1.0, add the ASMCLUSTER keyword to the ASSIGN KEY command if the security is based only on Oracle ASM clusters. Specify the Oracle ASM cluster name for the unique name for the key. For example: 

    CellCLI> ASSIGN KEY FOR ASMCLUSTER '+asm1' -
         ='f3d15c0c5e854345bcb3c2b678b1de45

    Note:

    If you are using DB-scoped security, do not add the ASMCLUSTER keyword to the ASSIGN KEY command.
  7. On the database servers, restart Oracle Clusterware, the Oracle ASM instances, and the Oracle Database instances.

    The commands to stop and start Oracle Clusterware are: 

    # crsctl stop crs
# crsctl start crs

    Then restart the Oracle ASM and Oracle Database instances if they are not started automatically by Oracle Clusterware.

  8. Remove the temporary cellkey.ora files created in step 3.
4.4.6.3 Changing the Assigned Key Value for DB-Scoped Security

You can change the key value used by an Oracle Database client configured to use DB-scoped security.

  1. Shut down the Oracle Database instances for which you are changing the security configuration.
  2. Use the CellCLI CREATE KEY command to generate a random hexadecimal string.
    This command can be run on any cell.
    CellCLI> CREATE KEY

          fa292e11b31b210c4b7a24c5f1bb4d32
  3. Update the cellkey.ora file for the database client.
    1. On one of the database servers, copy the $ORACLE_HOME/admin/db_unique_name/pfile/cellkey.ora file to the user directory for the Oracle software owner, for example, /home/oradba1/cellkey.ora.
    2. Update the file to use the new key for the database client.
      key=fa292e11b31b210c4b7a24c5f1bb4d32
asm=asm1
  4. Copy the cellkey.ora file to $ORACLE_HOME/admin/db_unique_name/pfile on each database server, overwriting the existing file.

    In the following command, dba1_group is a file that contains the names of the database servers that host instances of the database client, and oradba1 is the software owner for the Oracle Database installation. 

    dcli -g dba1_group -l oradba1 -f /home/oradba1/cellkey.ora -d $ORACLE_HOME/admin/
db_unique_name/pfile/cellkey.ora
  5. Make sure the permissions for the cellkey.ora in $ORACLE_HOME/admin/db_unique_name/pfile are configured so that only the Oracle Database software owner has access to the file.

    Make sure the owner of the file is the Oracle Database software owner. If the current file permissions are not rw------- (600), then modify the permissions, as shown in the following command: 

    dcli -g dba1_group -l oradba1 chmod 600 $ORACLE_HOME/admin/db_unique_name/
pfile/cellkey.ora
  6. Use the ASSIGN KEY command to update the security key assigned to the Oracle Database client on all the cells that contains grid disks used by the database.

    Use the DB_UNIQUE_NAME for the database and the new key value for the database client. 

    dcli -g cell_group -l celladmin "cellcli -e \"ASSIGN KEY FOR 'db_unique_name'=
'fa292e11b31b210c4b7a24c5f1bb4d32'
  7. On the database servers, restart the Oracle Database instances.
  8. Remove the temporary cellkey.ora file created in step 3.

4.4.7 Enabling Cell-to-Cell Operations

If you have configured ASM-scoped security or DB-scoped security for your Oracle Exadata Database Machine, then you must configure access control to ensure direct cell-to-cell operations are not restricted.

To ensure cells have access to other cells when they need to communicate directly with one another, for example for offload operations, you need to set up cell keys for each cell.

Parent topic: Configuring Data Security for Exadata Storage Servers

4.4.7.1 Configuring Simple Cell Access

You can use a single key for both inbound and outbound cell-to-cell traffic.

To ensure cells have access to other cells when they need to communicate directly with one another, for offload operations for example, you can create a single key. Assign that key to all cells using the simple version of the ASSIGN KEY command.

It is not necessary to use the ALTER GRIDDISK command to update the availableTo attribute for the cell key. The cells use the existing access control policy by making sure the originating client is identified at the remote target cell.

Perform these steps only if you have already configured ASM-Scoped Security or DB-Scoped Security.
  1. Generate a random hexadecimal string.
    This command can be run on any cell.
    CellCLI> CREATE KEY
      fa292e11b31b210c4b7a24c5f1bb4d32
  2. Assign the key to each cell.
    CellCLI> ASSIGN KEY FOR CELL 'fa292e11b31b210c4b7a24c5f1bb4d32'

    To update all cells with a single command, use dcli. 

    dcli -g mycells -l celladmin "cellcli -e assign key for cell \'fa292e11b31b210c4b7a24c5f1bb4d32\'"
4.4.7.2 Configuring LOCAL and REMOTE Cell Keys

You can configure each cell to have a unique key and to accept multiple remote cell keys for granting access.

To ensure cells have access to other cells when they need to communicate directly with one another, for offload operations for example, you create cell keys. You can create a single key used by all cells, or you can assign a unique key to individual cells using the LOCAL and REMOTE keywords.

You might want to use multiple cell keys temporarily during rekeying, or if you want to limit access to specific cells. In this case, you need to specify LOCAL or REMOTE in the ASSIGN KEY command.

Perform these steps only if you have already configured ASM-Scoped Security or DB-Scoped Security.
  1. Generate a random hexadecimal string for each cell.
    These commands can be run on any cell.
    Cellcli> CREATE KEY
      fa292e11b31b210c4b7a24c5f1bb4d3

Cellcli> CREATE KEY
      b67d5587fe728118af47c57ab8da650a

Cellcli> CREATE KEY
      118af47c57ab8da650ab67d5587fe728
  2. On each cell, set the key for the local cell.
    Specify a unique identifier for each cell, for example, cell01, cell02, and so on.
    
[celladmin@dm01cel01 ~]$ cellcli -e assign key for local cell -
'cell01'='fa292e11b31b210c4b7a24c5f1bb4d3'
[celladmin@dm01cel02 ~]$ cellcli -e assign key for local cell -
'cell02'='b67d5587fe728118af47c57ab8da650a'
[celladmin@dm01cel03 ~]$ cellcli -e assign key for local cell -
'cell03'='118af47c57ab8da650ab67d5587fe728'
  3. Set the cell keys that the local cell will accept.
    For each cell that you want to grant access to the local cell, use the ASSIGN KEY FOR REMOTE CELL command and specify the local key of that cell. You can specify any name for the remote keys.
    [celladmin@dm01cel01 ~]$ cellcli -e assign key for remote cell -
'rcell02'='b67d5587fe728118af47c57ab8da650a', -
'rcell03'='118af47c57ab8da650ab67d5587fe728'

[celladmin@dm01cel02 ~]$ cellcli -e assign key for remote cell -
'rcell01'='fa292e11b31b210c4b7a24c5f1bb4d3', -
'rcell03'='118af47c57ab8da650ab67d5587fe728'


[celladmin@dm01cel03 ~]$ cellcli -e assign key for remote cell -
'rcell01'='fa292e11b31b210c4b7a24c5f1bb4d3', -
'rcell02'='b67d5587fe728118af47c57ab8da650a'
  4. Verify that the keys are set on each storage server.
    CellCLI> LIST KEY
       db1        c25a62472a160e28bf15a29c162f1d74
       asm1       118af47c57ab8da650ab67d5587fe728      ASMCLUSTER
       cell01     fa292e11b31b210c4b7a24c5f1bb4d32      LOCAL-CELL
       rcell02    b67d5587fe728118af47c57ab8da650a      REMOTE-CELL
       rcell03    118af47c57ab8da650ab67d5587fe728      REMOTE-CELL
4.4.7.3 Changing Between Simple Cell Keys and LOCAL and REMOTE Keys

You must remove the existing cell keys before assigning any new keys with a different format. This protects you from inadvertently breaking your configuration by having different remote and local keys on the storage servers.

If you attempt to assign a LOCAL or REMOTE key to an existing cell key (that is, you have run the simple ASSIGN KEY FOR CELL command, and you want to switch to the explicit LOCAL or REMOTE keys), you will get the following error: 

CELL-02911: Remove existing CELL key before assigning LOCAL CELL key

Similarly, if you attempt run ASSIGN KEY FOR CELL when local or remote cell keys already exist, you will get the following error: 

CELL-02912: Remove all existing LOCAL and REMOTE CELL keys before assigning a CELL key.
 Use LIST KEY FOR CELL to show all LOCAL and REMOTE CELL keys, then use ASSIGN KEY to assign an 
empty value to each.

You must remove all existing LOCAL and REMOTE cell keys before assigning a simple cell key.

  1. View the configured keys on each storage server.
    1. For simple cell keys, you would see results similar to the following:
      CellCLI> LIST KEY
       db1        c25a62472a160e28bf15a29c162f1d74
       asm1       b4095e91d67bbf68d2e2fbe1fc50530f      ASMCLUSTER
       cellkey    fa292e11b31b210c4b7a24c5f1bb4d32      CELL
    2. For local and remote cell keys, you would see results similar to the following:
      CellCLI> LIST KEY
       db1        c25a62472a160e28bf15a29c162f1d74
       asm1       b4095e91d67bbf68d2e2fbe1fc50530f      ASMCLUSTER
       cell01     fa292e11b31b210c4b7a24c5f1bb4d32      LOCAL-CELL
       rcell02    b67d5587fe728118af47c57ab8da650a      REMOTE-CELL
       rcell03    118af47c57ab8da650ab67d5587fe728      REMOTE-CELL
  2. Remove the existing cell keys.
    1. For simple cell keys, use a command similar to the following:
      dcli -g mycells -l celladmin "cellcli -e assign key for cell 'cell01'=''"
    2. For local and remote cell keys:
      Remove the local key on each cell.
      [celladmin@dm01cel01 ~]$ cellcli -e assign key for local cell 'cell01'=''
[celladmin@dm01cel02 ~]$ cellcli -e assign key for local cell 'cell02'=''
[celladmin@dm01cel03 ~]$ cellcli -e assign key for local cell 'cell03'=''
      Run the following commands from any server to remove the remote keys on each cell:
      dcli -g mycells -l celladmin "cellcli -e assign key for remote cell 'rcell01'=''" 
dcli -g mycells -l celladmin "cellcli -e assign key for remote cell 'rcell02'=''"
dcli -g mycells -l celladmin "cellcli -e assign key for remote cell 'rcell03'=''"
  3. Recreate the keys in the desired format.
    1. To change simple cell keys to local and remote keys, follow the steps in Configuring LOCAL and REMOTE Cell Keys
    2. To change local and remote cell keys to a simple cell key, follow the steps in Configuring Simple Cell Access.

4.4.8 Removing ASM-Scoped Security or DB-Scoped Security

If you want to revert to an open security model, you must remove DB-scoped security for grid disks before removing ASM-scoped security.

Before making updates to the security on cells, you must shut down the Oracle Database and Oracle ASM instances. After all of the changes to security configuration are complete, start the Oracle Database and Oracle ASM instances.

Parent topic: Configuring Data Security for Exadata Storage Servers

4.4.8.1 Removing DB-Scoped Security

To remove DB-scoped security on grid disks, perform the following procedure:

  1. Shut down the Oracle Database and Oracle ASM instances.
  2. Remove any database clients named in the availableTo attribute of the grid disks for which you want to remove DB-scoped security. Example 4-7 provides examples of how to do this.

    Note:

    If you removing DB-scoped security for a database client for only some of the grid disks, but not all, do not complete any further steps.
  3. If a database client is not configured for security with any other grid disks, then you can remove the key assigned to the database client on the storage servers. Use the CellCLI ASSIGN KEY command.

    In the following command, db_client is the name of the database client. To the right of the equal sign are two single quote characters with no space between them. 

    CellCLI> ASSIGN KEY FOR 'db_client'=''

    Repeat this step on each storage server (cell) for which the database client no longer needs DB-scoped security.

  4. On each database server, remove the cellkey.ora file located in the $ORACLE_HOME/admin/db_unique_name/pfile/ directory for the database client.
  5. Verify the key assignment has been updated on the storage servers.
    CellCLI> LIST KEY
        asm1    66e12adb996805358bf82258587f5050
        db2     cf03b74de32a67a6c1ec87b9da72bd47
    CellCLI> LIST GRIDDISK ATTRIBUTES name,availableTo WHERE availableTo=!''
         DATA1_CD_00_cell01     asm1
         DATA1_CD_01_cell01     asm1
         DATA1_CD_02_cell01     asm1
         DATA2_CD_00_cell01     asm1,db2
         DATA2_CD_01_cell01     asm1,db2
         DATA2_CD_02_cell01     asm1,db2
...
  6. Restart the Oracle Database and Oracle ASM instances.

Example 4-7 Removing Database Clients from Grid Disks

The following command removes all database clients from a group of grid disks:

CellCLI> ALTER GRIDDISK DATA1_CD_00_cell01, DATA1_CD_01_cell01,                  -
         DATA1_CD_02_cell01, RECO1_CD_00_cell01, RECO1_CD_01_cell01,             -
         RECO1_CD_02_cell01                                                      -
         availableTo='asm1'

If there are multiple database clients configured for DB-scoped security, for example db1, db2, and db3, and you only want to remove security for one client (db1), you can use a command similar to the following for a group of grid disks: 

CellCLI> ALTER GRIDDISK sales_CD_04_cell01, sales_CD_05_cell01,                  -
         sales_CD_06_cell01, sales_CD_07_cell01, sales_CD_08_cell01,             -
         sales_CD_09_cell01,                                                     -
         availableTo='+asm,db2,db3'

The following example removes all database clients from all grid disks:

ALTER GRIDDISK ALL availableTo='+asm'

Note:

If you want open security for the grid disks and storage servers, then you must remove ASM-scoped security after removing DB-scoped security.
4.4.8.2 Removing ASM-Scoped Security

After you have removed DB-scoped security, you can remove ASM-scoped security if you want open security for the grid disks on the storage servers.

  1. Shut down the Oracle Database and Oracle ASM instances.
  2. Use the LIST KEY command to view the unique alias used for the Oracle ASM client.
    Run this command on any storage server where ASM-scoped security is configured for the Oracle ASM client.
    CellCLI> LIST KEY
        asm1    66e12adb996805358bf82258587f5050
        db2     cf03b74de32a67a6c1ec87b9da72bd47
  3. Remove the Oracle ASM client named in the availableTo attribute of the grid disks for which you want to remove ASM-scoped security.

    Use the alias from step 2. Example 4-8 provides examples of how to do this.

  4. If the Oracle ASM client is not configured for security with any other grid disks, then you can remove the key assigned to the Oracle ASM client on the storage servers. Use the CellCLI ASSIGN KEY command.
    1. Determine if the Oracle ASM client in step 2 shows the ASMCLUSTER designation to the right of the key value.
    2. Use the ASMCLUSTER keyword in the ASSIGN KEY command only if the Oracle ASM client is listed as an ASMCLUSTER.

    In the following command, asm_cluster is the alias from step 2. To the right of the equal sign are two single quote characters with no space between them. 

    CellCLI> ASSIGN KEY FOR [ASMCLUSTER] 'asm_cluster'=''

    Run this command on all storage servers on which the key was assigned to the Oracle ASM client. You can alternatively use a command similar to the following: 

    dcli -g cell_group -l celladmin "cellcli -e \"ASSIGN KEY FOR [asmcluster] 
'asm_cluster'=''\""
  5. Update or delete the cellkey.ora file.

    View the cellkey.ora file located in the /etc/oracle/cell/network-config/ directory on each database server.

    If the Oracle ASM client for which you are removing ASM-scoped security is the only client listed in the file, then remove the cellkey.ora file on all servers with the same file contents.

    If there is more than one Oracle ASM client listed in the cellkey.ora file, then perform the following steps:

    1. Remove the entry for the Oracle ASM client for which you are removing ASM-scoped security.
    2. For all servers that list the Oracle ASM client in the cellkey.ora file, copy this file to those servers, or update the file on those servers.
  6. Verify the key assignment has been updated on the storage servers.
    CellCLI> LIST KEY
    CellCLI> LIST GRIDDISK ATTRIBUTES name,availableTo WHERE availableTo=!''
  7. Restart the Oracle Database and Oracle ASM instances.

Example 4-8 Removing the Oracle ASM Client from Grid Disks

The following command removes the Oracle ASM client from all grid disks on a cell: 

CellCLI> ALTER GRIDDISK ALL availableTo=''

The following command removes the Oracle ASM client from all grid disks on a group of cells: 

dcli -g cell_group -l celladmin "cellcli -e \"ALTER GRIDDISK ALL availableTo=''\""

The following command removes the Oracle ASM client from a group of grid disks on a cell: 

CellCLI> ALTER GRIDDISK sales_CD_01_cell01, sales_CD_02_cell01,       -
         sales_CD_03_cell01, sales_CD_04_cell01, sales_CD_05_cell01,  -
         sales_CD_06_cell01                                          
         availableTo=''

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.

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

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.

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

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.

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