Secure IAM on AWS with Multi-Account Strategy

TL;DR

The paper addresses the challenge of securing IAM on AWS, especially for small organizations, by advocating a multi-account strategy. It analyzes drawbacks of single-account structures and shows how AWS features like Organizations, IAM Identity Center, and cross-account sharing can mitigate risks while improving operational excellence and cost control. It details a staged policy management approach centered on the principle of least privilege and leverages tools such as IAM Access Analyzer and CloudTrail for auditing. The findings emphasize that partitioning assets into multiple accounts reduces blast radius, simplifies access control, and supports scalable governance in cloud deployments.

Abstract

Many recent IT companies use cloud services for deploying their products, mainly because of their convenience. As such, cloud assets have become a new attack surface, and the concept of cloud security has emerged. However, cloud security is not emphasized enough compared to on-premise security, resulting in many insecure cloud architectures. In particular, small organizations often don't have enough human resources to design a secure architecture, leaving them vulnerable to cloud security breaches. We suggest the multi-account strategy for securing the cloud architecture. This strategy cost-effectively improves security by separating assets and reducing management overheads on the cloud infrastructure. When implemented, it automatically provides access restriction within the boundary of an account and eliminates redundancies in policy management. Since access control is a critical objective for constructing secure architectures, this practical method successfully enhances security even in small companies. In this paper, we analyze the benefits of multi-accounts compared to single accounts and explain how to deploy multiple accounts effortlessly using the services provided by AWS. Then, we present possible design choices for multi-account structures with a concrete example. Finally, we illustrate two techniques for operational excellence on multi-account structures. We take an incremental approach to secure policy management with the principle of least privilege and introduce methods for auditing multiple accounts.

Figures (6)

• Figure 1: In single-account structures, all cloud resources are put inside a single account and all users access the same account. This may be efficient for small organizations, but it is insecure due to problems in visibility, environment separation and cost optimization.
• Figure 2: Separation by product, where each product uses a dedicated account.
• Figure 3: Bucket $S$ explicitly allows access for user $3$, but implicitly denies user $2$. Both identity-based and resource-based policies must explicitly allow the access for cross-account accesses to work.
• Figure 4: The AWS Single Sign-On console shows a list of accounts and the permission sets that can be used to access that account. This SSO user can access the MyApplication account with the permissions assigned to a backend engineer. The console also enables users to switch accounts easily.
• Figure 5: An example of a multi-account structure for a hypothetical company. Accounts are structured into five organizational units, and accounts are provisioned under each unit.