NetBackup Encryption and Key Management Solutions.pdf

This document is provided for informational purposes only. All warranties relating to the information in this document, either express or implied, are disclaimed to the maximum extent allowed by law. The information in this document is subject to change without notice. Copyright 2013 Symantec Corporation. All rights reserved. Symantec, the Symantec logo and NetBackup are trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S. and other countries. Other names may be trademarks of their respective owners

NetBackup Whitepaper

NetBackup Encryption and Key

Management Solutions This document discusses the various options available for data encryption in NetBackup and compares the benefits of each option.

If you have any feedback or questions about this document please email them to [email protected] stating the document title.

This document applies to the following versions of NetBackup: 7.0, 7.1, 7.5 and 7.6

NetBackup Whitepaper Encryption and Key Management Solutions

i

Document Control

Contributors

Who Contribution

Don Peterson Author

Revision History

Version Date Changes

1.0 28th February 2013

Table of Contents

Why Encryption 1

Overview of Encryption 1

NetBackup Client Encryption (CE) 3

Operation 3

Benefits 4

Limitations 4

Performance Considerations 4

NetBackup Media Server Encryption Option (MSEO) 5

Operation 5

Basic Functionality 6

Benefits 6

Limitations 7


NetBackup Key Management Service (KMS) 8

Operation 8

Encrypting data on tape 9

Encrypting data to Cloud Storage 9


ii

Encrypting data to AdvancedDisk Storage 10

Key States 10

Benefits 11

Limitations 11


NetBackup Deduplication Encryption 12

FIPS 140-2 Validation 12

Appendices

APPENDIX A Comparison tables

APPENDIX B Related documents


Page 1

Why Encryption

Many customers send their backup data on tape media to an off-site storage facility. When tape media is transported from one site to another, there is the possibility of the tape being lost or stolen. If this occurs, and confidential customer data is on those tapes, the company may have to notify all customers, whose confidential data is at risk. This can cost a million dollars or more. Even very reputable companies like Iron Mountain have been known to lose tapes they were transporting from a customer location to their storage facilities.

When data is encrypted it is unreadable unless the proper key for decrypting the data is available. Therefore, when encrypted backup tapes go missing there is no risk they can be read by unauthorized persons. Having data encrypted avoids the need for a company to notify customers of their confidential data being at risk if the tapes the data is on are lost. It also avoids potential lawsuits if that data was compromised (i.e., was not encrypted) and the adverse publicity associated with the loss of confidential data, which can also affect the companys stock price.

Industry regulations such as Sarbanes Oxley, HIPPA and PCI are also driving companies to more securely protect confidential data.

Confidentiality of data at off-site storage, whether it is tape media sent off-site or backups to the cloud storage, is a major security concern of most companies today. However, notebook computers often have a great deal of proprietary information on them, whether it is customer data or internal company data. Cell phones, tablets, and USB drives also contain company data, which is confidential. These are all considered different end points for potential encryption.

In addition, deduplication has caused a dramatic increase in the use of disk as a backup target. Companies often want to make a duplicate copy of that backup data at another location. Encrypting the data while it is duplicated or replicated from one site to another site and while at rest at the second site is gaining interest. Companies are also becoming concerned about the security of their primary storage and are looking to encrypt that data as well.

Overview of Encryption

There are six main requirements for an enterprise level encryption and key management solution.

1. Keys for encrypting and decrypting data.

2. A key manager that is used to generate and store the keys and manage the key lifecycle process

3. A method to backup, duplicate, replicate and/or export/import keys.

4. An encryption/decryption engine. This can be in software, hardware or a combination of the two.

5. A distribution method for providing keys from the key store to the encryption engine. For example, the SCSI T10 spec determines how keys are passed between an application and the tape drive.

6. A policy management engine that allows the administrator to specify which data gets encrypted.

In addition, a data/capacity reduction engine such as compression or deduplication is typically required to minimize storage cost. Because encryption randomizes the data, if data is not compressed or


Page 2

deduplicated prior to encryption, much more storage space would be required to store the data. This can be software or hardware based, but must be performed prior to encrypting the data.

Two different types of encryption are commonly used.

1. Symmetric encryption the same key is used to both encrypt and decrypt the data

2. Asymmetric encryption a public/private key pair is used where the public key is used for encryption and the private key is used for decryption

The NetBackup Client Encryption and KMS solutions both use symmetric encryption, where the same key is used to both encrypt and decrypt the data. The encryption key is not stored on the tape or disk, but a unique identifier to the encryption key is stored on the media. MSEO uses a combination of symmetric and asymmetric encryption in which the same key is used to encrypt and decrypt the data. The encryption key is encrypted by a public key and stored on the tape and decrypted by a private key in order to be used to decrypt the data.

