Verwaltung von Secrets für nichtmenschliche Identitäten in Audits 2026

Der Alarm um 02:13 Uhr, den niemand zuordnen konnte

Um 02:13 Uhr an einem Dienstagmorgen schlägt der Kanal des Security Operations Center Alarm. Ein Export aus einer Produktionsdatenbank wurde von einem internen Automatisierungskonto gestartet. Der Zugriffspfad ist legitim. Das Token ist gültig. Die Quell-IP gehört zu einem Cloud-Runner, den das Engineering-Team nutzt. Es ist keine Schadsoftware erkennbar. Es liegt keine Phishing-Meldung vor.

Der CISO stellt die erste naheliegende Frage: „Wem gehört diese Identität?“

Schweigen.

Der DevOps-Leiter erinnert sich, dass das Token vor zwei Jahren während einer Kundenmigration erstellt wurde. Das Plattformteam sagt, es werde möglicherweise von einer Abrechnungsintegration verwendet. Der Datenbankadministrator sagt, es habe Lesezugriff, weil das Entfernen dieses Zugriffs einmal einen nächtlichen Job unterbrochen habe. Die Rechtsabteilung fragt, ob personenbezogene Daten betroffen waren. Das Compliance-Team fragt, ob es sich um einen meldepflichtigen Vorfall nach NIS2, DORA oder GDPR handelt. Der Auditor fordert Nachweise, dass Servicekonten, API-Schlüssel, Zertifikate und CI/CD-Secrets inventarisiert, überprüft, rotiert, überwacht und widerrufen werden.

Um 09:00 Uhr zeichnet sich die Audit-Feststellung bereits ab. In einem vergessenen Microservice wurde ein hartcodierter, nicht rotierter API-Schlüssel entdeckt. Er gewährt weitreichenden Zugriff auf eine produktive Kundentransaktionsdatenbank. Der Entwickler, der ihn erstellt hat, hat das Unternehmen vor zwei Jahren verlassen. Das System hat keinen benannten Verantwortlichen, keinen dokumentierten Zweck, keinen Nachweis zur Rotation und keine Überwachungsregel.

Das ist das Problem nichtmenschlicher Identitäten im Jahr 2026.

Die meisten Organisationen haben die Zugriffskontrolle für menschliche Benutzer verbessert. Sie verfügen über MFA, Eintritts-, Wechsel- und Austrittsprozesse, Überprüfungen privilegierter Zugriffe und Protokolle von Identitätsanbietern. Maschinenidentitäten haben sich jedoch schneller vermehrt als die Governance. Servicekonten, Workload-Identitäten, API-Schlüssel, OAuth-Token, SSH-Schlüssel, Zertifikate, Kubernetes-Secrets, SaaS-Integrationstoken, Konten für robotergestützte Prozessautomatisierung und CI/CD-Bereitstellungszugangsdaten führen heute kritische geschäftliche Aktionen aus, ohne im menschlichen Sinn „Benutzer“ zu sein.

Für SaaS-Anbieter, Fintechs, Managed Service Provider, Cloud-Betreiber und datenintensive KMU sind unverwaltete nichtmenschliche Identitäten kein bloßes technisches Hygienethema mehr. Sie sind ein Resilienz- und Compliance-Risiko auf Ebene des Leitungsorgans. NIS2 behandelt Zugriffskontrolle, Richtlinien zum Asset-Management, Sicherheit der Lieferkette, Verfahren zum Umgang mit Informationssicherheitsvorfällen und Cyberhygiene als zentrale Maßnahmen des Cybersicherheitsrisikomanagements. DORA stellt IKT-Risiken, operative Resilienz, Vorfallmeldung und IKT-Drittparteienrisiken bei Finanzunternehmen unter die Rechenschaftspflicht des Leitungsorgans. GDPR verlangt von Verantwortlichen und Auftragsverarbeitern, personenbezogene Daten zu schützen und Rechenschaftspflicht nachzuweisen.

Der schwierige Teil besteht nicht darin, nachzuweisen, dass Secrets existieren. Der schwierige Teil besteht darin, nachzuweisen, dass jede nichtmenschliche Identität einen Verantwortlichen, einen Zweck, einen Lebenszyklus, eine Risikobewertung, genehmigte Zugriffe, eine sichere Speichermethode, eine Rotationsregel, Überwachungsabdeckung und einen Widerrufspfad hat.

Warum nichtmenschliche Identitäten zum neuen Problem des privilegierten Zugriffs wurden

Eine nichtmenschliche Identität, kurz NHI, ist jede digitale Identität, die von Software, Infrastruktur oder automatisierten Prozessen anstelle einer Person genutzt wird. In der Praxis umfasst dies Servicekonten, die von Anwendungen genutzt werden, API-Schlüssel für SaaS-Integrationen, OAuth- und Refresh-Token von Drittanwendungen, SSH-Schlüssel für Automatisierung, TLS-Zertifikate und private Schlüssel, CI/CD-Secrets, Cloud-Workload-Identitäten, Datenbank-Verbindungszeichenfolgen, eingebettete Zugangsdaten, RPA-Bot-Konten und lieferantenseitig verwaltete Integrationszugangsdaten.

