Under the shared responsibility model, both AWS and the cloud customer have security-related responsibilities. AWS is responsible for the security “of” the cloud, which includes all the hardware, software, networking, and facilities that power AWS services. The customer is responsible for security “in” the cloud, which relates to how they configure and use AWS resources, and the data and workloads they run in the cloud.
Source: AWS
- What Is the AWS Shared Responsibility Model?
- Examples of AWS Shared Responsibility Model
- AWS Shared Responsibility Model Challenges
- Applying the AWS Shared Responsibility Model in Practice
What Are the Security Responsibility of AWS vs. Cloud Customers?
AWS Responsibility: “Security of the Cloud”
AWS is responsible for the security “of” the cloud. This means that AWS manages and controls the components from the host operating system and virtualization layer down to the physical security of the facilities in which the services operate.
This responsibility includes managing the infrastructure that runs all of the services provided by AWS. This infrastructure is composed of the hardware, software, networking, and facilities that run AWS Cloud services. AWS also manages the physical security of its data centers and the underlying infrastructure’s integrity and resilience. AWS uses automated monitoring systems and advanced operational techniques to ensure high service performance and availability.
Customer Responsibility: “Security in the Cloud”
While AWS ensures the security “of” the cloud, customers are responsible for the security “in” the cloud. This means that customers control and manage the security measures they choose to implement in relation to their content, platform, applications, systems, and networks, just like they would do when running these assets outside AWS.
This responsibility includes managing user access controls, encryption, firewall settings, operating system configurations, data and application-level protection, and the secure handling of AWS service outputs. Essentially, the customer is responsible for everything they run in the cloud, store in the cloud, or connect to the cloud.
Inherited Controls
In the AWS shared responsibility model, inherited controls are those that AWS operates fully and provides to customers. Because of AWS’s scale and experience managing a secure cloud infrastructure, customers can benefit from AWS’s operational best practices. These inherited controls can help customers reduce the cost and complexity of managing their own infrastructure.
Inherited controls include physical and environmental controls such as data center security and environmental protection, as well as certain aspects of patch management and system hardening. For example, AWS is responsible for patching and fixing flaws within the infrastructure, but customers are responsible for patching their guest OS and applications. AWS Systems Manager Patch Manager is an Amazon tool that can help customers automate patch management for their workloads.
Shared Controls
Shared controls in the AWS shared responsibility model are specific controls that both AWS and the customer must implement in some way for a complete and effective control implementation. They represent a subset of security controls that both AWS and the customer have responsibility for.
Shared controls may include incident response, awareness and training, contingency planning, and configuration management.
The shared nature of these controls can provide customers with a high degree of flexibility and control, allowing them to implement the specific controls they require for their unique needs. However, it also places an important responsibility on the customer to ensure these controls are properly implemented.
Customer Specific Controls
Customer specific controls are controls that are entirely the responsibility of the customer based on the nature of their business, the data they are handling, and the specific requirements they have. These controls are derived from the customer’s own internal policies and regulatory requirements.
Typically, customer specific controls include data classification and accountability, securing customer data, and ensuring the integrity of business processes. It is the customer’s responsibility to implement these controls in a way that meets their security, compliance, and governance requirements.
Examples of the AWS Shared Responsibility Model
AWS Shared Responsibility Model for EC2
Amazon Elastic Compute Cloud (EC2) is a web service that provides resizable compute capacity in the cloud. It is designed to make web-scale computing easier for developers. As with all AWS services, there are shared responsibilities when it comes to security.
AWS is responsible for the infrastructure that runs all of the services offered in the AWS Cloud, including the infrastructure that supports EC2. This includes the physical hardware, data centers, network infrastructure, and the hypervisor managing the servers.
On the customer side, you are responsible for the 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. Essentially, you must ensure that your EC2 instances are securely configured and any data stored on them is protected.
AWS Shared Responsibility for Containers
When using container services like Amazon Elastic Container Service (ECS) or Amazon Elastic Kubernetes Service (EKS), the shared responsibility model extends to these services. AWS is responsible for the security of the underlying infrastructure, including the compute, storage, and networking resources.
On the other hand, customers are responsible for the security of applications and data within containers, container images, container networking options, and container orchestrator configuration.
AWS Shared Responsibility of IT Controls
When it comes to IT controls, AWS is responsible for the physical and environmental controls, while customers are responsible for the system-level controls. AWS provides a secure foundation, upon which customers can build secure workloads and applications.
Customers are responsible for implementing and managing the IT controls that apply to their applications and data. This includes ensuring the encryption of sensitive data, defining IAM roles and policies, managing operating system patches and updates, and ensuring network and firewall configurations are secure.
Challenges Raised By the AWS Shared Responsibility Model
Here are a few challenges organizations commonly face when attempting to implement their part of the shared responsibility model.
Lack of Cloud Expertise
Many organizations, especially small and medium-sized businesses, do not have in-house cloud experts. This means they often lack the knowledge and skills necessary to manage and secure their AWS environments.
This lack of expertise can lead to mistakes, such as misconfigured security controls, which can expose the organization to security vulnerabilities. Additionally, without the necessary expertise, organizations may also fail to take full advantage of AWS’s robust security features and capabilities.
Native Tools Challenges
AWS provides a set of native tools to help organizations manage their security and compliance. However, these tools can sometimes be a challenge to use effectively.
For instance, some organizations find AWS’s native tools complex and hard to navigate, particularly if they lack cloud expertise. Moreover, these tools often require a lot of manual effort to set up and configure. This can be especially challenging for organizations with limited IT resources.
Multi-Cloud Security
As more and more organizations adopt a multi-cloud strategy, securing these environments becomes a significant challenge. Each cloud provider, including AWS, has its own set of security controls and configurations, making it difficult for organizations to maintain a consistent security posture across their various cloud environments.
In addition, the AWS shared responsibility model applies only to AWS environments. If an organization uses other cloud providers, they will need to understand and manage the shared responsibility models for those providers as well. This can be complex and time-consuming.
In addition, managing security in a multi-cloud environment requires visibility into all your cloud environments. Without this visibility, it’s difficult to identify and respond to security threats quickly and effectively.
Applying the AWS Shared Responsibility Model in Practice
Determine External and Internal Requirements
The first step in applying the AWS shared responsibility model is understanding your organization’s external and internal security and compliance requirements. This involves assessing various external regulations, standards, and best practices that your organization must adhere to, as well as internal policies and procedures that govern how you manage and protect data.
It’s crucial to identify these requirements early on, as they will influence the security controls and measures you implement. For example, if your organization must comply with the General Data Protection Regulation (GDPR), you’ll need to ensure that you have appropriate data protection measures in place. Similarly, if you have internal policies around data encryption, you’ll need to ensure that these are enforced within your AWS environment.
Consider Using Established Security Frameworks
When applying the AWS shared responsibility model, it’s beneficial to consider established industry frameworks such as the National Institute of Standards and Technology Cybersecurity Framework (NIST CSF) and the International Organization for Standardization (ISO) 27017. These frameworks provide detailed guidelines on how to manage and mitigate cybersecurity risks in the cloud.
The NIST CSF, for example, offers a risk-based approach to managing cybersecurity risk, and is designed to complement existing cybersecurity and risk management practices. Meanwhile, standards such as ISO 27017 provide a best practice framework for information security in cloud computing environments.
By aligning your AWS practices with these industry frameworks, you can ensure that you are adhering to recognized best practices and effectively managing cybersecurity risks within your AWS environment.
Consider Using AWS Cloud Adoption Framework (CAF) and Well-Architected Framework
The AWS Cloud Adoption Framework (CAF) and Well-Architected Framework are valuable resources when applying the AWS shared responsibility model. The CAF provides a structured approach for migrating to the cloud, while the Well-Architected Framework provides a set of architectural best practices for designing and operating reliable, secure, efficient, and cost-effective systems in the cloud.
By leveraging these frameworks, you can ensure that you are following best practices in your digital transformation journey. This includes ensuring that your architecture is designed with security in mind, that you are effectively managing your cloud resources, and that you are continuously optimizing your cloud operations.
Evaluate AWS Security, Identity, and Compliance Services
AWS provides a range of security, identity, and compliance services that can help you meet your security and compliance objectives. These include services like AWS Identity and Access Management (IAM), which enables you to manage access to AWS services and resources securely, and AWS Security Hub, which gives you a comprehensive view of your security posture across your AWS environment.
It’s important to understand how these services can help you meet your security and compliance objectives. This might involve, for example, using AWS IAM to enforce least privilege access, or using AWS Security Hub to monitor for security incidents and vulnerabilities. In some cases, if you see AWS tools do not meet your requirements, you might complement or replace them with third-party security solutions.
Review Third-Party Audit Attestation Documents
Third-party audit attestation documents can provide valuable insight into the security controls that AWS has in place, and which of these controls you inherit as part of the AWS shared responsibility model. These documents, such as the AWS System and Organization Controls (SOC) reports, provide detailed information on how AWS meets key security and compliance requirements.
By reviewing these documents, you can gain a better understanding of the security controls that AWS provides, and identify any additional controls that you may need to implement within your environment. This might include, for example, additional access controls or logging and monitoring systems.
Perform a Well-Architected Review of Your AWS Workloads
A Well-Architected Review is a systematic approach to evaluating your AWS workloads against the five pillars of the Well-Architected Framework: Operational Excellence, Security, Reliability, Performance Efficiency, and Cost Optimization.
This review can be a valuable tool in applying the AWS shared responsibility model, as it allows you to identify areas where you may need to implement additional security controls or measures. For example, you might discover that you need to improve your incident response procedures, or that you need to implement more robust data encryption methods.
Explore AWS Security Competency Partners
AWS Security Competency Partners are AWS partners that have demonstrated expertise and proven customer success in securing every stage of cloud adoption, from initial workload migrations to ongoing security management.
Working with these partners can provide you with valuable insights and guidance in applying the AWS shared responsibility model. Whether you’re just starting your cloud journey or looking to enhance your existing security posture, these partners can provide the expertise and support you need to ensure a secure and compliant AWS environment.
AWS Cloud Security with Aqua Security
Aqua provides the most complete security solutions to protect workloads running on Amazon ECS, EKS, AWS Fargate, and AWS Lambda. As an Advanced APN member and Container Competency technology partner, Aqua provides highly-integrated security controls for cloud native applications on AWS.
Aqua supports managed container services, such as Amazon ECS for container orchestration, Amazon EKS for Kubernetes-based deployments, AWS Fargate for on-demand container scaling, AWS Lambda for serverless functions, and Amazon ECR for storing and managing container images.
Protect workloads running on Amazon EKS – Prevent unauthorized images from running in your EKS cluster, enforce container immutability, network segmentation, and segregation of duties.
Secure Applications running on AWS Fargate containers – Embed Aqua MicroEnforcer into your containers to ensure that workloads running on AWS Fargate are only performing their intended function, detect vulnerable or compromised containers.
Extend security from Amazon ECR to Amazon ECS – Manage image vulnerabilities, ensure only trusted images can be deployed, automatically whitelist legitimate container behavior, and detect and block suspicious activities.
Protect AWS Lambda Functions – Control the risk of AWS Lambda functions by discovering over-provisioned permissions and roles, embedded credentials and keys, and vulnerabilities. Monitor functions at runtime, preventing code injection and malicious activity.
Cloud Security Posture Management (CSPM) – Ensure that your AWS accounts and services are configured according to best practices, including the CIS Foundation Benchmarks for AWS. Continuously scan hundreds of settings for risks and monitor CloudTrail events for anomalies. Automatically create and retain compliance reports for PCI, HIPAA, and more.
Cloud VM Security and Compliance – Protect workloads running on Amazon EC2 instances and ensure they are properly hardened. Scan for vulnerabilities and malware, apply File Integrity Monitoring (FIM), check configuration against the CIS Benchmark for Linux, and monitor user access and activity. Create command-level audit trail for compliance and forensics.
Image Vulnerability Scanning & Assurance – Prevent unauthorized images from running in your AWS environment. Continuously scan images stored in Amazon ECR to ensure that DevOps teams do not introduce vulnerabilities, bad configurations, or secrets into container images. Get actionable recommendations for remediation of security issues.
Serverless Function Risk assessment and Mitigation – Continuously scan Lambda functions in AWS accounts to ensure that developers don’t introduce vulnerabilities into function code, leave access keys in environment variables, or create overly permissive roles. Define security policies for AWS Lambda functions and alert or prevent the execution of functions that violate the policies.
Protect Applications in Runtime – Prevent unvetted containers from running in your Amazon ECS, EKS, and Fargate environments. Automatically create security policies based on container behavior and ensure that containers only do what they are supposed to do in the application context. Detect and prevent activities that violate policy, and defend against container-specific attack vectors.
Container-Level RBAC – Apply highly granular access control policies into containers at runtime via integration with AWS IAM roles. Define user access privileges according to role, allowing or preventing specific Docker actions, such as view, run, stop, view logs, and more.
Secrets Management – Leverage AWS KMS (key management store) to securely deploy secrets – such as passwords, keys, and tokens – into containers at runtime. Aqua makes it easy to manage, rotate, and revoke secrets in containers with no downtime, running only in memory without persistence on disk.
