Data stored in Amazon S3 will now be encrypted by default, a change that brings AWS in line with competitor policies.
As of January 5, 2023, S3 automatically applies server-side encryption (SSE-S3) for each new object, unless you specify a different encryption option. This change puts another security best practice into effect automatically—with no impact on performance and no action required on your side.
SSE-S3 has actually been supported for a long time, as Amazon says in its blog, but it was previously left up to the user to enable it. “S3 buckets that do not use default encryption will now automatically apply SSE-S3 as the default setting. Existing buckets currently using S3 default encryption will not change.”
But is that enough to protect your sensitive data? The simple answer is No. When it comes to AWS security, S3 buckets are by far the most vulnerable aspect of it all. Misconfigured S3 buckets have resulted in large-scale data breaches involving major organizations.
When it comes to security in AWS services, AWS follows a shared responsibility model which involves both AWS and the customer. While AWS takes the responsibility of “Security of the Cloud” the client will be responsible for “Security in the cloud”
Security of the cloud
AWS is taking the responsibility of ensuring the security of all the infrastructure running underneath the AWS cloud which consists of all the hardware, software, networking and security of the facilities which run the cloud services.
Security in the cloud
Customers will be responsible for security in the cloud-based on the services which they select to use. In some service, customers will have more responsibility and control when setting up and securing the service such as S3 where clients have the responsibility of defining all of the access controls and many other configurations to ensure the security data.
Make sure your S3 Buckets are secured
Most of the S3 bucket breaches we have seen in the past, involved companies configuring data to be accessed publicly. The chances of inexperienced users misconfiguring S3 buckets and changing access control are fairly easy. Such a change can open up your S3 buckets for public access, resulting in unauthorised access and data breach. S3 buckets are vulnerable to being misconfigured easily, which is why they are a big security concern.
Steps to Secure your S3 Buckets
1. Ensure that your Amazon S3 buckets 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. The following are some of the steps you can take:
With a few clicks in the S3 management console, you can apply S3 Block Public Access to every bucket in your account—both existing and any new buckets created in the future—and make sure that there is no public access to any object. S3 Block Public Access settings override S3 permissions that allow public access, making it easy for the account administrator to set up a centralized control to prevent variation in security configuration regardless of how an object is added or a bucket is created.
2. Implement least privilege access
When granting permissions, you decide who is getting what permissions to which Amazon S3 resources. You enable specific actions that you want to allow on those resources. Therefore you should grant only the permissions that are required to perform a task. Implementing least privilege access is fundamental in reducing security risk and the impact that could result from errors or malicious intent.
The following tools are available to implement least privilege access:
- IAM user policies and Permissions Boundaries for IAM Entities
- Amazon S3 bucket policies
- Amazon S3 access control lists (ACLs)
- Service Control Policies
3. 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.
Instead, you should use an IAM role to manage temporary credentials for applications or services that need to access Amazon S3. When you use a role, you don’t have to distribute long-term credentials (such as a user name and password or access keys) to an Amazon EC2 instance or AWS service such as AWS Lambda. The role supplies temporary permissions that applications can use when they make calls to other AWS resources.
4. Enable multi-factor authentication (MFA) Delete
MFA Delete can help prevent accidental bucket deletions. If MFA Delete is not enabled, any user with the password of a sufficiently privileged root or IAM user could permanently delete an Amazon S3 object.
MFA Delete requires additional authentication for either of the following operations:
ü Changing the versioning state of your bucket
ü Permanently deleting an object version
5. Encryption of data at rest
This is now enabled by default
6. Enforce encryption of data in transit
You can use HTTPS (TLS) to help prevent potential attackers from eavesdropping on or manipulating network traffic using person-in-the-middle or similar attacks. You should allow only encrypted connections over HTTPS (TLS) using the aws:SecureTransport condition on Amazon S3 bucket policies.
7. S3 Object Lock
S3 Object Lock enables you to store objects using a “Write Once Read Many” (WORM) model. S3 Object Lock can help prevent accidental or inappropriate deletion of data. For example, you could use S3 Object Lock to help protect your AWS CloudTrail logs.
8. Enable versioning
Versioning is a means of keeping multiple variants of an object in the same bucket. You can use versioning to preserve, retrieve, and restore every version of every object stored in your Amazon S3 bucket. With versioning, you can easily recover from both unintended user actions and application failures.
Also consider implementing on-going detective controls using the s3-bucket-versioning-enabled managed AWS Config rule.
9. Pre signed URLs
Pre signed URLs can be used to grant temporary access to a specific object or to allow a user to upload an object to an S3 bucket without having to grant permanent access to the S3 bucket.
10. Use AWS Trusted Advisor
Trusted Advisor inspects your AWS environment and then makes recommendations when opportunities exist to help close security gaps.
Trusted Advisor has the following Amazon S3-related checks: logging configuration of Amazon S3 buckets, security checks for Amazon S3 buckets that have open access permissions, and fault tolerance checks for Amazon S3 buckets that don’t have versioning enabled, or have versioning suspended.
11. AWS PrivateLink for S3
Access Amazon S3 directly as a private endpoint within your secure, virtual network with AWS PrivateLink for S3. Simplify your network architecture by connecting to S3 from on-premises or in the cloud using private IP addresses from your Virtual Private Cloud (VPC). You no longer need to use public IPs, configure firewall rules, or configure an internet gateway to access S3 from on-premises.
