A Step-by-Step Guide to S3 Security Features & Setup

As the gold standard for reliably storing files of varying types in the cloud, Amazon’s S3 has become synonymous with storage. 

While this widespread adoption is a sign of a good developer experience and reliable storage across the board, it also presents a unique opportunity for attackers looking to exploit multiple targets due to S3’s widespread adoption. 
In 2024, Amazon’s Sonaris denied 27 billion attempts to find unintentionally public S3 buckets, highlighting the scale of these threats. In this post, we’ll provide practical steps that you, as a developer or IT professional, can take to defend your S3 resources and avoid becoming another statistic in the following security report. 

What is Amazon S3?

Amazon Simple Storage Service, or S3, is an object storage service that can store all kinds of objects, from images to large chunks of genome data. 

S3’s 99.999999999% uptime in a month provides security and peace of mind for developers and operations teams. Its ease of use, SDKs in most modern languages, and incredible durability make it a reliable choice for storing all kinds of objects. 

Beyond its uptime and developer experience, S3 offers a generous free tier and reasonable pricing for most use cases. The first 50 TB costs $0.023 per GB.

5 Critical S3 Security Vulnerabilities

Within S3’s simplicity also lies the potential for critical vulnerabilities to arise; here are some of the most critical ones to be aware of:

1. Configuration Mistakes

While you can configure buckets for practically any use case, there are countless ways to misconfigure them. A common mistake is setting overly permissive CORS policies, allowing any origin to make requests to your bucket. Another frequent oversight is failing to enable encryption in transit, leaving your data vulnerable during transfer. These misconfigurations often slip through because they don’t break functionality—everything works fine until it doesn’t. 

Additionally, they can arise from a lack of adherence to zero trust principles, meaning implicit trust is placed in users and systems. The zero trust principle is a security concept that requires strict identity verification for every person and device trying to access resources on a network, regardless of whether they are inside or outside the network’s perimeter. One approach to mitigating these risks is implementing Just-In-Time (JIT) access, ensuring that users only have the necessary permissions for the specific tasks they need to perform and only for the duration of that task.

2. Malicious Uploads 

If your S3 bucket is secure, don’t forget to consider what goes into it. Without proper file validation, attackers can upload malicious files such as viruses, trojans, or ransomware that your application serves to users. If an attacker uploads malware-infected files, they can use your legitimate application as a malware platform. 

3. Lack of Visibility 

While AWS provides a decent console interface, most developers in production environments can’t access it due to security policies, which creates a significant visibility gap. Teams often build their own front-end interfaces to manage and monitor their S3 resources. Without proper visibility, you might not notice unusual access patterns or unauthorized changes until it’s too late, hindering governance and compliance efforts. 

4. Publicly Accessible Buckets 

Publicly accessible buckets containing sensitive data remain the leading cause of S3-related breaches. It’s not just about misconfiguration; sometimes, it’s a legitimate requirement gone wrong, which could expose API keys, database credentials, secrets, and more. You may need to share some files temporarily and make the bucket public, planning to lock it down later. Then, someone uploads sensitive data without realizing it’s public, and suddenly, your company’s internal documents are indexed by search engines. It’s a mistake that’s embarrassingly common yet immensely effective for attackers.

5. Vulnerable Third-Party Integrations 

The quest for better S3 management often leads teams to third-party tools and packages. You could find a great visualization tool for your bucket structure or a convenient package for handling uploads. The catch is these integrations often require your AWS access keys. 

If that third-party service gets compromised, your keys are in the wild. Even worse, using a vulnerable package in your application could give attackers direct access to your S3 resources. Remember the event-stream incident? One compromised package can affect thousands of projects.

A Step-by-Step Guide to S3 Security Features

While the attack surface for S3 varies depending on your use case, Amazon is constantly building features to secure access to your S3 buckets. These features align with the zero trust principle of minimizing the attack surface by restricting public access by default. Below are some of the most useful ones. 

Block Public Access Enhancements 

AWS has significantly enhanced its public access blocks, which operate at both the account and bucket levels. You can enforce these blocks across your entire organization. Even if a developer accidentally opens a bucket to the public during testing, these enhanced blocks act as a fail-safe, preventing public access.

Access Control Lists

While AWS now recommends using bucket policies as the primary access control mechanism, Access Control Lists (ACLs) provide valuable functionality for specific use cases. ACLs can be used to specify which users or groups are authenticated to access particular objects within a bucket, providing granular control over access. These ACLs operate at the bucket and object levels, giving you precise control over who can access particular objects. The recent enhancements to ACLs make them particularly useful when you need to:

