NetBackup™ Security and Encryption Guide
- Read this first for secure communications in NetBackup
- About secure communication in NetBackup
- How NetBackup CA-signed certificates (or host ID-based certificates) are deployed during installation
- How secure communication works with primary server cluster nodes
- About NetBackup clients installed on nodes of a clustered application
- How NetBackup certificates are deployed on hosts during upgrades
- When an authorization token is required during certificate deployment
- Why do you need to map host names (or IP addresses) to host IDs
- How to reset host attributes or host communication status
- What has changed for catalog recovery
- What has changed with Auto Image Replication
- How the hosts with revoked certificates work
- Are NetBackup certificates backed up
- Can you configure external certificates for primary server
- How secure communication works with primary server cluster nodes using external certificates
- How revocation lists work for external certificates
- How communication happens when a host cannot directly connect to the primary server
- How NetBackup 8.1 or later hosts communicate with NetBackup 8.0 and earlier hosts
- How communication with legacy media servers happens in the case of cloud configuration
- Communication failure scenarios
- Secure communication support for other hosts in NetBackup domain
- Secure communication support for BMR
- Configuration for VMware backups that protect SQL Server and backups with SQL Servers that use multiple NICs
- 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 datacenter levels
- NetBackup security implementation types
- Operating system security
- NetBackup security vulnerabilities
- Standard NetBackup security
- Client side encryption security
- NBAC on primary, 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 primary and media servers
- Single datacenter with NBAC complete
- Multi-datacenter with standard NetBackup
- Multi-datacenter with client side encryption
- Multi-datacenter with NBAC on primary and media servers
- Multi-datacenter with NBAC complete
- Auditing NetBackup operations
- About NetBackup auditing
- Viewing the current audit settings
- About audit events
- 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)
- Send audit events to system logs
- SYSLOG_AUDIT_USE_OCSF_FORMAT for NetBackup primary server
- 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
- RBAC features
- RBAC settings
- Configuring RBAC
- Role permissions
- Notes for using NetBackup RBAC
- Add AD or LDAP domains
- Default RBAC roles
- Add a custom RBAC role
- Edit or remove a role a custom role
- View users in RBAC
- Add a user to a role (non-SAML)
- Add a smart card user to a role (non-SAML, without AD/LDAP)
- Add a user to a role (SAML)
- Remove a user from a role
- NetBackup interface access for OS Administrators
- Smart card or digital certificate
- Configure user authentication with smart cards or digital certificates
- Configure smart card authentication with a domain
- Configure smart card authentication without a domain
- Edit the configuration for smart card authentication
- Add or delete a CA certificate that is used for smart card authentication
- Disable or temporarily disable smart card authentication
- Single Sign-On (SSO)
- 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 primary servers
- Installing the NetBackup primary server highly available on a cluster
- Configuring NetBackup Access Control (NBAC) on a clustered primary 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 primary 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 primary server
- Verification points in a mixed environment with a Windows primary 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)
- Configuration requirements if using Change Server with NBAC
- Minimizing security configuration risk
- Configuring multifactor authentication
- About multifactor authentication
- Configure multifactor authentication for your user account
- Disable multifactor authentication for your user account
- Enforce multifactor authentication for all users
- Configure multifactor authentication for your user account when it is enforced in the domain
- Reset multifactor authentication for a user
- Configuring multi-person authorization
- About multi-person authorization
- Workflow to configure multi-person authorization for NetBackup operations
- RBAC roles and permissions for multi-person authorization
- Multi-person authorization process with respect to roles
- NetBackup operations that need multi-person authorization
- Configure multi-person authorization
- View multi-person authorization tickets
- Manage multi-person authorization tickets
- Add exempted users
- Schedule expiration and purging of multi-person authorization tickets
- Disable multi-person authorization
- Section II. Encryption of data-in-transit
- NetBackup CA and NetBackup certificates
- Overview of security certificates in NetBackup
- About secure communication in NetBackup
- About the Security Management utilities
- 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
- Disaster recovery packages
- Setting a passphrase to encrypt disaster recovery packages
- Validate the disaster recovery package passphrase
- 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
- Managing passphrases and passphrase keys for encryption of private key of host ID-based certificates
- 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 primary server (Certificate Authority)
- Forcing or overwriting certificate deployment
- Retaining host ID-based certificates when reinstalling NetBackup on non-primary hosts
- Deploying certificates on a client that has no connectivity with the primary 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 primary server after disaster recovery installation
- About the communication between a NetBackup client located in a demilitarized zone and a primary 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
- 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
- Configuring data-in-transit encryption (DTE)
- About the data channel
- Data-in-transit encryption support
- Workflow to configure data-in-transit encryption
- Configure the global data-in-transit encryption setting
- Configure the DTE mode on a client
- View the DTE mode of a NetBackup job
- View the DTE-specific attributes of a NetBackup image and an image copy
- Configure the DTE mode on the media server
- Modify the DTE mode on a backup image
- Media device selection (MDS) and resource allocation
- How DTE configuration settings work in various NetBackup operations
- External CA and external certificates
- 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
- MANAGE_WIN_CERT_STORE_PRIVATE_KEY option for NetBackup primary servers
- Limitations of Windows Certificate Store support when NetBackup services are running in Local Service account context
- About certificate revocation lists for external CA
- About certificate enrollment
- About viewing enrollment status of primary servers
- Configure an external certificate for the NetBackup web server
- Configuring the primary 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 primary server
- 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 NetBackup encryption key file
- NetBackup CA and NetBackup certificates
- Section III. Encryption of data at rest
- Data at rest encryption security
- Data at rest encryption terminology
- Data at rest encryption considerations
- Destination types for encryption of data at rest
- 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
- NetBackup key management service
- About FIPS enabled 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
- KMS operations using command-line interface (CLI)
- 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 key management service
- 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
- Checking the compatibility of KMS vendor with NetBackup
- Key rotation
- Disaster recovery when catalog backup is encrypted using an external KMS server
- Alerts for expiration of KMS credentials
- Data at rest encryption security
- Ciphers used in NetBackup for secure communication
- FIPS compliance in NetBackup
- About FIPS
- About FIPS support in NetBackup
- Prerequisites
- Specify entropy randomness in NetBackup
- Configure FIPS mode in your NetBackup domain
- Enable FIPS mode on NetBackup during installation
- Enable FIPS mode on a NetBackup host after installation
- Enable FIPS mode for the NetBackup Authentication Broker service
- Enable FIPS mode for the NetBackup Administration Console
- Disable FIPS mode for NetBackup
- NB_FIPS_MODE option for NetBackup servers and clients
- USE_URANDOM for NetBackup servers and clients
- 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
- Anomaly detection
- Section IV. Malware scanning
- Introduction
- How to setup Malware scanning
- Instant Access configurations
- Malware tools configurations
- Scan host configurations
- NetBackup malware scan host capabilities
- Prerequisites for a scan host
- Limitations and considerations for scan host using NFS share
- Configuring scan host
- Configuring a scan host pool
- Managing a scan host
- Configure resource limits for malware detection
- Performing malware scan
- Managing scan tasks
- Malware scan configuration parameters
- Troubleshooting
Multi-datacenter with client side encryption
A multi-datacenter with client side encryption option is defined as a medium to large group of hosts (greater than 50). These hosts can span two or more geographic regions and can be connected by a Wide Area Network (WAN). In this example one datacenter is located in London and the other datacenter is located in Tokyo. Both datacenters are connected through a dedicated WAN connection.
The example multi-datacenter can use client side encryption to ensure data confidentiality across the wire as well as on tape. This encryption helps to mitigate the risk of passive wire tapping within the organization. Risk of data exposure as the tapes are moved off site. This datacenter model assures a medium to large number (greater than 50) of managed hosts. Clients inside the datacenter as well as the DMZ, can have the potential for centralized naming services for hosts and user identities.
The multi-datacenter with client side encryption includes the following highlights:
NetBackup spans two or more geographic regions through a WAN
Useful for protecting off-site data
Data from client is encrypted and eliminates the passive interception of the data on the wire
Key management is de-centralized on to the clients
The original NetBackup encryption option
Client CPU is used to perform encryption
Must have the key to get data back. A lost key means lost data.
Useful when you need to scan tapes off-site or you need confidentiality on the wire
The following table describes the NetBackup parts that are used for a multi-datacenter with client side encryption implemented.
Table: NetBackup parts for a multi-datacenter with client side encryption implemented
Part | Description |
|---|---|
London datacenter |
Contains the primary server, media server 1 and clients 4, 5, and 6. The London datacenter also contains the encrypted data tape for clients 6 and 7 and unencrypted data tape for clients 4 and 5. The London datacenter connects to the Tokyo datacenter through a dedicated WAN connection. |
Tokyo datacenter |
Contains the media server 2 and clients 7, 10, 11, and 12. The Tokyo datacenter also contains the encrypted data tape for clients 7 and 12 and 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 primary server in London to media server 2 with clients 7, 10, 11, and 12 in Tokyo. The WAN also provides connectivity between media server 1 in London to client 7 in London. |
Primary server |
Specifies that the primary server is located in the London datacenter and communicates with media server 1 and clients 4, 5, and 6. The primary server also uses the WAN to communicate with media server 2, and clients 7, 10, 11, and 12 in Tokyo. |
Media servers |
Specifies that the multi-datacenter uses 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 primary server and clients 4, 5, and 6. Media server 1 also communicates with client 7 in Tokyo. Media server 1 writes unencrypted data to tape for clients 4 and 5. Media server 1 writes encrypted data to tape for clients 6 and 7. Note that client 7 is located in Tokyo but its tape backup is located in London. The encrypted tape for clients 6 and 7 is transported off-site to a vault in London. In Tokyo, media server 2 communicates with the primary server in London through the WAN and clients 7, 10, 11, and 12 in Tokyo. Media server 2 writes unencrypted data to tape for clients 10 and 11. Media server 2 also writes encrypted data to tape for clients 7and 12. Note that even though client 7 is located in Tokyo and is backed up in London, client 7 is also backed up in Tokyo. The encrypted tape for clients 7 and 12 is transported off-site to a vault in Tokyo. |
Client side encryption |
Specifies that the client side encryption (not shown in the figure) ensures data confidentiality across the wire as well as on tape. |
Tapes |
Specifies that both unencrypted and encrypted data tapes are produced in the London datacenter and in the Tokyo datacenter. The encrypted tape contains client side encrypted backup data. In London, the unencrypted tape is written for clients 4 and 5 and stored on-site at the London datacenter. The encrypted tape is written for clients 6 and 7. The encrypted tape is transported off-site to a vault in London for disaster recovery protection. In Tokyo, the unencrypted tape is written for clients 10 and 11 and stored on-site at the Tokyo datacenter. The encrypted tape is written for clients 7 and 12. Note that even though client 7 is located in Tokyo and is backed up in Tokyo, client 7 is also backed up in London. The encrypted tape is transported off-site to a vault in Tokyo for disaster recovery protection. Note: To decrypt the data, the key(s) used to encrypt the data must be made available. |
Transports |
Specifies that the multi-datacenter uses two transports. One transport is located in London and the other is located in Tokyo. The transport truck in London moves the encrypted tape for clients 6 and 7 off-site to a secure London vault facility. The transport truck in Tokyo moves the encrypted tape for clients 7 and 12 off-site to a secure Tokyo vault facility. Note that a backup copy of client 7 is vaulted both in London and in Tokyo. Note: If in the remote case a tape is lost during transport, the datacenter manager has potentially reduced the risk of a data breach. The breach is reduced through the use of client side data encryption. |
Vaults off-site |
Specifies that the multi-datacenter uses two vaults off-site. One vault is located in London and the other is located in Tokyo. Both vaults provide safe encrypted tape storage facilities off-site at different locations than the datacenters. Note: Storing the encrypted tapes at locations separate from the datacenters promotes good disaster recovery protection. |
Clients |
Specifies that the clients are located in both the London and Tokyo datacenters. In London, client 4 is a standard NetBackup type. Client 5 is a Web server type located in the DMZ. Client 6 is client side encrypted and is also located in the DMZ. All client types can be managed by the primary server and have their data backed up to tape through media server 1. Clients 5 and 6 communicate to NetBackup using NetBackup only ports through the internal firewall. Client 6 receives connections from the Internet using HTTP only ports through the external firewall. In Tokyo, client 7 is a client side encrypted client but outside of the DMZ. Client 10 is a standard NetBackup type. Client 11 is a Web server type located in the DMZ. Client 12 is client side encrypted also located in the DMZ. All client types can be managed by the primary server in London. Client 7 data is backed up to tape through media server 1 and 2. Client 10, 11, and 12 data is backed up to tape through media server 2. Clients 11 and 12 communicate to NetBackup using NetBackup only ports through the internal firewall. Client 12 receives connections from the Internet using HTTP only ports through the external firewall. |
Internal firewalls |
Specifies that the multi-datacenter uses two internal firewalls. One internal firewall is located in London and the other is located in Tokyo. In London, the internal firewall allows NetBackup to access Web server client 5 and client side encrypted client 6 in the DMZ. In Tokyo, the internal firewall lets NetBackup access Web server client 11 and client side encrypted client 12 in the DMZ. Only selected NetBackup ports and possibly other application ports are enabled for data communication into and out of the DMZ. HTTP ports that are open in the external firewall cannot pass through the internal firewall. |
Demilitarized Zones (DMZs) |
Specifies that the multi-datacenter uses two DMZs. 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 and client side encrypted client 6. That client exists between the internal firewall and the external firewall. The Web server client 5 and client side encrypted client 6 in the DMZ can communicate to NetBackup. Both clients communicate 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 and client side encrypted client 12. The client 12 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 the multi-datacenter can use two external firewalls. 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. The 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. The client side encrypted client 6 cannot be accessed from the Internet. In Tokyo, the external firewall 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. The client side encrypted client 12 cannot be accessed from the Internet. |
Internet |
Specifies that there is 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. |