More cloud means many things, including more opportunity and flexibility. But it also means more headaches for IT.
Services and data managed by modern IT departments is quite different from just a few years ago. Most companies have workloads, applications and services that exist on premises and in the cloud — or even multiple clouds. Employees work wherever they have internet access. Asset protection gets more challenging as users have an evergrowing list of access methods. Azure Active Directory (Azure AD) conditional access can give IT a way to maintain control over their expanding IT real estate through creating a set of policies that require users to perform approved actions to gain access to an application. Azure AD also decides, based on a combination of factors, when to require more login checks. Building policies with several conditions give administrators a layered approach for added security.
Changing times require updated security practices
It is no longer acceptable to rely on simple assumptions to grant access to resources. For example, you can’t block all access from countries in the Asia-Pacific region. Companies need more flexibility to handle more unique login combinations.
The company may require a different authentication level when a user logs in from their phone versus the corporate laptop. For compliance reasons, the executive team may be subject to more stringent controls than frontline workers. Access attempts from known good networks can still be a threat due to phishing and compromised credentials.
These factors add up to dynamic environments that don’t allow for a simple set of rules to govern access. Organizations must determine if a login attempt is legitimate or a threat as it happens, and Azure AD conditional access policies give enterprises real-time analysis of logins to stop potential threats.
What is Azure AD conditional access?
Azure AD conditional access is a set of policies that layer on top of an already successful access attempt. Policies are a set of requirements that grant or deny access. The policies use “signals” from many sources as part of the process to allow access, require more stringent access controls, such as two-factor authentication, or deny access. Signals are common criteria, such as user and group membership in Azure AD and the application being accessed, but also rely on other data, such as public IP location or the device type.
Conditional access policies use real-time risk intelligence data in Azure AD Identity Protection and the Microsoft Defender for Cloud Apps, formerly known as Microsoft Cloud App Security, to determine the risk level for each access attempt. If the risk threshold is met, Azure AD will require extra login information or deny the connection.
How to understand how conditional access policies work
To envision how these policies work, think of an if-then statement used in programming. If a user wants to access a resource, then they must complete an approved action and/or meet a set of conditions. For example, you can limit access to an HR application to HR staff who are using Azure AD-joined devices. You can limit access to a payroll application from known corporate IP ranges and require multifactor authentication (MFA). There are many combinations of requirements for a single user or application. You can also apply more than one policy to each cloud-based resource.
Besides these rules, Azure AD also enforces MFA for attempts that raise a security red flag. For example, if I normally log in from an addresses in the U.S., Azure AD may require additional security prompts if it sees an access attempt from another country. Azure AD may outright deny a login attempt from an IP of a known bad actor.
How to develop a conditional access policy in Azure AD
The console to configure a conditional access policy is simple to understand.
First, create a policy and select options, also called assignments, with the requirements the policy will enforce. Some options, such as “Users and Groups,” have the option to include or exclude specific users, groups and roles, and cover guests and external users. You can assign a policy to a single application, a group of applications or all applications in your Azure AD tenant.
From there, the choices get interesting.
Setting up the conditions in a policy
Conditional access policies have several unique options you set in place as requirements for access or to deny a login attempt. In the assignment portion of the policy, you can set several specific conditions.
For example, the policy can use “user risk” and “sign-in risk” conditions to determine the probability of a safe connection. Sign-in risk uses several signals in its analysis, including anonymous IP address information such as VPN or the Onion Router (Tor) network, malware-linked IP detection, suspicious browser clients and sign-in properties that don’t match the characteristics of previous attempts.
Microsoft determines user risk based on leaked credentials and Azure AD threat intelligence. Assigning a user-risk or sign-in requirement breaks down to low, medium and high categories. A setting of high would enforce a policy if the user risk and/or the sign-in risk are high.
Policies can be for all device platforms or set to block a specific platform. Azure AD conditional access supports policy checks for Android, iOS, Windows phones, Windows and macOS devices via user-agent strings. User agent strings can be customized, so work in this area needs to be thorough and coupled with Intune device compliance for best results.
Location is another compliance check option. Locations refer to public IPv4 address information, GPS coordinates, countries and regions or unknown regions. For an organization with several field offices, you could limit logins to known corporate IPs.
Filter access to privileged resources
A new feature called “filter for devices” creates policies to allow or block specific devices based on detailed criteria related to devices in the organization, which could be ideal for scenarios to restrict access to sensitive applications.
The following screenshot shows a policy that allows only one machine to connect to a specific application. It’s one example of how granular the policy can be to protect certain assets.
The Azure AD portal offers extensive filtering capabilities
For most organizations, conditional access policies will be a retrofit option because many will already be using several cloud applications, such as Office 365, Salesforce and Workday.
A little perspective here may help: My organization has more than 700 cloud applications and 20,000 users. We use conditional access extensively, but to get started we had to set up many policies, test the impact and then scale up. We now have about 25 conditional access policies to cover the range of applications we protect.
The Azure AD portal has extensive abilities to determine conditional access policies applied for login attempts. Microsoft captures detailed login information for each user and device, including what occurred and at what time. Comprehensive filtering and sorting capabilities find a range of activities, including login attempts for users, time ranges, applications, IP address information, login success and failures, with little effort.
Don’t let security lag after a move to the cloud
Conditional access policies give administrators an array of options previously unavailable in traditional on-premises networks. Conditional access help IT enforce compliance for logins to much higher standards. By utilizing the range of features — MFA, real-time risk analysis, extensive logging, filtering for devices — admins will have some peace of mind knowing they have done their utmost to protect the company.