Diese Identitäten weisen häufig drei Merkmale auf, die Auditoren aufmerksam machen.

Erstens sind sie langlebig. Ein menschlicher Benutzer rotiert möglicherweise Zugangsdaten, wechselt Rollen und verlässt die Organisation über einen formalen Offboarding-Prozess. Ein API-Token, das während eines Release-Fensters erstellt wurde, kann jahrelang aktiv bleiben, weil niemand riskieren möchte, die Produktion zu unterbrechen.

Zweitens sind sie mächtig. Ein Bereitstellungstoken kann Infrastruktur ändern. Ein Cloud-Service-Principal kann Speicher erstellen. Ein Datenbankkonto kann Kundendatensätze exportieren. Ein Signaturschlüssel kann die Integrität der Software-Lieferkette kompromittieren.

Drittens sind sie schwer zuzuordnen. Menschliche Identitäten sind mit HR-Datensätzen verknüpft. Nichtmenschliche Identitäten sind häufig mit Skripten, Pipelines, Lieferanten, vergessenen Projekten oder undokumentierten Integrationen verbunden.

Clarysecs Zenith Blueprint: 30-Schritte-Roadmap für Auditoren Zenith Blueprint benennt dies in der Phase „Kontrollen in der Praxis“, Schritt 22, ausdrücklich:

Und vergessen Sie die nichtmenschlichen Identitäten nicht. Genau hier decken Audits häufig stille Exponierungen auf. Werden API-Token nachverfolgt? Sind Integrationskonten Personen zugeordnet oder schweben sie im Niemandsland? Wann wurde die Datenbank-Zugriffszeichenfolge, die in einem jahrzehntealten Skript eingebettet ist, zuletzt rotiert?

Identitätsmanagement ist nicht glamourös, aber strukturell. Ohne es ist Ihr ISMS nur eine Sammlung verschlossener Türen, ohne Gewissheit darüber, wer die Schlüssel besitzt.

Der letzte Satz ist der Kern. Ein Unternehmen kann eine ausgereifte Richtlinie zur Zugriffskontrolle haben und dennoch ein Audit nicht bestehen, wenn Maschinenidentitäten unverwaltet sind. Ein ISMS, das nicht erklären kann, wem ein Secret gehört, warum es existiert und wann es zuletzt überprüft wurde, arbeitet noch nicht als kontrolliertes System.

ISO/IEC 27001:2022 macht aus der Verwaltung von Secrets belastbare Nachweise

ISO/IEC 27001:2022 ist wirksam, weil der Standard die Verwaltung von Secrets nicht als isolierte Engineering-Aufgabe behandelt. Er verlangt ein risikobasiertes ISMS mit definiertem Geltungsbereich, Anforderungen interessierter Parteien, Verantwortung der Leitung, Risikobeurteilung, Risikobehandlung, Kontrollauswahl, Erklärung zur Anwendbarkeit und kontinuierlicher Verbesserung.

Bei nichtmenschlichen Identitäten sollte die Organisation nicht mit dem Kauf eines Werkzeugs beginnen. Sie sollte mit Geltungsbereich und Verpflichtungen beginnen.

Nach den ISO/IEC 27001:2022-Klauseln 4.1 bis 4.4 bestimmt die Organisation interne und externe Themen, interessierte Parteien, gesetzliche, regulatorische und vertragliche Anforderungen, Schnittstellen und Abhängigkeiten. Im NHI-Kontext sollte der ISMS-Geltungsbereich Cloud-Umgebungen, SaaS-Plattformen, CI/CD-Systeme, Produktivanwendungen, Kundenintegrationen, Auftragsverarbeiter, Managed Service Provider und kryptografische Dienste identifizieren, in denen Maschinenzugangsdaten vorhanden sind.

Die Klauseln 5.1 bis 5.3 machen die Leitung für Richtlinien, Ressourcen, Rollen und Leistungsberichterstattung verantwortlich. Das ist wichtig, weil die Behebung von NHI-Mängeln häufig betriebliche Spannungen erzeugt. Die Rotation von Produktivdatenbank-Zugangsdaten, der Ersatz eines gemeinsam genutzten Legacy-Servicekontos oder die Durchsetzung Vault-gestützter Secret-Injektion kann fragile Workflows unterbrechen. Ohne Sponsor auf Leitungsebene verschieben Teams die Bereinigung.

Die Klauseln 6.1.1 bis 6.1.3 und 6.2 liefern die Steuerungslogik. Die Organisation definiert Risikokriterien, identifiziert Risiken für Vertraulichkeit, Integrität und Verfügbarkeit, weist Risikoverantwortliche zu, bewertet Eintrittswahrscheinlichkeit und Auswirkung, wählt Behandlungsoptionen, selektiert Kontrollen, erstellt die Anwendbarkeitserklärung und verfolgt messbare Ziele.

