Implementing Strong Identity: Policy-based Access

In this series of blogs we are reviewing the best practices in hardening your Microsoft 365 tenant against malicious attacks. Many attacks can be block by making zero-costs changes to your tenant. Policy-based Access can decide whether to block access to a requested resource or impose additional requirements, such as MFA, for granting access when risk is detected. Microsoft recommends four requirements for implementing strong identity for a Zero Trust security model.

In this blog, we are going to discuss the second security recommendation: Policy-based Access.

Multi-factor Authentication (MFA)
Policy-based access
Identity Protection
Secure access to SaaS and on-premises apps

Check out Enclyne’s Article on Multi-factor Authentication

Let’s review Zero Trust Model.

What is Zero Trust?

Instead of believing everything inside the organization’s firewall is safe, the Zero Trust model assumes breach and a “never trust, always verify” access approach. Every request, regardless of whether it originated internally or externally, is strongly authenticated, authorized, and inspected for anomalies.

Now, let’s discuss policy-based access and why it is a Microsoft Recommendation.

What is Policy-based Access?

Organizations need ways to restrict access to applications and systems in certain circumstances, such as gating access to an enterprise application based on signals associated with user and device identity. When user, device, or session risk is detected, access policies can decide whether to block access to a requested resource or impose additional requirements, such as MFA, for granting access.

How do we enable Policy-based Access with Azure AD Conditional Access?

Azure AD Conditional Access can enforce access policies for applications using signals from a variety of different sources, including Azure AD Identity Protection, Microsoft Cloud App Security, and Azure Advanced Threat Protection. These signals include user or group identity information, IP location data, device type or state, the kind of application or resource being accessed, and real-time login and session risk data. Policies to block or allow access can be targeted to specific groups or users, IP address ranges, specific platforms and applications, and sign-in behavior.

Azure AD Conditional Access enables enforcement of a variety of policy decisions. Common examples include blocking sign-ins involving legacy authentication protocols, access from specific locations, or other high-risk criteria. Other commonly applied policies include granting access to a requested resource but requiring MFA, or requiring a mobile device to have an approved app or be marked as compliant using Microsoft Intune, a cloud-based tool for enterprise mobility management. For example, Conditional Access can enforce policies that require MFA for systems administrators or for those seeking to perform Azure management tasks.

In addition to enforcing policies for granting or blocking access, Azure AD Conditional Access can enforce session-control policies that limit what users can do with their access.

For example, a Conditional Access policy can limit access to SharePoint and OneDrive content from unmanaged devices. In this scenario, users are given browser-only access to the app with no ability to sync, download, or print files. The goal in supporting policies for limited access is to ensure users have an opportunity to remain productive while minimizing security risks.