ADCS-Architekturen im Vergleich
Welche PKI-Hierarchie für welche Organisation passt – und warum die falsche Wahl teuer wird.ADCS-Architekturen im Vergleich – ein-, zwei- und dreistufig
Die ehrliche Empfehlung vorweg: Für den Mittelstand ist zweistufig fast immer richtig – eine Offline Root plus eine oder mehrere Issuing CAs. Einstufig ist die Express-Variante fürs Labor und für „wir sind ja nur klein“-Argumente, die sich nach drei Jahren rächen. Dreistufig (Root, Policy CA, Issuing CA) lohnt sich erst für Konzerne, regulierte Branchen oder mehrere getrennte Vertrauensdomänen. Wer einstufig startet, um Aufwand zu sparen, baut erfahrungsgemäß bald neu auf – meist unfreiwillig nach einem Audit.
Abb. 1: Die drei Hierarchien nebeneinander – mit Risiko bei Kompromittierung und Aufwand pro Variante.
1. Einstufig: schnell, aber fragil
Eine einstufige PKI besteht nur aus einer einzigen Issuing CA, die gleichzeitig Vertrauensanker und ausstellende Stelle ist. Sie ist in einer Stunde aufgesetzt – und genau das ist ihr Problem. Es gibt keine getrennte Vertrauensinstanz, die geschützt im Schrank steht.
Der Knackpunkt ist das Kompromittierungsszenario: Wird diese eine CA übernommen, gibt es keinen Rückzugspunkt. Du kannst nicht „nur die Issuing CA neu ausstellen lassen“, weil sie selbst der Root ist. Die Rettung heißt kompletter Neuaufbau der gesamten PKI – mit allem, was daran hängt: neue Vertrauenskette, neue Zertifikate, neue Verteilung.
Einstufig ist deshalb vertretbar für Testumgebungen, Labore und kurzlebige Projekte. Für eine produktive Umgebung, die Authentifizierung trägt, ist sie ein kalkuliertes Risiko, das sich selten auszahlt.
|
Warnung · Das „Wir sind ja nur klein“-Argument Der Klassiker: Eine kleine Firma startet einstufig, weil die zweite VM „zu viel Aufwand“ sei. Drei Jahre später kommt der erste Sicherheits-Audit – und die Empfehlung lautet: zweistufig neu bauen. Die Mehrkosten für die Offline Root von Anfang an sind im Verhältnis zur späteren Migration lächerlich. Einstufig spart heute einen halben Tag und kostet morgen ein Projekt. |
|---|
2. Zweistufig: der Mittelstands-Standard
Die zweistufige Architektur trennt die Rollen sauber: Eine Offline Root CA ist der Vertrauensanker und signiert ausschließlich die untergeordneten Issuing CAs. Die Issuing CA macht die eigentliche Arbeit – sie stellt im Tagesbetrieb Zertifikate aus. Die Root wird nach getaner Arbeit heruntergefahren und nur für CRL-Erneuerung oder neue Sub-CAs kurz reaktiviert.
Der Sicherheitsgewinn ist erheblich: Wird die Issuing CA kompromittiert, widerrufst du sie über die Root, baust eine neue Issuing CA und lässt sie von der weiterhin sauberen Root signieren. Die Vertrauenskette bleibt intakt, der Schaden ist begrenzt. Das ist der entscheidende Unterschied zur einstufigen Variante.
Diese Variante ist in den allermeisten Mittelstandsprojekten genau richtig – ausreichend robust, ohne overengineered zu sein. Wie sie konkret aufgesetzt wird, zeigt Spoke
„Aufbau einer ADCS-Umgebung von Grund auf“. Die Offline Root im Detail behandelt Spoke „Offline Root CA korrekt aufsetzen“.
|
Praxis-Tipp · Mehrere Issuing CAs unter einer Root Zweistufig heißt nicht „genau zwei CAs“. Unter einer Offline Root können mehrere Issuing CAs hängen – z. B. eine für Computer- und Nutzerzertifikate, eine separate für Codesigning oder Smartcards. Das ist immer noch zweistufig, gibt dir aber saubere Trennung nach Verwendungszweck, ohne die volle Komplexität einer dreistufigen Hierarchie. In der Praxis der häufigste Ausbauschritt. |
|---|
3. Dreistufig: maximal, aber aufwendig
Die dreistufige Architektur schiebt zwischen Root und Issuing CA eine
Policy CA ein. Sie definiert und erzwingt Richtlinien (Certificate Policies) und trennt unterschiedliche Vertrauensdomänen sauber – etwa interne Zertifikate gegenüber Partner- oder Tochtergesellschafts-Zertifikaten. Die Root signiert die Policy CAs, die Policy CAs signieren die Issuing CAs, diese stellen aus.
Der Preis dafür ist Komplexität: mehr CAs, mehr Schlüssel, mehr Veröffentlichungspunkte, mehr Betrieb. Diese Investition lohnt sich, wenn du regulatorisch getrennte Vertrauensräume nachweisen musst, mehrere weitgehend autonome Geschäftsbereiche hast oder als Konzern eine formale Policy-Trennung brauchst. Für einen typischen Mittelständler ist sie meist deutlich zu viel.
|
Kriterium |
Einstufig |
Zweistufig |
Dreistufig |
|---|---|---|---|
|
Anzahl CAs |
1 |
2+ |
3+ |
|
Aufbauaufwand |
niedrig |
mittel |
hoch |
|
Risiko bei Kompromittierung |
hoch |
mittel |
gering |
|
Policy-Trennung |
keine |
begrenzt |
voll |
|
Audit-Tauglichkeit |
schwach |
gut |
sehr gut |
|
Typischer Einsatz |
Lab/Test |
Mittelstand |
Konzern/reguliert |
4. Die Entscheidung positionieren
Am Ende ist es eine Abwägung zwischen Aufwand und Schutzniveau. Die folgende Positionierung hilft, die eigene Situation einzuordnen, statt aus dem Bauch heraus zu entscheiden.
Abb. 2: Aufwand gegen Schutzniveau – zweistufig markiert den Sweet Spot für die meisten Organisationen.
Die Faustregeln dazu:
|
Info · Hierarchie ist nicht Hochverfügbarkeit Ein häufiges Missverständnis: Mehr Stufen bedeuten nicht automatisch mehr Verfügbarkeit. Die Anzahl der Hierarchiestufen regelt Vertrauen und Policy-Trennung, nicht Ausfallsicherheit. Hochverfügbarkeit erreichst du über redundante Issuing CAs und eine robuste CRL/OCSP-Veröffentlichung – unabhängig von der Stufenzahl. Wie das geht, zeigt Spoke „OCSP-Responder und CRL-Hochverfügbarkeit“. |
|---|
5. Drei typische Fehlentscheidungen bei der Architekturwahl
Aus der Beratungspraxis wiederholen sich dieselben Muster. Wer sie kennt, vermeidet die teuersten Umwege.
Fehler 1: Einstufig „zum Ausprobieren“, das dann produktiv bleibt
Was als Testumgebung gedacht war, wächst klammheimlich in den Produktivbetrieb hinein. Plötzlich hängen WLAN-Authentifizierung und VPN an einer CA, die nie für Produktion gedacht war. Die Lehre: Sobald eine CA produktive Zertifikate ausstellt, ist sie produktiv – egal, wie sie mal gestartet ist. Trenne Test und Produktion von Anfang an.
Fehler 2: Dreistufig aus Prinzip, ohne echten Bedarf
Das Gegenteil kommt auch vor: Eine dreistufige Hierarchie wird gebaut, weil „mehr Stufen = sicherer“ klingt. Ohne getrennte Vertrauensdomänen oder regulatorische Pflicht bringt die Policy CA aber nur Komplexität: zusätzlicher Schlüssel, zusätzlicher Veröffentlichungspunkt, zusätzlicher Betriebsaufwand. Sicherheit entsteht durch saubere Umsetzung, nicht durch Stufenzahl.
Fehler 3: Die Root nicht wirklich offline halten
Eine zweistufige Architektur auf dem Papier, deren Root aber dauerhaft läuft, in der Domäne hängt und am Netz ist, hat den Sicherheitsvorteil verspielt. Die Trennung ist nur dann wirksam, wenn die Root tatsächlich offline und normalerweise heruntergefahren ist. Sonst hast du den Aufwand zweier CAs ohne den Schutz.
6. Praxis-Beispiel: Musterwerk GmbH
Die Musterwerk GmbH, ein Industrie-Mittelständler mit rund 1.500 Mitarbeitern an drei Standorten, kam mit einer einstufigen CA – schnell installiert, nie hinterfragt. Bei der ersten Sicherheitsbegutachtung fiel genau das auf: kein geschützter Vertrauensanker, kein Rückzugspunkt bei Kompromittierung.
Die Entscheidung gegen dreistufig fiel bewusst. Es gab keine getrennten Vertrauensdomänen, keine regulatorische Pflicht zur formalen Policy-Trennung – eine Policy-Stufe hätte nur Komplexität ohne Mehrwert gebracht. Stattdessen kam eine zweistufige Architektur mit einer Offline Root und zwei Issuing CAs: eine für Computer- und Nutzerzertifikate, eine separate für die Codesigning-Anforderungen der Fertigungssoftware. Robust, audit-tauglich und trotzdem überschaubar im Betrieb.
Verwandte Themen
Häufige Fragen (FAQ)
Welche Architektur ist für den Mittelstand richtig?
In den allermeisten Fällen zweistufig: eine Offline Root plus eine oder mehrere Issuing CAs. Sie bietet einen geschützten Vertrauensanker und einen Rückzugspunkt bei Kompromittierung, ohne die Komplexität einer dreistufigen Hierarchie. Einstufig ist nur für Labor- und Testumgebungen vertretbar.
Warum ist einstufig so problematisch?
Weil es keinen getrennten Vertrauensanker gibt. Wird die einzige CA kompromittiert, hilft kein Widerruf – sie ist selbst die Root. Die einzige Rettung ist der komplette Neuaufbau der gesamten PKI. Das macht einstufig für produktive Umgebungen zu einem schwer kalkulierbaren Risiko.
Wann lohnt sich eine dreistufige Architektur?
Wenn du regulatorisch getrennte Vertrauensdomänen nachweisen musst, mehrere weitgehend autonome Geschäftsbereiche hast oder als Konzern eine formale Policy-Trennung über eine Policy CA brauchst. Für einen typischen Mittelständler ist sie meist zu aufwendig und bringt keinen echten Mehrwert.
Was macht die Policy CA in der dreistufigen Variante?
Sie definiert und erzwingt Richtlinien und trennt unterschiedliche Vertrauensdomänen – etwa intern gegenüber Partner-Zertifikaten. Die Root signiert die Policy CAs, diese signieren die Issuing CAs. Damit lassen sich verschiedene Policy-Bereiche sauber voneinander abgrenzen.
Kann ich später von einstufig auf zweistufig wechseln?
Ja, aber es ist eine echte Migration mit Aufwand: neue Root, neue Vertrauenskette, Übernahme oder Neuausstellung der Zertifikate. Deshalb lautet die Empfehlung, gleich zweistufig zu starten – die Mehrkosten zu Beginn sind geringer als die spätere Umstellung.
Bedeuten mehr Stufen automatisch mehr Ausfallsicherheit?
Nein. Die Stufenzahl regelt Vertrauen und Policy-Trennung, nicht Verfügbarkeit. Hochverfügbarkeit erreichst du über redundante Issuing CAs und eine robuste CRL/OCSP-Veröffentlichung – unabhängig davon, ob die Hierarchie zwei oder drei Stufen hat.
Nächste Schritte mit boddenberg.de
Die Wahl der Architektur ist eine Weichenstellung für Jahre. Wenn du unsicher bist, ob deine bestehende Hierarchie noch passt oder ob ein Redesign sinnvoll ist, lohnt sich eine fokussierte Bestandsaufnahme.
Kontakt: Uli Boddenberg · boddenberg.de · Dortmund