Praktisch muss ein Risikobehandlungsplan für nichtmenschliche Identitäten folgende Fragen beantworten:

• Welche Systeme und Geschäftsservices hängen von NHIs ab?
• Welche Secrets können auf personenbezogene Daten, regulierte Finanzdienstleistungen, Produktionsinfrastruktur oder kritische Kundenservices zugreifen?
• Welche Identitäten sind privilegiert, inaktiv, gemeinsam genutzt, lieferantenseitig verwaltet oder unverwaltet?
• Welche Kontrollen reduzieren das Risiko, etwa Vaulting, Rotation, Prinzip der minimalen Berechtigung, Ablauf, Zertifikatslebenszyklusmanagement, CI/CD-Scanning, Überwachung und Notfallwiderruf?
• Welche Restrisiken erfordern eine geschäftliche Genehmigung?

ISO/IEC 27002:2022 stellt anschließend den Kontrollkatalog aus Anhang A bereit. Zu den relevantesten Maßnahmen gehören 5.9 Inventar von Informationen und anderen zugehörigen Assets, 5.15 Zugriffskontrolle, 5.16 Identitätsmanagement, 5.17 Authentifizierungsinformationen, 5.18 Zugriffsrechte, 5.19 Informationssicherheit in Lieferantenbeziehungen, 5.20 Berücksichtigung der Informationssicherheit in Lieferantenvereinbarungen, 5.21 Management der Informationssicherheit in der IKT-Lieferkette, 5.23 Informationssicherheit bei der Nutzung von Cloud-Services, 5.24 Planung und Vorbereitung des Managements von Informationssicherheitsvorfällen, 5.28 Sammlung von Beweismitteln, 8.2 Privilegierte Zugriffsrechte, 8.3 Einschränkung des Informationszugriffs, 8.5 Sichere Authentifizierung, 8.15 Protokollierung, 8.16 Überwachungstätigkeiten, 8.24 Einsatz von Kryptografie, 8.25 sicherer Entwicklungslebenszyklus, 8.26 Anforderungen an die Anwendungssicherheit, 8.28 sichere Programmierung und 8.31 Trennung von Entwicklungs-, Test- und Produktivumgebungen.

Clarysecs Zenith Controls: Der Cross-Compliance-Leitfaden Zenith Controls bildet diese ISO/IEC 27002:2022-Beziehungen so ab, dass Auditoren und Kontrollverantwortliche sie nutzen können. Für Maßnahme 5.16, Identitätsmanagement, erklärt Zenith Controls den Zusammenhang zwischen Identität und Zugangsdaten:

Identitätsmanagement liefert das Wer, während Authentifizierungsinformationen das Wie sicherstellen, also die Verifikation, dass die Person, die eine Identität beansprucht, legitim ist. 5.16 steuert das Identitätslebenszyklusmanagement, während 5.17 sicherstellt, dass Passwörter, Token, Zertifikate und andere Zugangsdaten sicher mit diesen Identitäten verknüpft und ordnungsgemäß verwaltet werden, um starke Authentifizierung zu unterstützen.

Diese Beziehung ist für NHIs wesentlich. Ein Token ohne Identitätsverantwortlichen ist nicht auditierbar. Ein Servicekonto ohne Berechtigungsüberprüfung entspricht nicht dem Prinzip der minimalen Berechtigung. Ein Zertifikat ohne Lebenszyklusstatus ist keine kontrollierte Kryptografie. Ein Integrationszugang eines Lieferanten ohne Vertragsbedingungen ist kein wirksames Drittparteienrisikomanagement.

Das Clarysec-Kontrollmuster: Identität, Secret, Berechtigung, Nachweis

Clarysec setzt das Management nichtmenschlicher Identitäten und Secrets über ein wiederholbares Kontrollmuster um. Wir behandeln „Secrets“ nicht ausschließlich als DevOps-Thema und „Servicekonten“ nicht ausschließlich als IAM-Thema. Wir verbinden Identität, Secret, Berechtigung und Nachweis.

Die Richtlinienebene macht dies durchsetzbar.

Für KMU legt Clarysecs Richtlinie zur Verwaltung von Benutzerkonten und Berechtigungen für KMU Richtlinie zur Verwaltung von Benutzerkonten und Berechtigungen für KMU fest:

Servicekonten, die von Systemen oder Anwendungen genutzt werden, müssen dokumentiert, auf bestimmte Systeme beschränkt und dürfen niemals für interaktive Anmeldungen verwendet werden.

Dies verhindert das klassische Anti-Pattern, bei dem ein Servicekonto zu einem gemeinsam genutzten Administrator-Login wird. Zudem erhält der Auditor einen klaren Test: Servicekonto-Inventar vorlegen, Systembeschränkung nachweisen und zeigen, dass interaktive Anmeldung deaktiviert oder technisch verhindert ist.

