In part 2 in my latest series showcasing the six pillars of the AWS Well-Architected Framework, we take a look at the Security pillar. As security is such a large topic, we will be covering the security stack across a series of posts. The intent of this blog series is to cover security and security practices at a high level. This is not an in-depth or comprehensive security guide. For comprehensive security guidance, Cevo’s Security Practice has your back.
If you’d like to learn more about the other pillars of the Well-Architected Framework, check out the other blogs in this series via the links below.
What we will be covering
- AWS Well-Architected Overview
- AWS Well-Architected: Security Pillar
- The Security Stack
- AWS Shared Responsibility Model
Why we are learning this
- To help others navigate and understand how to design and implement secure architecture that aligns to security requirements
- Using the AWS Well-Architected: Security Pillar for guidance to build secure infrastructure
How this will help me
You will:
- Be able to successfully define security requirements
- Have a better understanding of the components used in securing infrastructure
- Have a better understanding of security terms and the services at a high-level
- Be able to build effective solutions aligned to the AWS Well-Architected: Security Pillar
AWS Well-Architected Overview
AWS Well-Architected is a framework comprising six “pillars” for building infrastructure with good practice in mind.
By aligning architecture and infrastructure to the AWS Well-Architected Framework, customers can ensure their solutions are secure, reliable, efficient, sustainable, cost-effective and operationally supportable.
Aligning to the framework is not mandatory; however doing so creates good architecture and can help in making critical decisions and risk mitigation.
Comprised of six pillars of excellence:
- Security
- Reliability
- Operational excellence
- Performance efficiency
- Cost optimisation
- Sustainability
The AWS Well-Architected Wheel
The following infographic depicts the components and focus areas for each of the six pillars:
Well-Architected: Security
The Security pillar covers:
- Incident response
- Data protection
- Encryption in flight
- Encryption at rest
- Data classification
- Infrastructure protection
- Compute protection
- Network protection
- Detective controls
- Event management
- Security awareness
- Identity Access Management (IAM)
- Who should/can access solution
- How they access solution
Well-Architected: Security
Security is such a broad context, it is difficult to cover off everything. Today we are embarking on a discovery of Security in the context of AWS and the AWS Shared Responsibility Model, along with some of the common security services and ways you can implement a minimal security standard to your AWS infrastructure and accounts.
Security is everyone’s responsibility and shouldn’t be left to security teams to have to implement and operate solutions. Effective security should start with why you are securing your workload – this is your purpose for implementing security and justifies the investment. It is important to recognise that “being secure” is a loosely held term and wildly varies between the depth of security being used or enforced.
How you implement security is equally as important however this is usually rationalised by the following questions:
- Who needs access to the workload (either a user (human or entity) or a principal such as a service or another workload)?
- What do they need to access (specific data, datastore or system)?
- How are they accessing the workload (API, ODBC/JDBC, Web, etc)?
- Is the access to this workload coming from inside my network or is it external to my network (to understand your security boundaries and control points)?
- What is the minimum access required?
- How is this access enforced?
- How do we monitor compliance?
Security should be thought of in binary terms “true” and “false” as something is either secure or it isn’t. Finally, we have two terms that are sometimes loosely used interchangeably – governance and compliance. Governance sets the tone for the entire company’s attitude to risk, ethics and business practices. Compliance embodies that attitude in relation to specific laws and regulations. Governance is the intent and this is enforced through compliance.
The Security Stack
AWS Shared Responsibility Model
The AWS Shared Responsibility Model is established to provide guidance on where responsibilities intersect between you, as a consumer of AWS services, and AWS as a service provider. The key takeaways are:
- AWS is responsible for providing security of the cloud
- Customers are responsible for security in the cloud
What does this mean in practice and does this apply to all services? This is a great question and requires a little bit of unpacking to answer succinctly – as it depends on the service being used. Visually – the responsibility model looks like this as shown here:
A customer must secure things like passwords, logging, monitoring, alerting, Identity Access Management (IAM) – including identities, security keys and roles, any customer managed keys used for encryption, security-groups, ACL’s, routing and also the use of services such as Internet Gateways, NAT Gateways, Transit Gateways, API Gateways and any virtual appliances. When using services such as EC2, AppStream, WorkSpaces, containers running on ECS or EKS, Lightsail and Elastic Beanstalk require the customer to manage the operating system and/or application patching as well.
Wow – that is a lot of customer responsibility! So what exactly does AWS do as part of their responsibility? Well they provide the platform security to AWS including physical security of infrastructure, all infrastructure maintenance and when using managed services – this may extend to operating system and/or application patching such as RDS, DynamoDB, ECS, EKS (when using managed nodes), Lambda, CloudFront, WAF, FSx, EFS and S3.
Wait up – some of those services are “serverless” – what do you mean? Well – the term “serverless” is a little bit of loose terminology – it still runs on compute somewhere, right? What we are saying in the shared responsibility model is that while AWS manages the underlying infrastructure up to and including the operating system – you as a customer are responsible for the code being run on those services. They may be relying on packages for your code to run for example – and those packages might require updating regularly/periodically to patch against vulnerabilities.
The role AWS has in providing their security obligations is also about giving their customers the tools they need to secure their solutions – however it is up to the customer to implement those controls appropriately. In many media reports of data breaches involving AWS customers – in most cases it isn’t AWS that caused the breach as the controls existed for the customer to prevent the breach in the first place – the customer just hadn’t used the tools available to them or made conscious choice to turn off default security mechanisms (like making a public S3 bucket as an example). It’s important to recognise the responsibility boundaries and plan accordingly to ensure you are continuously meeting your responsibilities as a customer.
