ADCS-Härtung nach BSI IT-Grundschutz

Kurzfassung vorab: BSI IT-Grundschutz klingt nach 800 Seiten Bürokratie, ist für ADCS aber überraschend handlich: Der Kernbaustein APP.7 plus eine ordentliche Server-Grundhärtung deckt 80 Prozent ab. Wer die ESC-Pfade geschlossen, die Rollen getrennt und die Auditierung scharfgeschaltet hat, besteht den Grundschutz-Check fast nebenbei. Dieser Artikel übersetzt die abstrakten Bausteine in eine konkrete, abarbeitbare Reihenfolge — ohne Compliance-Geschwurbel, dafür mit PowerShell und einer ehrlichen Priorisierung.

Abb. 1: BSI-Härtung von ADCS in fünf aufeinander aufbauenden Ebenen — von der Architektur bis zur laufenden Kontrolle, flankiert von durchgängiger Dokumentation.

1. Warum BSI-Härtung mehr ist als ein Häkchen

Fangen wir mit einer Ehrlichkeit an, die im Compliance-Umfeld selten ausgesprochen wird: Ein BSI-konformes ADCS ist nicht automatisch ein sicheres ADCS, und ein sicheres ADCS ist nicht automatisch BSI-konform. Der Grundschutz ist ein strukturierter Rahmen, der sicherstellt, dass du nichts Wichtiges vergisst — er ist kein Garant gegen einen findigen Angreifer. Wer die Bausteine nur abhakt, ohne zu verstehen, was dahintersteckt, baut sich eine teure Scheinsicherheit.

Trotzdem lohnt sich der Aufwand, und zwar aus zwei Gründen. Erstens zwingt dich der Grundschutz, systematisch vorzugehen statt punktuell — und PKI-Sicherheit ist ein Kettenproblem, bei dem das schwächste Glied zählt. Zweitens ist BSI-Konformität in vielen Ausschreibungen, bei NIS2-Betroffenheit und im KRITIS-Umfeld schlicht Pflicht. Die gute Nachricht: Wenn du die Härtung sauber machst, fällt die Konformität als Nebenprodukt ab.

2. Die relevanten BSI-Bausteine — nur die, die zählen

Der IT-Grundschutz kennt über hundert Bausteine. Für ADCS sind eine Handvoll davon relevant, und nur einer ist wirklich der Kern. Hier die ehrliche Landkarte, damit du nicht wochenlang im Kompendium blätterst:

Abb. 2: Die relevanten BSI-Bausteine für ADCS — APP.7 als Kern, flankiert von Server- und AD-Bausteinen.

Der zentrale Baustein ist APP.7 (Entwicklung und Betrieb von Kryptokonzepten) beziehungsweise dessen PKI-Anteile. Er beschreibt die Anforderungen an eine Zertifizierungsinstanz: Schlüsselschutz, Vertrauensanker, Sperrmechanismen, Rollentrennung. Darunter liegt das Fundament aus SYS.1.1 (Allgemeiner Server) und SYS.1.2.3 (Windows Server) — denn eine CA ist immer auch ein Server, der grundgehärtet sein muss. Wer den OS-Unterbau vernachlässigt, hat eine Hochsicherheits-CA auf einem Schweizer Käse.

Flankierend kommen APP.2.1/2.2 (Active Directory und Domänencontroller) ins Spiel, weil die Issuing CA im Tier-0-Umfeld lebt und ihre Sicherheit untrennbar mit der des AD verbunden ist. CON.1 (Kryptokonzept) regelt Algorithmen, Schlüssellängen und Laufzeiten. Und OPS.1.1.5 (Protokollierung) schließlich verlangt eine zentrale, auswertbare Protokollierung — die Brücke zum Audit-Logging.

3. Ebene 1 und 2 — Architektur, Isolation und Schlüsselschutz

