Ressourcentags und Ressourcensperren

Ressourcen-Tags sind Name-Wert-Paare mit Metadaten, die Sie Azure-Ressourcen, Ressourcengruppen und Abonnements zuordnen. Im Gegensatz zu Ordnerstrukturen ermöglichen Tags, eine einzelne Ressource gleichzeitig nach mehreren Dimensionen zu kategorisieren. Eine VM kann beispielsweise gleichzeitig die Tags Environment=Production, Team=Backend, CostCentre=CC-042 und Project=Phoenix haben. Dadurch kann unabhängig nach jeder dieser Dimensionen gefiltert werden.

Organisationen definieren in der Regel eine standardisierte Tag-Taxonomie, die mehrere Dimensionen abdeckt. Finanz-Tags (CostCentre, BudgetOwner) ermöglichen die Kostenverteilung. Betriebliche Tags (Environment, Criticality, Owner) unterstützen Filterung und Benachrichtigungen. Lebenszyklus-Tags (AutoShutdown, ExpiryDate) ermöglichen Automatisierung. Sicherheits-Tags (DataClassification, Compliance) unterstützen Sicherheitstools. Wenn Sie die Taxonomie vor der Bereitstellung von Ressourcen definieren, verhindern Sie eine inkonsistente und nicht abfragbare Tag-Landschaft.

Tags können über das Azure-Portal, die CLI, ARM-Vorlagen, Bicep und Terraform angewendet werden. Der Befehl az tag verwaltet Tags für Ressourcen, während az group update Ressourcengruppen mit Tags versieht. Mit Azure Policy und dem Effekt Modify oder Append können Sie Tags beim Erstellen von Ressourcen automatisch hinzufügen oder voraussetzen. So wird sichergestellt, dass jede neue Ressource über ein CostCentre-Tag verfügt, ohne darauf angewiesen zu sein, dass Entwickler daran denken, es manuell hinzuzufügen.

Ein häufiges Missverständnis besteht darin, dass Tags einer Ressourcengruppe automatisch an die darin enthaltenen Ressourcen weitergegeben werden. Das ist nicht der Fall – Azure-Ressourcen-Tags werden nicht von übergeordneten Bereichen geerbt. Wenn Sie eine Ressourcengruppe mit Environment=Production taggen, erhalten die VMs und Datenbanken in dieser Gruppe dieses Tag nicht automatisch. Um eine einheitliche Verwendung von Tags durchzusetzen, verwenden Sie eine Azure Policy mit der integrierten Definition Inherit a tag from the resource group. Dadurch wird das Tag der Ressourcengruppe automatisch in alle darin enthaltenen Ressourcen kopiert.

Tags sind besonders leistungsfähig in Verbindung mit Azure Cost Management. In der Ansicht zur Kostenanalyse können Sie Ausgaben nach jedem Tag-Schlüssel gruppieren – beispielsweise die monatlichen Gesamtausgaben nach CostCentre anzeigen, um zu sehen, welche Abteilung am meisten Cloud-Ressourcen nutzt. Sie können auch nach Environment=Production filtern, um Entwicklungsausgaben aus Produktionsbudgets auszuschließen. Azure Cost Management berücksichtigt ein Tag in den Kostendaten nur, wenn es vor Beginn des Abrechnungszeitraums angewendet wurde.

Ressourcensperren schützen Azure-Ressourcen vor versehentlichem Löschen oder Ändern – unabhängig davon, über welche RBAC-Berechtigungen ein Benutzer verfügt. Auch ein Benutzer mit den Rechten „Besitzer“ oder „Mitwirkender“ kann daran gehindert werden, eine gesperrte Ressource zu löschen oder zu ändern. Sperren werden auf Ressourcen-, Ressourcengruppen- oder Abonnementebene angewendet und nach unten weitergegeben. Eine Sperre für eine Ressourcengruppe schützt somit jede darin enthaltene Ressource.

