Abstract

This technical note discusses how to use full-disk encryption with the Swarm storage solution. It includes the storage cluster nodes, Elasticsearch nodes, and CSN servers.

Overview

Swarm storage software provides a data platform for data protection, security, management and organization. The multi-tier storage method provides built-in security models and resilient replication and erasure coding options provided by object storage. Full-disk encryption capabilities are available for all the components within the storage system:

• Storage cluster nodes

• Elasticsearch nodes

• CSN management server

Swarm uses a multi-layered approach when it comes to protecting user data and enforcing business rules for information access. Customers may choose as many or as few of these layers as is appropriate for a particular deployment.

1. Physical access: full-disk encryption to prevent unauthorized booting of servers and usage of disk drives outside of the storage system.

2. Administrative access: shell login protections (local and remote) for ancillary servers and no shell capabilities for storage cluster nodes.

3. Configuration access: sensitive configuration information protected and available only to authorized system administrators using layers #1 and #2.

4. Protocol access: user data surfaced through defined object storage protocol only on defined VLAN; similar model used by storage area networks.

5. User authentication and authorization: rich access control mechanism that allows coarse-grained to fine-grained control up to per-object basis; security model scales as appropriate from simple up to complex RBAC.

Storage Cluster Nodes

Beginning with Swarm 9, the storage cluster nodes have the option to encrypt their disks so that data on a storage volume is not usable outside of the Swarm storage system. When using this feature, Swarm encrypts data as it writes it to disk and decrypts it on access.

See: Configuring Encryption at Rest

As with all previous releases of the Swarm, data may only be accessed through the native object storage protocol and no local or remote shell access exists for the storage cluster nodes.

Elasticsearch & CSN

The Elasticsearch nodes and the CSN management servers use the RHEL/CentOS operating system and protection for the disk contents and configuration information utilizes these mechanisms:

• Physical security: full-disk encryption using dm-crypt plus LUKS and requiring a security key at boot time. This prevents unauthorized startup and use of the disks outside of the system.

• Run-time security: pluggable authentication modules (PAM) for physical console and SSH remote access control. This prevents unauthorized shell access to a running system.

When using full-disk encryption, an authorized administrator must supply a security key in order to boot the system or when mounting a removed volume on another system. This is crucial in highly-security environments in order to prevent single-user booting that bypasses login and the use of the disk drives in a system that is under the control of an unauthorized person.

The configuration of full-disk encryption is performed during the initial OS installation. The following screenshot shows the option (“Encrypt system”) that is selected prior to the disk partitioning step in the RHEL/CentOS installation.

Provide the initial security key used to boot the system. After installation, the cryptsetup command is used to add, change, and remove security keys.

During system boot, administrators will be prompted to enter a valid security key in order to unlock the disk.

After the disk encryption setup steps are completed, the normal RHEL/CentOS operating system steps are performed and the Elasticsearch or CSN software is configured.

If an encrypted disk is removed from the original system and is mounted on another system, the same security key will be required in order to unlock the disk.

Since there are no backdoors built into this full-disk encryption mechanism, customers are advised to implement a mechanism by which a security key is held in escrow or recorded in a secure location. If the security key is lost or forgotten, there will be no way to reboot the system and gain access to the files on that system.