Die unteren beiden Ebenen entscheiden über alles Weitere. Eine einstufige CA ohne Offline Root lässt sich nicht BSI-konform härten, Punkt — der Grundschutz verlangt eine geschützte Vertrauenswurzel. Die zweistufige Hierarchie mit Offline Root und Issuing CA ist das Minimum, das du brauchst, und gleichzeitig der Mittelstands-Standard.

Beim Schlüsselschutz wird es konkret: Für die Root CA verlangt der Grundschutz im höheren Schutzbedarf ein HSM. Für die Issuing CA hängt es vom Schutzbedarf ab, aber ein YubiHSM 2 im niedrigen vierstelligen Bereich macht das Audit-Häkchen setzbar. Die Schlüsselerzeugung gehört in eine dokumentierte Key-Ceremony mit Vier-Augen-Prinzip — das klingt nach Zeremoniell, ist aber im Audit Gold wert, weil es belegt, dass kein Einzelner je allein Zugriff auf den Root-Schlüssel hatte.

4. Ebene 3 — Konfigurationshärtung in der Praxis

Hier sitzt die meiste Arbeit, und hier überschneidet sich der Grundschutz am stärksten mit der ESC-Härtung. Die wichtigsten Stellschrauben prüfst und setzt du mit certutil und PowerShell. Fangen wir mit der Bestandsaufnahme der CA-Konfiguration an:

Die Konfigurationshärtung folgt einer klaren Reihenfolge, die ich in jedem Redesign so durchziehe. Erst die sofort ausnutzbaren Lücken, dann die strukturellen Themen:

5. Ebene 4 und 5 — Betrieb, Rollen und Monitoring

Die oberen Ebenen werden im Alltag am häufigsten vernachlässigt, weil sie keine einmalige Konfiguration sind, sondern gelebte Prozesse verlangen. Der Grundschutz fordert eine saubere Rollentrennung: Wer die CA verwaltet (ManageCA), wer Zertifikate freigibt (ManageCertificates) und wer das Betriebssystem administriert, sollten nicht dieselbe Person sein — und schon gar nicht dasselbe Konto. Im Ein-Mann-Betrieb ist das schwierig, aber zumindest getrennte administrative Konten mit dokumentierter Aufgabenteilung sind machbar.

Ebene 5 — Monitoring und Audit — ist der Punkt, an dem viele Härtungsprojekte einschlafen. Die Auditierung ist scharfgeschaltet, aber niemand schaut hinein. Das ist, als würdest du eine Alarmanlage installieren und den Lautsprecher abklemmen. Mindestens die kritischen Konfigurationsänderungen (Event-IDs 4890, 4892, 4899) gehören in eine automatische Alarmierung. Wie das im Detail aufgesetzt wird, behandelt der Audit-Logging-Spoke.

Abb. 3: Härtungs-Roadmap in vier Phasen — die sofort ausnutzbaren Lücken zuerst, dann die strukturelle Härtung und die Verstetigung.

6. Praxis-Beispiel — die Sparfuchs & Partner Steuerberatungs GmbH

Die Sparfuchs & Partner Steuerberatungs GmbH ist ein kleiner Dienstleister mit unter 100 Mitarbeitern — schmales Budget, aber als Steuerberatung mit hohen Compliance-Anforderungen konfrontiert. Der Auslöser war eine Mandanten-Anforderung: Ein großer Mandant verlangte für die Zusammenarbeit den Nachweis einer grundschutzkonformen IT, inklusive der internen PKI, die für die Verschlüsselung der Mandantenkommunikation genutzt wurde.

Die Ausgangslage war typisch für die Größe: eine einstufige CA, direkt auf einem Domain Controller installiert (ein klassischer Grundschutz-Verstoß, weil keine Tier-Trennung), Auditierung aus, keine Dokumentation. Ein vollwertiges HSM sprengte das Budget. Die Lösung war ein pragmatischer Mittelweg: Wir haben die CA auf eine zweistufige Hierarchie umgebaut, die Offline Root als verschlüsselte, normalerweise heruntergefahrene VM realisiert und für die Issuing CA ein YubiHSM 2 für rund 700 Euro beschafft — genug für das Audit-Häkchen, verträglich fürs Budget.

