As adoption of Azure Information Protection continues to accelerate, the need for visibility into who has accessed your protected documents remains consistent. Although we provided a tracking portal that required the classic AIP client, the response showed that it rarely met your needs. Much of the feedback focused on the lack of control over the data displayed to users and administrators. Some of you expressed concern about the oversharing of data with end users (i.e. the location of the person who opened or tried to open the document), while others requested the ability to filter labeling activity by region.
Another limitation of the tracking portal was that it required users to manually register each document they wished to track. Given the effort involved to track a file, the feature was seldom used which lead us to remove it from the Unified Labeling (UL) client. But not to worry. Beyond the solution outlined in this blog, there are plenty of other reasons why you should migrate to the UL client today.
Now, some good news: Given the recent integration between AIP audit logs and Azure RMS logs, you now have an opportunity to build your own custom AIP tracking solution for both users and administrators.
In this 3-part blog series, you will learn how to:
- Create a custom AIP Tracking portal for end users
- Create a custom AIP Tracking portal for Security and/or Compliance administrators
- Notify end users and/or Security professionals when access to a protected document is denied
Let’s begin with the AIP Tracking portal for end users. This blog will focus on the steps to build your own portal and present the desired data to the right users.
Let’s look at the concept solution.
The concept solution is quite simple. For this example, we used an ASP.NET front end with Azure AD integration and two Azure Functions to query our Log Analytics (LA) Workspace.
Some notable points:
- You may use a single Azure Function. But to not upset any micro-services architecture deities, we decided to keep them separate.
- To quickly test the solution in your environment, you can do so without Azure Key Vault. If you don’t have AIP data, any other accessible LA Workspace will do.
- Because the Service Principal has the required permission to read the audit data, there’s no need to provide end users access to the LA Workspace.
- Lastly, Azure Function is not required to connect to the back-end REST API, but we found it allowed more ease and flexibility. Feel free to pick your favorite method.
Let’s unpack the solution a bit and explore all its components starting from the back-end data layer.
- Data Layer – As above diagram illustrates; AIP labeling data is stored in a LA Workspace. You can learn more about it here.
- Logic/middle Layer – This part of the solution is comprised of 4 separate components (Azure Functions and Key Vault are optional for testing but recommended in production):
- An Azure AD application (Service Principal) that has Log Analytics Data Reader permission on the AIP Log Analytics Workspace.
- Two Azure Functions
- An Azure Function that makes use of the Service Principal (SP) to connect to Log Analytics via REST API and return the list of protected documents for the current user.
- A second Azure Function that makes use of the Service Principal to connect to Log Analytics via REST API and returns the list of activities for a selected document.
- Azure Key Vault to protect all necessary secrets (Workspace ID, Client ID, and App Secret).
- UI Layer – For this solution, we used an ASP.NET Web application with Azure Active Directory integration for authentication.
Let’s look at the configuration settings for the solution components within Azure.
First, here is a look at the settings for the Service Principal in Azure AD. Notice we had to provide Data.Reader access to our Log Analytics Workspace.
Follow these instructions on how to create a Service Principal in Azure.
Here is a view of the two Azure Functions we created.
Then we stored the Workspace ID, SP Client ID, and SP Client Secret in Azure Key Vault as shown below.
We then configured both Azure Functions to get the required secrets from Azure Key Vault. Please check out Jeff’s excellent blog post on how to set this up. Please don’t skip the part about using managed identities for Azure Functions.
Now let’s look at some code, shall we?
With the above components configured, it’s now time to put them in use and see if everything works as expected.
The first step is to write the code for the Azure Function that will retrieve the list of protected documents for a given user email/ID. I used Visual Studio 2019 to create both Functions, but you can leverage VS Code and other tools.
IMPORTANT: This is a concept application and therefore has no error checking or any of the other enterprise grade optimizations you would need on a production solution.
We start by retrieving the required secrets from the Function’s variable setup above.
You then need to setup the code required to authenticate to the Log Analytics Workspace. This code was borrowed from the Log Analytics API site.
Finally, you configure and update your Kusto query with the email address of the current user and call the Log Analytics endpoint. Please look at the Log Analytics API link above to see the JSON response sample. In this case we are just returning the first table.
Now you can run the Function in Visual Studio to make sure you code is talking to the back-end as expected. If you pass a user email from your tenant on the “name” parameter, you should see some JSON data returned on the browser. Happy times. Your solution is setup and ready to be hosted (in the cloud of course).
Once you confirm that your code returns the desired data, you are ready to publish to Azure. Follow these instructions to learn about publishing Azure Functions from Visual Studio into an Azure Web Service.
You can now repeat these steps to create your second Azure Function making sure you pass the selected document instead of the user email.
Finally, let’s look at the user facing front end application. For this example, we created a simple ASP.NET web application right from a Visual Studio template. You can use a low-code/no-code solution like PowerApps of course but we’ll leave that one up to you.
As shown below, the very talented design staff at Contoso put together this elegant UI to display a list of recently protected documents by the authenticated user.
Upon clicking on the “Track File” button next to each document, a list of activity for the file is display right below.
At this point the file owner can see the list of users who have successfully opened (Access) and those who were denied access (AccessDenied) to the document.
That’s all there’s to it. You can find the source code used in this sample in this GitHub repo.
We hope this walk through has sparked some ideas for your own solution to get label activity into the hands of your users. If you do or plan to use something like this in your own environment, we would love to hear about it. Please visit the AIP Yammer group and share your thoughts/solution with the hashtag #AIPLogsSolution.
Thanks for your reading and stay tuned for the second installment of this series. Happy coding.