In the introduction to this series, we listed the 4 high-level categories of Azure governance, namely resource organization, resource security, auditing, and cost.
In this part, we will focus on Resource Security.
You can break Resource Security down into the following sub-categories: Role-Based Access Control (RBAC), Resource Locks, and Policy. Let’s explore each of these.
Role-Based Access Control (RBAC)
Role-Based Access Control (RBAC), as the name implies, is all about controlling who can access (and edit/modify, delete, etc.) resources. It gives us the ability to have granular control over our resources.
You can apply RBAC at the Subscription, Resource Group, and even the Resource level. So, by way of an example, you could contain all of your core networking components not only in a separate Azure Subscription but also use RBAC to ensure only the Networking Admins have permissions to modify these resources.
For more useful information, check out this article on Best Practice for Using RBAC. You can also check out the Manage Access Using RBAC and the Azure Portal article, along with the Azure Identity Management and Access Control Security Best Practices.
Built-In Roles vs Custom Roles
Another element of Role-Based Access Control (RBAC), is the concept of roles. We’re already familiar with that in an on-premises capacity (i.e. “local admin” etc.). But when it comes to Azure, there are a few differences.
Azure has an ever-growing list of built-in roles that can be leveraged for our granular access control needs. At the time of writing this article, there were 86! But if one of those built-in roles doesn’t exactly meet your needs, you can create a custom role.
You will have to use either Azure PowerShell, CLI, or the REST API to create the custom role (there currently is not UI to do so in the Azure Portal).
NOTE: There is a limitation of 2000 role assignments or custom roles per Azure tenant.
Resource Locks
When working with business-critical resources, especially those in Production, we need to protect them. Of course, that generally includes architecting for high-availability, geo-redundancy, and backup/disaster recovery.
But there’s also another tool in our toolbox that we can use to protect these sensitive resources, and it’s called Resource Locks.
There are only 2 types of lock types currently available, Delete and Read-Only.
- Delete Lock means you can read and modify a resource, but not delete it.
- Read-Only Lock means you can read a resource, but you cannot delete or update it. This is regardless of what permissions you may have.
In a Production environment, it is a good idea to place a Delete Lock on your core resources, like Domain Controllers, Virtual Networks, etc.
You can target resource locks at either the Resource Group level (in which, all resources will inherit the lock, even any newly added resources), or at the individual Resource level.
NOTE: If you have a resource lock enabled, and you need to perform an action that is blocked (i.e. trying to modify a resource that has a Read-Only lock), there currently is no suspend or temporarily disable feature. You will have to delete the resource lock, perform your action, and then re-create it.
However, if you think having a feature that would allow you to temporarily disable the Resource Lock would be useful, vote for the suggestion on Azure UserVoice.
Azure Policy
The final sub-category is Policy. But, Policy isn’t only related to resource security. Azure Policy helps you govern your resources, but it’s different from Role-Based Access Control (RBAC).
Role-Based Access Control (RBAC) gives you control and governance over what actions can be taken against your resources, like Create, Read, Update, and Delete (also referred to as CRUD).
A policy provides control and governance over the resources themselves (i.e. restricting which geographies and regions a virtual machine can be deployed to, or what SKU of virtual machines can be deployed).
You can create these policies, and then apply them to a Management Group, Subscription, or a Resource Group.
The reason why Azure Policy is categorized under Resource Security, is because Azure Security Center’s security policies are integrated with the Azure Policy platform. This allows you to be able to customize the security policies you want to be applied to your environment.
For some introductory information check out the article on What is Azure Policy? Also, check out this Azure Resource Manager (ARM) Policies article.
Now that we’ve covered Resource Security, let’s move onto the next high-level category, Auditing.