Die Auditierung wurde scharfgeschaltet, die Vorlagen bereinigt (zwei ESC1-Kandidaten gefunden und entschärft), und die gesamte Härtung in einem zwölfseitigen PKI-Konzept dokumentiert, das sich am APP.7-Baustein entlanghangelt. Der Mandanten-Nachweis war damit erbracht, und Sparfuchs hat als Nebeneffekt eine PKI bekommen, die tatsächlich sicher ist — nicht nur auf dem Papier. Gesamtaufwand: rund sechs Beratungstage über zwei Monate verteilt.

Verwandte Themen

Pillar-Seite: Active Directory Certificate Services – der komplette Leitfaden

Häufige Fragen (FAQ)

Welcher BSI-Baustein ist für ADCS relevant?

Der Kernbaustein ist APP.7 zu Kryptokonzepten und PKI. Darunter liegen die Server-Bausteine SYS.1.1 und SYS.1.2.3 für die Grundhärtung des CA-Servers sowie APP.2.1/2.2 für das Active-Directory-Umfeld. Flankierend regeln CON.1 das Kryptokonzept und OPS.1.1.5 die Protokollierung. In der Praxis deckt APP.7 plus eine ordentliche Server-Grundhärtung den Großteil ab.

Brauche ich für BSI-Konformität zwingend ein HSM?

Für die Root CA im erhöhten Schutzbedarf ja, für die Issuing CA hängt es vom Schutzbedarf ab. Im normalen Schutzbedarf ist ein Software-CSP mit verschlüsselter, isolierter VM vertretbar. Wichtig ist die Entscheidung vor der Schlüsselerzeugung — ein nachträglicher Umzug eines nicht-exportierbaren Schlüssels ins HSM ist nicht möglich und erzwingt eine Neuausstellung.

Reicht eine einstufige CA für den Grundschutz?

Nein. Der Grundschutz verlangt eine geschützte Vertrauenswurzel, und die lässt sich einstufig nicht sauber abbilden. Die zweistufige Hierarchie mit Offline Root und Issuing CA ist das Minimum — sie ist gleichzeitig der Mittelstands-Standard und der Aufwand gegenüber einstufig ist gering.

Wie aktiviere ich die CA-Auditierung?

Mit „certutil -setreg CA\AuditFilter 127" aktivierst du alle sieben Auditkategorien, anschließend muss der CA-Dienst neu gestartet werden. Zusätzlich muss die Objektzugriffs-Überwachung im Betriebssystem per auditpol für die Subkategorie „Certification Services" aktiviert sein, sonst landen die Ereignisse nicht im Security-Log. Beides zusammen ist die Voraussetzung für OPS.1.1.5.

Macht BSI-Härtung meine PKI automatisch sicher?

Nein — und diese Ehrlichkeit gehört dazu. Der Grundschutz ist ein strukturierter Rahmen, der sicherstellt, dass du nichts Wichtiges vergisst, kein Garant gegen einen findigen Angreifer. Wer die Bausteine nur abhakt, ohne sie zu verstehen, baut Scheinsicherheit. Wer die Härtung dagegen technisch sauber macht, bekommt die Konformität als Nebenprodukt.

Wie oft muss ich die Härtung überprüfen?

Mindestens halbjährlich, besser quartalsweise in größeren Umgebungen. Eine PKI driftet im Alltag, weil Admins neue Vorlagen anlegen oder Berechtigungen anpassen. Ein fester Review-Zyklus mit wiederholtem Scan, Vorlagenprüfung und Stichprobe im Audit-Log hält die Härtung lebendig — ohne ihn ist sie nach zwei Jahren wieder Geschichte.

Nächste Schritte mit boddenberg.de

BSI-Härtung ist selten ein Wochenend-Projekt — sie ist ein strukturierter Weg von der Bestandsaufnahme zur dokumentierten, nachprüfbaren Zielarchitektur. Drei Wege, das anzugehen:

Kontakt: Uli Boddenberg · boddenberg.de · Dortmund