a guide to best practices for using the netbackup media...

This document is provided for informational purposes only and is intended for distribution only by Symantec employees to selected partners and customers. 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 © 2009 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.

A guide to best practices for using the NetBackup Media Server Encryption Option Issue Date: 4th August 2009 Version number: 1.0 Applies to: All versions of NetBackup 5.1, 6.0 and 6.5 on platforms supporting the media server encryption option. Note: This is a living document and will be subject to periodic updates. Please check the data and version number to ensure you are referencing the latest version.

A guide to best practices for using the NetBackup Media Server Encryption Option

- i -

Table of Contents 1. Introduction ............................................................................................................................... 1

1.1. Introducing MSEO ........................................................................................................... 1 1.2. What Types of Encryption are Available?........................................................................ 2 1.3. Choosing an Encryption Strength .................................................................................... 2

2. MSEO Components & Architecture .......................................................................................... 3 2.1. Writing to Tape Backup, Inline Copy, and Duplication ................................................. 3

2.1.1. MSEO Variables ........................................................................................................ 3 2.1.2. MSEO Policies ........................................................................................................... 4

2.2. Reading from Tape - Restore .......................................................................................... 5 3. Key Creation and Management ............................................................................................... 6

3.1. Key Primer ....................................................................................................................... 6 3.1.1. Where and How Different Encryption Methods are Used .......................................... 6

3.2. Managing RSA Key Pairs ................................................................................................ 7 3.3. Encrypting RSA Key Pairs ............................................................................................... 8 3.4. Sharing RSA Key Pairs Among Security Servers ........................................................... 8 4. Sample Configurations ....................................................................................................... 10 4.1. Small Configuration ....................................................................................................... 10

4.1.1. Small Configuration Data Points .............................................................................. 11 4.2. Medium Configuration .................................................................................................... 11

4.2.1. Medium Configuration Data Points .......................................................................... 12 4.3. Large Configuration ....................................................................................................... 12

4.3.1. Large Configuration Data Points .............................................................................. 13 5. Synchronizing MSEO installations ......................................................................................... 14 6. Data Classification .................................................................................................................. 15 7. Implementation ....................................................................................................................... 16

7.1. Performance Considerations ......................................................................................... 16 7.2. Virtual tape driver Configuration .................................................................................... 17 7.3. Default Tape Driver Configuration ................................................................................. 18

7.3.1. Solaris ...................................................................................................................... 18 7.3.2. Windows .................................................................................................................. 18 7.3.3. Linux......................................................................................................................... 18

7.4. Tape Library Partitioning ............................................................................................... 19 8. Protecting the MSEO Security Server .................................................................................... 25 9. Reporting ................................................................................................................................ 27 10. Appendix I - MSEO Policies ................................................................................................ 31

10.1. Additional MSEO Policy Variables ................................................................................. 32 10.2. Notes Regarding Duplication and Disk Staging ............................................................ 32 10.3. Configuring NetBackup Policies to use MSEO Compression and Encryption Services 34

11. Appendix II Terminology .................................................................................................. 36 12. Appendix III - Configuring MSEO to Encrypt NetBackup Metadata ................................... 38


- 1 -

1. Introduction The ability to encrypt data protected on removable media has been the focus of much attention over recent months. Although simple in concept, many of the routine functions carried out in data centers by IT staffers become increasingly challenging when data encryption is added as a requirement. Among the concerns important to the data protection administrative staff when it comes to encrypting removable media, the following bullet points routinely take center stage:

Will there be a significant performance impact to backup and restore processes? Can I encrypt every type of data written to removable media? Is key management an automatic or manual process? How difficult is it to deploy a given solution? Is it possible to generate comprehensive reports related to encrypted backups?

This paper sets out to answer these questions while providing recommendations and best practices surrounding the NetBackup Media Server Encryption Option (MSEO).

1.1. Introducing MSEO By design, the NetBackup Media Server Encryption Option (MSEO) is a NetBackup native encryption solution that has been architected to overcome the constraints of NetBa Client Encryption (CE). Client side processing requirements, and the negative impact this processing can have on client operations, have been eliminated in cases where the client and NetBackup media server reside on separate systems. Pass phrase creation and management tasks have been eliminated. Key protection is automated and keys are centrally located instead of being dispersed among all clients that require encryption services.

NetBackup data being written to removable tape media can be encrypted via a virtual tape driver as specified in a NetBackup policy during a backup operation. This includes the ability to selectively encrypt specific backup copies and volume pools during inline copy as well as during NetBackup Vault Option duplications. With MSEO, encryption operations occur on a NetBackup media server.

The ability to both compress and encrypt data at the media server is provided by MSEO. Compressing data prior to encryption is a necessity as the random bit patterns associated with encrypted data do not typically yield good results when using hardware based tape drive compression.

Key management is automated and can be centrally located on the NetBackup master server.

MSEO is currently supported on following OS platforms:

Windows 2000 32-bit Windows 2003 32/64-bit Windows 2003 IA64 Windows 2008 64-bit Solaris 8, 9, 10 SPARC Solaris 10 Update 4, 5 and 6 x86 64-bit Red Hat Linux 4 Update 4 64-bit Red Hat Linux 5 GA 64-bit SLES 10 SP1 64-bit

With the release of MSEO 6.1.3, planned for August 2009, all updates for RHEL4 and RHEL5 newer than those listed above will also be supported.


- 2 -

1.2. What Types of Encryption are Available? MSEO includes support for the Advanced Encryption Standard (AES). Supported AES algorithms include cryptographic keys of 128 and 256 bits.

For additional information regarding AES, please reference Federal Information Processing Standards (FIPS) publication 197 at: http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf

