Kerberos Compliance: Authentifizierung prüfen, Risiken belegen, Audit bestehen

Kerberos ist seit MIT 1988 das Standardprotokoll für Authentifizierung in Microsoft Active Directory und wird in nahezu jedem deutschen Unternehmen produktiv eingesetzt. Mit ISO/IEC 27001:2022 Annex A.8.5 (Secure Authentication) und der NIS-2-Richtlinie ab 18. Oktober 2024 rückt das Protokoll in den Fokus der Prüfer. Wer Ticket Granting Tickets, Service-Principals und Schlüsselableitungen nicht dokumentiert, kann im Audit keinen Kontrollnachweis erbringen und riskiert Findings auf Stufe Major. Auch das Bundesamt für Sicherheit in der Informationstechnik verweist im IT-Grundschutz-Baustein APP.2.2 explizit auf Mindestanforderungen an Verschlüsselung, Kontotrennung und Vorfallreaktion im Active Directory.

Dieser Artikel ordnet Kerberos Compliance entlang der drei Ebenen ein, die Prüfer tatsächlich abfragen: Konfiguration, Betrieb und Reaktion. Sie erfahren, welche kryptografischen Parameter heute zulässig sind, welche Kerberoasting- und Golden-Ticket-Risiken Sie nachweislich adressieren müssen und wie sich Erkenntnisse aus Active-Directory-Assessments in das Informationssicherheits-Managementsystem rückführen lassen. Der Beitrag zeigt zudem, welche Verantwortlichkeiten zwischen Informationssicherheitsbeauftragtem, Compliance-Beauftragtem und IT-Betrieb geklärt sein müssen, damit Belege im Auditfall sofort vorliegen. CIVAC begleitet diesen Prozess als Compliance-Plattform und Officer-as-a-Service mit Audit-Vorlagen, Bestellurkunde und Berichtslinie. Lizenzieren Sie den Workspace für Ihre internen Beauftragten oder lassen Sie unsere Beauftragten bestellen. Beide Wege führen zum selben Ergebnis: ein dokumentierter, prüffähiger Kerberos-Härtungsgrad.

Kerberos verteilt Tickets aus einem Key Distribution Center und reduziert wiederholte Passwortübertragungen. Diese Architektur ist sicherheitstechnisch vorteilhaft, erzeugt aber eigene Prüfobjekte: Tickets müssen verschlüsselt, Schlüssel müssen rotiert und Service-Accounts müssen inventarisiert werden. Im Sinne von ISO/IEC 27001:2022 Annex A.5.16 (Identitätsmanagement) und A.8.5 (Sichere Authentifizierung) ist das Protokoll ein zentraler Kontrollpunkt, kein technisches Detail. Auch im BSI-Grundschutz-Baustein ORP.4 wird Kerberos als Verfahren benannt, dessen Härtungsstatus periodisch zu prüfen ist.

Für die Compliance ergeben sich drei Pflichten. Erstens müssen Sie belegen, dass krb5-Konfigurationen aktuelle Verschlüsselungsverfahren wie AES-256 nutzen und Legacy-Suiten wie DES oder RC4 deaktiviert sind. Zweitens müssen Sie nachweisen, dass Tickets in vertretbaren Zeiträumen ablaufen, üblicherweise zehn Stunden Initial-Ticket-Gültigkeit und sieben Tage Renewable-Lifetime. Drittens müssen Sie zeigen, dass Service-Principal-Names regelmäßig überprüft und privilegierte Konten getrennt sind. Die NIS-2-Richtlinie verschärft diese Erwartung, weil Active Directory in wesentlichen und wichtigen Einrichtungen als kritisches System gilt und Ausfälle oder Kompromittierungen unmittelbar Meldepflichten auslösen.

