As you move to the AWS cloud, you need to consider a number of security factors, including the following:
- Data security: The reality is that your data is typically more secure and durable when stored in the public cloud than in on-premises physical servers due to the multiple physical copies of any data records stored in public cloud storage. All storage mediums at AWS can also be easily encrypted with the Advanced Encryption Standard (AES). Amazon EBS volumes—both boot and data volumes—can be encrypted at rest and in transit, using customer mas-ter keys provided by AWS or keys provided by the customer. Shared storage services such as Amazon EFS and FSx for Windows File Server can also be encrypted at rest, as can all offered database engines. Amazon S3 buckets are encrypted with keys provided by the S3 service or the Key Management Ser-vice (KMS) shown in Figure 1-10. Data durability provides additional security as all data stored in the AWS cloud is stored in multiple physical locations.
For example, each EBS volume has multiple copies replicated within the data center where they are created.
Amazon S3 objects are replicated across at least three separate availabil-ity zones within the selected AWS region, producing a very high level of durability.
Figure 1-10 Encrypting S3 Buckets Using S3 Keys or AWS-KMS Managed Keys
- Data privacy: Amazon ensures that each AWS account’s stored data records remain isolated from other AWS customers. In addition, data records are always created as a private resource. Each S3 bucket can be shared publicly; however, each customer assumes the responsibility when changing a private S3 bucket to be publicly accessible across the Internet.
- Data control: Customers are fully responsible for storing and retrieving their data records stored at AWS. It’s the customer’s responsibility to define the security and accessibility of all data records stored at AWS.
- Security controls: AWS Identity and Access management permission policies can be defined at a very granular level to control access to all resources at AWS. Customers can also enable multifactor authentication (MFA) as an additional security control for all IAM users authenticating to AWS, and on S3 buckets when deletion of data records is attempted. Resource policies defining the precise level of security and access can be directly attached to resources such as S3 buckets.
Network Security at AWS
At AWS, networking is managed at the subnet level, and subnets are first created as private subnets with no direct access to the outside world. Subnets that reside on your private networks at AWS are hosted in a virtual private cloud (VPC). Only by adding gateway services to a VPC and route table entries are subnets able to be accessed from either the Internet, a private VPN connection, or from an external network location. The following are examples of networking services and utilities at AWS that help control network traffic:
- Each subnet’s ingress and egress traffic can be controlled by subnet firewalls called network ACLs that define separate stateless rules for inbound and outbound packet flow.
- Each EC2 instance hosted on a subnet is protected by a firewall called a security group, which defines what inbound traffic is allowed into the instanceand where outbound traffic is allowed to flow to.
- VPCs can be further protected by deploying the AWS Network Firewall, providing control over all network traffic, such as blocking outbound Server Message Block (SMB) requests, bad URLs, and specific domain names.
- VPC flow logs can be enabled to capture network traffic for the entire VPC, for a single subnet, or for a network interface.
Application Security at AWS
Both web and application servers hosted at AWS are usually located on private subnets, which are not directly accessible from the Internet. Customers requesting access to the application will be directed by DNS services (Route 53) to the DNS name of the load balancer, which in turn directs incoming traffic from the public subnet to the targeted web servers hosted in private subnets.
For example, the end-to-end traffic pattern for a three-tier web application can be designed using many encryption/decryption points on its path from source to destination, as described in the list that follows and as shown in Figure 1-11:
- AWS Web Application Firewall (WAF): AWS WAF is a custom traffic filter that can be associated with an Application Load Balancer to protect against malicious traffic requests.
- Application Load Balancer: An application load balancer can accept encrypted HTTPS traffic on port 443 and provide Secure Sockets Layer/ Transport Layer Security (SSL/TLS) decryption and, optionally, user authen-tication support.
- EC2 instance hosting a web application: EBS boot and data volumes can be encrypted using the AWS KMS service.
- EC2 instance hosting an application server: EBS boot and data volumes can be encrypted using the AWS KMS service.
- RDS database server: All boot and data volumes can be encrypted using the AWS KMS service.
Figure 1-11 Encrypted Traffic Flow at AWS