avatarTeri Radichel

Summarize

Organizational Hierarchies and Policies in AWS, Azure, and GCP

Multicloud.5 Accounts, OUs, Subscriptions, Tenants, Folders and Projects

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics. The Code.

🔒 Related Stories: Multi-Cloud Security | AWS Security | Azure Security | GCP & Google Security.

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In the last post I wrote about how you can set up cloud accounts more securely.

The next thing you are probably going to want to think about is how do you structure your account to keep it secure and track costs?

If you simply let people deploy anything they want in any manner they wish, then security is out the window in a large organization. You’re probably also going to have a hard time tracking costs in a manner that lets you bill the cost of the resources back to the proper department or line of business within the organization.

Each different cloud service is going to have a different mechanism for grouping resources and tracking costs. That means you’re going to need to sit down and read the documentation and try things out before you start deploying the resources if you intend to have any sort of governance and cost control in some type of cloud accounts and scenarios.

Architecting your organizational structure in clouds for governance

When you set up a cloud account, you need to offer the constructs that account provider offers to design an architecture that maintains security, controls costs, and hopefully makes goverance easier.

If you dump all your resources into one big pot, it’s going to be hard to sort that out. If you have your resources spread out all over the place, forget security and governance. If you have a structure that is too rigid, people won’t be able to do their jobs.

Another consideration is cost. Your costs may increase or decrease depending on how you structure your organization and where you deploy your resources. Some things increase in cost as they cross trust boundaries. Other things require licenses in each “container” you create in your organization.

I wrote this post about designing an organization architecture in AWS but these concepts apply to any cloud provider. It’s just that each cloud provider will have different constructs for you to use to design your structure. I’ll go over the options in Azure, GCP, and AWS below.

To make your life easier, use the principal of abstraction. Abstract out the things that are repetitive to a single policy or group where it makes sense. The more you can abstract multiple policies or tempates to a single policy or template with configurable parameters, the less you have to manage and the less chance for error.

You cannot buy a product to design your organizational architecture. Well, maybe you can but it might not work well because your organization likely has features, constraints and risk tolerance that varies from other organizations. Some of that may be your compentitive advantage. That is why I say, security architecture is not a checklist. You have to design the architecture for specific needs and to protect against your biggest risks and threats. Those may differ by organization.

Small team, one account, one budget cost center

If the service is only used by one team and the whole bill goes to that team then maybe you don’t need to worry about cost allocation. Perhaps the cloud service is used for managing resumes by human resources. The cost of that service is charged in full to the HR budget.

The security team may be involved in helping define a secure configuration. Perhaps an IT team configures the product so it is integrated with the company’s authentication system and logs are configured to be sent to the security team’s logging system or a central log data lake.

The IAM team helps implement user accounts and permissions so system users have the appropriate permissions within the system based on the group they are assigned in the company’s identity management system. This presumes the cloud provider supports such an integration, which hopefully it does if you performed a security assessment in advance.

Hopefully the security team can restrict access appropriately so the account only allows access from your corporate VPN or private network of some kind. That capability would also need to be evaluated during the assessment phase.

Lots of teams, massive cloud platform, many services

Now let’s say you’re embarking or have embarked on the journey to use AWS, Azure, and/or Google. These three cloud providers offer services that fall basically into the same category of service. However, they work completely differently in terms of how you group resources for billing purposes and apply governance and permissions across the platform.

Let’s look at the different constructs.

AWS

In AWS you create accounts. All the resources in a single AWS account will appear on the same bill or invoice. Each account will have it’s a separate bill. So one way to track all the resources that need to be billed to a single cost center or department is to put them in their own account. That is not always possible, but you will make your life easier if you split up resources that need to be billed to different parts of the organization into separate accounts.

On the flip side, you can also make your life easier for security and governance if you put certain high risk resources in their own accounts managed by people who have deep security knowledge in a particular area, like IAM, Encryption, or Networking. The boundaries for billing and security do not alway align. When you architect your organizational structure, you’ll want to consider how you align your account architecture to meet the needs of both accounting and security.

