Introducing AWS IAM Role and Policy Restrictions

Explored options to keep restricted permissions for 'S3 bucket' through an IAM Policy recently. Let us take a look at protection of S3 buckets in AWS using service policies and roles.

Introduction

To create the S3RestrictedPolicy IAM policy, first define the policy to allow access to only the AppConfig buckets. Choose the S3 service and include all S3 actions. Specify all resources except the bucket, then explicitly add the AppConfig bucket names to the policy. Once the policy is ready, create the IAM role.

For creating the S3RestrictedRole, set the trusted entity to an AWS account. Select "This account" during setup, attach the S3RestrictedPolicy as the role’s permission. Update the trusted entity configuration of S3RestrictedRole to include the ARN value for user2.

To test the IAM policy and role configuration, attach the S3RestrictedPolicy to user1 and log in as user1 to test access to the AppConfig buckets. Then, log in as user2, assume the S3RestrictedRole, and verify that the role’s access behaves as expected.

Objective

To create the S3RestrictedPolicy in AWS and apply it to users, start by navigating to the AWS Management Console and accessing the IAM service. In the IAM dashboard, go to "Policies" and choose "Create policy." Use the visual editor to select the S3 service, then set permissions to include all S3 actions. Define the resources by excluding general S3 bucket access and explicitly adding only the specific AppConfig buckets. After reviewing the configuration, name the policy "S3RestrictedPolicy" and finalize it.

Next, create an IAM role called S3RestrictedRole. Choose "AWS Account" as the trusted entity type and select "This account" to specify that users within your AWS account will assume this role. Attach the S3RestrictedPolicy during the role creation process. After creating the role, modify its trust policy to include the ARN for user2, allowing this user to assume the role.

To apply the policy, go to the IAM console's "Users" section and attach the S3RestrictedPolicy directly to user1. Log in as user1 to verify access, ensuring the user can only interact with the specified AppConfig buckets. For user2, log in and assume the S3RestrictedRole to confirm that access is similarly restricted to the designated buckets. This approach ensures controlled access to S3 resources, enforcing permissions based on specific use cases.

Assuming that we have four buckets with number of names matching customer and production:

Create a Policy in AWS to apply S3 Restrictions:

Add S3 and choose All S3 Actions:

Choose the ARNs of any sensitive S3 buckets for limiting the access:

Checked object within resources:

I have added two ARNs to the Bucket section:

Given a name to the policy:

Once created, added user1 to assume this policy:

Now created a AWS Account Trusted Entity:

Added this newly created S3 Restricted Permissions:

Given right name to the role:

Selected the policy to apply to this new role:

Edited policy to include ARN of user 2 -so user 2 can access selected S3 Buckets:

Test-User1:

User 1 do not have access to any buckets as expected:

User 2 with default role do not have access to any buckets as expected:

User 2 performing Switch Role to move to S3RestrictedPolicy can access the selective S3 Buckets as expected:

Use Cases and Purpose

Restricting S3 bucket access for certain users in AWS has several important business use cases, enhancing security, compliance, and operational efficiency:

1. Data Security and Privacy Compliance: Companies handling sensitive data, such as customer information or financial records, need to ensure that only authorized personnel access specific S3 buckets. Restricting access helps comply with regulations like GDPR, HIPAA, or SOC 2, reducing the risk of data breaches.
2. Role-Based Access Control (RBAC): Different teams (e.g., development, operations, and finance) often require varying levels of access. Developers might need access to application configurations, while financial data should be limited to finance teams. IAM policies can enforce these distinctions.
3. Minimizing Data Exposure: Limiting user access reduces the attack surface. For example, only allowing specific users to access critical or sensitive buckets mitigates the risk of accidental or malicious data deletion or modification.
4. Environment Separation: In multi-environment setups (development, staging, and production), you might restrict access to prevent accidental data corruption. Developers might have access to development buckets but not to production data.
5. Third-Party Vendor Access: If external partners or vendors need temporary access to certain data, S3 restrictions ensure they can only interact with specific resources, protecting other sensitive information.
6. Audit and Accountability: Restricting access helps maintain clear accountability. Knowing which users have access to specific buckets makes auditing easier and improves traceability for data access logs.
7. Cost Control: Unrestricted access might lead to unnecessary storage or data transfer costs. By controlling who can upload or download data from specific buckets, you can better manage cloud spending.
8. Data Residency and Regional Compliance: Businesses may need to enforce data residency requirements, ensuring data stored in specific regions is accessible only to users within certain geographical locations or organizational units.

These use cases demonstrate how restricting S3 access aligns with security best practices, operational needs, and compliance requirements.

Like this article? Subscribe to Engineering Leadership , Digital Accessibility, Digital Payments Hub and Motivation newsletters to enjoy reading useful articles. Press SHARE and REPOST button to help sharing the content with your network.

#LinkedInNewsUK #FinanceLeadership