ISO 27001 und Kubernetes: So bereiten Sie die Zertifizierung vor

TL;DR

ISO 27001 verlangt dokumentierte Informationssicherheit -- und Kubernetes liefert die technischen Mittel dafür. Annex A.9 (Zugriffskontrolle) wird durch RBAC umgesetzt, A.10 (Kryptographie) durch Encryption at Rest und TLS, A.12 (Betriebssicherheit) durch Audit-Logging. Dieser Artikel zeigt die konkrete Zuordnung mit YAML-Beispielen und einer Readiness-Checkliste.

Warum ISO 27001 und Kubernetes zusammengehoeren

ISO 27001 ist der internationale Standard fuer Informationssicherheits-Managementsysteme (ISMS). Wenn Ihre Organisation Container-Workloads in Kubernetes betreibt, faellt die Cluster-Infrastruktur in den Geltungsbereich (Scope) des ISMS. Auditoren erwarten, dass Sie nachweisen koennen, wie die Annex-A-Controls technisch umgesetzt sind.

Das Problem: Viele Teams dokumentieren ihre Kubernetes-Konfiguration nicht im Kontext der ISO-Controls. Sie haben RBAC eingerichtet, aber koennen nicht erklaeren, welches Annex-A-Control damit abgedeckt wird. Genau diese Luecke schliesst dieser Artikel.

Annex A Controls auf Kubernetes abbilden

Die folgende Tabelle zeigt die wichtigsten Zuordnungen:

A.9: Zugriffskontrolle mit RBAC

Annex A.9 verlangt, dass Zugriff auf Informationen und Systeme eingeschraenkt und kontrolliert wird. In Kubernetes ist RBAC das zentrale Werkzeug dafuer.

Ein haeufiger Fehler bei Audits: Teams vergeben cluster-admin an zu viele ServiceAccounts. Fuer ISO 27001 muessen Sie das Prinzip der geringsten Berechtigung (Least Privilege) nachweisen. Hier ein Beispiel fuer eine eingeschraenkte Rolle:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: app-deployer
  namespace: production
  labels:
    iso27001.control: "A.9.1"
    iso27001.description: "zugriffskontrollrichtlinie"
rules:
  # Nur Deployments verwalten, keine Secrets lesen
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]
  # Pods nur lesen, nicht loeschen
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
  # Kein Zugriff auf: secrets, configmaps, serviceaccounts, roles

Die Labels iso27001.control und iso27001.description sind keine Kubernetes-Standards, sondern eine Konvention, die Ihnen bei Audits hilft. Wenn der Auditor fragt, welche RBAC-Rollen A.9.1 abdecken, koennen Sie filtern:

kubectl get roles,clusterroles --all-namespaces \
  -l iso27001.control=A.9.1 \
  -o custom-columns=NAME:.metadata.name,NAMESPACE:.metadata.namespace

Fuer A.9.2 (Benutzerzugangssteuerung) muessen Sie dokumentieren, wie Benutzer Zugang zum Cluster erhalten und wie dieser Zugang entzogen wird. Nutzen Sie OIDC-Integration mit Ihrem Identity Provider (z.B. Entra ID, Keycloak), damit Deprovisioning automatisch greift, wenn ein Mitarbeiter die Organisation verlaesst.

A.10: Kryptographie -- Encryption at Rest

Annex A.10 fordert eine Richtlinie zum Einsatz kryptographischer Massnahmen. In Kubernetes betrifft das zwei Bereiche: Verschluesselung von Secrets im etcd (at rest) und TLS fuer Kommunikation (in transit).

Standardmaessig speichert Kubernetes Secrets nur Base64-codiert in etcd -- das ist keine Verschluesselung. Fuer ISO 27001 muessen Sie Encryption at Rest aktivieren:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      # AES-CBC mit 32-Byte-Schluessel
      - aescbc:
          keys:
            - name: key-2026-q1
              secret: <base64-codierter-32-byte-schluessel>
      # Fallback: Identity (unverschluesselt) fuer Migration
      - identity: {}

Aktivieren Sie die Konfiguration ueber den API-Server-Parameter --encryption-provider-config. Nach der Aktivierung muessen Sie alle bestehenden Secrets neu schreiben, damit sie verschluesselt werden:

# Alle Secrets in allen Namespaces neu schreiben
kubectl get secrets --all-namespaces -o json | \
  kubectl replace -f -

Dokumentieren Sie den Schluesselrotationsprozess. ISO 27001 erwartet, dass kryptographische Schluessel regelmaessig gewechselt werden. Ein vierteljährlicher Rotationszyklus ist ein guter Startpunkt.

A.12: Betriebssicherheit mit Audit-Logging