It was difficult originally to track all the accounts belonging to an organization. AWS came up with an overarching structure for enterprise account management after the fact. They were the first major infrastructure as a service (IAAS) cloud provider offering virtual compute resources and networks. Some of the enterprise features got added as larger companies started using the service.

AWS added AWS Organizations as a way to manage all the accounts belonging to an organization in one place. When you set up an AWS organization, you can see all the bills for the organization in one place and get a rollup of all the costs.

With AWS Organizations you can add existing accounts or create new accounts. Specifically you can:

  • Invite an account to the organization
  • Add a new account within an organization
  • Remove an account from the organization

Within an organization you can create an Organizational Unit (OU). You can add accounts to an OU. Organizations can apply policies to certain or all of the accounts in an OU instead of having to apply the same policy to multiple accounts individually. The policies you apply at the organizational level are called Service Control Policies (SCPs). Service control policies are very flexible and powerful allowing you to create rules on almost any action, resource or principal within your AWS account. You can leverage the logic to include or exclude resources, principals, and policies and leverage conditions in logs or tags to create extremely fine-grained policies if needed.

You can create OUs and Service Control Policies programmatically.

Service Control Policies are blocking policies only at the time of this writing, so you’ll want to test them appropriately before rolling them out to a production account — or even a development account!

I’ve written a number of stories about AWS Organizations, which you can find here if you are trying to determine how to structure your accounts and OUs.

AWS cost categories allow you to allocate costs on bills to different categories. Companies can define multiple cost categories on a single bill, so this would be a way to assign different line items on a bill to different cost centers. The challenge will be when you have a lump sum for a number of the same type of resources. You’ll need to make sure the cost categories feature will be able to distinguish resources from one another that need to be billed to different cost centers. You can allocate costs based on percentages and other types of rules as well.

AWS resource groups are a construct that allows you to automate actions on a group of resources. You don’t apply permissions or policies to AWS resource groups. They serve more of a DevOps function than a governance or cost management function.

AWS has a service called Azure Audit Manager which allows you to select compliance frameworks and apply them to your account. I honestly have not used this feature yet but looking at the documentation, I do not see that it is related to the Service Control Policies you create. I may use that in a future post.

You could create absolutely any automation you need with AWS services and tools to respond to events. AWS provides you the building blocks and you build it yourself as needed rather than giving you a specific tool to handle SIEM and SOAR type solutions. I do not see a specific trigger for a service control policy violation, but you should be able to collect that information and create a lambda function or automated run book to respond to it, for example.

Microsoft

Azure is Microsoft’s cloud platform for building and hosting applications and virtual servers. It was built more in line with an organization having one account, and a way to allocate costs and apply policies across that account.

Although Azure does have a mechanism to group multiple Azure accounts, a support person once told me less than 1% of Azure customers use this feature. An Azure Enterprise Agreement (EA) that allows an organization to manage multiple accounts under one umbrella has an additional cost associated with it, while AWS Organizations and Google Organizations are free.

Just reading this makes my head spin. It appears that there may be a price break if you commit to a long term contract. The price may go down. But it may go up. If you are interested in this option, talk to someone at Microsoft.

It used to be that you could not programmatically create user accounts unless you had an enterprise agreement. I think that may have changed. But we’ll dig into that in another post as here we’re concerned about grouping resources for cost management and governance.

If you do opt for an Azure EA, then you could track costs by setting up a separate account. You can also use accounts as security boundaries. But you may not want to do that depending on how the licenses get allocated across your organization. Hold that thought.

Within an Azure you account you have a default Tenant. The tenant is where you create all the identities that have access to resources in your account. It is essentially an instance of Azure Active Directory (AD) if you are familiar with that term. Azure AD is not the same as the on-premises version of Microsoft Active Directory most companies used before cloud became a thing. But it serves a similar purpose. And, Microsoft just gave Azure Active Directory a new name: Microsoft Entra ID. More on Azure IAM in a future post.

