Zero Trust: How Azure Active Directory and Identity Management Enable Cloud Security
After the successful SolarWinds attack in 2020 where attackers gained access to Microsoft’s systems, Microsoft changed its approach and aligned with the National Institute of Standards and Technology’s (NIST) zero trust architecture. In this article, we’re going to detail how Microsoft’s zero trust approach leverages Azure Active Directory and Identity and Access Management to enable cloud security.
In contrast to previous security models, in Microsoft’s defense in-depth approach – and especially for cloud applications, security and systems – Identity and access are the first layer of defense. This changes the way we do identity management. Identity and Access Management (IAM) used to consist of the three As (Authentication, Authorization, and Auditing), but within the Zero Trust security model, a fourth A becomes apparent: Administration.
What is zero trust?
Zero trust can best be described as the approach to achieving an IT environment where all access is governed by explicit verification and the lack of implicit trust. It’s based on three pillars:
- Verify explicitly
- Use the least privileged access
- Assume breach
Why zero trust matters for identity management
What’s also different from five years ago is that everything is connected to the Internet. Organizations no longer have the luxury of operating off the grid. Employees want and may need to work from any location. People who access applications and data from your organization are no longer just your employees.
Partner collaboration and consumer services require them to access your data too. VPNs just won’t do. Your old firewall and perimeter network no longer cut it. Where domain join used to be the go-to response to gain access, people bring in non-Windows devices that just don’t support it.
Identity and access are the first layers of defense. And they need to be top-notch.
How Microsoft’s Azure Active Directory works
Azure Active Directory (Azure AD) is Microsoft’s cloud-based identity and access management as a service (IAMaaS) solution. In contrast to Active Directory, Azure AD is a cloud-based and open-standards platform. It was designed to operate on the Internet, whereas Active Directory and its main protocols – NTLM and Kerberos – were initially designed for safe networks.
Open standards
Open standards seem like a necessity when creating a cloud-based platform, but there’s more to it. SAML, OAuth, OpenID Connect, and SCIM require admins to properly manage the environment. Admins can no longer coward behind security through obscurity.
Information on the building blocks is out in the open. The way the building blocks are stacked and managed actually differentiates between strong and breached organizations.
Not just cloud
Azure Active Directory is a cloud-based service, but it isn’t restricted to merely providing access to cloud-based resources. Its password vaulting capabilities allow centralized access to popular social media services like Twitter, but through its federation protocols, Azure AD is already able to integrate federated applications and services whether they’re hosted on-premises or in the cloud.
Through the Azure AD Application Proxy functionality, any on-premises web-based service can be integrated. Federated, password vaulted, Kerberos-constrained delegated or forms-based authentication are all supported using this technology.
When Active Directory is synchronized to Azure AD using Azure AD Connect, purely Azure AD-joined devices can access on-premises Kerberos-based apps, services, and data without a hitch. Simply sign in using any of the Windows Hello for Business methods (face recognition, fingerprint, PIN, or a security key) and get access to all the resources you need wherever they live.
There’s even talk of Azure AD offering RADIUS, Kerberos, and LDAP as built-in services… Imagine the resources you’d be able to protect that way!
How access is governed with Azure Active Directory
The big reason to integrate everything with Azure AD is that access is governed through Conditional Access, Identity Protection, Microsoft Intune, Continuous Access Evaluation, in addition to integrations with many Microsoft Defender products.
Conditional Access
A far cry from group membership-based access governance in Active Directory, Conditional Access allows organizations to govern access based on the user account’s attributes, group memberships and risk, the device’s join type, health status and location, and the client application used to access the Azure AD-integrated service. Based on all these conditions, controls can be put in place to require multi-factor authentication, provide read-only access, require acceptance of terms of service, and/or require a password reset for the user account.
Organizations who are further along on their Zero Trust journey typically use Conditional Access to provide mere read-only access to SharePoint document libraries when accessed not using an organization-managed device. And block access from outside their locations’ countries unless access is specifically requested beforehand.
Microsoft Intune
For device health attestation, devices need to be managed using mobile device management (MDM) and/or mobile application management. Microsoft Intune offers this functionality and integrates with Conditional Access seamlessly.
Admins can configure device compliance policies that require basic measures like drive encryption to determine whether a device is compliant. Or block them when they are jailbroken or rooted. Policy evaluation occurs every 15 minutes, by default.
Identity Protection
Just like in GPS, GLONASS, Galileo, and many other global positioning solutions, the number of satellites provides more accuracy. The more signals an organization can leverage, the higher the fidelity of its decisions.
Azure AD Identity Protection processes trillions of daily signals to provide organizations with information on risky locations, risky behavior, and leaked credentials. Using this information, Microsoft’s Threat Intelligence machine learning model provides a risk assessment for every sign-in.
Based on sign-in and user risk, admins can configure policies to require multi-factor authentication or a password reset. Another method, commonly used when an organization is under heavy fire, is to block sign-ins beyond a specific risk level.
The integration of Identity Protection into Conditional Access is fully automated and doesn’t require manual actions from admins. From a defender’s point of view, it’s virtually indistinguishable from magic.
Continuous Access Evaluation
An Azure AD sign-in session typically lasts for an hour. This is based on the open protocols underneath the service.
However, when an application supports it, Azure AD can short-circuit the session near real-time. Microsoft Edge and the Office apps support this feature in Exchange Online, SharePoint Online, and Microsoft Teams. Many more are coming.
The functionality is based on the Continuous Access Evaluation protocol. It can be used to require re-authentication when the user account is disabled or deleted, when the password is changed or reset for the user account, or when the device changes from one (trusted) location to another.
Microsoft Defender for Endpoint, Identity, and Cloud Apps
Assuming breach requires insights. The Microsoft Defender suite of products provides this overview through their dashboards, but also feeds their signals back into Azure AD Identity Protection.
Microsoft Defender for Endpoint can immediately flag a device as non-compliant when Windows Defender detects malware activity or tampering. Defender for Identity focuses on Active Directory on-premises, where it can automatically disable or reset the password for a synchronized user account when it’s suspected as a victim of tampering.
Microsoft Defender for Cloud Apps signals Identity Protection when a person tries to access unsanctioned cloud services or is suspected of unusual behavior.
Administration and Azure Active Directory
With all the automated verifications and instant revocations, you might think that admins are no longer needed. However, the opposite is true. In a (near) zero-trust architecture, Identity admins get assigned other tasks and other priorities within the organization in identity protection and in entitlement management.
Maintaining an access strategy
In concert with business stakeholders, admins need to lay out and maintain the overall access strategy. Technology may provide a solid foundation, but business processes define the way people use the platform.
This is certainly not a one size fits all, but more of an 800%/20% rule engagement, as the strategy will have to take exceptions into account. For instance, service accounts and service principals won’t be able to perform multi-factor authentication, so they’ll have to be limited to modern authentication to the services they access and to the IP addresses they access their back-end data from.
In terms of least administrative privilege (the second pillar of zero trust), Azure AD roles and API permissions should be scoped to the tasks assigned to the person, application, or service. To avoid the traps many admins fell into in the past, it’s a great idea to not assign every admin the Global Administrator role. And to not assign every application the Directory.ReadWrite.All permission in the Graph API…
To avoid standing permissions, admin roles in Azure AD can be assigned only when needed. With Azure AD Privileged Identity Management (PIM), admin roles can be requested, justified, and approved only when needed. The role assignment expires automatically afterward, or when the admin relinquishes the role.
Managing Identity Protection
Admins may no longer have to perform actions to lock out suspicious behavior, but they sure need to pay attention to the false positives. By confirming a user account’s compromise or dismissing the risk, the machine learning model is trained, which improves the signal quality.
Striving for attribute integrity
Admins also need to strive for excellent directory management. When a person leaves the organization, disabling their account after a month won’t cut it. When the department attribute isn’t populated in a straightforward manner, dynamic group memberships won’t work when they’re based on that attribute either.
Managing entitlements
When an organization doesn’t obtain at least a decent level of attribute integrity, it’ll be extremely hard to gain any benefit from the entitlement management features in Azure AD. Determining who can request, approve, and review access can take group ownership into account. But then owners will need to have been defined.
Conclusion
Zero Trust cannot be easily achieved, but as solutions from Microsoft and other vendors evolve, it might eventually be. It’s no wonder that Zero Trust is often described as a journey in terms of technology, processes, strategy, and licenses. When will you embark?
Related Article: