3.3.1. Identity and Access Management (IAM, Organizations, SCPs, Identity Center, Federation)

💡 First Principle: The cornerstone of cloud security is granular control over who can access what resources and perform what actions, enforced by a robust identity management system founded on the principle of least privilege.

Scenario: A large enterprise with a multi-account AWS environment wants to enable its developers to securely access resources across different development accounts without managing individual "IAM users" in each account. They also need to enforce a corporate policy that prevents any developer from launching expensive or non-compliant "EC2" instance types across all development accounts.

Identity and Access Management ("IAM") is paramount for securing your AWS environment.

• "IAM Users": Represents individual human identities requiring persistent AWS credentials. Best practice is to use them with "MFA" and discourage long-term access keys.
• "IAM Roles": Grant temporary, limited-privilege permissions to trusted entities (human or machine).
  • Practical Relevance: Used for cross-account access, "EC2 instance profiles", "Lambda function execution roles", and federation. Preferred over "IAM users" for programmatic access.
• "IAM Policies": JSON documents defining permissions.
  • Practical Relevance: Apply principle of "least privilege" (grant only necessary permissions). Can be "identity-based" (attached to users/roles) or "resource-based" (attached to "S3 buckets", "SQS queues").
• "AWS Organizations": Centralized management for multiple AWS accounts.
  • Practical Relevance: Consolidates billing and allows "Service Control Policies (SCPs)" to set maximum permissions for all "IAM users"/roles in member accounts, acting as preventative guardrails (e.g., deny specific high-risk actions across the entire organization).
• "AWS IAM Identity Center (SSO)": Centralizes access management to multiple AWS accounts and business applications from a single sign-on portal.
  • Practical Relevance: Simplifies multi-account access for users, integrates with corporate directories ("Active Directory", "Okta"), and provides a unified authentication experience.
• Identity Federation ("SAML 2.0", "OIDC"): Allows users to sign in with corporate credentials and assume temporary "IAM roles" in AWS.
  • Practical Relevance: Eliminates the need to create and manage separate "IAM users" for every employee, reducing credential sprawl and improving security.

Visual: IAM, Organizations, Identity Center, Federation

Loading diagram...

⚠️ Common Pitfall: Granting overly broad permissions (e.g., *.*) for convenience. This dramatically increases the blast radius if an identity is compromised. Always start with zero permissions and add only what is explicitly required.

Key Trade-Offs:

• Granularity vs. Management Overhead: Highly granular "IAM policies" are more secure but can be more complex to manage. Using "IAM groups" and well-structured roles helps balance this.

Reflection Question: How would you combine "AWS IAM Identity Center (SSO)", cross-account "IAM Roles", and "AWS Organizations Service Control Policies (SCPs)" to meet the requirements of a large enterprise for centralized access management and preventative governance, specifically preventing developers from launching non-compliant "EC2" instance types across all development accounts?