Data Security using Encryption in SwiftStack

(1)

Data Security using Encryption in

SwiftStack

(2)

Introduction

Many people have asked how to leverage encryption with the SwiftStack Object Storage System. Within the general topic of “encryption,” there are several strategies to understand and consider— each designed to protect against a certain type of threat. We describe in this whitepaper the most common object storage encryption strategies and options for implementing them with SwiftStack.

Defining Three “Threat Models”

To understand how a particular encryption strategy will protect your data, it is necessary to

understand the threat against which you are protecting. For the purposes of this paper, we will define three types of threats to consider as you protect the data in your SwiftStack Object Storage System:

1. “Data in Flight”

This category of threat includes the possibility of someone intercepting or eavesdropping data traffic between your client applications and your storage system. Whether it is a malicious person sharing the network in a coffee shop or someone who gained unauthorized access to your corporate network, the tools to capture and read data as it is sent are freely available and easy to use.

2. “Data at Rest”

If data has been stored on a physical device (e.g., hard drive, flash device, tape drive) and that device later leaves the control of the data’s owner (e.g., for repair or decommission, due to theft), there is a possibility that someone will attempt to read the data stored on the device. 3. “Hacker” or “Rogue Administrator”

If someone gains administrative privileges to a storage system, whether rightfully or wrongfully, it will most likely be possible for him or her to access the data “in flight” or “at rest” within that system while it is up and running.

The remainder of this paper will discuss ways to protect against these threat models when using SwiftStack Object Storage.

Encrypted Data and “The Key”

Fundamental to any encryption strategy is the concept that a “key” is required to encrypt and decrypt data. The idea, assuming the encryption algorithm is strong enough, is that once a piece of data has been encrypted with a specific key, that data can only be decrypted with the same key and is

completely useless, unreadable, and unrecoverable without the key. For that reason, a well-devised plan for key management is as important as encrypting data in the first place.

(4)

Protecting Data In Flight

Encrypting End-User Traffic

Data Traffic

The first location of potential encryption is at the SwiftStack proxy layer, which handles communication between the end-user application and the storage system. Many SwiftStack implementations are public-facing, meaning the proxy services are available over the Internet. As such, it is desirable to leverage encryption at this layer so that any third parties that gain access to the communication between the end-user and the object storage system cannot make sense of the encrypted traffic even if they capture it while in flight.

Because the object storage system uses HTTP as its transport protocol, encryption at this stage is straightforward. Using TLS1_{, SwiftStack leverages industry-standard cryptographic protocols to ensure}

data transferred over the wire is secure. This is the same protocol and scheme used in a web browser when visiting a secure site, such as https://www.google.com (typically indicated by a lock icon in your browser - See Figure 1).

Figure 1 - Example of TLS encrypted website

This feature is easily configured within the SwiftStack management console by simply enabling HTTPS (see Figure 2). To complete the process, required certificates would need to be uploaded.

Figure 2 - Enabling HTTPS support in SwiftStack

Authentication Traffic

Aside from the protection of the data being transferred, another benefit to this implementation is that the user interaction with the SwiftStack system for authenticating and receiving a token is also

encrypted. Tokens allow a user to authenticate once in a period of time instead of doing so with each and every connection to the storage system enhancing the storage system’s performance. Even for an object storage system used in a protected network where data traffic encryption is not considered as important, it may still be highly desirable to use encryption during authentication to protect the

(5)

transfer of user credentials and authentication tokens. Otherwise, if a third party obtains access to an end-user’s authentication token, they can use the object storage system with all of the privileges of the user.

Impacts of Encryption

Delivering encryption requires an investment of resources. There are two main considerations when encrypting end-user traffic to and from the storage system:

1. Increased CPU Load: There is added computational overhead on the proxy machines to perform the encryption and decryption of traffic. While modern CPUs do this efficiently, the resources of a proxy server will be constrained when handling simultaneous TLS traffic streams when compared to non-encrypted streams.

2. Managing Certificates: There is complexity in setting up and using certificates for endpoint encryption termination. A certificate must be purchased from a trusted certificate authority and, along with the private key, must then be distributed to all of the proxy machines within the object storage system. Alternatively, when using internal or self-signed certificates, the pre-trusted certificate images must also be distributed to all clients using the system in order for them to trust the storage application. Look for the SSL Certificate Bundle document at swiftstack.com/docs which describes certificate management within a SwiftStack storage environment.

