A new feature in public preview is the Azure AD access review functionality. With the new AzureAD access reviews function it is possible to review service principals in the Azure environment.
With the more growing trend of cloud services and application service principals it is important to get a good workflow for checking access. For user access to teams the functionally Azure AD access reviews are available for some time. Now in public preview, the functionality extended for the service principals.
In this blog the usage and working of Azure AD access review for service principals and the monitoring with Azure Sentinel.
What are service principals?
An Azure service principal is an identity created for use with applications, hosted services, and automated tools to access Azure resources. This access is restricted by the roles assigned to the service principal, giving you control over which resources can be accessed and at which level. For security reasons it’s always recommended to use service principals with automated tools rather than allowing them to log in with a user identity.
An application registered with an Azure Active Directory tenant has three components:
- service principal: identity object for the service
- App or client ID: globally unique ID for the app
- Application object: globally unique instance object
There are three types of SP available:
- Legacy
- Managed Identity
- Application
Ref: Apps & service principals in Azure AD — Microsoft identity platform | Microsoft Docs
Access reviews
The set-up for service principals access reviews is different than the normal setup for Teams and Office365 groups. For setting up the access reviews:
- Go to Azure AD
- Open Identity Governance
- Under Privileged Identity Managed – open Azure AD Roles
- Under Manage click on Azure AD Roles
- Now open Access Reviews and click New
- During the creation of the access review fil in the Review Name, description, start date, frequency, duration and end date.
- For getting the service principals in scope select the scope (preview) Service Principals and select the role membership (1). Now select the reviewers for the access review (2). If needed enable the completion settings and optionally give the action if reviewers don’t respond in the given period (3).
Extra information: The service principal named AZServicePrincipalSecurity2 is added to the Security administrator Azure AD role.
Now each service principal part of the Security Administrator rule will be checked by the access reviewers group on a monthly frequency.
Result Access Reviews
After creating the initial actions for Access Reviews will be started and sent to the user. For the user assigned as a reviewer, the following actions are visible.
The first action is the mail sent to the mailbox for starting the review action:
From the mail the user can start the review directly. With the direct start the following interface is visible. Here you can find the reviewed Role; given title and the start/ end date. The user can start the access review and fill in the reason for approving or deny the access.
Azure Sentinel / Service Principals
From Azure Sentinel there is the option available to discover the Service principal sign-in events and managed identities sign-ins. All data coming from the Azure AD connector attached to Azure Sentinel.
To reduce misusing of the applications authenticated with Oath2.0 protocol it is important to track the usage and discovery for the service principals. With Azure AD access review good point to start, with Sentinel there is a perfect use case to monitors the activity and sign-ins related to the service principals.
For the data ingestion firstly connect the data connector:
- Open Azure Sentinel
- Go to Data Connectors -> connect Azure Active Directory
- Open the connect page and now select the specific log event: service principal sign-in logs
- After applying it takes some time before events are created in the environment
- For checking the data available use the following KQL query:
AADServicePrincipalSignInLogs
| take 1000
| sort by TimeGenerated
If there are service principals in the environment. You should see the usage of the service principal listed in the results.
Use case analytic rule
With the data, there are multiple options to schedule Analytics Rule if there is an event. In the use case below:
Trigger an event when the sign-in or activity is not from a known IP address for a specific ServicePrincipal application name.
- Open Azure Sentinel with minimal Contributor permissions
- From the Azure Sentinel panel open the Analytics blade under the Configuration section.
- Create a new scheduled query rule
Fill in the following details:
- Name: Fill in own naming, example: Service Principal Anomalous usage outside corporate/application IP
- Description: Explanation of the rule
- Severity: Medium/ High
- Status: Enabled
Next; The Rule logic configuration. The KQL uses the AADServicePrincipalSignInLogs table with excluding the corporate IP address. Detection is based on the ServicePrincipalName.
AADServicePrincipalSignInLogs
| where ServicePrincipalName == “Fill in Service Principal Naming”
| where IPAddress != “Fill in corporate/ app ip”
The KQL gives the following events for the ServicePrincipalSignIn Logs focused for the AZServicePrincipalSecurity2 Service Principal.
If needed use Entity mapping for mapping the correct information together.
Simulate the alert creation
Now simulate the specific alert configuration. To trigger an alert, you need to sign in with the Service Principal from a new IP.
With the result: incident created inside Azure Sentinel with the needed information and Analytics Rule naming.
And the Azure Sentinel investigation view:
Sources
Microsoft: Introducing Azure AD access reviews for service principals