The NetBackup Key Management Service (KMS) allows an administrator to create keys. The KMS then automatically generates a unique identifier for that particular key. Keys can be created using either a random number or a pass phrase. If a pass phrase is used and a copy is stored somewhere that pass phrase can be used to regenerate an identical key if the original key is lost. If a random number generator is used to create a key, if that key is lost, the original key cannot be regenerated and any data encrypted by that key cannot be restored. Realistically, electronic keys arent typically lost, but may expire or are deleted.

Key stores are typically encrypted (keys are not stored in clear text) for security. In talking with backup administrators for large enterprise customers, most believe their companys security organization will specify where keys must be stored. In other words, most large companies wont want to have an assortment of key stores for different end points.

The Key Management Interoperability Protocol (KMIP) allows integration between hosts and clients, enabling different key management systems and/or encryption engines to communicate such that all keys used throughout various end points could be stored (and possibly created) by a single key management system.

When NetBackup sends keys from KMS on the master server to the media server, they are encrypted if NetBackup Access Control (NBAC) is enabled. If NBAC is not enabled, the keys are sent in clear text.

Note: Clear-text does not mean the encryption keys are human readable. They are a binary representation of the encryption key, which for AES would be 256 bits.

When sending keys from the key store to the encryption engine, the best security practice would be to transmit those keys in an encrypted fashion, not in clear text. However, few customers are concerned about the lack of encryption across FC. The SCSI T10 encryption specification has been updated to enable encrypting the keys within the SCSI protocol and some of the new LTO6 drives will be implementing this functionality. However, this requires the use of asymmetric encryption (public/private key pair), which the NetBackup KMS does not support.

The policy engine for key management determines which data gets encrypted. This can be very simplistic, such as all data being sent to a particular tape drive. However, most solutions offer some amount of flexibility in allowing the customer different options in terms of which data gets encrypted. This also needs to be relatively easy to configure.


Page 3

Because losing keys means data cannot be recovered, its very important to have a method(s) to backup/restore or export/import the key store and encryption keys. Some solutions allow a normal backup and restore process to be used. Other solutions provide an export/import functionality to accomplish this or to copy keys from one key manager to another to provide redundancy and/or disaster recovery capability.

NetBackup Client Encryption (CE)

NetBackup Client Encryption has been available for over a decade and has been enhanced with greater encryption strengths as they have become available. It is supported on all NetBackup releases and with all NetBackup clients other than those listed under Limitations below. It was included as part of the standard Client license beginning with NetBackup 6.5.

By compressing data on the client, less LAN bandwidth is consumed transferring the data to the media server. By encrypting data on the client, the confidentiality of the data is secured from the client to the storage. Customers concerned with sending data in clear text across the LAN from the NetBackup client to the media server should consider this solution. Data remains encrypted as it is transferred across SCSI or FC from the media server to the storage. Client Encryption can be used to encrypt data written to both tape and disk.

Operation

Key management for client encryption is quite basic. Each client manages its own keys, so encrypting backups coming from a large number of clients means managing a lot of independent key files.

Keys are created via the CLI, using a pass phrase. The pass phrase should be written down (or typed) and stored/saved somewhere, in case something happens to the key file. The keys within the key file are encrypted. An unencrypted copy of the key file should be backed up in case the client system, where the key file resides, dies. As long as the pass phrases used to generate the keys are known, the key file can be regenerated if it was not backed up. Using pass phrases allows generating a key file on Client B to restore encrypted data backed up from Client A, by creating a key using the same pass phrase. You can also copy (or restore a backed up copy of) the Client A key file to Client B in order to restore files encrypted by Client A to Client B. The CE software must be installed on Client B to do this.

CE uses the most recently generated key to encrypt the data, while all keys can be used for restores. A unique identifier, based on the checksum of the encryption key and the specified cipher (e.g., AES256), is stored in the key file and on the tape. NetBackup reads this identifier off the tape during the restore and sends it to the client. The client matches the identifier to the appropriate encryption key and uses the encryption key to decrypt the data.

Compression should always be performed on the client along with encryption. This is performed prior to encryption as encryption randomizes the data and would prevent compression (or deduplication) from reducing the amount of data to be stored. This minimizes the amount of data transferred from the client to the media server (which frees up LAN bandwidth) as well as minimizing the amount of tape media or disk space required.

Because CE does the compression and encryption in software, there will be additional CPU overhead and some performance penalty when using this functionality. The CPU overhead will be related to the amount of data being compressed and encrypted, but because most clients dont transfer huge amounts


Page 4

of data at high speeds, impact on the overall backup process may be acceptable. The CPU overhead will likely be something on the order of 70-80 clock cycles per byte of data being compressed and encrypted.

Compression and encryption are enabled on the Client by checking the compression and encryption boxes in the Attributes tab of the Policy configuration screen.

CE has added greater encryption strengths over time. Today, it supports both 128-bit and 256-bit AES encryption.

Benefits

Supported on all NetBackup releases and with all NetBackup clients other than those listed under Limitations below

Included as part for the standard Client license beginning with NetBackup 6.5

