In this piece, I'll discuss Azure Log Analytics' query auditing capabilities. I may write a post about the use cases later, explaining why this capability is important. There are numerous common applications in law, regulatory compliance, and monitoring, but that is for another time.

Here is what you can expect from this short post:

• What are audit logs?
• Audit logs versus logging
• How To: Configure the Log Analytics query auditing.

What are audit logs?

Audit trails, often known as audit logs, are records that document events or procedures in chronological order.

Granted, each case is unique, and the purpose and implementation of audit logs will vary. However, the gist stays the same: keep chronological recordings of relevant events for later examination.

Audit logs vs. Logging

Depending on your situation, the definitions of auditing and logging may differ significantly.

Logging is primarily concerned with application-level events such as administrative operations, custom logic in applications, errors and traces, abnormalities identified, and any pertinent system and application health information.

Audit logging, on the other hand, typically refers to user-level transactions, such as when an individual or an Azure identity modifies a system.

To put this into context with Azure Log Analytics queries, having auditing enabled allows you to know which queries were conducted and by whom.

Depending on your industry and regulatory compliance, legal requirements, and other data processing norms, you may also be required to keep audit logs for a longer amount of time than the application's life. This also depends largely on the type of data being audited.

Many implemented systems have both application and audit logs, with separate access layers and storage locations. For a good purpose.

Configure query audit logging

Let us cut to the chase. You would like to activate audit logs for queries in Azure Log Analytics. Here is how.

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

You can alter an existing audit configuration. Alternatively, select "Add diagnostic setting":

Check the Audit boxes in the Diagnostic settings, and then pick a location for the audit records.

In my scenario, I'm redirecting them to a different subscription within an audit workspace that is only available to authorised compliance workers.

The audit logs have been configured, and the queries I just ran appear in the audit log workspace. You can, of course, choose to transmit these audit records to another type of destination using the diagnostic settings dialogue.

Let's test it.

New queries will be logged to the audit log using the Log Analytics workspace that I recently created. Let's take it for a spin.

Run a query in the audited workspace

I'll create a simple query to list some information about recent requests:

The query is just returning the data, as expected. Observe your output.

Request information from the audit logs

There is a new table named LAQueryLogs in the workspace to which the audit logs are being shipped. Pulling data from this table returns the results of my test queries. We have succeeded.

 Furthermore, I can now extract data from the audit log for specific users, programmes, workspaces, or anything else.