To suggest security is “on the radar” for anyone moving to the cloud would be a dramatic understatement. But here we are. One thing I have discovered when talking with peers is there are a lot of gaps in fundamental security concepts out there. It’s critical to start your cloud journey with security in mind and being mindful of tools Azure provides out of the box. Yes, there are some extremely useful new services that can be leveraged, however, having the fundamental understanding of creating a secure cloud experience from the outset is just as important. I agree, learning fundamentals may not be as sexy as kicking the tires with Azure Sentinal, but they are extremely critical in improving your cloud security posture. In this article, we will take a look at how we can take a step in creating a secure platform by exploring role-based access control (RBAC).
There are several approaches to security. Providing access on the need to know and more importantly, least privilege security principles are critical for any organization both on-premises or in the cloud. This is where role-based access control comes in. RBAC allows you to assign permissions to users, groups, and applications at different scopes. In Azure, the scopes at which these rights are assigned are subscription, resource group or a single resource.
For example, your Global Admin can assign the role of Virtual Machine Contributor to Janis within the subscription. This grants Janis the right to create, delete, or modify any virtual machine within the subscription. Maybe Janis really only needs to view virtual machines within a particular resource group, but yet, she has the ability to spin up any type of VM or delete existing with the Virtual Machine Contributor role.
Often times we assign more rights than necessary because it’s easier and things just work. This is not new. However, in the cloud, we must be mindful of least privilege more than ever because bad things can happen. We really need to assess what Janis needs. If all she needs is to see the assets in the resource group, we simply need to grant Janis the role of Reader, thus narrowing the scope of Janis’s rights which is a better practice falling under the least privilege security principal.
In short, security principals are who or whatever is being assigned the role or right. Take file permissions for instance. If I assign Todd the read permission to a document, Todd is the security principal. There are categories of security principals in Azure, very similar to what you have on-premises:
There are quite a few built-in roles in Azure. The four most commonly used roles are:
Let’s go ahead and assign Janis the role of Reader for our resource group named demo-rg. As of right now, Janis cannot see any virtual machines within that resource group while she is logged into the portal. (see below)
Due to this being the cloud, role assignment isn’t instantaneous. I’ve found logging in and logging out seemed to expedite the process. Or just go grab a cup of coffee and the role should be assigned when you return. Now, if we select virtual machines (or click on the demo-rg), Janis can now see all assets in that resource group, including the virtual machines (see below. She only has the reader role which would adhere to least privilege security philosophy if this is all she needs.
Access management for Azure resources should be high on the priority list. Leveraging out-of-the-box tools such as role-based access control can make that job much easier, especially when implementing from the ground up with a thoughtful plan in place. RBAC allows us to manage the who, what, and when in the cloud:
Take time to explore how you can create a stronger security profile by checking out the Azure Security docs site. There are several Security Best Practices white papers that go into great depth in securing the platform. You can also find some great RBAC tutorials including how to create and apply using PowerShell and Cloud shell located here.