5 Shared Responsibility and IAM Practice

The shared responsibility boundary

AWS secures the underlying facilities, hardware, networking, and infrastructure that run its services. This is Security of the cloud. Customers are responsible for Security in the cloud: configuring access, protecting data, and managing applications and identities. The exact scope depends on the AWS services in use.

Applying the responsibility model

For Amazon EC2, the customer manages the guest operating system and its patches, while AWS maintains the underlying service infrastructure. With more managed services, AWS manages more of the underlying stack, but customers still configure access to their resources. A useful rule is that if you can configure a resource or its access, you are generally responsible for configuring it securely.

Examples of responsibility include:

• AWS protects its data-center facilities and maintains the underlying AWS service infrastructure.

• The customer creates IAM users or roles, assigns permissions, and enables MFA for human sign-in identities.

• The customer patches an EC2 guest operating system.

IAM identities and credentials

An IAM user is an identity in an AWS account. When using IAM users for people, assign each human a separate identity instead of sharing credentials; AWS recommends federated access for human users where practical.

An IAM role is an identity that a trusted user, service, or federated principal can assume. Roles are commonly used by applications and AWS services, and provide temporary credentials. AWS recommends temporary credentials for workloads through roles, MFA for identities, and least-privilege permissions. Use the account root identity only for tasks that require it, and protect it with MFA.

Policies, roles, and MFA

A permissions policy is a JSON document describing allowed or denied actions and resources, with optional conditions. It answers what the identity can do after access is granted.

A trust policy states who or what may assume a role. It does not define what the role can do after assumption; the role’s permissions policy defines that. A role therefore needs both an appropriate trust relationship and appropriate permissions.

MFA is an additional sign-in factor. It strengthens authentication but does not grant permissions to AWS resources.

A method for reviewing access

Review a requested action by identifying the principal, the action, the resource, and every policy control that applies.

1. Identify the principal making the request: a user, assumed role, service, or external principal.

2. Identify the requested action and match it to the relevant service action, such as s3:GetObject.

3. Check that the resource ARN matches the intended bucket, object, or other resource.

4. Review identity-based and resource-based policies, the role’s trust policy, and any applicable permissions boundary, session policy, or AWS Organizations policy.

5. Check for an applicable explicit Deny. It overrides an Allow. Without an applicable Allow, access is normally denied by default.

For cross-account access, both the requesting identity and the account that owns the resource must allow the access.

A bucket-scoped read policy

This identity-based policy allows listing one bucket and reading objects in that bucket. The bucket-level action uses the bucket ARN, while the object-level action uses an ARN ending in /*.

This policy does not allow uploading or deleting. It also does not guarantee that access will succeed: another applicable policy can deny the request, and other policy controls can further limit effective permissions. Least privilege means starting with only the actions and resources the task requires, then adjusting based on the real task.

Applying access review to common cases

A developer who only needs to read objects from one project bucket should not have s3:* on *, because that grants far more access than the task requires. Use only the specific read actions and bucket or object resources needed. Use the example policy if the task requires both listing and reading.

An application running on EC2 that only needs to read one S3 bucket should not store a long-term IAM user access key in a local configuration file. Prefer an IAM role for the EC2 workload, grant it only the required bucket permissions, and let the workload use temporary credentials.

A role with narrow bucket-read permissions can still be exposed if its trust policy allows an unintended principal to assume it. Restrict the trust policy to the intended user, service, or federated principal, and separately confirm that the permissions policy is limited to the required resources.

If a user has MFA enabled but policies allow only s3:GetObject, MFA does not enable the user to delete an object. Deletion requires an applicable policy allowing s3:DeleteObject, with no applicable deny; grant it only if the job requires it.

If one applicable policy allows an action and another explicitly denies it, the request is denied. Find and assess the applicable deny; adding another allow does not override it.

For EC2, patching the guest operating system is generally the customer’s responsibility. AWS secures the infrastructure beneath the instance. Responsibility can differ with more managed services, so assess the service being used.

Approval checklist and review

Before approving an access configuration, check whether:

• Each person or workload has an appropriate identity rather than shared credentials.

• A workload can use a role and temporary credentials instead of long-term access keys.

• MFA is enabled for human sign-in identities, especially privileged ones.

• Actions and resource ARNs are limited to what the task requires.

• Each role trusts only the intended principals.

• Explicit denies, permissions boundaries, session policies, or organization policies affect the request.

• Responsibility is clear for the service layer being configured.

The central distinction is that AWS protects the infrastructure of the cloud, while customers configure and protect their resources within it. IAM users and roles identify principals; trust policies determine who can assume a role, and permissions policies determine what actions are allowed. Access review must account for the principal, action, resource, and all applicable policies.