Encryption of Data at Rest

Encryption of the Data at Rest with FIPS certified Veritas Cryptographic Module

Product: Veritas™ InfoScale 7.1

Do I really need encryption?

It was 4 AM in the morning and my friend, the owner of a well know HR firm, was fast asleep, when his phone buzzed. He took the call reluctantly, but was quite perturbed by what he heard and the very next moment he rushed to his office. There was a burglary at his office and he learned that the hard disks from two terminals were stolen! The admin was quiet, but his colleague consoled my friend saying there was no reason to worry as backups were available. My friend shouted back at him... Why? Was he worried about the cost of the stolen hardware? No. My friend was worried about the contents in those media available in plain text. He knew it very well, that the cost of the physical media is nothing in comparison to the data contained within.

My friend’s story could be my story, your story or the story of any enterprise customer! Businesses today generate a lot of data, finally making its way into the data center. With the release of InfoScale 7.1, Veritas has come up with a solution for securing the data at rest for its Banking & Finance, HealthCare, Federal govt. customers, and any customer per se for which data is of utmost value. 

We can help

Veritas™ InfoScale 7.1 introduces a capability where the administrators will have an option to encrypt the volume data. A volume can be created as encrypted and the default is non-encrypted. Once a volume is designated as encrypted, any data that goes into it is encrypted. Its working is quite simple. All the IOs going to an encrypted volume are sent through the Veritas Cryptographic Module, which encrypts the IO after which it is written to the disk. Now, even if the disk falls into some unscrupulous hands, the data is still safe! The Veritas Cryptographic Module is FIPS 140-2 certified.

What’s new?

In order to create an encrypted volume, we need to provide and additional option ‘encrypted=on’. It will ask for a passphrase, the admin needs to provide that and confirm the same.

 

# vxassist -g dg make vol1 100m encrypted=on

Enter password for volume vol1:
Confirm password for volume vol1:

 

Apart from volumes, there is an option to create encrypted disk groups as well. An encrypted disk group essentially means that all the volumes created within are encrypted by default; the ‘encrypted=on’ option can be ignored. All the volumes in a disk group can have different passwords. The steps to create an encrypted disk group and a volume in it are as follows,

  • Create the encrypted disk group
# vxdg -o encrypted=on init encdg sdd sde
  • Create volume
# vxassist -g encdg make vol1 100m

Enter password for volume vol1:
Confirm password for volume vol1:

The volume was created as an encrypted one by default, so it asks for the password.

A new CLI called vxencrypt has been introduced for encryption. It is used to list down all the disk groups and volumes. A sample output would look like the one below,

# vxencrypt list

Disk group: dg

    VOLUME          STATUS
    vol1            encrypted with password

Disk group: encdg (encrypted by default)

    VOLUME          STATUS
    vol1            encrypted with password

Can’t we automate it?

Creating volumes and remembering-keying in the passwords for a number of volumes can become quite tedious. But InfoScale has a solution for that! InfoScale can integrate with any third party KMIP compliant Key Management Server(KMS) for the host authentication. Once a KMS client is configured on a node, the certificates on that node are used to communicate with the Server for authentication. Thus, with a KMS configured in the environment, creation of an encrypted volume won’t prompt for a password. Instead, now the certificates would be used internally for the authentication. Admins do not require remembering any password. With the KMS in place, this is how the encrypted volume creation would look like,

# vxdg init kmsdg sdb sdc
# vxassist -g dg make vol2 100m encrypted=on

The above command didn’t prompt for a password, as the host was authenticated by the KMS. If you refer to the output of ‘vxencrypt list’ below you would notice that the status of vol2 is encrypted and not ‘encrypted with password’ as it was in the previous case. This is because we did not explicitly provide a password while creating the vol2 for kmsdg since a KMS was configured.

# vxencrypt list

Disk group: kmsdg

    VOLUME          STATUS
    vol2            encrypted

Although, encryption works well with both the password and the KMS based approaches, we encourage the customers to go with the latter, wherever possible. The biggest caveat that comes with the password based approach is that the admin needs to manually key in the password for the volume, when it starts. However, with the KMS based approach password feeding is seamless, and it provides a great user experience.

Caveats

As a first version supporting interaction with KMS solutions, there are two important things regarding the usage of KMS. The first one is that if we have a third party KMS, then the KMS client must be configured in all the nodes of the cluster. InfoScale only checks the availability of a KMS solution and it doesn’t look into the working of the KMS. Absence of KMS even in one of the nodes, may give rise to erratic behaviors. So, either it is all or none. The second point is that, it is the responsibility of the administrator to make sure that the all the nodes communicate with the same KMS server. Right now, we do not support the multiple KMS authentication within a cluster. The figure below illustrates this point.

KMS_sceanrios.png

                                Figure 1                                                                           Figure 2

Figure 1 above refers to a scenario, where there are 3 nodes in a cluster. 2 nodes are interacting with ‘KMS 1’ and the third node is interacting with a second KMS, namely ‘KMS 2’. This is not a recommended configuration for clusters opting for Encryption with InfoScale managed storage. On the other hand Figure 2 has a 3 node cluster, all interacting with the same KMS. Either all the nodes have the KMS client configured or none and only one KMS to be used for a single cluster.

Summary

Veritas InfoScale 7.1 product series enables enterprises to encrypt the data at rest thereby maintaining the confidentiality of the data. Its FIPS 140-2 certification helps in complying with the government standards and adhering to the company or industry policies. Please refer to the certification on the NIST site http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2016.htm for further details on FIPS. InfoScale supports all the KMIP(1.0, 1.1 and 1.2) compliant KMS servers which would make the integration of InfoScale in the KMS environment easy.