Oracle® Secure Backup Administrator's Guide Release 10.2 Part Number E05407-02 |
|
|
View PDF |
The security of your backup tapes is extremely important, because they typically contain your most important data stored in one localized, compact, and easily transportable medium. You can have the most secure set of protection policies, a firewall, passwords, and retina scanners to protect access to data. But if your data is backed up on a portable storage medium in an unencrypted fashion, and if that storage medium leaves the security of your media room, then your security model breaks down.
Backup Encryption is an optional and highly configurable Oracle Secure Backup mechanism that ensures that data stored on tape is safe from prying eyes. Backup encryption is fully integrated with Oracle Secure Backup and is ready to use as soon as Oracle Secure Backup is installed. Backup encryption applies to both file system data and Recovery Manager (RMAN) generated backups.
Note:
Encryption is not supported for volume duplication, volume migration, or media management. For more information on these topics, see Chapter 9, "Vaulting".Backup encryption provides the backup administrator with the means to ensure that all client data that is written to tape is encrypted. It is not intended to enable an individual user to decide which of their data is encrypted or how it is encrypted. Nor is it meant to protect one user's data from another user. If you must encrypt data for individual users at the hard drive level, then Oracle recommends you use an operating system that provides built in encryption at the file system level, such as that provided by Windows with Encrypted File System (EFS), or a product such as PGP.
This chapter contains these sections:
Backup encryption is designed to be easy to implement. At its simplest the backup administrator is required to change just one global policy, and all data from each client is encrypted. For larger enterprises and for those backup administrators who wish to optimize their backup domain, backup encryption offers a large degree of configuration flexibility.
For file system backup, encryption can be selected for the entire administrative domain, a specific client, or even a specific backup job. The hierarchy of decisions going from highest precedence to lowest precedence for the encryption setting is global, client, job. If backup encryption is enabled at the global level, then the data coming from all clients and all jobs is encrypted. If the global policy does not enforce encryption, then the client encryption setting determines if encryption is performed. If the client does not require encryption, then the decision for encryption is deferred to the job level.
The global and client encryption policies have two possible settings:
required
All data coming from this backup domain or this client must be encrypted.
allowed
The decision to encrypt is deferred to the next lower priority item.
In general, encryption of Recovery Manager (RMAN) data follows the same rules as that of file systems. One difference is if the RMAN data coming out of the SBT interface is encrypted, then there is no further encryption. Another difference is that you cannot turn encryption on for one RMAN backup, because the job is created on the fly.
Note:
If a host is configured for encryptionrequired
, and if RMAN backup encryption is not enabled, then Oracle Secure Backup encrypts the RMAN backups using Oracle Secure Backup encryption based on the host encryption configuration. However, if RMAN backup encryption is enabled, then Oracle Secure Backup is aware that the backup is encrypted. This RMAN encryption satisfies the required
encryption policy for this host, and no other host encryption settings are honored by Oracle Secure Backup. Oracle Secure Backup specifically does not honor rekey duration, encryption algorithm or key generation settings in this situation.You can disable Oracle Secure Backup encryption with RMAN parameter OB_ENCRYPTION_FORCED_OFF
.
See Also:
Oracle Database Backup and Recovery User's Guide for more informationThe encryption algorithm is inherited from the global default policy and can be overridden at the client level. Each client can use a different encryption algorithm. For example, a payroll computer can use a higher level of encryption than a test lab computer. The supported encryption algorithms are:
AES128
AES192
AES256
Note:
The backup encryption algorithm cannot be selected at the job level.A client rekeyfrequency
policy defines when a new key is generated. For example, the policy might require that a new set of keys be generated every 30 days. Older keys are retained in a wallet-protected key store. This ensures that if a key or wallet and the associated backup tape are compromised, then only older data could be unencrypted. The default rekeyfrequency
policy for a client is inherited from the global rekeyfrequency
policy.
Keys can be generated either automatically or with a passphrase. The suggested mode of operation and default value is automatic generation. Each newly created client gets an automatically generated key during the mkhost
phase. This key is added to the wallet-protected key store that is specific for this client, and it remains valid for encryption until:
A key renewal event occurs
The backup administrator manually renews an automatically generated key
The backup administrator changes the key to a passphrase while providing a new passphrase
The passphrase is never stored anywhere. The hash of the passphrase and the key generated from the passphrase are stored in the encrypted store. Oracle Secure Backup does not enforce a minimum length for a passphrase.
Once the new key is created, it is added to the wallet-protected key store and marked as the active encryption key. Old encryption keys are left in the key store and used for automatic and seamless decryption of data. If clients are removed from the backup domain, then their key stores are still retained on the administrative server. This ensures that the backup administrator can always restore data no matter the age of the encrypted backup volume set.
Note:
There is one exception case where a key is not automatically added to the wallet. Keys for transient backups are effectively one-use keys and are not usually stored in the wallet. The backup administrator can override this behavior through a command line option. See "Transient Backups" for more information on transient backups.When a key expires, a new key is automatically generated. For passphrase generated keys, on the other hand, there is some overhead for the backup administrator, who must type in a passphrase for each client that is using passphrase-generated keys. When a passphrase-generated key expires, Oracle Secure Backup generates a warning message stating that the backup administrator must update the passphrase for the stated client. This message is placed in the Oracle Secure Backup log files, the display output, and an email to the backup administrator.
Once backup encryption is enabled, all data is encrypted using the defined encryption algorithm. The data is encrypted before it leaves the client. The encryption keys are stored in a mechanism that is protected by the Oracle Secure Backup wallet.
The administrative server is considered a secure host. All keys and wallet-protected key stores for all clients are stored on this protected computer. When a backup or restore job is started, the encryption key is passed over a Secure Sockets Layer (SSL) connection to the client that is encrypting or decrypting data. The encryption keys are retained in memory only so long as needed to perform the encryption or decryption.
The encrypted key stores are extremely valuable, because they enable encryption and decryption of all tapes. If the key stores are lost, then all data would also be lost. It is a best practices task for the backup administrator to ensure that the encrypted key stores are backed up. This should be easy to accomplish, because the encrypted key stores reside within a file system branch that should already be backed up as a best practices task. The encrypted key store format is platform independent.
Backups of Oracle Secure Backup administrative data must not be encrypted with an automatically generated key. If the administrative data were encrypted with a automatically generated key, and if the administrative server were destroyed, then there would be no way to get back the decryption key used to encrypt the encryption keys. A backup of the administrative server tree should be done using a transient backup.
Data is encrypted at the client level. Each client has its own set of keys. One key is the active key used for encrypting new backups. Older keys are used to seamlessly restore older backups that were created with those keys.
Note:
Oracle Secure Backup does not encrypt backups of Network Attached Storage (NAS) devices. Oracle Secure Backup encryption is performed on the client host where Oracle Secure Backup software has been installed. Because backup software cannot be installed directly on NAS devices, Network Data Management Protocol (NDMP) is used for backup and restore operations.There might be times when the backup administrator must back up a set of data from backup domain Site A and restore it at another backup domain Site B. The backup set might contain backup files for several clients. Each of these client backup files is encrypted to a client-specific encryption key, which was most likely used in recent backups at Site A. In order for Site B to decrypt the data, the backup administrator would have to collect all keys used in encrypting the data at Site A and then ship those keys to Site B.
This would be a serious threat to security, because these keys were used in other recent backups. Oracle Secure Backup enables cross-site backup encryption without this security threat by encrypting data at the volume set level for a given backup job. The key for this volume set encryption is based on a passphrase. The data is encrypted against this passphrase-generated key for all clients that are part of this backup job. The backup administrator of Site A gives the passphrase and encryption algorithm used to Site B. The passphrase and encryption algorithm are provided when Site B does the restore operation, and the data can be decrypted.
In all other cases, the encryption keys for backup encryption are automatically added to the appropriate wallet-protected key store. A transient key, however, is a one-time key used mainly for moving data to a remote location. Transient encryption keys, therefore, are not stored in the protected key stores by default. Oracle Secure Backup does provide an option to the backup administrator to store the transient encryption key in the key store.
See Also:
Oracle Secure Backup Reference for complete syntax and semantics of the obtoolbackup
commandOracle Secure Backup enables the backup administrator to do a one-time unencrypted backup without changing global or client encryption settings.
Suppose the backup administrator is planning to move all home directories from one host to another and does not want to copy files directly between these two hosts. The backup administrator wants instead to back up a dataset worth of data to a tape, restore it to the new host, and immediately destroy the tapes or the contents of the tapes after the transfer. The backup administrator does not want to use encryption because of the processing overhead that occurs.
In this special case, the backup administrator can use the backup
--encryption
forcedoff
command. This command overrides global and client encryption settings and performs an unencrypted backup. Transcripts and all other reports for this job then state that encryption was forcibly disabled for this backup set. There is a similar mechanism available to RMAN backups using the OB_ENCRYPTION_FORCED_OFF
variable from within RMAN.
See Also:
Oracle Secure Backup Reference for complete syntax and semantics of the obtoolbackup
commandBy default the initial global and client backup encryption policy settings are allowed
. Encryptions keys are generated automatically with a default AES192 encryption algorithm. If the backup administrator decides that the default configuration is sufficient for the enterprise, then no configuration is required. This section describes the configuration of a more complicated case.
In this more complicated enterprise, there are three classes of hosts that need differing types and amount of encryption:
Developers
These clients require encryption only for source code backup operations in a dataset called sourcecode.
Payroll
This client requires AES256 encryption with a new encryption key each week.
CEO
This client requires all data to be encrypted using a passphrase-generated key.
There are no options that must be changed for developer clients. The backup administrator instead updates the backup job for the sourcecode dataset that is used to back up the developer computers. If the backup schedule does not yet exist, then the backup administrator creates a new backup schedule with a mkhost
command:
mksched --dataset sourcecode --type backup --encryption yes SourceCode
If the backup schedule already exists, then the backup administrator uses the chsched
command with the same options specified.
The payroll host requires changes to the default client policies and settings for the encryption algorithm, key regeneration time, and client encryption flags. The backup administrator can make these changes with a chhost
command:
chhost -algorithm aes256 -encryption required -rekeyfrequency 1week Payroll
This will ensure that all data from the payroll client is always encrypted to the AES256 algorithm with a new key encryption key each week.
The default encryption is sufficient for the CEO client, but the backup administrator must change the encryption key type to passphrase-generated. This can be done with another chhost
command:
chhost --keytype passphrase -passphrase "What's my password?" TheBoss
Once the initial configuration has been performed there is minimal additional overhead managing backup encryption.
The encryption state is displayed as part of the job transcript during a backup operation for both file system and RMAN backups.