You can add a custom domain name to an Azure tenant. If someone in your organization has already used your domain name within Azure, you won’t be able to add it. You will have to find that person and consolidate any resources you have into one account.

Please read this information on domain name security as you are making changes to domain names and considering where they may be in use throughout your organization.

You can create multiple tenants in your Azure account. If you wanted to be sure that a particular user could only ever access certain resources, then you could add the user to one tenant and then create a new tenant and associate all the resources you don’t want the user to access in the other tenant. That’s one approach and is definitely useful for certain use cases.

  • When you want to give a third-party access, you might not want to add them in your primary tenant (There are some specific services for this I’ll cover later).
  • If you are testing changes to your tenant, you could break a lot of things. You might create a new tenant for that purpose.

What you do not want to do is create multiple tenants unnecessarily, because the way Microsoft licensing works, you might pay for the same license for a user for every tenant in which they operate. Or perhaps you have to pay for two Windows licenses across two tenants. For this reason, you may want to restrict most users to a single tenant. I am not, nor do I wish to be, a Microsoft license specialist, so consult Microsoft for more information.

Within or associated with your tenant, you can create subscriptions. In Azure, a subscription is associated with a bill. The resources you create must be associated with a subscription. The resource will show up on the bill for the subscription in which it was created. You can use subscriptions to group resources such that all the resources for a particular subscription are charged to a single cost center. That may make your accounting team happy.

Azure management groups are similar to AWS OUs. You can add multiple subscriptions to a management group and apply policies to the management group to enforce rules for security and governance at that level instead of applying the policy to each individual subscription.

There’s also the concept of resource groups. When you create a resource, you assign it to a resource group in Azure. You can use resource groups to group resources that need to follow the same rules. You can grant users access to all the resources in a resource group. The other nice thing about resource groups (and something you need to guard against) is that when you delete a resource group, all the resources in that group are deleted. That makes cleaning up an application proof of concept implementation easier, for example.

The mechanism for creating policies in Azure for an organization is called Azure Policy. Policies can be applied to management groups, subscriptions, resource groups, or individual resources. You can set up policies in alert only mode which will not stop an action but send an alert to the logs. You can alternatively set up a blocking policy that blocks actions that constitute a policy violation.

You can feed policy violations into Azure’s SIEM product, Sentinel, and programmatically respond to those events with Azure’s SOAR functionality. I’ve heard mixed reviews on this tool but it looks really cool. Just make sure you try it and look into all the permissions it requires. Also consider if and how you can suppress false positives.

Azure has a mechanism for grouping policies together called Azure Initiatives. You can find predefined initiatives in Azure that are aligned to certain compliance frameworks and apply them to your account. For example, if you want to be compliant with the NIST Framework, you could select those rules and apply the associated policies to your account in a non-blocking manner. Then once you are sure they won’t break anything, turn on blocking for those rules.

Azure has the concept of a billing account which is separate from your Azure or O365 account. If you want to see all your bills across all services you login at the Microsoft portal. There you can see things like Office and Exchange licenses, as well as any Azure services. There are different kinds of billing accounts and Microsoft has changed the name of and links to these pages over time. Check your emails, bills, and the documentation for the specific services you are using to find out how to get to your billing account and what type of billing account you have.

If you are logged into Azure and navigate to billing accounts you might not be seeing everything your company is paying for in relation to Microsoft Cloud products. There is also a billing portal for M365. I was able to see all the things I’m paying for at a generic Microsoft login page. Enterprise agreements also have a billing account. You can manage permissions for users to access different billing accounts.

GCP

Google cloud services, like Microsoft, have a few different offerings that you log into at different places.

The first is Google Workspace. If you set up a Google Workspace account you can use cloud applications Google offers such as Gmail, Google Docs, Drive, Slides, Sheets, etc. If you set up a Google Workspace you can also add users and grant them permissions to those applications and Google Cloud Platform.

