Je mehr Menschen in Azure Ressourcen anlegen, desto wichtiger werden Regeln: Welche Regionen sind erlaubt? Welche Daten sind sensibel? Wie verhindern wir, dass jemand versehentlich die Produktionsdatenbank löscht? Diese Fragen gehören zu Governance (Steuerung nach festen Regeln) und Compliance (Einhaltung von Vorgaben). In dieser Lektion lernen Sie drei Werkzeuge kennen: Microsoft Purview, Azure Policy und Ressourcensperren.
Das Beispiel ist die erfundene Hartmann Medizintechnik AG, die sensible Daten verarbeitet und deshalb besonders aufpassen muss.
Microsoft Purview: die eigenen Daten kennen
Microsoft Purview ist eine Familie von Lösungen für Datenverwaltung, Risiko und Compliance. Sie liefert eine einheitliche Sicht auf Daten, egal ob sie lokal liegen, in mehreren Clouds oder in Software-as-a-Service-Anwendungen. Drei Fähigkeiten stehen im Mittelpunkt:
- Automatische Datenerkennung: Purview findet, wo Daten liegen.
- Klassifizierung sensibler Daten: Es erkennt, welche Daten sensibel sind.
- Durchgängige Datenherkunft (data lineage): Es zeigt, woher Daten kommen und wohin sie fließen.
Zwei Lösungsbereiche gehören dazu. Risiko und Compliance hilft, sensible Daten über Clouds, Apps und Geräte hinweg zu schützen, Datenrisiken zu erkennen und gesetzliche Vorgaben zu erfüllen. Hier spielt Microsoft 365 mit Teams, OneDrive und Exchange eine wichtige Rolle. Einheitliche Datenverwaltung (unified data governance) erstellt eine aktuelle Karte der gesamten Datenlandschaft samt Klassifizierung, zeigt, wo sensible Daten liegen, und verwaltet den Zugriff darauf sicher und in großem Umfang.
Purview beantwortet also die Frage: Welche Daten haben wir, wie sensibel sind sie, und wohin fließen sie?
Azure Policy: Regeln für Ressourcen
Azure Policy erstellt, weist zu und verwaltet Richtlinien, die Ihre Ressourcen kontrollieren oder prüfen. Die Konfiguration von Ressourcen soll mit Ihren Standards übereinstimmen. Beispiele für Regeln:
- Virtuelle Maschinen dürfen nur bestimmte Größen haben.
- Ressourcen dürfen nur in bestimmten Regionen liegen.
- Jede neue Ressource braucht einen Tag
Owner.
Was Azure Policy kann:
- Bewerten und anzeigen. Es prüft Ihre Ressourcen und zeigt die, die gegen eine Richtlinie verstoßen. Das gilt auch für Ressourcen, die vor der Richtlinie entstanden sind.
- Verhindern. Es kann verhindern, dass nicht konforme Ressourcen überhaupt angelegt werden.
- Nachbessern. In manchen Fällen korrigiert es nicht konforme Ressourcen selbst, etwa indem es einen fehlenden Tag ergänzt. Einzelne Ressourcen lassen sich als Ausnahme markieren.
Richtlinien lassen sich auf jeder Ebene festlegen: auf einer Ressource, einer Ressourcengruppe, einem Abonnement. Sie werden vererbt. Eine Richtlinie auf einer Ressourcengruppe gilt für alle Ressourcen darin. Azure bringt eingebaute Definitionen mit, zum Beispiel für Speicher, Netzwerk, Compute und Überwachung.
Eine Initiative fasst zusammen, was zusammengehört: eine Gruppe verwandter Richtlinien für ein größeres Ziel. Wenn Sie den Stand eines Ziels wie „Überwachung aktivieren“ verfolgen wollen, bewerten Sie eine Initiative statt vieler einzelner Richtlinien.
Ressourcensperren: Schutz vor Versehen
Auch mit Zugriffsrechten kann jemand mit ausreichendem Zugriff eine wichtige Ressource löschen. Eine Ressourcensperre (resource lock) verhindert das. Es gibt zwei Arten:
| Sperre | Lesen | Ändern | Löschen |
|---|---|---|---|
| Delete (Löschschutz) | ja | ja | nein |
| ReadOnly (Schreibschutz) | ja | nein | nein |
ReadOnly wirkt, als hätten alle Berechtigten nur die Rolle Reader: Sie dürfen lesen, aber weder ändern noch löschen. Sperren lassen sich auf eine einzelne Ressource, eine Ressourcengruppe oder ein ganzes Abonnement legen und werden vererbt. Sie gelten unabhängig von den RBAC-Rechten: Auch ein Owner muss die Sperre zuerst entfernen, bevor er die blockierte Aktion ausführen kann. Das ist der zweistufige Weg: Sperre entfernen, dann ändern. Verwalten können Sie Sperren im Portal, mit PowerShell, der Azure CLI oder in Vorlagen.
Drei Werkzeuge, drei Fragen
| Werkzeug | Frage | Wirkt auf |
|---|---|---|
| Azure RBAC | Wer darf was? | Personen, Gruppen, Anwendungen |
| Azure Policy | Wie müssen Ressourcen beschaffen sein? | Konfiguration der Ressourcen |
| Ressourcensperre | Soll sich diese Ressource überhaupt ändern lassen? | Einzelne Ressourcen und Bereiche |
Policy und Sperren ergänzen die Rechte: Die Rechte regeln, wer handeln darf, die Richtlinie, wie das Ergebnis aussehen muss, und die Sperre schützt vor Löschen oder Ändern, auch wenn jemand dazu berechtigt wäre.
Typische Verwechslungen
- Purview ist keine Richtlinie. Purview kennt und klassifiziert Daten. Dass Ressourcen bestimmte Einstellungen haben müssen, regelt Azure Policy.
- Eine Richtlinie wirkt auch rückwirkend. Azure Policy bewertet bestehende Ressourcen mit und zeigt, welche nicht passen.- Eine Sperre ist kein Zugriffsrecht. Sie ändert nicht, wer berechtigt ist, sondern was mit der Ressource überhaupt geschehen kann, solange sie liegt.
- Vererbung gilt für beides. Eine Richtlinie oder Sperre auf einer Ressourcengruppe trifft alle Ressourcen darin, auch spätere.
Das Beispiel der Hartmann Medizintechnik AG
Purview zeigt der Firma, wo sensible Daten liegen. Azure Policy erlaubt Ressourcen nur in den vorgesehenen Regionen und verlangt den Tag Owner. Auf die Ressourcengruppe der Produktionsdatenbank legt die IT eine Sperre vom Typ Delete.
Übung 1
Entscheiden Sie bei jedem Fall, ob Purview, Azure Policy oder eine Ressourcensperre passt:
- Neue Ressourcen sollen nur in zwei erlaubten Regionen angelegt werden können.
- Die IT-Leitung will wissen, in welchen Datenspeichern des Unternehmens sensible Daten liegen.
- Die Konfiguration der Produktionsdatenbank soll geändert werden können, die Datenbank selbst aber nicht versehentlich gelöscht werden.
- Ein Archivspeicher soll weder geändert noch gelöscht werden, auch nicht vom Owner.
Lösung 1
- Azure Policy. Eine Richtlinie für erlaubte Regionen kann nicht konforme Ressourcen verhindern.
- Microsoft Purview. Datenerkennung und Klassifizierung sensibler Daten sind sein Zweck.
- Sperre vom Typ Delete. Lesen und Ändern bleiben möglich, das Löschen nicht.
- Sperre vom Typ ReadOnly. Sie verbietet Ändern und Löschen und gilt auch für den Owner. Er müsste sie erst entfernen.