Migration Of On-Prem PCI Stack to AWS Reference Architecture
This page goes over the Migration Reference Architecture for a PCI stack deployed in the premises to AWS Cloud. The main goal of this blog is to provide an incremental architecture with common pitfalls that are often overlooked and caught by the QSA in the audits later in the journey. I hope this blog helps reduce back and forth between the external QSA auditor and the rest of the internal teams, thereby making your PCI-DSS certification journey a blissful one.
I have arranged the flow of the blog as follows
- Goals
- The Basics
- The Intermediate
- The Advanced
You have to get your architecture either to the intermediate or advanced level to get the application PCI-DSS certified.
Goals
Migrate On-Prem application to the cloud with minimal refactoring to transform the application into an AWS Well-Architected application that is PCI-DSS compliant. I assume you all know
What the heck is a Well-Architected application?
I will cover here briefly just for the sake of completion. They are as follows
- Easy To Operate the Stack(s)
- Highly Secure with Continuous Monitoring for Security
- Highly Reliable
- Highly Performant Stack(s)
- Cost Optimized
- Sustainable
I have summarized an incremental architecture from ‘the basic’ followed by ‘intermediate’ and finally ‘advanced’. As I said, we want to be in the intermediate or advanced level to meet the PCI-DSS.
The Basics
I have categorized the architecture into the following sections under ‘the basics’
- Network Architecture
- Application Architecture
- Database Architecture
- Security Architecture
Network Architecture
- Route 53 as DNS Server.
- Standard, External/Internet-facing virtual private cloud (VPC).
- Three-Tired Architecture with one public subnet and two private subnets where the application and database layers are residing in the private subnets
- Multi-AZ architecture with an Application Load Balancer(ALB) to balance load across the AZs
- We will have to configure WAF for Application Load Balancer(ALB)
- Managed Internet Gateway (IG) to allow inbound traffic into the private subnet for applications
- Managed Network Address Translation (NAT) gateways to allow outbound internet access for resources in the private subnets
Application Architecture
- Refactored On-Prem application to make it AWS Cloud compatible.
Common Pitfalls to Avoid: Refactoring application assumes best practices outlined by the cloud provider, implementation language, and other basic good practices such as externalizing all the parameters.
- Containerize the Application.
Common Pitfalls to Avoid: The base image shall be hardened and pulled from a PCI Complaint source.
Database Architecture
I am assuming the On-Prem database to be a SQL-flavored one.
- Multi-AZ Amazon RDS SQL database.
- Enable Data Encryption at rest.
Security Architecture
Security Architecture should have the following minimum constructs in place.
- Utilize AWS Certificate Manager to request a new certificate or import a certificate
Import On-Prem/Equivalent Certificate
Request AWS Certificate
- Utilize WAF-managed rule set the protect the requests coming into the ALB.
- Utilize Network access control list (network ACL) rules to filter traffic. I am assuming the target audience knows that NACLs are stateless.
Should you decide to use NACL, you will need to configure inbound and outbound traffic.
- Leverage AWS Identity and Access Management (IAM) configuration with custom (IAM) policies, with associated groups, roles, and instance profiles provided by the AWS-Cloud InfoSec team in your organization.
- Utilize Security Groups to restrict access to the resources by configuring ports
- Utilize AWS Secrets Manager to store and retrieve any keys/passphrases used in the Architecture.
- Utilize AWS KMS for all the Key Management. You can either use AWS-KMS or Cloud HSM/External as the Key Material Origin. My recommendation is to use AWS KMS; unless any business implications mandate you to use Cloud HSM/External.
- Use encryption on Amazon Simple Storage Service (Amazon S3) buckets for logging, backup data, and web content if you are using any.
- Use AWS CloudTrail, Amazon CloudWatch, and AWS Config for enabling monitoring and alerts.
The Intermediate
I am going to go over in the same order as above. I will add more services at each layer to take it to the intermediate level.
- Network Architecture
- Application Architecture
- Database Architecture
- Security Architecture
Network Architecture
- Utilize Global Accelerator as an optional step. It comes with two perks: 1) QSAs are going to love the architecture from the security perespective as it comes with two Static IPs. The FQDN (Fully Qualified Domain Name) will always resolve to one of the Static IPs. 2). It allows the architecture to extend to Multi-Region architecture
- Endpoints need to be created to access Managed AWS Services such as Secrets Manager, S3, etc. The type of endpoints can be of Interface or Gateway type
Application Architecture
- If there are any lambda(s) or containers that needs to be run, you can deploy in the same subnet where the primary application is deployed
- Application containers should access other containers (if there any) over private hosted URL.
- Application containers should access DB over a URL in Private Hosted Zone
Database Architecture
You will need to create a URL in the Private Hosted Zone to access the Database.
Deploy a lambda function/equivalent to rotate the Database access credentials.
Deploy a lambda function/equivalent to rotate the encryption key that encrypts the DB password.
Security Architecture
The following security architecture has some of the items recommended by AWS for PCI-DSS.
- All the lambdas should be implemented in the Payment VPC.
- ECR Image tag Immutability should be turned on.
- ECR Image scan should be turned on.
- ECR Image manual deletion should be turned off.
- ECR Image addition events may be channeled via Event Bridge to your Info-Sec / Operations team. It is an optional step.
- AWS Shield Advanced should be turned on.
- Amazon Virtual Private Cloud (Amazon VPC) default security group should prohibit inbound and outbound traffic.
- Security groups should not allow inbound traffic from 0.0.0.0/0 to port 22.
- Amazon VPC flow logging should be enabled in all VPCs.
- AWS Identity and Access Management (IAM) root user access key’ should not exist.
- S3 buckets should prohibit public read access.
- S3 buckets should have cross-Region replication enabled.
- S3 buckets should have server-side encryption enabled.
- [GuardDuty.1] Amazon GuardDuty should be enabled.
- IAM access keys should be rotated every 90 days or less.
- Amazon RDS database instances should have encryption at rest enabled.
Common Pitfalls to Avoid:AWS Managed Rules for AWS WAF has a maximum web ACL capacity unit (WCU) limit. You may need to be selective on the managed rules.
Centralized Logging Architecture
As per the PCI DSS, we need to maintain centralized logging outside of the Payments account for logging all the events in PAC Cloud.
- All the logging, monitoring, and alerts from sources such as CloudTrail, CloudWatch, and AWS Config rules need to be streamed to the centralized logging account (if your organization has one) or another AWS Account outside of the payment account.
- These logs need to be encrypted as well.
The Advanced
In this section, I will go over how to leverage AWS Security Hub for automated real-time remediations for Payment Card Industry Data Security Standard (PCI DSS) and AWS Foundational Security Best Practices (AWS FSBP) policy violations detected by AWS Security Hub.
I have summarized it below.
Integrate AWS Security Hub custom actions with AWS Systems Manager automation documents to provide real-time remediations of AWS Security Hub PCI DSS and AWS FSBP findings as follows:
- Leverages the ability of AWS Security Hub to send findings associated with custom actions to Amazon CloudWatch Events as Security Hub Findings — Custom Action events.
- The CloudWatch Events rule invokes the corresponding AWS Lambda function as the target for the Security Hub custom action event.
- The AWS Lambda function updates the dashboard that your Info-security team has put together, followed by processing the finding using the AWS Security Finding Format (ASFF) and invokes the corresponding AWS Systems Manager Automation Document with the input from the ASFF finding.
- AWS Systems Manager remediates the Security Hub finding.
All these items can be managed via Cloud Formation or Terraform templates that are used in your organization. This is explained in much detail here https://aws.amazon.com/quickstart/architecture/compliance-pci-fsbp-remediation/
