SSL Transport Encryption

Encryption At Rest

Encrypting Your Files

Bucky Backup also supports further encrypting backup data at the file level. This method is not enabled by default, so additional configuration is required. You can encrypt some or all of your data down to file level granularity. Encryption at rest generally covers most security requirements, but encrypting the files themselves can provide an additional barrier for highly sensitive data.

Once configured, the Bucky Backup client encrypts the data you have specified in the client before it hits the network. The data will be encrypted end-to-end, meaning both during transport over the network and while at rest on disk or tape. The Spectrum Protect client uses keys to encrypt your data. Unlike node passwords, encryption keys cannot be "reset", so if you forget or lose your key, your data is not retrievable (see below).

There are three methods available for your key storage:

• ENCRYPTKEY GENERATE - The key is automatically generated by the client and stored in the backup server database. This is the most used option.Your data will be encrypted during transport and while at rest, but you don't need to worry about losing the key. To restore your encrypted data you just need the node name and password. This method is slightly less secure than the others because the backup server admins, by virtue of being able to reset your node password, could restore your encrypted data. On the other hand, if you are restoring encrypted data to a different machine, a freshly reinstalled machine, or in a bare machine recovery, you don't need to know the key. This is the least secure, but easiest to use method of key encryption.
• ENCRYPTKEY SAVE - You create the key, and it is stored locally. The TSM client will use the stored key whenever it needs to, including during scheduled backups. You'll need to run at least one manual backup so you can enter and save the key. After that, you will only need to re-enter the key if the saved key is unavailable. For example, if you need to perform a bare metal recovery, or if you are restoring files to a different machine. Neither the server admins nor anyone who is able to guess your node's password would be able to restore the encrypted data without also knowing the key, but since it is saved other local admins would be able to do backups and restores of the encrypted data. We recommend you use some sort of key escrow so your data can be recovered in the event of a disaster. 
• ENCRYPTKEY PROMPT - You create the key and enter it every time you transfer encrypted data. This is a problem for scheduled backups that send over encrypted files, because the scheduler will stop with a prompt asking for the encryption key, and the backup will fail at that point. If your prefer this option you should exclude your encrypted files from the scheduled backups and back them up manually. Neither the server admins nor anyone who is able to guess your node's password would be able to restore the encrypted data without knowing the key. This is the most secure, but least convenient method of key encryption. We recommend you use some sort of key escrow so your data can be recovered in the event of a disaster.

Which Type of Key Encryption to Use:

• Most people choose ENCRYPTKEY GENERATE because it's the easiest and least likely to prevent you from restoring your data and the data is encrypted from end-to-end. You don't need to know what the key is since it's stored in the server database and will be given to the client as needed.
• Trust required: Other local admins and backup server admins.
• The next most used option is ENCRYPTKEY SAVE because it adds another layer of security to your backups but is still convenient to use. Scheduled backups are still possible. The only time you need to know the key is usually in the case of a disaster recovery, otherwise the client can access the key from the local save file.
• Trust required: Other local admins.
• You are responsible for keeping track of the encryption key. If you lose it, your backed up data is not retrievable.
• The most secure option is ENCRYPTKEY PROMPT. Only you, or others, that know the encryption key can run backups or retrieve files. Scheduled backups are not possible for encrypted files.
• Trust required: Yourself or anyone you share the key with.
• You are responsible for keeping track of the encryption key. If you lose it, your backed up data is not retrievable.
• Tip: If you want this level consider excluding those files from regular backup. You could either back them up manually or create and use the separate node to backup the files that need to be encrypted. 
• WARNING: Each time you run a backup you can type in a different key. Be very careful that you keep track of what data was backed up with which key or it will be impossible to restore your data. It's highly recommended to always use the same key and to use copy and paste to ensure that it's correct.

How to Use Key Encryption:

• You need to set the ENCRYPTKEY option for your client. You can do this by editing the relevant file directly or by changing the option in the graphical client.
• GUI
• Start the client and go to the preferences editor under the "Edit" menu.
• On the "Authorization" tab, choose the options for "Encryption Key Password" and "Encryption Type".
• Edit the config manually
• Open the dsm.opt (Windows) or dsm.sys (UNIX/Linux) file in your favorite editor.
• Add the ENCRYPTKEY key option you prefer if it doesn't already exist on a new line, for example: ENCRYPTKEY GENERATE
• Add "ENCRYPTIONTYPE AES256" if it doesn't already exist.
• Add "INCLUDE.ENCRYPT" statements to the dsm.opt (Windows) or dsm.sys or inclexcl file (UNIX/Linux). See Bucky Backup - Includes and Excludes in TSM .
• Restart your TSM Scheduler service after saving changes.
• If you are using GENERATE, you are done.
• If you are using SAVE, you will need to run a manual backup so that you can enter a key that will be saved locally. 
• The best way is to run "dsmc incr" from the command line. Full path and admin rights may be required.
• If you are using PROMPT, you always need to do your backups/restores manually.

Tips

• Use COMPRESSION YES. The compression will happen in the client before the encryption so it may save you some money. Once the files are encrypted the server cannot compress or deduplicate them.
• Be aware that encryption uses a little more CPU during the backup process.
• We recommend only encrypting files that are highly sensitive. Encrypted files look completely random to the server and cannot be deduplicated. Deduplication saves everyone money. If everyone started encrypting all of their backups, costs would go up as a result.
• If you're not using GENERATE, you should store your key somewhere safe in case you forget the key. We recommend some type of key escrow on another machine in a different physical location.

INCLUDE.encrypt Examples

• To encrypt all files:
• Windows: include.encrypt ?:\...\*.*
• UNIX: include.encrypt /.../*
• To encrypt a specific file:
• Windows: include.encrypt C:\path\to\file.txt
• UNIX: include.encrypt /path/to/file.txt
• To encrypt all files in a directory and it's sub-directories:
• Windows: include.encrypt C:\path\to\directory\...\*.*
• UNIX: include.encrypt /path/to/directory/.../*

For more information on include/exclude statements, please see: Bucky Backup - Includes and Excludes in TSM