Understanding Azure Log Analytics query auditing

In this post, I will talk about Azure Log Analytics and query auditing capabilities. I may cover the use cases in an article later, expanding on why this functionality matters. There are many common use cases in legislation, regulatory compliance, and monitoring, but that's for another time.

Here's what to expect from this short post:

• What are audit logs?
  • Audit logs vs. Logging
• How to: Configure Log Analytics query auditing

What are audit logs?

Audit trails, or audit logs, are records that chronologically catalog events or procedures.

For the initial brief, I will leave you with the first paragraph from Wikipedia, and a link to the full article.

An audit trail (also called audit log) is a security-relevant chronological record, set of records, and/or destination and source of records that provide documentary evidence of the sequence of activities that have affected at any time a specific operation, procedure, event, or device
- https://en.wikipedia.org/wiki/Audit_trail

Granted, each situation is unique, and the reason and implementation of audit logs will differ. However, the gist remains the same - chronological records of important events that you can later review.

Audit logs vs. Logging

The definition of auditing versus logging can be very different depending on your situation.

Mostly logging has to do with the application-level events, like administrative actions, custom logic in the applications, exceptions, and traces, anomalies being detected, and any relevant health information about the systems and applications.

Audit logging, however, usually means user-level transactions; When an individual, or an identity in Azure, for example, makes a change to a system.

To put this into the context of Azure Log Analytics queries, having auditing enabled means you can see what queries have been executed, and by whom.

Depending on your industry and regulatory compliance, legal requirements, and other data processing guidelines, you may also have an obligation to maintain the audit logs for a period of time that extends beyond the life of the application. This is also heavily dependent on what type of data you are auditing.

I see a lot of implemented systems having both application logs and one or more audit logs, with separate access layers and storage locations. For good reason.

Configure query audit logging

Let's cut to the chase. You want to enable audit logs for queries in Azure Log Analytics. Here's how.

From the Azure Portal, go to your Azure Log Analytics Workspace, then click "Diagnostic settings":

If you have an existing audit configuration, you can modify it. Otherwise, click "Add diagnostic setting":

From Diagnostic settings, tick the Audit boxes and then specify a destination for the audit logs.

In my case, I'm sending them to a different subscription into an audit workspace that is only accessible to authorized compliance personnel.

The configuration of the audit logs is done, and I can see that queries I just ran are showing up in the audit log workspace. You can, of course, select to ship these audit logs to another type of destination as per the diagnostic settings dialog.

Put it to the test

With the Log Analytics workspace I just configured for audit logging, new queries will be logged to the audit log. Let's take this for a spin.

Run a query in the audited workspace

I will make a very basic query to just list some information about recent requests:

requests
| where timestamp > ago(2h)
| where  operation_Name =~ 'OrchestratorFunction'
| extend OriginatingSource = tostring(customDimensions.["Source"])
| order by timestamp desc

The query is just returning the data, as expected:

Request information from the audit logs

In the workspace you're shipping the audit logs to, you can see there's a new table LAQueryLogs. Pulling out the data from this table brings the results from my test queries in. We have success.

Additionally, I can now pull out information from the audit log for specific users, applications, workspaces, or anything else.

The results of the audit query return all rows with a set of fields, including the QueryText.

Columns worth making note of include:

• TenantId - Where did this query take place?
• AADObjectId - What's the ObjectId of the identity executing the query?
• AADTenantId - What is the Azure AD tenant ID of the identity executing the query?
• AADEmail - The e-mail address of the identity executing the query.
• AADClientID - The Client ID of the identity executing the query.
• QueryText - Perhaps the most interesting one, where you can see the actual query that was executed.

There are more data available, but for me, these are the key aspects to understand and query for, for my situations.

Thanks for reading. I hope you found it beneficial - please leave a comment, I appreciate those!