Clarysecs Richtlinie zum Asset-Management für KMU Richtlinie zum Asset-Management für KMU erweitert die Definition von Assets um:

Digitale Zugangsdaten und Dienste: Domainnamen, digitale Zertifikate, API-Schlüssel, E-Mail-Konten, Cloud-Logins

Das ist relevant, weil viele Organisationen nur Server, Laptops und Anwendungen inventarisieren. Im Jahr 2026 kann ein API-Schlüssel sensibler sein als ein Laptop. Ein privater Zertifikatsschlüssel kann ein produktives Authentifizierungs-Asset sein. Ein durch Automatisierung genutzter Cloud-Login kann regulierte Daten exponieren. Zugangsdaten als Assets zu behandeln, ist die Grundlage für auditfähige Verwaltung von Secrets.

Für Unternehmensumgebungen setzt Clarysecs Richtlinie zur Verwaltung von Benutzerkonten und Berechtigungen Richtlinie zur Verwaltung von Benutzerkonten und Berechtigungen die Messlatte für Nachweise höher:

Die Organisation muss ein detailliertes Inventar aller aktiven und inaktiven Zugangsdaten, privilegierten Konten sowie Servicekonten auf Systemebene führen. Dieses Inventar muss kontinuierlich aktualisiert und vierteljährlich überprüft werden.

Bei der vierteljährlichen Überprüfung werden viele Lücken sichtbar. Inaktive Zugangsdaten, verwaiste Service-Principals, alte Integrationsbenutzer, unverwaltete Lieferantenkonten und Notfalltoken werden erst sichtbar, wenn jemand das Register mit den tatsächlichen IAM-, Vault-, CI/CD- und Cloud-Aufzeichnungen vergleicht.

Secrets sind Authentifizierungsinformationen, keine Entwicklerbequemlichkeit

Der gefährlichste Ausdruck in der Verwaltung von Secrets lautet „temporärer Schlüssel“.

Temporäre Schlüssel werden dauerhaft. Testzugangsdaten gelangen in die Produktion. Quellcode legt Token offen. Build-Protokolle exponieren Passwörter. Supportteams teilen Zertifikate über Tickets. Entwickler kopieren Umgebungsdateien in Chats. Ein Auftragnehmer erstellt einen Cloud-Service-Principal und verlässt das Projekt.

Der Zenith Blueprint, Phase „Kontrollen in der Praxis“, Schritt 22, beschreibt Authentifizierungsinformationen umfassend:

Bei dieser Kontrolle geht es nicht nur um Passwörter, auch wenn Passwörter selbstverständlich Teil des Gesamtbilds sind. Es geht um alle Zugangsdaten, die zur Bestätigung einer Identität genutzt werden: Passwörter, PINs, kryptografische Schlüssel, biometrische Vorlagen, Smartcards, Token, Zertifikate, OAuth-Token, SSH-Schlüssel, API- Secrets. Das sind die Schlüssel zum Königreich, und Maßnahme 5.17 stellt sicher, dass diese Schlüssel mit der gebotenen Ernsthaftigkeit behandelt werden.

Klar gesagt: Schwaches Authentifizierungsmanagement bleibt eine der wichtigsten Ursachen für Sicherheitsverletzungen. Schwache oder gemeinsam genutzte Passwörter. Hartcodierte Zugangsdaten im Quellcode. Unveränderte Standard-Logins auf Admin-Portalen. Zertifikate mit abgelaufener oder unbekannter Verantwortlichkeit. In all diesen Fällen ist nicht die Identität gescheitert, sondern der Schutz und die Steuerung des Mechanismus, mit dem diese Identität nachgewiesen wird.

Clarysec-Richtlinien übersetzen dies in operative Regeln.

Die Richtlinie zu kryptografischen Kontrollen für KMU Richtlinie zu kryptografischen Kontrollen für KMU legt fest:

Schlüssel dürfen nicht im Klartext gespeichert oder in Quellcode, Dokumente oder E-Mails eingebettet werden.

Die Richtlinie für sichere Softwareentwicklung für KMU Richtlinie für sichere Softwareentwicklung für KMU legt fest:

Keine hartcodierten Zugangsdaten oder Secrets im Quellcode

Für Unternehmen legt die Richtlinie für sichere Softwareentwicklung Richtlinie für sichere Softwareentwicklung fest:

Secrets dürfen nicht hartcodiert oder im Klartext in Repositories gespeichert werden.

Und die Richtlinie zu Anforderungen an die Anwendungssicherheit Richtlinie zu Anforderungen an die Anwendungssicherheit ist noch direkter:

Die Speicherung von Passwörtern oder kryptografischen Schlüsseln im Klartext ist streng untersagt.

Diese Richtlinienklauseln schaffen einen klaren Prüfpfad. Sicherheitsteams können Repositories, CI/CD-Variablen, Container-Images, Konfigurationsspeicher, Vorgangsmanagementsysteme, Dokumentationsplattformen und Protokolle gegen explizite Anforderungen testen. Sie unterstützen auch GDPR Article 32 zur Sicherheit der Verarbeitung, weil die Offenlegung von Secrets direkt zu unbefugtem Zugriff auf personenbezogene Daten führen kann.