Less LAN bandwidth is consumed transferring the data to the media server.

Confidentiality of the data is secured from the client to the drive.

Can be used to encrypt data written to both tape and disk

Keys are generated using pass phrases, so even if the key file is destroyed, as long as pass phrases are known the key file can be regenerated.

Limitations

Not supported on NetWare and VMS clients

Not supported with BMR

Not supported with the SAN Client

Not supported with NetBackup Accelerator

Not support with Client-side deduplication

Compression and encryption performed in software, which will consume CPU cycles on the client machine

Key management is on each client (not centralized)

Keys are only generated using pass phrases, which does not maximize security as they can be regenerated (keys generated using a random number generator cannot be regenerated).

Performance Considerations

Client compression/encryption consumes CPU overhead, so you must make certain this overhead does not adversely impact the applications running on the server. The fact that this overhead will also limit performance is not a major issue if the client is sending data to a media server for backup. However, if the client is on a SAN media server, the impact on performance could be such that it cannot keep a tape drive streaming, which could adversely affect performance. If the backup is sent to a media server for writing to tape, multiplexing of backup images could be used to make certain the tape drives are used efficiently. If CE is used for backups to a VTL or to disk, the speed is of less importance unless too many jobs are being run concurrently, resulting in a great deal of disk thrashing.


Page 5

NetBackup Media Server Encryption Option (MSEO)

NetBackup MSEO was released in 2007 and is a software-based solution that performs compression and encryption on the media server. This off-loads the NetBackup client from having to perform these tasks. Because many NetBackup clients are running applications, consuming client CPU cycles for compression and encryption may not be desirable. MSEO moves the CPU overhead for software compression and encryption to the media server.

There are two MSEO software components, which are separately licensed. One is the MSEO Media Server agent, which is priced the same as a NetBackup Media Server or San Media server license on which the MSEO agent is installed. The MSEO Media Server Agent includes a license key that must be entered on each NetBackup media server configured with MSEO tape drives. The MSEO agent software verifies the NetBackup MSEO license bit is enabled before it will transfer any data (encrypted or unencrypted) to an MSEO-configured tape drive.

The second component is the MSEO Key Management Server (KMS), which is installed on what is referred to as the MSEO Security Server.

Note: The NetBackup KMS (Key Management Service) has no relationship to the MSEO KMS. A MSEO KMS license is NOT required to use the NetBackup KMS.

Operation

The MSEO KMS software on the Security Server provides centralized key management and the encryption policy engine. The KMS software is installed on the Security Server, which can be a system running NetBackup (typically this would be the master server because if the master goes down backups and restores wont be able to performed anyway) or a completely separate system running a supported MSEO operating system. A single MSEO Security Server can manage keys for one or many NetBackup domains. You can also configure redundant MSEO Security Servers for high availability.

The second component is the MSEO agent, which is installed on each NetBackup media server, which will be used to compress and encrypt backup images being written to tape. At a high level, the MSEO media server agent includes a Virtual Tape Driver and is inserted transparently between the NetBackup bptm daemon and the native/physical tape driver on a media server and performs compression and encryption. Once installed, MSEO is transparent to all normal NetBackup operations, which means the entire backup process remains the same as before installing MSEO. Compression and encryption take place through the MSEO Virtual Tape Driver.

MSEO uses a combination of symmetric and asymmetric encryption. Initially, a Public/Private Key pair is created. Every time a new backup job requiring encryption is run, an Encryption Key is created and sent to the media server, where it is used to encrypt the data being backed up. The Public Key is used to encrypt the Encryption Key, which is then written on the tape along with the encrypted data and a hash of the Public Key. When a restore needs to be performed, the hash of the Public Key is read from tape by the MSEO media server agent and forwarded to the MSEO Security Server. The MSEO Security Server uses the Public Key hash to determine which Public Key was used for encrypting the Encryption Key. It then sends the corresponding Private Key (from the Public/Private Key pair) to the MSEO media server agent. The MSEO media server agent uses the Private Key to decrypt the Encryption Key, and then uses the Encryption Key to decrypt the data before sending on the data to the bptm daemon. The encrypted Encryption Key is stored only on the tape, not in the MSEO Security Server.


Page 6

MSEO provides a variety of compression and encryption algorithms to use. These can be specified using Key Words in the in the Attributes tab of the NetBackup Policy configuration screen or by defining them in rules configured through the MSEO Security Server Console.

MSEO provides an Export/Import feature to copy keys from one MSEO Security Server to another MSEO Security Server. This can be a subset of the keys within the MSEO Security Server. The Export/Import feature of MSEO can also be used to backup the Security Server. You can use NetBackup to backup the appropriate directories and files used in the Export operation. However, the Import operation requires files be put in a different directory, so you CANNOT use a standard NetBackup restore operation to rebuild the Security Server. There are some manual operations that are covered in the MSEO System Administration Guide. If you attempt to use a standard NetBackup restore operation to rebuild a MSEO Security Server, it will corrupt the keys and you will not be able to restore any backup images previously encrypted.

