This entry in our series on Azure secure cloud migration discusses the process of implementing a public key infrastructure (PKI) in the cloud. See “Preparing to Migrate to a Secure Cloud” for more information on the blog series and topics covered. Implementing these solutions on-premises always poses interesting systems management questions and in that regard deploying in the cloud requires answering these same questions in different way.
Implementing Certificate Authorities in Azure
The creation of a public key infrastructure (PKI) on Microsoft’s Azure infrastructure as a service (IaaS) has a lot in common with an on-premises deployment, but requires key trade-offs to be viable. This post covers these critical trade-offs and ideas on how to best mitigate risk in a deployment that does not fit the traditional ideal—meaning on-premises with operating systems running on native hardware and a hardware security module (HSM) available for key storage and access.
Accessing the “Offline” Root Certificate Authority
The root certificate authority (CA) server is the single most important piece of an organization’s PKI. In an idealized implementation, this critical system runs on dedicated hardware and has no network connectivity to the world around it. In that scenario, all communications to and from the root CA would take place via removable media (e.g., a floppy disk), but in a cloud service this is not feasible. Design decisions need to be made to approximate an idealized solution as much as possible.
The first hurdle to overcome is the accessibility of the console in the Microsoft Azure environment. The console is technically accessible, but requires a PKI for configuration of a Remote Desktop Gateway solution to enable that access, which leads to a catch-22 scenario. The best alternative to consider is how to allow a modicum of network connectivity without unnecessarily exposing the root CA to risk when connecting with Remote Desktop Protocol (RDP) to the root CA In this case, using either Azure network security groups (NSGs) or Windows Firewall on the root CA’s guest operating system can accomplish the task. The former gives the ability to allow connectivity to the root CA in almost all situations, while the latter could result in a completely isolated guest operating system left completely without access. Network access is preferred over console access if properly controlled and NSGs are preferred because the Windows Firewall could potentially leave the system inaccessible if improperly configured.
Inbound access to the root CA via RDP (Azure’s default method of guest system access) from a limited number of trusted systems works well, and leveraging drive redirection capabilities of the RDP connections conveniently fills the need for transporting files securely to and from the root CA. Besides RDP access, the only other network exception required is for software activation of the operating system. All other outbound access to other hosts can be disabled. This process will explicitly allow to the root CA to reach the server kms.core.windows.net on TCP port 1688 and TCP/UDP port 3389 to key systems permitted remote access.
The second hurdle to surmount is protecting the root CA’s private key information. Microsoft’s Azure Key Vault (AKV), the Azure alternative to an HSM , does not support Active Directory Certificate Services, so the Azure-based implementation of the root CA is best served using an operating system based software key storage provider. This means protecting the entire root CA operating system is required to protect the private key. Access to the root CA is critical and, while it may be drastic, the best way to protect the root CA operating system from unauthorized access is at a higher level, either by placing the root CA in its own resource group or, to satisfy the extremely strict, its own Azure subscription.
Protecting the organization’s root CA from mistakes, like accidental deletion, can be achieved by granting this level of accessibility to a small number of people; this process is easily managed. A separate subscription can also result in better independent administrative controls for this critical system.
A Note on Policy CAs and Issuing CAs
If deploying a three-tier PKI solution with dedicated policy servers, then access to policy CAs would best reflect the processes used to manage the root CA server. Dedicated issuing CAs or combination issuing/policy CAs are active systems that need to communicate with the rest of the network. Deploy these systems as on-premises but use Azure IaaS instead.
Standing up PKI in Azure is not all that different than implementing in an on-premises environment when it comes to online/issuing CAs. Offline systems are the key differentiator between on-premises and cloud deployments and with a little bit of careful planning, these special cases can be easily managed.