Andere führen Compliance wie einen Aktenschrank. Wir führen sie wie Software. Im CIVAC-Workspace für den Informationssicherheitsbeauftragten liegen Kerberos-Kontrollen als auditierbare Objekte mit Verantwortlichen, Frequenzen und Belegen. Damit wird das Protokoll prüfbar, statt nur betrieblich konfiguriert. Die Geschäftsleitung erhält im selben System einen Statusbericht, in dem Härtungsgrad, Reviewstand und offene Findings zusammenlaufen. So entsteht ein durchgehender Faden von der Technik über die Organisation bis zur Berichtslinie an die Leitung, der im Audit ohne weitere Vorbereitung präsentierbar ist und Diskussionen über Verantwortlichkeiten verkürzt. Wer Kerberos als operatives Detail behandelt, übersieht die Hebelwirkung auf das gesamte Sicherheitsniveau, weil ein kompromittiertes KDC die Wirkung aller anderen Kontrollen aufhebt und das Vertrauen in Identitäten untergräbt.

Die ISO/IEC 27001:2022 nennt Kerberos nicht namentlich, fordert aber in Annex A.8.5 und A.8.16 sichere Authentifizierung und Monitoring. Wenn ein Auditor Ihren Geltungsbereich auf das Active Directory ausdehnt, prüft er die Implementierung anhand der 93 Controls. Die NIS-2-Umsetzung in Deutschland verlangt nach § 30 NIS2UmsuCG technisch-organisatorische Maßnahmen, die dem Stand der Technik entsprechen. Der BSI-Grundschutz konkretisiert das in den Bausteinen APP.2.2 Active Directory und ORP.4 Identitäts- und Berechtigungsmanagement, einschließlich Anforderungen an krb5-Konfigurationen, KRBTGT-Passwortrotation und Ticket-Encryption. Auch die Versicherungsaufsicht VAIT, die Bankenaufsicht BAIT und die Aufsicht über Zahlungsdienstleister ZAIT verweisen auf vergleichbare Anforderungen.

Damit liegen drei bis vier Rahmenwerke übereinander, die im Audit getrennt nachgewiesen werden müssen. Ein einzelnes Konfigurations-Screenshot reicht nicht. Prüfer erwarten ein Inventar der Domain Controller, eine dokumentierte Härtung mit Versionsstand, Berichte aus dem Schwachstellenscanner und eine Begründung, warum bestimmte Legacy-Konfigurationen abweichend zugelassen sind. Die Belegkette muss zeitlich konsistent sein, das heißt Härtungsentscheidung, Implementierungsdatum und Wirksamkeitsprüfung müssen aufeinander aufbauen. Wer eine Maßnahme rückwirkend datiert, riskiert Findings auf Stufe Major bis hin zum Entzug der Zertifizierung.

Der Prüfer ruft an, der Nachweis liegt bereit. Im CIVAC-Workspace verknüpfen Sie ISO-Controls, NIS-2-Maßnahmen und BSI-Bausteine mit denselben Belegen, sodass eine Kerberos-Härtung in allen drei Rahmenwerken gleichzeitig dokumentiert ist. Das spart Doppelarbeit und reduziert Inkonsistenzen, die Prüfern sofort auffallen. Eine konsolidierte Belegmatrix verkürzt typische Audit-Tage um etwa zwanzig Prozent, weil Rückfragen seltener werden und Stichproben schneller zu beantworten sind. Audit-fest, dokumentiert, § 30-fest. Wer für VAIT, BAIT oder ZAIT prüft, kann dieselbe Belegmatrix nutzen und damit drei aufsichtsrechtliche Linien gleichzeitig bedienen, ohne Belege parallel zu pflegen oder Versionsstände abgleichen zu müssen.

Kerberoasting nutzt Service-Principal-Names, um verschlüsselte Tickets aus dem Active Directory anzufordern und offline gegen Wörterbücher zu brechen. Wird ein Service-Account mit schwachem Passwort identifiziert, kann ein Angreifer dessen Identität übernehmen. Golden-Ticket-Angriffe setzen die Kompromittierung des KRBTGT-Kontos voraus und erlauben das Ausstellen beliebiger Tickets ohne Domain-Controller-Beteiligung. Silver Tickets fälschen Service-Tickets gegen einzelne Dienste und umgehen das KDC vollständig. Alle drei Angriffsklassen sind seit Jahren öffentlich dokumentiert, in Open-Source-Tools wie Rubeus, Mimikatz und Impacket implementiert und gehören zum Standardrepertoire jedes Red-Team-Engagements.

