MHC-04 Workload-Identität und Zero-Trust-Netzwerkarchitektur

Auf einen Blick

Operativer Nutzen

Reduziert credential-basierte seitliche Ausbreitung nach einer Erstkompromittierung strukturell und begrenzt den erreichbaren Schadensradius; ein übernommener Dienst kann sich nicht mehr über wiederverwendete Zugangsdaten zu Nachbardiensten weiterbewegen. Innerhalb der eigenen Berechtigungen kann eine kompromittierte Workload weiterhin handeln – daher in Kombination mit Berechtigungsminimierung und Detection (MHC-05).

Betroffene Richtlinie

Zugriffssteuerungs- und Netzwerksicherheitsrichtlinie.

Abhängigkeiten

bildet die Identitätsgrundlage für MHC-13; selbst ohne Vorbedingung.

Aufwandstreiber

Die Umstellung bestehender Dienste bindet mehr Ressourcen als ein Neubau; der konkrete Aufwand hängt von den verfügbaren Ressourcen der Organisation ab.

Primäre Kennzahl

Anteil der produktiven Dienst-zu-Dienst-Verbindungen mit Workload-Identität und mTLS.

Berührte Standards (ohne Erfüllungsanspruch)

u. a. ISO/IEC 27002 A.8.20/A.8.21/A.8.22, NIST SP 800-207 und 800-207A, NIS2-DVO Nr. 6.7/8/11.

Control-Statement

Jede produktive Workload (Dienst, Prozess, Container, AI-Agent) erhält eine eindeutige, kryptografisch verifizierbare Identität mit kurzlebigen, automatisch rotierenden Credentials. Die Identität selbst ist stabil und eindeutig zuordenbar; kurzlebig und nicht wiederverwendbar sind die daraus abgeleiteten Credentials (z. B. SVIDs, Zertifikate, Token). Die Kommunikation zwischen Diensten wird anhand dieser Identität autorisiert, nicht anhand der Netzwerklage (IP-Adresse, Subnetz, Perimeter). Weiterführende Härtung (Stufe Managed): Ausweitung auf Entwicklungs- und Testumgebungen sowie identitätsbasierte Mikrosegmentierung.

Zweck und Bedrohungsbezug

Mit AI beschleunigte Angreifer gelangen von der Erstkompromittierung zur seitlichen Ausbreitung (Lateral Movement) innerhalb von Minuten. Klassische Perimeter-, VPN- und Jump-Host-Modelle vertrauen einem Dienst allein wegen seiner Netzwerklage; ein übernommener Host erhält dadurch faktisch Zugriff auf die Nachbardienste. Eine eigene Identität je Workload entzieht diesem Muster die Grundlage: ohne gültige, kurzlebige Identität kommt keine Verbindung zustande. Ziel ist, die klassischen Pfade für die seitliche Ausbreitung strukturell zu schließen. Der Schutz beruht auf einer kryptografischen Barriere, nicht darauf, dass ein Angriff nur verzögert wird.

Wirkung in den Regelwerken

Auf diese Controls und Anforderungen wirkt das MHC. Die Einstufung zeigt, wie stark das jeweilige Control unter KI-gestützten Angriffen an Wirkung verliert.

Alle 93 Controls in der Analysematrix · Alle 23 Anforderungen der Bausteinfamilie

Reifegrad-Pfad

Initial

SPIFFE/SPIRE für privilegierte Workloads; mTLS auf den 3–5 kritischsten Dienst-zu-Dienst-Pfaden.

Defined

Workload-Identität für alle produktiven Microservices sowie für alle produktiven, unter MHC-13 fallenden AI-Agenten und agentischen Workflows; ZTNA für privilegierten Remote-Zugriff.

Managed

flächendeckend inklusive Dev/Test; identitätsbasierte Mikrosegmentierung; AI-Agenten mit capability-scoped Identitäten.

Messung und Audit-Nachweis

Kennzahlen

Anteil der produktiven Dienst-zu-Dienst-Verbindungen mit mTLS/Workload-Identität (Zielwert Defined: 100 % produktiv); Zeit bis zum Entzug einer Workload-Identität.

Stage-Gate (Richtwert)

Initial ≥ 80 % der privilegierten Service-Workloads mit SPIFFE/SPIRE-Identität; Defined mTLS-Pflicht für Ost-West-Verkehr: 100 % der In-Scope-Verbindungen oder dokumentierte, befristete und risikogenehmigte Ausnahmen (≥ 95 % nur als Übergangsschwelle, nicht als vollständige Defined-Erfüllung); Managed attestierungsgestützte Zugriffspolicies produktiv. Gate-Erfüllung als Ja/Nein-Nachweis im Projektcontrolling (MRIS Kap. 10.6).

Nachweis

SPIRE-Registry (Inventar der ausgestellten Identitäten), Service-Mesh-Policy-Konfiguration, Protokolle der mTLS-Durchsetzung.

Nachweislogik (in Anlehnung an ISO/IEC 27001, Clause 9)

dokumentiert? — über die SPIRE-Registry; verantwortlich? — Plattform-Team; Häufigkeit? — fortlaufend (Erneuerung im Minuten- bis Stundentakt); Toleranz? — keine produktiven, im Klartext gespeicherten gemeinsamen Geheimnisse auf kritischen Pfaden.

Typische Fehler

• mTLS bleibt im Permissive-Mode (Klartext wird weiter akzeptiert) — keine Schutzwirkung.
• Identitäten mit zu langer Gültigkeit (Tage statt Minuten) — der Vorteil der kurzen Laufzeit entfällt.
• AI-Agenten arbeiten weiter unter persönlichen Entwickler-Konten — Nachvollziehbarkeit und Begrenzung der Rechte fehlen.
• Freigaben auf IP-Basis als dauerhafter Parallelweg statt als befristete, dokumentierte Ausnahme.

Abgrenzung und Restrisiko

Abgrenzung

schützt die Ebene Dienst-zu-Dienst; die Authentisierung der Endnutzer deckt MHC-03 ab; die Governance der AI-Agenten vertieft MHC-13.

Restrisiko

eine übernommene Ausstellungs-Infrastruktur (SPIRE) oder ein legitim ausgewiesener, aber übernommener Dienst bleiben wirksam; eine Identität ersetzt nicht die Minimierung der Rechte (Least Privilege bleibt erforderlich).

Wirksamkeitsgrenze

Zero Trust ist ein Architektur-Weg, kein Produkt. Eine nur teilweise umgesetzte Segmentierung oder Workload-Identität kann falsche Sicherheit erzeugen; Wirksamkeit entsteht erst, wenn Authentisierung, Autorisierung und Least Privilege durchgängig und prüfbar greifen.

ISO/IEC 27002:2022

A.5.15 Zugangssteuerung; A.5.16 Identitätsmanagement; A.6.7 Remote-Arbeit; A.8.2 Privilegierte Zugangsrechte; A.8.20 Netzwerksicherheit; A.8.21 Sicherheit von Netzwerkdiensten; A.8.22 Trennung von Netzwerken.

Framework

NIST SP 800-207 (Zero-Trust-Prinzipien); NIST SP 800-207A (Cloud-native Zero Trust, Workload-Identität, Service Mesh); SPIFFE/SPIRE (CNCF).

Umsetzung im Detail

Organisatorische und technische Umsetzung, Umsetzungsbeispiele und die Priorisierung im Gesamtprogramm beschreibt der Implementation Guide.

Implementation Guide (PDF)Zum MHC-Katalog

Quelle: MRIS Implementation Guide (ISO/IEC 27001), Fassung 2.0. Lizenz CC BY-SA 4.0. © 2026 Richard Peddi.