“Identity is the new perimeter“. If you have not heard of this phrase in the recent days, you have a lot of catching up to do with cloud security. I will leave you to it. In this post I am going to talk about a segmentation strategy that is suggested as a part of Microsoft’s Well-Architected Framework. The days when all that segmentation meant was about Networks are long gone. Segmentation at different levels help in creating a defense in depth.
Resource Entity Hierarchy
To be able to segment your cloud workloads you need to have a well-defined resource entity hierarchy. The word may sound like a jargon, it isn’t. The simple but effective mechanism of arranging the cloud resources in a hierarchy that helps in further exercising Governance in the best possible way. The following picture depicts a sample entity hierarchy.
Segmentation & RBAC
You should recreate the same for your cloud setup. Now that you have the hierarchy ready, it is important to
- Understand the segmentation options
- Design the RBAC mechanism to align with the segmentation strategy
The modified version of the same picture now shows the segments in the following places
- The red-colored horizontal lines show the segmentation between the logical constructs of resource organization. You have segmentation between management groups & subscriptions and between subscriptions and resource groups. The vertical arrow shows the direction of flow of hierarchy
- The green-colored lines and arrows show the segmentation between a) environment of operations i.e., Dev and Prod and b) Application based boundaries via resource groups.
To assign the necessary permissions (or) privileges to Users/Groups/Service Principal/Managed Identities following Least-Privilege principle aka Just Enough Access (JEA), the assignments have to be done at the most appropriate level.
Note: One key point in designing the RBAC permissions is that managing granular permissions becomes an overkill and the best suggested practice is avoid it whenever possible. At the same time, assigning elevated privileges to all at a management group level is a security blunder that you don’t want to be doing.
The idea here is to create a diagram with some of the important groups (collection of users) being assigned elevated privileges and be placed at the appropriate level in the hierarchy. This helps in visualizing the amount of access the group would have. Two examples have been shown, one at the root management group level and another at the resource group level. The role and associated permissions assigned at the root management group level flow down the elements in the hierarchy. Be mindful of this. Also, if there is uncertainty if the role should be assigned at one of the top levels and if you are providing permissions more than what is necessary, gather the permissions chart or a subset of it from the azure portal and place beside the management group in the picture. This helps in evaluating the assignments and also would help you decide if you need a custom RBAC role.
#AzureGovernance #AzureSecurity #IAMWithRBAC #ResourceEntityHierarchy