Secure (and usable) multi-AWS account IAM setup
Managing multiple AWS accounts increases billing, compliance, and operational complexity, but it provides valuable security boundaries between workloads. The post proposes a centralized IAM design in which users exist in only one account, receive minimal default permissions, and temporarily assume narrowly scoped roles in target accounts. MFA and short-lived credentials further limit the impact of compromised credentials, although the approach is constrained to roughly ten accounts by IAM group limitations. ## Why Use Multiple AWS Accounts? - Accounts isolate workloads at several levels: - **Network:** VPCs are separate unless explicitly peered. - **API access:** A compromised account cannot access others without delegated roles. - **Compute and billing:** Per-account spending limits, billing alerts, and CloudTrail monitoring can contain or reveal abuse such as cryptocurrency mining. - The main challenge is gaining these security benefits without creating unmanageable administrative overhead. - The proposed pattern is better suited to production environments than development setups where every developer may have a separate account. - Current IAM group limitations restrict the design to approximately ten accounts. ## Centralized IAM User Management - Each IAM user should exist in only one account. - Centralizing users makes onboarding, offboarding, password policies, and auditing easier. - Other accounts can be monitored for unexpected IAM user creation, which should generally never occur. - Users receive only the permissions needed to manage their own authentication settings. ## Why Use IAM Instead of SSO? - SSO would centralize authentication through an existing identity provider. - However, the post argues that SSO can limit the ability to apply MFA protection precisely to privileged operations. - Since MFA is central to the proposed privilege-escalation model, standalone IAM users are retained despite their administrative drawbacks. ## Minimal Default Permissions By default, users should be able to: - View their own IAM record. - Change their console password. - Create, update, or delete their own API credentials. - Create their own MFA device. They should have no meaningful access to other AWS APIs. This limits the blast radius of stolen usernames, passwords, or API keys: without the user’s MFA device, an attacker can generally do little more than inspect the compromised user’s record. ## Temporary Privilege Through Role Assumption - Users perform privileged work by calling `sts:AssumeRole` in the target account. - Assuming a role provides temporary credentials and a session token. - Credentials have a short lifetime, normally no more than one hour by default. - This resembles the Unix `sudo` model: users begin with restricted permissions and explicitly elevate privileges when necessary. ## MFA-Protected Privilege Escalation A role assumption should succeed only when both conditions are met: - The user has an active MFA device and can authenticate with it. - The user belongs to a group authorized to assume the requested role. MFA does not eliminate compromise risk, but it makes stolen API credentials substantially less useful and limits the damage they can cause without the corresponding MFA device. ## Privileges Grouped by Operational Topic - Administrative capabilities are divided into roles based on responsibility rather than assigning broad account-wide permissions. - Example roles include: - A **VPC role** for network configuration. - An **EC2 role** for instance management. - An **S3 role** for storage administration. - Users can then be mapped to groups and roles according to their job responsibilities, making permissions easier to understand and maintain. ## Practical Recommendation Use multiple AWS accounts as deliberate security boundaries, but centralize IAM users, keep their baseline permissions minimal, require MFA for role assumption, and grant temporary, topic-specific roles. This provides strong isolation while keeping privilege management manageable, particularly for production environments with a limited number of accounts.
Read original(opens in new tab)