Within the traditional datacentre environment, certain security controls are expected to be handled by the hosting provider or datacentre operator, these include, but are not limited to physical security and access controls, whereas you as customer may be required to secure the server operating system (and other public facing applications). Like the traditional datacentre scenario, AWS operates with a Shared Responsibility Model, where certain aspects (security controls) of the environment are managed by them as the Public Cloud Provider, however key parts of the environment are still considered the responsibility of the customer. This the term Shared Responsibility Model is used to refer to this shared security role.
In this post, I focus on the shared responsibly model as it applies to the key AWS service categories and dive into the most common best practice architecture and design principles when designing and building workloads for the cloud.
AWS Shared Responsibility Model – at a Glance
Security and Compliance is a shared responsibility between AWS and the customer. This shared model can help relieve the customer’s operational burden as AWS operates, manages, and controls the components from the host operating system and virtualisation layer down to the physical security of the facilities in which the service operates. The customer assumes responsibility and management of the guest operating system (including updates and security patches), other associated application software as well as the configuration of the AWS provided security group firewall. Customers should carefully consider the services they choose as their responsibilities vary depending on the services used, the integration of those services into their IT environment, and applicable laws and regulations. The nature of this shared responsibility also provides the flexibility and customer control that permits the deployment.
As shown in the diagram below, this differentiation of responsibility is commonly referred to as Security “of” the Cloud versus Security “in” the Cloud.
AWS responsibility “Security of the Cloud”
AWS is responsible for protecting the infrastructure that runs all of the services offered in the AWS Cloud. This infrastructure is composed of the hardware, software, networking, and facilities that run AWS Cloud services.
Customer responsibility “Security in the Cloud”
Customer responsibility will be determined by the AWS Cloud services that a customer selects. This determines the amount of configuration work the customer must perform as part of their security responsibilities. For example, a service such as Amazon Elastic Compute Cloud (Amazon EC2) is categorized as Infrastructure as a Service (IaaS) and, as such, requires the customer to perform all of the necessary security configuration and management tasks. Customers that deploy an Amazon EC2 instance are responsible for management of the guest operating system (including updates and security patches), any application software or utilities installed by the customer on the instances, and the configuration of the AWS-provided firewall (called a security group) on each instance. For abstracted services, such as Amazon S3 and Amazon DynamoDB, AWS operates the infrastructure layer, the operating system, and platforms, and customers access the endpoints to store and retrieve data. Customers are responsible for managing their data (including encryption options), classifying their assets, and using IAM tools to apply the appropriate permissions.
This customer/AWS shared responsibility model also extends to IT controls. Just as the responsibility to operate the IT environment is shared between AWS and its customers, so is the management, operation and verification of IT controls shared. AWS can help relieve customer burden of operating controls by managing those controls associated with the physical infrastructure deployed in the AWS environment that may previously have been managed by the customer. As every customer is deployed differently in AWS, customers can take advantage of shifting management of certain IT controls to AWS which results in a (new) distributed control environment. Customers can then use the AWS control and compliance documentation available to them to perform their control evaluation and verification procedures as required. Below are examples of controls that are managed by AWS, AWS Customers and/or both.
Inherited Controls
Controls which a customer fully inherits from AWS.
- Physical and Environmental controls
Shared Controls – Controls which apply to both the infrastructure layer and customer layers, but in completely separate contexts or perspectives. In a shared control, AWS provides the requirements for the infrastructure and the customer must provide their own control implementation within their use of AWS services. Examples include:
- Patch Management – AWS is responsible for patching and fixing flaws within the infrastructure, but customers are responsible for patching their guest OS and applications.
- Configuration Management – AWS maintains the configuration of its infrastructure devices, but a customer is responsible for configuring their own guest operating systems, databases, and applications.
- Awareness & Training – AWS trains AWS employees, but a customer must train their own employees.
Customer Specific – Controls which are solely the responsibility of the customer based on the application they are deploying within AWS services. Examples include:
- Service and Communications Protection or Zone Security which may require a customer to route or zone data within specific security environments.
Shared Responsibility - Practical Example
The shared responsibility model for infrastructure services, such as Amazon Elastic Compute Cloud (Amazon EC2) for example, specifies that AWS manages the security of the following assets:
- Facilities
- Physical security of hardware
- Network infrastructure
- Virtualisation infrastructure
In this Amazon EC2 example, you as the customer are responsible for the security of the following assets:
- Amazon Machine Images (AMIs)
- Operating systems
- Applications
- Data in transit
- Data at rest
- Data stores
- Credentials
- Policies and configuration
It should be noted that the general shared responsibility model depicted above offers a generalised responsibility view. Specific responsibility models that focus on the consumption types of AWS services exist and are grouped as follows:
- Infrastructure services
- Container services
- Abstracted services
Refer to the Best Practices for Security, Identity, & Compliance site or the AWS Security Documentation for detailed information on the responsibilities as it pertains to various services or service categories.
Infrastructure services
An infrastructure service is a type of computing service where common virtualisation infrastructure is managed by AWS. Amazon Elastic Cloud Compute (EC2) is the most common example, however Amazon Connect is another example of an AWS infrastructure service.
For infrastructure services, AWS is responsible for:
- Foundation services (networking, storage, compute)
- AWS global infrastructure
- AWS Identity and Access Management
- AWS API endpoints
For infrastructure services, the customer is responsible for:
- Customer data
- Customer applications
- Operating system
- Network and firewall
- Customer Identity and Access Management
- High availability
- Scaling
- Instance management
- Data protection (in transit, at rest, and backup)
Container services
A container service allows multiple applications to share resources while running on the same operating system. Commonly these services are managed by AWS, and commonly runs on underlying EC2 infrastructure. Amazon Relational Database Service (RDS) is an example of an AWS container service. The “container services” categorisation should not be confused with Docker containers.
For container services, AWS is responsible for:
- Foundational services (networking, storage, compute)
- AWS global infrastructure
- AWS Identity and Access Management
- AWS API endpoints
- Operating system
- Platform/application
For container services, the customer is responsible for:
- Customer data
- Firewall (virtual private cloud)
- Customer Identity and Access Management (database users, table permissions)
- High availability/scaling
- Data protection (in transit, at rest, and backup)
Abstracted services
An abstract service is a storage, database, or messaging service that is fully managed by AWS, with the customer mostly owning some aspects of configuration and the data that sent to or hosted on the service.
Amazon Simple Storage Service (S3) and Amazon DynamoDB are examples of AWS abstract services.
An abstract service is a storage, database, or messaging service. Amazon Simple Storage Service (S3) and Amazon DynamoDB are examples of AWS abstract services.
For abstract services, AWS is responsible for:
- Foundational services (networking, storage, compute)
- AWS global infrastructure
- AWS Identity and Access Management
- AWS API endpoints
- Operating system
- Platform/application
- Data protection (at rest – Server Side Encryption, in transit)
- High availability/scaling
For abstract services, the customer is responsible for:
- Customer data
- Data protection (at rest – Customer Side Encryption)
Design Principles and Best Practice
When migrating workloads to Amazon Web Services, starting a greenfield project, or assessing existing workloads for security governance alignment, there are several best practices to consider as part of the overall architecture and workload solution designs. Each of these areas are briefly defined below.
- Implement a strong identity foundation: Implement the principle of least privilege and enforce separation of duties with appropriate authorisation for each interaction with your AWS resources. Centralise identity management, and aim to eliminate reliance on long-term static credentials.
- Enable traceability: Monitor, alert, and audit actions and changes to your environment in real time. Integrate log and metric collection with systems to automatically investigate and take action.
- Apply security at all layers: Apply a defence in depth approach with multiple security controls. Apply to all layers (for example, edge of network, VPC, load balancing, every instance and compute service, operating system, application, and code).
- Automate security best practices: Automated software-based security mechanisms improve your ability to securely scale more rapidly and cost-effectively. Create secure architectures, including the implementation of controls that are defined and managed as code in version-controlled templates.
- Protect data in transit and at rest: Classify your data into sensitivity levels and use mechanisms, such as encryption, tokenisation, and access control where appropriate.
- Keep people away from data: Use mechanisms and tools to reduce or eliminate the need for direct access or manual processing of data. This reduces the risk of mishandling or modification and human error when handling sensitive data.
- Prepare for security events: Prepare for an incident by having incident management and investigation policy and processes that align to your organisational requirements. Run incident response simulations and use tools with automation to increase your speed for detection, investigation, and recovery.
The figure below offers a quick reference of the key design principles that should form part of your Public Cloud design.
AWS Well-Architected Framework
The AWS Well-Architected Framework helps you understand the pros and cons of decisions you make while designing and building systems on AWS. Using the framework helps you learn architectural best practices for designing and operating secure, reliable, efficient, cost-effective, and sustainable workloads in the AWS Cloud. It provides a way for you to consistently measure your architectures against best practices and identify areas for improvement.
The framework provides a consistent approach to evaluating systems against the qualities you expect from modern cloud-based systems, and the remediation that would be required to achieve those qualities.
The AWS Well-Architected Framework is based on six pillars — operational excellence, security, reliability, performance efficiency, cost optimisation, and sustainability. Each of the pillars are briefly defined in the table below.
Overlaying the previously highlighted design principles and AWS Well-Architected Framework onto an Amazon Web Services ecosystem (AWS account, infrastructure, container, and abstract services) the most common best practices are graphically depicted in the sections that follow.
For security specific facets, refer to the Best Practices for Security, Identity, & Compliance site or the AWS Security Documentation for detailed information. A complete list of AWS Security, Identity, & Compliance services are defined here.
Identity and Access Management
Logging and Monitoring
Infrastructure Security
Data Protection
Defence in Depth
Defence in-depth is an approach to cloud security in which a series of defensive mechanisms are layered in order to protect entire physical and virtual data centre network. However, it needs continuous awareness, assessments, and audits. Defence in-depth design of your workloads start at the physical layer (an AWS responsibility); however several layers of customer focus and continuous assessment remains to ensure your organisations data remains secure.
Workload Isolation and Data Residency
Organisations with specific regulatory or data sovereignty requirements are in full control over where business and operational (log, telemetry) data resides, by making use of the AWS regions aligned to their operational requirements.
Each AWS region is designed to be isolated from the other regions. This achieves the greatest possible fault tolerance and stability; however AWS do not automatically replicate resources across regions to ensure you as the customer have full control over where data resides.
AWS Compliance and 3rd Party Attestations
AWS Artifact is your go-to, central resource for compliance-related information that matters to you. It provides on-demand access to AWS’ security and compliance reports and select online agreements. Reports available in AWS Artifact include our Service Organization Control (SOC) reports, Payment Card Industry (PCI) reports, and certifications from accreditation bodies across geographies and compliance verticals that validate the implementation and operating effectiveness of AWS security controls. Agreements available in AWS Artifact include the Business Associate Addendum (BAA) and the Nondisclosure Agreement (NDA).
Australian customers can rest assured knowing that most AWS services available within the Asia Pacific (Sydney) Region, including some global services meet the Australian Cyber Security Centre (ACSC) Information Security Manual (ISM) requirements to operate PROTECTED workloads.
Reference the IRAP PROTECTED on AWS solution and AWS Artifact for guidance on designing and deploying workloads with sensitive data requirements.
The Australian Cyber Security Centre (ACSC) produces the Information Security Manual (ISM). The purpose of the ISM is to outline a cyber security framework that organisations can apply, using their risk management framework, to protect their information and systems from cyber threats.
Security Best Practice
Security best practices for three of the most common used AWS services are highlighted below. For more information refer to the Best Practices for Security, Identity, & Compliance site or the AWS Security Documentation for detailed information.
Amazon S3
- Ensure that your Amazon S3 buckets use the correct policies and are not publicly accessible.
- Unless you explicitly require anyone on the internet to be able to read or write to your S3 bucket, you should ensure that your S3 bucket is not public.
- Implement least privilege access and use IAM roles for applications and AWS services that require Amazon S3 access. For applications on Amazon EC2 or other AWS services to access Amazon S3 resources, they must include valid AWS credentials in their AWS API requests. You should not store AWS credentials directly in the application or Amazon EC2 instance. These are long-term credentials that are not automatically rotated and could have a significant business impact if they are compromised.
- Consider encryption of data at rest using Server-Side Encryption (SSE) as a default security practice, unless the data within the bucket can truly be classified as public.
- Enforce encryption of data in transit.
- Consider S3 Object Lock.
- Enable versioning.
- Consider Amazon S3 cross-region replication (for backup and cross region redundancy)
- Consider VPC endpoints for Amazon S3 access.
Refer to Security Best Practices for Amazon S3 for detailed guidance.
Amazon RDS
Amazon RDS leverages the same secure infrastructure as Amazon EC2, however direct visibility or control over the virtual instance is abstracted. You can use the Amazon RDS service without additional protection, however if you require encryption of data at rest for compliance or other regulatory requirements, you can add protection at the application layer, or at the platform layer using SQL cryptographic functions.
Best practices differ between the various RDS supported database engines; thus the scenario’s will depend on your unique deployment. In this guide, we focus on several generic best practices. For any specific database engine on RDS, refer to the Security in Amazon RDS guide.
- Enable automatic backups and set the backup window to occur during the daily low in write IOPS.
- To remediate the risk of bad actors deleting backups or holding data for ransom, consider using AWS Backup (cross-account backup) to securely copy backups to one or more AWS accounts in your AWS Organization.
- Use AWS Identity and Access Management (IAM) policies to assign permissions that determine who is allowed to manage Amazon RDS resources. For example, you can use IAM to determine who is allowed to create, describe, modify, and delete DB instances, tag resources, or modify security groups.
- Deploy your DB instance in a virtual private cloud (VPC) based on the Amazon VPC service for the greatest possible network access control.
- Use security groups to control what IP addresses or Amazon EC2 instances can connect to your databases on a DB instance. When you first create a DB instance, its firewall prevents any database access except through rules specified by an associated security group.
- Use Secure Socket Layer (SSL) or Transport Layer Security (TLS) connections with DB instances running the MySQL, MariaDB, PostgreSQL, Oracle, or Microsoft SQL Server database engines.
- Use Amazon RDS encryption to secure your DB instances and snapshots at rest. Amazon RDS encryption uses the industry standard AES-256 encryption algorithm to encrypt your data on the server that hosts your DB instance.
- Use the security features of your DB engine to control who can log in to the databases on a DB instance. These features work just as if the database was on your local network.
Refer to Security in Amazon RDS for detailed guidance.
Amazon EC2
- Restrict access to your instances using security groups. For example, you can allow traffic only from the address ranges for your corporate network.
- Use private subnets for your instances if they should not be accessed directly from the internet. Use a bastion host or NAT gateway for internet access from an instance in a private subnet.
- Use AWS Virtual Private Network or AWS Direct Connect to establish private connections from your remote networks to your VPCs.
- Use VPC Flow Logs to monitor the traffic that reaches your instances.
- Use AWS Security Hub to check for unintended network accessibility from your instances.
- Use EC2 Instance Connect to connect to your instances using Secure Shell (SSH) without the need to share and manage SSH keys.
- Use AWS Systems Manager Session Manager to access your instances remotely instead of opening inbound SSH ports and managing SSH keys.
- Use AWS Systems Manager Run Command to automate common administrative tasks instead of opening inbound SSH ports and managing SSH keys.
Refer to Infrastructure security in Amazon EC2 for detailed guidance.
Important Resources
Security and Compliance Quick Reference Guide
An executive and senior management reference guide focused on AWS security and compliance.
AWS Startup Security Baseline (AWS SSB)
A set of controls that create a minimum foundation for businesses to build securely on AWS without decreasing agility. The controls in this guide are designed with early startups in mind, mitigating the most common security risks without requiring significant effort.
AWS Security Reference Architecture (AWS SRA)
A holistic set of guidelines for deploying the full complement of AWS security services in a multi-account environment. It can be used to help design, implement, and manage AWS security services so that they align with AWS best practices.
AWS Security Incident Response Guide
A guide that presents an overview of the fundamentals of responding to security incidents within an AWS Cloud environment. It focuses on an overview of cloud security and incident response concepts, and identifies cloud capabilities, services, and mechanisms that are available to customers who are responding to security issues.