Lessons in Azure Security, Part 1 — Tenant & Identity
Today as a fitting start to my new series we will be focusing on not leaving your front door open by implementing Azure Tenant & Identity Governance controls.
This is the first in a series (and my Medium career!) on lessons I have learnt in designing and operating a secure Microsoft Azure ecosystem. Throughout the series I will be focusing on quick wins that you should consider to harden your Azure deployment, from tenant controls through to resources and deployments.
So you’ve decided to start using Azure.. now what?
In Azure a tenant is the highest level of segregation in your environment, it is a dedicated and managed Azure Active Directory instance that is used to govern access to your cloud resources and subscriptions.
Loosely speaking there are two main types of users to care about within an Azure tenant:
- Member Users — These originate within the “home” tenant itself and may look like the following bob.jones@yourtenant.onmicrosoft.com, or users may be from any Azure registered custom domain such as belinda.jones@mycompany.net.
- Guest Users — These originate from other Azure Active Directory tenants, these could be companies you need to collaborate with or even users from other directories that your organisation manages.
From my experience organisations will tend to have a tenant that is aligned to their local on premise directory with access federation in place, however many organisations tend to have various other Azure Tenants at their disposal.
A logical place to start with your security journey is the Azure Tenant and effectively governing identities, as these can be seen as the “front door” to your cloud environment.
As this set up is responsible for authenticating stakeholders to administer cloud resources at the management plane, poor governance and control can be a a real sweet spot for attackers! So Don’t leave your front door open!
The Breakdown
Speaking from experience here are some items to consider when thinking about Azure Tenant & Identity Governance:
- Consult your Identity Secure Score — a great place to start on an existing tenant, by quickly viewing your current state of play to drive further improvements.
- Consider Enabling Security Defaults — for any new free tier tenants, or if you want to quickly establish a baseline on an existing tenant that has no access policies in place.
- Implement Custom Conditional Access Policies — there are many different uses of conditional access policies that will suit different needs, it’s essential that you carve an access baseline for your tenant.
- Review Collaboration Settings — if you are going to be collaborating with users from other tenants via Azure B2B it’s worth checking out collaboration settings.
- Use the power of Identity Governance — a more advanced yet powerful offering to deliver tightly controlled and time bound access packages for privileged Azure Identities.
Ready to dive into the detail? Lets go..
1. Consult your Identity Secure Score
Authenticate to your Azure Portal and head over to https://portal.azure.com/#blade/Microsoft_AAD_IAM/SecurityMenuBlade/IdentitySecureScore
This will give you a “Secure Score” rating and is a decent first crack at analysing the state of play within your Azure AD Tenant as seen below:
Clicking into an individual action will give you the following:
- Your current score vs Maximum Score
- A view of what will change and a step by step guide on how to change it.
- Potential impacts to users so you can work out the impact of applying the control.
Overall this is a great starting point for an existing tenant as it will allow you to work out the strength of your current identity controls within minutes and get some really good steer on how to solve them .. kudos to Microsoft!
Most of these findings can be resolved with a combination of tenant level settings and conditional access policies, some of which we will touch on further in this article.
2. Consider Enabling Security Defaults
Microsoft have packaged a series of access policies together under “Security Defaults”, which can be a great baseline for any new tenants, or any older tenants with no identity controls in place.
Note: Applying this setting should be carefully assessed for an existing Tenant to ensure you do not impact existing users!
To enable it head on over to https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Properties and select “Manage Security Defaults”
Note: These Security Defaults can not be used in parallel with custom conditional access policies, this can be a good quick win for free tier tenants, however more complex licensed tenants will likely need custom conditional access policies to meet the needs of various users — see point 3.
Security Defaults will enable the following features on your tenant (which also are good inspiration for custom conditional access policies!):
- All Users Must Register for MFA- This ensures all users register for MFA when accessing the tenant for the first time, making it less disruptive to roll out future MFA policies.
- All Tenant Administrators MUST use MFA- All privileged users with admin directory roles must use MFA for all Azure sessions.
- Blocking of Legacy Authentication Methods- These methods are more susceptible to compromise via man in the middle / brute force attacks, thus are blocked by policy.
- MFA Required for “High Risk” Logins- If login is noticed as anomalous then MFA will be required.
- Protecting Azure based operations- As Azure operations can be classed as highly privileged — require MFA for these.
Note: Microsoft is starting to role these out by default on newly created tenants, if you have existing tenants it’s worth checking that you are either covered by the baseline or need to implement some custom conditional access policies.
3. Implement Custom Conditional Access Policies
What is a Conditional Access Policy?
A Conditional Access Policy (CAP) allows access to Azure AD backed applications only when a “condition” is met. These conditions can be set in line with your security policies and can be scoped to particular user groups and access conditions.
These policies can be used to solve a variety of use cases, such as only allowing access to certain approved Microsoft Products and enforcing conditions for access such as using managed corporate devices, trusted locations and MFA.
A well designed implementation can help significantly mitigate risks around accessing and administering the cloud whilst not impacting user experience when not needed. They can also help meet regulatory & compliance demands in some industries.
Note: This feature requires Azure Active Directory P1 licences for users that will utilise access policies.
How does it work? The anatomy of a Conditional Access Policy
Conditional access policies are formed from both Assignments and Access controls that are defined within the policy.
Think of the assignment as the scope of the policy, and the access control as the resultant effect for assigned devices. This can also be described as an “if then” statement i.e if the assignment applies then apply the access control.
The Microsoft docs are a great start for building CAPs , however I have described the options available below as an additional point of reference.
Assignments
Assignments are a high level grouping of who and what the conditional access policy applies to and also who is excluded from it. This includes user groupings, applications and also device conditions.
- Users and Groups:
What sets of users and groups the policy will either include or exclude, this can be used to craft access requirements for particular stakeholder groups. You can also select directory roles and (should you wish) all users here. - Actions and Cloud Apps:
What Cloud Apps the policy applies to (or all), this allows you to fine grain policies for particular applications such as Azure Portal, PowerBi etc. - Conditions:
Conditions relate to the attributes of the device that is being used to access. This allows you to create various access policies based on the state of the device, this could include policies based on sign in risk, locations and device platform.
Access Controls
Access control is the resultant action for all devices that meet the criteria outlined in the assignment definition. This is where you state wether the policy will grant or deny access and also any additional controls that need to be met such as MFA / device state.
- Grant:
This is a critical part of the policy where you specify wether you should GRANT or DENY access, you can also add additional access controls here such as enforcing MFA, requiring hybrid AD compliant devices etc. - Session:
Optional session controls that can apply to the access policy, these can be used to control sign in frequency / persistent session length. It can also be used to proxy sessions through Microsoft Cloud App Security (MCAS), MCAS is a reverse application proxy that can be used to further control and monitor access to cloud applications.
Mode of Operation
Lastly you can select either “Report Only”, “On” or “Off” for your freshly created policy, Report Only is an audit only mode that can be used to analyse the affect of polices on real user data prior to enabling them.
Roll Out Tips
Based on experience its worth considering the following when rolling out your first polices:
- Don’t lock yourself out- When rolling out policies, specifically more complex ones, it is always worth excluding your administrators or break glass accounts from the policy so they can be rolled back should an issue occur.
- Exclusions are easier to maintain than inclusions- For key policies user groupings often change, so when scoping conditional access policies I always try apply to a broad scope (often all users) and then exclude groups where necessary.
- Trial policies in Report Only first- In order to minimise disruption test policies in report only first and observe in the Active Directory logs how it affects stakeholders prior to roll out.
- Apply a broad baseline policy- aim to apply a broad baseline policy to secure access to your Azure management plane, i’d suggest MFA from untrusted locations at a minimum.
How are multiple Conditional Access Policies Evaluated?
All relevant policies (up to 195) for a particular user will be merged together and applied for a particular cloud app — all policies must allow a GRANT in order for the user to be given access.
Common Conditional Access Polices to consider
- Blocking legacy authentication
- Blocking sign ins from untrusted geographies.
- Enforcing MFA for all admin roles.
- Enforcing managed corporate device for Azure access.
I appreciate that’s a lot of information covered on CAPs in this section, i’d suggest working out an appropriate baseline for your organisation based on user groupings and risk profiles and then iterating from there.
4. Review Collaboration Settings
Azure AD B2B (Business to Business) is a fantastic feature, it allows you to invite users from other Azure Tenants to collaborate on anything Microsoft has to offer (Power Platform, 365, Azure etc). This removes the need for managing in-house member identities for external users, and it keeps the authentication responsibility in the external users domain.
There are two main areas that you can harden for cross business collaboration:
- Ensure Conditional Access Policies cover External Identities
Once invited B2B users will use their home tenant to authenticate, however a key concept that is often overlooked is the following…
Conditional Access policies (ie MFA, Location) for B2B users is YOUR responsibility, it will not be inherited from the users home tenant.
If your B2B users are accessing sensitive data within your tenant, make sure your access policies are enforcing MFA at a minimum.
From what I understand Microsoft are working on cross-tenant trust features for 2021, this will allow you to trust the access policies evaluated at the B2B users home tenant. I’m really looking forward to this feature!!
2. Review your Tenants Collaboration Settings
Head on over to… https://portal.azure.com/#blade/Microsoft_AAD_IAM/CompanyRelationshipsMenuBlade/Settings
These options allow you to do the following:
- Restrict who can invite external users to your organisation, you may want to restrict this to individuals with the guest inviter role.
- Create an Allow list for external domains to collaborate with, this ensures you are only collaborating with trusted organisations and domains.
5. Use the power of Identity Governance
Microsoft is regularly releasing features to govern identities, including automating access reviews and creating pre-defined workflows for granting and revoking access. For the purposes of this article we will focus one feature Privileged Identity Management (PIM).
Note: This feature requires Azure Active Directory P2 licences for users who will be using just in time access to roles.
The first thing i’d recommend is heading over to Discover and Monitor, this will give you an instant drill down of some best practices around identity — such as your number of Global Admins, service principles with permissive access and users with permanent permissive role assignments.
PIM allows you to shift away from users with permanent administrative roles to defined, approved and time bound access for eligible identities, this provides a number of benefits:
- Administrative role access is time bound, reducing the risk in event of account compromise.
- Reduces risk associated with malicious insiders, as they need to follow approval workflows to use administrative access.
- Follows a “Break Glass” access model where people assume administrative roles when they really need it, as apposed to having it permanently.
- Alert workflows can be triggered when a privileged role is assigned, allowing for a response to suspicious privilege escalations.
This feature carries licence implications but is definitely worth considering to mature your Azure tenants identity governance, whilst also meeting regulatory requirements around privileged access management.
Whats up Next?
Thanks for reading my first Medium article, hopefully you’ve gained some useful insight on how to harden your Azure tenant and govern identities used to access cloud resources.
We started by using the identity secure score to identify areas of improvement, then discussed the Microsoft Security Defaults, moving into custom conditional access polices, external collaboration settings and finished off with a taste of Azure Privileged Identity Management (PIM).
This is just the tip of the iceberg when it comes to security in Azure, up next in the series we will drilling further into monitoring security events effectively.
Look out for Part 2 — Logging made simple
Please also check out some selected articles around the topics discussed below.
