Secure access to AWS resources

Give every person and workload the smallest set of permissions it needs, prefer temporary credentials over long-term keys, and use account boundaries plus organization-wide guardrails to contain mistakes.

The root user and IAM basics

• Root user: Has full access to the account and can't be limited by IAM policies. Turn on MFA, delete or never create root access keys, and use it only for the few tasks that require it.
• IAM users and groups: Users hold long-term credentials; groups attach the same policies to many users. For people, federated access through IAM Identity Center is preferred over individual IAM users.
• IAM roles: An identity with no long-term credentials. Whoever assumes it gets temporary credentials from AWS STS. Workloads (EC2 instance profiles, Lambda execution roles, ECS task roles) should always use roles.
• Policy evaluation: Everything starts as an implicit deny. An Allow is needed somewhere, and any explicit Deny in any applicable policy wins over every Allow.
• Least privilege: Grant only the actions and resources needed. IAM Access Analyzer can generate a policy from the activity recorded in CloudTrail and flag resources shared outside your account or organization.

Policy types and where they apply

• Identity-based policies: Attached to a user, group, or role: AWS managed, customer managed (reusable, versioned), or inline (one identity only).
• Resource-based policies: Attached to the resource itself (S3 bucket policy, KMS key policy, SQS queue policy, Lambda function policy). They name a Principal, so they can grant access to another account without anyone switching roles.
• Permissions boundaries: Set the maximum permissions an identity-based policy can give a user or role. Useful when you let developers create their own roles.
• Service control policies (SCPs): Set the maximum permissions for accounts in an AWS Organizations OU or account. They grant nothing on their own, and they don't restrict the management account.
• Resource control policies (RCPs): Organization-wide limits on what can be done to your resources (for example, blocking access from outside the organization), the resource-side partner of SCPs.
• Effective permissions are the overlap: an action must be allowed by the identity or resource policy and not blocked by an SCP, RCP, permissions boundary, or session policy.

Roles, AWS STS, and cross-account access

• Trust policy vs permissions policy: The trust policy says who may assume the role; the permissions policy says what the role can do once assumed.
• Cross-account access: Create a role in the account that owns the resources and trust the other account. Callers in the other account also need permission for sts:AssumeRole on that role.
• External ID: A condition in the trust policy for third parties that assume roles in many customers' accounts. It protects against the confused deputy problem.
• Role switching: Console users can switch into a role in another account and get its temporary permissions for the session.
• Temporary credentials expire on their own, so a leaked credential has a short life. That is why roles beat access keys for both people and code.

Federation and directories

• AWS IAM Identity Center: Workforce single sign-on to many AWS accounts and apps. Assign permission sets to users and groups per account. Connects to an external identity provider (SAML 2.0, with SCIM provisioning) or to Microsoft Active Directory.
• IAM identity providers: SAML 2.0 or OIDC providers in a single account let federated users assume roles directly. Use for one account or for workloads such as CI/CD systems that present OIDC tokens.
• AWS Directory Service: AWS Managed Microsoft AD runs real Active Directory in AWS and can trust an on-premises domain; AD Connector proxies authentication to an existing on-premises AD without storing directory data in AWS.
• Federate when users already exist in a corporate directory: they sign in once with their existing credentials, and there are no IAM users to create, rotate, or remove when people leave.

Securing many accounts

• AWS Organizations: Groups accounts into organizational units (OUs) with consolidated billing, SCPs, RCPs, and delegated administration for security services.
• AWS Control Tower: Sets up and governs a multi-account landing zone: a log archive and an audit account, Account Factory for new accounts, and controls (preventive through policies, detective through AWS Config rules, proactive through CloudFormation hooks).
• Separate accounts: Accounts are the strongest isolation boundary on AWS. Split production, development, security tooling, and logging into different accounts so a mistake in one can't reach another.
• AWS Resource Access Manager (AWS RAM): Shares resources such as subnets, Transit Gateways, and Route 53 Resolver rules with other accounts in the organization instead of copying them.
• An organization trail in AWS CloudTrail records API activity from every account into one central, locked-down S3 bucket.

Global infrastructure and the shared responsibility model

• IAM is a global service; most other resources live in a Region. An SCP that denies actions outside approved Regions (the aws:RequestedRegion condition key) enforces data residency across every account.
• Under the shared responsibility model AWS secures the infrastructure; you own identities, permissions, network rules, encryption choices, and your data on every service.