Die Active Directory Zertifikatsdienste gibt es mit dem Namen seit Windows Server 2008, vorher hieß es nur Stammzertifizierungsstelle (engl. Certificate Authority). Sie dient der Erstellung einer eigenen Public Key Infrastructure (kurz PKI). Sowas kann dann für Zertifikatsbasierte Anmeldung an Systemen, einem Netzwerkrichtlinienserver mit 802.1X oder der Absicherung von internen Webservern mit (SSL) TLS Zertifikaten für https genutzt werden. Die Einsatzmöglichkeiten sind vielfältig, diese Beispiele sollen nur verdeutlichen für welche Szenarien man eine CA in der eigenen Infrastruktur einsetzen kann.
Dies soll keine Installationsanleitung für die ADCS sein, sondern das grundlegende Konzept einer CA Struktur und die Vor- aber auch Nachteile eines solchen Dienstes aufzeigen.
Die Root CA oder auch Stammzertifizierungsstelle ist die höchste Instanz in der Vertrauenskette. Sie stellt z.B. Zertifikate für Webserver aus, mit denen der Webserver gegenüber Dritten seine Identität und Authentizität nachweisen kann, wenn der Root CA vertraut wird. Genau dieses Verhalten sehen wir in unserem täglichen Surfen im Internet, wenn das grüne Schloss neben der URL angezeigt wird.
Die Browser haben eine Liste mit über 100 grundsätzlich vertrauenswürdigen CAs implementiert. Dadurch muss nicht jeder seine eigene CA haben und diese allen bekannt machen, sondern kann auch auf Drittanbieter Zertifikate zurückgreifen, um seine Website mit HTTPS betreiben zu können. Eine Root CA sollte aufgrund der Kritikalität sehr gut abgesichert und im besten Fall offline sein, um eine Kompromittierung zu verhindern.
Eine Sub CA ist eine Untergeordnete Zertifizierungsstelle, die meistens dazu genutzt wird, Zertifikate zu bestätigen oder auszustellen. Sub CAs können also als eine Art Loadbalancer eingesetzt werden. Sie können auch für unterschiedliche Aufgaben genutzt werden, zum Beispiel für die Trennung von TLS und S/MIME oder für unterschiedliche Standorte. Sub CAs können auch weitere Sub CAs unter sich haben und die jeweils übergeordnete Stelle signiert die Zertifikate der untergeordneten Stelle, somit ist eine Chain of Trust, also eine Kette des Vertrauens geschaffen. Dies hat den Vorteil, dass im Fall einer Kompromittierung, nicht alle Zertifikate für ungültig erklärt werden müssen, sondern nur die, die von der kompromittierten Sub CA ausgestellt wurden. Die root CA wird also nur genutzt, um neue Sub CAs und die Zertifikatssperrliste (engl. Certificate Revocation List, CRL) zu signieren.
Hier ein Bild der Zertifikatskette einer Website.
Der ADCS lässt sich sehr gut in eine bestehende Domäne integrieren, sollte aber sehr gut gesichert sein oder offline und als Tier 0 Asset angesehen werden. In einem zwei oder mehr stufigem hierarchischem Konzept ist aus administrativer Sicht die gesamte Public Key Infrastructure ein Tier 0 Asset, es gibt wenige Ausnahmen wie z.B. die Zertifikatssperrliste, welche in das Tier 1 eingeordnet wird. Die Zertifikate zum Beispiel für 802.1X, um Zugriff auf das Netzwerk zu erhalten, können mit Hilfe von Gruppenrichtlinien automatisch verteilt und erneuert werden. Damit können dann Endgeräte die domänenintegriert sind, mit Hilfe des Netzwerkrichtlinienservers (kurz NPS) vollautomatisch in das richtige VLAN geschoben werden, was die Netztrennung sehr positiv beeinflusst und vereinfachen kann.
Da gerade in der heutigen Zeit die Serveradministration durch viele Wizzards vereinfacht werden soll, lässt sich der ADCS sehr schnell installieren. Das Problem daran ist, dass man sich auch sehr einfach viele neue Lücken und Angriffsvektoren in das Netz holen kann, wenn man nicht aufpasst und die Absicherung der CA und der PKI vernachlässigt. Ein sehr schönes Beispiel ist die Verbindung des PetitPotam Exploits mit einer Relay Attacke gegen die CA und der daraus resultierenden vollständigen Kompromittierung der gesamten Domäne.
Durch eine eigene Zertifizierungsstelle oder Public Key Infrastructure kann ich meine lokalen Dienste wie Web Applikationen mit Zertifikaten versorgen, denen innerhalb der eigenen Struktur vertraut wird. Dies erschwert es Angreifern z.B. einen Man in the Middle Angriff erfolgreich durchzuführen, da die Verschlüsselung aufgebrochen und die Zertifikate ausgetauscht werden müssten. Mit eigenen Zertifikaten kann man aber auch die Network Access Control (NAC) via 802.1X aufwerten und Benutzername und Passwort gegen Zertifikate zu tauschen. Wichtig ist aber die Absicherung des Tier 0 Assets, welches eine CA darstellt. Denn darüber kann ein Angreifer sich privilegieren und auch eine Persistenz im Netzwerk schaffen. Auch wenn die Implementierung von ADCS die Sicherheit erhöhen kann ist ein administrativer Aufwand notwendig um diese sicher einzurichten und kontinuierlich zu managen.
Wir verwenden Cookies, und Google reCAPTCHA, das Google Fonts lädt und mit Google-Servern kommuniziert. Durch die weitere Nutzung unserer Website stimmen Sie der Verwendung von Cookies und unserer Datenschutzerklärung zu.