Für die Compliance bedeutet das: Drei Risikoszenarien müssen explizit adressiert sein. Sie benötigen erstens ein dokumentiertes Service-Account-Härtungsprogramm mit Passwortlängen von mindestens 25 Zeichen und Group Managed Service Accounts, wo technisch möglich. Zweitens muss das KRBTGT-Passwort zweimal in definierten Abständen rotiert werden, üblich sind 180 Tage oder ad hoc nach Kompromittierungsverdacht. Drittens benötigen Sie ein Detection-Konzept, das ungewöhnliche Ticket-Anfragen, etwa massenhafte TGS-REQ-Pakete oder Tickets mit überlangen Gültigkeiten, sichtbar macht. Diese Erkennung muss im SIEM mit Regeln, Schwellwerten und Eskalationspfaden hinterlegt sein.

Diese Maßnahmen sind im CIVAC-Workspace als Kontrollziele mit Mess- und Reviewzyklen abgebildet. Der externe Informationssicherheitsbeauftragte dokumentiert Erkennungsregeln, Schwellwerte und Eskalationspfade im selben System, in dem auch der Vorfallmeldepfad NIS-2 verankert ist. Bestellurkunde, unterschrieben, abgelegt, belegbar. Das Risiko wird damit nicht nur technisch behandelt, sondern auch organisatorisch nachweisbar, sodass die Wirksamkeit einer Detection-Regel im Audit anhand realer Alerts und ihrer Bearbeitung belegt werden kann. Ergänzend empfiehlt sich eine jährliche Red-Team-Übung mit dem expliziten Ziel, Kerberoasting und Golden-Ticket-Szenarien zu testen, deren Ergebnisse wiederum in das Risikoregister einfließen und die Wirksamkeit der bestehenden Kontrollen belegen.

Ein typisches ISO-27001-Audit zur Kerberos-Härtung dauert zwischen vier und acht Stunden, abhängig von Domainstruktur und Tochtergesellschaften. Prüfer arbeiten dabei eine Checkliste ab, die in vier Bereiche gegliedert ist. Erstens Konfigurationsnachweise: aktuelle Group-Policy-Exporte zu Kerberos-Richtlinien, Encryption Types und Maximum Lifetimes. Zweitens Identitätsnachweise: Inventar der privilegierten Konten, Trennung von Tagesarbeitskonten und Admin-Konten, Service-Account-Liste mit Verantwortlichem. Drittens Betriebsbelege: Tickets aus dem Change Management, in denen KRBTGT-Rotation und Domain-Controller-Patches dokumentiert sind. Viertens Vorfallbelege: Beispiele aus dem SIEM, die zeigen, dass die Detection für Kerberoasting greift und in einer angemessenen Zeit bearbeitet wurde.

Wer ohne Vorbereitung in das Audit geht, liefert oft nur Screenshots ohne Zeitstempel. Das genügt nicht, weil ISO 27001:2022 unter A.5.36 Wirksamkeitsprüfungen über die Zeit verlangt. Die Belege müssen also einen vollständigen Quartals- oder Jahresrhythmus zeigen, idealerweise mit Verlinkung in das Risikoregister. Genau diese Verknüpfung leistet das CIVAC-Workspace-Modell, in dem 37 Audit-Vorlagen für Authentifizierung, Identitätsmanagement und Vorfallreaktion einsatzbereit bereitstehen. Jede Vorlage besitzt feste Felder für Verantwortlichen, Datum, Beleg, Folgemaßnahme und Reviewintervall.

Audit-fest, dokumentiert, ISO-fest. Das Ziel ist nicht die schöne Präsentation, sondern die nahtlose Rückverfolgbarkeit von Maßnahme über Beleg bis zum Verantwortlichen. Wenn Ihr Prüfer eine Stichprobe zieht, soll der nächste Klick reichen, nicht eine Suche durch verteilte Ordner und SharePoint-Strukturen. In der Praxis entscheidet diese Geschwindigkeit darüber, ob ein Audit-Tag entspannt verläuft oder mit Nachfragen, Stress und nachträglichen Belegsuchen endet. Die Disziplin liegt im täglichen Pflegen, nicht im Audit-Wochenende. Erfahrene Prüfer erkennen sofort, ob Belege im Tagesgeschäft entstehen oder ob sie nachträglich für die Auditvorbereitung produziert wurden, und gewichten ihre Stichproben entsprechend härter.

