AWS for Industries

AWS Private Certificate Authority

In this edition of the Financial Services Industry (FSI) Services Spotlight monthly blog series, we highlight five key considerations of AWS Private Certificate Authority (AWS Private CA): achieving compliance, data protection, isolation of compute environments, automating audits with APIs, and operational access and security respectively. Each of the five areas includes specific guidance, suggested reference architectures, and technical code that can help streamline service approval of AWS Private CA. These must be adapted to your business, compliance, and security requirements. This edition of the Service Spotlight will feature AWS Private CA: a service that helps you to create private certificate authority hierarchies and issue and revoke digital certificates deployed in your organization’s private-public key infrastructure (PKI), including on AWS managed resources and in the Internet of Things.

AWS Private CA provides secure identity through digital certificates. Similar to how websites and internet applications use public certificates to prove identity and ensure secure connections with consumers over TLS. Customers prefer private certificates over public ones to identify internal resources without leaking internal information and to support customization in ways that public certificates do not allow.

With AWS Private CA, enterprise customers can build a PKI inside the AWS cloud for private use within an organization. AWS manages the undifferentiated heavy lifting of creating, managing, and securing CAs. With AWS Private CA, you can create your own CA hierarchy and issue certificates for authenticating internal users, computers, applications, services, servers, devices, and signing computer codes. Certificates issued by a private CA are trusted only within your organization, not on the Internet. Private CA customers get security, configuration, management, and monitoring of a highly available private CA without hiring a security and maintenance team or the cost and commitment required to buy a third-party solution.

After creating a private certificate authority (CA), you can issue certificates directly (without obtaining validation from a third-party CA) and customize them to meet your organization’s internal needs.

Today, many FSI customers are leveraging AWS Private CA for their private PKI requirements. Goldman Sachs uses AWS Private CA to authenticate clients connecting to Amazon Managed Streaming for Apache Kafka (Amazon MSK) brokers.

Achieving Compliance with AWS Private CA

Security and compliance are a shared responsibility between AWS and the customer. AWS will operate, manage, and protect the infrastructure that runs the AWS services. The customer’s responsibility is determined by the service selected; the more managed services are used, the less customer configuration is required. When using AWS Private CA, the customer’s responsibility is determined by your AWS service. You are also responsible for other factors, including the sensitivity of your data, your company’s requirements, and applicable laws and regulations.

AWS Private CA falls under the scope of the following compliance programs concerning AWS’s side of the shared responsibility model. The related documents are on demand under an AWS non-disclosure agreement (NDA) through AWS Artifact.

C5 Cloud Computing Compliance Controls Catalog
CCCS Canadian Centre for Cyber Security
DESC CSP Dubai Electronic Security Centre Cloud Service Provider Security Standard
DoD CC SRG Department of Defense Cloud Computing Security Requirements Guide
ENS High Esquema Nacional de Seguridad
FedRAMP Federal Risk and Authorization Management Program
FINMA Swiss Financial Market Supervisory Authority
	
	
HIPAA BAA Health Insurance Portability and Accountability Act
HITRUST CSF Health Information Trust Alliance Common Security Framework
	
	
	
ISO and CSA STAR certificates International Organization for Standardization (ISO) and Cloud Security Alliance (CSA) Security Trust Assurance and Risk (STAR)
	
MTCS Multi-Tier Cloud Security
	
PCI Payment Card Industry Data Security Standard
Pinakes	Banking association CCI - Third-Party Qualification
PiTuKri Criteria for Assessing the Information Security of Cloud Services
SOC 1,2,3 System and Organization Controls

Data protection in AWS Private CA
Encryption in transit

AWS Private CA can be accessed via the network using AWS API. Clients should support Transport Layer Security (TLS) 1.0 or later. We recommend TLS 1.2 or later. Clients must also support cipher suites with perfect forward secrecy (PFS), such as Ephemeral Diffie-Hellman (DHE) or Elliptic Curve Ephemeral Diffie-Hellman (ECDHE). Most modern systems, such as Java 7 and later, support these modes.

Additionally, requests must be signed using an access key ID and a secret access key associated with an IAM principal. Or you can use the AWS Security Token Service (AWS STS) to generate temporary security credentials to sign requests.

Encryption at Rest

