Früher galt in der Firmen-IT ein einfaches Bild: Drinnen, hinter der Firewall, ist es sicher, draußen ist es gefährlich. Heute arbeiten Menschen von überall, und Daten liegen in der Cloud statt nur im Firmennetz. Das Bild von der sicheren Burg trägt nicht mehr. Diese Lektion zeigt zwei Denkmodelle, mit denen Microsoft Sicherheit beschreibt, und einen Dienst, der in Azure beim Umsetzen hilft.

Als Beispiel dient die erfundene Berger Logistik AG, die ihre Disposition nach Azure verlegt.

Zero Trust: nie vertrauen, immer prüfen

Zero Trust ist eine Sicherheitsstrategie, kein Produkt und kein Dienst. Der Kerngedanke: Eine Anfrage wird nicht deshalb für vertrauenswürdig gehalten, weil sie aus dem Firmennetz kommt. Jede Anfrage wird so behandelt, als käme sie aus einem unkontrollierten Netz. Kurz: nie vertrauen, immer prüfen.

Microsoft nennt drei Grundsätze:

  1. Explizit prüfen (verify explicitly): Immer anhand aller verfügbaren Daten authentifizieren und autorisieren, etwa Benutzeridentität, Standort, Gerätezustand und die Art der Arbeitslast.
  2. Geringste Rechte verwenden (use least privilege access): Zugriffe begrenzen, zum Beispiel durch Rechte nur für die Zeit und den Umfang, die jemand braucht, und durch risikobasierte Richtlinien.
  3. Einen Einbruch annehmen (assume breach): Die Auswirkung eines Einbruchs klein halten, den Zugriff in Segmente teilen, Verschlüsselung durchgängig prüfen und mit Auswertungen Bedrohungen erkennen.

Sie kennen die Bausteine bereits aus der vorigen Lektion: Conditional Access prüft explizit, Azure RBAC mit kleinen Bereichen setzt die geringsten Rechte um. Zero Trust ersetzt übrigens die Grundlagen der Sicherheit nicht, es baut auf ihnen auf.

Defense in Depth: Schutz in Schichten

Das zweite Modell heißt Defense in Depth, auf Deutsch gestaffelte Verteidigung. Eine Reihe von Schutzmaßnahmen soll den Vormarsch eines Angriffs bremsen. Stellen Sie sich Schichten um die Daten vor: Gelingt ein Angriff durch eine Schicht, steht die nächste schon bereit. Man verlässt sich nie auf eine einzige Schutzmaßnahme, ein Angriff wird langsamer, und Sicherheitsteams bekommen Warnungen, auf die sie reagieren können.

Es sind sieben Schichten, von außen nach innen:

Schicht Aufgabe Beispiel
Physische Sicherheit Schutz der Hardware im Rechenzentrum Zugangskontrolle zu Gebäuden und Hardware
Identität und Zugriff Identitäten sichern, nur nötigen Zugriff geben Single Sign-on, Multifaktor-Authentifizierung, Protokollierung von Änderungen
Perimeter Schutz vor netzbasierten Angriffen Schutz vor verteilten Überlastungsangriffen (DDoS), Firewalls am Rand
Netzwerk Kommunikation auf das Nötige beschränken Segmentierung, standardmäßig verbieten
Compute Rechenressourcen und virtuelle Maschinen absichern Zugriff auf VMs sichern, Systeme aktuell halten
Anwendung Anwendungen frei von Schwachstellen halten Geheimnisse in einem sicheren Speicher wie Azure Key Vault
Daten Zugriff auf die Daten steuern Verschlüsselung gespeichert und beim Übertragen

In der Mitte liegen die Daten, denn auf sie haben es Angreifer fast immer abgesehen: Daten in Datenbanken, auf Platten von virtuellen Maschinen, in Software-as-a-Service-Anwendungen oder im Cloudspeicher.

Die beiden Modelle ergänzen sich. Defense in Depth fragt: Welche Schichten stehen zwischen Angriff und Daten? Zero Trust fragt: Warum soll ich dieser Anfrage vertrauen? Das eine ist ein Aufbau, das andere eine Haltung.