Wenn ein KRBTGT-Hash offengelegt wird oder ein Domain Controller kompromittiert ist, liegt nach § 32 NIS2UmsuCG ein erheblicher Sicherheitsvorfall vor. Frist läuft ab Kenntnis. Die Frühwarnung an das Bundesamt für Sicherheit in der Informationstechnik muss innerhalb von 24 Stunden erfolgen, die Folgemeldung mit erster Bewertung innerhalb von 72 Stunden, der Abschlussbericht nach spätestens einem Monat. Diese Fristen sind unabhängig davon, ob Sie selbst die Ursache schon identifiziert haben. Wer die 24-Stunden-Frist verpasst, riskiert Bußgelder bis 10 Mio. Euro oder 2 Prozent des Konzernumsatzes bei wesentlichen Einrichtungen.

Für Kerberos-Vorfälle hat das konkrete Folgen. Sie müssen vor dem Vorfall festgelegt haben, wer den Vorfall klassifiziert, wer das BSI-Meldeportal bedient und wer die operative Wiederherstellung führt. Eine Golden-Ticket-Lage erfordert in der Regel eine zweifache KRBTGT-Rotation in kurzem Abstand, eine domänenweite Sitzungsbeendigung und in vielen Fällen die Neuausstellung der Service-Account-Passwörter. Das ist eine Entscheidung mit hohem Wirkungsgrad und muss von einem benannten Verantwortlichen getroffen werden, nicht aus dem laufenden Tagesgeschäft heraus. Andernfalls drohen widersprüchliche Anweisungen.

Im CIVAC NIS-2-Meldepfad sind die Rollen, Templates und Eskalationsstufen vorkonfiguriert. Die 24h- und 72h-Meldefenster sind als Aufgaben mit Verantwortlichen hinterlegt, der Workspace verschickt automatisch Erinnerungen. Damit wird die Vorfallmeldung nicht zur Improvisation, sondern zur Routine. Ein Probelauf einmal pro Jahr deckt Lücken in der Erreichbarkeit der Verantwortlichen auf und prüft, ob der Meldetext fachlich tragfähig ist. Die Probe selbst wird wieder als Beleg im ISMS abgelegt und steht im Audit zur Verfügung. Wichtig ist die Abstimmung mit Konzernkommunikation und Rechtsabteilung, weil eine Meldung an das BSI auch Implikationen für die Pressearbeit und Vertragsbeziehungen mit Kunden hat.

Service-Accounts sind in vielen Umgebungen historisch gewachsen und schlecht dokumentiert. Genau diese Konten sind das Hauptziel von Kerberoasting. Eine prüffeste Bestandsaufnahme verlangt mindestens fünf Felder pro Konto: technischer Name, fachlicher Zweck, eingesetzter Dienst, Passwortlänge und Verantwortlicher. Group Managed Service Accounts sind, wo technisch möglich, gegenüber klassischen Service-Accounts vorzuziehen, weil sie automatisch rotieren und Passwörter mit 240 Zeichen erzeugen. Ein Inventar ohne Verantwortlichen ist im Audit wertlos, weil niemand die Pflege übernimmt und Findings über Jahre nicht abgearbeitet werden.

Privilegierte Konten gehören in ein Tier-Modell. Tier 0 sind Domain-Administratoren, Tier 1 sind Server-Administratoren, Tier 2 sind Workstation- oder Helpdesk-Konten. Die Anmeldung darf nur auf der jeweils zugewiesenen Tier-Ebene erfolgen, um lateral movement zu verhindern. Diese Trennung ist im Authentication-Policy- und Authentication-Silo-Mechanismus von Active Directory technisch umsetzbar und für ISO/IEC 27001:2022 Annex A.8.2 (Privilegierte Zugriffsrechte) prüfbar. Eine Tier-0-Anmeldung auf einer regulären Workstation ist im Auditfall ein klares Finding und sollte technisch unterbunden sein.