1.3. Choosing an Encryption Strength There are a few general pieces of information that are available to assist in deciding whether to use 128 or 256 bit keys with AES:

Key strength correlates to key length, and coincides with the amount of time and resources it would take to find a decryption key that could be used to decipher encrypted data. Longer keys increase the amount of work required to compromise the security of protected data. Based on this information, AES 256 bit encryption is considered stronger and therefore more secure when compared to AES 128 bit encryption.

Corporate security policies may dictate the use of AES with 256 bit key lengths, in which case the decision regarding key length / strength has already been made.

http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf


- 3 -

2. MSEO Components & Architecture The following section takes a more detailed look at the components, architecture, and configuration of MSEO.

MSEO consists of two primary components; the MSEO Security Server, and the MSEO Agent. The MSEO Security Server provides key management, MSEO policies, and audit templates. The MSEO Agent includes a Policy Enforcement Module (PEM), and the virtual tape driver.

2.1. Writing to Tape Backup, Inline Copy, and Duplication

When a tape write operation occurs, the MSEO Agent intercepts the write request. MSEO-specific variables are parsed from the backup header and sent to the MSEO Security Server. The MSEO Security Server locates the matching MSEO policy and evaluates the rules within the MSEO policy. The first rule that evaluates to true dictates whether the operation is allowed and what, if any, compression and encryption should be applied to the backup data. The results of the evaluation are returned to the MSEO Agent along with a Backup Encryption Key (BEK) and public key, and the virtual tape driver fulfills any approved request. This scenario applies to all tape write operations; backup, inline copy, and NetBackup Vault Option duplication.

2.1.1. MSEO Variables MSEO specific variables parsed from the backup header include:

Volume pool number Backup copy number NetBackup policy name NetBackup policy keyword phrase variables

Media Server MSEO Agent

PEM

Virtual Tape Driver

Real Tape Driver

NetBackup Master Server MSEO Security Server

Figure 1 - Component block diagram


- 4 -

NetBackup policy keyword phrase variables parsed from the backup header must be enclosed within XML (eXtensible Markup Language) tags in order for the virtual tape driver to send them to the MSEO Security Server for evaluation. The XML tag format requires that the keyword phrase

introduced typically include:

KeyGroup KeyType Compress

An example NetBackup policy keyword phrase might look like this: <mseo> KeyGroup=Keys_01;; KeyType=aes128;; Compress=lzrw3;; </mseo>

2.1.2. MSEO Policies An MSEO policy contains rules that are evaluated at execution time. Variables extracted from the NetBackup header are available for use within an MSEO policy. The first MSEO policy rule that evaluates to true is used to dictate what, if any, key group, compression, and encryption is applied to the data stream before it is sent to a tape drive.

The example sh

Figure 2 - MSEO default policy

Note that the default MSEO policy contains three rules, each of which are contained within the >

A detailed look at the first rule follows:


- 5 -

Figure 3 - Rule within MSEO default policy

can use variables from a NetBackup policy keyword phrase.

rule would evaluate to true. MSEO would compress the backup stream with lzrw3 compression, and would encrypt the backup stream with 128 bit AES encryption.

Additional MSEO policy information is contained in Appendix I.

2.2. Reading from Tape - Restore When a tape read operation occurs, the MSEO Agent intercepts the read request. NetBackup metadata is parsed from the backup stream and sent to the MSEO Security Server. The MSEO Security Server locates the matching MSEO policy and evaluates the rules within the policy. The first rule that evaluates to a true condition determines whether the operation is allowed or not. If the operation is allowed, the MSEO Security Server determines how the data was encrypted and / or compressed. The results of the evaluation are returned to the MSEO Agent along with the private key if the data needs to be decrypted, and the virtual tape driver fulfills any approved request. Requests that have been denied by the MSEO Security Server result in a failed tape read operation.

The MSEO Security Server can reside on a master / media server along with the other components in standalone configuration. The MSEO Security Server can also reside on a remote media server with the other MSEO components. In cases where multiple media servers will be performing encryption / decryption operations, it is recommended that the MSEO Security Server be installed on the NetBackup master server. This centralizes administration in larger environments.

Note: The MSEO Security Server can reside on any centrally available server, which does not need to be running NetBackup software. A MSEO Security Server can span NetBackup domains. It is recommended the MSEO Security Server be installed on a NetBackup Master Server because if the master server goes down no backups or restores will be able to be performed anyway (at least in that specific NetBackup domain)..


- 6 -

3. Key Creation and Management MSEO revolves around data encryption and the keys used to encrypt and decrypt that data. This section describes the keys, how they are applied, and recommendations associated with the creation and management of keys.

3.1. Key Primer MSEO uses two encryption methods when writing data to, or reading data from tape media:

1) AES 128 and 256 bit for backup data encryption

2) RSA 512, 1024, 2048, and 4096 bit for key encryption

3.1.1. Where and How Different Encryption Methods are Used Tape Write:

When the MSEO Security Server receives a permitted backup request from an MSEO Agent, it performs the following operations:

It generates a new random AES 128- or 256-bit Backup Encryption Key (BEK) for each backup job or fragment.

Based on the Key Group parameter evaluated for the MSEO policy, it retrieves the group of RSA public keys to be used to encrypt the BEK

It encrypts the BEK with each RSA public key It returns the BEK and its encrypted values using each public key in the key group to the

MSEO Agent

The MSEO Agent stores the encrypted BEK in the MSEO metadata associated with each backup data block as well as uses the BEK to encrypt the backup data. The BEK is only stored on the tape, encrypted by the RSA public key(s), and a copy is not maintained in the MSEO key store. It is the public and private RSA encryption key pairs that are stored in the MSEO Security Server key store.

