When you start configuring access control policies, it is necessary to analyze who of the employees performs what tasks. Later on, when assigning a certain level of access to an employee or to a group of employees, you can use the tried-and-true principle of least privilege (PoLP).

The essence of this principle is in the fact that the access to a module or program should only be provided to the employee if the latter really needs it for the work to be completed. Benefits of this approach are as follows:

• Security. The access to key components of the system will only be granted to those employees who are responsible for maintenance of a particular resource.
• Increased stability of the system. Provided an employee can only use and configure the resource in question, there is no chance that other resources’ settings, beyond the area of responsibility, will be accidentally changed.
• Focus. Employees will only see resources that they have to work with—and nothing else. As a result, it will be easier to get familiar with and configure all resources available to them.
• More efficient cost control over resources taken on lease. You can minimize the likelihood of overspending on an incorrectly selected pricing tier by having all management of software and resources’ pricing, as well as renting new resources, conducted only by the employees who are aware of the costs, system requirements and consumption rates.

It is necessary to specify access policies when working with Microsoft Azure Portal, too. To help you solve this problem, MS Portal offers a lot of approaches, the most common of which are RBAC (role-based access control) and ABAC (attribute-based access control).

The essence of this approach is that the user is assigned a role in a customized system, and that role matches his or her business role in the company. Based on the role, the user gets the access to specific resources. This approach is easier to configure, and it works fine in organizations where roles are repetitive, and groups of employees share common sets of privileges bound up with their roles.

For example, there is a head of the development department. This job implies having all privileges and all access rights. The department’s head leads other developers who share the same business role and tasks. Developers’ tasks are scoped by access to a particular resource. In this case, two roles are set up: “Head of the development department” and “Developer”. The role of development head will imply having more privileges and more extensive access.

ABAC is more difficult to configure, but at the same time it provides greater flexibility. It is often ABAC that helps you solve problems that cannot be solved in RBAC. For example, the access to resource “A” can only be given to developers, whose role is Developer of course. But let’s imagine that you might need an additional condition that the access to the resource is only given to the developer working in a particular department. If you want developers from this department, but not others, to manage resource “A”, you will have to set up an attribute indicating how the developer is linked to the resource. For example, you can add the attribute “Department 1” to the resource. As a result, the resource will only be accessible to those working in Department 1.

You can start adding new users directly in Azure Active Directory.

The “Roles and administrators” section already contains a lot of pre-created roles. If you cannot find a suitable role among the existing ones, you can create your own roles in AAD (Azure Active Directory) at higher pricing tiers. Then you will need to add the user to a Management Group or to a Subscription. In Azure, Subscriptions and Management Groups (and also Resource Groups) are all essential organizational constructs.

An Azure Management group is logical containers that allow Azure Administrators to manage access, policy, and compliance across multiple Azure Subscriptions.

Microsoft defines a subscription as “an agreement with Microsoft to use one or more Microsoft cloud platforms or services, for which charges accrue based on either a per-user license fee or on cloud-based resource consumption”.

In a more granular approach, adding users and assigning roles can be done from within the resource itself (e.g. a virtual machine), by using the “Access control” section of the resource. That is to say you can allow a user to manage one specific resource only.

With that end in view, you can assign one of the following well-known roles to the user:

• Owner: has full access to resources including the privilege of delegating access rights to others.
• Contributor: can create and manage all types of Azure resources but cannot grant access to others.
• Reader: can view existing resources available in Azure..

If a user can access a resource, and there are other resources created in the “Management group”, “Subscription” or “Resource group”, then all resources in particular organizational constructs will also be available to the user.

You can refer to Microsoft documentation to become more familiar with different approaches. Below is the list of several articles that we have found useful:

• What is Azure role-based access control (Azure RBAC)
• Managing access to apps
• Create a basic group and add members using Azure Active Directory
• Assign administrator and non-administrator roles to users with Azure Active Directory