Die Dokumentation gehört in ein zentrales System, nicht in eine Excel-Tabelle, die niemand mehr pflegt. Im CIVAC-Workspace führen Sie das Konteninventar als lebendes Register mit Quartalsreviews. Der Compliance-Beauftragte und der Informationssicherheitsbeauftragte arbeiten dabei auf demselben Datenstand und können Findings unmittelbar als Maßnahme adressieren. Lizenzieren Sie den Workspace für Ihre internen Beauftragten oder lassen Sie unsere Beauftragten bestellen. Das Register dient zugleich als Grundlage für die Risikoanalyse, weil jeder Service-Account einem Schutzbedarf zugeordnet ist. Aus dieser Zuordnung lässt sich ableiten, welche Konten besondere Härtung benötigen, welche in das Privileged-Access-Management aufgenommen werden müssen und welche ohne erhöhten Aufwand ausreichend geschützt sind.

Kerberos-Compliance ist kein Inselthema. Die Erkenntnisse aus Authentifizierungs-Reviews speisen das Risikoregister, beeinflussen das Sicherheitskonzept und schlagen sich in der Statement of Applicability nieder. ISO/IEC 27001:2022 verlangt nach Klausel 6.1.2 eine systematische Risikobeurteilung, bei der Schwachstellen aus dem Authentifizierungsbereich auf Geschäftsprozesse abgebildet werden. Ein erfolgreicher Kerberoasting-Angriff auf einen Service-Account, der das ERP-System bedient, ist ein anderer Vorfall als ein Angriff auf einen Druckerdienst. Diese Unterscheidung muss im Risikomodell sichtbar sein.

Diese Mapping-Logik muss im ISMS explizit sein. Andernfalls fehlt die Begründung, warum bestimmte Kontrollen priorisiert sind. Im CIVAC-Workspace sind die 93 Controls der ISO/IEC 27001:2022 mit Risikobewertungen, Verantwortlichen und Maßnahmenstatus verbunden. Wenn ein Pen-Test eine schwache Service-Account-Konfiguration aufdeckt, lässt sich das Finding direkt einem Control, einem Risiko und einer Wiedervorlage zuordnen. Die Wiedervorlage erinnert automatisch an die Wirksamkeitsprüfung, sodass das Finding nicht ungeprüft verschwindet, sondern in einer geschlossenen Schleife behandelt wird.

Die Wirksamkeitsprüfung erfolgt dann nicht durch eine separate Aktivität, sondern durch das Vorlegen der Belege aus dem laufenden Betrieb. Damit wird das ISMS lebendig, statt nur ein Ordner zu sein, der einmal jährlich für das Audit aktualisiert wird. Bestellurkunde, unterschrieben, abgelegt, belegbar. So entsteht Compliance, die der Prüfer und der CISO gleichermaßen gerne lesen, weil sie nicht aus Powerpoint, sondern aus Belegen besteht. Die Geschäftsleitung sieht im Dashboard, welche Restrisiken aktiv getragen werden und welche Maßnahmen wirken. Diese Transparenz ist auch eine Voraussetzung für die Risikoakzeptanz nach ISO 27001, weil ohne dokumentierte Entscheidung kein Restrisiko durch das Management übernommen werden kann und das ISMS sonst unvollständig bleibt.

Aus der Praxis lassen sich fünf Findings benennen, die in Kerberos-Audits regelmäßig auftauchen. Erstens: aktivierte RC4-Verschlüsselung auf Service-Tickets ohne dokumentierte Begründung. Zweitens: KRBTGT-Passwortrotation, die seit mehreren Jahren nicht durchgeführt wurde. Drittens: fehlende Trennung zwischen Tagesarbeits- und Administrationskonten der IT. Viertens: Service-Accounts mit nur acht oder zwölf Zeichen Passwortlänge und ohne Rotationskonzept. Fünftens: keine Detection-Regel für ungewöhnliche TGS-REQ-Muster. In Audits stoßen wir auf alle fünf, oft in Kombination, was die Restrisikobewertung schnell in den hohen Bereich treibt.