Kryptografische Governance in Unternehmen benötigt zudem Verantwortlichkeit. Clarysecs Richtlinie zu kryptografischen Kontrollen Richtlinie zu kryptografischen Kontrollen verlangt:

Ein zentrales Schlüsselmanagement-Register muss geführt werden, um alle kryptografischen Schlüssel, deren Lebenszyklusstatus, zugewiesene Verwahrer und Nutzungskontexte zu dokumentieren.

Für nichtmenschliche Identitäten sollte dieses Register Zertifikatsschlüssel, Signaturschlüssel, API-Schlüssel und cloudseitig verwaltete Schlüssel mit dem übergreifenden NHI-Register verbinden. Der Auditor sollte ein Produktivzertifikat vom Geschäftsservice über Verantwortlichen, Verwahrer, Ablaufdatum und Rotationsnachweis bis hin zum Incident-Response-Verfahren nachvollziehen können.

NIS2, DORA und GDPR: ein Nachweismodell, viele Aufsichtsbehörden

Governance nichtmenschlicher Identitäten ist ein Cross-Compliance-Problem, weil derselbe Fehler mehrere Verpflichtungen auslösen kann.

Ein offengelegtes API-Token bei einem SaaS-Anbieter kann eine Serviceunterbrechung nach NIS2, die Exponierung personenbezogener Daten nach GDPR und vertragliche Vorfallmeldungen gegenüber Finanzkunden unter DORA-Lieferkettenerwartungen verursachen. Ein kompromittiertes CI/CD-Secret bei einem IKT-Dienstleister kann Kundenresilienz, Softwareintegrität und operative Kontinuität beeinträchtigen. Ein vergessenes Lieferanten-Integrationskonto kann Zugang zu regulierten Systemen schaffen, ohne angemessene Sorgfaltsprüfung oder Vertragskontrollen.

NIS2 Article 21 verlangt angemessene und verhältnismäßige technische, operative und organisatorische Maßnahmen. Die Mindestbereiche umfassen Risikoanalyse, Richtlinien zur Sicherheit von Informationssystemen, Verfahren zum Umgang mit Informationssicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, sichere Beschaffung, Entwicklung und Wartung, Umgang mit Schwachstellen, Wirksamkeitsbewertung, Cyberhygiene, Kryptografie, HR-Sicherheit, Zugriffskontrolle und Richtlinien zum Asset-Management sowie gegebenenfalls MFA oder kontinuierliche Authentifizierung. Nichtmenschliche Identitäten liegen nahezu über allen diesen Bereichen. NIS2 Article 23 schafft außerdem gestufte Meldungen erheblicher Vorfälle, einschließlich Frühwarnung innerhalb von 24 Stunden, Vorfallmeldung innerhalb von 72 Stunden und Abschlussbericht spätestens einen Monat nach der Vorfallmeldung.

DORA gilt seit dem 17. Januar 2025 und umfasst IKT-Risikomanagement, Meldung schwerwiegender IKT-bezogener Vorfälle, Tests der operativen Resilienz, Informationsaustausch und IKT-Drittparteienrisiken. Articles 5 und 6 verlangen Governance, Rechenschaftspflicht des Leitungsorgans und ein dokumentiertes Rahmenwerk für das Management von IKT-Risiken. Article 8 verlangt die Identifizierung IKT-gestützter Geschäftsfunktionen, Informations-Assets und Abhängigkeiten. Articles 17 bis 19 verlangen Vorfallmanagement, Klassifizierung und Berichterstattung. Articles 28 bis 30 verlangen IKT-Drittparteienrisikomanagement, Vertragsregister, Sorgfaltsprüfungen, Sicherheitsstandards, Auditrechte, Unterstützung bei Vorfällen, Kontrollen für Unterauftragsvergabe und Exit-Strategien.

GDPR gilt überall dort, wo personenbezogene Daten in seinem territorialen Anwendungsbereich verarbeitet werden. Article 5 verlangt Integrität, Vertraulichkeit und Rechenschaftspflicht. Article 32 verlangt geeignete technische und organisatorische Maßnahmen für die Sicherheit der Verarbeitung. Wenn ein Servicekonto oder API-Schlüssel auf personenbezogene Daten zugreifen kann, werden unverwaltete Secrets zu einem Datenschutzkontrollversagen und nicht nur zu einem IT-Problem.

Dieselben Nachweise können ISO/IEC 27001:2022-Zertifizierung, NIS2-Aufsicht, DORA-Prüfungen und GDPR-Rechenschaftspflicht unterstützen, wenn sie richtig strukturiert sind.

