Demystifying Identity and Access Controls
Differences: Identity and access differ in that one is about who you are and the others about what you’re allowed to see or do. If you can prove your identity, that’s called being authenticated. If you can prove you have a right to access something, that’s called being authorized.
When we talk about authentication and authorization, these two steps can seem like they’ reoccurring at the same time, but they are totally separate processes. As software has moved to the cloud, security technologies have become more sophisticated and these twosteps have become even more separate.
Role-based access control, or RBAC for short, is like a barrier between the user and the authorizer. Roles are assigned to users and users can switch between the different roles so that when someone wants to carry out a task, the Authorizer will either allow or deny the task based on her current role.
Privileged Identity Management (PIM) is a very broad industry term rather than a reference to any specific tools. Many analysts, most notably Forrester, use the term ‘PIM’ to refer to all things within the ‘PAM’, or Privileged Access Management, space. PIM and PAM are often used interchangeably to refer to the wider universe of tools and technology that relate to the management, governance, auditing, and lifecycles of all types of privileged access and privileged user credentials.
WHY USE PIM / PAM
With the clarification on terminology aside, any explanation of the Azure PIM tool must first start with a deeper look at Microsoft’s position on identity security.
The idea of identity as a security perimeter is meant to act in lieu of traditional controls placed on the network. The Question then is, if you can be more certain that the user accessing a resource is who they say they are, then do you need other controls in place?
We view this initiative as a natural evolution of Active Directory’s very basic approach to securing user identities (i.e. just a username and a password). Azure AD takes this to the next level with core features such as: Enhanced MFA, including Windows Hello for Business and MSFT Authenticator, Conditional Access: the foundational layer of identity security in Azure AD, Azure PIM and Azure Identity Governance, Automated Threat Response and Cloud Intelligence solutions SIEM, Sentinel, and ATP.
Of these features, Conditional Access is by far the most pervasive feature in the identity stack. If you or your organization leverages Office 365 or Azure AD today, you have most likely worked with, or been subject to, Conditional Access policies. This feature is where Azure AD administrators can define granular, context-based policies which challenge users for things like additional authentication (MFA) depending on where they are trying to authenticate from, or which resources they are trying to authenticate to.
With Conditional Access, you can block connections from locations (perhaps from a country your business), force users to reauthenticate when their connection changes, allow connections seamlessly from managed devices that are compliant with the latest security policies, or many other conditions that administrators can set.
The key to understand for the purpose of de-mystifying Azure PIM is that Conditional Access is an identity security tool that applies to everyone in your organization. Azure PIM then becomes a much more targeted tool in a broad set of capabilities that make up the security policy push for ‘identity as security’.
How Azure PIM Works
Unlike Conditional Access, Azure PIM only applies to administrative roles within Azure and Azure AD. This is an important consideration, both as it relates to ‘administrative’ functions as well as, more importantly, the idea of Azure and Azure AD ‘roles’. Also, unlike Conditional Access, Azure PIM requires Microsoft’s highest license tiers for users that are subject to the tool.
A distilled-down way to describe Azure PIM is that it’s a clever provisioning and deprovisioning utility wrapped around Azure AD and Azure resources to allow for time-bound, or Just in Time (JIT) access instead of standing access.
A good way to understand Azure PIM is to think of what it is coming from: Active Directory Security Groups. In AD, the approach to manage a Security Group is to simply add a user in when they need the privileges associated with that group. If it is a temporary need, then, hopefully, someone remembers to go in later and remove them. This is a accident prone no-frills, manual process that is fraught with opportunities to make a mistake and leave the user as a permanent member of the group. In addition, the user has all the rights and privileges associated with that group 100% of the time while they are a member, even though they may only need those enhanced privileges for a small amount of time. This is the concept of ‘standing access’ that Azure PIM attempts to mitigate.
Azure PIM takes this model and evolves it; the Azure PIM utility within the Azure portal allows you to assign users or groups within Azure AD to become ‘eligible’ for various roles. Eligibility essentially means the user may not have these privileges all the time, but rather for a short period when they opt-in, or ‘activate’ their roles.
A new set of audit records now exist where they did not before in Active Directory; you can now view who activated roles and when. Email alerts are available here as well to fire off notifications when certain roles are activated and deactivated.
Administrators and users of Azure PIM must access and work within the Azure Portal.
Administrators can select users or groups and define their eligibility criteria, such as which specific role and the time period that it applies to.
Administrators decide which roles the assignment pertains to, followed by the time options for the assignment. Permanent eligibility is enabled by default and can be changed to target a specific date range.
On the other side, users navigate to the ‘Azure PIM blade’ within the portal and find their eligible assignments to start the activation process. If successful, the portal will force a refresh once the role privileges are successfully applied.
For anyone who works within Active Directory can attest, this is a big improvement that Azure PIM offers as a utility to manage role membership.
What exists outside of Azure in your environment?
This is the broader question that I believe is worth asking in a planning phase when considering Azure PIM: what in your environment will exist outside of the Microsoft ecosystem, both now and in the future?
Consider that an environment where multiple solutions exist to solve the same problem can often add complexity that a consolidated solution would inherently avoid. In the case of Azure PIM, the guiding principle to understand, if multiple tools might be required, will it be based on what is or is not part of Azure. Think about your own environment:
- What does your workstation environment look like? Are they all Azure AD-joined? What about macOS or Linux devices?
- On the server side, are these devices in Azure?
- Think of data warehousing – which database platforms do you use? How is privileged access managed for these systems?
- SaaS or 3rd-party applications? Can these be integrated into Azure?
- Network switches? Hypervisors? Firewalls? Load Balancers? VPN infrastructure?
- What about 3rd-parties that need remote access into any of these systems? How do you secure that access?
- Is identity the end-all-be-all of security for you? Or just one part of a wider PIM/PAM strategy?
- Other cloud providers : AWS, GCP, Oracle, etc., how do you plan to unify processes and technology across these platforms?
Azures PIM’s scope is bound to Azure, but your privileged access management controls should extend to your entire environment, on-premises, mutli-cloud, etc.
When answering the question of how effective Azure PIM might be for you, I’d ask you to balance what you know about your environment and where gaps might exist, as those gaps would have to be filled by another point solution. It is fairly easy to see where Azure PIM provides value, but it’s important to be mindful of mapping Azure PIM’s real capabilities against what a comprehensive PAM strategy in your organization need to look like.
