Problem statement
Since the introduction of HIPAA in 1996, healthcare providers have invested in different solutions to secure sensitive patient data. These providers are increasingly turning to the cloud, which has quickly become a low-cost way to develop the complex infrastructure required to support their critical organizational activities. The most important items for HIPAA compliance are:
- Encryption at rest and in transit
- Strict access policies and limited access to PHI
- Activity logs and audit controls
- Reporting security incidents
Multi-account AWS infrastructure makes it easier to manage protected health information (PHI) and improve overall security and accountability by isolation of different environments.
This post will cover the use of AWS Control Tower to provide an easy way to set up and govern a new, secure, multi-account AWS environment based on best practices established through AWS’ experience working with thousands of enterprises as they move to the cloud.
Solution overview
AWS Landing zone contains several accounts for every application for different environment and management purposes:
- Root account is used for consolidated billing, managing service control policies (SCP), pipeline for the Control Tower Customization solution and SSO configuration for an external identity provider as G-Suite.
- Logging account is used for storing logs from all accounts within AWS organization and services such as CloudTrail, AWS Config, GuardDuty, VPC FlowLogs, ELB access logs, API Gateway and Lambda logs.
- Audit account is used for GuarDuty master and SNS notifications for the security team. It gives security and compliance teams read and write access to all accounts in a landing zone.
- Networking account is used for central management VPC, Transit Gateway, VPN connections and Serverless Transit Network Orchestrator which allows to automate connecting new VPCs to the central Transit Gateway and manage routing for different environments.
- Application accounts are separate for every application environment such as Prod, Stage, Dev.
Service control policies (SCP) are used to prevent application accounts using AWS resources in regions other than US-EAST-1 (Northern Virginia).
The diagram below describes high-level design of a multi-account AWS environment for healthcare application.
Solution design
Network
Network segmentation is an important part of a cloud infrastructure security and highly effective strategy to limit the impact of network intrusion. AWS Transit Gateway (TGW) is used for a solution for secure network traffic in multi-VPC environments.
Management VPC is a core of network infrastructure. It contains AWS Transit Gateway, Serverless Transit Network Orchestrator and VPN connections for technical staff. Once a new VPC is created in an application account, CloudWatch event triggers Lambda function that attaches VPC to the central Transit Gateway and appropriate routes are propagated. Despite the fact that VPCs are connected to the Transit Gateway, networks are isolated from each other, for example, Dev resources can not access Prod. Environments are isolated and the only way to access an application environment is through the Management VPC in the Networking account. For the audit and monitoring purposes VPC Flow Logs are being sent to the Log Archive account.
The diagram below describes network interconnection between central management VPC and application VPC.
Threat detection
Logs collected from different AWS services such as CloudTrail event logs, VPC Flow Logs and DNS logs can be used by the AWS GuardDuty to analyze tens of billions of events across multiple AWS data sources. GuardDuty uses machine learning, anomaly detection, and integrated threat intelligence to identify and prioritize potential threats.
To manage multiple accounts in Amazon GuardDuty, AWS recommends to choose a single AWS account to be the master account for GuardDuty, this is the Audit account in our case. Other accounts are then associated with the master account as member accounts. There are many types of threats that GuardDuty is able to detect:
- Port scanning.
- SSH/WinRM/RDP bruteforce.
- Denial of service TCP/UDP/DNS. Outbound traffic from EC2.
- Bitcoin tools on EC2 or other cryptocurrency-related activity.
- Spam bots on EC2.
- Penetration tests using Kali/Parrot/Pentoo Linux.
- Using AWS Root credentials.
- Change of IAM password policy.
- Trojans on EC2.
- EC2 as a client on a Tor network.
- Unusual traffic volume.
- and many more
The diagram below describes high-level design of multi-account GuardDuty implementation.
AWS master account runs a pipeline that makes any new AWS account within an organization to activate GuardDuty and accept an invitation from GuardDuty master. Audit account contains SNS topics for notifications about any security issues found by GuardDuty or AWS Config.
Centralized logging
Logging account works as a repository for logs of API activities and resource configurations from all accounts in the landing zone. CloudTrail and AWS Config logs by default are being sent from all accounts to an encrypted S3 bucket in the Logging account. In this solution other logs such as VPC Flow Logs, GuardDuty logs and API Gateway access logs are being sent to dedicated S3 buckets in the Logging account as well. This is necessary for HIPAA compliance audits and useful for the day-to-day monitoring and analysis of infrastructure and activities.
The diagram below describes high-level design of centralized logging implementation for a multi-account AWS infrastructure.
Storing logs in the dedicated and isolated AWS account can help keep their integrity and authenticity.
Compliance monitoring
AWS Control Tower provides “guardrails” as high-level rules that enable ongoing governance for the overall AWS environment. Through guardrails, AWS Control Tower implements preventive (SCP) or detective (AWS Config) controls that help govern resources and monitor compliance across groups of AWS accounts.
A guardrail applies to an entire organizational unit (OU), and every AWS account within the OU is affected by the guardrail. Therefore, when users perform work in any AWS account in your landing zone, they’re always subject to the guardrails that are governing their account’s OU.
You can see compliance status for every AWS account on the Control Tower Dashboard. In the below example there is a Root account fully compliant with 26 configured guardrails such as:
- Disallow creation of access keys for the Root user
- Enable encryption for Amazon EBS volumes attached to Amazon EC2 instances
- Disallow internet connection through RDP/SSH
- Enable MFA for the Root user
- Disallow public read access to Amazon S3 buckets
- Disallow public access to Amazon RDS database instances
- Disallow Amazon RDS Database Instances That Are Not Storage Encrypted
- and many more
But some accounts are Noncompliant and it is easy to check resources which cause it. Performance-US account is not compliant with one rule. Need to enable MFA for the root user.
Another account, which was created long before the Control Tower setup, has several issues such as unencrypted EBS volume and security group with a rule allowing incoming SSH access from 0.0.0.0/0
Having such reports we can easily fix all resources which violate compliance rules and make our cloud infrastructure much more secure. Moreover, the security team continuously receives notifications about any changes in the AWS cloud infrastructure that lead to Noncompliant status.
Conclusion
AWS Control Tower provides an AWS environment creation and management according to AWS best practices across the most relevant pillars.
The organization’s operational excellence is taken into consideration from the very early stages of the Control Tower solution design. The business requirements at all levels are actually translated into the different accounts responsibility, services that are going to be used and levels or separation.
The environment is well secured, applies security according to the organization’s different levels, helps the customer to define and apply different levels of encryption and access control.
The additional accounts that contain logging and monitoring tools provide the organization the ability to keep the system reliable at all time, provide reliable and scalable environments to customers and in-house users.
Last but not least, cost analysis tools are kept in use during the whole systems lifecycle, make sure that the organization measures the computing resources and services efficiency in the production and development environments, and help cost planning according to the organization requirements and expansion.
