The more people create resources in Azure, the more important rules become: Which regions are allowed? Which data is sensitive? How do we prevent someone from accidentally deleting the production database? These questions belong to governance (steering by fixed rules) and compliance (meeting requirements). In this lesson you get to know three tools: Microsoft Purview, Azure Policy and resource locks.

The example is the made-up Hartmann Medizintechnik AG, which processes sensitive data and therefore has to be especially careful.

Microsoft Purview: knowing your own data

Microsoft Purview is a family of solutions for data management, risk and compliance. It provides a unified view of data, whether it sits on premises, in several clouds or in software-as-a-service applications. Three capabilities are central:

  • Automatic data discovery: Purview finds where data lives.
  • Classification of sensitive data: It recognizes which data is sensitive.
  • End-to-end data lineage: It shows where data comes from and where it flows.

Two solution areas belong to it. Risk and compliance helps protect sensitive data across clouds, apps and devices, detect data risks and meet legal requirements. Microsoft 365 with Teams, OneDrive and Exchange plays an important role here. Unified data governance creates an up-to-date map of the entire data landscape including classification, shows where sensitive data lives, and manages access to it securely and at scale.

So Purview answers the question: What data do we have, how sensitive is it, and where does it flow?

Azure Policy: rules for resources

Azure Policy creates, assigns and manages policies that control or audit your resources. The configuration of resources should match your standards. Examples of rules:

  • Virtual machines may only have certain sizes.
  • Resources may only be located in certain regions.
  • Every new resource needs an Owner tag.

What Azure Policy can do:

  • Evaluate and display. It checks your resources and shows the ones that violate a policy. This also covers resources that were created before the policy.
  • Prevent. It can prevent noncompliant resources from being created at all.
  • Remediate. In some cases it corrects noncompliant resources itself, for example by adding a missing tag. Individual resources can be marked as an exemption.

Policies can be set at any level: on a resource, a resource group, a subscription. They are inherited. A policy on a resource group applies to all resources in it. Azure comes with built-in definitions, for example for storage, networking, compute and monitoring.

An initiative bundles what belongs together: a group of related policies for a larger goal. If you want to track the status of a goal such as "enable monitoring," you evaluate one initiative instead of many individual policies.

Resource locks: protection against mistakes

Even with access rights, someone with sufficient access can delete an important resource. A resource lock prevents that. There are two types:

Lock Read Change Delete
Delete (delete protection) yes yes no
ReadOnly (write protection) yes no no

ReadOnly acts as if all authorized users had only the Reader role: they may read, but neither change nor delete. Locks can be placed on a single resource, a resource group or a whole subscription and are inherited. They apply independently of the RBAC permissions: even an Owner must first remove the lock before they can perform the blocked action. That is the two-step path: remove the lock, then change. You can manage locks in the portal, with PowerShell, the Azure CLI or in templates.

Three tools, three questions

Tool Question Acts on
Azure RBAC Who may do what? People, groups, applications
Azure Policy How must resources be configured? The configuration of resources
Resource lock Should this resource be changeable at all? Individual resources and scopes

Policy and locks complement the permissions: the permissions regulate who may act, the policy what the result must look like, and the lock protects against deletion or change, even if someone would be authorized to do it.

Common mix-ups

  • Purview is not a policy. Purview knows and classifies data. Azure Policy regulates that resources must have certain settings.
  • A policy also works retroactively. Azure Policy also evaluates existing resources and shows which ones do not fit.
  • A lock is not an access right. It does not change who is authorized, but what can happen to the resource at all while it exists.
  • Inheritance applies to both. A policy or lock on a resource group affects all resources in it, including later ones.

The example of Hartmann Medizintechnik AG

Purview shows the company where sensitive data lives. Azure Policy allows resources only in the intended regions and requires the Owner tag. On the resource group of the production database, IT places a lock of the Delete type.

Exercise 1

For each case, decide whether Purview, Azure Policy or a resource lock fits:

  1. New resources should only be creatable in two allowed regions.
  2. The head of IT wants to know in which of the company's data stores sensitive data lives.
  3. The configuration of the production database should be changeable, but the database itself must not be deleted by accident.
  4. An archive storage should be neither changed nor deleted, not even by the Owner.

Solution 1
  1. Azure Policy. A policy for allowed regions can prevent noncompliant resources.
  2. Microsoft Purview. Data discovery and classification of sensitive data are its purpose.
  3. Lock of the Delete type. Reading and changing remain possible, deleting does not.
  4. Lock of the ReadOnly type. It forbids changing and deleting and also applies to the Owner. They would have to remove it first.