Options for delivering PKI within a Cloud model will be presented for discussion. If the enterprise has Citrix, note that Citrix needs a CA in order to facilitate SAML-Windows integration.
- PKI would normally be deployed before applications are migrated 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.
- 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.
PKI is necessary within a Cloud project for AD and Citrix, namely; to allow Citrix FAS to Windows AD authentication given that Windows does not support SAML, and allow CA’s within the domain forest for AD. We will need to have a CA issuing a smart card to allow Citrix-to-Windows pass-through authentication over the trust, and the authentication is via smart card so this would imply trusting the domain controller cert, via a GlobalCA issuer.
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. However, PKI is a part of Security Best Practices.
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, data access (eg AD, Citrix). A Cloud program could forego PKI at the machine-network level, and implement PKI at the domain-app-data level for example, starting with Citrix and AD.
- Implement a Global CA PKI for at least Citrix (if present) and AD (which will be present). Devices, Workspaces and other endpoints could wait until later.
- Current PKI infra is integrated with AD and managed by a Cloud MSP or SI. An interim BAU support needs to be identified.
Section 1: Assess the Current PKI Infra
It is necessary to understand the current PKI estate and then extend that to the AWS Cloud. For example, we will need to assess if the current PKI is integrated with AD and is used to provide CA for Web Servers.
Within the company Domain, the firm would have hardware, software, policies and standards to manage the creation, administration, distribution and revocation of keys and digital certificates. 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.
Table: Current PKI Assumptions
| # | Item | Implication |
| 1 | Understand who supports the current PKI infra and if they will no longer do so once AD is extended into the Cloud | Operations, support |
| 2 | Current GloblaSign CA supports WebServers | Cloud CA will need to support more than WebServers eg Citrix, AD |
Section 2: Challenges implementing Public Key Infrastructure in the Cloud
A Cloud platform will often times be comprised of multiple Active Directory (AD) Domains; or an extension of the current domain; and possibly several Amazon Managed Service Domain Services.
These domains are not all members of a common Directory Forest and so do not all share a common root.
In addition, there could be a requirement for certificate services to support VPN clients, Intune and Office 365 integration. These would need a separate look.
Domains:
- Domains will be linked via Trust Relationships and do not share a common directory root.
- Active Directory managed by policy, process, permissions, configuration.
Implications:
- Requires a PKI solution to span multiple domain and forests as well as internal and external access requirements.
- Requires PKI solution to meet needs of various actors and endpoints which could for example include: Okta, VPN, Active Directory, Bluecoat, NetScaler, Federation with SAML, Web servers, Office 365 and Intune as well as individual application server requirements.
| 1 | It is unlikely that a Client or its partners have the time, expertise, or the available resources to develop, test, deploy and then manage an internal-PKI infrastructure. |
| 2 | Citrix Cloud or any SaaS platform must use an external Global CA to recognize and accept the CAs |
.
Section 3: Public (GlobalCA), Internal, Hybrid PKI – Pros and Cons summary
3.1 Public vs Private CA
Public CA authorities such as Digicert allow customisable APIs for PKI workflows. Global CA authorities manage the infrastructure, and Enterprise domains would trust the ‘root’ of the CA provider. A similar architecture can be built ‘internally’ and managed by a partner. Some PKI architectures are hybrids, part of the infra is under the Global PKI provider and part managed on site. In some cases, it is possible to extend the existing Domain PKI to Citrix (or allow Citrix to access the same) to solution the requirement for FAS – CA integration with Windows.
**In general terms a Global-CA outsourced provider model is preferred since it would significantly reduce management complexity and allow a federate domain architecture to use PKI without domain-trust issues.
3.2 Global PKI
Purchasing or subscribing to a public PKI infrastructure has the following Pros and Cons associated with it. Options: GlobalSign, DigiCert
Pros:
- Ready to use solution including: Multi-Domain Certs; Standard SSL; Wildcard (some security implications for WildCard usage); Dedicated root, Custom Profiles, Certificate LCM, Centralized Cert management and reporting
- Allows complicated federated-domain architecture to recognize one global CA authority
- Compliant with industry security standards and policies
- Low cost to maintain beyond purchase/subscription cost
- Lower skills requirement to maintain and manage
- APIs can be customized from the main GlobalCA authority to allow for specific workflows to be secured which may not be part of standard public deployments (this would likely be relevant in most cases)
- Citrix and other Cloud-SaaS platforms will recognize the GlobalCA
Cons:
- Less flexibility, requirement to conform to vendors solution parameters – this is however mitigated by customisable APIs
- Higher costs than building internally (depending on solution and contract)
- Potential for incompatibility or lack of vendor support for integration with other 3rd parties
Architecture: The root CA sits outside of the client’s infra. All domains will recognise certs issued from the foot CA. Figure: Workflow PKI Architecture
- The Root CA signs the CA certificate for Sub CA Domain 1 – 4.
- The Sub CA Domain 1 signs Sub CA certificates of Users and Computers.
- Sub CA Users and Computers sign certificates for users while sub CA computers signs certificates for computer.
- Sub CA Domain 2 – 4 signs certificates for computers in their respective domains
When a user or a computer uses a certificate, it must verify the validity of its certificate authority and all CA on top until the Root CA, this is called the chain of trust, or certificate chain. Every certificate in the chain is checked and must be valid for the chain to be valid.
- PKI provides a chain of trust, so that identities on a network can be verified.
- Like any chain, a PKI is only as strong as its weakest link.
- If one CA is compromised, the security of the entire PKI is at risk.
3.3 AWS CMS
AWS Certificated Managements Services is an option, but has many limitations, would require an own-build and management and probably is inferior to a Global-CA authority solution. A GlobalCA is more conducive to best practices and a POC should focus on a Third-Party Solution.
Pros:
- Ready to use solution for AWS applications and services
- Allows centralized management of CA and certificates within AWS
- Compliant with industry security standards and policies
- Low cost to maintain beyond purchase/subscription cost
- Lower skills requirement to maintain and manage
Cons:
- Assumes that a root domain CA exists
- Need to build, manage – CA domain needs expertise
- Seems to be chasing what is already available with GlobalCA providers
- Large number of limitations in usage
- WildCard CA used which is not ideal and presents security risks
Does not seem fit
for purpose.
Section 4: PKI Recommended Solution
Use a Global 3rd party CA such as GlobalSign or Digicert. Focus the PKI on AD and Citrix to start with. Do a POC comparing 2 options. Present to the program, get a sign off and implement.
Design Assumptions:
| No | Item | Implication |
| 1 | GlobalCA Authority – with a dedicated root | Should replace current PKI infra |
| 2 | AWS – AMS trust should be 2-way | Should resolve cross domain acceptance issues |
| 3 | We will not issue CA’s for Users, or Laptop Devices but only use CA in the first phase, for AD, Domain certification and Citrix – FAS -Smart Card integration | PKI can be developed over time – the core infra components are the main concerns at this time |
| 3 | POC needs to be done for both GlobalSign and DigiCert for AD and Citrix | Agile team |
Figure: Complete CA Architecture
Figure: Targeted CA Architecture
There are cross – domain issues for AD, in which a CA is necessary to authenticate between domains. The Federated Authentication Service (FAS) is a Citrix component that integrates with the Active Directory certificate authority (CA), allowing users to be authenticated within a Citrix environment. The FAS issues a smart card certificate automatically on behalf of Active Directory users who are authenticated by StoreFront. This uses similar APIs to tools that allow administrators to provision physical smart cards.
- The user is brokered to a Citrix XenApp or XenDesktop Virtual Delivery Agent (VDA)
- The certificate is attached to the machine
- The Windows domain sees the logon as a standard smart card authentication.
- FAS will be utilised to authenticate users with XenApp worker servers using the Okta SAML assertion which is a cryptographically-signed XML block issued by a trusted IdP that authorizes a user to log on to a computer system.
==END