1. Security Guide
  2. Secure Installation and Configuration
  3. Securely Install the Key Management Appliance

Securely Install the Key Management Appliance

Follow the recommended installation and configuration process for the Key Management Appliance to ensure a secure installation.

Installing and configuring KMAs in an OKM Cluster include the following steps:

Install the KMA in a Rack

An Oracle Customer Service Engineer installs the KMA in a rack according to procedures outlined in the Oracle Key Manager 3 Installation and Administration Guide.

Secure the ILOM of the KMA

The customer should secure the ILOM of a KMA (possibly with guidance from an Oracle Customer Service Engineer). Oracle Key Manager KMAs are manufactured with recent ILOM firmware. The ILOM should also be secured after the ILOM firmware is upgraded. Securing the ILOM consists of setting particular ILOM settings to prevent changes to the ILOM that may compromise security. For instructions, see the ILOM appendix of the Oracle Key Manager 3 Installation and Administration Guide.

Secure the OpenBoot PROM of the KMA

The customer should secure the OpenBoot PROM of a KMA (possibly with guidance from an Oracle Customer Service Engineer). Oracle Key Manager KMAs are manufactured with recent OpenBoot PROM firmware. It should also be secured after the firmware is upgraded. Securing the OpenBoot PROM consists of setting particular settings to prevent changes that may compromise security. For instructions, see the Oracle Key Manager 3 Installation and Administration Guide.

Configure the First KMA in the Cluster

To configure the first KMA, you must identify the split credentials and user IDs and passphrases. Refer to Quorum Protection later in this document for more information. To initialize the OKM Cluster on this KMA, follow the configure cluster procedure described in the Oracle Key Manager 3 Installation and Administration Guide. 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 in to the KMA and define additional OKM users.

Add KMAs to the Cluster

Use the QuickStart program to add a KMA to the cluster.

  1. Launch the host console of your SPARC KMA from its Service Processor web interface or CLI, depending on the server type of your KMA.
  2. Launch the OKM QuickStart utility within the host console.
  3. To add this KMA to the OKM Cluster, follow the Join Cluster procedure described in the Oracle Key Manager 3 Installation and Administration Guide.

Considerations When Installing OKM

To maximize security, follow key considerations when configuring and installing OKM.

Considerations When Defining Key Split Credentials

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. Find a balance between security and convience.

Considerations When Defining Additional OKM Users

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.

Considerations When Configuring Autonomous Unlock

Using Autonomous Unlock has important security implications. For maximum security, make sure this feature is disabled. OKM 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 the Security Officer can modified it 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 2.x Security and Authentication White Paper at: http://www.oracle.com/technetwork/articles/systems-hardware-architecture/okm-security-auth-300497.pdf

Characteristics of Hardened KMAs

KMAs are manufactured as hardened appliances have these key characteristics.

  • Unneeded network services are not enabled. For example, ftp and telnet access is not provided.
  • A host-based firewall is installed and pre-configured for intrusion prevention.
  • KMAs do not produce core files.
  • Users are not permitted to log in to the KMA. Attempting to log in through the system console brings up the OKM Console utility.
  • The ssh service is disabled by default. For customer support purposes, the Security Officer can enable the ssh service and enable 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 DVD drive in a SPARC KMA is uncabled.
  • USB ports are disabled when a KMA is booted up.
  • Non-executable stacks are enabled.
  • Address space lookup randomization is configured.
  • Non-executable heaps are enabled.
  • Filesystem-level encryption is used for security sensitive filesystems.
  • Solaris is configured in accordance with the Security Compliance Automation Protocol (SCAP) Basic Solaris and PCI-DSS benchmarks. Solaris is also configured for compliance with a current version of the Solaris 11 DISA STIG. Refer to the OKM 3 Installation and Administration Guide for how to produce STIG reports for compliance auditing.
  • Unnecessary Solaris services are disabled.
  • The optional nShield Solo+ 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.
  • Oracle Solaris Verified Boot is configurable on SPARC T7-1 and later based KMAs to secure the system boot process. You can configure this feature in the ILOM to warn about or prevent the loading of corrupted kernel modules, insertion of other malicious programs masquerading as legitimate kernel modules, or installation of unauthorized kernel modules. Refer to the Oracle ILOM Administrators's Guide for Configuration and Maintenance for more information about this feature.
  • Newer KMAs based on SPARC T7-1 and later servers are tamper evident (ILOM fault) when the chassis door is accessed while power is applied.
  • ILOM firmware is FIPS 140-2 Level 1 certified and may be configured in FIPS mode.
  • The Solaris Cryptographic Security Framework is configured per the FIPS 140-2 Level 1 security policies (documented for Solaris 11.3) with or without the presence of a Hardware Security Module.