Encrypting the Controller’s Management Traffic

The SwiftStack Controller creates a persistent link between itself and all nodes within the system using a Linux tunnel interface and leveraging OpenVPN for encryption. This means that all traffic between the controller and each node is encrypted automatically. There are no configuration options required to enable this feature.

Encrypting Intra-Cluster Traffic

After data is received by the proxy, it will likely be redirected to one of the storage nodes within the cluster for storage or retrieval. The communication link between the proxy server and the storage nodes is NOT encrypted—for a variety of reasons:

1. It is assumed that the network between the proxy and storage nodes is a local area network (LAN) and is private. There is no assumed immediate value in encrypting the data traversing this network.

2. The added overhead of encrypting these traffic streams can be significant. Within a SwiftStack cluster, processes are constantly checking each other’s status, resulting in a significant amount of communication to be encrypted. In addition, reading and writing data is designed to be as streamlined as possible. Encryption overhead at this layer would unnecessarily slow down these operations.

(6)

3. If security needs are high enough where internal data should be encrypted, performing the data encryption at the object layer instead of the network layer is a better choice. See the

“Protecting Data at Rest” section below for details.

4. In special cases, such as when leveraging SwiftStack’s Global Clusters feature where a cluster MAY span across a wide area network, point-to-point VPN setups can be configured to achieve data encryption over the WAN link. This configuration is beyond the scope of this document, but you may contact SwiftStack sales or support for additional guidance.

For situations where encryption of intra-cluster traffic is a requirement, SwiftStack recommends implementing a layer-two encryption technology at the switching layer such as MACsec, also known as IEEE 802.1AE.

(7)

Protecting Data At Rest

After data has been stored in the object storage system, encryption is commonly used to protect the data “at rest.” The basic strategy is to ensure that anyone who gets access to physical storage devices (through legitimate or illegitimate means) can see only encrypted data but does not have the

necessary key to decrypt it. There are a number of viable strategies for encrypting data at rest, each with advantages and disadvantages to consider.

Client-Side Encryption (User)

The most robust method of protecting data at rest within the storage system is to encrypt the object before it is even written to the storage system. This way, the data that is written to disk is not viewable by any party who may gain access to the physical storage devices. While data would be encrypted end-to-end, it is still advisable to use secure networking as a best practice.

In addition, this strategy protects against the rogue administrator threat as well, because the raw data on disk cannot be decrypted by anyone without the appropriate key, which is held by the original user who put the object into the system.

This is the most secure strategy for protecting object data at rest; in fact, it is the only strategy

discussed in this paper which protects against the rogue administrator threat! The main downside is that it puts the requirement on the end-user to perform some level of encryption before putting data into the system, so key management is now the responsibility of the end-user or application using the storage system.

Advantages

● Data cannot be read by accessing physical devices

● Data cannot be read by rogue administrators with system access

● Users have the flexibility to choose the appropriate encryption tools for each use case ● Data in the system can be “securely deleted” simply by purging related encryption keys Disadvantages

● End-users or applications must manage and retain encryption keys ● End-user system CPUs must perform encryption/decryption operations

System-Side Encryption

With a system-side encryption strategy, unencrypted data is sent to the storage system (over a secure connection via TLS/SSL). As the system receives data, it is encrypted enroute to the storage media (e.g., hard drives, flash devices). Inversely, when data is requested, the storage system decrypts the data before sending it back to the end-user.

(8)

The primary reason this strategy may be considered instead of client-side encryption is that it removes the requirement for end-users to manage their encryption keys. However, by storing encryption keys within the storage system, this strategy no longer protects against the rogue-administrator threat. If an adversary obtains access to the object storage system and has the ability to read the data at rest, he or she would also have the ability to read the key used to encrypt the data, thereby nullifying any security value.

SwiftStack does not currently offer system-side encryption. Along with others in the OpenStack

development community, SwiftStack has outlined a plan for implementation. When it is implemented, the encryption feature is expected to utilize middleware to leverage third-party key management systems for external key escrow.

