Editor's note: This post is the first in ‘The Azure Bakery’ series; this part is about Azure Active Directory. Click here for the introduction to the series.
When you sign up for a Microsoft cloud service, such as Azure, the tenant, an Azure Active Directory instance is created. The Azure Active Directory tenant represents your organization. It’s the first layer of our Azure cake.
Every Azure environment is built on top of an Azure Active Directory
(Azure AD) tenant. Azure AD is Microsoft’s cloud-based identity and access management service.
What is needed when engineering and deploying your solution? There’s a lot to it. Today, we look at Azure AD from a fundamental perspective by looking at identity and security basics.
To access and manage your Azure environment, we need an identity; this is essential for authentication and authorization. Authentication is the process of verifying who you are, whereas authorization determines what you can and cannot do.
Ensure the identity has the needed permissions for fulfilling only the role it’s supposed to do and not more. This way, if the identity falls into the wrong hands, the amount of damage is limited. This approach is called role-based access control (RBAC) and follows the principle of least privilege. There are three identity types.
User accounts: They enable users and administrators to log in and work with Azure. When authenticating, the user needs to enter a username and password. Preferably followed by a second form of authentication, this is called multi-factor authentication.
Service principals: They allow applications and automation tools to access and work with resources within Azure. Authentication is handled by a combination of the application identifier and a secret key or certificate.
Managed identities: They provide an identity for resources. The identities can be used, for example, to access other resources, like the secret keys inside an Azure Key Vault. You don’t need to manage credentials; Azure manages these.
Authentication is the process of verifying who you are, whereas authorization determines what you can and cannot do.
There are two managed identity types: system-assigned and user-assigned.
A system-assigned managed identity is created as part of a resource, for example, a virtual machine. A user-assigned managed identity is created as a stand-alone resource and is usually associated with more than one resource. For example, when workloads that run on multiple resources share a single identity.
When there are on-premises and cloud identities, it’s recommended to integrate them. The integration enables you to manage user identities from one location, on-premises. And allows the users to use a common identity for accessing on-premises and cloud resources.
Synchronization between the directories is accomplished by using Azure AD Connect. The software is installed on an on-premises server, which connects to Active Directory (on-premises) and synchronizes with Azure Active Directory (cloud).
Azure AD has many different capabilities and offerings to enhance your security posture — machine learning, Conditional Access policies, and self-service, to name a few.
Treat identity as the primary security perimeter by centralizing security controls around the user and service identities.
Multi-factor authentication: This service adds a second form of authentication to the users’ sign-in process. The user is prompted for an additional form of identification, such as approving the sign-in or providing a code, finger, or face scan. Handling these requests is often done through a second device like your phone.
When only using a password to authenticate, you leave an insecure attack vector. Is it the user signing in, or is it someone else who obtained the credentials? Adding another factor will increase security because this isn’t as easily obtained or duplicated as a password.
When only using a password to authenticate, you leave an insecure attack vector.
The basic multi-factor authentication (MFA) features are available to Azure AD administrators for free. If you want to create reports, receive fraud alerts, whitelist IPs, or use a custom greeting and caller ID, you need Azure AD Premium P1 or P2 licenses.
Conditional Access policies: The policies are evaluated when a user wants to access a resource. With Conditional Access, you can bring signals together to make decisions, like blocking or granting access and using if-then like statements to keep your organization secure and optimize the user experience.
When you want to use Conditional Access policies, you need Azure AD Premium P1 or P2 licenses.
Privileged Identity Management: This service enables you to manage and monitor access to Azure AD and Azure resources. By minimizing the number of users and giving just-in-time access, you reduce an attacker’s chance of acquiring privileged permissions. Privileged Identity Management (PIM) provides time and approval-based role activation.
By minimizing the number of users and giving just-in-time access, you reduce an attacker’s chance of acquiring privileged permissions.
For example, when a user needs privileged permissions, like managing the configuration for security-related services, they can activate the security administrator’s role. Justification needs to be given during the activation process, and the request needs to be approved by the manager. When approved, the user is added to the role for a specified time. This way, you’re in control of the privileged permissions in your organization.
When you want to use PIM, you need Azure AD Premium P2 licenses.
Emergency access accounts: These are essential because they prevent you from locking yourself out of your Azure tenant. Either by accident or failure of a service that you depend on for handling the sign-in. You can mitigate this by creating at least two emergency access accounts.
Create the emergency access accounts directly in Azure AD to make them cloud-only. And use the *.onmicrosoft.com domain; this way, the accounts are not synchronized or federated.
The emergency access accounts should not be associated or connected with any individual user, device, phone, or hardware token. Use a smartcard or password for the credentials and keep them secure and known to the individuals who are authorized to use them.
When using passwords, make sure to randomly generate a password that’s at least sixteen characters long. And that the password doesn’t expire.
Separate the password into two or three parts, write it down on separate pieces of paper, and store them in different secure locations.
When using passwords, make sure to randomly generate a password that’s at least sixteen characters long.
The emergency access accounts should have a permanent Global Administrator role assignment for when the PIM service is down or having issues.
The authentication mechanism used for each emergency access account should differ. For example, set up the first emergency access account to use Azure AD MFA and exclude the account from any Conditional Access policies. And the second account to use Conditional Access with a third-party MFA provider. This way, if one of the services is not available, you’ll still be able to use one of the accounts.
Use Log Analytics to monitor sign-in and audit log activity from the emergency access accounts. By triggering notifications, you’ll get notified when a sign-in occurs. Monitoring makes sure that the accounts are only used for emergencies or testing.
Thank you so much for taking the time to read this post. I’d love to hear what you think, and I hope to see you next week when we’re going through the next layer of our cake, management groups. Bye for now!