Planning the account structure

The different cloud providers have different ways of handling account structure. AWS has an organization structure where folders can be created and account can be categorized under Organizational Units (OU’s). For example, you can attach a policy-based control to an OU, and all accounts within the OU automatically inherit the policy. You can create multiple OUs within a single organization, and you can create OUs within other OUs. Microsoft Azure provides a hierarchy of organizations, subscriptions and also licenses. Google cloud platform has taken the good parts from AWS and improved them with their resource hierarchy from top to bottom: Organization, Folders, Projects and then the resources within the projects.

Planning for the account structure first is extremly important. This is where you create the heirarchical organization structure to govern the management of your cloud resources. In the end, this means that the decisions you make here makes it either easier or harder to do important things such as chargeback and organizational level billing, monitoring and centralized backup solutions.

• Create a notification account email group for the superadmin that is monitored by multiple people.

• Standardize the tagging of the accounts and the resources within the accounts. Examples of good tags are “costcenter”, “owner”, “environment” and other internally used codes.

• Make sure that each new account has billing alarms or if the cloud provider supports it, budgets. These should be adjustable.

• Minimize the number of account administrators to avoid granting too many permissions.

• Separate Dev/Test/Prod environments.

• Periodically audit access and accounts.

Enabling account access

Cloud providers can leverage existing directory services and use SAML based authentication to the cloud platforms. You should early in the process setup Single Sign On. You should look into tooling such as Okta, AzureAD or Auth0 to make the integration to your cloud platform easier by replicating to these services from your onpremise ID and directory solutions.

• Enforce Multi Factor Authentication (MFA) from the identity provider side. Make sure that MFA can be used for programmatic access as well.

• Plan for break-glass events to prevent organization-wide account lockout. This is usually the super administrator or the root account that only one or two people can access.

• Create standard recommendations for account access, such as scripts for programmatic access, example configurations and hardware/virtual MFA recommendations.

Identity and access management

Identity and access management (IAM) becomes harder the later you think about it. You can end up in solutions where you will have thousands of user accounts, service accounts or roles depending on how rampant you have let your users create keys. If you were securing your company office building, you wouldn’t give every employee a master key that can copy, give away, open the front door, the mailbox, and the safe. When you’re securing your cloud infrastructure you should also limit employees access based on their role and what they require to do their job.

This concept is known as the principle of least privilege, which NIST’s Computer Security Resource Center defines as: “allowing only authorized accesses for users (or processes acting on behalf of users) which are necessary to accomplish assigned tasks in accordance with organizational missions and business functions.” In practice, this means assigning credentials and privileges only as needed to both users and services, and removing any permissions that are no longer necessary.

• Integrate audit logs into your centalized logging system and alert on suspicious access such as “Administrator” or “Root” access.

• Avoid using broad permissions and try to specify the permissions to the resources that need access with the type of accesss needed.

• Assign roles to groups and not individuals. If you assign an IAM role directly to an individual, they retain the rights granted by that role even if they change roles, move around your organization, or no longer require them.

• Use role based access with short lived credentials for external services such as CI/CD pipelines if possible.

• Reduce the risks of default account behavior by limiting the access on creation.

• Managed services are easier to integrate with IAM roles. This goes for both AWS, GCP and Azure, where the managed databases and other services can control access not by the network but by the IAM role assignment.

Group and account organization

All major cloud providers have a way to group accounts. AWS uses Organizations, Azure uses Management Groups and GCP uses a similar tree structure with folders to handle account grouping.

To future proof account creation you need to consider how to group your accounts for each of the cloud providers. I recommend creating a genralized structure that can be used for inspiration for each public cloud.

One of the first things to look into is how you currently manage hierarchies. One of the inpirations can be looking at the networking segregation that is used in your internal data centers. Another thing to look into can be compliance where accounts can be classified into different compliance structures. Note that you should only use current structures as inspiration since the public cloud allows separation without having to separate accounts into different networks.

• Keep the account hierarchy as flat as possible

• Use tags for the accounts so that you can easily navigate accross the account tree

• Remember to include a Sandbox group for expermintation and total isolation

  • Having a totally different organization for Sandboxing the organization is really helpful

• Create top folders for “IAM”, “Security”, “Audit” and “Backup”

• On the same level, create a folder for each business unit or other part of the organization that will have multiple environments

• Only use “Production” and “Non-production” as environment separation. The accounts in each of the environment folders can be multiple

  • “ProjectAbc-Prod”, “ProjectAbc-Test”, “ProjectAbc-Dev”

• Implement policies at the top level of the organization / folder structure that enforces sane rules

  • Avoid implementing too many policies where you need to create excemptions at lower levels unneccessary

• Do not transpose the structure into a deeply nested hierarchial mess

• Don’t create accounts directly under the root of the structure

• Treat accounts as a unit of management alinged with buiness needs and priorities

  • Make sure account owners are aware of their roles and responsibilities

Back to Home