When the MSEO Agent checks with the MSEO Security Server to determine if it can read a tape archive and the MSEO Security Server grants permission, the MSEO Security Server performs the following operations:

Generate Random AES BEK Public Key

Encrypted BEK

Encrypted with BEK

Backup Media (Tape)

Backup Data

MSEO Metadata

Encrypted

Backup Data

Figure 4 - Tape write process


- 7 -

It locates one of the RSA private keys corresponding to the RSA public key(s) used to encrypt the BEK

It decrypts the BEK using the RSA private key It returns the decrypted BEK to the calling MSEO Agent

The BEK, along with the encryption and compression algorithms get passed to the Virtual tape driver to restore the data.

Notes:

There is no need or ability to manage the AES randomly generated AES keys

The AES key, BEK, is uniquely generated for each write job. The only instance of the AES key is encrypted and written to tape as part of MSEO metadata. MSEO does not maintain copies of AES keys in the MSEO Security Server key store.

The RSA key pairs are generated and managed by the MSEO administrator, and are stored in the MSEO Security Server key store.

3.2. Managing RSA Key Pairs RSA key pairs are important from the MSEO administrative perspective in that encrypted data cannot be recovered without them. Protecting and distributing RSA key pairs plays an important role in certain scenarios. The examples provided here are not intended to be exhaustive, but are instead provided to emphasize the importance of properly managing RSA key pairs:

The entire MSEO database, including the key store containing the RSA key pairs should be protected such that this data could be recovered in the event the MSEO Security Server needed to be rebuilt from the ground up

A disaster recovery site that needs to recover encrypted data will only be able to do so if it has a copy of the exported MSEO RSA key pairs used at the primary site

Encrypted BEK AES Encrypted Backup Data

AES Encryption Key (BEK)

Decrypt with RSA Private Key

Clear Backup Data

Decrypt (Symmetric)

Backup Media Contents (Tape)

Figure 5 - Tape read process


- 8 -

Recovering encrypted data on a NetBackup media server, which uses a different MSEO Security Server than the one initially involved in backing up the data, requires the MSEO RSA key pairs used for encryption are available for recovery

Business partners or affiliates that have a requirement to share encrypted backup media need to share their RSA public keys in order to be able to recover data encrypted at the partner or affiliate site.

The number of RSA key pairs used is typically related to business requirements. For instance, in the prior example where one business was sharing encrypted backup media with an affiliate, it would probably require at least two unique RSA public keys. One RSA public key could be used locally for encrypting backup media that was not meant to be shared. The second RSA public key, sent by the affiliate could be used for encrypting backup media that was meant to be shared. The first RSA private key would restore locally and would not be shared with the affiliate; the second RSA private key at the affiliate site would be used to decrypt shared content.

3.3. Encrypting RSA Key Pairs Previously mentioned in this section were two types of encryption used to write and read encrypted data to or from tape media. A third type of encryption is used to secure the RSA key pairs such that they are securely managed.

MSEO uses a hierarchical key management scheme to protect all the RSA private keys from unauthorized access. All the keys are protected with a symmetric master key, which in turn is protected by a passphrase.

The Security Server must know the master passphrase in order to access the master key to decrypt the private keys stored on the disk. The MSEO Security Server can either read the passphrase from the command line, which prompts the administrator to interactively enter the passphrase, or the Security Server can read the passphrase from the access file.

3.4. Sharing RSA Key Pairs Among Security Servers In the event backups that have been encrypted without the correct private key of an RSA key pair.

You can share public and private RSA encryption keys between MSEO Security Severs so that backups made on one server can be restored on other servers, and vice versa.

The keys that you share are the MSEO database keys used to encrypt and decrypt backup tape headers. These are not the keys used to encrypt the backup data. Those are AES keys, and no copy of an AES key exists other than on the tape itself.

Configuring a media server to access multiple Security Servers requires the databases to be synchronized between all the Security Servers. That is, the Security Servers need the same policies, keys, etc. to effectively and transparently administer one the media servers. If an alternate Security Server is used in the event the primary Security Server is inaccessible, the database of the alternate Security Server must have the same keys and policies to administer the media server.

Note: The encryption keys of one Security Server cannot be copied from one Security Server to another. Encryption keys are wrapped with a system-specific default key. Without the appropriate default key, the encryption keys are worthless and cannot be used to restore backups. Encryption keys must be exported from a Security Server, copied to another Security Server, and then imported by that other Security Server. Exporting the keys releases their association with the current Security Server and packages them in a password-protected file. Importing unpackages the keys and establishes their association with the new Security Server. Security Server keys must be exported and imported using the MSEO Server Console or the cgadmin utility.

Error messages that occur as the result of not having the correct RSA private key or access file may look like the dialog as seen in the following graphic image:


- 9 -

Figure 6 - RSA private key missing error

Symantec recommendation: Best practice is to share keys between MSEO Security Servers.


- 10 -

4. Sample Configurations Configuration activities are relatively straightforward. Configuration options are divided into the following general categories:

Configuring the virtual tape driver for use with tape drive devices Registering PEM hosts / media servers with the MSEO Security Server Creating and managing encryption keys Configuring MSEO policies Configuring NetBackup Policies to use MSEO compression and encryption services

4.1. Small Configuration In this example, a small configuration is defined as deployment that includes a single NetBackup master server, and a single NetBackup media server.

Key-pair1

NetBackup Master Server

Security Server

Media Server

VTD

PEM

Figure 7 - Small Configuration


- 11 -

The block diagram shown in Figure 7 denotes a small sample configuration where the NetBackup master and media server functions are hosted on the same system. MSEO Security server and MSEO Agent software is also installed on this system.

