Dell EMC CloudLink – Part1, Introduction.
Security is all around us, just the other day, I blogged about a new feature of CloudIQ, called “CloudIQ CyberSecurity” , now, let’s talk about encryption of the actual data..
Keeping data safe in a traditional data center is one of the biggest challenge’s security administrators are facing these days. Ensuring data safety requires security controls, and system checks built layer by layer into the structure of a data center. Customers are turning to data encryption to help secure their deployments from on-premise and throughout the cloud.
Modern enterprises are heading toward embracing hybrid cloud models for deployment flexibility, infrastructure scalability, and cost-effective use of IT resources. However, because cloud computing is based on a shared, multitenant compute, network, and storage architecture, traditional security controls are not sufficient. Data owners have many reasons for encrypting their data, from securing sensitive data that reside on the cloud, addressing regulatory compliance to protecting against theft of customer data and sensitive intellectual property.
Encryption enciphers the original data into an unrecognizable format. This format of the data is different from the original data. Encryption is done using a key algorithm. These encryption and decryption keys must be stored in a secure location. Unauthorized access to the keys or losing them may lead to data inaccessibility and data security issues.
There are two methods of encryption- symmetric and asymmetric encryption.
-
Symmetric encryption, pertains to the sender and the recipient holding the same keys to encrypt and decrypt a message.
-
Asymmetric encryption, uses a key pair—a public key for encrypting a message, and a private key to decrypt it.
Challenges in Data Encryption
Datacenters require that data must be secured both at the hardware and software layers that is on-premise and on the cloud.
Cloud computing is based on a shared, multi-tenant, and software-defined compute, network, and storage architecture. Data owners are responsible for securing sensitive data across public and private clouds, but traditional security controls no longer apply. New solutions must address privacy, regulatory, and data remanence (residual data) requirements. They must also provide the flexibility to support various encryption approaches for diverse use cases.
Storage infrastructure-level encryption provides a convenient way to secure data in the private data center that is transparent to the applications deployed on the physical and virtual infrastructures that consume the storage.
Virtual machine-level encryption offers an infrastructure-agnostic approach that is portable across private and public clouds and keeps VMs secure during the migration process.
Some of the challenges that might be encountered when encrypting data:
-
Key Management – Encrypted volumes in virtual machines require externally stored keys. But they do not have direct access to physical hardware in cloud environments. Also, for every volume in a virtual machine that we deploy, another key must be secured and managed. Managing these keys can be difficult and time-consuming, and if we do not do it consistently, we risk losing data.
-
VM movement – Moving a VM from one host to another in the encrypted state requires a flexible solution that keeps the data encrypted regardless of where and how it moves.
-
Native OS Data Encryption – We can secure data using native operating system encryption capabilities (Microsoft Windows uses BitLocker for Windows and various Linux distributions use dm-crypt), but these solutions are difficult to configure, manage, and apply consistently throughout a deployment.
CloudLink Solution
CloudLink deployed across multiple sites
CloudLink is a flexible data encryption and key management solution for data encryption in public, private, and hybrid cloud environments. CloudLink encrypts data with unique keys that enterprise security administrators control. Neither data center administrators nor other tenants in the cloud have access to the keys, offering protection against tampering and data spillage.
CloudLink can secure sensitive information within machines on-premise, cloud, and multi-cloud environments. It provides encryption for volumes with pre-startup authorization by leveraging native operating system encryption features – Microsoft BitLocker for Windows or dm-crypt for Linux. Pre-startup authorization is provided via key release policies which help to validate that the encrypted machine has not been compromised. Policy-based key release is available for VM, bare metal, VxFlex platform encryption, and SED (Self-Encrypting Drive) key management.
CloudLink Features
Data Center Encryption
Let us look at the encryption types supported by CloudLink at different data center layers. At the bottom hardware layer, encryption can be provided for SEDs (Self-Encrypting Drives) or Controller-based encryption. Moving up the stack, encryption can be done at the software-defined storage level, at virtual machines, or even in Kubernetes containers (next release v7.0).
CloudLink can provide external key management over KMIP (Key Management Interoperability Protocol). KMIP is an open standard defined and developed by OASIS, and it governs the communication between the third-party encryptors and key managers. CloudLink supports KMIP versions 1.1 through 1.4.
CloudLink provides policy-based key management and supports multiple data encryption options for VxFlex OS devices, SEDs, virtual, and bare-metal machines.
The image describes the CloudLink solution architecture. Click each component for more details.
CloudLink Center and Agent
CloudLink Center: A significant component of the CloudLink solution is the CloudLink Center. CloudLink Center is a policy-based key management server. It is packaged as a virtual appliance and can be deployed on VMware ESXi, Microsoft Hyper-V, Microsoft Azure, or Amazon Web Services infrastructure.
CloudLink Center provides a web-based user interface for managing the CloudLink environment. The GUI uses the underlying REST-API and allows an administrator to manage agents, users, and encryption keys. An administrator can also configure roles, policies, and keystores, as well as monitor events, alarms, and logs.
Agent: The CloudLink agent runs on individual machines. It communicates with CloudLink Center for pre-startup authorization and decryption of BitLocker or dm-crypt encryption keys.
Encryption Keys
CloudLink uses the following types of encryption keys to secure virtual machines:
-
A device/volume encryption key that is used by native OS based encryption. A unique device encryption key is generated for each encrypted device.
-
A device/volume key encryption key (VKEK) that is generated by CloudLink. CloudLink generates a VKEK for each device or encryption key.
When the CloudLink agent initially sends a volume encryption key to the CloudLink Center, the CloudLink Center uses its own encryption key to encrypt the volume key. The VKEKs protect volume keys from being copied and used to decrypt volumes.
CloudLink Center stores and protects keys in a location that is called a keystore.
Keystores
CloudLink Center stores and protects keys in a location called a keystore. The keystore is made up of two components, the Key Location which stores the encryption keys and a Key Protector which is the protection mechanism that is used to encrypt and protect the encryption keys.
-
During installation, CloudLink creates an internal key location – the CloudLink Vault to store volume encryption keys and VKEKs.
The Vault is used as the internal key protector which encrypts or protects the key location.
CloudLink can also use other external Key Protectors such as Microsoft Azure Key Vault, SafeNet Network HSM, and KMIP-compliant servers
CloudLink supports the use of remote keystores, such as Microsoft Active Directory or Amazon S3. The keys are stored in a location external to CloudLink Vault, and secured with an external key protector.
Key Location
CloudLink Center supports several options for the key location used to store encryption keys.
Key Protectors
A key protector is the protection mechanism used to encrypt and protect the device encryption keys.
KMIP Server
A KMIP (Key Management Interop Protocol) server is used to store public and private keys for encrypted machines. CloudLink Center supports KMIP to allow applications supporting that protocol to securely store keys and certificates.
The applications, or KMIP clients, are given access to a single KMIP partition. A KMIP partition is a logical container for keys that are created by the client. Multiple clients can be assigned to the same partition. All objects within a partition are encrypted using a key that is saved to the partition’s keystore and are stored in the CloudLink Center database.
CloudLink is a certified VMware Ready™ KMS (Key Management Server), giving VMware customers complete flexibility for their data encryption needs. With VMware vCenter connected, CloudLink can perform as a KMIP server to support vSAN and vSphere encryption without deploying any agents.
CloudLink Supported Encryption
SED Encryption
Self-encrypting drive (SED) is an intelligent hardware security solution that automatically encrypts the data that is written to it without any user interaction. SED offloads encryption from the host CPU, freeing cycles that software-based encryption would otherwise consume. The encryption process in SED is done by using a unique and random Data Encryption Key (DEK) which the drive uses to both encrypt and decrypt data. The Authentication Key in the SED manages access to the encrypted data.
Click to watch video on What is SED.
Securing data with SEDs requires a key management service that stores, manages, and serves the appropriate authentications to these drives. CloudLink provides support and management capabilities that allow users to safely secure their data-at-rest.
CloudLink provides two key management options:
-
Local Key Management: CloudLink agent can provide direct SED key management via the HBA controller. The CloudLink Agent provided by the CloudLink Center acts as the keystore manager. SED encryption keys are stored on the disk controller which ensures that data cannot be accessed if the disk is removed from the server for purposes like maintenance, decommissioning and repurposing.
-
External Key Management: SED encryption keys are stored in an external key manager via KMIP. This protects against cases like theft of the server.
PowerFlex Integration with CloudLink
PowerFlex is a software-defined storage solution that uses the nodes’ local disks and LAN to create a virtual SAN. It is designed for a massively parallel I/O system with high resiliency and can scale to thousands of nodes. VxFlex OS pools together local storage devices from each node. Volumes are then created from the pooled storage and used as shared storage among all nodes. PowerFlex is inherently elastic and can be deployed in various architectures to support various use cases.
Storage Data Server (SDS) manages the capacity of a single node and acts as a backend for data access. The SDS is installed on all nodes contributing storage devices to the VxFlex OS cluster. SDS could be running on Bare metal Linux (only supported on Linux) nodes or a Linux VM on supported hypervisors. CloudLink Agent is installed on SVM or Linux running on SO nodes.
Similar to VM encryption, agents leverage dm-crypt, a Linux OS native encryption capability to encrypt the SDS devices. Encryption is enabled on raw devices before they can be added to the storage pool.
Enterprise security administrators can control these keys with CloudLink Center. The CloudLink Center provides a centralized, policy-based key release, enabling single-screen security monitoring and management across one or more PowerFlex deployments, including storage-only, hyperconverged, and those on ESXi.
CloudLink operates directly on SDS devices so that data at rest encryption is transparent to applications. There is no impact to VxFlex OS features because encryption is performed before data is written to SDS devices. This ensures that the enterprise-grade data protection and resiliency that is provided by PowerFlex are uninterrupted by the encryption process.
PowerFlex Encryption Overview
In a PowerFlex environment, storage is provided by multiple nodes that are running the Storage Data Server (SDS) process. Applications reside on nodes that are running the Storage Data Client (SDC) process. When an application requires data, the SDC contacts the SDS to retrieve the information. Nodes can run both the SDC and SDS processes and can, therefore, support applications and provide storage.
CloudLink agents are installed on the SDS nodes only, and work with the operating system to encrypt local devices. The agents communicate with CloudLink Center using ports 80 and 1194. Although both CloudLink and PowerFlex support multiple operating systems, currently the solution only works with SDS nodes running a CloudLink agent on Linux.
Encrypting SDS Device
CloudLink encrypts raw devices so the encrypted device can be added to VxFlex OS SDS. A raw device does not contain partitions or a file system. If the device is already added to VxFlex OS, the device should be removed before you encrypt it because the encrypted device no longer contains the original data. An encrypted device’s data can be erased so it can be used for another purpose, but this process destroys all data.
In CloudLink Center, you can encrypt a VxFlex OS SDS device when the machine is in the connected state. Encrypting a device is a quick operation because the device contains no data. Only one device can be encrypted at a time.
In the image here, we have encrypted three devices through the CLI and this is reflected in the CloudLink Center.
CloudLink and PowerFlex Manager
CloudLink can be integrated into PowerFlex Manager as a discoverable resource in PowerFlex integrated rack and appliance.
PowerFlex Manager can provide life-cycle management, monitoring, upgrades, and alerts for the CloudLink Center. These operational tasks are configured automatically in VxFlex Manager during the integration (discovery process) of the CloudLink Center.
CloudLink Capabilities
Users and Roles
Each person who must work with CloudLink must be defined as a user in CloudLink Center. User accounts can be created locally in CloudLink Center or can be defined by integrating with a Microsoft Windows domain.
Each user is assigned a role that determines their permissions and specifies which administrative functions or tasks are permitted in CloudLink Center. A user can be assigned multiple roles, giving them a combined set of permissions.
CloudLink Center provides three built-in roles:
-
SecAdmin – Full access to all objects and functionality and provided by default.
-
Admin – Limited access to CloudLink Center functionality, primarily for managing user accounts and backups, and viewing event logs.
-
Observer – View configuration options and event logs.
Custom roles can also be created. The roles are assigned to users and when a user logs in to CloudLink Center, he or she receives the permissions that are assigned to the role.
Machine and Machine Groups
When a CloudLink agent registers with CloudLink Center, a machine object is created. Each machine must be assigned to a machine group, which is also an object defined in the CloudLink Center and used to combine machines into manageable units.
Machine groups link various objects, like approved networks, policies, approved locations, and keystores to all the machines in the group. Machine groups are used to combine machines for administrative or operational purposes.
For example, you might group machines by department, where each department may have a different set of requirements. Another example could be to group machines by function or location, where development has different requirements than production. Each machine group can have its own administrator as well.
A machine is assigned to a machine group during deployment. If you do not specify a group during deployment, the machine is assigned to the built-in machine group named Default. You can change the machine group that a machine belongs to after deployment.
Policies
Policies are created on the CloudLink Center and are used to determine which volumes are encrypted and which agent is authorized to have a key.
All machines in a group use the same:
-
Keystore
-
Authentication
To access CloudLink Center, a user must provide both a username and password. For increased security, CloudLink provides an option to enable two-factor authentication provided by RSA.
CloudLink supports the creation of local user accounts with REST-API and also supports users and groups from Microsoft Windows Domain.
An extra layer of security can be added using two-factor authentication, provided by Google Authenticator.
Licensing
Licenses come in different flavors for CloudLink:
-
Capacity license defines how much total storage will be protected.
-
Instance license defines the number of virtual or bare-metal machines that will be protected in a CloudLink environment.
-
KMIP license defines how many KMIP clients can be managed.
-
Socket-based license is available for VMware platforms and is assigned to ESXi hosts by the number of sockets.
-
SED license enables the management of keys for self-encrypted drives. A single SED license is used per physical machine regardless of the number of SEDs connected to that machine.
CloudLink Deployment and Management
CloudLink agents can be deployed on various versions of Windows and Linux operating systems. Refer to the latest Deployment guide for detailed information. A network connection between the agents and the CloudLink Center is required for virtual machine startup, key requests, and continuous monitoring. Network port 80 is used for the agent installation and port 1194 is for normal agent communication. These ports must be opened for any firewalls that exist between the two endpoints. Port 443 must be open for users to access the web UI of the CloudLink Center.
Clustered CloudLink Center
A CloudLink Center cluster provides for high availability if one CloudLink Center server in the cluster becomes unavailable, whether due to planned maintenance or an unexpected issue. High availability is achieved by deploying the CloudLink Center appliance in an active/active cluster of 2-4 nodes. A CloudLink Center cluster consists of up to four CloudLink Centers. These additional nodes should be dispersed across multiple physical servers to increase availability. Configuration information is replicated across nodes. Replicated items include licenses, policies, user accounts, locally stored passcodes, and keys, actions, alarms, and events. Network ports 80 and 443 must be open between the clustered CloudLink Centers to enable all communication traffic.
CloudLink Cluster Node Failure
When a CloudLink cluster is established, agents can be connected to and controlled by any node in the cluster. Under normal operating conditions, an agent communicates with one node. If that node fails, the agents that were connected to that node can connect and communicate to any of the other nodes.
Deployment in Multiple Clouds
CloudLink Center can be deployed in a private cloud running various hypervisors and can secure virtual machines within that cloud. CloudLink can also secure virtual machines in other clouds, as long as a network connection exists between the CloudLink Center and agents and ports 80 and 1194 are open. CloudLink Agent is deployed to individual virtual machines hosted in the private cloud or to virtual machine instances in a supported public or hybrid cloud environment. For public cloud, CloudLink Center can be deployed in Microsoft Azure, or Amazon Web Services.
Backup and Recovery in CloudLink
System issues such as power interruptions or hardware failures may cause problems in CloudLink Center, such as data loss or database corruption. If problems occur, it is important to have a backup of CloudLink Center so that you can deploy a new server and restore CloudLink Center from the backup.
A backup file includes all critical information to get CloudLink Center up and running, including keystore configuration, user accounts, machine registrations and policies, and events. You can create backup files manually or automatically. You can create a backup store where CloudLink Center stores automatic backups.
A backup is stored in a file that is encrypted using a FIPS 140 encryption library. The private key from the RSA key pair must be secured by the administrator and will be required to perform CloudLink restore operation. Backups are stored locally by default but can be redirected to a remote site using FTP, SFTP, or FTPS protocols.
You generate the RSA-2048 key pair. The public key is stored in CloudLink Center. Download and save the private key when the key pair is generated. To restore CloudLink Center from a backup file, both the backup
CloudLink, can be downloaded by clicking the screenshot below
and the documentation, can be accessed from this url https://www.dell.com/support/home/en-us/product-support/product/cloudlink-securevm/docs