Because MSEO performs compression and encryption in software, there must be enough CPU cycles available to obtain acceptable performance. In analyzing the impact of MSEO on the media server, a ballpark estimate indicates roughly 70-90 CPU cycles are required per BYTE of data backed up on Windows/Linux and UNIX media servers respectively.

Basic Functionality

Initially supported on NetBackup 5.1 MP3 and was supported on all NetBackup 6.0 and 6.5 versions. Now supported on all NetBackup 7.x versions

Supports encrypting backups to most physical tape drives supported by NetBackup (see NetBackup HCL for specifics) and VTLs

Supports encrypting backups to most tape drives

Supported on Solaris 9 and 10 SPARC and x64, Red Hat Linux 4 and 5, SUSE 10 and 11, Windows 2003 x86 and x64 and Windows 2008 x64

MSEO Key Management Software can be installed on a NetBackup system (typically master server) or a completely separate system. This software/system is referred to as the MSEO Security Server.

OpenSSL is used to encrypt communication and keys transferred between MSEO media server agents and the MSEO Security Server

MSEO Security Server Console allows configuring encryption policies

Benefits

Off-loads NetBackup client from having to perform compression and encryption

Security Server can manage keys for multiple NetBackup domains

Export/Import feature for Key Management allows easily duplicating all keys (or a subset) to a second Security Server to provide redundancy and high availability

Much granularity in specifying which data is compressed and encrypted

MSEO media server agent is FIPS 140-2 certified


Page 7

Limitations

Cannot use standard NetBackup backups and restores for protecting the keys; you must use the Export/Import functionality of MSEO

Must have a enough CPU cycles on media server(s) to handle the amount of data being backed up

Because MSEO compresses the data, it may be difficult to keep the newer, fast tape drives streaming even at their minimum date rate unless the media server has enough CPU GHz to support the drives data rates.

Not supported on AIX and HP-UX OS platforms and no plans to do so.

Transparent to NetBackup, so verifying what has been encrypted must be performed through MSEO.


The MSEO driver is multithreaded and the software has been tuned for multiple drive environments to be able to utilize all of the multiple CPUs processing power.

However, with faster tape drives, you can easily run into a CPU bottleneck if you dont carefully analyze the backup environment. It takes roughly 70 more clock cycles on a Windows or Linux server or about 90 more clock cycles on UNIX server to perform MSEO compression/encryption per BYTE of data backed up. Backing up 100 MB/sec of data through a Solaris media server requires about 9 GHz of CPU processing for MSEO, plus whatever processing is needed for other tasks.

Although the number of clock cycles used for regular, unencrypted backups may vary from media server to media server this represents a significant increase in all cases. Deploying MSEO on an existing infrastructure may result in the throughput dropping dramatically and it may be necessary to reduce the number of tape drives per media server and deploy additional media servers to achieve the same throughput. Adding HBAs to a media server to get additional throughput doesnt just work when software compression/encryption is used.

To determine the impact of deploying MSEO encryption, first determine how much data must be backed up and the length of the backup window. This determines the minimum required sustained data rate to complete the backup in the allotted time frame. Allow an additional 10% for tape mounts and load times. Multiplying that data rate in GB/sec by 70 or 90 CPU cycles/byte determines the CPU GHz required for MSEO compression/encryption. For example, if the backup window is 8 hours and the amount of data to be backed up is 2.5 TB, the sustained data rate is around 91 MB/sec. Allowing for tape mounts and load times raises this to around 100 MB/sec, requiring between 7 GHz and 9 GHz of CPU on the media server depending on the operating system used.

While smaller volumes of data and longer backup windows may require less CPU cycles, it is also important to consider the tape technology being used. All tape drives have a minimum data rate at which they must receive data in order to keep the media streaming. If the incoming data rate drops below the minimum speed, the drive will stop the media, rewind it to the proper location, then resume the data transfer to the media. This stop, rewind, restart process is referred to as shoe-shining and adversely impacts overall data throughput.

You must take into account how much MSEO is able to compress the data. For example, if MSEO can compress the data 2:1, and the minimum streaming speed of a tape drive is 30 MB/sec, MSEO will need


Page 8

to compress and encrypt data at 60 MB/sec to keep the tape steaming. This means a minimum of 4.2 GHz of CPU for Windows or Linux 5.4 GHz of CPU for UNIX for each tape drive, just to keep the drive streaming at its minimum rate, which still isnt using the tape drive efficiently.

For IBM LTO tape drives, Digital Speed Matching (to maintain streaming operation) is provided at specific transfer rates, with the minimum being 50% of the native rate for LTO2 and LTO3 drives, 28% for LTO5 drives and 25% for LTO4 and LTO6 drives.

For HP LTO tape drives, the drive can maintain streaming down to 1/3 the native transfer rate. HP refers to this as data rate matching. Below that limit, the drive will stop streaming. Between the upper and lower limits, the drive will adjust performance automatically, on-the-fly.