Jedes dieser Findings ist vermeidbar, wenn die Härtung dokumentiert und das ISMS einen Reviewzyklus erzwingt. Der Aufwand zur Behebung ist überschaubar: Encryption Types lassen sich per Group Policy zentral steuern, eine zweifache KRBTGT-Rotation kostet einen halben Arbeitstag, Group Managed Service Accounts sind in Windows Server seit 2012 verfügbar, und Detection-Regeln gibt es als Public Templates für gängige SIEM-Systeme wie Microsoft Sentinel, Splunk oder Elastic. Ein zentraler Patchstand der Domain Controller und ein gehärtetes Monitoring auf Anmeldeereignisse runden das Bild ab.

Schwieriger ist die organisatorische Verankerung. Wer die Härtung einmal umsetzt und danach nicht überprüft, hat das Audit nur verschoben. Im CIVAC-Workspace sind Reviewzyklen mit Verantwortlichen und Erinnerungen hinterlegt, sodass die Härtung nicht ein einmaliges Projekt bleibt, sondern in den Linienbetrieb übergeht. Die FAQ-Sektion beantwortet weitere praktische Fragen zu Belegketten und Audit-Vorbereitung. Wichtig ist eine klare Übergabe zwischen IT-Betrieb und Informationssicherheit, damit Reviewergebnisse tatsächlich in das ISMS einfließen. Ein zweiwöchentliches Synchronisations-Meeting zwischen Domain-Admin, ISB und Compliance reicht in den meisten Organisationen aus, um Findings frühzeitig zu erfassen und Auditüberraschungen zu vermeiden.

CIVAC bringt zwei Wege zusammen, mit denen Sie Kerberos-Compliance umsetzen. Lizenzieren Sie den Workspace für Ihre internen Beauftragten oder lassen Sie unsere Beauftragten bestellen. Im Workspace-Modell arbeiten Ihr Informationssicherheitsbeauftragter, Ihr Compliance-Beauftragter und gegebenenfalls Ihr Datenschutzbeauftragter auf einer gemeinsamen Datenbasis. Die 37 Audit-Vorlagen, 93 ISO-Controls und die NIS-2-Meldepfade sind vorkonfiguriert und mit Ihren Domain-Controllern, Service-Accounts und Anwendungen verknüpft. Die EU-Datenresidenz ist standardmäßig aktiviert, sämtliche Beleg-Uploads verbleiben in Deutschland.

Im Officer-as-a-Service-Modell stellt CIVAC Ihnen einen externen Informationssicherheitsbeauftragten zur Seite, der die Kerberos-Härtung prüft, die Bestellurkunde unterzeichnet und im Audit als Ansprechpartner zur Verfügung steht. Die CIVAC-SLA für die Bestellung beträgt zwei Werktage, statt der branchenüblichen zwei bis sechs Wochen. Die Beauftragten arbeiten remote aus EU-Datenresidenz und sprechen die Sprache Ihrer IT, was die Übergabe von Pen-Test-Ergebnissen und SIEM-Auswertungen deutlich beschleunigt. Eine quartalsweise Berichtslinie an die Geschäftsleitung ist Bestandteil des Modells, ergänzt um anlassbezogene Sondermeldungen bei kritischen Findings oder Vorfällen, sodass die Aufsichtsorgane stets einen aktuellen Stand kennen.

Aus dem Lesen einen Auftrag machen. Wenn Sie die Kerberos-Compliance Ihres Active Directory belastbar nachweisen wollen oder einen externen Beauftragten zur Übernahme der Rolle suchen, schreiben Sie an info@civac.de oder nutzen Sie das Kontaktformular auf civac.de. Eine kurze Vorabklärung umfasst typischerweise Domain-Anzahl, Anzahl der Service-Accounts und gewünschte Auditierungstiefe, sodass der Workspace nach Bestellung innerhalb weniger Tage einsatzfähig ist. Wir melden uns innerhalb eines Werktags mit einem konkreten Vorschlag inklusive Termin für ein Onboarding-Gespräch. Bestellurkunde, unterschrieben, abgelegt, belegbar. So wird aus einem regulatorischen Druckpunkt eine geordnete, auditfähige Routine, die Sie Ihrer Geschäftsleitung und Ihren Prüfern transparent zeigen können.