Die Zertifikatsdienste des Windows Server 2008, mit vollständiger Bezeichnung als Active Directory Certificate Services oder auch AD CS bezeichnet, sind eine der eher ungeliebten Kernkomponenten für die Sicherheit. Sie sind eine Kernkomponente, weil immer mehr Sicherheitsfunktionen auf digitalen Zertifikaten basieren. Ungeliebt sind sie dagegen, weil Zertifikatsdienste generell sehr planungsaufwändig und komplex sind. Noch komplexer wird die Herausforderung im heterogenen Umfeld, wenn verschiedene System-Plattformen bedient werden müssen, weil es dann häufig auch um die Frage des Miteinanders unterschiedlicher Zertifikatsdienste und die Integration mit externen Diensten geht.
Bei der neuen Version der Zertifikatsdienste gibt es mehrere wichtige Neuerungen. Eine ist die automatische Bereitstellung (Enrollment) von Zertifikaten auch für Arbeitsstationen und andere Geräte im Netzwerk, die im Kontext von Standards wie IEEE 802.1X für die Authentifizierung von Clients in Netzwerken immer wichtiger wird. Dieser NDES (Network Device Enrollment Service) unterstützt das SCEP (Simple Certificate Enrollment Protocol), das von Cisco definiert wurde. Eine weitere ist die Unterstützung von OCSP (Online Certificate Status Protocol) für eine aktuellere und effizientere Beantwortung von Anfragen zum Status von Zertifikaten. Weitere Neuerungen sind die Cluster-Unterstützung und neue, stärkere Verschlüsselungsfunktionen, die unterstützt werden.
Die Auswahl der Server-Edition
Bei den Zertifikatsdiensten ist zu beachten, dass die meisten Funktionen und Komponenten nur bei der Enterprise- und der Datacenter-Edition des Windows Server 2008 enthalten sind. Bei der Web-Edition werden die Zertifikatsdienste nicht unterstützt. Bei der Standard-Edition wird nur die Basisfunktionalität der CA unterstützt. Die neuen Funktionen wie NDES oder OCSP sind dagegen dort nicht zu finden. Das gilt auch für folgende speziellere Features:
-
Zertifikate der Version 2 (Windows Server 2003) und Version 3 (Windows Server 2008) werden nicht unterstützt. Diese Zertifikate bieten eine größere Anpassbarkeit und zusätzliche Funktionen. Die Standard-Edition unterstützt nur Basis-Zertifikate, mit denen sich nur die wichtigsten Anforderungen in reinen Windows-Infrastrukturen abdecken lassen.
-
Die Archivierung von Schlüsseln wird ebenfalls nicht unterstützt.
-
Es gibt kein dediziertes Rollenkonzept, über das sich Aufgaben innerhalb des Zertifikatsmanagements unterschiedlichen Benutzergruppen zuordnen lassen. Das ist für größere Umgebungen zwingend und aus Sicherheitsgründen generell empfehlenswert.
-
Die Delegation des Enrollment Agents ist bei den Enterprise- und Datacenter-Versionen sehr viel flexibler, so dass genau gesteuert werden kann, welcher Benutzer welche Aufgaben innerhalb einer komplexeren Infrastruktur übernehmen darf.
Indirekt kommen weitere Einschränkungen beispielsweise bezüglich der Cluster-Unterstützung, die es ebenfalls erst bei der Enterprise Edition gibt, zum Tragen. Daher ist es empfehlenswert, die Enterprise-Edition des Windows Server 2008 als Basis für eine unternehmensweite Zertifikatsinfrastruktur auf Basis des Active Directory zu wählen.
Installation: Die Rollendienste
Bei der Installation der Zertifikatsdienste, die als zusätzliche Serverrolle eingerichtet werden, gibt es vier Dienste, die ausgewählt werden können:
-
Die Zertifizierungsstelle als Kernfunktion, über die Zertifikate ausgestellt und verteilt werden können.
-
Die Webregistrierung, über die ein Web-Frontend als IIS-Anwendung bereitgestellt wird, über das Benutzer Zertifikate anfordern und abholen können.
-
Die Unterstützung für das Online Certificate Status Protocol (OCSP), die ebenfalls die IIS voraussetzt.
-
Die NDES, hier auch als MSCEP (Microsoft Simple Certificate Enrollment Protocol) bezeichnet.
Spezielle Anforderungen für die Rollendienste
Wenn die Webregistrierung ausgewählt wird, wird ein zusätzliches Dialogfeld angezeigt, in dem auf die erforderlichen zusätzlichen Rollendienste und Funktionen hingewiesen wird, die eingerichtet werden müssen. Das sind einerseits die IIS und andererseits der Windows-Prozessaktivierungsdienst, der für das Management der verschiedenen getrennt operierenden Prozesse bei den IIS benötigt wird.
Für das OCSP müssen zusätzlich die Remoteserver-Verwaltungstools für die Active Directory-Zertifikatsdienste installiert werden.
Die Rolle der MSCEP kann nur auf Servern eingerichtet werden, auf denen keine Zertifikatsdienste installiert sind. Diese Trennung erfolgt aus Sicherheitsgründen. Falls die MSCEP/NDES genutzt werden sollen, sind also mindestens zwei Server in der Infrastruktur erforderlich.
Die Einrichtung der CA
Bei der Einrichtung der CA kann anschließend zwischen einer Unternehmens-CA und einer eigenständigen CA unterschieden werden. Erstere ist mit dem Active Directory integriert und kann dieses beispielsweise für das automatische Enrollment von Zertifikaten zu Benutzern verwenden. Eigenständige CAs arbeiten dagegen unabhängig vom Active Directory. Die Unternehmens-CAs bringen für die einfache Anforderung und Verteilung von Zertifikaten erhebliche Vorteile, auch wenn eine eigenständige CA potenziell sicherer ist. Bei einer Unternehmens-CA wird die Windows-Authentifizierung als Bestätigung der Identität eines Benutzers akzeptiert, weshalb die Verteilung von Zertifikaten nur so sicher wie die bisher verwendete Windows-Authentifizierung ist.
Eigenständige CAs können auch als Trusted Root CAs im Offline-Modus – also ohne automatische Bereitstellung von Zertifikaten – für verschiedene CAs innerhalb eines Unternehmens eingesetzt werden.
Außerdem kann bei der Einrichtung einer CA unterschieden werden, ob es sich um eine Stammzertifizierungsstelle (Trusted Root CA) oder eine untergeordnete Zertifizierungsstelle handeln soll. Die erste oder einzige Zertifizierungsstelle im Unternehmen ist immer eine Stammzertifizierungsstelle.
Die privaten Schlüssel der CA
Das Sicherheitsmodell von digitalen Zertifikaten und damit von CAs basiert auf der Public Key-Verschlüsselung oder, genauer, auf Public-/Private-Key-Verfahren. Im Gegensatz zu reinen Private Key-Verfahren gibt es dabei ein Schlüsselpaar, von dem ein Schlüssel öffentlich sein darf und der andere privat sein muss. Informationen, die mit dem öffentlichen Schlüssel codiert wurden, können nur mit dem privaten Schlüssel decodiert werden und umgekehrt. Damit lassen sich alle Anwendungsfälle im Bereich der Verschlüsselung und Signatur abbilden.
Eine Zertifizierungsstelle erzeugt Zertifikate für Clients. Deren Echtheit wird durch eine Signatur gewährleistet, die mit dem privaten Schlüssel der CA codiert ist. Die Signatur kann mit dem öffentlichen Schlüssel der CA, der für gängige externe CAs beispielsweise in den Browsern vorinstalliert ist, überprüft werden. Der private Schlüssel einer CA ist damit die sensibelste Information in dem gesamten Konzept. Wenn er kompromittiert wird, sind alle ausgestellten Zertifikate wertlos.
Bei der Einrichtung einer CA kann entschieden werden, ob ein neuer privater Schlüssel erzeugt oder ein bereits vorhandener Schlüssel genutzt werden soll. Letzteres ist typischerweise bei der Wiederherstellung einer CA der Fall, ersteres bei der initialen Installation.
Die Algorithmen
Der nächste Schritt ist die Auswahl der Algorithmen. In der Regel kann man mit den Standardwerten, die angeboten werden, gut arbeiten. Es gibt aber inzwischen eine Vielzahl so genannter CSP (Cryptography Service Providers), über die spezielle Funktionen bereitgestellt werden.
Zu diesen speziellen Funktionen gehört beispielsweise die Unterstützung von Smartcards, auf denen die Zertifikate abgelegt werden, und von speziellen Verschlüsselungsfunktionen. Beim Windows Server 2008 wurde die Bandbreite in diesem Bereich deutlich ausgebaut, wie weiter unten im Zusammenhang mit CNG (Cryptography Next Generation) noch ausgeführt wird.
Bei besonders sicherheitssensitiven Umgebungen und in Situationen, in denen der physische Schutz der Zertifizierungsstellen nicht optimal gewährleistet ist, kann man auch verstärkte Sicherheitsfunktionen für den privaten Schlüssel der CA konfigurieren, was aber administrative Eingriffe bei der Nutzung erfordern kann.
Name und Gültigkeitsdauer
Die folgenden Schritte in der Konfiguration sind die Festlegung des Namens der Zertifizierungsstelle und der Gültigkeitsdauer der Zertifikate, die von dieser CA ausgestellt werden. Der Name wird standardmäßig vom Namen des Servers abgeleitet. Es bietet sich aber an, die Zertifizierungsstelle mit einer vom Unternehmensnamen abgeleiteten Bezeichnung zu versehen.
Der Name ist auch deshalb wichtig, weil das Zertifikat der Stammzertifizierungsstelle im Browser von Clients unter dieser Bezeichnung erscheint und alle Zertifikate, die von der CA ausgestellt werden, ebenfalls diese Information enthalten.
Außerdem muss eine Gültigkeitsdauer für von der CA ausgegebene Zertifikate festgelegt werden. Diese ist ein Kompromiss zwischen administrativem Aufwand und Sicherheit. Bei Ablauf der Gültigkeit müssen die Zertifikate erneuert werden. Wenn mit Autoenrollment-Funktionen gearbeitet wird, ist das unproblematisch, da in diesem Fall auch die Aktualisierung von Zertifikaten automatisiert werden kann. Bei einer manuellen Verteilung von Zertifikaten entsteht aber durch die Erneuerung ein erheblicher administrativer Aufwand.
Zertifikatsdatenbank
Ein weiterer Schritt ist die Festlegung des Speicherorts für die Zertifikatsdatenbank. Standardmäßig wird diese unterhalb von C:\Windows\system32\CertLog abgelegt, ebenso wie das Protokoll mit den Veränderungen. Es macht in jedem Fall Sinn, für Datenbank und Protokoll unterschiedliche physische Festplatten anzugeben. Außerdem ist zu überlegen, diese Informationen in Verzeichnissen direkt unter dem Root der jeweiligen Laufwerke abzulegen. Die Zugriffsberechtigungen werden bei der Installation standardmäßig gesetzt.
Da in der Datenbank sehr sensible Informationen abgelegt werden, muss der Server mit der Zertifizierungsstelle physisch entsprechend gut geschützt werden.
Damit ist die eigentliche Basiskonfiguration der Zertifizierungsstelle abgeschlossen. Im nächsten Schritt müssen noch die IIS eingerichtet werden, falls die Webregistrierung oder OCSP als Rollendienst für die AD CS ausgewählt wurden. Wie bereits oben erwähnt, sind bei den IIS 7 nur die unbedingt erforderlichen Rollendienste ausgewählt. Abschließend können die Konfigurationseinstellungen noch einmal überprüft werden.
Die Bedeutung der Zertifikatsdienste
Die Zertifikatsdienste des Windows Server 2008 sind vor allem deshalb inzwischen von so großer Bedeutung, weil immer mehr Funktionen auf den Zertifikatsdiensten basieren.
Ein wichtiger Aspekt ist die zertifikatsbasierende Authentifizierung über Smartcards oder zunehmend auch USB-Tokens, auf denen die Zertifikate abgelegt werden. Diese wird bei Windows Vista voll unterstützt und von Microsoft als bevorzugter Mechanismus für die Authentifizierung propagiert. Ohne einen Mechanismus für die Erstellung und Verteilung von digitalen Zertifikaten ist dieses Konzept nicht nutzbar. Wie ernst Microsoft das Thema nimmt, wird auch am ILM 2007 (Identity Lifecyle Manager) deutlich, dem Nachfolger des MIIS 2003. Dort ist nun ein Tool für das Management von Smartcard-Infrastrukturen integriert.
Zertifikate sind aber auch für neue Funktionen in Windows-Infrastrukturen von großer Bedeutung. Dabei sind zum einen die AD FS (Active Directory Federation Services) zu nennen. Für die sichere Kommunikation in Federation-Beziehungen werden digitale Zertifikate zwingend benötigt – und können über die AD CS bereitgestellt werden.
Auch die Rights Management Services (RMS) von Windows benötigen digitale Zertifikate, um die digitalen Informationen zu sichern. Sie können ebenfalls mit den AD CS gemeinsam umgesetzt werden.
Weitere Beispiele für wichtige sicherheitsrelevante Dienste sind die Authentifizierung von Systemen im Netzwerk über IEEE 802.1x oder die Verschlüsselung von eMails mit S/MIME – und natürlich die ganz profane SSL-Verschlüsselung.
CNG – Cryptography Next Generation
Eine interessante Erweiterung der Zertifikatsdienste stellt CNG (Cryptography Next Generation). Darunter werden im Kern zwei wesentliche Neuerungen zusammengefasst. Die eine sind neue Schnittstellen für die Nutzung von Zertifikatsdiensten in Anwendungen, also beispielsweise die Anforderung, Abholung und Speicherung von Zertifikaten. Die Erweiterbarkeit der Zertifikatsdienste wird dadurch deutlich erhöht.
Die zweite wichtige Neuerung ist die Unterstützung der so genannten Suite-B-Algorithmen. Diese sind von der US-Regierung definiert worden und sind für den Einsatz im öffentlichen Bereich der USA entsprechend von hoher Bedeutung. Die Suite-B-Algorithmen sollen die RSA-Algorithmen ersetzen und ein höheres Maß an Sicherheit bieten.
Die Zertifikatsdienste des Windows Server 2008 unterstützen diese Algorithmen. Allerdings muss dabei mit einer reinen Windows Server 2008-Infrastruktur für die Zertifikatsdienste gearbeitet werden. Außerdem werden die Algorithmen client-seitig derzeit nur bei Windows Vista und dem Windows Server 2008 unterstützt. (mha)