Kubernetes und ISO 27001: Welche Controls die Architektur erfüllt

TL;DR. Eine Kubernetes-Plattform erfüllt etwa ein Dutzend Controls aus Anhang A strukturell, das heißt die Architektur erzwingt sie, statt dass eine Richtlinie sie beschreibt: Zugriffskontrolle, Netzsegmentierung, Konfigurationsmanagement, Änderungsmanagement, Protokollierung und Kapazität. Sie erfüllt kein Control, dessen Gegenstand eine Entscheidung, eine Pflicht oder ein Mensch ist, und das ist der größte Teil der organisatorischen und personellen Themen. Der typische Fehlerfall ist nicht ein fehlendes Control, sondern ein Control, das die Plattform durchsetzt und das sich nicht nachweisen lässt, weil der Nachweis aus einer voreingestellten Aufbewahrungsfrist herausgefallen ist.

ISO 27001:2022 führt in Anhang A 93 Controls in vier Themen: organisatorisch, personenbezogen, physisch und technologisch. Plattform-Teams lesen das technologische Thema, erkennen das meiste wieder und schließen daraus, der Cluster erledige die Hauptarbeit. Auditoren lesen das organisatorische Thema, finden davon nichts im Cluster und schließen daraus, der Cluster sei belanglos. Beide Lesarten irren auf dieselbe Weise: Sie behandeln die Plattform entweder als den gesamten Control-Satz oder als gar keinen, obwohl sie ein genau bestimmter und stabiler Ausschnitt ist.

Dieser Beitrag beschreibt diesen Ausschnitt. Vorausgesetzt wird eine Plattform, wie kompetente Teams sie heute bauen: deklarative Manifeste in Git, laufend abgeglichen, Admission Control mit erzwungenen Regeln, RBAC, das nicht für alle Cluster-Admin bedeutet, und aktive Network Policies. Nichts Exotisches.

Inhalt

Was die Architektur strukturell erzwingt
Was sie nur erzwingt, wenn man es so konfiguriert hat
Was kein Cluster erfüllen kann
Das Nachweisproblem, und das ist das eigentliche
Wie sich das auf die UAE Information Assurance Standards abbildet

1. Was die Architektur strukturell erzwingt

Das sind die Controls, bei denen eine korrekt gebaute Plattform nicht der Nachweis des Controls ist, sondern das Control selbst. Der Unterschied zählt: Ein Auditor, der hier den Cluster prüft, prüft das Control und nicht einen Bericht darüber.

A.5.15 Zugangssteuerung und A.8.2 Privilegierte Zugriffsrechte. Kubernetes-RBAC ist ein echtes, erzwungenes Autorisierungsmodell, das standardmäßig verweigert. Bindet man Rollen an Gruppen aus dem Identity Provider statt an einzelne Personen, wird aus dem Eintritts-, Wechsel- und Austrittsprozess eine Änderung der Gruppenmitgliedschaft statt einer Cluster-Operation. Die Falle: In fast jedem Cluster existiert mindestens ein langlebiger Service Account mit Cluster-Admin, angelegt bei der Installation und nie entfernt, der das Control still aushebelt.

A.8.20 Netzwerksicherheit und A.8.22 Trennung von Netzwerken. Eine NetworkPolicy wird vom CNI erzwungen und nicht in einem Diagramm dokumentiert. Ein Default-Deny je Namespace plus explizite Freigaben ist eine Segmentierung, die ein Auditor prüfen kann, indem er eine Verbindung versucht.

A.8.9 Konfigurationsmanagement. Das ist die stärkste Passung im gesamten Standard. Deklarative Manifeste, die laufend abgeglichen werden, bedeuten, dass Konfigurationsabweichung vom System erkannt und zurückgesetzt wird. Das ist eine stärkere Aussage, als sie irgendeine Organisation über ihre Server trifft. Admission Policies machen aus dem Standard eine ausführbare Regel.

A.8.32 Änderungsmanagement. Eine Änderung ist ein Pull Request mit Review, Freigabe und Abgleich. Der Freigabe-Datensatz ist der Control-Nachweis, und er entsteht unabhängig davon, ob jemand daran denkt, ihn zu erzeugen.

A.8.6 Kapazitätssteuerung. Requests, Limits und Autoscaling sind Kapazitätssteuerung als Code, mit historischen Daten dahinter.

yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: payments
spec:
  podSelector: {}
  policyTypes: [Ingress]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-gateway
  namespace: payments
spec:
  podSelector:
    matchLabels: {app: ledger}
  policyTypes: [Ingress]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels: {name: edge}
          podSelector:
            matchLabels: {app: gateway}
      ports:
        - protocol: TCP
          port: 8443

