Monitoring Privileged Identity Management
We’ll learn how to utilize Azure Active Directory (Azure AD) Privileged Identity Management (PIM) for monitoring and viewing activity, activations, and audit history for Azure resources roles in your business in this lesson. Privileged Identity Management’s security and lifecycle management features are available to any resource in the Azure portal that has the Azure role-based access control functionality.
Monitoring Activity and Activation
For monitoring what actions a specific user took in various resources, you can view the Azure resource activity that’s associated with a given activation period.
- Firstly, open Azure AD Privileged Identity Management.
- Secondly, select Azure resources.
- Then, select the resource you want to view activity and activations for.
- After that, select Roles or Members.
- Fifthly, select a user.
By date, you may obtain a summary of the user’s Azure resource activity. It does, however, provide recent role activations throughout the same time period.
- Lastly, select a specific role activation to see details and corresponding Azure resource activity that occurred while that user was active.
Exporting role assignments with children
You must have compliance requirements in which you must provide a complete list of role assignments to auditors. Privileged Identity Management allows you to query role assignments at a single resource, including all child resources’ role assignments. Previously, however, administrators found it impossible to obtain a comprehensive list of role assignments for a subscription.
They also had to export role assignments for each resource separately. However, you can now query for all active and eligible role assignments in a subscription, including role assignments for all resource groups and resources, using Privileged Identity Management.
- Firstly, open Azure AD Privileged Identity Management.
- Secondly, select Azure resources.
- Then, select the resource you want to export role assignments for, such as a subscription.
- After that, select Members.
- Then, select Export to open the Export membership pane.
- Lastly, select Export all members to export all role assignments in a CSV file.
View resource audit history
Resource audit provides you a view of all role activity for a resource.
- Firstly, open Azure AD Privileged Identity Management.
- Then, select Azure resources.
- Thirdly, select the resource you want to view audit history for.
- Fourthly, select Resource audit.
- After that, filter the history using a predefined date or custom range.
- However, for Audit type, select Activate (Assigned + Activated).
- Lastly, under Action, click (activity) for a user to see that user’s activity detail in Azure resources.
View my audit
My audit enables you to view your personal role activity.
- Firstly, open Azure AD Privileged Identity Management.
- Secondly, select Azure resources.
- Thirdly, select the resource you want to view audit history for.
- Then, select My audit.
- Lastly, filter the history using a predefined date or custom range.
Get reason, approver, and ticket number for approval events
- Open Azure AD after logging in to the Azure portal with the Privileged Role administrator role rights.
- Audit logs should be chosen.
- To see just audit events for the Privileged Identity Management service, use the Service filter. You may do the following on the Audit logs page:
- In the Status reason column, look for the reason for an audit event.
- For the “add a member to role request approved” event, look at the approver in the Initiated by (actor) column.
- On the Activity tab of the Details pane, choose an audit log event to get the ticket number.]
- On the Targets tab of the Details pane for an audit event, you can see the requester (the person who activated the role). Azure resource roles have three different target types:
- The role (Type = Role)
The log event immediately above the approval event is usually an event for “Add member to role accomplished,” with the requester as the Initiated by (actor). From an auditing standpoint, you won’t usually need to look for the requester in the permission request.
Reference: Microsoft Documentation