NetBackup and Veritas Appliances Hardening Guide
- Top recommendations to improve your NetBackup and Veritas appliances security posture
- Introduction
- Keeping all systems and software updated
- Enabling multifactor authentication
- Enabling multiperson authorization
- Increasing the security level
- Implementing an immutable data vault
- Securing credentials
- Reducing network exposure
- Enabling encryption
- Enabling catalog protection
- Enabling malware scanning and anomaly detection
- Enabling security observability
- Restricting user access
- Configuring a sign-in banner
- Steps to protect Flex Appliance
- About Flex Appliance hardening
- Managing multifactor authentication
- Configuring the multi-factor authentication on NetBackup primary and media server instance
- Configuring the multi-factor authentication on NetBackup WORM storage server instance
- Managing single sign-on (SSO)
- Managing user authentication with smart cards or digital certificates
- About lockdown mode
- Using network access control
- Using an external certificate
- Forwarding logs
- Creating a NetBackup WORM storage server instance
- Configuring an isolated recovery environment using the web UI
- Protecting the NetBackup catalog on a WORM storage server
- Using a sign-in banner
- Steps to protect NetBackup Appliance
- About NetBackup Appliance hardening
- About multifactor authentication
- About single sign-on (SSO) authentication and authorization
- About authentication using smart cards and digital certificates
- Disable user access to the NetBackup appliance operating system
- About Network Access Control
- About data encryption
- FIPS 140-2 conformance for NetBackup Appliance
- About implementing external certificates
- About antimalware protection
- About forwarding logs to an external server
- Creating the appliance login banner
- Steps to protect NetBackup
- About NetBackup hardening
- About multifactor authentication
- Configure NetBackup for single sign-on (SSO)
- Configure user authentication with smart cards or digital certificates
- Workflow to configure multi-person authorization for NetBackup operations
- Access codes
- Workflow to configure immutable and indelible data
- Add a configuration for an external CMS server
- Configuring an isolated recovery environment on a NetBackup BYO media server
- About FIPS support in NetBackup
- Installing KMS
- Workflow for external KMS configuration
- Validating KMS credentials
- Configuring KMS credentials
- Configuring KMS
- Creating keys in an external KMS
- Workflow to configure data-in-transit encryption
- Workflow to use external certificates for NetBackup host communication
- About certificate revocation lists for external CA
- Configure an external certificate for the NetBackup web server
- Configuring the primary server to use an external CA-signed certificate
- Configuring an external certificate for a clustered primary server
- Configuring a NetBackup host (media server, client, or cluster node) to use an external CA-signed certificate after installation
- Configuration options for external CA-signed certificates
- ECA_CERT_PATH for NetBackup servers and clients
- ECA_TRUST_STORE_PATH for NetBackup servers and clients
- ECA_PRIVATE_KEY_PATH for NetBackup servers and clients
- ECA_KEY_PASSPHRASEFILE for NetBackup servers and clients
- ECA_CRL_CHECK for NetBackup servers and clients
- ECA_CRL_PATH for NetBackup servers and clients
- ECA_CRL_PATH_SYNC_HOURS for NetBackup servers and clients
- ECA_CRL_REFRESH_HOURS for NetBackup servers and clients
- ECA_DISABLE_AUTO_ENROLLMENT for NetBackup servers and clients
- ECA_DR_BKUP_WIN_CERT_STORE for NetBackup servers and clients
- MANAGE_WIN_CERT_STORE_PRIVATE_KEY option for NetBackup primary servers
- Guidelines for managing the primary server NetBackup catalog
- About protecting the MSDP catalog
- How to set up malware scanning
- About backup anomaly detection
- Send audit events to system logs
- Send audit events to log forwarding endpoints
- Display a banner to users when they sign in
- Steps to protect NetBackup Flex Scale
- About NetBackup Flex Scale hardening
- About the security meter
- STIG overview for NetBackup Flex Scale
- FIPS overview for NetBackup Flex Scale
- Managing the login banner
- Changing the password policy
- Support for immutability in NetBackup Flex Scale
- Authenticating users using digital certificates or smart cards
- About system certificates on NetBackup Flex Scale
- Deploying external certificates on NetBackup Flex Scale
- About multifactor authentication
- Considerations before configuring multifactor authentication
- Configuring multifactor authentication for your user account
- Disabling multifactor authentication for your user account
- Enforcing multifactor authentication for all users
- Configuring multifactor authentication for your user account when it is enforced in the cluster
- Resetting multifactor authentication for a user
- About single sign-on (SSO) configuration
Deploying external certificates on NetBackup Flex Scale
You can generate and use external certificates instead of internal certificates. External Certificate Authority (ECA) certificates are the digital credentials that attest to the certificate owner's identity and affiliation. Once you deploy the external certificates, all the NetBackup Flex Scale components use them. These include the NetBackup primary server, media server, storage engine, management gateway, and the NetBackup Flex Scale web services. One certificate is deployed for all the components. The external certificates also deploy a certificate bundle and (optionally) certificate revocation list. To generate an external certificate, you have to create a certificate request with proper 'Subject Distinguished Name' and 'Subject Alternative Names.' You can generate a certificate request using the GUI. The necessary FQDNs are auto-populated to generate the correct request. You can add additional information as needed. Based on the certificate request, you can create an external certificate. When deploying external certificate for the first time, you have to provide a CA certificate bundle. This is used to validate the incoming and deployed external certificate. You can also optionally provide a certification revocation list. NetBackup components use the CRL.
Some important terminologies:
A certificate authority, also known as a certification authority, is a trusted organization that verifies websites (and other entities) so that you know who you are communicating with online. Their objective is to make the internet a more secure place for both organizations and users. Becoming a Certificate Authority (CA) means that you (or your customers) oversee the issuing process of cryptographic pairs of private keys and public certificates.
Certificate bundle (CA bundle) is a file that contains root and intermediate certificates. The end-entity certificate along with a CA bundle constitutes the certificate chain.
Certificate Revocation List (CRL) is a list of digital certificates that have been revoked by the issuing Certificate Authority (CA) before their scheduled expiration date and should no longer be trusted. CRL is optional. It may be provided as a file or embedded in certificate as a URL.
Subject Alternative Name: This field lets you specify additional host names (such as sites, IP addresses, common names) to be protected by a single SSL certificate. They are added to generate certificates for new nodes or additional VLAN IPs to be added in the future.
Considerations while deploying ECA:
All certificates for communication should be obtained from a common trusted CA. Auto Image Replication (AIR) between MDSPs that uses different external CAs is not supported but you can concatenate the individual root CA certificates into one file and upload them as a CA bundle.
After ECA is deployed on the cluster, you can renew or update the ECA.
It is recommended to pause backup/restore operations before starting ECA deployment/renewal.
The CA bundle and CRL file independent of other security artifacts.
When you deploy security artifacts, they are validated and if inconsistencies are found, you are notified, and deployment does not proceed. If you provide an external certificate and CA certificate bundle, the EC certificate is validated against the user provided CA certificate bundle. If only one of the items is provided, it is validated against deployed artifacts.
Only NetBackup Certificate Authority (NBCA) + ECA deployment is supported in this release.
You cannot revert to NBCA deployment once NBCA + ECA deployment is done.
You do not get any alert for NBCA expiry or renewal. An event is raised when NBCA is about to expire and renewed in the background.
NBCA is auto renewed 60 days before expiration.
If NBCA renewal fails, a failed task can be seen on NetBackup Flex Scale GUI.
You are notified 60 days before the expiration of the ECA certificates. An alert appears on the appliance GUI and an email is also sent.
You can deploy external certificate only if all NetBackup Flex Scale components are up and running. These include NetBackup primary and media services, storage engines, management gateway, and NetBackup Flex Scale management web services.
You cannot deploy security artifacts, if upgrade, add node or VLAN operation is in progress and vice versa.
If the ECA's subject alternative names have information on new nodes (FQDNs) to be added, add node operation succeeds seamlessly and all services come up after the add node operation. If subject alternative names are not updated, add node operation fails.
For Nutanix, HBase workloads using SSL certificates, append the respective SSL certificates to the CA bundle after ECA certificates are renewed. If you do not append the SSL certificates to the CA bundle during ECA renewal, backup and restore operations for the workloads may fail.
If you want to deploy ECA on a cluster on which disaster recovery is already configured, ensure that you configure ECA on the primary cluster.
If ECA is deployed on the primary cluster before adding the secondary cluster, then you must redeploy ECA from the primary cluster after disaster recovery configuration is complete. This is to ensure proper connectivity between the primary server, media server, and storage services.
If CRL mode is selected as CRL URL during ECA deployment, ensure that the CRL URL host name is resolvable by the existing DNS servers. If there are no DNS servers or if the DNS server cannot resolve the CRL URL host name, you must add the CRL URL as a custom host entry for the NetBackup container and the cluster nodes. This is also applicable if a DNS server is present during ECA deployment but is removed later.
If you do not want to generate CSR from the GUI, then you can use your own certificate for ECA deployment. In such a scenario, you must upload your own unencrypted private key.
If ECA is configured with the CRL as an URL, and if the CRL server becomes unreachable or unavailable for more than 24 hours for any reason, the NetBackup services on the NetBackup Flex Scale cluster appears as degraded. Once the connectivity to the CRL server is established again, the NetBackup services appear as healthy.
Considerations while deploying ECA on a cluster on which only media server is deployed:
There are some additional considerations that you need to keep in mind when you deploy ECA on a media server only cluster.
If you have deployed media server only clusters with external NetBackup primary server on BYO:
If ECA deployment is done after media server only configuration:
The primary server should be configured in ECA + NBCA mode before starting ECA deployment on the cluster.
The CA chain (Root + Intermediate ) used should be same trusted certificate chain for both primary and media server only cluster.
If media server only deployment is done after ECA configuration on NetBackup BYO:
Pure ECA mode is not supported.
If the primary server is deployed in NBCA + ECA mode then media server can be deployed using it and ECA can be configured on media server only cluster.
The CA chain (Root + Intermediate ) used should be same trusted certificate chain for both primary and media server only cluster.
If you have deployed media server only cluster with external NetBackup primary server in a NetBackup Flex Scale cluster:
If ECA deployment is done after media server only configuration:
Primary server should be configured in ECA + NBCA mode before starting ECA deployment on the media server only cluster.
This can be done using the NetBackup Flex Scale ECA deployment workflow.
The CA chain (Root + Intermediate ) used should be same trusted certificate chain for the cluster on which both primary and media servers are deployed and media server only cluster.
If media server only deployment is done after ECA configuration on a NetBackup Flex Scale cluster on which both primary and media server are deployed
Pure ECA mode is not supported a NetBackup Flex Scale cluster on which both primary and media server are deployed.
If the cluster is deployed in NBCA +ECA mode, then media server only cluster can be deployed using it and ECA can be configured on media server only cluster.
The CA chain (Root + Intermediate ) used should be same trusted certificate chain for the cluster on which both primary and media servers are deployed and media server only cluster.