In our recent webinar “Controlling Your Azure Environment: Governance for the Modern Enterprise” we touched on the five disciplines of cloud governance from Microsoft’s Cloud Adoption Framework. This blog post is the third in the “The Five Disciplines of Cloud Governance” five-part series expanding on those concepts. If you missed the first two post in the series, check them out here.
Your Identity Baseline is our focus today. Organizations that have already adopted Office 365 likely understand the centrality of identity for cloud and hybrid deployments. Identity is the main security perimeter, and the other disciplines of governance have at least some dependency on Identity. Getting it right depends on two core concepts:
- Centralized Management
- Identity Protection
Coming up with your organization’s specific Identity Baseline will depend on your risk tolerance and needs. While these recommendations will give you some food for thought, developing a full plan should be part of a broader policy and risk review. For more information on how to develop Identity Policy Statement specific to your organizations, see the Cloud Adoption Framework documents on this topic.
Let’s start with Centralized Management. Managing identities across disparate, unconnected systems can lead to identity sprawl and inconsistencies, which can lead to both security risks as well as lower user and IT productivity. Centralizing identity using a single Azure AD tenant and synchronizing those identities with your on-premises Active Directory using Azure AD Connect, provides users and IT a consistent management experience. Implementing single sign-on in Azure AD provides additional user convenience and allows IT to focus on managing and securing one set of protected credentials and access controls rather than trying to manage password policies and provisioning across multiple applications. Lastly, turning on features like self-service password resets lets IT focus on high value activities and improves user experience.
Centralized Identity Management does have practical limits. You may choose not to synchronize certain highly privileged administrator accounts between on-premises AD and Azure AD, and Microsoft recommends that every organization maintain at least two managed “break glass” accounts for emergency access.
When we consolidate identities, protecting those identities from compromise becomes even more critical. That’s why Multi-factor Authentication (MFA) and Identity Protection should be considered as part of your Identity Baseline. All user accounts, regardless of access level, should be protected with MFA. Azure AD supports a number of native and third-party MFA providers that protect against credential compromise by requiring a second factor such as a one-time code from the authenticator app or a text message. Azure AD Conditional Access enhances MFA by supporting finer grained policies around when and how frequently to prompt users and should be considered once the Identity Baseline is in place.
While MFA provides an additional factor to protect sign-in events, Azure AD Identity Protection provides enhanced security by inspecting sign-in events for unusual patterns. If you normally only sign-in from an office in Washington DC, but are suddenly detected signing-in from Belgium, Azure ID Identity Protection can flag the event, require an additional MFA prompt and alert the user and administrators to the suspicious behavior. Identity Protection can also help identify users with potentially compromised passwords or users who are signing in from compromised devices.
Disabling weak protocols is an aspect of Identity Protection that is often overlooked but can have dire consequences. If you’ve implemented MFA and Identity Protection, but still have legacy authentication methods such as basic auth or IMAP turned on, identities can still be compromised. These protocols should be disabled unless compelling business reasons exist to keep them in place.
Putting It All Together
These identity baseline concepts of Identity Protection and Centralized Management come together to provide the basis for implementing a solid and secure Role Based Access Control strategy. That’s a significant topic on its own and one for another day. Many of the technologies and concepts addressed in this post are also relevant to Office 365, so if you’ve implemented them as part of your Office 365 roll out, often only minor adjustments and revisions are required to address your Azure roll out.