As a startup, it's important to ensure that you're implementing proper Identity and Access Management (IAM) practices from day one. IAM is critical in protecting your organization's resources, maintaining compliance with regulations such as SOC2 or HIPAA, and ensuring smooth and efficient user management. Despite its importance, getting IAM right on AWS is routinely a source of confusion and regret for people doing it (even if they’ve done it before). It can be a challenging and time-consuming process, especially if you've already set up manual roles across various services. This blog post will guide you through the ideal setup for startups, helping you achieve a secure, productive, and compliant environment.
IAM is essential for safeguarding your organization's digital assets, controlling who has access to specific resources, and keeping track of user activities. Implementing a robust IAM strategy not only ensures the security and integrity of your systems, but it also helps your startup maintain compliance with industry regulations, such as SOC2 and HIPAA. These compliance programs require that businesses implement strict access control and user management policies to prevent unauthorized access, data breaches, and other security threats. In this guide, we aim to strike a balance between best practices and considerations like setup time, understandability, and familiarity with concepts for startup users. It’s rooted in real-world experience with startup teams at Coherence.
To establish a secure and compliant IAM environment with multiple AWS accounts in an Organization, we recommend the following setup (we also see other startup-focused recommendations in line with this, for example this from SST):
Create an AWS Organization in an otherwise-empty management account: Begin by setting up a central management account for your startup. This account will serve as the foundation for your IAM strategy, allowing you to manage other AWS accounts and resources.
Other accounts created via the organization: Use a team-accepted method to generate unique email addresses for each account, such as mailinglist+accountname@startup.com. You won’t actually use the root account to login to these accountes, but AWS requires each account to have a unique email that owns it.
The first account that most teams will add is the sandbox account for the dev team: Create a sandbox account where your entire development team can experiment without affecting staging or production environments. Ensure everyone understands that anything within this account can be deleted or broken at any time.
Next, add a staging account for non-production use: Create a staging account for hosting all non-production workloads, with limited write access for the dev team. Consider using tools like Coherence for providing your team hosted production-quality review apps instead of just having one shared staging environment. The other 2 accounts you’ll often create in your organization are:
Use AWS Identity Center: Leverage AWS Identity Center to manage access to the different accounts in your organization. You can use the built-in users/groups functionality to add users to groups, and then attach permission sets to groups using the IAM Identity Center “Assign users or groups” workflow (most teams use the predefined AdministratorAccess permission set, but you can create custom permissions as well). You can also use an SSO source instead of adding users and groups manually in IAM Identity Center.
As you scale, you’ll be well-positioned to import organizational level controls using more complete services such as https://aws.amazon.com/controltower/ as they are needed or you have the bandwidth to operate them.
Establishing a secure and compliant IAM setup on AWS for your startup is essential in today's digital landscape. By following the guidelines provided in this blog post, you'll be well on your way to achieving a robust IAM strategy that not only protects your organization's resources but also ensures adherence to industry regulations. Remember, getting IAM right from the beginning can save you time and resources in the long run, and help you avoid the pitfalls of manual role management.
