Azure-Sicherheit bedeutet heute, produktive Cloud-Plattformen mit gemeinsam genutzten Identitäten, Netzwerken, Datenflüssen und Automatisierung kontrollierbar, nachvollziehbar und belastbar zu betreiben.
Letzte Überarbeitung: 2026. Der Schwerpunkt dieses Artikels liegt auf produktiven Azure-Umgebungen, Landing Zones und Workloads in Microsoft Azure. Hybrid- und On-Premises-Szenarien werden nur dort berührt, wo sie für Identität, Netzwerkverbindungen oder Security Monitoring in Azure relevant sind.
Azure-Sicherheit beginnt mit dem geteilten Verantwortungsmodell. Microsoft schützt die physische Infrastruktur, zentrale Cloud-Dienste und viele Plattformkomponenten; Kundinnen und Kunden bleiben verantwortlich für Identitäten, Berechtigungen, Datenklassifizierung, Netzwerkkonfiguration, Workload-Härtung, Logging und Reaktion auf Vorfälle. In der Praxis scheitern Sicherheitsprogramme selten daran, dass ein einzelnes Feature fehlt. Häufiger fehlen klare Standards, konsistente Durchsetzung und ein Betrieb, der Abweichungen erkennt, bevor daraus ein Sicherheitsvorfall wird.
Zero Trust ist deshalb der rote Faden: keine implizite Vertrauensstellung allein aufgrund eines Netzwerks, einer Rolle oder eines früheren Logins. Jede Anfrage sollte anhand von Identität, Gerätezustand, Kontext, Berechtigung und Risiko bewertet werden. Für Azure bedeutet das, den Tenant, Management Groups, Subscriptions, Netzwerke, Workloads und Datenquellen gemeinsam zu betrachten, statt Security Controls isoliert pro Ressource zu konfigurieren.
Die Sicherheitsgrundlage: Tenant, Landing Zone und Verantwortlichkeiten
Eine belastbare Azure-Sicherheitsarchitektur beginnt oberhalb einzelner Ressourcen. Management Groups, Subscriptions, Namenskonventionen, Tags, Azure Policy, Rollenmodelle und Netzwerkzonen bilden die Sicherheitsleitplanken, die später für Workloads gelten. Wer diese Ebene überspringt, landet schnell bei manuellen Ausnahmen, uneinheitlichen Diagnostic Settings und Berechtigungen, die niemand mehr sauber erklären kann.
Das Azure Virtual Network ist dabei der zentrale Baustein für private Kommunikation, Segmentierung und kontrollierte Erreichbarkeit. Ein Azure Virtual Network trennt Workload-Bereiche, ermöglicht private Adressräume, Peering, Routing und die Integration mit lokalen Netzen. Sicherheit entsteht aber erst durch das Zusammenspiel mit Network Security Groups, Application Security Groups, User-Defined Routes, Private Endpoints und zentralen Kontrollpunkten wie Azure Firewall oder Web Application Firewall.
Ein häufiger Fehler besteht darin, Subnetze als reine Netzwerkstruktur zu sehen. In einer sicheren Landing Zone sind Subnetze auch Sicherheitsgrenzen: Datenbanken liegen anders als Web-Tiers, Management-Zugänge anders als Applikationszugänge, und Plattformdienste werden möglichst über Private Endpoints angebunden. Public Network Access sollte für sensible Dienste nicht der Standard bleiben, nur weil es die erste Bereitstellung vereinfacht.
Warum das wichtig ist: Eine gute Azure-Architektur reduziert die Zahl der Orte, an denen Sicherheit manuell entschieden werden muss. Wenn Netzwerke, Identitäten, Policies und Monitoring auf Plattformebene vorbereitet sind, muss ein einzelnes Produktteam nicht jedes Kontrollmuster neu entwerfen.
Identität ist der wichtigste Sicherheitsperimeter
In Azure ist Identität meist näher am Risiko als das Netzwerk. Administratoren, Entwickler, Automatisierungskonten, Workload-Identitäten und externe Gastbenutzer können Ressourcen ändern, Daten lesen oder Sicherheitskontrollen deaktivieren. Microsoft Entra ID ist deshalb nicht nur ein Anmeldedienst, sondern die zentrale Steuerungsebene für Zugriff, Rollen, Conditional Access und privilegierte Administration.
MFA ist ein wichtiger Kontrollpunkt, reicht aber allein nicht aus. Privileged Identity Management sollte administrative Rollen zeitlich begrenzen, Genehmigungen erzwingen und Aktivierungen protokollieren. Just-in-Time-Zugriff reduziert dauerhaft aktive Berechtigungen, während Access Reviews verhindern, dass alte Projektrollen, Gastkonten oder Ausnahmeberechtigungen unbemerkt bestehen bleiben.
Auch Workload-Identitäten verdienen dieselbe Aufmerksamkeit wie Benutzerkonten. Service Principals mit weitreichenden Rechten, langlebigen Secrets und unklarer Eigentümerschaft sind ein typischer Schwachpunkt. Wo möglich, sollten Managed Identities verwendet werden, weil sie ohne im Code gespeicherte Secrets auskommen und sich sauber mit Azure RBAC, Key Vault und Plattformrichtlinien verbinden lassen.
Break-Glass-Konten bleiben trotzdem notwendig. Sie sollten cloud-only sein, von normalen Conditional-Access-Regeln ausgenommen werden, starke Authentifizierung verwenden und besonders eng überwacht werden. Der Zweck dieser Konten ist der Notfallzugriff, nicht der bequeme Ausweg aus einem schlecht gepflegten Rollenmodell.
Policy-as-Code: Sicherheitsleitplanken statt manueller Kontrolle
Azure Policy ist der Mechanismus, mit dem Sicherheitsanforderungen wiederholbar durchgesetzt werden. Einzelne Policies prüfen zum Beispiel, ob Storage Accounts öffentliche Zugriffe erlauben, ob Diagnostic Settings vorhanden sind oder ob bestimmte Ressourcentypen in einer Subscription bereitgestellt werden dürfen. Initiatives bündeln mehrere Policies zu einer Baseline, die auf Management Groups oder Subscriptions angewendet werden kann.
Der praktische Wert liegt nicht nur im Audit. Mit passenden Effekten lassen sich nicht konforme Ressourcen verhindern, Konfigurationen ergänzen oder Remediation Tasks auslösen. So wird Policy-as-Code zu einem Sicherheitsgurt gegen Drift: Eine Umgebung bleibt nicht nur am Tag des Deployments konform, sondern wird kontinuierlich gegen die vereinbarten Regeln geprüft.
Azure Blueprints waren lange ein gängiger Begriff für Governance-Pakete. Für neue Architekturen sind heute jedoch Azure Policy, Initiatives, Template Specs und Deployment Stacks die relevanteren Bausteine. Sie passen besser zu Infrastructure-as-Code, Versionierung, Pull Requests und kontrollierten Rollouts über Entwicklungs-, Test- und Produktionsumgebungen.
Das folgende Beispiel zeigt ein kompaktes Bicep-Muster für eine Policy-Zuweisung. Es eignet sich als Ausgangspunkt, wenn eine Initiative zentral auf eine Subscription angewendet werden soll. In produktiven Umgebungen sollten Parameter, Exemptions und Remediation-Rollen getrennt versioniert und über eine Pipeline ausgerollt werden.
Example — Policy-Initiative per Bicep zuweisen
targetScope = 'subscription'
param initiativeDefinitionId string
param assignmentName string = 'security-baseline-assignment'
param enforcementMode string = 'Default'
resource securityBaseline 'Microsoft.Authorization/policyAssignments@2022-06-01' = {
name: assignmentName
properties: {
displayName: 'Security baseline for Azure workloads'
policyDefinitionId: initiativeDefinitionId
enforcementMode: enforcementMode
parameters: {}
}
}
Das Beispiel erstellt keine eigene Policy-Definition, sondern weist eine vorhandene Initiative zu. Genau diese Trennung ist wichtig: Plattformteams können Baselines zentral pflegen, während Workload-Teams nachvollziehbar sehen, welche Controls auf ihre Subscription wirken. Ein sicherer Rollout beginnt meist mit Audit, wechselt nach Bereinigung kritischer Findings zu Deny oder Modify und erlaubt nur dokumentierte, zeitlich begrenzte Ausnahmen.
Defender for Cloud und Key Vault richtig einordnen
Microsoft Defender for Cloud ist der zentrale Dienst für Cloud Security Posture Management und Workload-Schutz in Azure. Das ältere Azure-Security-Center-Wording taucht noch an manchen Stellen auf; produktiv sollte jedoch mit Defender for Cloud geplant und dokumentiert werden. Der Marketplace-Eintrag zum früheren Azure Security Center ist vor allem historisch beziehungsweise produktbezogen einzuordnen.
Defender for Cloud hilft dabei, Fehlkonfigurationen, fehlende Härtung und Sicherheitsrisiken sichtbar zu machen. Empfehlenswert ist, die Ergebnisse nicht als isolierte To-do-Liste zu behandeln, sondern mit Azure Policy, Asset Ownership und Ticketing zu verbinden. Eine Empfehlung ohne verantwortliches Team, Zieltermin und technische Remediation bleibt im Betrieb oft liegen.
Sensible Werte gehören nicht in Quellcode, Deployment-Parameter oder Pipeline-Logs. Azure Key Vault schützt Secrets, Zertifikate und Schlüssel und sollte mit RBAC, Private Endpoint, Logging und klaren Löschschutz-Einstellungen betrieben werden. Für viele Workloads ist die Kombination aus Managed Identity und Key Vault der sauberste Weg, weil Anwendungen keine statischen Zugangsdaten speichern müssen.
Auch hier steckt der Unterschied im Betrieb. Rotation, Eigentümerschaft, Ablaufdaten, Zugriffsauswertungen und Alarmierung sind mindestens so wichtig wie die initiale Ablage eines Secrets. Ein Key Vault ohne Diagnoseprotokolle und ohne Review der Zugriffe ist zwar ein besserer Speicherort als Quellcode, aber noch kein vollständiges Secret-Management-Modell.
Netzwerksicherheit: Firewall, WAF, Front Door und Private Endpoints
Azure-Netzwerksicherheit wird häufig falsch geplant, weil ähnliche Begriffe unterschiedliche Ebenen schützen. Eine Web Application Firewall prüft HTTP- und HTTPS-Verkehr auf Anwendungsebene. Azure Firewall kontrolliert Netzwerkverkehr zentral auf Layer 3 bis Layer 7, inklusive ausgehendem Verkehr und FQDN-Regeln. Azure Front Door ist ein globaler Einstiegspunkt für Webanwendungen mit Anycast, TLS, Routing und WAF-Funktionen am Edge. Private Endpoints reduzieren die öffentliche Erreichbarkeit von Plattformdiensten, indem sie Zugriff über private IP-Adressen ermöglichen.
- Für interne Ost-West-Kontrolle und zentrale Egress-Regeln ist Azure Firewall meist der passende Kontrollpunkt.
- Für regionale Webanwendungen mit TLS-Terminierung, Pfad-basiertem Routing und WAF eignet sich Application Gateway.
- Für globale Webanwendungen mit Edge-Routing, Performance-Anforderungen und WAF nahe am Nutzer ist Azure Front Door naheliegend.
- Für Storage, Key Vault, Datenbanken und andere PaaS-Dienste sollten Private Endpoints geprüft werden, damit sensible Dienste nicht öffentlich erreichbar bleiben.
Eine Web Application Firewall schützt vor typischen Webangriffen wie Injection-Mustern oder Cross-Site Scripting, ersetzt aber keine Netzwerksegmentierung. Azure Application Gateway ist besonders dann relevant, wenn regionale Web-Workloads mit WAF, TLS und Routing-Funktionen abgesichert werden sollen. Für DDoS-Szenarien ist Azure DDoS Protection der richtige Dienstbezug; dieser Schutz sollte nicht Defender for Cloud zugeschrieben werden.
In der Praxis werden diese Dienste kombiniert. Eine globale Anwendung kann über Front Door erreichbar sein, regionale Backends über Application Gateway absichern, ausgehenden Verkehr über Azure Firewall führen und Datenebenen über Private Endpoints isolieren. Das Ziel ist nicht möglichst viele Sicherheitsdienste einzusetzen, sondern jeden Kontrollpunkt auf der richtigen Ebene zu platzieren.
Storage-Sicherheit: Zugriff, Schlüssel, SAS und Unveränderbarkeit
Storage Accounts enthalten oft die Daten, die ein Angreifer tatsächlich sucht: Exporte, Backups, Logs, Dokumente, Datenfeeds oder Analyseergebnisse. Deshalb sollte Storage-Sicherheit nicht auf Verschlüsselung im Ruhezustand reduziert werden. Diese ist wichtig, aber Zugriff, Netzwerkpfade, Schlüsselverwaltung und Lebenszyklusregeln entscheiden im Alltag häufiger über das Risiko.
Azure RBAC ist für viele Szenarien die bevorzugte Zugriffsmethode, weil Berechtigungen an Identitäten, Rollen und Governance-Prozesse gebunden werden können. Shared Keys sollten eingeschränkt werden, wenn sie nicht benötigt werden, da sie sehr weitreichende Kontrolle über ein Storage-Konto ermöglichen. Shared Access Signatures bleiben nützlich, sollten aber kurzlebig, eng berechtigt und möglichst an konkrete Anforderungen gebunden sein.
Typische SAS-Fehler sind lange Laufzeiten, Schreibrechte ohne Notwendigkeit, fehlende IP- oder Protokolleinschränkungen und fehlendes Monitoring. Besonders problematisch sind SAS-Links, die in Tickets, E-Mails oder Logs weitergegeben werden und dadurch faktisch wie Passwörter zirkulieren. Wenn externe Datenbereitstellung regelmäßig nötig ist, lohnt sich ein dediziertes Muster mit separaten Containern, kurzen Ablaufzeiten und klarer Protokollierung.
Für besonders schützenswerte Daten können immutable Storage-Funktionen wie zeitbasierte Aufbewahrung oder Legal Hold relevant sein. Sie verhindern, dass Daten innerhalb definierter Regeln verändert oder gelöscht werden. Das ist vor allem für Audit-Logs, Nachweisdaten und bestimmte regulatorische Anforderungen nützlich, muss aber sorgfältig geplant werden, weil falsche Aufbewahrungsregeln operative Auswirkungen haben können.
Monitoring, Sentinel und Incident Response
Ohne verlässliche Telemetrie ist Azure-Sicherheit reaktiv. Azure Monitor sammelt Metriken, Aktivitätsprotokolle, Ressourcenprotokolle und Anwendungsdaten. Azure Monitor Alerts sorgen dafür, dass relevante Ereignisse nicht nur in einem Log Analytics Workspace liegen, sondern operationalisiert werden.
Microsoft Sentinel ergänzt diese Grundlage als SIEM- und SOAR-Plattform. Sinnvolle Datenquellen sind Entra-ID-Anmeldungen, Azure Activity Logs, Defender-for-Cloud-Alerts, Firewall- und WAF-Logs, Key-Vault-Zugriffe, Storage-Diagnoseprotokolle und relevante Workload-Logs. Nicht jede Datenquelle muss mit maximaler Aufbewahrung in Sentinel landen; sonst entstehen schnell hohe Ingestion- und Retention-Kosten ohne entsprechenden Sicherheitsnutzen.
Eine pragmatische Log-Strategie unterscheidet zwischen heißen und kalten Daten. Heiße Daten werden aktiv korreliert, alarmiert und untersucht, etwa Anmelderisiken, privilegierte Rollenaktivierungen und sicherheitsrelevante Netzwerkereignisse. Kalte Daten dienen eher forensischer Nachvollziehbarkeit, Audit und langfristiger Aufbewahrung. Diese Trennung hilft, Kosten zu steuern, ohne blinde Flecken bei wichtigen Signalen zu schaffen.
Die folgende KQL-Abfrage ist ein einfaches Beispiel für die Untersuchung privilegierter Aktivitäten im Azure Activity Log. Sie eignet sich als Ausgangspunkt für Hunting oder eine Analytics Rule, wenn Änderungen an Rollenzuweisungen besonders überwacht werden sollen.
Example — Privilegierte Rollenzuweisungen mit KQL prüfen
AzureActivity
| where OperationNameValue has "MICROSOFT.AUTHORIZATION/ROLEASSIGNMENTS/WRITE"
| project TimeGenerated, Caller, ActivityStatusValue, ResourceGroup, SubscriptionId, CorrelationId
| order by TimeGenerated desc
Die Abfrage filtert auf neue Rollenzuweisungen und zeigt die wichtigsten Felder für eine erste Bewertung. In einer produktiven Sentinel-Regel sollten bekannte Automatisierungskonten, genehmigte Change-Fenster und Break-Glass-Szenarien berücksichtigt werden, damit Alarmierungen relevant bleiben. Runbooks können anschließend Tickets erstellen, Benachrichtigungen versenden oder zusätzliche Kontextdaten abrufen, sollten aber nicht unkontrolliert Berechtigungen entfernen, ohne den Betriebsprozess zu berücksichtigen.
Betrieb und Weiterbildung als Teil der Sicherheitsarchitektur
Azure-Sicherheitskontrollen entfalten ihren Wert erst, wenn Plattformteams, SecOps und Workload-Teams dieselben Muster verwenden. Dazu gehören dokumentierte Baselines, klare Verantwortliche, wiederholbare Deployments, regelmäßige Reviews und ein Incident-Response-Prozess, der geübt wird. Ein Sicherheitskonzept, das nur in Architekturfolien existiert, wird im Tagesbetrieb schnell von Ausnahmen überholt.
Besonders in regulierten Branchen sollte jede sicherheitsrelevante Entscheidung nachvollziehbar sein: warum eine Ressource öffentlich erreichbar ist, weshalb eine Policy-Ausnahme existiert, wer eine privilegierte Rolle aktivieren darf und welche Logs für Vorfälle verfügbar sind. Diese Nachvollziehbarkeit ist kein rein formaler Compliance-Punkt. Sie verkürzt Untersuchungen, erleichtert Audits und macht technische Schulden sichtbar.
Wer Azure-Sicherheit systematisch vertiefen möchte, kann strukturierte Microsoft-Azure-Trainings als Ergänzung zu internen Standards nutzen; Readynez bündelt entsprechende Lernpfade unter Microsoft Azure Training. Entscheidend ist dabei, praktische Umsetzung mit Architekturentscheidungen zu verbinden: Policy, Identität, Netzwerk und Monitoring sollten gemeinsam trainiert werden, weil sie in echten Umgebungen voneinander abhängen.
Eine belastbare Azure-Sicherheitsbasis aufbauen
Gute Azure-Sicherheit entsteht aus konsistenten Entscheidungen. Identitäten werden mit Entra ID, PIM, Conditional Access und Managed Identities kontrolliert. Netzwerke werden segmentiert, öffentliche Angriffsflächen reduziert und Kontrollpunkte wie Azure Firewall, Application Gateway, Front Door, WAF und Private Endpoints gezielt eingesetzt. Daten werden über RBAC, Key Vault, Private Endpoints, restriktive SAS-Muster und gegebenenfalls Unveränderbarkeit geschützt.
Gleichzeitig muss der Betrieb Abweichungen erkennen: Azure Policy verhindert Drift, Defender for Cloud priorisiert Härtung, Azure Monitor und Microsoft Sentinel liefern Signale für Detection und Response. Die wirksamste nächste Maßnahme ist daher selten ein einzelnes neues Tool, sondern eine klare Baseline, die versioniert, ausgerollt, überwacht und regelmäßig angepasst wird. Weitere Informationen zu Cloud- und Security-Lernpfaden finden sich auf der Readynez-Website.
