Public Key Infrastructure – an overview of Cloud usage

Purpose

This note provides an overview of PKI and issues many firms will face.   It deals with infrastructure for large firms, which usually have most if not all of the following:

• AD, Citrix, iDaaS, File Servers, O 365, Microsoft Exchange Server, even Printers (domain based access).

You need to deploy PKI when migrating to, or building out a cloud platform.  Many firms do not understand that a well-defined and deployed PKI architecture, precedes a cloud deployment. This is particularly true of a ‘multi-cloud’, or ‘hybrid on-premise, cloud’ infrastructure.  Too often security including PKI is an afterthought and that is dangerous.

Definition of terms one finds when discussing Public Key Infrastructure

Abbreviation	Description
PKI	A public key infrastructure (PKI) is a set of roles, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates and manage public-key encryption.
CA	Certification Authority, is an entity that issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate.
Digital Certificates	In cryptography, a public key certificate (also known as a digital certificate or identity certificate) is an electronic document used to prove ownership of a public key.
VPC	Amazon Virtual Private Cloud (VPC) is a commercial cloud computing service that provides users a virtual private cloud, by provisioning a logically isolated section of Amazon Web Services (AWS) Cloud.
AD	Active Directory (AD) is a directory service that Microsoft developed for Windows domain networks
Forest	At the top of the AD structure is the forest. A forest is a collection of trees that share a common global catalog, directory schema, logical structure, and directory configuration.
Tree	AD tree is a collection of one or more domains and domain trees in a contiguous namespace, linked in a transitive trust hierarchy.
Domain	A domain is defined as a logical group of network objects (computers, users, devices) that share the same Active Directory database.
DC	A domain controller (DC) is a server that responds to security authentication requests (logging in, checking permissions, etc.) within a Windows domain

 

Digital certificates affirm the identity of the certificate subject and bind that identity to the public key contained in the certificate.

PKI key elements:

• A trusted party, called a certificate authority (CA), acts as the root of trust and provides services that authenticate the identity of individuals, computers and other entities
• A registration authority, often called a subordinate CA, certified by a root CA to issue certificates for specific uses permitted by the root
• A certificate database, which stores certificate requests and issues and revokes certificates
• A certificate store, which resides on a local computer as a place to store issued certificates and private keys

Workflows:

• A CA issues digital certificates to entities and individuals after verifying their identity.
• It signs these certificates using its private key; its public key is made available to all interested parties in a self-signed CA certificate.
• CAs use this trusted root certificate to create a “chain of trust”, with many public vendor root certificates embedded in Web browsers so they have built-in trust of those CAs.
• Web servers, email clients, smartphones and many other types of hardware and software also support PKI and contain trusted root certificates from the major CAs.
• Along with an entity’s or individual’s public key, digital certificates contain information about the algorithm used to create the signature, the person or entity identified, the digital signature of the CA that verified the subject data and issued the certificate, the purpose of the public key encryption, signature and certificate signing, as well as a date range during which the certificate can be considered valid.

Components

Options for delivering PKI within a Cloud platform are discussed.  Key components that many firms have which will need or be impacted by PKI include the following:

• Active Directory Domains
• Citrix Netscaler-AppV- infrastructure
• iDaaS or Identity Management as a Service (OKTA, OneLogin etc)

 

There are 2 different ‘levels’ of PKI (to keep it simple):  one is the network/VPN/IPSec level and the second is above the transport level for domain based applications, web applications, data access (eg AD, Citrix).  Most cloud projects will need to secure their machines, VPN access and authentication-authorisation at the application level, starting with Citrix, iDaaS and AD.

There are 5 concerns re PKI:

1) Citrix FAS to Windows Integration which needs a CA and could potentially use an existing PKI infrastructure if one exists;

2) The rest of the infrastructure including AD-OKTA which needs CA;

3) If an existing internal PKI infra exists for VPN/Machines/Web Applications there must be a process to extend that to the Public Cloud (eg AWS)

4) GlobalCA authority which is typically used for SaaS applications and multi-domain federated architectures where domains must try the CA from a global authority (eg. On-premise Domain CA is recognized by a public cloud domain).

5) PKI-CA encryption standards must be based on SHA-2 given that SHA-1 is defunct and has many security flaws.

 

Why PKI:

1. PKI would normally be deployed before applications are migrated to the Cloud or instantiated within a cloud architecture. Public key infrastructure (PKI) supports the distribution and identification of public encryption keys, enabling users and computers to both securely exchange data over networks such as the Internet and verify the identity of the other party.

 

2. Without PKI, sensitive information can still be encrypted (ensuring confidentiality) and exchanged, but there would be no assurance of the identity (authentication) of the other party. Any form of sensitive data exchanged over the Internet is reliant on PKI for security.

 

3. Note that Citrix needs a CA in order to facilitate SAML-Windows integration. Windows does not recognise native SAML calls.

 

4. SSO components such as OKTA need SAML Certificates to verify internet-based access to agents running on Cloud VMs (and to load balancers if being used)

 

PKI is necessary for most firms with complicated architectures especially when they include AD, Citrix, and an iDaaS.  For example, the Citrix Federated Authentication Server will need to authenticate against a Windows AD server.  In this use case, we will need to have a CA issuing a smart card to allow Citrix-to-Windows pass-through authentication over the domain trust, and the authentication is via smart card so this would imply trusting the domain controller cert, via a GlobalCA issuer; or an appropriate internal PKI server.

For the other components there are other ways to secure the infrastructure behind authentication to provide encryption, non-repudiation and secure end-point, data and application access.  PKI is necessary for multi-domains for AD authentication and to provide SSL for OKTA ELBs and for SaaS.

 

Figure:  2 Virtual Private Cloud Architectures with different domains using PKI

Complexity of PKI is evident for most firms – standard components which are impacted by PKI include: AD, Citrix, iDaaS, File Servers, O 365, Microsoft Exchange Server, even Printers (domain based access).

General Recommendations around PKI infrastructure:

1. If an existing on-premise PKI exists (most larger firms do have an internal CA server) investigate whether extending the current Windows CA infra to AWS is possible and satisfies cross-domain and SaaS CA requirements.
2. If the internal PKI is not SHA2 based, upgrade it immediately.
3. If the target platforms are using multi-AD domains and different SaaS and private cloud platforms, it will likely be necessary to do a trial project with a GlobalCA solution. An example is to have AWS domains accepting on-premise CA’s when both domains may be different.
4. Decide on how to manage PKI, what architecture it is (internal-only, GlobalCA only, or a hybrid).
5. Identify budgets and costs.
6. Before you migrate to the Cloud make sure PKI is deployed or ready to deploy to support the infrastructure components.
7. Do trial runs.

 

==END