Veritas 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
- API keys
- Auth.conf file
- Role-based access control (RBAC)
- 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 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
- 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 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
- 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
- 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 master 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
- 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
- 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
- NetBackup web services account
- Immutability and indelibility of data in NetBackup
Setting up trust with the master server (Certificate Authority)
Each NetBackup host must first trust the NetBackup master server, which acts as the Certificate Authority (CA). Trust is essential so that the host can request a host ID-based certificate. The CA certificate can be used to authenticate other hosts in the domain, and is stored in the trust store of each host. Setting up trust involves requesting a certificate from the master server.
See Automatic host ID-based certificate deployment.
Run the nbcertcmd -listCACertDetails command to see the list of CA certificates that are in the host's trust store. The output displays all of the master servers that the host already trusts.
To establish trust with the master server (CA)
- The host administrator must have the Root Certificate Fingerprint that was communicated to them through an authentic source. The source was most likely the master server administrator, who communicated the fingerprint by email, by file, or on an internal website. The following topic describes that process:
See Finding and communicating the fingerprint of the certificate authority.
- From the NetBackup host, run the following command:
nbcertcmd -getCACertificate -server master_server_name
- In the confirmation output, enter y to proceed.
For example:
nbcertcmd -getCACertificate -server master1 Authenticity of root certificate cannot be established. The SHA1 fingerprint of root certificate is B8:2B:91:E1:4E:78:D2: 25:86:4C:29:C5:92:16:00:8D:E8:2F:33:DD.
Note:
Are you sure you want to continue using this certificate ? (y/n): y The validation of root certificate fingerprint is successful. CA certificate stored successfully.
- Next, the administrator performs the following task:
For information about this command, see the NetBackup Commands Reference Guide.
The NetBackup Administration Console and the Backup, Archive, and Restore user interfaces communicate with NetBackup hosts (master server, media server, or client) over a secure channel. NetBackup secures this channel using a NetBackup host ID-based or a host name-based security certificate that the NetBackup Certificate Authority (CA) issues.
Figure: Message inquiring whether to add a Certificate Authority (CA) to the trust store displays in the NetBackup Administration Console in the following situation: A user is running the NetBackup Administration Console on a NetBackup host. The user tries to connect to another NetBackup host (a target host) using the NetBackup Administration Console. However, the CA that issued the security certificate to the target host is not in the trust store of the host where the user launched the console.
To verify the CA fingerprint that the dialog displays, see the following topic:
See Finding and communicating the fingerprint of the certificate authority.
If the user selects Yes in this message, the CA is added to the trust store of the host where the console is running. This host will then trust all hosts that have a certificate signed by the CA that is listed in the message.