Advertorial AWS customers might assume that security is taken care of for them – however, this is a dangerous misconception.
While AWS secures its infrastructure, security within an organization’s cloud environment is the customer’s responsibility. Think of AWS security like a secure building: AWS provides the sturdy walls and roof, but the organization is in charge of the locks, the alarm system, and ensuring that no valuable data is left exposed.
In this blog, we highlight what AWS doesn’t secure with real-world examples, and share key actions organizations can take to protect their AWS environments.
AWS operates on a Shared Responsibility Model, where both AWS and its customers have distinct security responsibilities.
AWS secures the underlying infrastructure that powers its cloud services – including hardware, software, networking, and data centers – essentially providing the “walls and roof.” On the other hand, customers are responsible for securing their data, applications, and configurations within the AWS environment – the “locks on the doors” and the “alarm system.”
In short, AWS handles security of the cloud, while its customers are responsible for security in the cloud. Understanding this distinction is crucial to maintaining a secure environment.
Customer responsibilities and actions
Let’s look at some real-world vulnerabilities that fall under the customer’s responsibility and what actions can be taken to mitigate them. The following examples focus on two key areas of the AWS Shared Responsibility Model:
– Platform, Applications, and Identity and Access Management.
– Operating System, Network, and Firewall Configuration.
– Platform, Applications, Identity and Access Management.
– SSRF and the AWS Metadata Service.
Organizations using AWS are responsible for securing vulnerabilities in their applications deployed in the cloud, including application-layer issues like Server-Side Request Forgery (SSRF).
SSRF vulnerabilities allow attackers to manipulate a server into making unintended requests, which can lead to unauthorized data access or further exploitation.
This can be particularly dangerous in cloud environments because the metadata service assumes that any request it receives is legitimate. If an attacker exploits an SSRF vulnerability, they could trick the server into exposing sensitive data, such as IAM credentials, which could provide an initial foothold into the cloud environment.
To defend against this, organizations should take a twofold approach:
– Secure applications by identifying and fixing SSRF vulnerabilities using a web application vulnerability scanner.
– Enable AWS IMDSv2, the improved metadata service that mitigates SSRF attacks, adding a defense-in-depth layer, even if an application is vulnerable.
Access control weaknesses, misconfigurations and data exposures
Identity and Access Management (IAM) in AWS allows organizations to control who can access specific resources. While access can be restricted to authorized users within the organization, AWS also allows access to external accounts or even the public.
Managing access is the organization’s responsibility – only the customer knows which data should be public (e.g., website media files) and which should remain private (e.g., server backups with customer data).
S3 buckets have historically been a target for misconfiguration, as it’s easy to accidentally make them public. While AWS has made it more difficult to do so – providing warnings throughout the interface – it’s still possible to expose bucket-stored data with a simple misstep. Ensuring proper configuration is key to preventing data exposure.
Organizations are responsible for the data stored in AWS and securing the applications that access it. For example, if an application connects to an AWS Relational Database Service (RDS), the organization is responsible for ensuring that the application does not expose sensitive data to attackers.
While AWS does help secure RDS data stores, such as providing automatic patch updates, it can’t control how the data is used. For example, in a multi-tenant SaaS application using RDS, the organization is responsible for securing the application and ensuring attackers cannot access data belonging to other users. Authentication and authorization fall under the customer’s responsibility, and a simple Insecure Direct Object Reference (IDOR) vulnerability can allow an attacker to access sensitive data from all users.
OS, network, and firewall configuration and patch management
It almost goes without saying that AWS does not patch servers for organizations. When teams deploy EC2 instances, the operating system (OS) and software running on the server will develop vulnerabilities over time. While AWS handles patching the firmware and updating the hardware on which the EC2 instances run, the OS and software layers are the organization’s responsibility.
For example, if an organization deploys an Ubuntu 24.04 LTS EC2 instance running Redis, it is responsible for patching vulnerabilities in both the OS (Ubuntu) and the software (Redis). AWS, on the other hand, is only responsible for issues affecting the underlying hardware, such as Spectre.
AWS provides services like Lambda, which reduce the need for some patch management, but even these services require occasional attention to ensure they use a supported runtime with the latest patches.
AWS gives organizations control over their attack surface, but it is their responsibility to manage what they choose to expose. Teams can make services publicly accessible or protect them within private cloud networks – though the decision, and associated risks, lie with them.
For instance, if an organization deploys a GitLab server inside their AWS account, they are responsible for securing it. This means using a VPN, placing it behind a firewall, or placing it inside a VPC while ensuring secure access for their team. If a zero-day vulnerability is discovered in GitLab tomorrow and the server is publicly exposed, the customer would quickly regret leaving it on the internet – and AWS wouldn’t be to blame.
AWS Security: The key takeaway
These examples cover just a small fraction of potential security risks in AWS but demonstrate an important point: cloud security isn’t “done for you.” While AWS provides a solid foundation, the responsibility of securing an organization’s environment is significant.
From cloud misconfigurations to access control weaknesses and exposed services, failing to address these gaps can leave organizations vulnerable.
Intruder offers agentless cloud security scanning, performing daily checks on AWS environments to ensure they align with best practices. Combined with vulnerability scanning and attack surface management, Intruder gives teams full visibility into their AWS security – detecting misconfigurations, critical vulnerabilities, and exposed services, all from a single, powerful platform. With clear severity ratings and actionable remediation advice, organizations can prioritize and address their most critical issues fast.
Learn more about Intruder’s cloud security scanning and start your 14 day free trial.
Contributed by Intruder.