How to build a highly available, highly scalable AWS secure cloud? – PART II

The scope of this post will be to discuss the security features provided by AWS. Now that we have covered all designing concepts in the previous post, let us dive deeper and address the security of our cloud architecture.

Securing the Architecture
Security of cloud environment is important considering the enormous impact it has on core operations. We will address security requirements (S1 and S2) in this section.

• S1. Securing data at rest and in transit
• S2. Manage access control as the user base expands

Amazon offers several services that integrate with other services to help improve overall security posture. Following services are significant to our architecture:

VPC (VIRTUAL PRIVATE CLOUD)
Network segmentation is one of the basic controls for restricting access to authorised users. VPC is a logically isolated section of AWS cloud where customers can launch AWS resources in a virtual network. VPC is similar to traditional networks and enables the seamless creation of public/private subnets, and control access using security groups.
Furthermore, our architecture stack i.e. OpsWorks stack needs to be launched in a VPC. Once main VPC is created it is assigned an Internet Gateway. We need to logically isolate DMZ Tier, Web Tier, and Database Tier. Also, Web Tier and Database Tier will have a private VPC for each availability zone connected with VPC peering.

• DMZ Tier contains ELB, CloudFront, and a public subnet with Bastion host and NAT Gateway.
• Web Tier is a private subnet managed by OpsWorks App Layer and consists of EC2 instances.
• Database Tier is a private subnet managed by RDS OpsWorks Layer and consists of AWS Aurora RDS instances.
• VPC endpoints should be setup to access private S3 bucket and Glacier vaults from private VPC’s.

SECURITY GROUPS
Security groups are similar to router ACL’s that implement access control on resources in a particular subnet (VPC). Security groups and VPC allow customers to choose the private IP ranges and subnet masks as per requirement. We will create three groups: DBGroup for database instances, WebGroup for server instances and DMZ group for public instances. Briefly, following controls should be implemented for VPC’s using security groups:

• A Database private subnet (DBGroup) is only accessible from web server subnet (WebGroup)
• A web server subnet is only accessible from elastic load balancer (ELB).
• Web and Database subnet allows outbound connections to NAT device. This is required for software updates or other maintenance that require access to the Internet.
• A bastion host is only accessible from public IP (on-premise system) provided by customers network over RDP.

IDENTITY ACCESS MANAGEMENT (IAM)
Amazon IAM enables us to manage user access to AWS resources on a need-to-know basis. IAM supports the creation of user, role and groups permissions. Following basic IAM controls need to be in place to secure the environment:

• Never use AWS Master Account to login. It provides super-user access to all resources in AWS cloud.
• Create IAM Roles and assign roles to instances. RBAC can be implemented using IAM features.
• Enable two-factor-authentication for IAM users.
• Resource and user policies must be defined to restrict access to S3 and Glacier repositories.

AWS KEY MANAGEMENT SERVICE (KMS)
KMS is a managed service that handles encryption keys used to encrypt data mentioned in S1 requirement. KMS integrates with Amazon CloudTrail to log key usage.

ENCRYPTION

Data at Rest
AWS offers three Key Management Infrastructure (KMI) models for encrypting data at rest. These models are based on the level of control AWS and customers have on KMI components. AWS manages the entire KMI in Model C and offers server-side encryption all storage services referenced in this guide. Model C server-side encryption is recommended for current architecture to avoid key management overhead for the customer. It uses an AES-256 algorithm for server side encryption and all storage services in our architecture support this feature.

Data in transit
AWS services support IPsec and SSL/TLS for encrypting data in transit. IPsec offers applications layers to communicate securely without any modification. SSL/TLS, on the other hand, and often requires application layer support. Moreover, HTTPS traffic can be offloaded at ELB to minimise performance impact on web servers, however, security and performance requirements need to be evaluated based on data criticality.

LOGGING AND MONITORING
Logging and monitoring user activity is one of the core principles of information security. CloudTrail web service tracks API calls on AWS account and stores log files to S3 bucket. It integrates seamlessly with AWS OpsWorks and affords compliance with standards and policies.

SECURITY PATCHING
Infrastructure security of EC2 instances needs to be managed by customers including patching and hardening. Security and maintenance of services like ELB and RDS are managed by Amazon.Conclusion

Conclusion
We have identified all the concepts and components required to build an AWS architecture that meets customer requirements. Final reference architecture shown below is an accretion of these concepts and components. The architecture is self-explanatory, however, do let us know in comment section if you have any queries.