Secure (and usable) multi-AWS account IAM setup | Datadog

The post presents a defense-in-depth approach to securing AWS accounts with IAM. Its central recommendation is to minimize long-lived credentials and broad permissions by combining strong authentication, role-based access, least privilege, and continuous auditing. Secure account governance is treated as an ongoing operational process rather than a one-time configuration.

Protect the Root User

• Use the root user only for tasks that cannot be performed through IAM.
• Enable multi-factor authentication (MFA), preferably with a hardware security key.
• Avoid creating root access keys.
• Store root credentials securely and monitor for any root-user activity.

Use Federated, Role-Based Access

• Prefer AWS IAM Identity Center or an external identity provider for human access.
• Grant users access through groups and roles instead of individual permissions.
• Use short-lived role credentials rather than permanent IAM user access keys.
• Require separate roles for administrative, development, production, and read-only work.

Apply Least Privilege

• Start with narrowly scoped permissions and expand them only when necessary.
• Restrict actions by resource, account, region, and relevant condition keys.
• Avoid wildcard permissions such as Action: "*" and Resource: "*".
• Use IAM Access Analyzer and CloudTrail activity to identify unused or excessive permissions.
• Add permission boundaries or organization-level Service Control Policies when teams need guardrails around delegated administration.

Secure Workloads and Automation

• Assign IAM roles directly to EC2 instances, Lambda functions, containers, and other workloads.
• Do not embed access keys in source code, configuration files, or deployment artifacts.
• Store unavoidable secrets in services such as AWS Secrets Manager or Systems Manager Parameter Store.
• Rotate and revoke credentials promptly when they are exposed or no longer required.

Monitor and Audit IAM

• Enable CloudTrail across accounts and regions, with logs protected from modification.
• Alert on suspicious activity, including root-user use, policy changes, disabled logging, and unusual access-key behavior.
• Regularly review users, groups, roles, policies, and unused credentials.
• Use AWS Config, Security Hub, or equivalent controls to check compliance with account-security requirements.

Centralize Governance

• Manage multiple AWS accounts through AWS Organizations.
• Keep production and sensitive workloads isolated from development accounts.
• Apply Service Control Policies to prevent high-risk actions, even for administrators.
• Establish a controlled emergency or “break-glass” access process with strong monitoring.

The practical recommendation is to combine MFA, centralized identity, temporary role credentials, narrowly scoped permissions, and continuous auditing. No individual IAM setting is sufficient on its own; security comes from layering preventive controls with detection and response.