MSEO BestPractices

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.
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
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
-i-
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?
 Can I selectively decide what data gets encrypted, and what doesn’t?
 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 NetBackup’s 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.
-1-
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.
-2-
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.
NetBackup Master
Server
Media Server
MSEO Agent MSEO Security Server
PEM
Virtual Tape Driver
Real Tape Driver
Figure 1 - Component block diagram
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
-3-
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
be prefixed with “<mseo>” and suffixed with “</mseo>”. The MSEO specific variables that can be
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 shown here is based on the “default.xml” MSEO policy:
Figure 2 - MSEO default policy

Note that the default MSEO policy contains three rules, each of which are contained within the
XML tags “<SebRule>” and “</SebRule>”.
A detailed look at the first rule follows:
-4-
Figure 3 - Rule within MSEO default policy

The portions of the rule that contain “|netbackup.keyword.KeyType|” and
“|netbackup.keyword.Compress|” represent areas where the rule can use variables from a
NetBackup policy keyword phrase.
In the case where the NetBackup policy keyword phrase was, “<mseo> KeyType=aes128;
Compress=lzrw3; </mseo>”, the 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)..
-5-
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.
Generate Random AES MSEO

Public Key
BEK Metadata
Encrypted
BEK
Encrypted
Backup
Backup Data
Data Encrypted with
BEK
Backup Media (Tape)

Figure 4 - Tape write process
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:
-6-
 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.
Backup Media Contents

(Tape)
Encrypted BEK AES Encrypted Backup Data
Decrypt with RSA

Private Key
AES Encryption Key (BEK)

Decrypt
(Symmetric)
Clear Backup Data
Figure 5 - Tape read process

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
-7-
 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 that the reason for sharing RSA key pairs isn’t understood, you can’t recover
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:
-8-
Figure 6 - RSA private key missing error
Symantec recommendation: Best practice is to use the “cgadmin” export / import keys utility to
share keys between MSEO Security Servers.
-9-
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.
NetBackup
Master
Server
Security Key-pair1
Server
Media Server
VTD
PEM
Figure 7 - Small Configuration
- 10 -
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.
NetBackup
Master
Server
Security Key-pair1 Key-pair2