A.8.20 und A.8.22 als erzwungene Objekte statt als Diagramm

2. Was sie nur erzwingt, wenn man es so konfiguriert hat

Diese Controls liegen in Reichweite der Plattform und sind nicht standardmäßig erfüllt. Jedes davon setzt eine Entscheidung voraus, die jemand getroffen haben muss, und genau deshalb werden sie am häufigsten behauptet und nicht gehalten.

A.8.7 Schutz vor Schadsoftware und A.8.8 Handhabung technischer Schwachstellen. Image-Scanning in der Pipeline ist nötig und nicht hinreichend: Ein Scan zur Build-Zeit sagt nichts über ein Image, das seit vier Monaten läuft. Geschlossen wird das Control durch Admission Control, die unsignierte oder nicht per Digest festgelegte Images ablehnt, plus eine feste Rebuild-Kadenz. Die Policy unten schlägt fehl geschlossen, und nur diese Einstellung bedeutet überhaupt etwas.

yaml

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: require-signed-images
spec:
  failurePolicy: Fail            # closed, not open
  matchConstraints:
    resourceRules:
      - apiGroups:   ["apps"]
        apiVersions: ["v1"]
        operations:  ["CREATE", "UPDATE"]
        resources:   ["deployments"]
  validations:
    - expression: >
        object.spec.template.spec.containers.all(c,
          c.image.startsWith('registry.internal/') &&
          c.image.contains('@sha256:'))
      message: "images must be internal and pinned by digest"

A.8.8 bei der Admission erzwungen, fehlschlagend geschlossen

A.8.24 Einsatz von Kryptographie. Secrets in Kubernetes sind base64-kodiert und nicht verschlüsselt, solange keine Verschlüsselung im Ruhezustand gegen ein KMS konfiguriert ist. Auditoren wissen das und fragen danach. Ein External-Secrets-Operator, der aus einem echten Secret-Manager liest, ist das Muster, das die Frage übersteht, weil es zugleich beantwortet, wer den Schlüssel hält.

A.8.15 Protokollierung und A.8.16 Überwachung von Aktivitäten. Im Audit-Log der Control Plane steht die Antwort auf die Frage, wer was getan hat, und dieses Log ist häufig aus, oder an mit einer Aufbewahrung von wenigen Tagen. Workload-Logs ersetzen es nicht: Sie zeigen, was die Anwendung getan hat, nicht wer die Plattform geändert hat.

A.8.13 Sicherung von Informationen. Ein etcd-Backup ist kein Plattform-Backup, und Volumes ohne die Objekte, die sie referenzieren, sind es ebenso wenig. Erfüllt wird das Control durch eine Wiederherstellung, die man durchgeführt hat, nicht durch einen Job, der Erfolg meldet.

3. Was kein Cluster erfüllen kann

Rund zwei Drittel von Anhang A liegen außerhalb der Reichweite jeder Plattform, und das Gegenteil anzunehmen ist der Grund, warum Zertifizierungsprojekte drei Wochen vor dem Audit auflaufen. Das organisatorische Thema fragt, wer entschieden hat, mit welcher Befugnis und wie oft überprüft. Das personenbezogene Thema fragt nach Überprüfung von Bewerbern, Arbeitsbedingungen, Disziplinarverfahren und danach, was am Tag eines Austritts passiert. Das physische Thema fragt nach dem Gebäude.

Drei treffen technisch starke Organisationen besonders:

A.5.7 Bedrohungsinformationen und A.5.24 bis A.5.28, Umgang mit Sicherheitsvorfällen. Ein Cluster erzeugt Alarme. Er erzeugt keinen Vorfallsprozess, kein Schweregradmodell, keinen Eskalationspfad und keinen Nachweis, dass ein Vorfall nachträglich ausgewertet wurde.
A.5.19 bis A.5.22, Lieferantenbeziehungen. Jeder Managed Service in der Plattform ist ein Lieferant, und das Control fragt, was Sie über ihn geprüft haben und wann, nicht welchen Anbieter Sie gewählt haben.
A.5.23 Informationssicherheit bei Nutzung von Cloud-Diensten. Das eine Control, das nach Plattform-Team aussieht und keines ist. Es geht um die Entscheidung, den Dienst zu nutzen, um die Bedingungen, unter denen das akzeptiert wurde, und um den Ausstieg.

Das brauchbare Modell dahinter: Die Plattform kann eine Regel erzwingen, sie kann keine Pflicht tragen.

4. Das Nachweisproblem, und das ist das eigentliche

