Zero Trust - How To Start With Microsoft Azure
Zero Trust is all the hype right now and if you ask 5 people for a definition and you will get at least 6 different answers.
But instead of coming up with yet another definition, let’s use NIST’s?
“Zero trust (ZT) is the term for an evolving set of cybersecurity paradigms that move defences from static, network-based perimeters to focus on users, assets, and resources. A zero trust architecture (ZTA) uses zero trust principles to plan industrial and enterprise infrastructure and workflows. Zero trust assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location (i.e., local area networks versus the internet) or based on asset ownership (enterprise or personally owned). Authentication and authorisation (both subject and device) are discrete functions performed before a session to an enterprise resource is established.”
*TL;DR*: Trust nobody, verify everything.
Build a strong foundation
A good reminder for everybody is that you cannot build a house on a wonky foundation. Before you get started with Zero-Trust, it’s important to secure your foundations. Here are some good, often free and fairly simple steps to strengthen any cloud implementation.
Multi-Factor Authentication
Ensure everybody logging in to systems using their Microsoft Azure AD identity is also prompted for MFA, no exception.
Read Microsoft's guide on how to plan and implement an MFA deployment.
Apply least privilege principles to all identities and define firefighter ID’s, or develop processes to temporarily elevate access.
Review permissions and by default grant the lowest permissions possible. Apply this from the front desk to the system admins buried in the back-of-house.
Read Microsoft's privileged accounts guidance including Azure AD Privileged Identity Management.
Apply network segmentation when designing your cloud to reduce the blast radius in case of a breach. Datacenter network administrators have designed like this for decades. Talk to someone who has done this before and they will be able to explain VLANs and subnets to you.
Encrypt communication between any part of a network or parts of a single application. Most cloud services support this out of the box. Just because something communicates in "your virtual network" it should not communicate unencrypted. Encryption is free on all clouds!
Avoid legacy authentication like Windows Active Directory, and use modern authentication and short-lived Azure AD credentials.
You can even start issuing U2F keys and go passwordless.
Some of these require a mindset change which will already set you up to be ready to think beyond these foundational aspects of cloud and identity security.
There's no point working on "zero trust" if you do not implement the above. Starting with these steps first will make a much easier task later.
What next?
Under "Zero Trust" principles, every API must undergo a full authentication and authorisation cycle for every call it receives.
This does not mean that the platform will present the user with a new MFA or password prompt all the time. Rather, the user-created credentials/token are verified and validated every time an API is executed on that user's behalf.
Here are some next steps to consider:
Take inventory of your cloud applications.
One cannot transform what one does not know about. Or, one cannot secure what one does not know about.
Understand all your applications that run on the cloud.
What do they do?
Who has access and at what level?
How does authentication to those applications work?
Review each application and ask yourself "From a security point of view, what would need to be true for this application to live on the internet?".
This question applies to everything that is part of the application. Every single API call.
"The App Service is in a VNET" is not an excuse for proper authentication.
Select a high worth, low effort application and start transforming/securing it.
A practical example
Microsoft Azure hosts our application and runs a static website frontend. An Azure Function App with several distinct Azure Functions for each component of the application serves the backend. A SQL Server backend provides data to the functions.
Traditionally, a user would log in to a frontend and be presented with the application. All future API calls would assume that because the user was able to log in to the front end that they would also be allowed to execute all the other APIs. So, why have each API authenticate and authorise the user again?
Remember when most of us worked in an office with the swipe cards & lanyards that we had to wear "on our person at all times". This applies the same principle as we are suggesting with APIs. A passcard allowed us to login as we come through the front door. The colour of the lanyard defined our role (visitor, permanent, restricted area). But importantly, we were re-authenticated as we moved from area to area or office to office.
Without re-authentication, you are leaving doors unlocked for competitors, thieves or malicious actors to just wander in. They have everything they need to take a look and potentially damage your business.
The same is true of many applications. Finding a way around the initial "login step" opens a free-for-all. In the cloud, you are often only a simple misconfiguration away from exposure. It requires extra attention.
Why is this important?
Most Cloud and PaaS services are publicly accessible (on the internet) by default. This includes Azure Storage Accounts, Azure Functions, Azure App Services, Azure Kubernetes Services, Azure SQL Databases and many other similar services from other cloud providers.
This is not a bad thing, just something that a lot of "cloud beginners" are not very aware of and others occasionally forget.
Microsoft Azure gives us all the tools and capabilities to rapidly build very secure applications, even with publicly accessible APIs. All we need to do is use them and apply some / all the principles above to ensure they are secure and stable.