Kubernetes fuer Banken und Fintechs: MaRisk, BAIT und BaFin-konforme Cluster

TL;DR

• BAIT fordert dokumentierte IT-Strategie, Funktionstrennung und lueckenloses Audit-Logging. Kubernetes liefert die technischen Bausteine dafuer.
• Segregation of Duties laesst sich ueber RBAC mit getrennten Roles fuer Entwickler, Operatoren und Auditoren abbilden.
• Network Policies isolieren Kernbanken-Namespaces. Eine Default-Deny-Policy ist Pflicht.
• Managed Kubernetes gilt als wesentliche Auslagerung nach BAIT und erfordert eine BaFin-Anzeige sowie ein dokumentiertes Auslagerungsmanagement.
• API-Server Audit Logs auf Level RequestResponse sind die Basis fuer BaFin-konforme Protokollierung.

Die regulatorische Landschaft

Wer in der Finanzbranche Kubernetes betreiben will, muss drei Regelwerke kennen: MaRisk, BAIT und PSD2. Die MaRisk definiert die Anforderungen an das Risikomanagement von Kreditinstituten. Die BAIT konkretisiert diese fuer IT-Themen. PSD2 kommt hinzu, wenn Zahlungsverkehr im Spiel ist.

Die gute Nachricht: Kubernetes hat Bordmittel, die viele dieser Anforderungen technisch abdecken. Die schlechte: Man muss sie auch tatsaechlich nutzen und dokumentieren.

BAIT-Kapitel und ihre Kubernetes-Relevanz

RBAC: Funktionstrennung fuer Banken

Die BAIT verlangt eine klare Trennung zwischen Entwicklung, Betrieb und Ueberwachung. In Kubernetes bildet man das ueber separate Roles ab.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: banking-developer
  namespace: core-banking
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: banking-operator
  namespace: core-banking
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch", "update", "patch"]
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: bafin-auditor
rules:
  - apiGroups: ["", "apps", "batch", "networking.k8s.io"]
    resources: ["*"]
    verbs: ["get", "list", "watch"]

Drei Punkte dazu:

1. Entwickler koennen Deployments und Logs lesen, aber nichts aendern. Aenderungen laufen ausschliesslich ueber die CI/CD-Pipeline.
2. Operatoren koennen Deployments updaten (fuer Rollbacks) und Pods loeschen (fuer Incident Response), aber keine neuen Deployments anlegen.
3. Der Auditor-Role bekommt Read-Only-Zugriff auf alles. Das ist fuer BaFin-Pruefer und die interne Revision.

Keiner dieser Rollen hat Zugriff auf Secrets. Secret-Management laeuft ueber einen dedizierten Prozess, zum Beispiel ueber External Secrets Operator mit einem Vault-Backend. Mehr zu Secrets-Management unter Azure Key Vault vs. Kubernetes Secrets.

Namespace-Isolation mit Network Policies

Kernbanken-Systeme muessen auf Netzwerkebene isoliert sein. Das ist keine Empfehlung, sondern eine BAIT-Anforderung. Der erste Schritt ist eine Default-Deny-Policy:

apiVersion: v1
kind: Namespace
metadata:
  name: core-banking
  labels:
    compliance: bait
    data-classification: confidential
    business-criticality: critical
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: core-banking
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Darauf aufbauend oeffnet man gezielt die erlaubten Kommunikationspfade:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-and-monitoring
  namespace: core-banking
spec:
  podSelector:
    matchLabels:
      app: core-banking-api
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              access-core-banking: allowed
        - podSelector:
            matchLabels:
              role: api-gateway
      ports:
        - protocol: TCP
          port: 8443
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              name: logging
      ports:
        - protocol: TCP
          port: 514
    - to:
        - namespaceSelector:
            matchLabels:
              name: monitoring
      ports:
        - protocol: TCP
          port: 9090

Damit kann der core-banking-api Pod nur Traffic vom API-Gateway empfangen und nur an Logging und Monitoring senden. Alles andere wird blockiert. Wichtig: Network Policies wirken nur, wenn der CNI-Provider sie unterstuetzt (Calico, Cilium, etc.). Die Standard-Netzwerk-Implementierung in manchen Managed-Kubernetes-Angeboten ignoriert Network Policies stillschweigend.

Audit-Logging fuer BaFin-Pruefungen

Die BAIT verlangt eine lueckenlose Protokollierung aller sicherheitsrelevanten Ereignisse. Auf Kubernetes-Ebene bedeutet das: API-Server Audit Logging mit einer granularen Policy.

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["secrets"]
    namespaces: ["core-banking", "payment-services"]
  - level: RequestResponse
    resources:
      - group: "apps"
        resources: ["deployments", "statefulsets"]
    verbs: ["create", "update", "patch", "delete"]
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["pods/exec", "pods/attach"]
  - level: Metadata
    resources:
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"

