Time to revive this blog. It’s been waaay to inactive lately, while I’ve been busy on customer projects, and figuring out where my blog should go. A lot of what I previously blogged, is now in Azure documentation and a large number of blogs. I’ve decided to shift focus to describe the challenges I run into at work, and what solutions we come up with. So in short: Move away from theory, and onto real world solutions. Let’s go!
In the past few years logging and traceability has become more and more of a requirement from customers I work with. This is even more true when they’re doing Azure projects.
Over and over again, I’m asked if we can create a secured and truested space in Azure, where logs can be stored and made tamper proof.
In this post I will share my design for creating a secure area in your Azure environment, where you can place your logs. There are many ways of doing this, but this is my preferred proposal that can easily be adjusted to customer needs.
Why secure logs?
They’re just logs, why do we need to secure them? I’ve heard that question over and over again. The answer is simple: if your logs aren’t secure, you can’t trust the integrity, and can’t prove what happened in case of a leak, hack or misconfiguration.
Consider a hack. Someone gained access to a database of yours hosted in Azure, containing customer information protected under GDPR. GDPR requires that you inform customers in case of a leak. With Azure SQL Auditing you can store information about all queries that was executed on your database. You can see all the information you need to investigate the incident; timestamp, client ip, username, database, query. Without this information you wouldn’t know how the hacker connected to your database, and you wouldn’t know what data was leaked as part of the query.
The basics:
You will need the following to do this configuration:
- Azure AD P2 license
- A minimum of 2 Azure subscriptions
The Azure AD P2 license is for Azure AD PIM. You can obtain this through other licenses too, like EMS E5 and M365 E5.
The design
The way to good security it based on a good design. The below drawing shows the concept I’m basing my implementations on. Your design can be different from this, but the concept is the same: We need a locked down subscription, that no one has access to.
We do this by creating a seperate subscription just for our logs. This subscription is placed in a Management Group that is under strict control. No one should have permanent access to the Management Group, or the parent groups. Consider the design below: If someone has contributor access on the Root Management Group, they’ll inherit permissions to manage the locked down subscription.
To control access, you’ll need a good Identity Management tool – Azure AD is one, and with an Azure AD P2 license you gain access to Azure AD Privileged Identity Management, or just AAD PIM, which is exactly what we need here.
As you can see, I have two subscriptions in this example. One is for the production environment of a BI application, the other one is for logging data from the BI application. This way the BI department can deploy their application and resources, without having access to the IT subscriptions and resources, including the Secure Logs subscription.
That’s the management group and subscription layout, now comes the resources.
In the Secure Logs subscription, you will find a Log Analytics workspace, which will be used for storing logs. In the Prod subscription, a SQL Server with a database on is deployed, and Auditing is enabled.
For Azure SQL, you can enable auditing on either the server level, og database level. If you enable it on the server level, all databases deployed on the server, will inherit these audit settings. If you enable on database level, you will need to configure it for each database individually. I prefer enabling server level auditing, and make sure no one has permissions to change these settings. You can do this by using the correct Azure RBAC roles, for the people who needs access to Azure SQL servers and databases.
To make sure you catch changes in configuration of auditing, you should enable Azure Activity Log collection too, and use Azure Policy to alert you of changes to the configuration.
All of the above configuration, will be described in the next two posts. Until that, stay secure!
Cloudpuzzles 