One way to reduce MSEOs CPU impact is to use the NetBackup client to perform the compression. This will obviously impact the client CPU, but if there is available bandwidth on the client, it would likely reduce the MSEO overhead by about 60%. Compressing the client data also means less data will be sent across the LAN from the client to the media server freeing up LAN bandwidth.

In summary, using faster tape drives and making efficient use of them requires adequate CPU GHz in the media server.

A MSEO performance calculator is available and provides performance estimates based on OS platform, number of CPUs/cores and speed, tape drive vendor and drive type, number of tape drives per media server and amount of data to be backed up.

NetBackup Key Management Service (KMS)

The NetBackup Key Management Service (KMS) was introduced in the NetBackup 6.5.2 release and initially managed encryption keys for tape drives supporting the SCSI T10 encryption standard. Today, this includes all LTO4, LTO5 and LTO6 tape drives, IBM TS1120/30/40 tape drives and Oracle T10000B/C tape drives.

The key store for KMS is located on the master server and manages keys within a single NetBackup domain. The Key Store can be installed on any OS platform supported by NetBackup as a master server. Any OS platform supported by NetBackup as a media server can be used to backup data to one of the supported tape drives. The KMS is included with the Enterprise Server and Server licenses and is no additional charge.

In NetBackup 7.1, an OST encryption plug-in was added to the NetBackup media server. The OST plug-in obtains keys from the NetBackup KMS to encrypt data (using AES256 encryption) being sent to cloud storage pools. In NetBackup 7.5, this same encryption capability was added for backups to AdvancedDisk storage pools.

Operation

The NetBackup KMS runs on the master server and manages encryption keys for tape drives with embedded encryption and the NetBackup OST plug-in encryption engine. The Key Store on the master server contains Key Records. Each Key Record consists of an encryption key, a unique identifier for that key, and metadata (e.g., date key was created, status of the key, description for the key, etc.). All encryption keys in the Key Store are encrypted with a Key Protection Key (KPK) and the entire Key Store is encrypted with a Host Master Key (HMK). Both of these keys are AES256.


Page 9

The Key Store is initially created using the NetBackup CLI. The administrator is then requested to enter either a pass phrase or allow a random number generator to be used to create the Host Master Key. An additional request is made to create the Key Protection Key. It is recommended that these two keys be created using pass phrases. That way, if these keys are lost, both keys can be recreated to decrypt the KMS Key Store.

When a cloud storage pool is being created, a wizard pops up and allows the initial creation of the KMS key store if it has not already been created. This includes generating the HMK and KPK keys, and a key group and encryption key for the cloud storage pool. More details on this can be found in the Encrypting data to Cloud Storage section of this document.

Encrypting data on tape

Once a key store has been created, a Key Group is then created using the NetBackup CLI. When used with tape, the Key Group must have an ENCR prefix. Because NetBackup will use the tape drive to encrypt any data written to media in a volume pool with an ENCR prefix, a NetBackup volume pool must be created with the name matching the Key Group name. Once this is completed, the NetBackup CLI is used to create an encryption key. A pass phrase or random number can be used to generate encryption keys, like is done for the KPK and HMK. Once the encryption key has been created, NetBackup generates a Key Tag (256 bits, 64 characters), which is the unique identifier for that encryption key. If a pass phrase is used for the encryption key, as long as the pass phrase and key tag are known, an identical encryption key can be created in case something happens to the Key Store or encryption key.

Note: When a random number generator is used to generate an encryption key, if the key is lost or deleted, data encrypted by that key can NEVER be restored.

The SCSI T10 encryption standard requires a KAD (Key Associated Data), which is a unique identifier for an encryption key, to be written on the tape along with the encrypted data. NetBackup uses the Key Tag as this unique identifier if the tape drive supports a 256-bit KAD; otherwise the key Tag is truncated to the appropriate length.

When the backup image is to be encrypted, the NetBackup media server obtains the active encryption key and KAD for the volume pool being used (which has a corresponding Key Group) from the master server. The media server sends the encryption key, KAD and data to the tape drive, which uses the encryption key to encrypt the data and also writes the KAD onto the tape.

If this backup image or individual files need to be restored, the NetBackup media server requests the KAD from the tape drive and sends this to the KMS on the master server. The KMS looks up the encryption key corresponding to the KAD and sends this to the media server, which passes it to the drive. The drive then uses the encryption key to decrypt the data and send it to the media server.

Encrypting data to Cloud Storage

The KMS can be used along with the OST encryption plug-in on the media server to encrypt data going to cloud storage. Each Cloud storage target used for NetBackup storage requires a key group. KMS requires a unique name for each key group, using the format: cloud_provider_url:volume_name. For example, nirvanix.com:filesystembackups

When configuring cloud storage, the cloud_storage_server_stype defines the storage type and storage vendor. The vendor is the name of the cloud provider. The storage type is either encrypted or not