A.12.4 verlangt Ereignisprotokollierung. Kubernetes bietet dafuer das API-Server-Audit-Log. Ohne dieses Log koennen Sie nicht nachweisen, wer wann welche Aenderungen am Cluster vorgenommen hat.

apiVersion: audit.k8s.io/v1
kind: Policy
metadata:
  labels:
    iso27001.control: "A.12.4"
rules:
  # Authentifizierungsversuche vollstaendig loggen
  - level: RequestResponse
    users: ["system:anonymous"]

  # RBAC-Aenderungen vollstaendig loggen
  - level: RequestResponse
    resources:
      - group: "rbac.authorization.k8s.io"
        resources: ["*"]

  # Secret-Zugriffe: Metadata (keine Inhalte!)
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets"]

  # Alle Schreiboperationen loggen
  - level: Request
    verbs: ["create", "update", "patch", "delete"]

  # Default: Metadata fuer alles andere
  - level: Metadata

Leiten Sie die Audit-Logs an ein zentrales System weiter und stellen Sie sicher, dass die Logs manipulationssicher gespeichert werden. Der Auditor wird fragen: Wie lange werden Logs aufbewahrt? Wer hat Zugriff auf die Logs? Koennen Logs nachtraeglich veraendert werden?

Admission Controller fuer A.14

A.14.2 fordert sichere Entwicklungsprozesse. In Kubernetes setzen Sie das ueber Admission Controller um, die unsichere Konfigurationen verhindern, bevor sie im Cluster landen.

Pod Security Admission (PSA) ist der eingebaute Mechanismus:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    iso27001.control: "A.14.2"
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Das restricted-Profil verhindert privilegierte Container, Host-Namespaces und Root-User. Fuer Policy-as-Code-Anforderungen, die ueber PSA hinausgehen, nutzen Sie Kyverno oder OPA Gatekeeper.

Readiness-Checkliste fuer das Audit

Nutzen Sie diese Checkliste, um Ihre Kubernetes-Umgebung auf das ISO-27001-Audit vorzubereiten:

Dokumentation fuer den Auditor

Der Auditor will nicht Ihre YAML-Dateien lesen. Er will Dokumente sehen, die erklaeren, warum Sie etwas so konfiguriert haben. Bereiten Sie folgende Dokumente vor:

1. Zugriffskontrollrichtlinie: Beschreibt das RBAC-Konzept, Namespace-Strategie und den Prozess fuer Berechtigungsvergabe
2. Kryptographie-Richtlinie: Dokumentiert Verschluesselungsstandards, Schluesselmanagement und Rotationszyklen
3. Logging-Konzept: Definiert welche Events geloggt werden, wo Logs gespeichert werden und wie lange
4. Incident-Response-Plan: Beschreibt das Vorgehen bei Sicherheitsvorfaellen im Cluster

Verlinken Sie in jedem Dokument auf die konkreten Kubernetes-Konfigurationen (GitOps-Repository). So kann der Auditor nachvollziehen, dass die dokumentierten Massnahmen tatsaechlich implementiert sind.

Haeufig gestellte Fragen

Muss der gesamte Kubernetes-Cluster im ISMS-Scope sein?

Nicht zwingend. Sie koennen den Scope auf bestimmte Namespaces oder Cluster einschraenken. Allerdings muessen Sie begruenden, warum bestimmte Teile ausserhalb des Scopes liegen. In der Praxis ist es oft einfacher, den gesamten Cluster einzubeziehen.

Reicht Kubernetes-natives RBAC fuer A.9 aus?

RBAC deckt die technische Zugriffskontrolle ab. Fuer A.9 brauchen Sie zusaetzlich eine dokumentierte Richtlinie, einen Prozess fuer Berechtigungsvergabe und regelmaessige Access Reviews. Die Technik allein reicht nicht.

Wie oft muessen Audit-Logs ueberprueft werden?

ISO 27001 schreibt keine feste Frequenz vor. Sie muessen jedoch nachweisen, dass Logs regelmaessig ausgewertet werden. Automatisierte Alerts fuer kritische Events (z.B. cluster-admin-Vergabe) kombiniert mit monatlichen manuellen Reviews sind ein pragmatischer Ansatz.

Welche Kubernetes-Version ist fuer ISO 27001 erforderlich?

Es gibt keine Vorgabe fuer eine bestimmte Version. Allerdings muessen Sie nachweisen, dass Sie Sicherheitsupdates zeitnah einspielen. Cluster mit End-of-Life-Versionen sind ein Befund im Audit.

Brauche ich einen externen Auditor fuer die Zertifizierung?

Ja. ISO 27001 erfordert ein Zertifizierungsaudit durch eine akkreditierte Zertifizierungsstelle. Interne Audits sind Teil des ISMS, ersetzen aber nicht die externe Zertifizierung.