Microsoft Defender for Cloud

Microsoft Defender for Cloud ist der Azure-Dienst, der Sicherheit über Ihre Ressourcen hinweg zeigt und verbessern hilft. Er funktioniert für Azure, für lokale Server und für andere Clouds wie AWS und Google Cloud. Er hat zwei Hauptaufgaben:

  • Sicherheitslage verbessern (Cloud Security Posture Management, CSPM): Defender for Cloud prüft Ihre Ressourcen laufend gegen Sicherheitsstandards und gibt Empfehlungen, wo etwas falsch konfiguriert ist. Die Secure Score fasst das zu einer Zahl zusammen: Je höher sie ist, desto geringer das erkannte Risiko. Die Grundfunktionen, genannt Foundational CSPM, sind kostenlos. Ein kostenpflichtiger Plan, Defender CSPM, bringt weitere Fähigkeiten.
  • Arbeitslasten schützen (Cloud Workload Protection, CWPP): Für Server, Container, Speicher, Datenbanken und mehr gibt es eigene Schutzpläne, etwa Defender for Servers, Defender for Storage oder Defender for Containers. Sie erkennen Bedrohungen und erzeugen Sicherheitswarnungen mit Schweregrad und Hinweisen zur Abhilfe.

Defender for Cloud ist also weder Firewall noch Virenscanner, sondern die Stelle, die Konfiguration bewertet und Angriffe meldet.

Typische Missverständnisse

  • Zero Trust ist kein Produkt. Man kann es nicht kaufen, nur Schritt für Schritt umsetzen, mit Diensten wie Conditional Access, RBAC und Verschlüsselung.
  • Eine Schicht reicht nie. Auch die beste Firewall ersetzt weder starke Anmeldung noch aktualisierte Server. Defense in Depth heißt gerade, dass jede Schicht einen Ausfall der anderen auffängt.
  • Das Rechenzentrum sichert Microsoft. Die physische Schicht gehört bei Azure zu Microsofts Aufgaben. Identität, Konfiguration und Daten bleiben Ihre.
  • Defender for Cloud ersetzt keine Planung. Der Dienst bewertet und warnt. Die Empfehlungen setzen Menschen um.

Das Beispiel der Berger Logistik AG

Die Disposition läuft in virtuellen Maschinen, Daten liegen in einem Speicherkonto. Zero Trust bedeutet hier: Mitarbeitende melden sich mit MFA an, Conditional Access prüft das Gerät, und jede Rolle gilt nur für die Ressourcengruppe der Disposition. Defense in Depth bedeutet: Das Rechenzentrum sichert Microsoft physisch, die IT schützt Identitäten, trennt Netze, hält die Server aktuell, legt Geheimnisse in Key Vault ab und verschlüsselt die Daten. Defender for Cloud zeigt die Secure Score und meldet, dass ein Speicherkonto noch öffentlich erreichbar ist.

Übung 1

Ordnen Sie jede Maßnahme der Schicht von Defense in Depth zu und sagen Sie, ob dahinter eher ein Zero-Trust-Grundsatz steckt:

  1. Ein Passwort für die Datenbank liegt in Azure Key Vault statt im Programmcode.
  2. Alle Anmeldungen verlangen MFA.
  3. Ein Netzsegment für die Buchhaltung darf nur mit dem Rechnungsserver sprechen.
  4. Ein Schutz filtert große Angriffswellen, bevor sie die Website erreichen.

Lösung 1
  1. Anwendungsschicht. Geheimnisse gehören in einen sicheren Speicher. Ein Zero-Trust-Grundsatz steht hier nicht im Vordergrund.
  2. Schicht Identität und Zugriff. Zero Trust: explizit prüfen, denn ein Passwort allein genügt nicht.
  3. Netzwerkschicht. Kommunikation wird auf das Nötige beschränkt. Zero Trust: Einbruch annehmen und geringste Rechte, weil ein Einbruch in einem Segment bleiben soll.
  4. Perimeterschicht. Der Schutz vor DDoS-Angriffen ist die klassische Aufgabe des Perimeters. Auch hier steht kein Zero-Trust-Grundsatz im Vordergrund.