Page 10

encrypted. For example use nirvanix_raw to not encrypt the data and nirvanix_encrypt to encrypt the data.

If the Key Management Service (KMS) is not already configured, the Cloud Storage Server Configuration Wizard includes steps to create and enable KMS. The command line can also be used to configure KMS.

When adding (configuring) cloud volumes, the option of using a single pass phrase (a single encryption key) for each volume or the same pass phrase for all volumes must be selected. Depending on the option chosen, a pass phrase will need to be entered when adding only the first volume or when each volume is added.

Cloud storage can also be configured using the nbdevconfig command. More detail on this can be

found in both the NetBackup Cloud Administrator Guide and the NetBackup Commands Reference Guide.

The NetBackup Security and Encryption Guide has a great deal of additional information on the NetBackup KMS in the chapter titled Data at rest key management.

Encrypting data to AdvancedDisk Storage

The NetBackup KMS can be used along with the OST encryption plug-in on the media server to encrypt data going to AdvancedDisk storage.

To use encryption, the AdvancedDisk_crypt type must be used when configuring the storage servers and the disk pools. The nbdevconfig command must be used to configure the storage servers and the disk pools.

Each storage server and volume combination requires a key group. The key group name is of the following format: storage_server_name:volume_name. The volume_name must be the last directory name in the pathname to the volume.

More details can be found in the NetBackup AdvancedDisk Storage Solutions Guide. The NetBackup Security and Encryption Guide has a great deal of additional information on the NetBackup KMS in the chapter titled Data at rest key management.

Key States

The NetBackup KMS supports a number of states for encryption keys. When encryption keys are created they can be put into a Prelive or Active state. In an Active state, the encryption key will be used for any backup jobs specifying that volume pool or name. The Prelive state would be used if a customer wants to periodically change keys. A script could be written that automatically changes an encryption key in a Prelive state to the Active state. When a new key is moved to an Active state, the existing key is moved to an Inactive state. A key in an Inactive state is only used for restores. An encryption key can also be moved to a Deprecated state. In this state it cannot be used for either backups or restores. This might be done to prevent restoring specific backup jobs without some type of approval. Encryption keys can be moved between Active, Inactive and Deprecated states. The final state is called Terminated, in which the encryption key is placed to delete the key. Once the key is deleted, no data encrypted with that key can be restored unless a pass phrase was used to generate the encryption key and both the pass phrase and the Key Tag are a known.

The NetBackup KMS should be backed up. It is not part of the NetBackup catalog backup, but it would be wise to backup the three KMS files with the catalog. A KMS backup consists of three files: the KMS


Page 11

database, the HMK file and the KPK file. The KMS database should be backed up to a different tape than the HMK and KPK files; otherwise someone obtaining the tape would have access to all the encryption keys. You should not encrypt the backup of the KMS files as this is the equivalent of locking the keys in the safe and modern cryptography doesnt allow picking the lock. Before being backed up, the KMS database should be quiesced using the NetBackup CLI. It can be unquiesced once the backup is completed. Because the database only changes when Key Groups or encryption keys are created or attributes are changed, quiescing the database does not affect the ability to encrypt backup jobs or restore encrypted backup images.

The Key Store can be copied from one master server to another by using a backup/restore operation or just copying the three files.

Benefits

Centralized Key Store for a NetBackup domain

Compression and encryption performed by tape drive, so no performance degradation or impact on media server CPU

Encrypts data to cloud and AdvancedDisk storage pools

Free functionality with NetBackup 6.5.2 and later

KMS can be used on all supported NetBackup master server platforms and all supported media server platforms can write to encrypted tape drives

Limitations

Maximum of 20 Key Groups (ability to encrypt a total of 20 volume and/or disk pools) with 10 encryption keys per group (note: In NetBackup 7.6, a maximum number of 100 key groups will be supported.)

No export/import functionality

All management performed via NetBackup CLI unless Cloud storage is the backup target

Encryption keys encrypted when transferred from master server to media server only if NetBackup Access Control (NBAC) is used

OST encryption plug-in supports on encryption, not compression and will consume some CPU overhead for encrypting data cloud or AdvancedDisk storage pools.


Unlike MSEO, because compression and encryption are performed in hardware on the tape drive; using KMS does not result in performance degradation or CPU overhead on the media server.

For encryption to Cloud or AdvancedDisk storage, AES256 encryption is performed in software on the media server. This is likely to consume about 30 clock cycles per byte of data being encrypted, so that needs to be taken into account and to make certain there enough CPU processing power on the media server to handle the maximum data rate expected.


Page 12

NetBackup Deduplication Encryption

The various NetBackup deduplication methods, which include PDDO, MSDP and client-direct, all utilize the same encryption functionality.

Blowfish 128-bit encryption is used with all of these deduplication methods. The 128-bits are combined with a 128-bit hash to generate a 256-bit key, which is used for encrypting the data. Encryption keys are automatically generated for each unique data segment.

