Security

Security should be considered job zero when designing a cloud architecture. It should be the first consideration you take, not the last – which is unfortunately too often the case. If securing your infrastructure is an inconvenient afterthought, it will be difficult, if not impossible, to keep your customer data safe and private.

The security pillar of the Well-Architected Framework focuses on protecting systems and information. Systems are the physical and virtual resources that you have provisioned in your IT environment, and information is the data that flows throughout those systems.

The foundation of any secure platform is Identity and Access Management (IAM). You must be able to reliably authenticate your users, and once you know exactly who they are, you must provide mechanisms to authorize users to limit what they're allowed to do. The same applies to applications that require access.

Never hardcode credentials into your application code or into configuration files! One of the most common causes for data breaches comes from passwords or API keys that are checked into the source code. Use things such as cross-account roles, EC2 instance profiles, and AWS Secrets Manager to work around use cases where you might be tempted to use hardcoded access keys.

A best practice for securing your cloud system is to adopt a policy of zero trust. Zero trust means that even when data is flowing between servers behind your firewall, on your internal network, you still apply stringent security measures. It helps to be a little paranoid and assume that a bad actor is on your network, watching everything that happens, and looking for a way to infiltrate further. An example of zero trust is encrypting communications between your web servers and your database server, regardless of the fact that they are sitting on your internal network.

One exception to this rule is network traffic that is flowing to and from your EC2 instances. Due to the design of the hypervisor, it is impossible for a third party to sniff that traffic. Unlike a traditional network where a sniffer running in promiscuous mode can see everything, the hypervisor prevents the delivery of packets to anywhere but the target. Regardless, many compliance regimes require all traffic to be encrypted, and it's still good practice.

With Amazon CloudTrail, it's possible to leave an audit trail that details every action taken within your account in all regions. If a security event occurs, auditors must have rapid access to log files that can help them find out who the culprit is, and how they broke in.

Always enable CloudTrail and send the logs to an S3 bucket in a different account, accessible only to security auditors. Placing the audit trails in a different security domain means that an attacker will have a harder time covering their tracks.

Simulate security events frequently so that your operations team can practice incident response. When you identify patterns in those responses, automate them so that a human is not required to deal with the situation. This will improve consistency and time to response. An example of this is automatically responding to an S3 bucket being made public – instead of simply sending an email to an administrator to alert them to the problem, write a Lambda function that flips the bucket back to private immediately.

To learn more about the security pillar, read the official whitepaper: https://d1.awsstatic.com/whitepapers/architecture/AWS-Security-Pillar.pdf.

Table of Contents for Security

Create new playlist

Sign In

Sign Up

Table of Contents for
Security