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.
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:
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:
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:
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:
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.