Skip to main content

This article applies to Cloud.

Available in:

StandardPremiumEnterprise
Small Business
Code42 Support

Configure a Vault server to hold your Code42 archive keystore

Overview

External keystores mean that even in the Code42 cloud environment, you can fully control the encryption keys that secure your backed-up data. The keys are stored separately from the Code42 cloud, in a Vault keystore system. Vault is a third-party application specifically built to secure secrets. This article describes how to configure a private, self-administered Vault server to store Code42 encryption keys.

Once you have your Vault server running and tested as described in this article, move your Code42 keys into Vault by following the instructions for migrating keys to a new keystore.

Let Code42 manage your keys
Instead of managing your encryption keys in Vault, Code42 can manage your keys for you. See our Encryption Key Management and Security product document for details. For more information, contact your Customer Success Manager (CSM) for enterprise support at csmsupport@code42.com.

Considerations

Vault is not a Code42 product
Our Customer Champions can assist you with migrating your keystore to your private, self-administerd Vault. Customer Champions cannot, however, provide assistance with Vault-specific tasks, such as upgrade, installation, configuration, networking, and exporting certificates. For assistance with Vault, consult the Vault documentation.

Vault versions

To ensure secure operation, install the latest Vault version from the Vault downloads page. Previous versions are available from the Vault releases page

Vault uses two SSL certificates

A Vault server connecting with the Code42 cloud uses two CA-signed SSL certificates:

  • Your Vault domain certificate secures your Vault server's domain (for example, vault.example.com). It provides encryption for all communications between Vault and the Code42 cloud. It's the same process at work in most HTTPS connections between clients and servers.
  • Your Vault user/administrator certificate authenticates the user of your Vault server who administers your Code42 cloud key storage. Your Vault server uses this certificate to authenticate and authorize requests from your Code42 cloud organization.

Before you begin

Install a Vault server

Install a Vault server at a location available to the Code42 cloud. For system requirements, see the Vault Reference Architecture guide. 

  1. Set up a machine or virtual machine with network access that allows TLS/HTTPS communication with the Code42 cloud.
  2. Plan storage capacity of roughly 1 KB for each of your Code42 users.
  3. Download a Vault package for that machine's operating system.
  4. Install and configure a Vault server as described by the Vault documentation
  5. Connect your Vault server to whatever storage backend suits your purposes.

Back up Vault

To guard against loss of your encryption keys, make sure that you back up your Vault. For Vault's backup instructions, see the Vault Disaster Recovery Replication guide.

Back up your Vault!
When you create a private keystore, create a scheduled process to back it up.
Losing a self-administered private keystore is catastrophic. A wide range of Code42 functions fail. You cannot create new users. You cannot replace a lost or damaged device from backup. You cannot restore data via the console. The only sure way to protect your data is to restart all user backups from scratch.

Steps

Sample commands
The commands below are samples only. They illustrate configuration of a Vault server on a Linux operating system. Code42 makes no guarantees regarding their suitability for your environment

Step 1: Configure your Vault to work with Code42

To allow the Code42 cloud to read and write encryption your encryption keys, configure your Vault server as follows:

  1. Enable SSL certificate authentication:
vault auth enable cert
  1. Tune Vault to issue short-lived authentication tokens for TLS connections:
    Replace<nn> with a number of seconds. A short time-to-live (TTL) is more secure than a long one. Code42 recommends 60 seconds.
    vault secrets tune -default-lease-ttl=<nn>s auth/cert
    
  2. Mount the Vault public key infrastructure (PKI):
    vault secrets enable 1
  3. Tune Vault to set the life-span of the SSL certificates it generates:
    Replace<nnnnnn> with a number of hours. Any certificate you generate with Vault works for this number of hours, then you need to replace it. Code42 recommends at least 8760 hours (1 year).
    vault secrets tune -max-lease-ttl=<nnnnnn>h pki
    
  4. Create your Vault user certificate:
    Replace <nnnnnn> with the same number of hours you provided above.
    vault write pki/root/generate/internal common_name=crashplan.com ttl=<nnnnnn>h
    vault write pki/roles/cpRole allow_any_name="true" allow_subdomains="true"
    vault write pki/issue/cpRole common_name=crashplan.com > temp_cert.pem
    cp temp_cert.pem crashplan_cert.pem
    cp temp_cert.pem crashplan_key.pem
    
    The resulting *.pem files contain hold three encrypted strings in the following order, with the following labels:
    certificate ...
    issuing_ca ...
    private_key ...
    
  5. Edit crashplan_cert.pem with a text editor so that it holds only the certificate string:
    -----BEGIN CERTIFICATE-----
    MIIDEzCCA ... 
    <encrypted string truncated here> 
    ... /x8Qtigpn=
    -----END CERTIFICATE-----
    
  6. Edit crashplan_key.pem so that it holds only the key string:
    -----BEGIN RSA PRIVATE KEY-----
    MIIEox8/+ ...
    <encrypted string truncated here>
    ... 5QD9moAAl 
    -----END RSA PRIVATE KEY-----
    
  7. Write the four lines below to a text file named crashplanPolicyFile
    The file defines a Vault policy that allows writing and storing certificates and policies—and nothing else.
    # crashplanPolicyFile
    path "pki/issue/*" {policy = "write"}
    path "sys/policy/*" {policy = "write"}
    path "auth/cert/certs/*" {policy = "write"}
    
  8. Read the policy into your Vault system:
    vault policy-write crashplanPolicy crashplanPolicyFile
    
  9. Create a Vault user to work with the Code42 cloud:
    vault write auth/cert/certs/crashplanUser display_name="crashplanUser" 
       policies=crashplanPolicy certificate=@crashplan_cert.pem
    
  10. Create a PKCS12 key and certificate file for import to the Code42 cloud:
    The openssl command will prompt you for a password. Provide up to 10,000 characters.
    openssl pkcs12 -export -out crashplan.p12 -inkey crashplan_key.pem 
       -in crashplan_cert.pem
    

Step 2: Open your firewall to the Code42 cloud

Implement firewall rules to open an inbound port at your Vault server that allows requests from the Code42 cloud. This allows the Code42 cloud to access keys in your Vault so they can be used for encryption and decryption.

Specific IPs
To obtain specific destination IPs for the Code42 cloud, contact our Customer Champions for Code42 for Enterprise support.

Step 3: Configure the Code42 cloud to work with your Vault

The crashplan.p12 file created at the end of Step 1 is a PKCS12 certificate (also called a PFX or P12 file) that identifies your Code42 cloud organization to your Vault server.

Provide the file and its password to the Code42 cloud by following the instructions for migrating keys to a new keystore.

The maximum file size is 5 MB.

Vault best practices

We recommend the following best practices for configuring Vault. For more information, see Vault's Production Hardening guide. 

Use a tested and trusted backend

Vault is compatible with different kinds of storage backends. Choose a storage backend that fits your production needs. Consul is a backend developed by HashiCorp that can function as both a backend for storing data and also service discovery in a multi-cluster setup of Vault. DynamoDB is also widely-used because it supports high availability mode while providing persistent data for Vault.

Run in high availability mode

High availability mode (HA) requires multiple Vault nodes deployed as members of the same cluster. This ensures that when the active node goes offline, the secondary node can continue to respond to API calls. Certain storage backends do not support an HA deployment, so it is important to ensure this is considered when choosing a backend. Some storage backends that support HA include Consul, DynamoDBEtcd, FoundationDB, and Zookeeper.

Do not run in development mode

You can run Vault in development mode with the following command:  vault server -dev

Never use this command to launch Vault in production environments. Launch Vault from a script like init.d or systemd as found in a Linux distribution (distro). You should also create a Vault user and group, and preferably a volume mount that only Vault can read and write to.

Always use TLS

Vault should always be used with Transport Layer Security (TLS) in production. Most high availability production environments would normally have a load-balancer or reverse proxy route traffic to the Vault nodes. It is important to ensure that this traffic is not terminated on these devices. There should end-to-end TLS communication from Code42 authorities to the load-balancer to Vault nodes.

Run as a single tenant

Run Vault as a single tenant on a machine. This reduces the risk of compromising the Vault service and exposing the keys because there is no other process on the machine that can be compromised.

Configure firewall rules

Vault listens on ports 8200 and 8201. We recommend that in a production deployment you use a local firewall to control all traffic to Vault. In cloud provider environments, use a security group or firewall rule to achieve the same objective.

Enable auditing 

Enable auditing to provide a record of Vault operations. You can send audit logs to a different destination or other system processes like syslog.

Consider your upgrade procedure

If you use automated deployments for upgrading applications, it is important to consider how you upgrade Vault and your storage backends. Choose a backend that allows for persistent data during automated deployment upgrades. DynamoDB and Google Cloud Spanner both ensure persistency during a rolling upgrade.

  • Was this article helpful?