HCP for cloud scale supports encryption of data sent between systems (that is, data "in flight") and, as a licensed feature, data stored persistently within the system (that is, data "at rest").
Certificate management
HCP for cloud scale uses Secure Sockets Layer (SSL) to provide security for both incoming and outgoing communications. To enable SSL security, two types of certificates are needed:
- System certificate: the certificate that HCP for cloud scale uses for its GUIs and APIs (for incoming communications)
- Client certificates: the certificates of IdPs, storage components, and SMTP servers (for outgoing communications)
When the HCP for cloud scale system is installed, it generates and automatically installs a self-signed SSL server system certificate. This certificate is not automatically trusted by web browsers. You can choose to trust this self-signed certificate or replace it by using one of these options:
- Upload a PKCS12 certificate chain and password and apply it as the active system certificate.
- Download a certificate signing request (CSR) and then use it to obtain, upload, and apply a certificate signed by a certificate authority (CA).
- Generate a new self-signed certificate and apply it as the active system certificate.
For client certificates, upload the certificate of each client HCP for cloud scale needs to access using SSL.
You can manage certificates, and view details of installed certificates, using the System Management application.
Data-in-flight encryption
HCP for cloud scale supports data-in-flight encryption for the HTTPS protocol for all external communications. Data-in-flight encryption is always enabled for these data paths:
- S3 API (HTTP is also enabled on a different port)
- Management API
- System Management application graphical user interface (GUI)
- Object Storage Management application GUI
- External key management system (KMS) servers
You can enable or disable data-in-flight encryption for the data paths between HCP for cloud scale and:
- An identity provider (IdP) server
- Each application using TLS or SSL
- Each managed storage component
- Each SMTP server using SSL or STARTTLS
Communication between HCP for cloud scale instances does not use data-in-flight encryption. Depending on the security needs, you might need to set up an isolated internal network for HCP for cloud scale at the site.
Data at rest encryption
HCP for cloud scale supports data at rest encryption as an available licensed feature. Storage component encryption keys can be stored using either an internal service or an external key management system.
HCP for cloud scale supports data at rest encryption (DARE), enabled at the system level and controlled at the bucket level. When encryption is enabled on the system and on a bucket, every object added to the bucket is encrypted, using the S3 API, with a unique data encryption key (DEK). In turn, once an object is encrypted, the DEK is itself encrypted (or "wrapped"), using a key encryption key (KEK), and stored as part of the metadata for the encrypted object. One KEK is generated per storage component and stored separately.
An administrative account with appropriate permissions can enable encryption globally for the system. As an HCP for cloud scale administrator, before you can enable encryption, you must obtain and upload a license for the feature. Then, as part of enabling encryption, you must first decide between two mutually exclusive methods for storing KEKs:
- Internal encryption, provided by an HCP for cloud scale service.
- External encryption, provided by an external key management system (KMS).
Once encryption is enabled for the system, a bucket owner with appropriate permissions can set a policy to enable encryption at the bucket level, or later disable it. An administrator can manage the connections to KMS servers and manage KEKs by initiating rekeying as needed.