DORA und AKS: Was Auditoren in der Landing Zone sehen

Robin, Azure und Kubernetes bei Pexon Consulting | 10 Min. Lesezeit | 08.09.2026

TL;DR

DORA AKS Landing Zone ist die nachweisbare Schnittmenge aus Identity, Netz, Logging und Exit, nicht ein Cluster mit schöner YAML. Der Prüfer will ICT-Risiko, Zugriffswege und Wiederanlauf, nicht Folien. Private API, WAF vor HTTP und GitOps sind Bausteine. Wer nur Architektur-Slides hat, bleibt im POC.

Was DORA AKS Landing Zone vom Cluster-Verkauf trennt

DORA verlangt ICT-Risikomanagement, Incident-Nachweise und Auslagerungssteuerung. AKS ist ein Betriebsobjekt in dieser Kette. Die Money-Page AKS Consulting und Implementierung klärt, wie der Cluster steht. Dieser Text klärt, was ein Auditor in der Landing Zone sehen will, bevor die erste Fachanwendung deployed.

Die Breite für regulierte Branchen steht im Artikel AKS für regulierte Branchen. Hier geht es enger: Nachweise, nicht Marktüberblick.

Bei einer Genossenschaftsbank mit Microsoft-Stack und internem Prüfer war genau dieser Schnitt der Auftrag: Landing Zone als Code, dokumentierter API-Zugang, Upgrade-Pfad. Nicht „Kubernetes einführen“.

Ein Auditor kommt selten mit einer Kubernetes-Checkliste. Er kommt mit DORA-Artikeln zu ICT-Risiko, Incident, Testing und Auslagerung. DORA AKS Landing Zone übersetzt diese Artikel in Azure-Objekte, die man klicken, exportieren und datieren kann. Fehlt die Übersetzung, bleibt der Cluster ein Betriebsobjekt ohne Akte.

Was der Walkthrough am ersten Tag wirklich abfragt

Der Prüfer öffnet nicht zuerst kubectl. Er fragt: Wer ist Owner des Abos, in dem AKS liegt? Welche Management Group hängt darüber? Welche Policy ist assigned, welche Exemption hat Ablauf? Dann erst der Cluster: öffentlicher API-Server oder privat, wie kommt ein Mensch an die API, wie lange gilt das Ticket.

Danach Logs. Nicht „wir haben Container Insights“. Sondern: Retention in Tagen, wer das Log ändern darf, ob ein Alert jemals ein Ticket erzeugt hat. Ein Screenshot vom Kickoff zählt nicht. Ein Sentinel-Incident mit Datum zählt.

Change kommt als Drittes. Letzter Merge auf main, Pipeline-Run, wer approved hat, ob ein Hotfix am Cluster vorbei ging. GitOps ohne Branch Policy ist Folie. Ein Apply vom Laptop des Dienstleisters ist der Befund, den interne Revision zuerst findet.

Exit kommt zuletzt, oft als Fangfrage. Liegen Images in einer Registry, die der Bank gehört? Liegt das IaC im Repo der Bank oder nur beim Partner? Gibt es ein Runbook, das jemand ohne den ursprünglichen Dienstleister ausführen kann? DORA AKS Landing Zone ohne Exit-Kapitel ist unvollständig, auch wenn der Cluster sauber privat steht.

Bank-IT findet den Branchen-Einstieg unter Banking. Dieser Artikel bleibt auf AKS-Nachweisen, nicht auf Produktverkauf.

Die fünf Artefakte, die fehlen, wenn nur das Cluster steht

1. Subscription- und Spoke-Schnitt. Ein AKS in einem gemischten Abo mit Shared-VNet und unklaren Owners fällt beim Inventar durch.
2. Privater API-Zugang. Jump Box und langlebige kubeconfig sind der Klassiker. Den Weg ohne Jump Box beschreibt der private AKS-API-Zugang mit Azure Bastion.
3. HTTP-Schutz vor dem Service. WAF ist Policy auf dem Application Gateway, nicht Schutz des API-Servers. Azure WAF vor AKS bleibt der Spoke dafür.
4. GitOps mit Review. Ein Apply vom Laptop des Dienstleisters ist kein Change-Nachweis. Branch Policy, PR, Pipeline-Log.
5. Restore-Test mit Datum. Backup-Checkbox in Terraform reicht nicht. Der Prüfer fragt nach dem letzten Wiederanlauf, nicht nach der Resource.

apiVersion: v1
kind: ConfigMap
metadata:
  name: lz-audit-hints
  namespace: kube-system
data:
  api-access: "private-link plus bastion, no public API"
  identity: "entra workload identity, no static kubeadmin"
  change: "gitops apply only, pr required on main"

Das ist kein Ersatz für die Landing Zone. Es zeigt die Fragen, die im Audit-Walkthrough kommen. Die Antworten liegen in Azure Policy, Entra und dem Git-Repo, nicht in dieser ConfigMap.

Zwei Tore, zwei Kapitel. Der API-Server ist das Betriebstor. HTTP vor den Fachanwendungen ist das Anwendungstor. Wer WAF auf den API-Server legt, vermischt die Akte. Wer nur Network Security Groups zeigt, hat Unterlage, kein Prevention-Regelwerk. Die WAF-Policy in Prevention auf den Hosts, die der Prüfer im Scope hat, gehört in das HTTP-Kapitel. Der private API-Pfad gehört in das Zugriffs-Kapitel. Mischen erzeugt Nachfragen, die den Termin sprengen.

Upgrade-Pfad ist der stille Befund. Ein Cluster auf einer alten Kubernetes-Version mit „wir patchen im nächsten Quartal“ fällt beim Testing-Artikel. Der Nachweis ist der letzte Upgrade-Job, das Wartungsfenster, das Rollback. Nicht die Absicht in Confluence.

Production-Gap: Folien ja, Controls nein

Häufig gestellte Fragen

Reicht ein privates AKS für DORA?

Nein. Privatheit des API-Servers ist ein Baustein. Inventar, Rechte, Logging, Change und Exit bleiben offen.

Ist Azure Policy die Landing Zone?

Policy erzwingt Guardrails. Die Zone ist das Abo- und Netz-Schnitt plus Identity. Policy ohne Owner-Modell ist Checkliste ohne Betrieb.

Wo landet WAF in der Nachweisakte?

Bei HTTP-Anwendungen, nicht beim Cluster-API. Zwei Tore, zwei Kapitel.

Was ist mit DORA und einem Managed Kubernetes außerhalb von Azure?

Dieselbe Prüfer-Logik. Dieser Text ist Azure/AKS, weil die Money-Page und die Won-Muster dort sitzen.

Können wir Folien aus dem Workshop als Nachweis nutzen?

Als Einstieg ja. Als Audit-Beleg nein. Der Prüfer will das laufende Control, nicht die Absicht.

Nächster Schritt

Verwandte Themen