Veritas NetBackup™ Security and Encryption Guide
- Increasing NetBackup security
- Security deployment models
- Port security
- About NetBackup daemons, ports, and communication
- Additional port information for products that interoperate with NetBackup
- About configuring ports
- Auditing NetBackup operations
- Configuring Enhanced Auditing
- Access control security
- NetBackup Access Control Security (NBAC)
- Configuring NetBackup Access Control (NBAC)
- Configuring Access Control host properties for the master and media server
- Access Control host properties dialog for the client
- Troubleshooting Access Management
- Windows verification points
- UNIX verification points
- Verification points in a mixed environment with a UNIX master server
- Verification points in a mixed environment with a Windows master server
- About determining who can access NetBackup
- Viewing specific user permissions for NetBackup user groups
- Security management in NetBackup
- About the Security Management utilities
- About audit events
- About host management
- Adding shared or cluster mappings
- About global security settings
- About host name-based certificates
- About host ID-based certificates
- Using the Certificate Management utility to issue and deploy host ID-based certificates
- About certificate deployment security levels
- Setting up trust with the master server (Certificate Authority)
- About reissuing host ID-based certificates
- About Token Management for host ID-based certificates
- About the host ID-based certificate revocation list
- About revoking host ID-based certificates
- Security certificate deployment in a clustered NetBackup setup
- About deployment of a host ID-based certificate on a clustered NetBackup host
- Data at rest encryption security
- About NetBackup client encryption
- Configuring standard encryption on clients
- About configuring standard encryption from the server
- Configuring legacy encryption on clients
- About configuring legacy encryption from the client
- About configuring legacy encryption from the server
- Additional legacy key file security for UNIX clients
- Data at rest key management
- About the Key Management Service (KMS)
- Installing KMS
- Configuring KMS
- About key groups and key records
- Overview of key record states
- Configuring NetBackup to work with KMS
- About using KMS for encryption
- KMS database constituents
- Command line interface (CLI) commands
- About exporting and importing keys from the KMS database
- Troubleshooting KMS
- Regenerating keys and certificates
- NetBackup web services account
Data at rest encryption considerations
The following table describes the data at rest encryption limitations.
Table: Data at rest encryption limitations
Limitation | Description |
---|---|
Computer performance effect of data encryption | Encryption algorithms are like data compressions algorithms in that they are very CPU intensive. Compressing data without the addition of computer hardware (either dedicated or shared), can affect computer and NetBackup performance. |
Data compression must be performed before data encryption | Data compression algorithms look for data patterns to compress the data. Encryption algorithms scramble the data and remove any patterns. Therefore if data compression is desired, it must be done before the data encryption step. |
Choice of an encryption algorithm | There are many encryption algorithms and associated key sizes. What should a user choose for data encryption? AES (Advanced Encryption Standard) is the standard for data encryption and supports 128, 192, or 256 -bit encryption keys. |
Suggested key size | Generally, the larger key the more secure, and the longer into the future the data will stay secure. AES is one of the best choices because it is deemed secure with all three supported (128, 192, 256 bit) key sizes. |
FIPS certification for my encryption solution | While FIPS certification may be required for use by the US government, it should not be the only criteria that is used to evaluate an encryption solution. Other considerations should be part of any decision-making process as follows:
|
Appropriate encryption key granularity | The appropriate encryption key granularity is best explained with the example of home security. A single house key is convenient. You can enter the garage, front door, or backdoor all using the same key. This security is good until the key is compromised (for example, if the key is stolen). Then you need to change all the locks that used the key. An extreme example is to have a key for every drawer and cupboard in a house. Then, a lost key would require the changing of on a single lock. The correct solution is somewhere in between. You must understand your tolerance for a compromised or lost key from your business process perspective. A lost key implies all the data that is encrypted with that key is destroyed. A compromised key implies all the data that is encrypted with that key must be decrypted and reencrypted to become secure. |