RBAC model for Azure AD

A lot of companies are struggling with the setup of a RBAC model which fits their organisation. Especially when adopting more Cloud services, it becomes even more challenging. Azure subscriptions, resource groups, databases, key vaults are just some examples. Also, we connect SaaS and other applications to the directory which are accessible via the Access Panel (myapps.microsoft.com). What is the best approach using Azure AD groups?

A good practice I have used in multiple cases is shown in the image below.

rbac

This practice provides a foundation which can be easily adjusted depending on the requirements. In this setup, we create separate groups for Departments, Applications and Resource groups. Department groups can be used to assign a set of access rights for applications. The application groups can be used to individually assign an application to a specific user. Unfortunately, you cannot use group inheritance of memberships which is why you to need to link both the group categories to the application.

For the resource groups, I’d like to make use a simple setup. It always fits the organisation IT model and it’s easy to explain. If your organisation is more business unit based you might consider to assign permissions to resource groups based on the business unit ownership structure.

Azure SQL and the Azure key vault are other services which require a good security practice. For these I do recommend to create individual groups linked to the roles in the SQL and Key vault. For instance, you should create a DataReader, DataWriter and DataOwner group per Azure SQL server at a minimum.

Check the links below if you want to know more about the Azure AD integration with services like Azure SQL and Azure Key Vault.

https://github.com/Microsoft/azure-docs/blob/master/articles/key-vault/key-vault-group-permissions-for-apps.md

https://github.com/Microsoft/azure-docs/blob/master/articles/sql-database/sql-database-aad-authentication-configure.md