RequestResponse loggt sowohl die Anfrage als auch die Antwort der API. Das ist fuer Secret-Zugriffe und Deployment-Aenderungen notwendig. Fuer Authentication/Authorization-Events reicht Metadata, da der Body keine relevanten Informationen enthaelt.

Die Logs muessen in ein SIEM-System fliessen und dort mindestens fuenf Jahre aufbewahrt werden. Ein lokales Audit-Log-File auf dem Node reicht nicht. Dafuer eignet sich ein Stack aus Vector oder Fluentd als Log-Shipper und einem zentralen Log-Backend mit Write-Once-Semantik.

Mehr zum Thema Observability unter Kubernetes Observability Stack.

Hochverfuegbarkeit und Notfallmanagement

Die BAIT (Kapitel 10) fordert getestete Notfallplaene. Fuer Kubernetes bedeutet das: Multi-Zone-Deployment, PodDisruptionBudgets und eine dokumentierte Disaster-Recovery-Prozedur.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: core-banking-pdb
  namespace: core-banking
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: core-banking-api
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: core-banking-api
  namespace: core-banking
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: core-banking-api
      containers:
        - name: banking-api
          image: registry.internal/core-banking:v4.2
          ports:
            - containerPort: 8443
          resources:
            requests:
              cpu: "2"
              memory: "4Gi"
            limits:
              cpu: "4"
              memory: "8Gi"

maxUnavailable: 0 stellt sicher, dass bei einem Rolling Update kein Pod wegfaellt, bevor ein neuer bereit ist. topologySpreadConstraints verteilt die Pods gleichmaessig ueber Availability Zones. Das PodDisruptionBudget verhindert, dass bei einem Node-Drain weniger als zwei Pods uebrig bleiben.

Managed Kubernetes als Auslagerung

Wenn eine Bank Managed Kubernetes nutzt, ist das nach BAIT eine wesentliche Auslagerung, die bei der BaFin angezeigt werden muss. Folgende Punkte muessen dokumentiert sein:

Ein Provider mit C5-Testat und ISO 27001 deckt einen Grossteil der Control-Plane-Sicherheit ab. Aber die Shared Responsibility bleibt: RBAC, Network Policies, Anwendungssicherheit und Compliance-Dokumentation liegen weiterhin bei der Bank.

Mehr zur Auswahl eines Managed-Kubernetes-Providers unter Managed Service vs. Inhouse Vergleich.

Encryption at Rest konfigurieren

Die BAIT fordert Verschluesselung sensibler Daten. In Kubernetes betrifft das vor allem Secrets und ConfigMaps:

# EncryptionConfiguration fuer den API Server
# Datei: /etc/kubernetes/encryption-config.yaml
# Referenziert ueber: --encryption-provider-config flag

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
      - configmaps
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-encoded-32-byte-key>
      - identity: {}

In Managed-Kubernetes-Umgebungen (AKS, EKS, GKE) ist Encryption at Rest meistens standardmaessig aktiv, oft mit einem Cloud-KMS-Backend. Trotzdem sollte man das explizit pruefen und dokumentieren. Ein BaFin-Pruefer wird danach fragen.

Haeufige BaFin-Findings vermeiden

Aus der Praxis: Diese Findings tauchen bei BaFin-Pruefungen von Kubernetes-Umgebungen immer wieder auf.

Der wichtigste Rat: Nicht erst bei der Ankuendigung einer Pruefung anfangen, die Dokumentation zusammenzusuchen. Wenn die Cluster-Konfiguration in Git liegt (GitOps), hat man den Grossteil der technischen Dokumentation automatisch.

Fazit

Kubernetes in der Finanzbranche ist machbar, wenn man die regulatorischen Anforderungen von Anfang an mitdenkt. Die technischen Bausteine sind da: RBAC fuer Funktionstrennung, Network Policies fuer Segmentierung, Audit Logs fuer Protokollierung, PDBs und Topology Constraints fuer Hochverfuegbarkeit.

Der Aufwand liegt in der Dokumentation und in den Prozessen drumherum. Ein GitOps-Workflow mit ArgoCD oder Flux liefert den Audit Trail als Nebenprodukt. Mehr dazu unter GitOps mit ArgoCD.

Wenn Sie Unterstuetzung bei der MaRisk/BAIT-konformen Kubernetes-Einfuehrung brauchen, sprechen Sie uns an unter /kontakt.