NIST CSF 2.0 kann als Kommunikationsebene für dieselben Nachweise genutzt werden. Die Funktion GOVERN umfasst Erwartungen von Interessenträgern, gesetzliche und vertragliche Verpflichtungen, Risikobereitschaft, Verantwortung der Leitung, Richtlinien und Aufsicht. Die operativen Ergebnisse umfassen Asset-Inventare, von Lieferanten erbrachte Services, Identitäts- und Zugangsdatenmanagement, Prinzip der minimalen Berechtigung, Datensicherheit, Protokollierung, Überwachung, Incident Response und Wiederherstellung.

COBIT 2019 und Assurance-Teams nach ISACA-Prägung betrachten in der Regel Governance und Prozessfähigkeit. Sie fragen, ob Verantwortlichkeiten zugewiesen sind, ob Kontrollen in operative Prozesse eingebettet sind, ob Ausnahmen genehmigt werden, ob Kennzahlen an das Management berichtet werden und ob Nachweise Wiederholbarkeit statt einer einmaligen Bereinigung belegen.

Ein praxisnaher Sprint zum Aufbau eines Registers für nichtmenschliche Identitäten

Ein praxisnahes Clarysec-Engagement beginnt häufig mit einem fokussierten Sprint, nicht mit einem sechsmonatigen Tooling-Programm. Ziel ist ein belastbares NHI-Register, eine Risikoeinstufung und ein Mängelbehebungsplan, die in den ISO/IEC 27001:2022-Risikobehandlungsplan und die Anwendbarkeitserklärung einfließen können.

Beginnen Sie mit einem Geschäftsservice, etwa einer Kundenabrechnungsplattform, einer Handelsanwendung, einem Patientenportal oder einem SaaS-Tenant-Managementsystem. Beziehen Sie Produktion, Staging, CI/CD, Cloud-Infrastruktur, Monitoring-Werkzeuge, Datenbanken, SaaS-Integrationen und lieferantenseitig verwaltete Services ein.

Verknüpfen Sie dies mit Zenith Blueprint, Phase Risikomanagement, Schritt 14, in dem Clarysec Behandlungsrichtlinien mit regulatorischen Querverweisen abgleicht. In diesem Schritt umfassen sichere Entwicklungs- und Pipeline-Kontrollen keine hartcodierten Secrets, Peer-Review, automatisierte statische Analyse, Dependency-Scanning, Trennung von Entwicklung, Test und Produktion, MFA für Pipeline-Zugriff, Integrität von Build-Artefakten und CI/CD-Protokollierung.

Erheben Sie Identitäten und Secrets aus Identitätsanbietern, Cloud-IAM, Secret-Vaults, Kubernetes, CI/CD-Variablen, Repository-Einstellungen, Datenbankbenutzern, SaaS-Administrationskonsolen, Zertifikatsmanagement-Werkzeugen und Lieferantendokumentation.

Bewerten Sie Identitäten risikobasiert, die Produktionszugriff, privilegierte Rechte, Zugriff auf personenbezogene Daten, Abhängigkeit von kritischen oder wichtigen Funktionen, Lieferantenkontrolle, langlebige Token, keinen Verantwortlichen, keine Rotation, keine Überwachung oder hartcodierte Speicherung aufweisen. Nutzen Sie ISO/IEC 27001:2022-Risikokriterien, um Eintrittswahrscheinlichkeit und Auswirkung zu bewerten. Verwenden Sie DORA-Analysen zu kritischen oder wichtigen Funktionen, soweit anwendbar. Berücksichtigen Sie GDPR-Auswirkungen, wenn personenbezogene Daten zugänglich sind. Nutzen Sie NIS2-Serviceauswirkungen, wenn Störungen oder Kundenschäden plausibel sind.

Wenden Sie für jede Hochrisiko-NHI Behandlungsmaßnahmen an. Verschieben Sie Secrets aus Quellcode, Dokumenten und CI/CD-Klartextvariablen in einen Vault oder verwalteten Secret-Speicher. Ersetzen Sie gemeinsam genutzte Servicekonten durch eindeutige Workload-Identitäten. Deaktivieren Sie interaktive Anmeldung für Servicekonten. Wenden Sie das Prinzip der minimalen Berechtigung und umgebungsspezifische Zugangsdaten an. Konfigurieren Sie Rotation, Ablauf und Notfallwiderruf. Binden Sie Secrets an Verantwortliche und Verwahrer. Ergänzen Sie Protokollierung für Authentifizierung, Tokennutzung und sensitive Aktionen. Ergänzen Sie Warnmeldungen für auffällige Geografie, ungewöhnliche Zeitpunkte, ungewöhnliches Volumen oder neuen Ressourcenzugriff. Aktualisieren Sie Lieferantenverträge für die Handhabung von Zugangsdaten, Unterstützung bei Vorfällen und Auditrechte. Dokumentieren Sie Ausnahmen mit Genehmigung des Risikoverantwortlichen und Ablaufdatum.

Die Richtlinie zu Testdaten und Testumgebungen Richtlinie zu Testdaten und Testumgebungen unterstützt die Umgebungstrennung:

Die Integration mit CI/CD-Pipelines muss die Trennung von Umgebungen und Authentifizierungsdaten durchsetzen.

Diese Klausel ist häufig entscheidend. Wenn Entwicklung, Test und Produktion Secrets gemeinsam nutzen, kann eine Umgebung mit geringerem Risiko zum Pfad für eine Produktionsverletzung werden.

Der Sprint sollte mit einem Nachweispaket enden, nicht nur mit einer Liste von Feststellungen. Nehmen Sie den Export des NHI-Registers, Einträge aus der Risikobeurteilung, den Behandlungsplan, die Zuordnung zur Anwendbarkeitserklärung, Richtlinienreferenzen, Vault-Screenshots, Rotationsprotokolle, Genehmigungen aus Berechtigungsüberprüfungen, Ergebnisse des CI/CD-Secret-Scannings, Definitionen von Überwachungsregeln, eine Verantwortlichkeitsmatrix für Lieferantenzugangsdaten, ein Incident-Runbook sowie Ausnahmen mit Verantwortlichen und Ablaufdaten auf.

Protokollierung und Erkennung: nachweisen, dass die Nutzung von Maschinenidentitäten sichtbar ist

Eine Maschinenidentität, die gut inventarisiert, aber in Protokollen unsichtbar ist, bleibt gefährlich. Erkennung ist Teil der Kontrollgeschichte.

Clarysecs Richtlinie zur Protokollierung und Überwachung für KMU Richtlinie zur Protokollierung und Überwachung für KMU umfasst Authentifizierungsnachweise:

Authentifizierungsprotokolle: erfolgreiche und fehlgeschlagene Anmeldeversuche, Sitzungsdauer, MFA-Nutzung

Passen Sie diese Anforderung für NHIs an Maschinenauthentifizierung an. Für eine Workload-Identität gibt es möglicherweise keine MFA-Nutzung, aber es sollten Authentifizierungsereignisse, Tokennutzung, Zertifikatsnutzung, API-Aufruf-Metadaten, Quell-Workload, Zielservice, Token-Lebensdauer, Fehlerereignisse und privilegierte Aktionen vorliegen.

In Zenith Controls ist ISO/IEC 27002:2022-Maßnahme 8.2, Privilegierte Zugriffsrechte, mit Protokollierung und Überwachung verknüpft, weil privilegierte Konten detaillierte Aufzeichnungen und Aufsicht erfordern. Zenith Controls verknüpft 8.2 zudem mit Identitätsmanagement, Zugriffsrechten, Einschränkung des Informationszugriffs und sicherer Authentifizierung. Für Auditoren bedeutet dies: Privilegierte nichtmenschliche Identitäten sollten mit derselben Ernsthaftigkeit überprüft und überwacht werden wie menschliche Administratoren, manchmal sogar strenger.

Gute Überwachungsfragen sind:

• Hat sich ein Servicekonto von einer unerwarteten Workload oder einem unerwarteten IP-Bereich authentifiziert?
• Hat ein API-Schlüssel auf einen neuen Endpunkt oder Datenbestand zugegriffen?
• Wurde ein Zertifikat nach seiner Ersetzung weiter genutzt?
• Hat ein CI/CD-Token außerhalb einer genehmigten Pipeline bereitgestellt?
• Hat ein Konto mit Nur-Lese-Zugriff Schreiboperationen versucht?
• Wurden inaktive Zugangsdaten wieder aktiv?
• Hat eine Lieferantenintegration außerhalb vereinbarter Zeiten oder Volumina auf Daten zugegriffen?

Wenn der Alarm um 02:13 Uhr auftritt, müssen Sie beantworten können, welche Identität verwendet wurde, welches Secret sie authentifiziert hat, welche Zugriffsrechte ausgeübt wurden, welche Daten oder Systeme betroffen waren, ob die Aktivität erwartet war, welcher Verantwortliche sie validieren kann und ob Schwellenwerte für Vorfallmeldungen erreicht sind.

Die Sicht des Auditors: derselbe Prozess, unterschiedliche Fragen

Die stärkste Auditposition lautet nicht: „Wir erfüllen alles.“ Sie lautet: „Wir betreiben einen kontrollierten Prozess, der Nachweise für mehrere Verpflichtungen erzeugt.“ Unterschiedliche Auditoren prüfen diesen Prozess unterschiedlich.

Über diese Perspektiven hinweg sind die wiederkehrenden Feststellungen vorhersehbar: kein einheitliches NHI-Inventar, kein Verantwortlicher für Maschinenidentitäten, im Code oder in Dokumentation gespeicherte Secrets, gemeinsam genutzte Zugangsdaten über Umgebungen hinweg, keine Rotation oder kein Ablauf, lieferantenseitig verwaltete Zugangsdaten außerhalb von Berechtigungsüberprüfungen, Überwachung, die Menschen abdeckt, aber keine Maschinen, und Incident-Runbooks, die Secret-Leakage ignorieren.