• Grant cross-account permissions to particular objects without sharing entire buckets.
• Support legacy applications that rely on the ACL model.

Source

Object Ownership 

S3’s object ownership controls have become a powerful tool for preventing confused deputy scenarios. A confused deputy scenario occurs when a malicious actor tricks an authorized user or application into misusing their privileges to access or modify resources they shouldn’t be able to. By enforcing the bucket owner, you guarantee that all objects uploaded to your bucket belong to the owner, regardless of who uploaded them. This seemingly simple feature prevents access control headaches, especially when dealing with cross-account access or third-party uploads.

Amazon Macie

Macie has transformed from a nice-to-have tool for S3 security to a must-have. Its enhanced sensitive data detection capabilities automatically scan your buckets for information such as credit card numbers, API keys, and personally identifiable information. 

Macie’s integration with EventBridge allows you to automate responses to sensitive data discoveries, such as automatically encrypting or quarantining suspicious objects.

Source

Storage Lens 

Lens provides visibility into S3 usage patterns across your organization. Analyzing access patterns and configuration settings can spot potential security risks before they become problems. For instance, it can identify buckets with unusual access patterns or those missing critical security controls, such as encryption.

Object Versioning

While object versioning has been around for a while, its security features are well worth highlighting. Beyond backup and restore capabilities, versioning is an additional line of defense against malicious actions and accidental deletions. You can recover the previous versions if someone overwrites or deletes your objects. In a world where ransomware attacks increasingly target cloud storage, this feature has become a critical component of any S3 security strategy.

5 S3 Security & Setup Best Practices

Here are five essential S3 security best practices that will dramatically reduce your risk exposure:

Follow the principle of least privilege. Grant only the minimal permissions needed for each user, service, or application. Use IAM roles instead of long-term access keys whenever possible, and implement strict bucket policies that explicitly deny public access. 

1. Restrict Access to Your S3 Resources

Follow the principle of least privilege. Grant only the minimal permissions needed for each user, service, or application. Use IAM roles instead of long-term access keys whenever possible, and implement strict bucket policies that explicitly deny public access. 

Beyond restricting access, consider implementing Just-In-Time (JIT) access. JIT access grants temporary privileges only when needed, minimizing the potential impact of compromised credentials or misconfigurations.

2. Embrace Logging

Enable AWS CloudTrail for all API activity and S3 server access logging for detailed request data. CloudWatch Alerts should also be used to automate the monitoring of these logs.

3. Implement Encryption Everywhere

Enable default encryption for all buckets to protect data at rest. You have three main options for encrypting your S3 objects:

• SSE-S3 is the simplest option. In this option, AWS manages the encryption keys for you. It’s ideal for basic encryption needs where you don’t require granular control over your keys.
• SSE-KMS: This option gives you more control over your encryption keys. You can create and manage your keys using the AWS Key Management Service (KMS), which allows access policies and track key usage.

Client-Side Encryption: With this option, you encrypt your data before uploading it to S3. This gives you complete control over your encryption keys and ensures that only you can decrypt your data. However, it also requires you to manage your encryption infrastructure.

Source

4. Enable Versioning with Lifecycle Policies

Versioning protects against accidental and malicious deletions or modifications. Still, it’s important to note that versioning alone does not prevent unauthorized access—it merely retains a history of your object versions. To control costs while maintaining security, you can pair this with lifecycle policies that automatically move older versions to cheaper storage classes or archive them after a defined period.

5. Use ACLs Strategically for Granular Control

While bucket policies handle broad permissions, leverage ACLs for object-level permission requirements. It provides an additional security layer, especially useful in multi-tenant environments or when granting temporary access to specific objects without exposing entire buckets.

S3 Access Without the Hassle with Apono

You can secure your S3 resources with the best practices we discussed above, including:

• Restricting access to your S3 resources
• Embracing logging
• Implementing encryption everywhere
• Enabling versioning with lifecycle policies
• Using ACLs strategically for granular control

Robust security can sometimes restrict an organization’s engineers, but with tools like Apono, you can implement frictionless cloud access to resources.

While Apono doesn’t directly manage or secure S3 buckets, it helps organizations implement robust access controls for S3 resources. Apono integrates with AWS natively, allowing you to manage access to your S3 buckets, IAM roles and groups, EC2, EKS clusters, RDS instances, and more. With Apono, you can simplify the implementation of JIT access for S3 resources, allowing you to easily manage and control temporary permissions without hindering productivity.
Book a demo today to give Apono a try.