Veritas NetBackup™ Security and Encryption Guide
- Increasing NetBackup security
- About NetBackup security and encryption
- NetBackup security implementation levels
- World-level security
- Enterprise-level security
- Datacenter-level security overview
- NetBackup Access Control (NBAC)
- Combined world, enterprise, and data center levels
- NetBackup security implementation types
- Operating system security
- NetBackup security vulnerabilities
- Standard NetBackup security
- Client side encryption security
- NBAC on master, media server, and graphical user interface security
- NBAC complete security
- Security deployment models
- Workgroups
- Single datacenters
- Multi-datacenters
- Workgroup with NetBackup
- Single datacenter with standard NetBackup
- Single datacenter with client side encryption
- Single datacenter with NBAC on master and media servers
- Single datacenter with NBAC complete
- Multi-datacenter with standard NetBackup
- Multi-datacenter with client side encryption
- Multi-datacenter with NBAC on master and media servers
- Multi-datacenter with NBAC complete
- Port security
- About NetBackup TCP/IP ports
- About NetBackup daemons, ports, and communication
- Standard NetBackup ports
- NetBackup master server outgoing ports
- NetBackup media server outgoing ports
- NetBackup enterprise media management (EMM) server outgoing ports
- Client outgoing ports
- Java server outgoing ports
- Java console outgoing ports
- About MSDP port usage
- About Cloud port usage
- Additional port information for products that interoperate with NetBackup
- About communication ports and firewall considerations in OpsCenter
- Ports required to communicate with backup products
- Web browser to launch OpsCenter user interface
- About OpsCenter user interface and OpsCenter server software communication
- About OpsCenter server to NetBackup master server (NBSL) communication
- About SNMP traps
- About communication between OpsCenter and Sybase database
- About email communication in OpsCenter
- About configuring ports
- Port requirements for NDMP backups
- Known firewall problems encountered when using NetBackup with third-party robotic products
- Auditing NetBackup operations
- About NetBackup auditing
- Viewing the current audit settings
- Audit retention period and catalog backups of audit records
- Viewing the detailed NetBackup audit report
- User identity in the audit report
- Disabling auditing
- Audit alert notification for audit failures (NetBackup Administration Console)
- About Enhanced Auditing
- Access control security
- NetBackup Access Control Security (NBAC)
- About using NetBackup Access Control (NBAC)
- NetBackup access management administration
- About NetBackup Access Control (NBAC) configuration
- Configuring NetBackup Access Control (NBAC)
- NBAC configuration overview
- Configuring NetBackup Access Control (NBAC) on standalone master servers
- Installing the NetBackup master server highly available on a cluster
- Configuring NetBackup Access Control (NBAC) on a clustered master server
- Configuring NetBackup Access Control (NBAC) on media servers
- Installing and configuring access control on clients
- About including authentication and authorization databases in the NetBackup hot catalog backups
- NBAC configure commands summary
- Unifying NetBackup Management infrastructures with the setuptrust command
- Using the setuptrust command
- Configuring Access Control host properties for the master and media server
- Access Control host properties dialog for the client
- Using NetBackup Access Control (NBAC) with Auto Image Replication
- Troubleshooting Access Management
- Troubleshooting NBAC issues
- Configuration and troubleshooting tips for NetBackup Authentication and Authorization
- 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 the nbac_cron utility
- Using the nbac_cron utility
- Using the Access Management utility
- About determining who can access NetBackup
- Viewing specific user permissions for NetBackup user groups
- Granting permissions
- Authorization objects
- Media authorization object permissions
- Policy authorization object permissions
- Drive authorization object permissions
- Report authorization object permissions
- NBU_Catalog authorization object permissions
- Robot authorization object permissions
- Storage unit authorization object permissions
- DiskPool authorization object permissions
- BUAndRest authorization object permissions
- Job authorization object permissions
- Service authorization object permissions
- HostProperties authorization object permissions
- License authorization object permissions
- Volume group authorization object permissions
- VolumePool authorization object permissions
- DevHost authorization object permissions
- Security authorization object permissions
- Fat server authorization object permissions
- Fat client authorization object permissions
- Vault authorization object permissions
- Server group authorization object permissions
- Key management system (kms) group authorization object permissions
- Upgrading NetBackup Access Control (NBAC)
- About AD and LDAP domains
- NetBackup CA and NetBackup certificates
- Overview of security certificates in NetBackup
- About secure communication in NetBackup
- About the Security Management utilities
- About audit events
- About host management
- Hosts tab
- Adding host ID to host name mappings
- Add or Remove Host Mappings dialog box
- Removing host ID to host name mappings
- Mappings for Approval tab
- Viewing auto-discovered mappings
- Mapping Details dialog box
- Approving host ID to host name mappings
- Rejecting host ID to host name mappings
- Adding shared or cluster mappings
- Add Shared or Cluster Mappings dialog box
- Resetting NetBackup host attributes
- Allowing or disallowing automatic certificate reissue
- Adding or deleting comment for a host
- About global security settings
- About secure communication settings
- Disabling insecure communication
- About insecure communication with 8.0 and earlier hosts
- About communication with 8.0 or earlier host in multiple NetBackup domains
- Automatically mapping host ID to host names and IP addresses
- About disaster recovery settings
- Setting a passphrase to encrypt disaster recovery packages
- Disaster recovery packages
- About host name-based certificates
- About host ID-based certificates
- Web login requirements for nbcertcmd command options
- Using the Certificate Management utility to issue and deploy host ID-based certificates
- About NetBackup certificate deployment security levels
- Automatic host ID-based certificate deployment
- Deploying host ID-based certificates
- Deploying host ID-based certificates in an asynchronous manner
- Implication of clock skew on certificate validity
- Setting up trust with the master server (Certificate Authority)
- Forcing or overwriting certificate deployment
- Retaining host ID-based certificates when reinstalling NetBackup on non-master hosts
- Deploying certificates on a client that has no connectivity with the master server
- About host ID-based certificate expiration and renewal
- Deleting sensitive certificates and keys from media servers and clients
- Cleaning host ID-based certificate information from a host before cloning a virtual machine
- 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
- Deleting 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
- Deploying host ID-based certificates on cluster nodes
- Revoking a host ID-based certificate for a clustered NetBackup setup
- Deploying a host ID-based certificate on a clustered NetBackup setup using reissue token
- Creating a reissue token for a clustered NetBackup setup
- Renewing a host ID-based certificate on a clustered NetBackup setup
- Viewing certificate details of a clustered NetBackup setup
- Removing CA certificates from a clustered NetBackup setup
- Generating a certificate on a clustered master server after disaster recovery installation
- About the communication between a NetBackup client located in a demilitarized zone and a master server through an HTTP tunnel
- Adding a NetBackup host manually
- Migrating NetBackup CA
- Setting the required key strength before installation or upgrade using the NB_KEYSIZE environment variable
- Migrating NetBackup CA when the entire NetBackup domain is upgraded to NetBackup 8.3
- Manually migrating NetBackup CA after installation or upgrade
- Establishing communication with clients that do not have new CA certificates after CA migration
- Viewing a list of NetBackup CAs in the domain
- Viewing the CA migration summary
- Decommissioning the inactive NetBackup CA
- External CA support in NetBackup
- About external CA support in NetBackup
- Workflow to use external certificates for NetBackup host communication
- 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
- About certificate revocation lists for external CA
- About certificate enrollment
- About viewing enrollment status of master servers
- Configuring an external certificate for the NetBackup web server
- Configuring the master server to use an external CA-signed certificate
- Configuring a NetBackup host (media server, client, or cluster node) to use an external CA-signed certificate after installation
- Enrolling an external certificate for a remote host
- Viewing the certificate authorities that your NetBackup domain supports
- Viewing external CA-signed certificates in the NetBackup web UI
- Renewing a file-based external certificate
- Removing certificate enrollment
- Disabling the NetBackup CA in a NetBackup domain
- Enabling the NetBackup CA in a NetBackup domain
- Disabling an external CA in a NetBackup domain
- Changing the subject name of an enrolled external certificate
- About external certificate configuration for a clustered master server
- About API keys in NetBackup
- Data at rest encryption security
- Data at rest encryption terminology
- Data at rest encryption considerations
- Encryption security questions to consider
- Comparison of encryption options
- About NetBackup client encryption
- Configuring standard encryption on clients
- Managing standard encryption configuration options
- Managing the NetBackup encryption key file
- About configuring standard encryption from the server
- Restoring an encrypted backup file to another client
- About configuring standard encryption directly on clients
- Setting standard encryption attribute in policies
- Changing the client encryption settings from the NetBackup server
- Configuring legacy encryption on clients
- About configuring legacy encryption from the client
- About configuring legacy encryption from the server
- Restoring a legacy encrypted backup created on another client
- About setting legacy encryption attribute in policies
- Changing client legacy encryption settings from the server
- Additional legacy key file security for UNIX clients
- Data at rest key management
- Federal Information Processing Standards (FIPS)
- About FIPS enabled KMS
- About the Key Management Service (KMS)
- Installing KMS
- Configuring KMS
- Creating the key database
- About key groups and key records
- Overview of key record states
- About backing up the KMS database files
- About recovering KMS by restoring all data files
- Recovering KMS by restoring only the KMS data file
- Recovering KMS by regenerating the data encryption key
- Problems backing up the KMS data files
- Solutions for backing up the KMS data files
- Creating a key record
- Listing keys from a key group
- Configuring NetBackup to work with KMS
- Configuring NetBackup KMS using the KMS web application
- About using KMS for encryption
- KMS database constituents
- Command line interface (CLI) commands
- CLI usage help
- Create a new key group
- Create a new key
- Modify key group attributes
- Modify key attributes
- Get details of key groups
- Get details of keys
- Delete a key group
- Delete a key
- Recover a key
- About exporting and importing keys from the KMS database
- Modify host master key (HMK)
- Get host master key (HMK) ID
- Get key protection key (KPK) ID
- Modify key protection key (KPK)
- Get keystore statistics
- Quiesce KMS database
- Unquiesce KMS database
- Key creation options
- Troubleshooting KMS
- External KMS support in NetBackup
- About external KMS
- Certificate configuration and authorization
- Workflow for external KMS configuration
- Validating KMS credentials
- Configuring KMS credentials
- Configuring KMS
- Configuring keys in an external KMS for NetBackup consumption
- Creating keys in an external KMS
- Determining a key group name during storage configuration
- Working with multiple KMS servers
- Working with external KMS during backup and restore
- Key rotation
- Disaster recovery when catalog backup is encrypted using an external KMS server
- Alerts for expiration of KMS credentials
- Regenerating keys and certificates
- About regenerating keys and certificates
- Regenerating NetBackup authentication broker keys and certificates
- Regenerating host identity keys and certificates
- Regenerating web service keys and certificates
- Regenerating nbcertservice keys and certificates
- Regenerating tomcat keys and certificates
- Regenerating JWT keys
- Regenerating NetBackup gateway certificates
- Regenerating web trust store certificates
- Regenerating VMware vCenter plug-in certificates
- Regenerating NetBackup Administrator Console session certificates
- Regenerating OpsCenter keys and certificates
- Regenerating NetBackup encryption key file
- NetBackup web services account
Multi-datacenter with NBAC complete
The multi-datacenter with NBAC complete example is defined as a medium to large group of hosts (greater than 50) that span two or more geographic regions and can be connected by a Wide Area Network (WAN). In this example, one datacenter is in London and the other datacenter is in Tokyo. Both datacenters are connected through a dedicated WAN connection.
This environment is very similar to the multi-datacenter with NBAC master and media server. The main differences are that all hosts participating in the NetBackup environment are reliably identified using credentials and non-root administrators can manage the NetBackup clients based on configurable levels of access. Note that user identities may exist in global repositories such as Active Directory in Windows or NIS in UNIX. Identities can also exist in local repositories (UNIX passwd, local Windows domain) on those hosts supporting an authentication broker.
The multi-datacenter with NBAC complete includes the following highlights:
NetBackup spans two or more geographic regions through a WAN
Similar to highlights for multi-datacenter with NBAC master and media server except for root or administrator on client. The non-root administration of clients and servers is permitted in this configuration.
On client systems, non-root / administrator users can be configured to perform local backup and restores (setup by default)
The environment facilitates trusted identification of all hosts participating in NetBackup
Requires all hosts to be at NetBackup version 7.7 or later.
Figure: Multi-datacenter with NBAC complete shows an example multi-datacenter with NBAC complete.
The following table describes the NetBackup parts that are used for a multi-datacenter with NBAC complete implemented.
Table: NetBackup parts used for a multi-datacenter with NBAC complete implemented
Part | Description |
|---|---|
London datacenter |
Specifies that the London datacenter contains the root broker, authentication broker 1, GUI 1, authorization engine, master server, media server 1, and clients 1 and 5. The London datacenter also contains the unencrypted data tape for clients 1, 5, and 10. The London datacenter connects to the Tokyo datacenter through a dedicated WAN connection. |
Tokyo datacenter |
Specifies that the Tokyo datacenter contains the authentication broker 2, GUI 2, media server 2, and clients 10 and 11. The Tokyo datacenter also contains the unencrypted data tape for clients 10 and 11. The Tokyo datacenter connects to the London datacenter through a dedicated WAN connection. |
Wide Area Network (WAN) |
Specifies that the dedicated WAN link connects the London datacenter with the Tokyo datacenter. The WAN provides connectivity between the root broker and authentication broker 1 and authentication broker 2. In addition, the WAN provides connectivity between the root broker and authentication broker 1 and GUI 2 along with media server 2. The WAN connects the authorization engine to media server 2. The WAN connects the master server to GUI 2, media server 2, and clients 10 and 11. Finally the WAN connects media server 1 to client 10. |
Master server |
Specifies that the master server, located in the London datacenter, communicates with the root broker and authentication broker 1. It also communicates with GUI 1, authorization engine, and media server 1. The master server further communicates with GUI 2 and media server 2, and clients 10 and 11 in Tokyo. |
Media servers |
Specifies that in this multi-datacenter example there are two media servers. Media server 1 is located in the London datacenter and media server 2 is located in the Tokyo datacenter. In London, media server 1 communicates with the master server, root broker and authentication broker 1, authorization engine, and clients 1, 5, and 10. Media server 1 writes unencrypted data to tape for clients 1, 5, and 10. In Tokyo, media server 2 communicates with the master server, root broker, and authentication broker 1 and authorization engine in London through the WAN. Media server 2 also communicates with GUI 2, and clients 10 and 11 in Tokyo. Media server 2 writes unencrypted data to tape for clients 10 and 11. |
GUIs |
Specifies that in this multi-datacenter example, there are two GUIs. GUI 1 is in London and GUI 2 is in Tokyo. These remote administration console GUIs receive credentials from the authentication brokers. The GUIs then use the credentials to gain access to functionality on the media servers and master servers. In London, GUI 1 receives a credential from authentication broker 1. GUI 1 has access to functionality on the master server and media servers 1 and 2. In Tokyo, GUI 2 receives a credential from the authentication broker 2. GUI 2 has access to functionality on the master server and media servers 1 and 2. |
Root broker |
Specifies that there is only one root broker required in a multi-datacenter installation. Sometimes the root broker is combined with the authentication broker. In this example the root broker and authentication broker are shown as the same component and are located in the London datacenter. In London, the root broker authenticates the authentication broker 1, also in London, and authentication broker 2 in Tokyo. The root broker does not authenticate clients. |
Authentication brokers |
Specifies that there can be more than one authentication broker in a datacenter installation. Sometimes the authentication broker can be combined with the root broker. In this datacenter installation, there are two authentication brokers. The authentication broker authenticates the master server, media server, GUI, and clients by establishing credentials with each. The authentication broker also authenticates a user through a command prompt. In London, authentication broker 1 authenticates a credential with the master server, media server 1, GUI 1, and clients 1 and 5. All NetBackup servers and clients in Tokyo and London authenticate to authentication broker 1 in London. GUI 1 authenticates to authentication broker 1 in London. GUI 2 authenticates to authentication broker 2 in Tokyo. |
Authorization engine |
Specifies that there is only one authorization engine required in a datacenter installation. The authorization engine communicates with the master server and media server to determine permissions of an authenticated user. These permissions determine the functionality available to the user. The authorization engine also stores user groups and permissions. The authorization engine resides in London and communicates with the master server, and media server 1. The authorization engine also communicates over the WAN to authorize access to media server 2 in Tokyo. Note: The authorization engine resides on the master server as a daemon process. It is shown in the figure as a separate image for example only. |
Tapes |
Specifies that the unencrypted data tapes are produced in both the London and Tokyo datacenters. In London, the unencrypted tape is written for clients 1, 5 and 10 and stored on-site at the London datacenter. In Tokyo, the unencrypted tape is written for clients 10 and 11 and stored on-site at the Tokyo datacenter. Note that even though client 10 is located in Tokyo and is backed up in Tokyo, client 10 is also backed up in London. |
Clients |
Specifies that the clients are located in both the London and Tokyo datacenters. In London, client 1 is a standard NetBackup type. Client 5 is a Web server type located in the DMZ. All client types can be managed by the master server and have their data backed up to tape through media server 1. Client 5 communicates to NetBackup using NetBackup only ports through the internal firewall. Client 5 also receives connections from the Internet using HTTP only ports through the external firewall. In Tokyo, client 10 is a standard NetBackup type. Client 11 is a Web server type located in the DMZ. All client types can be managed by the master server and have their data backed up to tape through media server 2. Client 11 communicates to NetBackup using NetBackup only ports through the internal firewall. Client 11 also receives connections from the Internet using HTTP only ports through the external firewall |
Internal firewalls |
Specifies that there can be two internal firewalls in this multi-datacenter example. One internal firewall is located in London and the other is located in Tokyo. In London, the internal firewall lets NetBackup access Web server client 5 in the DMZ. In Tokyo, the internal firewall lets NetBackup access Web server client 11 in the DMZ. Only selected NetBackup ports and possibly other application ports are enabled for data communication through the internal firewall and into and out of the DMZ. HTTP ports that are open in the external firewall are not allowed to pass through the internal firewall. |
Demilitarized Zones (DMZs) |
Specifies that there can be two DMZs in this multi-datacenter example. One DMZ is located in London and the other is located in Tokyo. In London, the DMZ provides a "safe" area of operation for the Web server client 5 that exists between the internal firewall and external firewall. The Web server client 5 in the DMZ can communicate to NetBackup through the internal firewall using designated NetBackup ports. The Web server client 5 can also communicate through the external firewall to the Internet using only HTTP ports. In Tokyo, the DMZ provides a "safe" area of operation for the Web server client 11 that exists between the internal firewall and external firewall. The Web server client 11 in the DMZ can communicate to NetBackup through the internal firewall using designated NetBackup ports. The Web server client 11 can also communicate through the external firewall to the Internet using only HTTP ports. |
External firewalls |
Specifies that there can be two external firewalls in this multi-datacenter example. One external firewall is located in London and the other is located in Tokyo. In London, the external firewall lets external users access the Web server client 5 located in the DMZ from the Internet over HTTP ports. NetBackup ports are open for Web server client 5 to communicate through the internal firewall to NetBackup. The NetBackup ports are not allowed to pass through the external firewall to the Internet. Only the HTTP ports of Web server client 5 can pass through the external firewall to the Internet. In Tokyo, the external firewall lets external users access the Web server client 11 located in the DMZ from the Internet over HTTP ports. NetBackup ports are open for Web server client 11 to communicate through the internal firewall to NetBackup. The NetBackup ports are not allowed to pass through the external firewall to the Internet. Only the HTTP ports of Web server client 11 can pass through the external firewall to the Internet. |
Internet |
Specifies that there can be only one Internet but there are two Internet connections in this multi-datacenter example. One Internet connection is located in London and the other is located in Tokyo. The Internet is a collection of interconnected computer networks that are linked by copper wires, fiber-optic cables and wireless connections. In London, the Web server client 5 can communicate over the Internet using HTTP ports through the external firewall. In Tokyo, the Web server client 11 can communicate over the Internet using HTTP ports through the external firewall. |