Security concerns with our architecture

Access the interactive diagram for this lesson here. (It may ask you to create a free account in order to view. You do not need paid features to view this course’s content so you can ignore that!)

In the prior lesson, we looked at this typical cloud architecture by explaining the purpose of each component.

An architecture like this is often referred to as a multi-tier architecture because the services are separated into multiple different layers, or tiers. For example, when we have a presentation tier, a logic tier, and a data tier, we can call that a three-tier architecture.

When we are dealing with an architecture like this, we need to think about the security implications. We shouldn’t just launch these resources and call it a day as soon as it works. We have to map out potential attack vectors and we have to think like an attacker in order to also implement defenses.

In this lesson, we’re going to walk through this architecture like a security professional who is looking to implement defenses.

For example, with this architecture alone, I can think of at least 5 categories we would need to focus on as an organization to properly secure this deployment:

1. Networking Security
2. Data Protection
3. IAM
4. Logging & Monitoring
5. Business Continuity

Networking Security

One of the primary concerns is that, since this an architecture for a web application, we will be accepting user requests through a website.

Those requests will travel into our VPC, into our subnets, into our web servers and app servers, and those servers will be communicating with our database.

This, alone, creates all sorts of potential attack vectors. We could be dealing with:

• Injection attacks like XSS, SQL injections, OS Command injections, etc…
• Denial of Service attacks
• Access control issues that allow privilege escalation
• Information and data leaks
• and much more…

For those reasons, we need to consider network security by implementing:

• DDoS defenses
• Network segmentation through proper configuration of subnets
• Traffic control with Network Access Control Lists (NACLs) and Security Groups
• And so on…

Once we have all of this in place, we can also add firewalls, such as the AWS Web Application Firewall, or WAF, and a Content Distribution Network, or CDN.

This multi-layered approach will help reduce the amount of malicious traffic reaching our VPC in the first place, but even for those attacks that do make it through, we can make it extremely difficult for them to go beyond and cause any damage.

Data Protection

In addition to network security, we need to be thinking about data protection.

Data protection involves all aspects of securing our data, which includes data stored in Amazon S3, in EC2 instances, and in our databases.

EC2 instances use what’s called Elastic Block Store, or EBS, which can be directly attached to an instance. These can be high-performance SSD-based or even HDD-based, and they can store data that’s directly used by our web servers or application servers.

That means they can be storing sensitive data that should be encrypted at rest.

The same holds true for data stored in Amazon S3 — while Amazon takes care of physical security, which we’ll talk about in the “Shared Responsibility” lesson soon — we may still need to encrypt data stored on S3 for regulatory compliance reasons.

We will also need to encrypt data in transit, which is data moving across networks, and/or data in use.

All of this encryption requires keys, so we also need a proper and secure way of creating and managing private keys.

IAM

Even if we have top-notch network and data security practices in place, if we’re not properly taking care of our AWS accounts and users, a malicious actor can easily hijack our accounts and resources.

For example, if we don’t follow the principle of least privileges and a user account gets compromised, an attacker could do a serious amount of damage even with accounts that are supposed to be low-level accounts.

The same is true for resources launched in AWS. If we don’t give least privileges to our EC2 instances or other resources, and if an attacker gains access to one of our instances, they could easily escalate privileges and laterally move through our VPC and subnets.

To properly secure our AWS users, accounts, and resources, we need to learn about:

• Policies
• Roles
• User account and credentials best practices
• End user management
• and more…

Logging, Monitoring, and Auditing

Once our security controls are in place, we need to have a way of keeping eyes on whether they are being effective or not, and whether anyone is attacking our infrastructure or has successfully breached our defenses.

The way to do that is with logging, monitoring, and auditing.

This requires learning how to properly log from multiple different sources, depending on the services we’re using. It also requires learning how to ingest those logs to turn them into useful and actionable data, how to monitor key metrics, and how to create and set up alerts in order to get notified.

Business Continuity

Finally, we need to consider business continuity.

Business continuity refers to taking proactive steps to ensure that our most important operations can continue functioning during an attack or during some sort of other disruption.

Certain types of attacks, like Distributed Denial of Service, or DDoS attacks, are designed to try and take down operations to cause harm to the business.

Or, it doesn’t even have to be a malicious disruption. AWS, while a very stable cloud platform, does have outages from time to time. How well your environment sustains those outages depends on the type of outage, but also on how you’ve set up your environment.

That’s why business continuity is an important part of your security strategy, and we’ll explore how we can use:

• Load balancers
• Auto Scaling
• Availability Zones
• Backups
• Versioning

…in order to increase our resiliency to potential disruptions.

Useful Benchmarks and Frameworks

By the way, there exist multiple benchmarks or frameworks we can use to help us secure our cloud environments.

One of those benchmarks is from the Center for Internet Security, or CIS. These documents are freely available for download from their website, and here’s just one example of one for AWS Three-Tier Web recommendations.

If we scroll down to the Table of Contents, we can see a section dedicated to Recommendations.

Many of these recommendations align directly with what we just talked about. They have multiple recommendations for:

1. Data protection
2. Identity and Access Management
3. Business continuity
4. Event monitoring and response
5. Audit and logging
6. Networking

If you click on any of those recommendations, you will see a brief description and explanation, as well as how to audit your environment to verify compliance.

Conclusion

In this lesson, we walked through a practical scenario of how we can start to look at cloud architectures from a security perspective.

Now, let’s move on to the next lesson where we’ll take a closer look at how AWS works.