NetBackup™ Security and Encryption Guide
- Read this first for secure communications in NetBackup
- Communication failure scenarios
- Increasing NetBackup security
- Security deployment models
- Auditing NetBackup operations
- About audit events
- Section I. Identity and access management
- About identity and access management
- AD and LDAP domains
- Access keys
- API keys
- Auth.conf file
- Role-based access control
- Default RBAC roles
- Smart card or digital certificate
- Single Sign-On (SSO)
- Enhanced Auditing
- NetBackup Access Control Security (NBAC)
- Configuring NetBackup Access Control (NBAC)
- Configuring Access Control host properties for the primary 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 primary server
- Verification points in a mixed environment with a Windows primary server
- About determining who can access NetBackup
- Viewing specific user permissions for NetBackup user groups
- Section II. Encryption of data-in-transit
- NetBackup CA and NetBackup certificates
- About the Security Management utilities
- About host management
- Adding shared or cluster mappings
- Allowing or disallowing automatic certificate reissue
- 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 NetBackup certificate deployment security levels
- Setting up trust with the primary 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
- Host ID-based certificate deployment in a clustered setup
- About deployment of a host ID-based certificate on a clustered NetBackup host
- Migrating NetBackup CA
- Configuring data-in-transit encryption (DTE)
- Configure the DTE mode on a client
- Modify the DTE mode on a backup image
- How DTE configuration settings work in various NetBackup operations
- External CA and external certificates
- About external CA support in NetBackup
- Configuration options for external CA-signed certificates
- ECA_CERT_PATH for NetBackup servers and clients
- About certificate revocation lists for external CA
- About certificate enrollment
- Configuring an external certificate for the NetBackup web server
- About external certificate configuration for a clustered primary server
- Regenerating keys and certificates
- NetBackup CA and NetBackup certificates
- Section III. Encryption of data at rest
- 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
- NetBackup key management service
- About FIPS enabled 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
- External key management service
- Configuring KMS credentials
- Configuring KMS
- Creating keys in an external KMS
- Working with multiple KMS servers
- Data at rest encryption security
- Ciphers used in NetBackup for secure communication
- FIPS compliance in NetBackup
- Disable FIPS mode for NetBackup
- NetBackup web services account
- Running NetBackup services with non-privileged user (service user) account
- Running NetBackup commands with non-privileged user account
- Immutability and indelibility of data in NetBackup
- Backup anomaly detection
- Section IV. Malware scanning
About immutable and indelible data
NetBackup protects your data from being encrypted, modified, and deleted using WORM properties.
WORM is the acronym for Write Once Read Many.
WORM properties provide two additional levels of security for backup images:
Immutability - this protection ensures that the backup image is read-only and cannot be modified, corrupted, or encrypted after backup.
Indelibility - this property protects the backup image from being deleted before it expires. The data is protected from malicious deletion.
Configuring these WORM properties protects your data from certain malware attacks to some extent, for example ransomware.
NetBackup provides the ability to write backups to WORM storage devices so their data cannot be corrupted. Additionally, it lets you take advantage of advanced options available from your storage vendors to ensure backups are retained unaltered on storage platforms to meet regulatory and compliance requirements.
All NetBackup image copies have an Expiration Time. This time is calculated by using the configured retention level in the schedule and the start time of the backup job.
When a NetBackup image is written to a WORM-enabled storage unit, the data cannot be altered or deleted until the WORM Unlock Time for that image has elapsed. Unlike the Copy Expiration time that is calculated from the start time of the backup job, the WORM Unlock Time is associated with the WORM storage. The WORM Unlock Time value is calculated using the configured retention level and the write completion timestamp for the backup image onto WORM storage.
When you use bpimagelist to view an image that is written to WORM storage, the timestamp that is associated with the Copy Expiration time precedes the WORM Unlock Time for that copy of the backup image. For longer-running backups or duplication jobs, the difference is greater between Copy Expiration Time and WORM Unlock Time.
As part of normal operations, copies of backup images on WORM storage are not removed from the catalog and storage until both Copy Expiration Time and Worm Unlock Time timestamps have elapsed. The WORM Unlock Time of a copy that is written to WORM storage can only be extended and cannot be shortened. To extend the expiration date, use the bpexpdate -extend_worm_locks command.
In special circumstances, the bpexpdate -try_expire_worm_copy option can be used to force an attempted removal of a WORM indelible image from the NetBackup catalog. This option is only recommended to be used after removing WORM locks directly on the storage device. Only use this option with assistance from Veritas technical support.
When duplicating an image onto WORM storage, the WORM Unlock Time can be configured to match the Copy Expiration Time by running the bpduplicate command using the -worm_unlock_match_expiration option that was introduced in NetBackup 10.1.
If older backup images are duplicated to WORM storage without using this command option, the WORM Unlock Time for the duplicated copy is calculated using the configured retention level, and the timestamp when the duplication job was complete.
The bpduplicate -worm_unlock_match_expiration command option is not used for SLP driven duplications. For SLP driven duplications, the retention period is applied from the end of the duplication job to calculate WORM Unlock Time of the new copy. The Copy Expiration Time for the new copy is calculated from the retention period that is applied to the backup time (for copy 1).
For AIR jobs, the retention period is applied from the end of the import job to calculate the WORM Unlock Time of the imported copy. The Copy Expiration Time is calculated as the retention period that is applied from the beginning of the import job.
For more information about the bpduplicate command and the bpexpdate command, see the NetBackup Commands Reference Guide.
Note:
When you use the bpduplicate -worm_unlock_match_expiration and bpexpdate -extend_worm_locks command options, they rely on the accuracy of the NetBackup primary server clock. That is because the WORM Unlock Time mirrors the Image Expiration timestamp for that copy.
For more information about how to base the WORM Unlock Time on the original backup time, see the following knowledge base article:
Images duplicated to WORM storage have unlock time calculated from duplication date not backup date