AWS Well-Architected Framework Security Best Practices

The AWS Well-Architected Framework has been a staple for many years for AWS practitioners of all sorts, including cloud architects and platform engineers. It’s a blueprint for architectural and design best practices that will lay the foundation for resilience, operational efficiency, and security on the AWS Cloud. 

On the security side, while not expressly connected to, Well-Architected has many similar guiding principles as those found in CISA Secure by Design and NIST Zero Trust Architecture. In short: if you follow the design principles in Well-Architected, you’ll start out with a stronger secure foundation.

Word of caution, however, humans are humans, and attackers exploit that every second of every day, so it’s imperative to bake security into your cloud architecture. One glimpse into the world of the techniques and tactics used by attackers is found in the MITRE ATT&CK Framework. I even wrote about how you can protect your Kubernetes clusters from attack. Many of those defensive mitigations can be implemented proactively, so you’ll also maintain that strong secure foundation.

Well-Architected Design Principles

There are 7 design principles that Well-Architected enumerates:

1. Implement a strong identity foundation
2. Maintain traceability
3. Apply security at all layers
4. Automate security best practices
5. Protect data in transit and at rest
6. Keep people away from data
7. Prepare for security events

It should be no surprise that the first, and most important, design principle is to Implement a strong identity foundation. Since the early days of AWS Cloud, identity has been the perimeter for access to AWS and customer-managed resources. 

“Implement the principle of least privilege and enforce separation of duties with appropriate authorization for each interaction with your AWS resources. Centralize identity management, and aim to eliminate reliance on long-term static credentials.”

We’ll break down each of the recommendations for identity security, and how StrongDM fits in with AWS Well-Architected.

AWS Well-Architected Framework Security Best Practices

Implement the principle of least privilege

Least privilege is the principle that people and systems should have the minimal access required to do their job. On one hand, this makes complete sense, we’re granting access to the minimal amount of actions a user can perform on a minimal amount of resources, but we leave that access standing, 24x7x365. Instead of having standing access, let’s move to a Zero Standing Access and Zero Standing Privileges model that’s implemented with Just-in-Time and Dynamic Access workflows, where we can dramatically reduce the risk exposure. 

By only granting access to resources when someone needs it, when they need it, and for the duration they need, we can achieve a risk reduction by as much as 98.8%. Bonus points for that access being automatically revoked to ensure that we don’t have all of that standing access left behind.

Enforce separation of duties with appropriate authorization for each interaction with your AWS resources

Separation of duties is the principle no user should be given enough access to negatively impact your environment. For example, a software engineer probably shouldn’t have access to internal financial data. When you have a truly dynamic and  automated access workflow model, separation of duty is a byproduct of the Zero Standing Privileges model. 

Furthermore, the authorization should be continuously checked to ensure that the user’s device being used for access remains relatively risk-free from malware during the session, their IP address hasn’t changed, or they haven’t been instantly teleported to another geolocation during their access window.

Centralized identity management

Managing identities and authenticating through a centralized identity management provider is the way to ensure that provisioning and deprovisioning of people is happening across many systems and services, including your cloud infrastructure. Ideally, if a user is deprovisioned, that should immediately revoke all access grants, and stop any active sessions because they would no longer be unauthorized. Multiple factors of authentication should also be implemented, including more modern methods such as passkeys and biometric tokens.

Aim to eliminate reliance on long-term static credentials

Static credentials have been a problem for cloud admins and architects since the beginning. API access keys and passwords should never be embedded in application configuration files or even worse, checked into code repositories. There have been too many middle-of-the-night security incidents that were ultimately caused by the unintentional storing of API keys in a public S3 bucket or Git repo.

It’s about Maturing your Security Access Strategy

Achieving a truly mature, dynamic access model is a journey. Operationalizing all of the design principles in the AWS Well-Architected framework doesn't happen overnight, neither does maturing your access. Many of the principles in the above maturity model apply directly to the principles within the Well-Architected framework. 

As you progress through the maturity model, your access aperture will narrow. In the widest aperture, you are granting access at the AWS account level, then eventually you’ll be granting access to resources at both the control plane, such as configurations, and inside the data plane, such as databases and data objects.

So how do we get to a place where we truly don’t have standing privileges? How can I dynamically grant access to an EKS cluster or RDS Postgres database in a just-in-time way? Is Zero Standing Privileges achievable?

StrongDM is a Critical to Implementing Well-Architected

Our Solution Guide for AWS Well-Architected prescribes how you can apply StrongDM capabilities to many of the design principles and best practices found in the framework, not just Identity Security. 

We have product features that allow you to implement tag-based, dynamic access workflows that can be kicked off from Slack, for example. We allow you to grant access to RDS databases and EKS clusters, and have full visibility into the actions your users are taking on those resources, and in the case of SSH and RDP, full session recording. Our microsegmentation network architecture ensures the session from client to resource is fully encrypted and secure. 

So yes! You can achieve Zero Standing Access and Zero Standing Privileges not just on your AWS resources and accounts, but across many resource types, including the legacy stuff you’re still trying to figure out how to get over to the cloud.

Looking to implement Zero Standing Privileges? Book a StrongDM demo to see it in action.