Identity

Hierarchy

Privileged Identity Management

Privileged Identity Management provides time-based and approval-based role activation to mitigate the risks of excessive, unnecessary, or misused access permissions on resources that you care about. Here are some of the key features of Privileged Identity Management:

• Provide just-in-time privileged access to Azure AD and Azure resources

• Assign time-bound access to resources using start and end dates

• Require approval to activate privileged roles

• Enforce multi-factor authentication to activate any role

• Use justification to understand why users activate

• Get notifications when privileged roles are activated

• Conduct access reviews to ensure users still need roles

• Download audit history for internal or external audit

• Prevents removal of the last active Global Administrator and Privileged Role Administrator role assignments

Access Review

• To review the role whether it is still applicable or not

Conditional Access Policies

• To require the specific groups of user or apps to grant or block the access, such as require multi-factor authentication

Resource Lock

• To create read-only / delete lock on the resource to restrict the action

Managed Identity

• It provides the ways for resource to access another other resources

• Once connect the resource with managed identity, and then assign the role to managed identity, the application can access other resource based on the role

• There are 2 types

• System-assigned: Can’t be shared. It can only be associated with a single Azure resource. Workloads that are contained within a single Azure resource. Workloads for which you need independent identities. For example, an application that runs on a single virtual machine.

• User-assigned: Can be shared. The same user-assigned managed identity can be associated with more than one Azure resource. Workloads that run on multiple resources and can share a single identity. Workloads that need pre-authorization to a secure resource, as part of a provisioning flow. Workloads where resources are recycled frequently, but permissions should stay consistent. For example, a workload where multiple virtual machines need to access the same resource.

Application object

• It is representation of the user containing certain roles

• When applied application object to the application, the application can access the resource that include on the user role

Policies

• Set the policies up to management group level to limit the access, enforce some of the action

Blue Print

• To define the deployment including ARM Templates, policies, resource groups and role-based access control

• To assign the definition up to an existing management group or subscription level