Google has another option called Cloud Identity that you can use to manage identities in your organization. It also facilitates SSO so users can log into other systems with the same credentials. Both Azure and AWS offer similar services. You can sign up for Cloud Identity with or without Google Workspace. You will need one or the other to set up organizational controls on GCP.

GCP Resource Manager is the name of the feature that allows you to create your organizational structure.

When you create resources in Google Cloud Platform (GCP) you create them in a project. Every resource in Google Cloud Platform must be in a project.

You can group projects in GCP using folders. The folders in GCP are like OUs in AWS or Management Groups in Azure. Folders allow you to group your projects and apply policies to groups instead of individual projects.

A Google organization is similar to AWS Organizations or an Azure Account. It allows you to see and manage all the resources for your organization in one place. An organization is the root node in a GCP environment and has no parent.

If you want to create a GCP organization you will need to set up a Google Workspace or Google Identity. When you set up either of those services, an organization is automatically created. You can link an existing GCP account to an existing Google Workspace or Google Identity account.

You can add a custom domain name to a Google account. Once again, if someone has already uses that domain name in Google — let’s say your marketing team set up a YouTube channel — you’re going to have to sort that out. I have heard companies complain about the problems with consolidating use of a domain name in Azure and Google in the past. I’m not sure if that process has improved.

You can create multiple billing accounts to pay for services in Google Cloud. You can restrict user permissions to only see and manage certain billing accounts. One of the nice things in GCP is that you can easily disable billing for any project and effectively stop any further charges coming from that project. You also need to understand who has that permission as obviously that could cause problems.

Google Cloud has an organization policy service which allows you create what are called constraints. You can apply constraints to the entire organization, folders, or projects.

Google Cloud also has the concept of restrictions which you can use to block access to Google Cloud accounts other than the organization’s cloud resources or specific vendor resources on a company managed device.

You can use resource settings in Google Cloud to apply certain settings across your organization, folders and projects. The settings are inherited by descendants in the Google hierarchy. The example Google provides is for default DNS servers across projects.

Google has various other services, some of which are facilitated through third-parties, but do not seem to have a service used in conjunction with the Google policy service to align with a particular compliance framework or respond to alerts. You can, of course, create the policies you need using the above tools to map to your compliance needs or use a third-party CSPM tool that will do this for you. The tools I have tested sometimes work better in one cloud or another, so make sure you test them out first to make sure they meet your needs. Many offer a free trial.

Pros and Cons of Third-Party Tools

Hopefully that overview will help you if you started in one cloud and are moving to another. This also helps you understand that even if you were to purchase a tool that claims to help you with multi-cloud security, under the hood it needs to create the policies to secure your cloud system in three different ways. And in fact, you could create those policies yourself, if you wanted to do that.

Using a third-party tool will likely save some time, but you’ll need to assess the security of that tool. You are giving that tool access to your cloud accounts and knowledge of the vulnerabilities and misconfigurations that exist in them. Evaluate the access and control you need to give the tool. All these things are important so you don’t end up with another SolarWinds scenario where a compromised vendor provided malicious actors access to many cloud and email accounts.

Determine if that tool actually does what it claims to do. Ensure that it doesn’t place undue burden on your teams or applications. Ensure that the tool finds what you need it to find without producing too many false positives. Make sure you can turn off alerts that are not applicable to your organization. Consider the cost of any resources the tool needs to create to function properly.

Some things change. Some things stay the same.

I’ve written here about how these cloud services work today but they are constantly changing and improving; Case in point, Azure AD is being renamed Entra ID. When one cloud service adds a feature the others add it sometimes soon after. What for updates from the cloud providers. Also, put in feature requests for services you would like to see added.

These are not the only security controls available in these cloud environments, these are the tools specific to creating policies that will prevent egregious misconfigurations. Beyond these tools you can use other security and governance services like IAM, encryption, network, and security monitoring services from each cloud provider to help you maintain security in your account.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab
Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation
Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab
AWS
Azure
Gcp
Governance
Cloud
Recommended from ReadMedium