Passwords: the traditional way to prove your identity.
Multifactor authentication (MFA): requires multiple forms of ID, enhancing security.
Azure AD Multi-Factor Authentication: Microsoft's MFA service.
Passwordless authentication: replaces passwords with something you have or are.
Role-based access control (RBAC) in Azure ensures people access only what they need, following the least privilege principle.
Azure authentication methods
Authentication means proving who you are, like showing your passport when you're travelling.
In Azure, you have different ways to make users authenticate:
Passwords: The traditional way to verify your identity.
Multifactor Authentication (MFA): prompting a user for an extra form of identification when they're signing in.
MFA asks for two or more elements to let you pass. These elements fall into three categories:
Something the user knows – this might be your password, or a challenge question (e.g. "what was your dream job when you were a child?")
Something the user has – this might be a code that's sent to the user's phone.
Something the user is – this is typically a fingerprint or face scan.
Compare multifactor authentication with single-factor authentication. Under single-factor authentication, an attacker would need only a username and password to authenticate. Multifactor authentication should be enabled wherever possible because it adds enormous benefits to security.
Think about how you sign into websites, emails or your banking app. After entering your username and password, have you ever needed to enter a code that was sent to your phone? If so, you've used multifactor authentication to sign in.
Azure AD Multi-Factor Authentication: Microsoft's MFA service.
Lets users choose an additional authentication method, like a phone call or a mobile app notification.
Passwordless Authentication: passwords are removed and replaced with something you have, plus something you are, or something you know.
Users often get frustrated having to remember their passwords AND go through MFA. People are more likely to comply when it's easy and convenient to do so.
Once you register your device with Azure (your device is 'something you have'), once you provide something you know or are (e.g. a PIN or fingerprint), you can be authenticated without using a password.
Azure offers options like Windows Hello for Business, Microsoft Authenticator app, and FIDO2 security keys as the authentication tool.
Role-Based Access Control
Role-Based Access Control (RBAC) in Azure ensures that people access only what they need to, following the principle of least privilege, which means granting access only at the necessary. It's a really popular security practise that many companies follow!
For example, if you only need read access to a storage blob, then you should only be granted read access to that storage blob. Write access to that blob shouldn’t be granted, nor should read access to other storage blobs.
Managing individual access for a whole team can be super time consuming. Imagine if you need to grant access to a whole bunch of resources for everyone, one by one! Or, imagine if someone new joins the team - now you need to grant them access to all the services that they'll be needing to use, one by one.
How RBAC works
Instead of granting access to individual accounts, you create an Azure RBAC group, which packages a set of permissions.
By assigning individuals or groups to an Azure RBAC group, they automatically gain all associated access permissions.
Now, if you add additional resources to the company, simply grant your Azure RBAC group access to the new resource. Everyone in that Azure RBAC group will automatically get permissions to the new resource.
Now, when a new member joins the team, they automatically get the same access as other members in the same Azure RBAC group.
RBAC access can be applied to management groups, subscriptions, resource groups, and single resources.
There are 5 types of access that can be granted. These access types are called roles:
Reader - an observer that won't make any updates
Resource-specific - on actions related to a resource are allowed. For example, a "Virtual Machine Contributor" can manage virtual machines but not other resource types
Custom - a tailored set of permissions based on unique needs
Contributor - they can manage but not delete resources. This role is suitable for users who need to make changes and perform actions on Azure resources without the risk of deletion.
Owner - the highest level of access. An admin that can read, update and delete
Access can be inherited from a higher to a lower level. For instance, an owner at the management group level has control over all subscriptions within it too.
Here's a peek at how you can assign roles on Azure!
Some final notes on RBAC
RBAC will activate on any action to an Azure resource that gets picked up by the Azure Resource Manager
Azure RBAC doesn't enforce access permissions at the application or data level. While Azure RBAC helps control who can access and change your app in your Azure account, you should still need to build in things like passwords and authentication in the app!
Azure RBAC uses an allow model. If you get two different roles assigned to you - let's say, read and write - for the same resource group, you get both read and write permissions on that resource group.
An extra note for the curious
Have you noticed that authentication and RBAC are not quite the same?
That's because RBAC does not deal with authentication. Instead, it deals with authorisation.
Authentication = you are what you say you are.
For example: at the airport, customs agents check if your passport photo matches you in person.
Authorisation = the level of access you get.
For example: at the airport, our plane ticket has a flight number, seat and row number and flight class. You are authorised for those exact things. You can't use your ticket for another flight, another flight class, or another seat. Taking this principle into cloud computing, we should only authorise users for the exact thing they need at the time they need.