By default, deduplication encryption is disabled, however, Symantec recommends that you use deduplication encryption.

The following is the behavior for the encryption that occurs during the deduplication process:

If you enable encryption on a client that deduplicates its own data, the client encrypts the data before it sends it to the storage server. The data remains encrypted on the storage.

Data is transferred from the client over a Secure Sockets Layer to the server regardless of whether or not the data is encrypted. Therefore, data transferred from clients that do not encrypt their own data is also protected across the LAN.

If you enable encryption on a load-balancing server, the load-balancing server encrypts the data. It remains encrypted on storage.

If you enable encryption on the storage server, the storage server encrypts the data. It remains encrypted on storage. If the data is already encrypted, the storage server does not encrypt it.

Encryption is enabled on either the media server or client via the NetBackup CLI.

You can enable encryption on all hosts that deduplicate their own data without configuring them individually or you can enable encryption on individual hosts.

Keys are not managed as they are with CE, MSEO or the NetBackup KMS. This is because the deduplication software automatically generates keys for each new segment that is backed up (if encryption is enabled).

Specifics regarding Enabling deduplication encryption can be found in the section of that name,

beginning on page 87 of the Symantec NetBackup Deduplication Guide.

FIPS 140-2 Validation

The National Institute of Standards and Technology (NIST) FIPS is concerned with Information Technology security and has a Cryptographic Module Validation Program (CMVP) and allows vendors to obtain various levels of FIPS 140-2 validation for their cryptographic modules. Validation requires modules to use NIST approved cryptographic algorithms, hashes and random number generators. Vendors also specify the boundary of their implementation. Most validations for NetBackup would be for FIPS 140-2 Level 2 unless the NetBackup appliance were to be validated, which would be at a Level 3.

When this document was written, only the MSEO 6.1.0 media server drive (agent) had received FIPS validation. The NIST validation can be found at the following URL: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2008.htm

If you scroll down to Cert # 1057 on that page (they are in descending order), you will find the Vormetric listing for the MSEO driver. We license the MSEO software from Vormetric.


Page 13

In order for NetBackup to run in a FIPS 140-2 mode, the cryptographic primitives used in NetBackup client encryption, the NetBackup KMS, the OST encryption plug-in (used to encrypt data going to Cloud or AdvancedDisk storage pools) and NBAC will be updated use a crypto module that Symantec will have FIPS validated. This will result in a FIPS 140-2 validation certificate for Symantec for this crypto module.

The following tape drives, which provide encryption, have received FIPS validation:

Vendor Tape Drive NIST Certificate #

HP LTO-5 1486

IBM LTO-4 1152

IBM LTO-5 1522

Oracle T10000A 1157

Oracle T10000B 1156

Oracle T10000C 1561

Table 1 - FIPS validated tape drives

In addition to the crypto primitive, FIPS validation also considers hashes used (e.g., MD5 cannot be used, but SHA-2 can be) and the use of a FIPS validated random number generator when generating encryption keys (FIPS does not allow the use of only a pass phrase when generating encryption keys).

Because FIPS validation is performed on a specific version of hardware or software and on a specific operating system platform, if the version of hardware or software is changed or the operating system platform is changed, a previous validation does not apply to a newer version of the hardware or software.

Therefore, because any change to NetBackup, such as a new maintenance release, would cause NetBackup to no longer be considered FIPS validated, we are not planning to validate NetBackup as a whole. What we plan to do is validate the cryptographic module used within NetBackup.

We are working on updating NetBackup to use the updated crypto module and to enable NetBackup to run in FIPS mode. The initial implementation of FIPS mode will be for the NetBackup KMS with the conversion of other areas of NetBackup to FIPS mode in subsequent releases. The current process for getting FIPS validation takes about eight months, but once that process is underway (we will get a letter from the testing facility verifying that), NetBackup should be acceptable to customers from a FIPS validation standpoint.

NetBackup deduplication (PureDisk, MSDP and client direct deduplication) uses Blowfish 128 encryption, which is not a cryptographic primitive that can obtain FIPS validation. It has not yet been decided whether we will modify the deduplication software to obtain FIPS validation.

We are considering getting the NetBackup Master/Media server appliance FIPS validated in the future.

Customers have been using NetBackup to encrypt data for many years and this has included generating keys using pass phrases and using crypto primitives that cant obtain FIPS validation. NetBackup wont prevent customers from using pass phrases to create a key because they may need to recreate an older, non-FIPS key in order to recover old data created with that key.

APPENDIX A Comparison tables

The following tables compare various aspects of the different encryption solutions.

Client Encryption Media Server

Encryption Option KMS Managed

Encryption NetBackup

Deduplication

Encryption target Existing tape drives or disk

Non-encrypted tape drive focus

Encrypting tape drives, cloud and AdvancedDisk

Symantec deduplicating storage pool

Where is data encrypted?

