Azure Portal Security Overview

Azure AD, Azure Portal and Azure DevOps are three main solutions that Microsoft offers as part of their Azure platform. Each service has its own security model and features and functionality surrounding managing and reporting on security. I plan on detailing each in upcoming blog posts, starting with Azure Portal.

What is Azure Portal?

Microsoft Azure Portal is a web-based application that allows users to create, manage/monitor, and delete resources on the Azure platform. It is accessed by going to https://portal.azure.com.

Security Model

Azure Portal security is role based and is managed with what Microsoft calls RBAC (role based access controls). Each role has a ‘definition’ that dictates what it can or cannot do.

This definition is broken into two different sections, Actions and DataActions:

Actions define what you can do to securable objects in the system
DataActions define what you can do to data that is stored within an action (for example a storage account or Azure database)

Under both the Actions and DataActions sections of the role definition you will also see the NotActions and NotDataActions. This is a way to remove access from the access granted in the Actions or DataActions. This is not an ‘explicit deny’ and is just inherent to the role itself (when assigned to a user if another role grants access to an object, that access will be granted).

Each line of the role definition designates a separate permission that the role can perform.

Each permission is broken into three parts:

Provider – groups together objects that fall under a certain area of Azure
Securable Object – actual object being assigned access
Access – level of access granted

For example, this AcrPull role is assigned one permission assignment (Microsoft.ContainerRegistry/registries/pull/read) that breaks down into the following:

Provider = Microsoft.ContainerRegistry
Securable Object = Registries/Pull
Access = Read

Some entries on the role definition may include wildcard (*) characters. This is a way for users to easily grant all securable objects at a particular access level that meets a particular criterion.

For example in the below role:

It has an Action permission of Microsoft.ApiManagement/service/* this means that this role has all access to all objects at this security object level as well as any objects underneath this level
It has an Action permission of Microsoft.Authorization/*/read this means that this role has read access to all objects at this level as well as any objects underneath this level

Another iteration of this is when the * command is by itself, the Contributor role has a * in the Actions permissions.

This means it has full access to all objects in the system. The objects in the NotActions then remove all access to all Authorization objects at the Delete and Write level as well as remove the Authorization/elevateAccess/Action permission.

Now that we understand the role themselves where can we assign them?

Role Assignment

Roles can be assigned to:

Users – refer to Azure Active Directory (AAD) Users
Groups – refer to AAD Groups which in turn can contain AAD groups and AAD Users
Service Principals / Managed Identities – refer to applications or other non-users that can still be assigned security in Azure (for example, automated services)

Assignment Scope

User roles and role definitions can be further defined to only be applicable at a particular scope. This feature allows for a cleaner role setup as you do not have to have duplicate roles that have the same object access but to different areas of your Azure environment, instead you can have one role and assign it at different scopes.

In Azure, you can specify a scope at four levels: management group, subscription, resource group, and resource. Scopes are structured in a parent-child relationship. Each level of hierarchy makes the scope more specific. You can assign roles at any of these levels of scope and the level you select determines how widely the role is applied.

For example, if Alice has been assigned the Reader role at the subscription scope (e.g. for the ABC Subscription), she will also have Reader role access to the underlying resource groups and resources within the ABC Subscription but she would not have access to other Subscriptions in the tenant.

Security Reporting Options

Azure Portal does a very good job at giving you a lot of different reporting and setup options for security. If you navigate to a subscription -> Access Control (IAM) you are presented with this access pane. Let’s go through and look at the different options here:

If you click on ‘View my Access’ you will be presented with your role in this subscription. You also get to see if you are assigned a class administrators role.

You can also run an access check for any other user, group, or service principal in your environment. In this case I am looking to see if our D365 Test User has access to this subscription and it does not.

If we navigate to the Roles tab, you will be able to see all roles that are available in this subscription.

If you select a role and click on the View option you will be presented with a complete listing of all permissions this role has access to. They will be broken out by Provider and if you click on the ‘information’ icon you can actually see the programmatic name of the permission.

If you navigate to the JSON tab, you will be presented with the actual ‘code’ for the role definition. This is where you can easily add/remove additional permissions and the only place where wildcard values can be added.