Identities of groups or teams in the past and the ability to grant them access has been continually evolving. Initially a team or group would be identified, and their rights granted through individual access controls (ACL).
As groups, Global, Local, and Universal, were integrated into the language and base design of Active Directory, the ACL’s could be granted to a group and then several users and groups could be added as members. This developed the nested group model.
As can be noted in the images, the IT Contingency Support team, consists of the IT Data Center Team, which contains the IT Cloud DevOps team, and the 12 users that are members of that group. So, any rights granted to the IT Contingency Support team will automatically be granted to these 12 users, and any other groups or users added to these other groups.
It is obvious from this, as to how complicated, and intertwined this can get. Especially over time if it is not managed and documented properly. This is also why groups, which are a very established concept, often get misconstrued as Roles, or are otherwise attempted to be used in the same fashion. In a small organization, this works. However, as organizations get more complex, or as they extend to the Cloud the concept of a group and a role needs to be recognized and defined. This is the difference between resource management (Groups) and security (Roles).
A brief summary of the difference is that a Role is a way to organize rights, while a Group is a way to organize Users.
This has resulted in several applications that exist to assist in easing the management of on-premise Roles and Groups. As well as a few different ways to use the default tools that exist in Active Directory to build these out the same. When extended into the Cloud structure though, these on-premise tools no longer exist. Therefore, it is important to plan out and develop a roles and responsibilities portion of the environmental governance documents.
Once the Roles are known, it is now a matter of implementing them both in the on-premise environment, and in the cloud.
In summary, it is important to define the roles that exist in an organization. This decision will dictate the permissions needed for each role and what they do. The next post will look at using both groups and roles.