Jede Feststellung lässt sich natürlich auf Clarysec-Kontrollen, -Richtlinien und -Mängelbehebungsvorlagen abbilden. Wichtiger ist: Jede kann innerhalb des ISMS in messbare Nachweise überführt werden.

Wie Clarysec Sie auditfähig macht

Der Ansatz von Clarysec ist praxisnah, weil er mit den Nachweisen beginnt, die Auditoren anfordern werden, und rückwärts in Kontrollen, Richtlinien und operative Routinen arbeitet.

Im Zenith Blueprint, Phase „Kontrollen in der Praxis“, Schritt 19, gibt Clarysec direkte Anleitung für Maschine-zu-Maschine-Authentifizierung:

Für Maschine-zu-Maschine-Authentifizierung, etwa Servicekonten oder API-Aufrufe, müssen Schlüssel, Zertifikate und Token ebenso konsequent geschützt werden. Vermeiden Sie die Einbettung von Zugangsdaten in Code. Verwenden Sie Secret-Management-Systeme oder Vaults, um sie sicher zu speichern und zu rotieren.

Ein typischer Clarysec-Workstream für nichtmenschliche Identitäten umfasst NHI-Discovery über Cloud, SaaS, CI/CD, Repositories, Vaults und Datenbanken, eine Richtlinienlückenbewertung anhand der Clarysec-Richtliniensätze für KMU oder Unternehmen, ISO/IEC 27001:2022-Risikobeurteilung und Zuordnung der Behandlung, Aktualisierungen der Anwendbarkeitserklärung, Nachweiszuordnung für NIS2, DORA, GDPR und NIST CSF, Design des NHI-Registers, Abgleich mit dem Schlüsselmanagement-Register, Secret-Scanning, Prozesse zur Berechtigungsüberprüfung, Verantwortlichkeitsmatrizen für Lieferantenzugangsdaten, Incident-Runbooks und Auditpakete mit Screenshots, Exporten, Protokollen, Genehmigungen und Ausnahmenaufzeichnungen.

Für KMU ist der Ansatz verhältnismäßig. Ein SaaS-Anbieter mit 70 Mitarbeitenden benötigt nicht denselben Tooling-Footprint wie eine globale Bank, aber er benötigt Verantwortlichkeit, Richtlinien, Risikobehandlung und Nachweise. Für regulierte Finanzunternehmen und IKT-Anbieter skaliert dasselbe Modell in DORA-Zuordnung kritischer Funktionen, Drittparteienrisiko-Governance und Resilienztests.

Wenn Ihr nächstes Audit im Jahr 2026 stattfindet, warten Sie nicht darauf, dass der Auditor die nichtmenschlichen Identitäten für Sie entdeckt. Beginnen Sie mit einem kritischen Service und stellen Sie fünf Fragen:

1. Kennen wir jedes Servicekonto, jeden API-Schlüssel, jedes Token, jedes Zertifikat und jedes CI/CD-Secret, das von diesem Service genutzt wird?
2. Hat jede NHI einen benannten Verantwortlichen, Verwahrer, Zweck und eine Risikobewertung?
3. Werden Secrets in Vaults gespeichert, rotiert und vor Quellcode, Dokumenten, E-Mails und Klartextspeicherung geschützt?
4. Werden privilegierte Maschinenidentitäten überprüft, überwacht und von interaktiver Nutzung ausgeschlossen?
5. Können wir Nachweise für ISO/IEC 27001:2022, NIS2, DORA und GDPR aus einem kontrollierten Prozess erzeugen?

Nutzen Sie Zenith Blueprint: 30-Schritte-Roadmap für Auditoren Zenith Blueprint, um Ihre ISMS-Umsetzung zu strukturieren. Nutzen Sie Zenith Controls: Der Cross-Compliance-Leitfaden Zenith Controls, um ISO/IEC 27002:2022-Kontrollen zu Identität, Authentifizierung, Berechtigungen, Protokollierung, Kryptografie, sicherer Entwicklung und Lieferantenkontrollen mit regulatorischen Nachweisen zu verbinden. Nutzen Sie die Clarysec-Richtlinienbibliothek für KMU und Unternehmen, einschließlich der Richtlinie zur Verwaltung von Benutzerkonten und Berechtigungen für KMU Richtlinie zur Verwaltung von Benutzerkonten und Berechtigungen für KMU, Richtlinie zu kryptografischen Kontrollen Richtlinie zu kryptografischen Kontrollen, Richtlinie für sichere Softwareentwicklung Richtlinie für sichere Softwareentwicklung und Richtlinie zu Anforderungen an die Anwendungssicherheit Richtlinie zu Anforderungen an die Anwendungssicherheit, um gute Absichten in durchsetzbare Anforderungen zu überführen.

Der Alarm um 02:13 Uhr wird irgendwo auftreten. Die Frage ist, ob Ihre Organisation mit Nachweisen beantworten kann, wer den Schlüssel hatte, was er geöffnet hat, warum er existierte und wie schnell Sie ihn absichern können.