Azure unterstützt zwei Sperrtypen. CanNotDelete (Löschsperre) ermöglicht Benutzern, die Ressource zu lesen und zu ändern, verhindert jedoch deren Löschung. Dies ist die am häufigsten verwendete Sperre. Sie wird auf Produktionsdatenbanken, Speicherkonten und VNets angewendet, um ein versehentliches Entfernen zu verhindern. ReadOnly verhindert alle Schreib- und Löschvorgänge, sodass sich die Ressource so verhält, als wäre allen Benutzern nur die Rolle „Leser“ zugewiesen. ReadOnly ist restriktiver und kann automatisierte Prozesse beeinträchtigen, die Ressourceneigenschaften aktualisieren.

Um eine gesperrte Ressource zu löschen oder zu ändern, muss ein Benutzer zunächst die Sperre entfernen. Dafür ist die Berechtigung Microsoft.Authorization/locks/delete erforderlich, die standardmäßig für die Rollen „Besitzer“ und „Benutzerzugriffsadministrator“ verfügbar ist. Das Entfernen der Sperre, die Änderung der Ressource und das optionale erneute Anwenden der Sperre können in einen Change-Management-Workflow integriert werden. So lassen sich geschützte Ressourcen weiterhin kontrolliert und mit einem Audit-Trail ändern.

Eine Sperre, die auf einen übergeordneten Bereich (Abonnement oder Ressourcengruppe) angewendet wird, wird von allen untergeordneten Ressourcen geerbt. Sie können eine Sperre auf einer niedrigeren Ebene nicht überschreiben. Wenn eine Ressourcengruppe beispielsweise über eine CanNotDelete-Sperre verfügt, können einzelne Ressourcen darin nicht gelöscht werden, selbst wenn sie nicht direkt mit einer Sperre versehen sind. Eine zusätzliche CanNotDelete-Sperre auf Ressourcenebene ändert das Verhalten nicht; die übergeordnete Sperre bietet bereits den erforderlichen Schutz.

ReadOnly-Sperren können in automatisierten Prozessen unerwartete Fehler verursachen. Einige Azure-Vorgänge, die auf den ersten Blick schreibgeschützt wirken, benötigen im Hintergrund tatsächlich Schreibzugriff auf Ressourceneigenschaften. Beispielsweise wird das Auflisten der Zugriffsschlüssel eines Speicherkontos durch eine ReadOnly-Sperre verhindert, da der Vorgang zur Auflistung der Schlüssel das Auditprotokoll des Kontos ändert. Auch das Skalieren einer VM, der Neustart eines App Service und das Anfügen eines Datenträgers an eine laufende VM werden blockiert. Testen Sie ReadOnly-Sperren in Nichtproduktionsumgebungen, bevor Sie sie auf kritische Ressourcen anwenden.

Die Kombination von Tags und Sperren ermöglicht ein leistungsfähiges Governance-Muster. Sie können ein Tag wie Protected=true verwenden, um Ressourcen zu kennzeichnen, für die CanNotDelete-Sperren gelten sollen. Anschließend können Sie ein Azure Automation Runbook ausführen, das nach Ressourcen mit diesem Tag sucht und die Sperre erstellt, falls sie fehlt. Dieses Muster einer selbstheilenden Governance stellt sicher, dass eine versehentlich von einem Administrator entfernte Sperre innerhalb des Zeitplans des Runbooks automatisch erneut angewendet wird.

Testen Sie Ihr Verständnis der Konzepte von Microsoft Azure Fundamentals (AZ-900) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: Ressourcen-Tags sind Metadatenpaare aus Name und Wert, die Kostenverteilung, Filterung und Automatisierung über beliebige Dimensionen hinweg ermöglichen, Tags werden nicht von übergeordneten Ressourcengruppen geerbt und müssen über Azure Policy durchgesetzt werden und Ressourcensperren (CanNotDelete und ReadOnly) schützen Ressourcen unabhängig von RBAC-Berechtigungen vor versehentlichen Änderungen. Als Nächstes befassen wir uns mit Azure Blueprints zum gemeinsamen Bündeln von Governanceartefakten.