Server
Media Server 1
VTD
Media Server 2
PEM VTD
PEM
Figure 8: Medium Configuration
- 11 -
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.
NetBackup NetBackup
Master Master
PubKEY3 PubKEY4 PubKEY1 PubKEY2
Server Server
Security Security
Server Server
Key-pair1 Key-pair2 Key-pair3 Key-pair4
Media Server 1 Media Server 3
VTD VTD
Media Server 2 Media Server 4
PEM VTD PEM VTD
PEM PEM
Site 1 Site 2
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.
- 12 -
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.
- 13 -
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.
- 14 -
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?
Classifying data as “internal use only” versus data that needs to be shared assists in
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
and media storage costs. Likewise, encryption isn’t free, implying that further classification of data
may enable additional cost savings.
- 15 -
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.
In other situations, the review may yield results that aren’t quite as simple:
1) The environment consists of two NetBackup media servers with three storage units
2) The first NetBackup media server has two storage units, storage unit “A” has four tape
drives and storage unit “B” has six tape drives
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
MSEO may have on overall media server performance could result in backups that don’t
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 CPUs’ processing power.
- 16 -
However, when attempting to encrypt a lot of data, you can easily run into a CPU bottleneck if
you don’t carefully analyze the backup environment. It 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
doesn’t “just work” when software compression/encryption is used.
First, determine how much data must be backed up and the size of the backup window. That
determines the minimum sustained data rate (although it doesn’t take into account tape mounts
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
MB/sec to maintain streaming. If it doesn’t receive data at that minimum speed, the drive will
“shoeshine” as it must stop, rewind, reposition, 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 1.2 GHz processors won’t be able to keep a single drive streaming. Given the drive 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
don’t necessarily want to realize later that to encrypt all your data within the backup window you
must purchase a number of additional and expensive media servers.
7.2. Virtual tape driver Configuration

Tape drives are configured to work with MSEO via a command line utility. The “cgconfig”
command can be used to list, configure, or de-configure devices on a drive by drive basis.
Use the “cgconfig” command to configure drives individually as part of the phased deployment
methodology.
Executing “cgconfig list” provides information about the current configuration of tape drives:
- 17 -
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.
- 18 -
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:
- 19 -
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:
- 20 -
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:
- 21 -
Figure 16: Non-MSEO storage unit

The two NetBackup storage units:
Figure 17: One library containing two storage units
- 22 -
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
new or scratch media to the library, and performing an inventory operation. The “Advanced
Options” button 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
- 23 -
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.
- 24 -
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
Reference the NetBackup System Administrator’s Guide section titled, “Offline, Cold
Catalog Backup Method”. The catalog files tab provides the ability to include additional
- 25 -
paths that will be protected when catalog backups are performed. Add an entry that
represents the MSEO Security Server data store path: “…/cgsb/server”.
 NetBackup 6.0 online, hot catalog backups
Reference the NetBackup System Administrator’s Guide section titled, “Online, Hot
Catalog Backup Method”. The MSEO Security Server data store has to be relocated to
“…/NetBackup/db” for inclusion into a hot catalog backup policy. You must relocate the
MSEO Security Server data store to accommodate this requirement.
 NetBackup 5.1 offline, cold catalog backups
Reference the NetBackup System Administrator’s Guide section titled, “Configuring
Catalog Backups”. The catalog files tab provides 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 path: “…/cgsb/server”.
- 26 -
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 tapes on a media server. The default output is defined in the “netbackup” audit
template XML document. This document is referenced by the standard “default” MSEO policy
XML document.
The following is an example of an unaltered “netbackup” XML audit policy:
Figure 21: Audit template XML file

The default report format prints the MSEO policy name, key type, compression algorithm,
encryption key, and RSA key information in the log. Unix logs are written to the “cgsb.log” file.
Windows logs are written to the event log, as depicted in the following example:
Figure 22: Windows event log
- 27 -
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 templates reside at “…\cgsb\server\db\audit”. 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 “Built-in
variables” and “Enabling Audits” 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.
- 28 -
Note: All audit template variables are prefixed with the characters “po.”
Audit Template Variables
Variable
Description
Causes the list of key names from the key

po.allenckey
group in the MSEO policy to be logged.
Causes the compression type requested in the
po.compress
MSEO policy to be logged.
Causes the key group requested in the MSEO
po.enckey
policy to be logged.
Causes the encryption type requested in the
po.keytype
MSEO policy to be logged.
Causes the name of the MSEO policy being
po.name
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,
- 29 -
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.
- 30 -
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

Note that the MSEO policy (SebPolicy) contains an element named “SebRules”. The “SebRules”
element contains three additional elements that are tagged “SebRule”. Referred to as a security
rule, each “SebRule” element contains “Effect”, “Action”, “KeyType”, “Compress”, and “Key”. In
essence, 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:
 Effect = “permit audit netbackup”
Based on other components in the security rule, “Effect” includes the word “permit” which
grants permission to the subsequent action, “write”. This portion of the security rule
grants permission during write, or backup operations. The statement also includes the
word “audit”, and references an audit template named “netbackup”. The audit template is
another XML file that specifies what information will be logged for auditing and reporting
purposes.
 Action = “write”
This portion of the rule specifies the requested access method. Valid values are “read” or
“write”, which correspond to restore and backup.
 KeyType = “|netbackup.keyword.KeyType|”
This portion of the rule specifies what encryption method to use when writing data to
tape. The “|netbackup.keyword.KeyType|” variable is replaced with the value specified in
the NetBackup policy keyword phrase. For example, this value could be none, AES128,
or AES256.
 Compress = “|netbackup.keyword.Compress|”
- 31 -
This section specifies the compression algorithm to use. The

“|netbackup.keyword.Compress|” variable is replaced with the value specified in the
NetBackup policy keyword phrase. For example, this value could be none, lzrw3, lzo1x,
or text85.eng.
 Key = “default”
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 could be altered to specify an alternate key, such as “KeyGroup1”,
or the variable name “|netbackup.keyword.KeyGroup|” to use a valued specified in the
NetBackup 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 “empty” returns a match if the string
doesn’t exist or is null. In the case of the example MSEO policy, “!” is used prior to
“Empty”, indicating that the inverse of the operator “Empty” is to be used. This indicates
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:
- 32 -
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
keyword phrase of “<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.
- 33 -
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:
- 34 -
Figure 29: NetBackup policy

Note that a keyword phrase has been entered into the policy attributes “Keyword phrase:” field.
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 XML tags identifies the “KeyType” and
“Compress” variables that will be evaluated by the MSEO policy. It also specifies the use of a key
group named “KeyGroup1” in the case of this example.
- 35 -
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 A class of algorithms for cryptography that use trivially related cryptographic keys
Keys for both decryption and encryption. – AES 128 / 256
Asymmetric A form of cryptography which generally allows users to communicate securely
Keys 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 In cryptography, a public key certificate is a certificate which uses a digital
Certificate 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 A software driver that assumes the role and responsibilities of the physical tape
Driver 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 The process that is responsible for authenticating and authorizing the access to
Server the physical tape devices through the virtual tape driver.
MSEO A MSEO policy is a set of security rules. Each security rule is a collection of
Policies 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
packages, “MSEO-Agent” for PEM hosts and “MSEO-Server” for Security
Servers.
Table 2: Terminology
- 36 -
Key Type Description

Symmetric Master Key (SMEK) Protects all of the Keys.
Symmetric Master Key Protects the Master Key.
Passphrase
RSA Private Key Protects RSA Private Keys using Public Key Cryptography.
Passphrase
RSA Private Encryption Keys RSA Private Encryption Keys.
(PREK)
Master Lists all Private Key Passphrases and is encrypted by the
Master Key.
Passphrase File
Public / Private Generated and encrypted using a random master passphrase.
Key Pairs (KPAIR)
Public Encryption Keys Public Encryption Keys
(PEK)
Public Key Group Public Key Group
PubEK
File (Backup) File (Backup) Encryption Key, also referred to as Backup
Encryption Key (BEK).
Encryption Key (FEK)
Table 3: Key terminology
- 37 -
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.
- 38 -

MSEO BestPractices

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

MSEO BestPractices

Hochgeladen von

Copyright:

Verfügbare Formate

A guide to best practices for using the

NetBackup Media Server Encryption

Version number: 1.0

1.1. Introducing MSEO

1.2. What Types of Encryption are Available?

1.3. Choosing an Encryption Strength

2. MSEO Components & Architecture

Virtual Tape Driver

Real Tape Driver

Figure 1 - Component block diagram

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

2.1.1. MSEO Variables

2.1.2. MSEO Policies

Figure 2 - MSEO default policy

Figure 3 - Rule within MSEO default policy

2.2. Reading from Tape - Restore

3. Key Creation and Management

3.1. Key Primer

3.1.1. Where and How Different Encryption Methods are Used

Generate Random AES MSEO

Backup Media (Tape)

Backup Media Contents

Encrypted BEK AES Encrypted Backup Data

Decrypt with RSA

AES Encryption Key (BEK)

Clear Backup Data

Figure 5 - Tape read process

3.2. Managing RSA Key Pairs

3.3. Encrypting RSA Key Pairs

3.4. Sharing RSA Key Pairs Among Security Servers

Figure 6 - RSA private key missing error

4.1. Small Configuration

Figure 7 - Small Configuration

4.1.1. Small Configuration Data Points

4.2. Medium Configuration

Security Key-pair1 Key-pair2

Figure 8: Medium Configuration

4.2.1. Medium Configuration Data Points

4.3. Large Configuration

Media Server 1 Media Server 3

4.3.1. Large Configuration Data Points

5. Synchronizing MSEO installations

7.1. Performance Considerations

7.2. Virtual tape driver Configuration

Figure 10 - Tape Drive Listing

7.3. Default Tape Driver Configuration

7.4. Tape Library Partitioning

Figure 11: One MSEO tape drive configured

Figure 12: DLT drives

Figure 13: Changing drive type

Figure 14: Altered drive type

Figure 15: MSEO storage unit

Figure 16: Non-MSEO storage unit

Figure 17: One library containing two storage units

Figure 18: Media type pull down menu

Figure 19: Media type

Figure 20: Policy storage unit

8. Protecting the MSEO Security Server

Figure 21: Audit template XML file

Figure 22: Windows event log

Audit templates reside at “…\cgsb\server\db\audit”. The audit template is referenced by name in

Figure 23: MSEO policy referencing the NetBackup audit template