Advantages

● End-users and applications do not need to manage encryption keys Disadvantages

● Not currently available in SwiftStack

● No protection against rogue administrators

● Storage system CPUs must perform encryption/decryption operations ● External key management systems have a high cost

Device-Level Encryption

Raw object data is written to disk in the exact way it is received by the SwiftStack Object Storage System. As noted above, client-side encryption (i.e., encrypting an object before it is put into the storage system) is the most secure method for protecting data at rest, however, another common strategy is to use device-level encryption.

The main advantage to implementing a block device encryption system is that if a drive is removed from the storage system, you have reasonable assurances that a third party who comes into physical contact with that drive will not be able to decrypt the data stored on it. This strategy does not, however, protect against the rogue administrator threat.

There are two primary ways to implement block device encryption with SwiftStack:

1. Use LUKS (Linux Unified Key Setup): Each SwiftStack storage node is built using a Linux

operating system, and Linux has a built-in encryption tool that can ensure raw blocks of data on each drive are encrypted. Linux itself encrypts and decrypts data on-the-fly as needed.

Configuration is simple, but administrators have to manage the keys used to unlock each drive when the Linux system is booted.

(9)

A brief demonstration video for using LUKS is available here: Demo Video: Using Linux Encryption (LUKS) with SwiftStack

2. Use self-encrypting hardware: Several hardware vendors now offer self-encrypting drives (SEDs) or drive controllers which offer automatic encryption. SEDs each contain their own key and encrypt or decrypt data as it is written to or read from the drive. There is no system CPU load for encryption operations elsewhere in the infrastructure, but each drive must be “unlocked” to be used. This unlocking can be a manual step for each drive in a node (e.g. 90 drives) when booting a node, or additional software is required for managing the credentials to lock or unlock the SEDs.

Advantages

● SEDs offer “instant-erase” features simply by changing a drive’s encryption key ● With SEDs, no CPU load is required elsewhere for encryption/decryption operations Disadvantages

● Key management is still required

● No protection against rogue administrators

(10)

Object-Level Deletion

Sometimes, users of a SwiftStack Object Storage System need to securely delete an object from the system. The implication is that all physical bits associated with that data are wiped such that the object cannot be restored again. Unfortunately, the eventually consistent architecture of the object storage engine, which enables globally distributed clusters that scale to exabytes, makes it very difficult to ensure that a deleted object can never be retrieved again in the future (e.g., if a failed storage node containing a copy of the object is repaired and returned to service in the cluster).

So, if secure data deletion guarantees are required, SwiftStack recommends leveraging client-side encryption before the object is placed into the system. That way, after the command to delete an object is sent to the system and the original encrypting keys are purged, there is no way to decrypt any object data that may temporarily remain in the system.

Device-Level Erasure

When a device such as a hard drive is intentionally removed from a storage system, corporate policy may require the data on it be completely erased before retirement, repair, or reuse. Past strategies including physical device destruction, degaussing, and overwriting data have been time-consuming and expensive. By leveraging encryption, however, one only needs to separate the device from any

associated encryption keys to render the data on it useless and effectively erased. In particular, vendors of self-encrypting drives offer a feature that allows the encryption key within the SED to be changed in a matter of seconds, effectively erasing the drive and making it safe to use again or send away.

(11)

Conclusion

In summary, when considering an encryption strategy, it is important to first determine the threat models against which you want to protect. Then, consider the advantages and disadvantages for each strategy that offers the level of protection you require.

In this paper, we discussed three threat models: eavesdropping data in flight, unauthorized access of data at rest on hardware that has been removed from a storage system, and unauthorized access of live data in a storage system by a rogue administrator or hacker. We then discussed strategies to protect against these threats either on the client-side, in the storage system, or at the device-level and the advantages and disadvantages for each.

If you choose only one, SwiftStack recommends the client-side encryption strategy, as it provides the most complete protection against known threats, offers the most flexibility, and enables secure deletion of data in the system. For a truly secure infrastructure, consider coupling this with other strategies within (e.g., self-encrypting hardware) and outside the storage system (e.g., intrusion detection, anti-virus) as well.

Data Security using Encryption in SwiftStack