In the past, company IT worked with a simple picture: Inside, behind the firewall, it is safe, outside it is dangerous. Today people work from anywhere, and data lives in the cloud rather than only in the company network. The picture of the safe castle no longer holds. This lesson shows two ways of thinking with which Microsoft describes security, and a service that helps with putting them into practice in Azure.
The example is the made-up company Berger Logistik AG, which is moving its dispatching to Azure.
Zero Trust: never trust, always verify
Zero Trust is a security strategy, not a product and not a service. The core idea: A request isn't considered trustworthy just because it comes from the company network. Every request is treated as if it came from an uncontrolled network. In short: never trust, always verify.
Microsoft names three principles:
- Verify explicitly: Always authenticate and authorize based on all available data, such as user identity, location, device state and the type of workload.
- Use least privilege access: Limit access, for example through permissions only for the time and scope someone needs, and through risk-based policies.
- Assume breach: Keep the impact of a breach small, divide access into segments, verify end-to-end encryption and detect threats with analytics.
You already know the building blocks from the previous lesson: Conditional Access verifies explicitly, Azure RBAC with small scopes implements least privilege. Zero Trust, by the way, doesn't replace the foundations of security, it builds on them.
Defense in depth: protection in layers
The second model is called defense in depth. A series of protective measures is meant to slow the advance of an attack. Picture layers around the data: If an attack gets through one layer, the next is already waiting. You never rely on a single protective measure, an attack gets slower, and security teams get warnings they can react to.
There are seven layers, from the outside in:
| Layer | Purpose | Example |
|---|---|---|
| Physical security | Protecting the hardware in the datacenter | Access control to buildings and hardware |
| Identity and access | Securing identities, giving only necessary access | Single sign-on, multifactor authentication, logging of changes |
| Perimeter | Protection against network-based attacks | Protection against distributed denial-of-service (DDoS) attacks, firewalls at the edge |
| Network | Limiting communication to what is necessary | Segmentation, deny by default |
| Compute | Securing compute resources and virtual machines | Securing access to VMs, keeping systems up to date |
| Application | Keeping applications free of vulnerabilities | Secrets in a secure store such as Azure Key Vault |
| Data | Controlling access to the data | Encryption at rest and in transit |
In the middle lies the data, because attackers are almost always after it: data in databases, on disks of virtual machines, in Software-as-a-Service applications or in cloud storage.
The two models complement each other. Defense in depth asks: Which layers stand between the attack and the data? Zero Trust asks: Why should I trust this request? The one is a structure, the other a stance.
Microsoft Defender for Cloud
Microsoft Defender for Cloud is the Azure service that shows security across your resources and helps improve it. It works for Azure, for on-premises servers and for other clouds such as AWS and Google Cloud. It has two main tasks:
- Improving the security posture (Cloud Security Posture Management, CSPM): Defender for Cloud continuously checks your resources against security standards and gives recommendations where something is misconfigured. The Secure Score sums this up in one number: The higher it is, the lower the detected risk. The basic functions, called Foundational CSPM, are free. A paid plan, Defender CSPM, brings further capabilities.
- Protecting workloads (Cloud Workload Protection, CWPP): For servers, containers, storage, databases and more there are protection plans of their own, such as Defender for Servers, Defender for Storage or Defender for Containers. They detect threats and generate security alerts with a severity and hints for remediation.
So Defender for Cloud is neither a firewall nor a virus scanner, but the place that assesses configuration and reports attacks.
Common misunderstandings
- Zero Trust is not a product. You can't buy it, only implement it step by step, with services such as Conditional Access, RBAC and encryption.
- One layer is never enough. Even the best firewall replaces neither strong sign-in nor updated servers. Defense in depth means precisely that each layer catches the failure of the others.
- Microsoft secures the datacenter. The physical layer is part of Microsoft's tasks in Azure. Identity, configuration and data remain yours.
- Defender for Cloud doesn't replace planning. The service assesses and warns. People implement the recommendations.
The example of Berger Logistik AG
Dispatching runs in virtual machines, and data lives in a storage account. Zero Trust here means: Employees sign in with MFA, Conditional Access checks the device, and every role applies only to the dispatching resource group. Defense in depth means: Microsoft secures the datacenter physically, IT protects identities, separates networks, keeps the servers up to date, stores secrets in Key Vault and encrypts the data. Defender for Cloud shows the Secure Score and reports that a storage account is still publicly reachable.
Exercise 1
Match each measure with a layer of defense in depth and say whether a Zero Trust principle is more likely behind it:
- A password for the database is in Azure Key Vault instead of in the program code.
- All sign-ins demand MFA.
- A network segment for accounting may talk only to the invoice server.
- A protection filters large waves of attacks before they reach the website.
Solution 1
- Application layer. Secrets belong in a secure store. A Zero Trust principle is not in the foreground here.
- Identity and access layer. Zero Trust: verify explicitly, because a password alone is not enough.
- Network layer. Communication is limited to what is necessary. Zero Trust: assume breach and least privilege, because a breach should stay in one segment.
- Perimeter layer. Protection against DDoS attacks is the classic task of the perimeter. Here, too, no Zero Trust principle is in the foreground.