7 mins to read
Amazon Web Services (AWS) S3, or Simple Storage Service, is a highly scalable object storage service that allows businesses to store and retrieve any amount of data. S3 permissions are the explicit rules within policies that determine who can access the service entirely and more specifically the objects within it. Let’s dive into why managing access is important.
The Role of IAM Policies in S3
Managing identity and access to the S3 service is vital. Because S3 is a storage service, it hosts sensitive and business-critical data for most enterprises using AWS – think business secrets, employee information, customer details, and more.
This information is a desirable target in malicious cloud attacks and can potentially be further weaponized in attacker recon and lateral movement. All this being said, it is apparent how important controlling who and what can access this service and enforcing rigid IAM protocol is.
Additionally, AWS operates on a shared responsibility model. While AWS manages the security of the cloud, customers are responsible for securing the services they use, including data protection in S3.
There are a variety of IAM policies (at the identity, resource, and organizational level) you can use to protect S3. Below we will break down the S3 service, IAM policies to secure it, and common “risky” permissions.
How to Define Access to Objects in Amazon S3 Buckets
There are different configuration options when wanting to control access to S3 buckets and individual objects. Let’s define different entities to know:
S3 Object
An S3 object is any file or data stored in S3. Each object has associated metadata and can be uniquely identified within a bucket –a bucket is a container for a collection of objects (files). Individual objects are what contain sensitive data and what you are trying to control access to.
User Policy
User policies are attached to IAM users or groups and define permissions for S3 operations. They are identity-based policies that detail how an identity can interact with S3 buckets and S3 objects.
S3 Bucket Policy
Bucket policies are attached directly to an S3 bucket. They are used to grant or deny access to the objects within the bucket from different AWS accounts. They are resource-based policies.
S3 Access Control List (ACL)
ACLs provide another layer of control over access to buckets and objects. Every bucket and object has an ACL attached to it defining what entities can access it and what actions they can perform.
S3 permissions and access can be managed using ACLs or bucket and user policies.
Key Elements of an S3 Policy
S3 policies whether at the bucket or identity level have the following components in JSON format:
Effect:
The effect defines whether the actions are allowed (“Effect”: “Allow”) or denied (“Effect”: “Deny”). Example below shows an explicit allow.
Principal:
The principal specifies the user, account, service, or other entity that is allowed or denied access to the resource. See example below for principal being user JohnDoe.
Actions:
Actions determine what operations are allowed or denied. The example below shows s3:GetObject and s3:GetObjectVersioning as allowed permissions.
Resource:
Example: “Resource”: “arn:aws:s3:::bucket_name”. This element specifies the S3 resource to which the policy applies. Example below calls out an example bucket.
Condition:
Conditions specify the circumstances under which the policy grants or denies permission. For example, you can restrict access based on IP address or time of day. Note: this is optional.
Identity policy allowing JohnDoe GetObject and GetObjectVersioning permissions to only objects with the defined tag key and value: ‘production.’
How to Configure S3 Bucket Policies
Navigate to the S3 Console
Navigate to the S3 Management Console. Select ‘buckets’ and choose the bucket name you want to create a policy for. Then select the permissions tab and under ‘bucket policy’ choose ‘edit’. Here you can use AWS policy examples or navigate to AWS Policy Generator.
Use AWS Policy Generator
The AWS Policy Generator is a useful tool for creating bucket policies. To use it, navigate to the AWS Policy Generator webpage, select the policy type as “S3 Bucket Policy,” and fill in the required statement – more information below.
Configure Statements
When building bucket policies, configuring a statement is crucial. A statement includes the elements like Sid (statement ID), Effect (Allow or Deny), Principal, Action, and Resource. You must carefully configure these elements to ensure the right level of access. Once your statement is finished, select ‘generate policy.’ Return to the S3 console to paste it into the edit field.
Grant Permissions
Granting permissions through bucket policies involves specifying the allowed or denied actions and associating them with the right users or user groups. This can include a wide range of permissions, from read and write access to administrative permissions. For example, to grant read access to a public group, you would include “Effect”: “Allow”, “Principal”: “*”, and actions like [s3 Get Object.]
Additional: Managing Buckets Using ACLs
Access Control Lists (ACLs) offer another way to manage access to your S3 buckets. An ACL allows you to grant basic read/write permissions to other AWS accounts. To set up an ACL, go to the S3 Management Console, select the bucket, and navigate to the Permissions tab. Here, you can add or remove accounts and specify the types of permissions (like read, write, or full control) for each account. It’s important to remember that ACLs are less granular than bucket policies and are best used for simpler access control scenarios.
AWS S3 Actions and Permission Examples
Let’s review some examples of common s3 permissions and their associated action.
s3:GetObject | Grants permission to retrieve objects from Amazon S3.
s3:ListBucket | Grants permission to list some or all of the objects in an Amazon S3 bucket.
s3:PutAccessPointPolicy | Grants permission to associate an access policy with a specified access point.
s3:PutAccessPointPolicyForObjectLambda | Grants permission to associate an access policy with a specified object lambda enabled access point.
s3:PutBucketPolicy | Grants permission to add or replace a bucket policy on a bucket.
s3:DeleteBucket | Grants permission to delete the bucket named in the URI.
s3:DeleteBucketPolicy | Grants permission to delete the policy on a specified bucket.
s3:DeleteObject | Grants permission to remove the null version of an object and insert a delete marker, which becomes the current version of the object.
s3:GetAccessPoint | Grants permission to return configuration information about the specified access point.
s3:GetBucketLogging | Grants permission to return the logging status of an Amazon S3 bucket and the permissions users have to view or modify that status.
s3:GetEncryptionConfiguration | Grants permission to return the default encryption configuration to an Amazon S3 bucket.
s3:GetObjectAcl | Grants permission to return the access control list (ACL) of an object.
7 Best Practices for Managing S3 Permissions
- Securing Access with Policies and ACLs: Use IAM policies (either attached to a bucket or user) to define S3 permissions at more granular levels. Your teams can leverage Service Control Policies (SCPs) for organization-wide guardrails around accessing S3. ACLs can be used to manage access to individual buckets and objects.
- Enforcing Least Privilege: Always adhere to the principle of least privilege, granting only the permissions necessary for an identity to perform its intended tasks. Regularly review permissions to ensure they align with current roles and responsibilities.
- Ensuring No Buckets are Public: Avoid making S3 buckets public unless absolutely necessary. Regularly use tools like AWS Trusted Advisor or S3 bucket policies to audit and ensure that none of your S3 buckets are unintentionally exposed to the public.
- Using Role-Based Access Control (RBAC): Implement RBAC to manage access to S3 resources. This involves assigning permissions based on roles within your organization and associating those roles with users, groups, or AWS services.
- Avoiding Wildcard Permissions: Refrain from using wildcard permissions (such as ‘*’) in policies, as they can inadvertently grant broader access than intended. Instead, define specific permissions for each user or service role.
- Keeping Permissions Granular and Specific: Tailor permissions to the specific needs of each user or service. Avoid broad permissions and define them as narrowly as possible to reduce the risk of unauthorized access.
- Monitoring Access: Utilize AWS CloudTrail, S3 access logs, or third party CIEM solutions to monitor who is accessing your S3 resources and what actions they are performing. This is crucial for detecting anomalous permission or access changes.
Challenges and Risks Around S3 Permissions
Policy Complexity
Privilege is very complicated in the cloud as there are a number of different policies granting privilege and privilege can even be inherited down line. In AWS alone, there are organizational policies (SCPs, permission boundaries), resource-based policies, and identity-based policies. It is nearly impossible to manually see what the net effect of these intersecting policies is. This means the effective permissions of identities can be difficult to see. This translates into access your teams can’t always track, which introduces security risk.
Troubleshooting Denied Access
Users trying to access S3 may come across error codes like ‘403 Forbidden’ when trying to see objects. It can be difficult to troubleshoot this and trace down the origin of the statement denial in bucket policies, IAM policies, or any SCPs.
Misconfigurations
Configurations allow for customization, but they also introduce the possibility of misconfigurations leaving the service or buckets at risk.This could be a publicly accessible bucket left open to the internet, or allowing anyone to upload or delete files from the bucket. Misconfigurations are a leading cause of attacker entry into cloud environments. From here, they can move laterally to further disrupt your environment.
Cross-Account Access
You can intentionally grant users cross-account (or even multi-cloud) access to S3 objects, but sometimes this access is unintentional. Permission inheritance and policy complexity can lead to cross-account access your teams can’t see. Any privilege your teams can’t see ‘on paper’ is dangerous and is at risk of being maliciously exploited or used for attacker lateral movement. Leveraging a third-party solution like CIEM offers effective permissions visibility.
Auditing and Compliance
As per the shared responsibility model, AWS is responsible for S3 service compliance. However, the data stored within S3 is your responsibility to ensure it is compliant with any regulations in your industry like HIPAA, PCI, FedRAMP, etc.
S3 Permissions Management Made Easy with Sonrai
Sonrai’s Cloud Permissions Firewall monitors for all unused access to S3 and instantly eliminates it with the click of a button. Reduce your permissions attack service and protect Amazon S3 data — all without taking away access your identities need.
