1 IAM Fundamentals and Least Privilege

IAM and access control

Identity and access management (IAM) controls who or what can access resources and what they are allowed to do. In AWS, IAM provides mechanisms to identify principals, authenticate requests, and authorize actions on AWS resources.

Identities, users, groups, and roles

An identity represents a person, application, or other workload that needs access. A Principal is the identity making a particular request.

AWS IAM identities include:

• IAM users: Identities with credentials and permissions. A user can represent a person or an application, though AWS generally recommends temporary credentials over long-term user credentials.

• IAM groups: Collections of IAM users that help administrators manage common permissions. Users—not groups—sign in.

• IAM roles: Identities that trusted principals can assume. Assuming a role provides temporary credentials and the permissions attached to that role. Roles are commonly used by applications, federated users, and people who need temporary or cross-account access.

The AWS account root user has broad access to the account. Protect it and reserve it for tasks that specifically require it, rather than using it for everyday work.

Authentication and authorization

Authentication verifies an identity by answering: Who or what is making this request? Credentials can include a password, access keys, or temporary role credentials. Multi-factor authentication (MFA) strengthens sign-in by requiring an additional factor, such as a code from an authenticator or a security key.

Authorization determines whether an authenticated principal may perform a requested action on a resource. For example, an application might authenticate with a role and then be authorized to read from a particular storage bucket. Authentication alone does not grant permission to use every AWS service or resource.

Policies and permission decisions

A Policy describes permissions. Identity-based policies are attached to users, groups, or roles; resource-based policies are attached to supported AWS resources. A policy statement commonly specifies:

• Effect: Allow or Deny.

• Action: The operation, such as reading an object.

• Resource: The resource the action applies to.

• Condition (optional): Circumstances that must be met for the permission to apply.

For example, this identity-based policy allows reading objects from one named S3 bucket, but does not grant access to other buckets:

AWS denies requests by default unless applicable permissions allow them. An explicit deny overrides an allow. Permission is not implied merely because a principal can sign in or has access to a related resource.

Applying least privilege

Least privilege means granting only the permissions needed for a task, and no more. Limit permissions to the necessary actions, specific resources, and relevant conditions. Prefer separate roles or permission sets for different jobs rather than sharing powerful credentials. Use temporary role credentials when practical, enable MFA for human sign-in, and review permissions as responsibilities change. Start with narrow access, then add permissions when a documented task requires them.

For example, a reporting application that only reads reports should receive permission to read the reports it needs—not permission to delete files, change bucket settings, or administer the account. Narrow permissions reduce the potential impact of mistakes or compromised credentials.

Shared responsibility for security

Shared responsibility means AWS and its customers share responsibility for security. AWS is responsible for the security of the cloud infrastructure that runs its services. Customers are responsible for security in the cloud, including choosing and configuring identities, credentials, MFA, and permissions appropriately. IAM supplies access-control tools; customers must use them safely.