In transit from client and on tape or disk

In transit from media server and on tape

On tape and disk and in transit from media server to disk

In transit and on disk

Encryption Software Software Hardware or software

Software

Key store/ manager

On each client Centralized across domains

Centralized on master server

N/A

O/S platform support

All standard clients

Solaris, Windows and Linux

All major platforms

All major platforms

Software cost Free Security server and each media server

Free Disk Protection Optimization Option

Table 2 - Key selection criteria

Location Client Encryption Media Server

Encryption Option KMS Managed Encryption

Key store Encryption Key (EK), checksum of EK and cipher used

Public key and private key

Encryption key and key tag (KAD)

Stored on tape

Checksum of EK and cipher used (in tar header)

Data encrypted by EK

EK encrypted with Public Key

Has of public key

Data encrypted by EK

KAD and data encrypted by EK

Stored on disk Checksum of EK and cipher used (in tar header)

N/A KAD as attribute and data encrypted by EK

Unique encryption key

Per client Per backup job Per tape or disk pool

Table 3 - What gets stored where?

Key management Encryption

Client Run bpkeyutil command to create key file and pass phrase

Specify encryption attribute in policy (also enable compression for tape backups)

Media Server Encryption Option

Create key pairs and encryption policies

Configure MSEO tape drives on media servers

KMS Tape Create KMS db, key groups and keys using CLI

Create volume pool with ENCR suffix matching key group name

KMS Cloud Use wizard to create KMS db and encryption key

Use wizard to create Storage Server and Storage Poll for encryption

KMS AdvancedDisk Create KMS db, key groups and keys using CLI

Use nbdevconfig to create Storage Server and Storage Poll for encryption

NetBackup Deduplication

None Enable via pd.conf on each host

Table 4 - Key management encryption configuration

Client Encryption Media Server Encryption

Option KMS Managed Encryption

Encryption key Per client Per backup job Per volume pool

Encryption policy basis

Per backup policy Various options including backup policy, client, media id, copy # and volume pool.

Per volume pool

Encryption (and compression) performed in:

Software Software Hardware

Table 5 - Encryption on tape

Client Encryption NetBackup

deduplication KMS Managed Encryption

Encryption key Per client Per segment Per storage pool

Encryption policy basis

Per client Per host (client or media server)

Per AdvancedDisk or cloud storage pool

Encryption (and compression) performed in:

Software Software Software

Table 6 - Encryption on disk

Table 7 Using Encryption and Key Management with NDMP

The NDMP spec does not support backups to disk from a NAS host, which is why there is an x in many cells.

MSEO can only be used when the data path is through the NetBackup media server, which means remote NDMP must be used.

KMS can also be used with:

Quantum VTLs supporting NDMP DirCpy functionality

OST Storage Servers listing Direct_Copy and KMS as supported functionality. As of the publication date, this included various Quantum and Fujitsu OST devices

Refer to the NetBackup Hardware Compatibility List for updated information

Direct Attach / Local

3-way (from one NAShost to another)

Remote (thru media server)

Encrypted tape drive NBU KMS NBU KMS NBU KMS

Tape drive w/o encryption or drive encryption not used

x x MSEO

VTL x x MSEO

AdvancedDisk x x NBU KMS

Symantec Dedupe storage x x Built-in

Cloud Storage x x NBU KMS

APPENDIX B - Related Documents and Hyperlinks

A MSEO Performance Calculator is available and provides performance estimates based on number of media servers; operating system; number and GHz of CPUs/Cores; % of CPU already used; number of tape drives, model and vendor; amount of data to be backed up and compressibility of the data.

https://symiq.corp.symantec.com/departments/pm/nbu/Pages/EncryptionandSecurity.aspx

The above is an internal web site, so you may need to ask a Symantec Sales Engineer to provide this to you.

NetBackup Security and Encryption Guide Has great deal of additional information on the NetBackup KMS in the chapter titled Data at rest key management

NetBackup Cloud Administrator Guide

NetBackup AdvancedDisk Storage Solutions Guide

Symantec NetBackup Deduplication Guide

NetBackup Commands Reference Guide

How to Export and Import Encryption Keys Using the NetBackup KMS

About Symantec:

Symantec is a global leader in providing storage, security and systems management solutions to help consumers and organizations secure and manage their information-driven world.

Our software and services protect against more risks at more points, more completely and efficiently, enabling confidence wherever information is used or stored.

For specific country offices and

contact numbers, please visit our

Web site: www.symantec.com

Symantec Corporation

World Headquarters

350 Ellis Street

Mountain View, CA 94043 USA

+1 (650) 527 8000

+1 (800) 721 3934

Copyright 2013 Symantec Corporation. All rights reserved. Symantec and the Symantec logo are trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S. and other countries. Other names may be trademarks of their respective owners.

NetBackup Encryption and Key Management Solutions.pdf

Documents

Transcript of NetBackup Encryption and Key Management Solutions.pdf