• Data Security Settings

    PDF

    Data Security Settings

    This chapter describes the security features that are available on the storage system for supported storage types.

    Topics include:

    About Data at Rest Encryption (physical deployments only)

    Data at Rest Encryption (D@RE) is provided through controller-based encryption (CBE) at a physical drive level. The goal of this feature is to ensure that all customer data and identifying information will be encrypted with strong encryption, primarily to ensure security in the event of loss of a drive.

    A unique data encryption key (DEK) is generated for each drive and is used to encrypt data as it is sent to the drive. The DEK is used to encrypt/decrypt user data using 256-bit Advanced Encryption Standard (AES) algorithm with the XOR Encrypt XOR Tweakable Block Cipher with Ciphertext Stealing (XTS) mode of operation.

    The Key Encryption Key (KEK) is a 256-bit randomly generated key created by RSA BSAFE and is used to wrap the DEKs at the time of DEK generation so that the DEKs are protected and secured as they move through the storage system. The algorithm used to wrap and unwrap the DEKs using the KEK is 256-bit AES Key Wrap, as specified in RFC 3394.

    The Key Encryption Key Wrapping Key (KWK) is a 256-bit randomly generated key created by RSA BSAFE and is used to wrap the KEK at the time of generation so that the KEK is protected as it travels throughout the array and to the SAS (Serial Attached SCSI) controller. The algorithm used to wrap and unwrap the KEK using the KWK is 256-bit AES Key Wrap, as specified in RFC 3394.

    Separate from CBE, system space on the Storage Processors (SPs) is encrypted using an encryption capability (dm_crypt) that is native to the Linux distribution. Specific partitions on the system drive are encrypted by default unless encryption is not activated on the system at manufacture time. For those system partitions that are not encrypted, some unencrypted data, such as diagnostic dumps, could be present. In addition, there is potential for small amounts of unencrypted user data as a result of writing diagnostic materials to the system partition. All the data written to the array by using regular I/O protocols (iSCSI, FC) are encrypted. Anything that comes into the array by using the control path will not be encrypted by this solution; however, information that is sensitive (for example, passwords) are encrypted by a different mechanism (as they are on non-encrypting arrays).

    A component, referred to as the Key Manager, is responsible for generating, storing and otherwise managing the encryption keys for the system. The keystore that is generated to store the encryption keys resides on a managed LUN in private space on the system. Keys are generated or deleted in response to notifications that a storage pool has been added or removed. Key backups are performed automatically by the system. In addition, changes to the configuration of the system that result in changes to the keystore will generate information alerts that recommend key backups be created. When an operation that results in a change to the keystore occurs, an alert will appear and persist.

    A separate auditing function is provided for general key operations that track all key establishment, deletion, backup, and restore changes as well as SLIC addition.

    For additional information about the Data at Rest Encryption feature, refer to the Unity: Data at Rest Encryption white paper.

    Feature activation

    D@RE is a licensed feature. The license must be installed during the initial configuration of your system. Once activated, the encryption operation cannot be reverted.

    The encryption operation will cause data encryption keys to be created and all user data will begin to be encrypted. The encryption keys are stored in a keystore file. The keystore file that is generated resides on a managed LUN in private space on the system.

    It is strongly recommended that you backup the generated keystore file to another location which is external to the system where the keystore can be kept safe and secret. In the event that the keystore on the system becomes corrupted, the system will be nonfunctional. The system will enter service mode; only the operating system boots. In this state, attempts to access the system through Unisphere will return an error indicating that the keystore is in an inaccessible state. In this case, the backup keystore file and a service engagement are required for resolution.

    Encryption status

    The following D@RE feature status can be viewed either through Unisphere or a CLI command:

    • Encryption Mode: type of encryption in use; for example, Controller-Based Encryption.
    • Encryption Status: based on the actual encryption status:
      • Unsupported, encryption of the system space on the SPs is disabled.
      • Not licensed, the Data at Rest Encryption license has not been installed on the system.
      • Encrypted, encryption is complete.
      • Not encrypting, CBE is disabled.
      • Scrubbing, the process of writing random data to unused space on drives or zeroing unbound drives to erase residual data from previous use.
        For SAS Flash 2 drives, unmap is used to scrub the drives rather than zeroing. For more information about Data at Rest Encryption and the scrubbing process, refer to the EMC Unity: Data at Rest Encryption white paper located at Online Support ( https://support.emc.com).
      • Encrypting, encryption is in progress.
    • KMIP Status, whether KMIP is enabled or disabled.

    To view the status of the D@RE feature in Unisphere, select Settings > Management > Encryption. The status of the encryption appears under Manage Encryption.

    As an alternative, use the CLI command uemcli -u <username> -p <password> /prot/encrypt show -detail to view the feature status (Encryption mode, Encryption status, Percent encrypted, Backup keystore status, and KMIP status). You can also use this CLI command to view the status of the keystore and to determine whether any user operations are required. See the Unisphere Command Line Interface User Guide for detailed information about these CLI commands.

    External key management

    Support for external key management is provided through the use of the Key Management Interoperability Protocol (KMIP). KMIP defines how a client operates with an external key manager.

    External key management is only supported with key management servers that have implemented the KMIP protocol developed by OASIS. If a Gemalto KeySecure KMIP server is used, the Key Manager on the storage system requires the user name and password to be configured on the server.

    Enabling and configuring support for KMIP on the storage system is dependent upon encryption being enabled on the storage system. When encryption is enabled and KMIP is enabled, the ignition key is migrated from the storage system to an external key manager, and the local copy is deleted. Also, the old location of the locally stored keys is reprogrammed and cannot be opened once the keys are migrated. Generating a new keystore file backup is recommended.

    A user role of administrator or storage administrator is required to configure external key management. To configure external key management, select Settings > Management > Encryption and, under Manage Encryption > External Key Management, select Configure. Fill in the information that is required in the dialog box that appears to configure key management server properties and to add the KMIP server to the KMIP server cluster. The dialog box also provides the means to import and manage the relevant CA and client certificates and to verify the configuration. The configuration requires two certificates:

    • CA certificate in PEM format
    • A password protected PKCS #12 file which contains the client certificate

    A copy of the configuration for the KMIP server, including the certificates and server configuration data, is stored locally in secure locations on the storage system as well as backend system drives to provide redundancy.

    For compatibility and interoperability information related to the KMIP servers, refer to the Simple Support Matrix for the storage system on the support website.

    Certificates are downloaded onto the active SP. At boot time, whenever a problem with certificate is reported, the system restores the certificates from its local copy of the lockbox, and retries. If it fails again, the system goes into service mode. If a difference is found, the lockbox content on the backend is updated.

    As an alternative, use the CLI command uemcli -u<username> -p<password> /prot/encrypt/kmip -set -username <value> {-passwd <value> | -passwdSecure} -port <value> [-timeout <value>] -server <value> to configure KMIP. Use the CLI command uemcli -u<username> -p<password> /sys/cert [ -type { CA | Server | Client | TrustedPeer } ] [ -service {Mgmt_LDAP | Mgmt_KMIP | VASA_HTTP } [ -scope <value> ] ] [ -id <value> ] to import CA and client certificates. Use the CLI command uemcli -u<username> -p<password> /prot/encrypt/kmip -verify to verify the configuration. See the Unisphere Command Line Interface User Guide for detailed information about these CLI commands.

    If there is a problem with or unexpected change to the KMIP configuration or status, the system cannot confirm the correct configuration or status and starts in Service Mode. The system cannot return to Normal Mode until the issue is resolved. A service script, svc_kmip, can be used to restore the correct KMIP server configuration and, if necessary, the Unity certificates so that the system can return to Normal Mode.

    The service script, svc_kmip, is only for recovery and cannot be used to set up the KMIP configuration and enable it on a new system. For more information about this service script, see the Service Commands Technical Notes.

    Backup keystore file

    Changes to the configuration of the system that result in changes to the keystore generate information alerts which persist and recommend key backups be created. A new alert will be generated only after the keystore has been retrieved from the system for backup.

    It is strongly recommended to backup the generated keystore file to another location which is external to the system where the keystore can be kept safe and secret. In the event that the keystore files on the system become corrupted and in an inaccessible state, the system will enter service mode. In this case, the backup keystore file and a service engagement are required for resolution.

    A user role of administrator or storage administrator is required to backup the keystore file. To backup the keystore file to a location that is external to the system where the keystore can be kept safe and secret, select Settings > Management > Encryption and, under Manage Encryption > Keystore, select Backup Keystore File. The dialog box that appears directs you through the steps to backup the generated keystore file.

    As an alternative, use the CLI command uemcli -u<username> -p<password> -download encryption -type backupKeys to backup the keystore file to a location that is external to the system where the keystore can be kept safe and secret. See the Unisphere Command Line Interface User Guide for detailed information about this CLI command.

    Data at Rest Encryption audit logging

    The D@RE feature provides a separate auditing function that supports logging of the following keystore operations:

    • Feature activation
    • Key creation
    • Key destroy
    • Keystore backup
    • Disk encryption completed
    • SLIC addition

    The audit log for keystore operations is stored in the private space on the system. To download either the entire audit log and checksum information or the information for a specific year and month, select Settings > Management > Encryption and, under Manage Encryption > Audit Log, select Download Audit Log & Chksum. To download a newly generated checksum file for the audit log file that was retrieved at an earlier time, select Settings > Management > Encryption and, under Manage Encryption > Audit Log, select Download Chksum. The filename that you supply must match exactly to the auditlog file that was retrieved previously.

    As an alternative, use the uemcli -u<username> -p<password> -download encryption -type auditLog -entries <all or YYYY-MM> CLI command to download the entire audit log and checksum information or a partial audit log, respectively. See the Unisphere Command Line Interface User Guide for detailed information about this CLI command.

    Hot spare operations

    When a system is already configured with DEKs for all the disk drives in the system that are in provisioned pools, drives that are not currently in a provisioned pool are considered unbound drives. Removal of unbound drives or unbound drives that become faulted have no affect on the keystore and therefore do not require a backup of the keystore file. Likewise, replacement of an unbound drive has no affect on the keystore and therefore does not require a backup of the keystore file.

    Disk drives that are not bound will be overwritten with default data to remove pre-existing data.

    When a system is already configured with DEKs for all the drives in the system that are in provisioned pools, those drives are considered bound drives. If a bound drive is removed or the drive becomes faulted, and after a period of five minutes a permanent hot spare replaces the removed or faulted drive, a DEK is generated for the hot spare, and rebuild begins. The DEK from the removed drive will be removed immediately from the keystore. A keystore modified status will be set by the Key Manager at this point and will trigger an alert to back up the keystore because DEK modifications were made to the keystore.

    If the removed disk drive is reinserted anywhere in the system before the five minute period has expired, a rebuild will not be required and modifications will not be made to the keystore. The DEK will remain the same because the key is associated with the disk drive, not the slot. Also, a keystore modified status alert will not be generated.

    If sanitizing or destruction of the removed drive is required, it should be done independently.

    Adding a disk drive to a storage system with encryption activated

    Inserting one or more new disks into the system does not trigger generation of a new DEK for each disk. This operation will not occur for a new disk until the disk is provisioned into a pool. A keystore modified status will be set by the Key Manager at this point and will trigger an alert to back up the keystore because DEK modifications were made to the keystore.

    When you add a new disk drive to a storage system, the drive is considered unbound. Disk drives that are not bound are overwritten with default data to remove pre-existing data. Only the addressable space of the drive is overwritten. Any residual plaintext data that may be hidden in obscured locations within the drive will not be overwritten.

    If the potential access to data remnants from the previous use of a drive violates your security policy, you must independently sanitize the drive before it is inserted in the storage system with encryption activated.

    Removing a disk drive from a storage system with encryption enabled

    When a system is already configured with DEKs for all the drives in the system that are in provisioned pools, those drives are considered bound drives. If a bound drive is removed and after a period of five minutes is not replaced, the DEK for the drive will not be removed from the keystore. The key will remain valid until the provisioned pool is deleted, or until a new drive is swapped in. If the removed disk drive is reinserted anywhere in the system before the five minute period has expired, a rebuild will not be required, as in the case of a replacement drive, and modifications will not be made to the keystore. The DEK will remain the same because the key is associated with the disk drive, not the slot. Also, a keystore modified status alert will not be generated.

    If sanitizing or destruction of the removed drive is required, it should be done independently.

    Replacing a chassis and SPs from a storage system with encryption enabled

    The generated keystore has a relationship to the hardware in the storage system. A service engagement is required to replace a chassis and SPs from a storage system with encryption enabled.

    Data security settings

    Table 1 shows security features available for supported storage system storage types.

    Table 1. Security features
    Storage type
    Port
    Protocol
    Security settings
    iSCSI storage
    3260
    TCP
    • iSCSI host (initiator) level access control is available through Unisphere (allowing clients to access primary storage, snapshots, or both).
    • CHAP authentication is supported so that storage system iSCSI Servers (targets) can authenticate iSCSI hosts (initiators) that attempt to access iSCSI-based storage.
    • Mutual CHAP authentication is supported so that iSCSI hosts (initiators) can authenticate storage system iSCSI Servers.
    SMB storage
    445
    TCP, UDP
    • Authentication for domain and administrative actions is provided through Active Directory user and group accounts.
    • File and share access controls are provided through Windows directory services. SMB share access control list (ACL) can also be configured through an SMI-S interface.
    • Security signatures are supported through SMB signing.
    • SMB encryption is provided through SMB 3.0 and Windows 2012 for those hosts capable of using SMB.
    • Supports optional file-level retention services through add-on software.
    NFS storage
    2049
    TCP
    • Share-based access control provided through Unisphere.
    • Support for NFS authentication and access control methods identified in NFS versions 3 and 4.
    • Supports optional file-level retention services through add-on software.
    KDC
    88
    • Key Distribution Center. Kerberos server that delivers Kerberos tickets to connect to Kerberos services.
    Backup and restore
    • NDMP security can be implemented based on NDMP shared secrets.