Hier ist der Fehler, den wir am häufigsten sehen, und es ist kein fehlendes Control. Die Plattform ist wirklich gut gebaut. RBAC ist eng, Network Policies greifen, Admission Control lehnt schlechte Images ab, jede Änderung lief durch ein Review. Das Audit verlangt den Nachweis, dass diese Controls im Prüfzeitraum wirksam waren, und die Antwort ist ein Screenshot des aktuellen Zustands.

Der aktuelle Zustand ist kein Nachweis. Ein Control, das das ganze Jahr wirksam war, sich aber nicht als wirksam zeigen lässt, wird bewertet wie eines, das es nicht war, weil der Auditor beide nicht unterscheiden kann. Die Standardaufbewahrung der meisten Cluster ist so kurz, dass der Anfang des Prüfzeitraums bereits verloren ist.

   Git (declared state)                    Cluster (actual state)
   ┌──────────────────────┐                ┌──────────────────────┐
   │ manifests + policy   │  reconcile ──▶ │ workloads            │
   │ reviewed, signed,    │ ◀── drift      │ RBAC, NetworkPolicy  │
   │ merged by 2 people   │                │ admission decisions  │
   └──────────┬───────────┘                └──────────┬───────────┘
              │                                       │
              │ commit history                        │ audit log + events
              ▼                                       ▼
   ┌────────────────────────────────────────────────────────────┐
   │ Evidence store (retained ≥ assessment window)              │
   │  who changed what, when, who approved, what was rejected   │
   └────────────────────────────────────────────────────────────┘
                              │
                              ▼
              Control shown OPERATING, not DECLARED

Beide Hälften der Plattform erzeugen den Nachweis bereits

Die Lösung ist architektonisch und nicht prozessual. Beide Hälften des Bildes, der deklarierte Zustand in Git und der tatsächliche Zustand im Cluster, erzeugen bereits einen dauerhaften Datensatz. Git trägt, wer eine Änderung vorgeschlagen hat, wer sie freigegeben hat und wann sie gemerged wurde. Der Cluster trägt das Audit-Log, die Admission-Entscheidungen einschließlich der Ablehnungen und die Reconciliation-Ereignisse. Leitet man beides in einen Speicher mit einer Aufbewahrung, die den Prüfzeitraum übersteigt, wird jedes Control oben zu einer Abfrage statt zu einer Übung.

Die Ablehnungen zählen mehr, als die meisten Teams erwarten. Eine Admission Policy, die noch nie etwas abgelehnt hat, ist von einer nicht wirksamen nicht zu unterscheiden, und das Ablehnungsprotokoll ist der billigste denkbare Beweis, dass das Control lebt.

5. Wie sich das auf die UAE Information Assurance Standards abbildet

Für Organisationen in den Emiraten zählt dieselbe Plattformarbeit doppelt. Die UAE IA (NESA) Standards umfassen 188 Controls in 15 Familien, und die technischen Familien T1 bis T9 decken dasselbe Gebiet ab wie das technologische Thema aus Anhang A: Asset Management, Zugriffskontrolle, Netzwerksicherheit, Überwachung und Kryptographie. Eine Plattform, die für die oben genannten ISO-Controls gebaut wurde, hält die meisten technischen UAE-IA-Controls über eine Zuordnung statt über neue Arbeit.

Was nicht übertragbar ist, ist die Form der Pflicht. UAE IA markiert 35 Controls als Always Applicable, unabhängig von der Risikobeurteilung, allesamt Management-Controls, und ordnet den Rest in Prioritätsstufen, wobei P1 erweitert und niemals reduziert werden darf. Das ist strenger als das ISO-Modell, in dem die Anwendbarkeit der Risikobeurteilung folgt und die Erklärung zur Anwendbarkeit das Ergebnis begründet. Wer nach ISO gebaut hat und annimmt, die risikobasierte Logik gelte weiter, findet die Lücke genau in den Controls, die der Cluster ohnehin nie erfüllen konnte.

Läuft der Cluster in einer Public Cloud, kommt eine weitere Schicht hinzu, denn ein Control, das der Anbieter betreibt, muss trotzdem von Ihnen nachgewiesen werden. Das steht in unserer Referenz zu Cloud-Security-Controls.

Weiterlesen

ISO/IEC 27001:2022, Anhang A, und ISO/IEC 27002:2022 für die Umsetzungshinweise hinter jedem Control
UAE Information Assurance Regulation v1.1, TDRA, Anhang A und Anhang B
NIST SP 800-190, Application Container Security Guide
CIS Kubernetes Benchmark, für die Konfigurationsbasis, die die Controls oben voraussetzen