Nesting Azure Active Directory Security Groups:

Role-based access control aka RBAC is a technique for granting access to resources based on roles assigned to users. Both roles and resources are independent of each other and so are the security principals who could be users or groups. Groups help to manage RBAC assignments so that users can be added to or removed from groups without changing the assignments. Roles, groups, and assignments are used to control access to resources and are often created only as many as necessary.

Some examples of roles include owner, contributor, and reader roles. These are universally applicable to users and groups across resources. When the current practice involves creating an Active Directory group for the purpose of controlling access to a specific resource, organizations tend to generate a lot of security groups. While resources can also be grouped and roles assigned to the scope of resource groups, it is likely that those resources have independent use cases which makes proliferation less likely to avoid.

Two techniques come to the rescue of the business to tame the number of groups, roles, and assignments. First is the use of a custom role and the second is the nesting of groups.

The custom role is inherently an entitlement to a collection of permissions. These permissions must be included based on least privileges required and cover as many permissions as necessary to facilitate one or more use cases. Since a use case could involve multiple resources, the permissions in the set could be a mixed lot. The higher the scope the more the number of resources and thereby more mixed the set of permissions. By being more inclusive in the customization of roles and assignments, we come up with definitions than those with built-in definitions from the resource providers.

Some people like to keep the permissions independent even for customizations because they can be assigned to different resources with the notion that one resource can be done away with while the other persists longer. This can arise from changing business needs where ownership and operations are no longer managed together. Besides, the resource grouping is generally done purely from the point of view that resources in a group will have the same lifetime and that deletion of the group will remove all the resources. Expansive roles and combining resources can therefore require different security groups for each even for the same set of users. One way to manage this is to treat two sets of security groups as one requiring another. One security group allows the users to be grouped and the nesting of one group into another gives those same users the roles and permissions necessary to complete their use cases. Nesting of security groups might not have been allowed on-premises, but it is most likely, allowed in the cloud.

The permission sets must also have some categories as they cannot all be privileges that allow access. Some must be called out as deny-permissions to clearly demarcate the utility of the custom role. Similarly, the permissions for control and data path must be called out independently of one another. There can be other categories as well, but these are widely used.

Lastly, there are several ways to organize hybrid entities but order and method help to make it easier. Also, prioritizing the use cases and determining the impact that they have, help to address the most important ones rather than cover all. Also, maintaining a sorted order of high to low privileges or being mindful of grading with each articulation and organization, helps to be exhaustive where necessary.