4.1.1. Small Configuration Data Points A typical small configuration may be implemented such that it uses a one encryption key, a single key group, an audit template, and a MSEO policy. If desired, the MSEO policy could be set to automatically compress and encrypt all backups to tape that were processed on this media server.

Alternatively, the small configuration could also be configured with multiple keys, key groups, and a MSEO policy that provided the flexibility to compress and encrypt data being written to tape based on variables supplied by a NetBackup policy keyword phrase.

4.2. Medium Configuration In this example, a medium sized configuration is defined as deployment that includes a single NetBackup master server, and multiple NetBackup media servers.

Figure 8: Medium Configuration

Key-pair1 Key-pair2


Security Server

Media Server 1

VTD

PEM Media Server 2

VTD

PEM


- 12 -

The block diagram shown in Figure 8 denotes a medium sized sample configuration where the NetBackup master server is hosted on one system, and two NetBackup media servers are hosted on additional systems. MSEO Security server software is installed on the same system as the NetBackup master server, and MSEO Agent software is installed on both NetBackup media servers.

4.2.1. Medium Configuration Data Points A typical medium sized configuration may be implemented such that it uses a one or more key pairs, one or more key groups, an audit template, and one or more MSEO policies.

Depending on implementation requirements, the ability to use a unique MSEO policy for each media server is available. This may be desirable in cases where one media server is used to encrypt during inline copy operations, another media server is used to encrypt data during NetBackup Vault option duplication, and other media servers are used to encrypt all or a subset of backups written to tape.

Configuration options are highly flexible. The example cited in graphic 4 has four NetBackup media servers using a common MSEO Security server hosted on the NetBackup master server. If desired, there can be more than a single MSEO Security server. Additionally, there is no requirement that all NetBackup media servers be configured as MSEO Agents.

4.3. Large Configuration In this example, a large configuration is defined as a deployment that includes multiple NetBackup master servers.

Figure 9: Large configuration

The block diagram shown in Figure 9 depicts a large sample configuration where two NetBackup master servers are hosted on different systems, and four NetBackup media servers are hosted on additional systems. MSEO Security server software is installed on the same systems as the NetBackup master servers, and MSEO Agent software is installed on all four NetBackup media servers.

Site 1

PubKEY3 PubKEY4

Site 2

Key-pair1 Key-pair2


Security Server

Media Server 1

VTD

PEM Media Server 2

VTD

PEM

Media Server 3

VTD

PEM Media Server 4

VTD

PEM


Security Server

PubKEY1 PubKEY2

Key-pair3 Key-pair4


- 13 -

4.3.1. Large Configuration Data Points Site 1 and Site 2 could be geographically separated, with Site 1 on the East coast and Site 2 on the West coast, for example. The public key portions of RSA key pair 1 and RSA key pair 2 from Site 1 can be copied to the MSEO Security Server at Site 2. The public key portions of RSA key pair 3 and RSA key pair 4 from Site 2 can be copied to the MSEO Security Server at Site 1. Backups created at Site 1 can be restored at Site 2 and vice versa.


- 14 -

5. Synchronizing MSEO installations Manual synchronization is required in NetBackup configurations with multiple Security Server installations. The keys and policies from one Security Server should be the same on all the Security Servers in the NetBackup configuration. This allows a backup made on one media server configured with one Security Server to be read on a different media server that is configured with a different Security Server. The suggested approach for synchronization is:

Select one Security Server as the primary server. This is done during software installation.

Configure the Security Server with hosts, keys, policies, and so on. Make sure it works. Install the secondary Security Servers or other, independent Security Servers. Use the MSEO Server Console export feature to package the keys for transport to the

other Security Servers. Copy the ./mseo/server/export directory of the primary server to the ./mseo/server/import

directory of the other servers. Copy the ./mseo/server/db directory of the primary server to the ./mseo/server/db

directories of the other servers. The ./db directory contains the host, key, policy, and audit log configurations.

Run the MSEO Server Console import feature on each of the other servers in order to unpackage and install the primary server keys.


- 15 -

6. Data Classification Serious consideration should be given to the concept of data classification in conjunction with deploying MSEO. Data classification involves a number of parameters that should likely be considered in advance of simply deciding to encrypt all data written to removable tape media. Among the parameters that may influence data classification are:

Is there a legal requirement that all data written to removable tape media be encrypted?

Local and national laws may govern exactly what data needs to be encrypted. Understanding these laws may assist in properly classifying data into two general categories; data that must be encrypted and data that does not need to be encrypted.

What encrypted data, if any, has to be shared with business partners and affiliates?

deciding what quantity of RSA key pairs are required.

Much like the concept of retaining all backups indefinitely, the concept of encrypting all data may end up costing more in the long run. Data is generally classified and backups are retained based on a service level assigned to the data classification. The result is reduced media consumption

may enable additional cost savings.


- 16 -

7. Implementation Two important goals of successfully implementing MSEO include securing data on tape with encryption and understanding any performance impact this may have on overall NetBackup media server performance.

After classifying data to determine what backups require encryption, a cursory review of existing NetBackup policies and storage units should be performed. The purpose of this review is to determine if the backups requiring encryption can use a collection of NetBackup storage units that have MSEO enabled. A review of NetBackup policies and storage units should result in a basic understanding of the environment.

For instance, an example review yields these results:

1) The environment consists of 1 NetBackup media server with a single storage unit

2) The NetBackup storage unit has eight tape drives

3) 25% of the data being protected requires MSEO encryption services

4) None of the NetBackup policies used to protect the data requiring encryption services include data that does not require encryption services

