Constantin, Azure und Compliance bei Pexon Consulting | 10 Min. Lesezeit | 08.09.2026
TL;DR
NIS2 Azure Tenant heißt Policy, Defender, Logging, RBAC und Landing-Zone-Guardrails im Entra- und Azure-Schnitt, nicht der Gesetzestext. Energie-IT und KRITIS brauchen eine wiederholbare Baseline für mehrere Tenants. Wer Policies nur in einem Wiki hat, bleibt im POC. Der Gesetz-Überblick bleibt der NIS2-Richtlinien-Artikel.
| Microsoft-Objekt | Nachweis im Audit |
|---|---|
| Azure Policy, Initiativen | Welche Controls sind assigned, Exemption mit Owner und Datum |
| Activity Log plus Diagnostic Settings | Wer hat wann was geändert, Retention, unveränderbarer Store |
| Microsoft Sentinel oder SIEM-Export | Alert-Regel, On-Call, letztes echtes Ticket |
| Entra PIM, Conditional Access | Wer Admin wird, wie lange, welcher Approval |
| Defender for Cloud / Servers | Secure Score als Trend, nicht als Screenshot vom Kickoff |
| Landing Zone Management Groups | Welche Spokes dürfen was, wer bricht die Guardrail |
Was NIS2 Azure Tenant nicht ist
Der Artikel NIS2-Richtlinie erklärt Betroffenheit und Fristen. Energie-IT-Beratung ist der Branchen-Einstieg. Dieser Text ist die Tenant-Baseline: was in Entra und Azure stehen muss, damit ein Versorger oder ein Partnerhaus mehrere Endkunden-Tenants gleich schneidet.
Öffentliche Lageberichte von Netzbetreibern und Übertragungsnetzbetreibern (EnBW, 50Hertz und vergleichbare EVUs in der Fachpresse) zeigen denselben Druck: Meldewege, Lieferkette, Betrieb. Das sind öffentliche Referenzen, keine Pexon-Cases. Der Hebel hier ist wiederholbare Konfiguration, nicht ein neues Gesetz-Whitepaper.
Die Cluster-Seite ist ein anderes Objekt. CIS und NIS2 auf Kubernetes gehören nicht in diesen Tenant-Schnitt. CI/CD-Guardrails auf Azure DevOps beschreibt Azure DevOps Governance.
Checkliste: zwölf Punkte, die ein Tenant tragen muss
- Management-Group-Hierarchie mit klaren Spokes, keine Wildcard-Contributor auf Root.
- Azure Policy-Initiative assigned, Exemptions mit Ticket und Ablauf.
- Entra: keine dauerhaften Global Admins, PIM für privilegierte Rollen.
- Conditional Access für Admins: Phishing-resistente Faktoren, keine Legacy-Auth.
- Activity Log an unveränderbaren Speicher, nicht nur 30 Tage im Portal.
- Diagnostic Settings auf Platform-Logs der kritischen Spokes.
- Defender for Cloud auf den Abos, die Workloads tragen, mit Owner für Alerts.
- Key Vault und Secrets: keine Keys in Pipeline-Variablen im Klartext.
- Network: Default-Deny zwischen Spokes, dokumentierte Peering.
- Resource Locks auf Shared-Hub, Change nur über Pipeline.
- Break-Glass-Konto getestet, Protokoll im Tresor, nicht in Confluence allein.
- Lieferkette: welche Dienstleister welche PIM-Gruppen haben, Joiner/Mover/Leaver.
Die Landing Zone als Netz- und Abo-Schnitt bleibt Azure Landing Zone. NIS2 Azure Tenant setzt Guardrails darauf, ersetzt sie nicht.
Partnerhäuser, die mehrere Versorger-Tenants gleich aufsetzen, brauchen denselben Blueprint plus Enablement. Der erste Tenant ist immer sauber. Der dritte Tenant hat Exemptions ohne Ablauf, PIM-Gruppen, die niemand pflegt, und einen Break-Glass-Account, der seit dem Kickoff nicht getestet wurde. Genau das ist der Production-Gap.
Energie-IT unter Energie-IT-Beratung sucht oft zuerst den Branchen-Einstieg. Dieser Text bleibt auf dem Tenant. Wer nur den Gesetzestext braucht, bleibt beim NIS2-Richtlinien-Artikel.
Was in CI/CD muss, damit Policy nicht Wiki bleibt
Eine Initiative, die nur im Portal assigned ist, driftet. Der nächste Spoke kommt per ClickOps, die Exemption schreibt jemand ohne Ticket, der Score von Defender wird zur Folie. NIS2 Azure Tenant heißt: Assignment als Code, Exemption mit Owner und Ablaufdatum, Pipeline, die den Drift meldet.
Activity Log ohne unveränderbaren Store ist ein Filter, den ein Admin leeren kann. Sentinel ohne On-Call ist ein Dashboard. Defender ohne Owner für Alerts ist Secure Score ohne Ticket. Der Auditor fragt nicht nach Lizenzen. Er fragt nach dem letzten echten Incident und wer ihn geschlossen hat.
RBAC driftet leise. Contributor auf der Subscription, Owner auf der Resource Group, eine Gastgruppe des Dienstleisters mit Standing Access. Joiner/Mover/Leaver muss die PIM-Gruppen treffen, nicht nur das AD der Fachbereiche. Sonst bleibt der Tenant nach dem Projekt offen.
# Nachweis-Fragen, die der Audit stellt - nicht die Policy selbst
assignment:
scope: "mg-energie-prod"
exemption_owner: "ticket plus datum"
drift: "pipeline fail on unassigned spoke"
logging:
activity_log: "immutable store, not portal default"
sentinel: "last real incident with owner"
identity:
standing_admin: false
break_glass_last_test: "datum"Das YAML ist die Checkliste im Repo, nicht der Ersatz für assigned Policy. Der Auditor will das Assignment im Tenant, das Ticket zur Exemption und das Datum des Break-Glass-Tests. Partner, die denselben Blueprint in den nächsten Versorger-Tenant kopieren, brauchen genau diese drei Felder, sonst startet Tenant drei wieder im Wiki.
Key Vault ohne Pipeline-Pfad bleibt Geheimnis im Chat. Resource Locks ohne Change-Prozess werden im Incident umgangen. Conditional Access ohne Legacy-Auth-Block lässt den Admin-Weg offen, den PIM gerade geschlossen hat. NIS2 Azure Tenant ist die Summe dieser Schnitte, nicht ein einzelnes Microsoft-Produkt.
Production-Gap: Policy steht, CI/CD fehlt
Häufig gestellte Fragen
Reicht Microsofts NIS2-Mapping als Nachweis?
Als Start ja. Der Auditor will assigned Policy, nicht die Marketing-Seite. Exemption ohne Owner fällt durch.
Was kostet die Baseline gegenüber einem Workshop?
Scoping hängt an Anzahl Abos, PIM-Reife und SIEM. Ohne Inventar keine Festpreis-Zahl hier. Das Angebot sitzt auf der NIS2-LP.
Ist das dasselbe wie Azure Landing Zone?
Nein. Landing Zone ist Abo, Netz, Identity-Fundament. NIS2 Azure Tenant ist das Regelwerk und der Nachweisbetrieb darauf.
Können wir nur Defender kaufen und fertig sein?
Defender ohne PIM, ohne Log-Retention und ohne Change-Pfad ist ein Dashboard. NIS2 fragt nach Prozess.
Wo endet die Tenant-Baseline, wo beginnt DevOps-Governance?
Tenant: Entra, Policy, Logs, Abos. Azure DevOps: Projekte, Pipeline-Gates, Entra-Gruppen in der Organisation. Beides nötig, zwei URLs.
Nächster Schritt
Verwandte Themen
