The PGP Encryption Server (Symantec Encryption Management Server) is usually located on the internal network and Encryption Desktop clients therefore also need to be on the internal network or connected to the internal network using a VPN (Virtual Private Network).
It is possible to publish the PGP Encryption Server on the Internet so that PGP Encryption Desktop (Symantec Encryption Desktop) clients do not need to be on the internal network or use a VPN connection. This avoids overloading the VPN.
However, there are various considerations to be aware of, especially when seeking to publish a PGP Encryption Server on the Internet that was previously on the internal network.
The PGP Encryption Server can only be installed on physical hardware or as a VMware Virtual Machine. The major cloud providers all offer a VMware solution: Azure VMware Solution, VMware Cloud on AWS and Google Cloud VMware Engine.
PGP Encryption Server 3.4.2 and above.
PGP Encryption Desktop 10.4.2 and above.
The considerations for publishing the PGP Encryption Server on the Internet are as follows.
In a PGP Encryption Server cluster, some cluster members can be configured not to host private keys of internal users and consumer groups. Do not allow PGP Encryption Desktop users to connect to such cluster members if any of the following apply:
If you do not use drive encryption or File Share Encryption and use only GKM mode keys for clients, it may be possible to allow Encryption Desktop to connect to cluster members that do not host private keys but this is not recommended.
All communications between PGP Encryption Desktop and PGP Encryption Server occur over port 443 (HTTPS). Therefore this is the only port that needs to be open between Encryption Desktop and PGP Encryption Server.
When you install the PGP Encryption Desktop, the PGPSTAMP registry setting contains the FQDN (fully qualified domain name) of the PGP Encryption Management Server. For example, keys.example.com. Clearly, if the PGP Encryption Desktop clients are connecting to PGP Encryption Server over the Internet, the clients must be able to resolve this FQDN to a public IP address.
If the FQDN within the PGPSTAMP value cannot be resolved from the Internet, the PGPSTAMP value needs to be changed. You can change PGPSTAMP by downloading the PGP Encryption Desktop installer from PGP Encryption Server after changing the PGP Encryption setting, then upgrading the clients. This will force the PGP Encryption users to re-enroll. You can avoid forcing the clients to re-enroll by writing a script to quit PGP Tray and change the PGPSTAMP registry entry. Search for article 153660 for further details about PGPSTAMP.
You could place the PGP Encryption Server in the internal network and configure your firewall or reverse proxy to allow clients to connect to it from the Internet over port 443. In this scenario, so long as the clients can resolve the FQDN of PGP Encryption Server there is nothing more to do.
Generally, however, you would place PGP Encryption Server in a DMZ. What you then need to consider is which ports to allow to connect from the DMZ to the internal network. For maximum security, you would allow no traffic from the DMZ to the internal network but this affects enrollment of users, regrouping of users, replication and server management. Each of these considerations is addressed below as well as listing other ports and services that may be needed.
Usually, the PGP Encryption Server is configured to use Directory Synchronization for enrollment. It connects to one or more Active Directory domain controllers in order to authenticate users at enrollment time. It also usually groups users according to their membership of Active Directory security groups. Therefore, if the PGP Encryption Server is in a DMZ, it will need to be able to connect to domain controllers in the internal network over LDAPS (or LDAP but this is not recommended).
If it is not possible to connect to domain controllers in the internal network over LDAPS, the PGP Encryption Server can be configured to allow clients to enroll using email. However, regrouping of users according to membership of Active Directory security groups will not be possible. At best, you would need to create a Dictionary of user names in the PGP Encryption Server and use that Dictionary to group users. It is much more time consuming and requires frequent maintenance.
In a clustered environment, one alternative configuration would be to keep at least one PGP Encryption Server in the internal network. That server could regroup users according to Active Directory security group membership. Users would still need to enroll using email.
If you wanted to enroll users using Directory Synchronization rather than email, you could implement split DNS whereby, for example, keys.example.com resolves to a public IP address when the client is connected to the Internet and resolves to an internal network IP address when the client is on the internal network or connected to the VPN. This way, users would need to be on the internal network or VPN for initial enrollment but after that could connect over the Internet.
If you have more than one Encryption Management Server in a cluster, the cluster members will need to be able to communicate with each other. This communication is done over port 444 so the servers will need to be able to communicate with each other in both directions over this port.
Administrators connect to the PGP Encryption Server administration console over port 9000 so this port would need to be accessible from the internal network. For security reasons it should not be accessible from the Internet.
The PGP Encryption Server must have access to at least one DNS server and in a clustered environment, that DNS server will need to be able to resolve the names of the PGP Encryption Servers themselves, using both forward and reverse DNS. In other words, the DNS server must be able to resolve the FQDN of each cluster member to an IP address and resolve each cluster member's IP address to its FQDN.
In a clustered environment, each PGP Encryption Server must be able to connect to an NTP server so that the time on each cluster member is identical and accurate.
Administrators with the SuperUser role will need to be able to connect to PGP Encryption Server over SSH (port 22) from time to time so this port needs to be open from the internal network only.
If users are enrolling using email then clearly the PGP Encryption Server needs to be able to send email to that user. It can either send directly using the MX record of the recipient domain or, more usually, relay using one of the organization's mail servers. If users are not enrolling using email, PGP Encryption Server may still need to send the daily status message to administrators. Obviously, if the PGP Encryption Server is used for gateway email then it may need to receive as well as send email.
Given that the PGP Encryption Desktop clients are connecting to a public FQDN, it is recommended but not required that the PGP Encryption Server uses a TLS certificate issued by a well known Certificate Authority.
If either the PGP Encryption or PGP Encryption Server are being used for email encryption, the Server will need to use LDAP to search for PGP keys on remote key servers. Outbound LDAP will also be required if the PGP Encryption Desktop users need to encrypt files to keys located on remote key servers.
Inbound LDAP will be required if remote key servers need to perform key lookups on the PGP Encryption Server.
If the SNMP service is enabled on PGP Encryption Server, connectivity to the SNMP server will be required.
If the PGP Encryption Server is used for S/MIME email and the Certificate Revocation service is enabled, remote hosts should be permitted to connect to port 80 (HTTP) on the server in order to download the Certificate Revocation List.
If the Verified Directory service is enabled on the PGP Encryption Server, remote hosts will need to be able to connect to port 80 (HTTP) or port 443 (HTTPS), depending how the service is configured.
If the Web Email Protection service is enabled on the PGP Encryption Server, remote hosts will need to be able to connect to port 443 (HTTPS).
If the PGP Encryption Server is configured to send its logs to an external syslog server, outbound UDP or TCP port 514 to the syslog server will need to be permitted.