The results of the review indicate that it may be appropriate to configure MSEO such that it uses two of the eight available tape drives. The existing NetBackup storage unit that contains eight tape drives must be logically partitioned into two NetBackup storage units, the first with six tape drives not configured to use MSEO, the second with two tape drives configured to use MSEO encryption services.

1) The environment consists of two NetBackup media servers with three storage units

2) The first

3) The second NetBackup media server has a single storage unit with eight tape drives

4) 40% of the data being protected requires MSEO encryption services

5) The NetBackup policies used to protect the data requiring encryption use two storage units, one on each media server

6) The NetBackup policies used to protect the data requiring encryption also include data that does not require encryption

The results of the review reveal the following data points:

A) NetBackup policy reconfiguration should be considered so the policies utilizing MSEO encryption services only include data that requires encryption

B) Assuming all eighteen tape drives are of the same type, it appears that seven of the tape drives should likely be configured to use MSEO encryption services

Other reviews may yield results that are somewhat more extreme. For instance, a decision may be made to simply encrypt all backups to tape media. In this case, the performance impact that

complete within a given backup window.

7.1. Performance Considerations The MSEO driver is multithreaded and the software has been tuned for multiple drive environments to be able to utilize all of the multiple


- 17 -

However, when attempting to encrypt a lot of data, you can easily run into a CPU bottleneck if takes roughly 73 clock cycles on a

Windows or Linux server or about 87 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 8.7 GHz of CPU processing for MSEO alone, plus whatever processing is needed for other tasks. To move 200 MB/sec through the media server would require 17.4 GHz of CPU for MSEO. Adding HBAs to a media server to get additional throughput

/encryption is used.

First, determine how much data must be backed up and the size of the backup window. That determines the minimum and load times, which must also be considered) to complete the backup within the backup window. That data rate in GB/sec x 73 or 87 CPU cycles/byte determines the CPU GHz required for MSEO compression/encryption.

The tape drive must also be considered. LTO2, LTO3 and LTO4 tape drives all have native transfer rates as well as a minimum transfer rate, which is required to keep them streaming. For example, an IBM LTO3 tape drive has a native transfer rate of 80 MB/sec, but requires at least 40

inimum speed, the drive will and spin up to speed before the write operation

can begin again. This has a drastic impact of overall performance.

In addition, because MSEO performs compression, if the data can be compressed by 1/3 a 1.5:1 compression ratio the media server will need to process 60 MB/sec of data to provide data to the tape drive at 40 MB/sec. On a UNIX system, that will require 5.2 GHz of processing for MSEO to keep one IBM LTO3 drive streaming at its minimum rate. A four CPU/core system with is capable of running at 120 MB/sec with 1.5:1 compression, even if the drive is able to be kept streaming (say by using 1.4 GHz or 1.5 GHz processors), it is being used at only 50% efficiency (60MB/sec vs.120 MB/sec).

In all likelihood, you will need to attach fewer tape drives to a MSEO media server in order to make certain the drives stream, and/or you will need to add CPUs to existing media servers or buy media servers with more processing power to be able to utilize the number of tape drives you already have.

The greater the amount of data to be encrypted, the more likely you may face a performance bottleneck based on media server processing power.

Because the number of CPU cycles per byte as noted above are estimates, it would be worthwhile to run some tests by deploying one tape drive on a media server and determining the maximum data rate that can be achieved. A second tape drive can be attached and the same test run. You want to determine the maximum overall throughput for the media server and this will occur when all drives can maintain streaming. Performance may be as good or better using only one drive, which can run at its maximum rate, than using multiple tape drives.

Remember to consider how much additional data may need to be encrypted in the future as you

must purchase a number of additional and expensive media servers.

7.2. Virtual tape driver Configuration Tape drives are configured command can be used to list, configure, or de-configure devices on a drive by drive basis.

configure drives individually as part of the phased deployment methodology.

configuration of tape drives:


- 18 -

Figure 10 - Tape Drive Listing

7.3. Default Tape Driver Configuration MSEO product installation results in different default MSEO settings for Solaris, Linux and Windows media servers. There are two primary items that need to be addressed:

MSEO device status (NOTE: In older versions of MSEO, these were referred to as CGSB devices as shown in Figure 11.

Devices that are configured as MSEO devices can be used to provide MSEO compression and encryption services. Devices that are not configured as MSEO devices cannot be used to provide MSEO compression and encryption services.

Asynchronous mode

Asynchronous mode affects two important aspects of tape drives that have been configured as MSEO devices. The first is performance. Enabling asynchronous mode provides a performance improvement when compared to disabling asynchronous mode when using a tape drive with MSEO. The second aspect of asynchronous mode is error recovery. NetBackup is not able to recover from a variety of errors if they occur on a MSEO enabled tape drive when asynchronous mode is enabled. In the event of an error occur, the NetBackup job will fail. Disabling asynchronous mode allows normal NetBackup recovery to occur, but performance will be impacted.

7.3.1. Solaris The default Solaris installation does not configure any tape drives as MSEO devices. In addition, when configuring MSEO devices, asynchronous mode is by default disabled. Asynchronous mode should be enabled to properly gauge MSEO performance.

7.3.2. Windows The default Windows installation configures all tape drives as MSEO devices. In addition, when configuring MSEO devices, asynchronous mode is by default disabled. Asynchronous mode should be enabled to properly gauge MSEO performance.

7.3.3. Linux The default Linux installation does not configures any tape drives as MSEO devices. In addition, when configuring MSEO devices, asynchronous mode is by default disabled. Asynchronous mode should be enabled to properly gauge MSEO performance.


- 19 -

7.4. Tape Library Partitioning As tape drives are configured to work with MSEO, there will be configurations where not all the tape drives within a given tape library are MSEO tape drives. Normally, a single tape library would be defined within NetBackup as a single storage unit. A single storage unit with MSEO and non-MSEO tape drives must be reconfigured into two separate storage units. One of the resulting two NetBackup storage units will contain only MSEO tape drives, and the other storage unit will contain only non-MSEO tape drives. This enables the NetBackup policies requiring MSEO encryption services the ability to use a policy storage unit containing MSEO tape drives.

The following example shows how a single tape library with three tape drives is configured within NetBackup when one of the tape drives is configured as an MSEO tape drive, and the remaining two drives are configured as non-MSEO tape drives. The following screen shot is no longer indicative of the how the results of the cgconfig list command are displayed as Figure 10 shows how devices are currently displayed.

Figure 11: One MSEO tape drive configured In Figure 11 above, the tape drive corresponding to number 1 is configured as a MSEO tape drive. The remaining two tape drives numbered 2 and 3 are not configured as MSEO tape drives.

Within the NetBackup administrative GUI, the tape drives are configured such that the MSEO tape drive is denoted as a different device type. In the case of this example, all three tape drives start with a drive type equal to DLT:

Figure 12: DLT drives

The first tape drive (Bus 0 target 0 LUN 0) is now changed from a device type of DLT to a drive type of DLT2:


- 20 -

Figure 13: Changing drive type

The three tape drives have been segregated such that the MSEO tape drive is defined as a DLT2 drive type, and the non-MSEO tape drives are defined as a DLT drive type:

Figure 14: Altered drive type

At this point two separate NetBackup storage units are created. The first storage unit is defined to have a density of DLT2. This storage unit contains the MSEO tape drive:


- 21 -

Figure 15: MSEO storage unit

The second storage unit is defined to have a density of DLT. This is the storage unit that contains the two non-MSEO tape drives:


- 22 -

Figure 16: Non-MSEO storage unit

The two NetBackup storage units:

Figure 17: One library containing two storage units


- 23 -

Because each of the two NetBackup storage units have a different density, tape media corresponding to these different densities must be allocated. This is accomplished by introducing

tton on the inventory dialog window allows newly imported media to be set to a specific media type:

Figure 18: Media type pull down menu

At this point, the library has two media types, one type for each storage unit:

Figure 19: Media type


- 24 -

Continuing, the NetBackup policies that require MSEO encryption services are altered to use the storage unit that has the MSEO tape drive:

Figure 20: Policy storage unit

This process may need to be executed more than once as additional tape drives are configured as MSEO tape drives if you do performance testing.


- 25 -

8. Protecting the MSEO Security Server Backup the MSEO Security Server data store with sufficient frequency so that no configuration data, like policy and agent certificates, has the potential to be irretrievably lost. Be sure to backup the data store without encryption. Do not encrypt the MSEO Security Server data store backup because you may not have the keys to decrypt it in the future. The data store is located at

./cgsb/server/ .

Multiple solutions are available for protecting the MSEO Security Server data store with or without NetBackup:

Protect the MSEO Security Server data store by including it with regularly scheduled NetBackup catalog backups without encryption

The MSEO Security Server data store only changes when manipulating RSA keys, MSEO policies, or MSEO audit templates. Protect this data using a separate NetBackup policy that does not use encryption

Burn the MSEO Security Server data store to CD/DVD and store it in a secure company safe or lockbox

Alternatively, duplicating the MSEO Security Server data store to a USB storage device that can be secured is another option

Public/private key pairs are another matter. To backup these keys, you MUST first export the keys using the GUI or entering CLI commands. After which, back up the ./mseo/server/export directory (key pair backup) in some manner that you are sure will be accessible without MSEO being present. For example, backup the directory without encryption or compression to a tape or system directory. Later, if you need to install the keys, restore the key pair backup to the ./mseo/server/import directory, and import the keys using the GUI or by entering CLI commands.

Note: The public/private key pairs of one Security Server cannot be copied from one Security Server to another. Key pairs are wrapped with a system-specific default key. Without the appropriate default key, these keys are worthless and cannot be used to restore backups. Public/private key pairs MUST be exported from a Security Server, the files in the /mseo/server/export directory copied, those files copied to the /mseo/server/import directory on another Security Server, and the key pairs imported by that other Security Server. Exporting the keys releases their association with the current Security Server and packages them in a password-protected file. Importing unpackages the keys and establishes their association with the new Security Server. Security Server keys must be exported and imported using the MSEO Server Console or the cgadmin utility.

Symantec recommendation: Best practice advice is to evaluate your site requirements and implement the appropriate solution or solutions. If you do not use the export/import capability of MSEO for backing up or moving keys, but attempt to only backup and restore the Security Server data store, to either the same Security Server or a different one, the public/private keys will be corrupted and you will NOT be able to restore any data backed up using these keys.

The procedure used to protect the MSEO Security Server data store as part of NetBackup catalog backups differs depending on the version of NetBackup being used, and also on whether hot or cold backups are being performed in the case of NetBackup 6.0. Relocating the MSEO Security Server data store may have ramifications that impact upgrades and product installation that are not currently understood.

NetBackup 6.0 offline, cold catalog backups

Catalog


- 26 -

paths that will be protected when catalog backups are performed. Add an entry that represents the MSEO Security Server data store

NetBackup 6.0 online, hot catalog backups

MSEO Security Server data store has to be relocated to ust relocate the

MSEO Security Server data store to accommodate this requirement.

NetBackup 5.1 offline, cold catalog backups

the ability to include additional paths that will be protected when catalog backups are performed. Add an entry that represents the MSEO Security Server data store


- 27 -

9. Reporting MSEO is transparent to NetBackup, so reports related to MSEO are not available as part of the NetBackup graphical or command line user interfaces. However, there are other alternatives for generating reports. One method to generate reports related to the compression and encryption associated with MSEO is to access log files created using a MSEO audit template.

The content included in log-based reporting is controlled by means of a MSEO audit template. Audit templates, used in concert with MSEO policies, enable the capturing of parameters used to write or read

XML document.

:

Figure 21: Audit template XML file

The default report format prints the MSEO policy name, key type, compression algorithm,

Windows logs are written to the event log, as depicted in the following example:

Figure 22: Windows event log


- 28 -

MSEO audit logs enable the ability to confirm that MSEO is performing compression and encryption operations as configured via the keyword phrase parameter in a NetBackup policy, or as hard-coded in an MSEO policy.

Symantec recommendation: Any time a MSEO policy or NetBackup policy keyword phrase is altered, check the MSEO audit logs to confirm that the desired actions are occurring.

Audit temp \cgsb\server\db\ The audit template is referenced by name in MSEO policy rules. This determines what gets logged when the rule evaluates to true. For example, the following MSEO policy explicitly calls for the use of the netbackup audit template in every rule:

Figure 23: MSEO policy referencing the NetBackup audit template

Audit templates can employ a variety of built-in variables that enable customizing of the type of information that gets logged. For example, you can log information such as the NetBackup media id, backup id and policy name as well as the MSEO key type. See the sections titled -in

Chapter 5 in the MSEO Administration Guide for more detailed information.

The logs could then be used to determine which NetBackup backup images have been encrypted by MSEO and which media contain encrypted backup images.


- 29 -

Note: A

Audit Template Variables Variable

Description

po.allenckey Causes the list of key names from the key group in the MSEO policy to be logged.

po.compress Causes the compression type requested in the MSEO policy to be logged.

po.enckey Causes the key group requested in the MSEO policy to be logged.

po.keytype Causes the encryption type requested in the MSEO policy to be logged.

po.name Causes the name of the MSEO policy being evaluated to be logged.

Table 1: Audit template variables In addition to the use of audit template variables, static text can also be added to an audit template.

The use of Veritas Backup Reporter (VBR) allows you to determine which backup jobs have been encrypted by MSEO by filtering on a specific MSEO keyword phrase used in a NetBackup policy. This allows you to determine which NetBackup policies and associated backup ids, backup images and tape media have been encrypted using MSEO. However, one must take care in configuring MSEO rules on the Security Server to make certain you do not configure a rule(s), so even though the specific keyword phrase is included in the backup policy, the rule directs MSEO to not encrypt the backup. If this error were made, your listing of encrypted backup ids would not be accurate and you would perceive some backups had been encrypted that were not encrypted. The graphic below shows a VBR report in which the MSEO keyword phrase was used as a filter for the Policy Description. Other fields can be chosen for the report depending on what your requirements are.

Figure 24: Veritas Backup Reporter on MSEO encrypted backups

If one chooses to use specific volume pools for all MSEO encrypted backups, NetBackup Operations Manager (NOM) could be used to generate a report of media in those volume pools,


- 30 -

which would indicate encrypted backup jobs. If NetBackup Vault is being used, media to be sent off-site is written to specific volume pools, so either Vault reports or NOM could be used to generate a report of encrypted backups.


- 31 -

10. Appendix I - MSEO Policies MSEO backup policies should not be confused with NetBackup policies. MSEO policies reside within XML files. The XML file elements, attributes, and values are used in conjunction with a NetBackup policy keyword phrase to compress and encrypt backups written to tape media when desired.

The graphic below is an example of the MSEO default.xml file:

Figure 25: Default.xml file

element contains three ressence, these define a condition and an action. These parameters are evaluated such that the condition of the security rule must equate to true before the subsequent action is performed.

The first rule in the example contains these parameters:

rule grants permission during write, or backup operations. The statement also includes the

another XML file that specifies what information will be logged for auditing and reporting purposes.

This portion of the rule specifies what encryption method to use when writing data to

the NetBackup policy keyword phrase. For example, this value could be none, AES128, or AES256.


- 32 -

This section specifies the compression algorithm to use. The

NetBackup policy keyword phrase. For example, this value could be none, lzrw3, lzo1x, or text85.eng.

This portion specifies the name of the RSA key group used to encrypt the AES key that gets written to tape. In this case, the value is hard-coded to use the default key. Conversely, this line coul Group

GroupNetBackup policy keyword phrase.

AttributeMatch Name =

These lines represent Boolean valued strings that compare one string against another using a supported function or relation. The condition e returns a match if the string

that the string cannot be empty or null for a match to occur.

The Third rule in the example MSEO policy referenced in Figure 24 gets invoked during a restore. All the attributes are extracted from the MSEO header to determine the Compression and Encryption algorithm and which key is used for encrypting the backup encryption key. .

Symantec recommendation: Although the second rule can easily be altered so that by default, compression and encryption are automatically applied during backups, best practice advice is when no NetBackup policy keyword phrase is used, no compression or encryption should occur.

10.1. Additional MSEO Policy Variables NetBackup volume pool numbers, NetBackup copy numbers, and NetBackup policy names can also be used within MSEO policy rules. This can assist in constructing rules applicable to inline copy and NetBackup Vault option operations.

For instance, the NetBackup volume pool number can be used to specify that only backups written to a specific volume pool number get compressed and encrypted. Optionally, the NetBackup copy number can be used to specify that only specific backup copy numbers get compressed and encrypted.

10.2. Notes Regarding Duplication and Disk Staging The NetBackup Vault option does not facilitate the introduction of MSEO specific variables from within a Vault policy. Looking at a Vault policy, you can see that the keyword phrase field is not active:


- 33 -

Figure 26: Vault policy

There are essentially two ways around this obstacle. The first is to hard-code specific NetBackup copy numbers and / or volume pool numbers into a MSEO policy.

The second is to understand that the original backup header will be duplicated along with the backup data. What this implies is that a backup performed to disk that used a NetBackup policy

<mseo>KeyType=aes256;KeyGroup=KeyGroup1;Compress=lzrw3</mseo>would pass the same keyword phrase through the Virtual tape driver at the time it was being duplicated to tape by the NetBackup Vault option. The MSEO specific variables in the keyword phrase are evaluated the same way that they are during regular backups.

If you plan to use MSEO to encrypt your backup image (copy1) and also encrypt the duplicate backup image (copy2), MSEO will have to decrypt and uncompress the backup image, then compress and encrypt it again as it writes copy2. This will basically double the CPU load compared to encrypting a backup.

Disk staging presents a similar challenge. The initial backup is performed to disk, and is subsequently staged to tape. Hard-coded variable values for NetBackup copy numbers and / or volume pool numbers can be used to control what happens, as well as the NetBackup policy keyword phrase.


- 34 -

The following MSEO policy example has been constructed for use with the NetBackup Vault option. Note that the NetBackup copy number must be equal to two, and that the NetBackup volume pool number must be equal to two for the rule to evaluate to true:

Figure 27: MSEO policy for use with the NetBackup Vault option

NetBackup volume pool number two equates to the DataStore pool:

Figure 28: NetBackup volume pools

10.3. Configuring NetBackup Policies to use MSEO Compression and Encryption Services

NetBackup policy keyword phrases are used in conjunction with MSEO policies to control compression and encryption operations when performing backups. An example NetBackup policy is shown here for reference:


- 35 -

Figure 29: NetBackup policy

The actual string typed into this field is: <mseo>KeyType=aes256;;KeyGroup=KeyGroup1;;Compress=lzrw3</mseo>

The string is prefixed and suffixed with XML tags that identify it as an MSEO keyword phrase. This requirement allows the product to differentiate between non-MSEO keyword phrases, and those that should be used in conjunction with MSEO policies to control the compression and encryption of backups.

The information that appears embedded within the It also specifies the use of a key


- 36 -

11. Appendix II Terminology Term Description

Cipher An algorithm for performing encryption and decryption.

Algorithm A procedure for accomplishing some task which, given an initial state, will terminate in a defined end-state.

Encryption The process of obscuring information to make it unreadable.

Key Pair Asymmetric Keys / RSA Keys / Public Key / Private Key

Symmetric Keys

A class of algorithms for cryptography that use trivially related cryptographic keys for both decryption and encryption. AES 128 / 256

Asymmetric Keys

A form of cryptography which generally allows users to communicate securely without having prior access to a shared secret key.

Hash In computer science, a hash table, or a hash map, is a data structure that associates keys with values.

Digital Certificate

In cryptography, a public key certificate is a certificate which uses a digital signature to bind together a public key with an identity. It can be used to verify that a public key belongs to an individual.

Virtual Tape Driver

A software driver that assumes the role and responsibilities of the physical tape driver. The MSEO virtual device driver is transparent to the media server operating system. When the MSEO virtual driver is used, the PEM controls SCSI-layer interaction to the physical devices.

Agent A term that identifies the Policy Enforcement Module (PEM) and its associated virtual tape driver.

Security Server

The process that is responsible for authenticating and authorizing the access to the physical tape devices through the virtual tape driver.

MSEO Policies

A MSEO policy is a set of security rules. Each security rule is a collection of attributes whose values are used by the MSEO Security Server to evaluate the read and write requests issued by NetBackup. Once evaluated, the first security rule whose attributes successfully evaluate to true is used.

PEM Policy Enforcement Module (PEM). On Unix, MSEO comprises two software MSEO- MSEO-

Servers.

Table 2: Terminology


- 37 -

Key Type Description

Symmetric Master Key (SMEK) Protects all of the Keys.

Symmetric Master Key Passphrase

Protects the Master Key.

RSA Private Key

Passphrase

Protects RSA Private Keys using Public Key Cryptography.

RSA Private Encryption Keys (PREK)

RSA Private Encryption Keys.

Master

Passphrase File

Lists all Private Key Passphrases and is encrypted by the Master Key.

Public / Private

Key Pairs (KPAIR)

Generated and encrypted using a random master passphrase.

Public Encryption Keys

(PEK)

Public Encryption Keys

Public Key Group

PubEK

Public Key Group

File (Backup)

Encryption Key (FEK)

File (Backup) Encryption Key, also referred to as Backup Encryption Key (BEK).

Table 3: Key terminology


- 38 -

12. Appendix III - Configuring MSEO to Encrypt NetBackup Metadata

Depending on the level of security required, MSEO is able to encrypt NetBackup metadata written to tape such that the encrypted backups cannot successfully undergo a phase 1 import operation on a NetBackup installation that does not have the appropriate keys. The backup header of each MSEO generated backup includes NetBackup and MSEO metadata. The MSEO portion of the header is always encrypted. By default, NetBackup metadata is not encrypted.

You can configure MSEO to encrypt the entire header with the same keys used to encrypt the MSEO metadata. Enable this feature to prevent any media server from accessing NetBackup metadata, except those configured with MSEO and with access to the appropriate keys.

Symantec recommendation: Disaster recovery and other offsite facilities will be unable to perform a phase 1 import and may be unable to locate specific backups in the event of mislabeling or loss of inventory records if NetBackup metadata is encrypted. Best practice advice recommends against using this feature unless specifically required by corporate policies.

a guide to best practices for using the netbackup media...

Documents