AWS Private CA stores certificate authority private keys in FIPS 140-2 hardware security modules (HSMs). In most regions, these comply with FIPs 140-2 level 3 (or higher), few regions support FIPS 140-2 level 2 (or higher); for a list of FIPS security compliance levels per region, see the AWS Private CA user guide. Private CA certificates are issued based on a key pair and certificate signing requests created by the customer. It is the customers’ responsibility to ensure that the private component of the key pair is suitably protected. The post on how to use AWS Secrets Manager to simplify the management of private certificates”, in the AWS Security Blog,  provides an example of protecting private key material using AWS Secrets Manager to simplify the management of private certificates and their key material when deploying to an EC2 instance.

When you use AWS Certificate Manager (ACM) to request a certificate from AWS Private CA, ACM generates a public/private key pair. The public key becomes part of the certificate. ACM stores the certificate and its corresponding private key, using AWS Key Management Service (AWS KMS) to help protect it.

Isolation of computing environments in AWS Certificate Manager

AWS Private CA is a managed service that does not provide isolated compute resources on the customer’s side of the shared responsibility model. As a managed service, AWS Private CA is protected by the AWS global network security procedures described in the Introduction to AWS Security whitepaper.

AWS Private CA instances can be shared securely using two mechanisms. The first mechanism allows sharing a certificate authority using AWS Resource Access Manager (RAM). The second mechanism allows for communicating using a resource-based policy applied to the certificate authority. In both cases, customers can create interface VPC endpoints to ensure that the API calls to AWS Private CA stay inside their VPCs.

AWS Resource Access Manager

Access sharing via AWS RAM is a common scenario among FSI customers. In this case, the CA administrator uses AWS Resource Access Manager (AWS RAM) to share Private CA access with another AWS account, which allows that account to issue private certificates.

Cross Account Sharing with Resource-Based Policy

Another way to permit cross-account access to a Private CA is to apply a resource-based policy on the private certificate authority. The following policy snippet demonstrates granting a user in another account access to a CA.

{                        
   "Version":"2012-10-17",
   "Statement":[
      {    
         "Sid":"1",
         "Effect":"Allow",         
"Principal":{                                                                                                                                               
            "AWS":"account"                                                                                
         },
         "Action":[
            "acm-pca:DescribeCertificateAuthority",
            "acm-pca:GetCertificate",
            "acm-pca:GetCertificateAuthorityCertificate",
            "acm-pca:ListPermissions",
            "acm-pca:ListTags"                                                                                   
         ],                                                                                              
         "Resource":"arn:aws:acm-pca:region:account:certificate-authority/CA_ID"
      }
   ]
}

VPC PrivateLink

Customers can establish private connections between their VPC and AWS Private CA by creating an interface VPC Endpoint as described here. Interface VPC Endpoints are powered by AWS PrivateLink. This technology lets you privately access AWS Private CA without an Internet Gateway, NAT device, VPN connection, or AWS Direct Connect connection. Using an interface VPC Endpoint, instances in your VPC don’t need public IP addresses to communicate with AWS Private CA, and the traffic between your VPC and AWS Private CA does not leave the Amazon network.

Automating audits with APIs

Financial institutions must often audit their AWS services for usage, user activities, and resource changes as part of their standard IT security and compliance policies. You can use AWS CloudTrail to log all API calls to the AWS Private CA.

AWS Private CA integrates with AWS CloudTrail. AWS CloudTrail captures API calls for all events, including calls from the AWS Private CA console and code calls to AWS Private CA API operations. Using the information collected by AWS CloudTrail, auditors can determine the request, the IP address from which the request was made, who made it, and when it was made.

Sample AWS CloudTrail request

Figure 1 Sample AWS CloudTrail event history

Figure 1: Sample AWS CloudTrail event history

Details for one of the CreateCertificateAuthority event is as shown below.

Figure 2 Sample AWS CloudTrail event showing CreateCertificateAuthority event details

Figure 2: Sample AWS CloudTrail event showing CreateCertificateAuthority event details

Another way to capture audit information of AWS Private CA is by leveraging Audit reports. Customers can create an audit report listing all certificates that private CA has issued or revoked. The report is saved in a S3 bucket.

Figure 3 Sample AWS Private CA Audit Report entries

Figure 3: Sample AWS Private CA Audit Report entries

End Entity Certificate issuance and renewal process

