Skip to main content
Sign Out

Welcome to Dell

My Account
  • Place orders quickly and easily
  • View orders and track your shipping status
  • Enjoy members-only rewards and discounts
  • Create and access a list of your products
  • Manage your Dell EMC sites, products, and product-level contacts using Company Administration.
Sign In Create an Account Dell Financial Services Premier Sign In Partner Program Sign In
Contact Us

Your Dell.com Carts

EMC® VNX® Series Security Configuration Guide for VNX

PDF

Data in place upgrade

To encrypt a system with a data in place upgrade, the system must read the entire contents of the set of disk drives incrementally, then write those contents back to the drives. The keying process will consume some percentage of the system cache. It will also consume a non trivial amount of system performance. This operation is scaled based on the I/O load of the system.

Upon activation, through either the Unisphere UI or the VNX for block securedata -feature -activate CLI command, the system will begin performing encryption operations. Data that is written before encryption is enabled is written in unencrypted form and will be encrypted later by the background encryption operation. This only occurs during the initial upgrade process. For any RAID group (RG) that is created after encryption is enabled, all data written to the RG will be encrypted.

When encryption is enabled, a key encryption key (KEK) will be generated as well as DEKs for all of the disk drives of the existing RAID groups. The system will begin the process of encrypting the existing data by reading the data, a stripe at a time, in unencrypted form and re-writing the data in encrypted form.

Certain conditions will delay or halt the data in place upgrade including:

  • RG zeroing in progress
  • RG rebuild in progress
  • RG verify in progress
  • Cache unavailable

The system will otherwise continue to operate normally, including encryption of already encrypted space on the drive.

NOTE: EMC strongly recommends enabling encryption prior to writing any data on the array or migrate to an array that has encryption already enabled. A sanitize operation is not performed on an HDD or SSD that is undergoing a data in place upgrade. 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 encrypted. This data is not readily retrievable through standard interfaces, but may be accessible through other means. If D@RE must be enabled through a data in place upgrade and if you prohibit unencrypted data, you will have to mitigate manually. For information concerning sanitization, refer to the latest version of the NIST publication, Guidelines for Media Sanitization, at http://csrc.nist.gov/.

Some unencrypted data could be in the system partition (for example, hostnames, IP addresses, dumps, and so on). 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).

If your security or compliance policies require sanitized drives, EMC recommends that after completing the data in place upgrade, you should migrate the encrypted data to a new or previously sanitized set of drives. One option to relocate the data is to use the MCx copy-to function, which is available through either Unisphere or the VNX for block CLI. This will move all the encrypted data from one disk drive to another drive of the same or larger capacity. After the MCx copy-to operation completes, perform your sanitization procedure on the original drive, which can then be returned to the system for reuse, if desired.

Special consideration for vault drives

If LUN or file system data exist on the vault drives (the first four drives) of the VNX after the data migration, you need to take special steps to replace those drives. Migrate the LUNs to another set of drives then insert a new, unused, compatible drive into position 0_0_0 and allow the system to fully rebuild the drive contents. This process should take less than an hour to complete. You need to repeat this procedure for each of the remaining three drives (positions 0_0_1, 0_0_2, and 0_0_3) ensuring that the rebuild is complete before proceeding to the next drive. After the drives have been replaced, you can migrate the LUNs back to the vault drives and then perform your sanitization procedure on the original drives.

Special consideration for FAST Cache

FAST Cache must be destroyed before activating encryption. If your security policy requires special sanitize procedures, you should appropriately sanitize the FAST Cache drives after the FAST Cache is destroyed and before you re-enable it. FAST Cache can be re-enabled as soon as the encryption activation process completes.

If SSD hot spares are being used only for FAST Cache, you can sanitize those SSD hot spares immediately.

NOTE:If a SSD will also be used as a storage pool or RG hot spare, plaintext data may be written to it if it is for a rebuild during a data in place upgrade. If you prohibit unencrypted data, you will have to mitigate manually. For this reason, leave sanitization of these hot spares until after the data in place upgrade completes.

Rate this content

Accurate
Useful
Easy to understand
Was this article helpful?
0/3000 characters
  Please provide ratings (1-5 stars).
  Please provide ratings (1-5 stars).
  Please provide ratings (1-5 stars).
  Please select whether the article was helpful or not.
  Comments cannot contain these special characters: <>()\