Welcome to “Zero Trust and Defense in Depth on Azure”. I’m Guy Hummel. To get the most from this course, you should already have some knowledge of Azure’s security services. If you don’t, then you can take our “Overview of Azure Active Directory” and “A Quick Introduction to Role-Based Access Control on Azure”.

In the past, many organizations focused their security efforts on keeping hackers out of their networks by relying on firewalls and other security systems on the perimeter of their networks. Users and devices that were inside the perimeter were treated with a certain level of trust because they were assumed to be legitimate.

This approach is flawed because if a hacker manages to get past your perimeter security, they can do a lot of damage. Even if you manage to keep hackers out, you’ll still face a threat from employees who act in bad faith.

A better approach is called “zero trust”, which means you don’t trust anyone, regardless of whether they’re inside or outside your perimeter. There are different principles you could use for designing and implementing a zero-trust architecture, but here are the ones that Microsoft uses:

• Verify explicitly
• Use “least privilege” access, and
• Assume breach

What they mean by “verify explicitly” is to verify a user’s identity and access permissions based on all relevant data points. For example, rather than just relying on a user entering the right user ID and password, you should also enforce conditional access based on the user’s device and location. You should also take into account the user’s behavior before granting access by using a tool such as Identity Protection. And you should take extra precautions before granting administrator access by using services such as Privileged Identity Management.

Next, the principle of least privilege says that you should only grant the bare minimum level of access that’s needed for a particular task. For example, if a user or application needs access to an Azure SQL Database instance, they should be granted the SQL DB Contributor role rather than the more general Contributor role, and they should be granted that role only for that specific database instance rather than assigning that role at the resource group, subscription, or management group level. 

Once again, you should be very careful when granting administrator access. One way to limit the risk is to use just-in-time access, which is a feature of Privileged Identity Management.

Finally, the phrase “assume breach” sounds kind of weird, but what it means is: assume that your network and/or your identities have been breached (that is, compromised). If you make this assumption, then you’ll design your architecture in such a way that it will limit the damage caused by an attack on your infrastructure. This is known as minimizing the blast radius.

The idea is that access is controlled for each element of your infrastructure, so just because an attacker has access to one element, it doesn’t mean they’ll have access to other elements. You can also use other methods to make it more difficult for attackers, such as running threat detection services and ensuring that all of your network traffic is encrypted.

And that’s it for zero trust.