Private certificate authorities created in AWS Private CA can issue end-entity certificates by invoking the AWS Private CA issue-certificate command directly or by invoking request-certificate on AWS Certificate Manager (ACM). Private certificates requested via ACM can be applied to services such as Elastic Load Balancer, Amazon CloudFront, Amazon Cognito, AWS Elastic Beanstalk, AWS App Runner, Amazon API Gateway, AWS Nitro Enclaves, AWS CloudFormation, AWS Amplify, Amazon OpenSearch Service and AWS Network Firewall (please refer to the product documentation for a complete list of services integrated with AWS Certificate Manager).

Private certificates created via AWS Certificate Manager are valid for 13 months. They can be renewed automatically by the AWS Certificate Manager after 12 months. Customers can use Private CA certificates on AWS integrated endpoints but require different validity or renewal periods cannot be renewed automatically. The customer’s responsible for automating the renewal process in this case.

The renewal process can be automated using Amazon CloudWatch, either by using Amazon CloudWatch events to identify expiring certificates or Amazon CloudWatch rules to identify all expiring certificates. A post in the AWS Security Blog describes how to monitor expirations of imported certificates in AWS Certificate Manager (ACM).

Alternatively, customers can monitor certificate expiry using the AWS Private CA Audit Reports. This solution makes use of a scheduled standard Amazon EventBridge rule. This rule targets a AWS Lambda function responsible for generating a new AWS Private CA Audit Report, storing this report in Amazon S3, and parsing the audit report to determine which certificates are approaching expiration. Finally, for each certificate approaching its expiration date, an end-user is notified via Amazon Simple Notification Service (SNS).

Figure 4: Sample architecture for the renewal process

Figure 4: Sample architecture for the renewal process

Operational access and security

Use Service Control Policies (SCPs) to manage IAM permissions within your AWS Organization. SCPs are an organization policy that can be used to manage permissions in your organization. SCPs offer central control over the maximum permissions for all accounts in your organization. SCPs help ensure your accounts stay within your organization’s access control guidelines.

Using SCP’s actions such as policy deletion, permission deletion, and configuring tagging restrictions.

Sample SCP to deny deletion of certificate authorities untagging.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Deny",
            "Action": "acm-pca:DeleteCertificateAuthority",
            "Action": "acm-pca:UntagCertificateAuthority",
            "Resource": "*"
        }
    ]
}

The following figure illustrates the current user is denied the ability to untag the certificate authority with the SCP in place.

Figure 5 Untag operation forbidden by SCP

Figure 5: Untag operation forbidden by SCP

Access Control using Resource-Based Policy

Another critical security aspect within AWS Private CA is using a resource-based policy. As previously illustrated, this can be used to allow cross-account access to Private CAs but is also essential for enforcing what types of certificate client applications can issue with the private certificate authority. The following snippet will enable principals in another account to issue certificates, but only if they are End Entity Certificates as defined by the End Entity Certificate template, V1. The purpose and types of certificate templates are described in the understanding certificate templates of the AWS Private CA user guide.

{                        
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"1",  
         "Effect":"Allow",
         "Principal":{
            "AWS":"source-account"
         },
         "Action":[
            "acm-pca:IssueCertificate"
         ],
         "Resource":"arn:aws:acm-pca:region:account:certificate-authority/CA_ID",
         "Condition":{
            "StringEquals":{
               "acm-pca:TemplateArn":"arn:aws:acm-pca:::template/EndEntityCertificate/V1"
            }
         }
      }
   ]
}

Conclusion

In this post, we reviewed AWS Private CA and highlighted key information that can help FSI customers accelerate the approval of the service within these five categories: achieving compliance, data protection, isolation of compute environments, automating audits with APIs, and operational access and security. We encourage customers to use the controls highlighted in this blog appropriately, following their business needs and AWS environment. While not a one-size-fits-all approach, the guidance can be adapted to meet your organization’s security and compliance requirements and provide a consolidated list of crucial areas for AWS Private CA.

In the meantime, visit our AWS Financial Services Industry blog channel and stay tuned for more financial services news and best practices.

Steve Lynch

Steve Lynch

Steve is a Principal Security Solutions Architect for the Global Financial Services (GFS) organisation at AWS. He helps large financial institutions to make best use of AWS security products and to move their most sensitive workloads to the cloud. Steve has more than 25 years of experience of building highly reliable security infrastructure for enterprises.

Anu Jayanthi

Anu Jayanthi

Anu Jayanthi is an AWS Solutions Architect. She works with Startup customers, providing advocacy and strategic technical guidance to help plan and build solutions using AWS best practices.