Azure landing zones are a recommended way for deploying Azure topologies for both new and existing Azure customers. I wrote an intro blog post about Azure Landing Zones that you can check out. In this blog post, I’d like to examine integrating “break glass” accounts into a target architecture.
First, some background. In Azure, user management is delegated off to a service called Azure Active Directory or AAD for short. AAD can have multiple different “user types”, but the most common are federated and cloud-only. In the federated case, identities can be enabled with multiple different authentication options, most of which effectively hand off the authentication responsibility to a 3rd party provider (that isn’t AAD). In the cloud-only case, authentication of user accounts is actually done by AAD itself. In all cases, user access can be protected with additional mechanisms such as Azure Multi-factor authentication (MFA) or Azure Conditional Access.
Typically, when enterprise customers set up access to Azure resources, they will do so by federating user accounts with their existing enterprise systems. This approach makes sense from a security perspective, as you can control how/when your identities are used centrally within your enterprise system. However, this architecture also introduces an extra failure case that you need to consider.
When you are planning your cloud deployment, you need to also plan for disaster recovery. Cloud consoles are typically accessible over the internet, and so you need to understand what your response would be in the following scenarios:
“Break glass” accounts are a strategy for providing access to the cloud console in the event of any of the failures described above. They are typically cloud-only accounts that do not have the additional security protections of MFA and Conditional Access. By creating accounts like this, you allow for management of your cloud resources in the event of failures in any of the above-described systems.
I think it is important to note that break-glass accounts are a tradeoff between continued operations and overall security. Typically, failure of authentication services does not prevent you from using already running cloud resources, but it does prevent you from managing them further. Businesses need to assess the tradeoff/risk of creating high-privileged accounts with limited account protections against the likelihood of failure in the authentication systems along with the impact. While Azure Landing Zones strongly recommend emergency access accounts, they might not always make sense for all situations.
To me, there are three different options when implementing “break glass” accounts.
Within AAD there is a directory role called Global Admin. This role has full access to the directory. Further, global admins have the option to elevate access to all Azure subscriptions. Effectively, using this function, you can become a User Access Administrator at the root scope of your management group hierarchy. From there, you can make any access changes you need to make, including granting yourself more access.
Depending on your agreement with Microsoft to purchase Azure, you may have what is called an Enterprise Agreement. In this situation, billing is handled via a separate mechanism within Azure. This mechanism allows for the creation of enterprise enrollment accounts, and one of the roles that you create is an account administrator. All subscriptions will belong to exactly one enterprise enrollment account. Enterprise Enrollment account administrators can set the service administrator for each subscription . In this access path, your “break glass” account could be the enterprise enrollment account administrator. In the event of access issues, use the enterprise enrollment portal experience to set a different service administrator for the target subscription.
Within Azure, all subscriptions belong to a hierarchy level within Azure Management Groups. Even if you have never really configured this before, you always have the root management group where each subscription will automatically live. In this access path, your “break glass” accounts can be assigned a certain permission level (Owner, or other) within an appropriate area of your management group structure. If there are access issues, simply log in to Azure with your “break glass” account and use its permissions to fix any issues.
Long story short, is, not really. All the access paths above have different trade-offs. Off the top of my head, here are some considerations:
Most conventional wisdom is to use the AAD global admin access path for your break-glass accounts. You can even see this recommendation for Canadian Government Use.
Hope you enjoyed the post!
Shamir Charania, a seasoned cloud expert, possesses in-depth expertise in Amazon Web Services (AWS) and Microsoft Azure, complemented by his six-year tenure as a Microsoft MVP in Azure. At Keep Secure, Shamir provides strategic cloud guidance, with senior architecture-level decision-making to having the technical chops to back it all up. With a strong emphasis on cybersecurity, he develops robust global cloud strategies prioritizing data protection and resilience. Leveraging complexity theory, Shamir delivers innovative and elegant solutions to address complex requirements while driving business growth, positioning himself as a driving force in cloud transformation for organizations in the digital age.