With more companies extending their environments to include Cloud Services and Cloud functions it is important to recognize how the users and privileges are defined and managed within these extensions. This is the first in a series of posts to investigate what this means for Identity Management throughout the Azure cloud.
To start with, what is meant by an Identity?
Originally a user’s identity was just an on-premise user object. This is what allowed them access to resources based on what rights were granted based on permissions. Over time functions such as groups, nesting, and claims based authentication were developed to improve these functions. Initially this helped organizations manage their user base and secure their resources. As on-premise environments got more complex, managing this access also go more complex and harder to control. Eventually concepts started to evolve and in today’s IT world identities have shifted from permissions to recognizing the role that a user has in the environment.
This evolution has drastically changed how thinking about identities is done. Instead of looking at individual user objects and accounts in regards towards what permissions they have, there needs to be a more directed review of what permissions a Role needs, and how to manage the user object or identity in relation to the role and responsibility without granting any more privileges than needed. Then securing the environment through the management of these roles.
The evolution of environments to incorporate cloud services has simply extended these concepts to include this new extension of the environment. The critical difference is that in the past, access was physically protected through controls such as requiring systems to be on the network, or through firewalled access. With extension into the Cloud this has shifted the security boundary from one of physical accessibility, to one of identity management. All of which will be discussed in future posts.
Azure Cloud vs. Services and Resources
Now that we have addressed what an identity is, what is it good for? Knowing who the person is does us no good if we don’t know what to do with them. So, it is important to understand the environment that the identity exists within. In this second post, we will look at Azure itself as a Cloud and the associated Services and Resources associated with it.
Azure is simply the brand name for the Microsoft Cloud concept. Clouds function relatively the same across the board. Here is an OSI model (Azure specific) of a Cloud concept.
As can be seen there are differences between the Azure functions and resource or service functions. These differences are central to identifying the tools used to manage the Azure Cloud environment, as well as defining the roles and responsibilities for each foundational layer, as well as for each service and resource. The good news is that these roles are easily customizable, and manageable, from the Layer 3 centralized services since they use a single identity source (Azure Active Directory).
By recognizing the separation of services, resources, and foundational requirements an organization can define their administrative and support roles to fit their business needs. This also allows for a more concise governance document and granular management of access. It should also be noted, that more than one group, team, or user can be part of multiple roles, and that a single role will have multiple permissions associated with it. Which will lead us to the next post in this series – Roles vs. Groups.