Who accessed my Azure Key Vault?
In this post we'll discuss:
- What is Key Vault, in case you landed here and you don't know.
- Configure diagnostics logging for your vault
- Querying the logs from your Azure Key Vault
- Connecting Azure Monitor and Rules to set up Alerts
- Get e-mails about any activity you need to review
What is Azure Key Vault?
Storing sensitive data in the cloud, as anywhere, is vital to the success of your online business and survival. Azure Key Vault provides a way to store keys, secrets and certificates securely and under lock and key in your Azure subscription.
Examples of things you can put in your vaults are:
- Client Secrets
- API keys
- Passwords
- Connection Strings
- Certificates
- Encryption Keys
- ... the list goes on, and on.
This post will not be about what the Key Vault is, but rather about how to find the diagnostics information you need about your vault, and see who accessed it, from where and when.
So, who accessed my vault?
In the Azure ecosystem there's a great deal of insights and tooling around your resources. With Azure Key Vault there's a bunch of build-in mechanisms to keep your vault secure, including, but not limited to:
- Access policies
- Firewalls
- Virtual Networks
- Access Restrictions
- Alerts, Metrics and Logs
Perhaps we'll talk more in detail about the other things in another post, but in this post I'll want to highlight something that has come up several times in discussions recently; "Who accessed my vault?"
In this post we'll explore:
- Enable diagnostic logging, including Auditing.
- Query the logs from your Azure Key Vault.
- Set up alerts in Azure Monitor to learn about any changes to your vaults.
When you land on your key vault's overview page, you'll see some basic monitoring stats. In one of my vaults, it looks like the picture below (the gap in the graph is due to having the service shut of during that period, hence no requests to the vault).
Diagnostic settings for Azure Key Vault
The easiest option to configure logging for your Azure Key Vault is to use the Diagnostic setting from the navigation when you're seeing your key vault in the Azure Portal:
From this dialog, you can either edit or configure a new diagnostic setting. Choose which ever you prefer, and from the new dialog you can control what to log:
From this configuration page, you can easily tick AuditEvent to ensure you capture the audit events for your vault - and since I'm sending them to my Log Analytics workspace, I'll be able to query them later.
Working with Logs from Azure Key Vault
Next up, we can drill down into the logs of our Key Vault. After all, we've just enabled the Diagnostic settings to ensure we can get all the juicy details delivered to our LAW (Log Analytics Workspace).
From your navigation on the Key Vault page, select "Logs" and you'll see the sweet log dashboard where we now can drill down into a multitude of events.
In the picture, there's a few things to look for:
- The "Logs" in the navigation.
- Switch between Simple Logs and Query Editor; Whatever is your preference.
- Review recently executed queries, or head to the General tab to get started with some sample queries to help you out.
I'm a big fan of Log Analytics and the capabilities in querying your data. I'll list a few of my commonly used queries that sits well with the scope of this article.
Query Examples for Azure Key Vault Logs
The first thing to note is that if you're going directly to your LAW (Log Analytics Workspace), you'll need to either specify the target resources in your queries, or select them in the UI. However if you're coming to the Logs from your Azure Key Vault as I showed in the previous section, the query editor is already filtering out events only for that specific vault. That's where I'll be focusing my attention right now.
Azure Log Analytics workspaces can benefit from complex queries because they use Log Analytics Query Language.
Example: Get the IP Address of all callers to your vault
AzureDiagnostics
| summarize count() by CallerIPAddress
This will yield a nice summarized view of the calling addresses to your vault, grouped by IP address:
We can dwell deeper into the details about these caller IP's at a later point, but essentially these are (mostly) service endpoint addresses of the various services in Azure that is calling into the vault.
Example: Summarize counts of failures to specific request uri's
AzureDiagnostics
| where httpStatusCode_d >= 300
| summarize count() by requestUri_s, ResultSignature, httpStatusCode_d
This will give you a count of failed requests, grouped by the properties you define:
Example: Get all Audit events
search *
| where Category=="AuditEvent"
| order by TimeGenerated desc
This will get you all the AuditEvents for your given time range. You can define the time range in your query too, should you want to. I'm using the UI for that to keep the query clean and easy to quickly change.
The result is a very detailed log of all audit events for your vaults, and you can then drill down into each event for the juicy details including the caller IP etc.
Azure Monitor
You can set up alerts for various signals in your Key Vaults (just like you can for any resource in the Azure subscription from the tenant downward).
A good tip is to ensure you've configured alerts for either specific, or all vaults in regards to for example "All Administrative operations".
The signal for All Administrative operations is triggered when there's any activity that matches this pattern; Specifically "Update", "Delete" or a vault is used in a deployment in the subscription.. So if someone modifies the configuration of your vault, or one of your vault if you're monitoring them all - then you'll be advised and can take swift action!
Now, if you've configured your subscription according to good security standards and you maintain a good security posture overall, you wouldn't have to think about someone modifying your vault, because nobody should be able to. However, as we all very well know, security can never be an after-thought and we have to consider all options - and take all preventative as well as reactive actions into account.
Here's an example of how to set that up:
Step 1. Create new Rule
Create a new Rule, and select the scope. I've selected the Subscription and the "Key Vault" but not a specific one; I want to be alerted as soon as any of my vaults are modified and they match the conditions in the next step.
It should eventually yield this result in the Resource target:
Step 2. Add a Condition
Click "Add" for a new Condition, and select the signals you want to monitor. I'm going for the "All Administrative operations" signal, which will signal me when a vault is updated, deleted or a vault is used for a deployment somewhere in my subscription.
Define the period you want to measure; In the example I chose a week just because that's the only time span I've got any modifications to my vaults. I would change this down to "Over the last 6 hours" to keep the ship tighter.
For the Alert logic, I'm leaving the defaults because I really want to know about anything.
The rest of the steps are just plain Azure Monitor; Define your Actions to take when a signal is raised, and what details to send with the Alert. Done.
You can also set up new alert rules based on log queries, which can be useful if you want to be notified when something happens in your logs instead of having to go into them and review.
Take action on Alerts
Depending on what type of action you set up - in my case I'm getting an e-mail - the results can vary.
When I enabled administrative alerts and then made changes to my vault, I got an alert fairly quickly after:
Seeing this overview is great, as I can see what type of operations has happened but no details, because that would obviously be insecure to ship over e-mail.
To find out more, you'll just click "View in Azure portal >" in the e-mail to go to the Portal, then go to your "Azure Monitor" and "Alerts":
Click on the alert severity you'd like to review. In my screenshot it's fairly easy to determine what to click, given it's a brand new subscription with no alerts except for the two administrative operations that just fired for this demo.
You can now go through each alert and take appropriate action. Select one of the alerts to see the details pane:
I've highlighted the interesting section with the State of the alert. If you have multiple technical staff looking into things in your Azure Monitor, or you have a massive amount of alerts, it could be a good idea to set the state of the alert.
An alert is set to "Fired" when it is sent, but now that I've reviewed it and decided that this was indeed an OK occurence of an administrative operation, I can go ahead and click "Change alert state" if you want to set it to Closed or Acknowledged.
Summary
A deeper dive into the various functions of Azure Monitor could be the topic of another post. With this post, I wanted to shed some light on various ways to figure out who's been accessing your vault, and when someone has tried to access it without success (Unauthorized).
Securing your assets in the cloud is important, but you shouldn't forget about them once they're deployed. Key Vault plays a very central role to a lot of things in the Azure ecosystem, and running a tight ship is important - and that includes ensuring you know what's going on inside the vaults (logs) and with the vaults (configuration).
Recommended reading
Enjoy, and please leave a comment!
Post header picture by Unsplash