In cloud computing generally and in Microsoft Azure specifically, the shared responsibility model means that both Microsoft and you (the customer) have a role to play in ensuring service high availability.
Let's take identity, for example, Microsoft provides a 99.9% availability service-level agreement (SLA) for Azure Active Directory (Azure AD). By contrast, it's your responsibility to secure your Azure AD accounts, integrate Azure AD into your applications, and so forth.
The aforementioned "three nines" of high availability means that Microsoft allows the following Azure AD downtime durations:
- 77 hours of downtime per year
- 83 minutes of downtime per month
- 08 minutes of downtime per week
- 44 minutes of downtime per day
My question for you is: How prepared are you for a Microsoft-side service outage to, say, Azure Multi-Factor Authentication (MFA)? The last thing you want as an Azure administrator is to be locked out of your subscriptions and resources if Azure MFA goes offline.
If Azure AD as a whole is unavailable, then nobody has Azure access. However, we can certainly leverage our side of the shared responsibility model to ensure that the failure of one or more Azure AD-dependent services doesn't cause a long denial of service for our users.
Some of these Azure AD-dependent services include:
- Federated identity with Active Directory Federation Services (AD FS)
- Azure Conditional Access policies
- Azure AD Identity Protection policies
In today's tutorial I'll give you detailed guidance on establishing an emergency "break glass" account to ward against this kind of outage.
Plan an Emergency Access Account
For our purposes, an emergency access account is a highly privileged cloud-only Azure AD user account that we'll use only in an emergency. Note that: it's crucial we do not associate our emergency access account (or accounts, if you want to make two) with either human beings at our organization or with Azure applications in the service principal context.
The emergency access account has three key properties. The account is:
- associated permanently with the Global Administrator Azure AD role
- configured with a non-expiring password
- exempt from Azure MFA policies
- exempt from Conditional Access or Identity Protection policies
You should directly assign the emergency access account the Global Administrator role. Therefore, you should not made the account eligible to activate the Global Administrator role via Azure AD Privileged Identity Management.
The password you assign to the emergency access account should be at least 16 characters long and generated (pseudo)randomly.
You can set the account's password never to expire by using Azure AD PowerShell. As shown in Figure 1, you can explicitly exempt your emergency access account from your Conditional Access policies.
Figure 1. Excluding our "break glass" emergency access account from Conditional Access policy.
Test Emergency Account Access
You'll want to run regular "fire drills" in which you log into the Azure Portal and to your cloud applications by using the emergency access account. You probably don't want to make any changes (such as temporarily disabling Azure MFA or Conditional Access), but it doesn't hurt to have that confidence of knowing what you need to do when or if you need to do it.
Remember you can always obtain emergency access to any subscription that trusts your Azure AD tenant by browsing to your Azure AD tenant in the portal, switching to the Properties blade, and toggling the Access management for Azure resources switch from No to Yes as shown in Figure 2.
Figure 2. Access management for Azure resources.
Enabling the access management option immediately grants you the User Access Contributor role-based access control (RBAC) role at the tenant root scope. This means you can edit RBAC access to any subscription associated with the Azure AD tenant.
Audit Emergency Account Access
You'll want to ensure that you configure Azure to log every use of the Azure AD emergency access account. You should also configure an alert to fire whenever this account usage occurs.
To ensure you don't run into log data retention issues, I recommend you create a Log Analytics workspace if you haven't already done so, and deploy the Activity Log Analytics monitoring solution to capture your subscription-level Azure activity logs.
Within Azure AD itself, you can route audit logs and sign-in logs to your Log Analytics workspace. Here are the associated Microsoft Docs articles that teach you how to perform these configuration tasks:
- Collect and analyze Azure activity logs in Log Analytics workspace in Azure Monitor
- Integrate Azure AD logs with Azure Monitor logs
This way you capture not only any emergency access account sign-ins, but also the accounts resource actions within your subscriptions. One of the coolest things about Azure Monitor logs and the Log Analytics workspace is you can generate reports by using Microsoft's internally developed Kusto Query Language (KQL).
KQL behaves like Structured Query Language (SQL). For example, the following KQL query reports on any sign-in activity from your emergency access account:
SigninLogs
| project UserId
| where UserId == "c9e2f9b8-2e52-4e39-8cf5-dd35d6f13ca7"
Actually, the above KQL query would be a great fit for an Azure alert. As Figure 3 shows, you'd define the alert's signal logic on a custom log search from within your Log Analytics workspace.
Figure 3. KQL-based Azure alert.
Takeaways
Well there you have it! I hope you take some comfort that you can mitigate against Azure MFA failures. As usual, I'd like to leave you with some hand-selected resources to help you further along your Azure AD security journey: