This section outlines the planning process for a secure installation and describes several recommended deployment topologies for the systems.
To better understand your security needs, ask yourself the following questions:
Many resources in the production environment can be protected. Consider the resources you want to protect when deciding the level of security you must provide.
The primary resource to be protected is typically your data. Other resources are outlined here because they are associated with managing and protecting your data.Various concerns with protecting data include data loss (that is, data being unavailable) and data being compromised or disclosed to unauthorized parties.
Cryptographic keys are often used to protect data from unauthorized disclosure. Thus, they are another resource to be protected. Highly reliable key management is essential to maintaining highly available data.Another layer of resources to be protected includes the assets within the Oracle Key Manager Cluster itself, including the Key Management Appliances.
These resources must be protected from everyone who does not have authority to access them. These resources should be physically protected. You should consider which of your employees should have access to these resources. Then identify which types of operations each employee should be able to issue in the Oracle Key Manager environment?
In some cases, a fault in your security scheme is easily detected and considered nothing more than an inconvenience. In other cases, a fault might cause great damage to companies or individual clients that use your resources. Understanding the security ramifications of each resource will help you protect it properly.
The following figure shows a typical deployment of an Oracle Key Manager solution.
Figure 2-1 Typical Deployment of OKM Solution
This section describes how to install and configure an OKM Key Management Appliance securely.
KMAs are manufactured as hardened appliances with Oracle Key Manager functionality already available on them.
Installing and configuring KMAs in an OKM Cluster include the following steps:
For each KMA, install it in a rack.
For each KMA, secure its BIOS and its ILOM.
Configure the first KMA in the OKM Cluster.
Add additional KMAs to the OKM Cluster.
More information about planning the deployment of an OKM Cluster appears in the Oracle Key Manager Systems Assurance Guide included in the Oracle Key Manager documentation libraries located at:
http://www.oracle.com/technetwork/documentation/tape-storage-curr-187744.html#crypto
An Oracle Customer Service Engineer installs a KMA in a rack according to procedures outlined in the Oracle Key Manager Installation and Service Manual. Oracle service personnel may refer to this manual for more detailed information.
Oracle Key Manager KMAs are manufactured with recent Embedded Lights Out Manager (ELOM) or Integrated Lights Out Manager (ILOM) and BIOS firmware. The BIOS of a KMA should be secured by either an Oracle Customer Service Engineer or by the customer. The BIOS should also be secured after the ELOM or ILOM firmware is upgraded.
Securing the BIOS consists of setting particular BIOS settings in order to prevent changes to the BIOS that may compromise security.
The following procedure shows an example of accessing the BIOS Setup Utility through the ILOM of a KMA for a Sun Fire X4170 M2 server. Access the BIOS Setup Utility through the ELOM of a KMA for a Sun Fire X2100 or X2200 M2 server. The BIOS settings of relevance in this procedure are the same on all of these server types.
Note: Netra SPARC T4-1 servers do not have a BIOS; there are no BIOS procedures for users to follow for this server. |
Log into the ILOM web-based interface. Follow (or navigate) to:
Remote Control > Redirection
and click Launch Redirection to launch the Remote Console.
Follow (or navigate) to
Remote Control > Remote Power Control
In the Remote Console, monitor normal boot messages. When the American Megatrends screen appears, press the F2 key to launch the BIOS Setup Utility.
See "ILOM Security Hardening" information in the OKM 3.0 Administration Guide if you want to harden the ILOM.
In the BIOS Setup Utility, do the following steps:
Go to the Security tab, navigate to the Change Supervisor Password field, press the Enter Key, and specify a password. Retain this password.
After specifying the supervisor password, the User Access Level field should appear. Navigate to the User Access Level field and change the setting from ”Full Access” to ”Limited.”
Go to the Boot tab. Navigate to Boot Device Priority and make the following changes:
Tab | Field Name | Value |
---|---|---|
Boot | 1st Boot Device
(under Boot Device Priority) |
HDD:P0-SEAGATE
ST95000NSSUN500G 101 |
Boot | 2nd Boot Device
(under Boot Device Priority) |
Disabled |
Boot | 3rd Boot Device
(under Boot Device Priority) |
Disabled |
Press the F10 key to save these changes and select OK to confirm.
Let the system boot up. Now that you have defined a supervisor password in the BIOS, the system will prompt for this password when someone accesses the BIOS Setup Utility.
For more information about navigating around the BIOS Setup Utility, refer to the ”Configuring BIOS Settings” section of the Sun Fire X4170, X4270, and X4275 Servers Service Manual at:
http://download.oracle.com/docs/cd/E19477-01/820-5830-13/index.html
Oracle Key Manager KMAs are manufactured with recent ILOM and BIOS firmware. The ILOM of a KMA should be secured by either an Oracle Customer Service Engineer or by the customer. The ILOM should also be secured after the ILOM firmware is upgraded.
Securing the ILOM consists of setting particular ILOM settings in order to prevent changes to the ILOM that may compromise security.
The following procedure includes accessing the Integrated Lights Out Manager (ILOM) of a KMA that is a Sun Fire X4170 M2 server.
Open a web browser. Log into the ILOM using its web-based interface. Refer to the Oracle Integrated Lights Out Manager (ILOM) 3.0 Daily Management – Web Procedures Guide at below link for more information about using the ILOM web interface: http://docs.oracle.com/cd/E19860-01/E21446/E21446.pdf
Newly manufactured KMAs have a default password for the ”root” user. This password should be changed and retained.
Navigate to Configuration > System Management Access > SNMP. For ”Settings”, the use of SNMPv3 is recommended (v1 and v2c can be disabled). Disable ”Set Requests” to prevent configuration changes from being made through SNMP.
Navigate to Configuration > System Management Access > IPMI. If the Auto Service Request (ASR) feature was introduced in OKM 2.4, then enable IPMI. Otherwise, disable IPMI if there are no plans to use it. Leaving this interface open exposes this KMA to reboot.
Navigate to Configuration > System Management Access > CLI. Configure the session timeout as the default setting allows CLI sessions to remain open indefinitely.
Navigate to Configuration > System Management Access > WS-Man. Disable this service if there are no plans to use WS-Management and CIM. Leaving this interface open exposes the KMA to attackers knowledgeable of the WS-Management protocol.
Navigate to Configuration > Clock. The ILOM clock is not synchronized with the host clock on a Sun Fire X4170 M2 server. So that ILOM event can be correlated with server events, the ILOM date and time should be set manually to UTC/GMT time or configured to synchronize with an external NTP server, preferably the same NTP server that is used by the KMAs in this OKM Cluster. See the Oracle Key Manager Administration Guide which is included in Oracle Key Manager documentation libraries at:
http://www.oracle.com/technetwork/documentation/tape-storage-curr-187744.html#crypto
Navigate to Configuration > Timezone. The ILOM timezone should be set to ”GMT.”
Navigate to User Management > User Accounts. Use of user accounts and roles is recommended over using just the default root account. See the ”User Account Management” section of the Oracle Integrated Lights Out Manager (ILOM) 3.0 Daily Management - Concepts Guide at:
Navigate to Remote Control > Host Control. The ”Next Boot Device” value should be set to ”Default (User BIOS Settings).”
Navigate to Maintenance > Firmware Upgrade. The ILOM firmware should be kept up to date and updated as described in the Oracle Integrated Lights Out Manager (ILOM) 3.0 Daily Management - Web Procedures Guide. As a precaution, the KMA should be shut down from the OKM Console before upgrading ILOM firmware.
If you suspect that ILOM configuration changes are causing problems, you can restore ILOM settings to default values by following the instructions in the ”Troubleshooting The Server and Restoring ILOM Defaults” section of the Sun Fire X4170, X4270, and X4275 Servers Service Manual at:
http://download.oracle.com/docs/cd/E19477-01/820-5830-13/index.html
Before configuring the first KMA, first identify key split credentials and user IDs and passphrases to be defined in this OKM Cluster. Useful worksheets appear in the Oracle Key Manage Systems Assurance Guide included in the Oracle Key Manager documentation libraries. Provide these key split credentials and user IDs and passphrases to the appropriate personnel. Refer to the Quorum Protection section later in this document for more information.
Note: Retain and protect these key split credentials and user IDs and passphrases! |
Open a web browser, launch the Remote Console, and launch the OKM QuickStart utility within the Remote Console. To initialize the OKM Cluster on this KMA, follow the Initialize Cluster procedure described in the Oracle Key Manager Administration Guide included in the Oracle Key Manager documentation libraries.
The key split credentials and a user with Security Officer privileges are defined during this procedure. After the QuickStart procedure is completed, the Security Officer must log into the KMA and define additional OKM users.
Defining fewer key split user IDs and passphrases and a lower threshold is more convenient but is less secure. Defining more key split user IDs and passphrases and a higher threshold is less convenient but is more secure.
Defining fewer OKM users, some of whom have multiple roles assigned to them, is more convenient but is less secure. Defining more OKM users, most of whom have only one role assigned to them, is less convenient but is more secure as it facilitates tracking operations performed by a given OKM user.
Open a web browser, launch the Remote Console, and launch the OKM QuickStart utility within the Remote Console. To add this KMA to the OKM Cluster, follow the Join Cluster procedure described in the Oracle Key Manager Administration Guide included in the Oracle Key Manager documentation libraries.
Oracle Key Manager offers the convenient option of Autonomous Unlock for each KMA. This option is defined during the QuickStart procedure for the first and additional KMAs in a Cluster and can be modified by the Security Officer later.
If Autonomous Unlock is enabled, then the KMA will automatically unlock itself at startup and will be ready to provide keys without requiring quorum approval. If Autonomous Unlock is disabled, then the KMA will remain locked at startup and will not provide keys until the Security Officer issues a request to unlock it and a quorum approves this request.
For maximum security Oracle discourages enabling autonomous unlock. For more information about the Autonomous Unlock option, refer to the Oracle Key Manager Version 3.0 Security and Authentication White Paper at:
As stated above, KMAs are manufactured as hardened appliances with Oracle Key Manager functionality already available on them. As hardened appliances, they have the following characteristics:
Unneeded Solaris packages are not included in the Solaris image. For example, ftp and telnet services and utilities do not appear in the Solaris image.
KMAs do not produce core files.
The standard Solaris login(1) utility has been replaced with the OKM Console. Thus, users cannot log into the Solaris console.
The ssh service is disabled by default. For customer support purposes, the Security Officer can enable the ssh service and define a support account for a limited amount of time. This support account is the only available account and has limited access and permissions. Solaris auditing tracks commands that the support account invokes.
The root account is disabled.
Solaris single user mode is disabled.
KMAs are not equipped with a DVD drive.
USB ports are effectively disabled.
Unused network ports are closed.
The Hardware Security Module is certified to FIPS 140-2 Level 3, therefore providing both tamper-evident and tamper-resistant features in addition to certified cryptographic algorithms.
The newer KMAs based on Sun Fire X4170 M2 servers are tamper evident (ILOM fault) when the chassis door is accessed while power is applied.