search cancel

Deploying or Publishing Symantec Encryption Management Server on the Internet

book

Article ID: 190699

calendar_today

Updated On:

Products

Encryption Management Server Powered by PGP Technology Encryption Desktop Powered by PGP Technology Gateway Email Encryption Gateway Email Encryption Powered by PGP Technology

Issue/Introduction

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 Encryption Management Server on the Internet so that 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 an Encryption Management Server on the Internet that was previously on the internal network.

Encryption Management 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.

Environment

Symantec Encryption Management Server 3.4.2 and above.
Symantec Encryption Desktop 10.4.2 and above.

Resolution

The considerations for publishing Encryption Management Server on the Internet are as follows.

Cluster members that do not host private keys

In an Encryption Management Server cluster, some cluster members can be configured not to host private keys of internal users and consumer groups. Do not allow Encryption Desktop users to connect to such cluster members if any of the following apply:

  • You are using SKM (Server Key Mode) keys for any of your users. This is because such client keys will be permanently corrupted.
  • You are using Encryption Desktop drive encryption. This is because Whole Disk Recovery Tokens (WDRTs) are not stored on cluster members that do not host private keys.
  • You are using File Share Encryption, especially with Group Keys. This is because File Share Encryption relies on private keys.

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.

Required port to publish

All communications between Encryption Desktop and Encryption Management Server occur over port 443 (HTTPS). Therefore this is the only port that needs to be open between Encryption Desktop and Encryption Management Server.

PGPSTAMP FQDN

When you install Encryption Desktop, the PGPSTAMP registry setting contains the FQDN (fully qualified domain name) of the Encryption Management Server. For example, keys.example.com. Clearly, if the Encryption Desktop clients are connecting to Encryption Management 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 Encryption Desktop installer from Encryption Management Server after changing the Symantec Encryption Server setting, then upgrading the clients. This will force the Encryption Desktop 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.

Internal Network or DMZ

You could place Encryption Management 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 Encryption Management Server there is nothing more to do.

Generally, however, you would place Encryption Management 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.

Enrollment and Regrouping of Users

Usually, Encryption Management 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 Encryption Management 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, Encryption Management 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 Encryption Management 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 Encryption Management 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.

Replication

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.

Management Console

Administrators connect to the Encryption Management 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.

DNS - forward and reverse

Encryption Management 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 Encryption Management 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.

NTP

In a clustered environment, each Encryption Management Server must be able to connect to an NTP server so that the time on each cluster member is identical and accurate.

SSH

Administrators with the SuperUser role will need to be able to connect to Encryption Management Server over SSH (port 22) from time to time so this port needs to be open from the internal network only.

SMTP

If users are enrolling using email then clearly Encryption Management 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, Encryption Management Server may still need to send the daily status message to administrators. Obviously, if Encryption Management Server is used for gateway email then it may need to receive as well as send email.

TLS Certificate

Given that the Encryption Desktop clients are connecting to a public FQDN, it is recommended but not required that Encryption Management Server uses a TLS certificate issued by a well known Certificate Authority.

LDAP

If either Encryption Desktop or Encryption Management Server are being used for email encryption, Encryption Management Server will need to use LDAP to search for PGP keys on remote key servers. Outbound LDAP will also be required if 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 Encryption Management Server.

SNMP

If the SNMP service is enabled on Encryption Management Server, connectivity to the SNMP server will be required.

Certificate Revocation List (CRL)

If Encryption Management 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 Encryption Management Server in order to download the Certificate Revocation List.

Verified Directory

If the Verified Directory service is enabled on Encryption Management Server, remote hosts will need to be able to connect to port 80 (HTTP) or port 443 (HTTPS), depending how the service is configured.

Web Email Protection

If the Web Email Protection service is enabled on Encryption Management Server, remote hosts will need to be able to connect to port 443 (HTTPS).

External Syslog

If Encryption Management 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.