Enhancing Security with Conditional Access for Workload Identities

Microsoft enables us to secure our service principals using their Workload Identities Premium license. In this blog, we’ll explore the potential risks associated with workload identities, how to analyze sign-in logs to identify threats, and strategies for mitigating those risks. We’ll also provide a step-by-step guide to setting up monitoring, including a KQL query to help summarize IP usage by workload identities. 

What are Workload Identities? 

Workload identities are non-human identities (NHI) used by applications, services, and automation tools to access cloud resources. Unlike user identities, these operate autonomously, often with privileged access to critical services and data. For example, a service principle that is used each day to take a backup of mailboxes. The application makes a weekly connection via the Graph API to collect the necessary data.  

Workload identities are an effective way to provide permissions and authentication for automation or applications, but they come with certain risks that need to be addressed: 

• Compromise of application secrets: If an application secret is leaked or compromised, a threat actor could use it to authenticate. 
• Limited Conditional Access protection: By default, workload identities are not covered by Conditional Access policies, leaving them unprotected against specific access controls. 
• Lack of Visibility: Traditional monitoring often focuses on user accounts, leaving workload identity activities overlooked. 

How Conditional Access Addresses These Risks 

Conditional Access policies for workload identities introduce the same principles applied to user accounts. By enforcing contextual conditions such as network location and risk assessment.  

• Limit Access: Restrict workload identity access based on conditions like IP range, ensuring only trusted environments are allowed. 

Enhance Visibility: The Workload Identities Premium license includes the same risk-based detections found in the Entra ID P2 license, allowing you to strengthen sign-in security with risk-based policies. 

Implementation Steps for Conditional Access 

Getting Insights 

The most challenging aspect of configuring Conditional Access policies for workload identities isn’t creating the policy itself—it’s the necessary analysis to determine whether you can restrict the service principal without causing disruptions. Many workloads are used by third parties hosting their infrastructure in public cloud environments, where IP ranges frequently change or may be too large to manage effectively. 

First, we need to ensure we have the necessary logs for our analysis: 

1. Navigate to entra.microsoft.com > Monitoring & Health > Diagnostic Settings. 
2. Verify that the ServicePrincipalSignInLogs checkbox is enabled. 

Figure 1: Enabling ServicePrincipalSignInLogs 

Enabling this setting ensures that sign-in logs are collected in our Log Analytics workspace, allowing us to analyze them using KQL. 

Important: If this checkbox was not previously enabled, logs will only start generating from that point forward. I recommend collecting at least 30 days of log data before analyzing sign-in behavior for meaningful insights. 

Analyzing Logs with KQL 

Once your logs are flowing into the Log Analytics workspace, you can use Kusto Query Language (KQL) to analyze activity and uncover potential anomalies. Go to  entra.microsoft.com > Monitoring & Health > Diagnostic Settings.  

This simple yet crucial KQL query provides an overview of which IP addresses each service principal is active from, as well as the number of sign-in activities observed. 

AADServicePrincipalSignInLogs 

| summarize SignInCount = count(), IPs = make_set(IPAddress) by AppId, ServicePrincipalName 

Figure 2: KQL Results 

Now comes the challenge—these logs capture sign-ins from all Enterprise Applications, but Conditional Access can only restrict service principals that belong to our tenant, meaning those with an app registration in our environment. Unfortunately, there is no direct KQL field to determine whether a service principal is created within our tenant or originates externally. 

                                                                                      Figure 3: finding applications we can target 

Based on the results above, we have three scenarios: 

• Purple Crossed Out (Not an App Registration): 
  This service principal is not owned by us. Since Conditional Access policies apply only to our own app registrations, we cannot directly restrict these applications.  

• Green (Restricted Access Feasible): 
  The app “olva-phished-test” has accessed our environment from a single address over the last 30 days. Since this falls within a manageable range (for me, up to seven IPs), Conditional Access can be used to restrict access to only these IPs. 

• Red (Too Many IPs for Restriction): 
  Another application that we own is signing in from a large number of different IP addresses. While these addresses belong to known Azure IP ranges, their sheer volume makes it impractical to enforce IP-based restrictions through Conditional Access. 

I can attempt to restrict the "olva-phished-test" app to access my tenant only from the identified IPs. However, it's important to understand that if the app attempts to sign in from a new IP address, it will be blocked, potentially causing disruptions. This emphasizes the fine line between enhancing security and minimizing operational impact. To reduce this risk, you can ask your application owner or any third parties using your secrets to provide a list of possible IP ranges. 

Create a named location 

First, we need to create a Named Location. Named locations in Entra ID allow us to define IP ranges, which can then be used in Conditional Access policies. 

1. Go to entra.microsoft.com > Conditional Access > Named Locations. 

Figure 4: creating a named location 

When creating the Named Location and adding the IP addresses, it’s important not to mark these IP address ranges as a trusted location. Trusted named locations are likely used in other Conditional Access policies, and marking them as trusted could introduce conflicts or unwanted behavior. This would compromise the security hygiene of your policies, so it’s best to keep them as non-trusted for this specific use case. 

Create the CA policy 

When you have a Workload Identities Premium license, you will see when creating the CA policy that you have a new option to select workload identities. 

Figure 5: new option to select workload identities 

Here’s an example of how to restrict an app from accessing your tenant, allowing it only from an IP address you define.

                                                     Figure 6: example config of block from non known location            

While the policy above is just one example of what’s possible, you now have the full power of Conditional Access at your disposal. This allows you to ensure that your workload identities remain within the boundaries of what is permissible according to your CA policies, giving you better control and security over your environment. 

Conclusion 

Workload identities are a critical component of modern cloud architectures, but they also pose significant security risks. By implementing Conditional Access policies and monitoring their activity, organizations can significantly enhance their security posture. Setting up a Log Analytics workspace and using tools like KQL for analysis provides actionable insights into workload identity behavior, enabling proactive threat mitigation. 

Questions about securing Workload Identities in Entra ID? Post a question on our AppGov Community Forum, and Microsoft MVPs like Louis will weigh in!