In the first installment of this 3-part blog series, we showed you how to create a custom AIP tracking portal that allowed end users to see access activity for their protected documents.
Today’s blog will focus on how you can empower your security and/or compliance professionals to access AIP labeling activity by other users within your organization. But, with an added bonus. The sample solution demonstrates how you could ensure that only the right administrators have access to user’s labeling data and within the right country or region.
For today’s scenario, we will introduce you to three personas within the Contoso organization.
First, a bit of context about the company: Contoso is a multinational organization with offices across Europe and the United States. Due to GDPR as well as internal regulations, Contoso needs to make sure that compliance administrators are not able to see AIP labeling data for users outside their own country or region.
And now let’s meet the personas involved.
- Persona 1: Alex Wilber – Alex is a Contoso employee who works out of the Munich office in Germany
- Persona 2: Diego Siciliani – Diego is a Contoso employee who works out of the Bellevue office in the United States
- Persona 3: Adele Vance – Adele is a Compliance professional at Contoso who works out of the New York office in the United States
As you’re probably aware by now, AIP stores all labeling activity in a single Log Analytics Workspace within a selected region. Although there we provide ways to restrict access to this data via RBAC, it’s an all or nothing proposition. If you grant an administrator reader’s access to the logs, that administrator will be able to see all logs by all users despite the user’s location. Log Analytics API however, gives you more control on what data you present to a security or compliance professional as you’ll see below.
Let’s look at the requirements. This solution is very similar to what we used on the previous user portal so please refer to our first blog for more details.
At a high level however, you need:
- An application registered within Azure AD (service principal)
- The service principal needs access to the Microsoft Graph
- Azure Function
- Log Analytics Workspace
- PowerShell to test the solution
Let’s look at some snippets of the code we used.
Like the previous user portal solution, we are leveraging an Azure Function but in this case there a couple of new features you would want to pay attention to. In this example, Adele Vance (compliance professional) wants to get a list of AIP files that were protected by Diego (end user).
To comply with Contoso’s policy, we need to make sure that Adele is authorized to access Diego’s AIP labeling activity. To that end, the Function expects to receive the email address for both Adele (admin) and Diego (user). Once the Function receives those two values, it calls the Microsoft Graph to 1) verify Adele’s rights by checking her group membership and to ensure both users are located within the same country.
IMPORTANT: While there are plenty of other ways to ensure that Adele (admin) is authorized to access Diego’s AIP audit data, we opted for the more traditional approach of checking her group membership.
Let’s begin by getting an AccessToken that we’ll use to call the Microsoft Graph.
Here we save the user and admin’s email addresses into separate variables and obtain an AccessToken.
We then make the following calls to the Microsoft Graph:
- Get the user’s country
- Check group membership for the administrator
- Get the administrator’s country
In this example, we created a security group for all compliance administrators in Germany and added Adele as its only member.
IMPORTANT: For a production solution, you would need to make sure you handle situations where the country field is not populated. You may also want to consider comparing against a list of countries or regions.
Now that we’ve made sure that Adele is a member of the right group and is in the same country as the user, we proceed to query Log Analytics for the user’s AIP activity. If either of the above requirements are not met, return a custom message to compliance professional. A recommended enhancement to this flow is to notify other administrators if there’s a failed attempt due to insufficient access.
The code below is used to query the Microsoft Graph and confirm that the administrator is member of the desired group by using its object ID from Azure AD. For a production grade application you would need to implement additional logic to determine admin access to user’s data. Additionally, you may want to verify the admin’s group membership and office location from a fronted web or mobile application.
IMPORTANT: This step is using the contact information in the Microsoft Graph. However, you can call any other system (ERP, etc.) to obtain this data.
This code takes a user’s email and a Graph access token to query the Microsoft Graph and retrieve the user’s country property.
Once everything checks out, we pass the user’s email address to the below code and retrieve the desired AIP activity.
You now have an Azure Function configured and ready for testing. Follow this link to publish your Function to Azure from Visual Studio.
Now let’s test your solution.
To change things a bit, we are going to provide a way to test your Function via PowerShell. First, get your Function’s URL and default Key:
Navigate to your Function in the Azure Portal and click on the Function name (Function1 in this case). You then click on the </> Get function URL link as shown below.
From the pop-up screen, copy the URL value into Notepad or your application of choice.
Finally, let’s run some PowerShell. Populate the following values:
- $AzSubscriptionId – Your Azure Subscription ID where the Function and Log Analytics are hosted
- $userId – The email for the user whose AIP activity you want to search
- $AppName – The name of the application created when you published the Function to Azure. - e.g. https://<APP_NAME>.net/...
- $FunctionName – “Function1” in this example
- $FunctionKey – The key at the end of the URL value from the previous step
- $adminEmail – the email address of the compliance professional
From the PowerShell ISE, run the code above. As a security or compliance professional (Adele in this case), enter your username and password.
If all requirements are met and we find data for the provided user, we return it as shown below.
If one or more conditions are not met, you should see the custom message configured in the Function as shown below.
At this point you may be asking what if I want to search for a document instead? Well, you can use the same app and add a few tweaks to it to accommodate a document search.
For example, you could:
- Pass a document name to the Azure Function
- Have the Function query Log Analytics for the desired document
- Get the Protection Owner (user’s email address) from the AIP activity on the document
- Call the Microsoft Graph and get the user’s country
- Finally, modify the Kusto query to return a list of documents
For now, I will leave that enhancement to your very capable hands.
As you’ve seen above, we demonstrated how to create a custom solution for your security and/or compliance administrators to quickly view AIP labeling activity by a user. We also showed the ability to restrict access to AIP audit data to the right administrators and only within the desired country or region.
Although we used PowerShell as the frontend today, you can of course create a web app to call the Azure Functions API. You should be able to reuse the portal created on our previous post and you can find the sample code in this repo.
The source code for this Function can be found in this GitHub repo.
Please stay tuned for our third and last installment of this series where we will show you how to notify users and/or admins when an AIP Access Denied event is received in your Log Analytics Workspace.
Thanks for reading and please keep your feedback coming via the AIP Yammer group using the hashtag #AIPLogsSolution.