![[Aufmachergrafik: heller corporate design]](04-1-010-0.jpg)
Windows Certificate Services Flexible PKI-Lösung ohne Extrakosten Windows Certificate Services Flexible PKI-Lösung ohne ExtrakostenSeit Windows 2000 enthalten Microsofts Server-Betriebssystem-Varianten standardmäßig Komponenten für eine Public Key Infrastructure (PKI). Im Mittelpunkt davon steht mit den Certificate Services der Dienst, der innerhalb der Windows-PKI als Certification Authority (CA) agiert. Bei Windows 2000 waren die Certificate Services jedoch im Wesentlichen auf reine Microsoft-Umgebungen ausgerichtet und besaßen nur einen sehr eingeschränkten Funktionsumfang.
Unter Windows Server 2003 haben sie aber einen deutlichen Zuwachs hinsichtlich Funktionsumfang, Interoperabilität und Sicherheit erfahren, sodass eine solche Microsoft-CA nun auch in heterogene IT-Strukturen passt, wie sie typischerweise in Unternehmen zu finden sind. Die Windows-2003-Certificate-Services sind zwar ebenfalls auf eine möglichst einfache und transparente Integration in Windows-Umgebungen ausgerichtet, durch die offene Architektur ist eine Integration aber auch in andere Umgebungen mit vertretbarem Aufwand möglich.
----------Anfang Textkasten----------
Das zentrale Element der Certificate Services ist die Server-Engine. Sie steuert alle anderen angeschlossenen Komponenten und zeichnet für die Ausstellung, Sperrung und Verwaltung der beantragten Zertifikate verantwortlich. "Unterhalb" der Server-Engine liegt die Certificate Database, die alle beantragten, ausgestellten, abgewiesenen und zurückgezogenen Zertifikate speichert. Sie liegt standardmäßig im Pfad C:\Windows\System32\CertLog\CA-Kurzname>.edb.
Die Server-Engine nimmt die Zertifikatsanträge von Clients über so genannte Intermediaries entgegen. Diese bereiten die vom Benutzer eingegebenen Informationen für die Server-Engine auf, indem sie die vom Client unformatiert bereitgestellten Anträge in das PKCS#10- oder CMC-Format umwandelt (Certificate Management via CMS, Cryptographic Message Syntax). Die Windows-2003-CA kann verschiedene Intermediaries verwenden:
Ob ein Zertifikatsantrag konform zu den Sicherheits- und den Zertifizierungs-Richtlinien ist, prüft das Policy-Modul. Es entscheidet dann über die Ausstellung oder Ablehnung des beantragten Zertifikats. Das Policy-Modul kann im auszustellenden Zertifikat zudem, abhängig vom angeforderten Zertifikats-Typ, zusätzliche Eigenschaften und Attribute setzen.
Ein nachgelagertes Exit-Modul benötigt man beispielsweise, wenn ausgestellte Zertifikate in weiteren (externen) Datenbanken oder Directories veröffentlicht werden sollen, wobei auch das Microsoft Active Directory als "externe" Datenbank gilt.
![[Zusammenspiel der einzelnen Komponenten]](04-1-010-1.jpg)
Abbildung 1: Komponenten der Microsoft Certificate Services
----------Ende Textkasten----------
Soll die Microsoft-CA in reine Windows-Umgebungen integriert werden, sind für mittlere Anforderungen kaum Anpassungen nötig, für die meisten Anwendungen genügen die Standardeinstellungen. Windows XP und Windows Server 2003 können die PKI nativ nutzen für:
Da man den CA-Service in das Active Directory einbinden kann, sind die CA-Administration und die Einbettung in Windows-Domänen/-Forests mit relativ geringem Aufwand verbunden.
In den meisten Netzwerken sind aufgrund gewachsener Strukturen kaum reine Windows-Umgebungen anzutreffen. Noch weiter verschärft sich die Situation, wenn man mit Zulieferern, Partnern und Kunden sicher kommunizieren oder den eigenen Mitarbeitern die Möglichkeit geben will, sich von außerhalb ins Firmen-LAN einzuwählen: In der Regel besteht dann keine Möglichkeit, die Kommunikationspartner oder Mitarbeiter an bestimmte Protokolle, Betriebssysteme oder Anwendungen zu binden. Will man sich von seiner Umwelt nicht völlig abschotten, muss man hybride Umgebungen in Kauf nehmen. PKI-Methoden sollten ohnehin über Netzwerk- und Organisationsgrenzen hinweg funktionieren, sonst läuft man Gefahr, Insellösungen zu schaffen.
Integration über Netzwerkgrenzen hinweg erfordert das Einhalten von Standards (im Wesentlichen durch die Hersteller von PKI-fähiger Software). Die Certificate Services von Microsoft unterstützen gängige Standards und können aufgrund ihrer Flexibilität auch speziellere Anforderungen erfüllen. Beispielsweise ist es mit einigen Kniffen möglich, Zertifikate mit besonderen Erweiterungen für Netscape, Signatur-Zertifikate für Adobe Acrobat und Server-Zertifikate für Cisco-Router und -Gateways über Ciscos Simple Certificate Enrollment Protocol (SCEP) auszustellen.
Durch Anpassung der Zertifikatsvorlagen (Certificate Templates), was seit Windows Server 2003 möglich ist, kann man in die ausgestellten Zertifikate beliebige Attribute aufnehmen, die PKI-fähige Anwendungen (auch von Drittherstellern) dann entsprechend auswerten können. Da man solche Attribute auch anhand ihrer Object-ID (OID) adressieren kann, ist sogar eine Erweiterung um Zertifikatsattribute denkbar, die zum jetzigen Zeitpunkt noch nicht standardisiert oder nur innerhalb einer bestimmten Organisation gültig sind.
Der größte Vorteil der Windows 2003 Certificate Services ist vermutlich, dass sie sowohl in der Standard- als auch der Enterprise- und Datacenter-Edition fester Bestandteil des Windows-Server-2003-Betriebssystems sind und man die CA somit mehr oder weniger als "kostenlose" Dreingabe erhält. Als weitere Stärken sind zu nennen:
Diesen Stärken stehen allerdings auch einige Punkte gegenüber, in denen die Windows-2003-Certificate-Services noch Schwächen zeigen:
Die Windows-2003-CA kann in zwei Varianten installiert werden: Entweder als Stand-alone-CA, die keine Anbindung an ein bestehendes Active Directory (AD) benötigt oder als Enterprise-CA, die in eine Windows-Domäne integriert werden muss. Zudem ist zu unterscheiden, ob damit eine Root-CA oder eine untergeordnete CA (Subordinate CA) implementiert werden soll. Tabelle 1 gibt einen Überblick über die resultierenden vier möglichen Grundkonfigurationen.
| CA-Typ | Beschreibung |
|---|---|
| Stand-alone Root-CA | oberste Ebene in einer Zertifizierungshierarchie, stellt sich selbst ein Zertifikat aus ("self signed"), benötigt kein Active Directory (AD) und muss nicht zwingend in eine Windows-Domäne integriert werden, kann leicht in einer sicheren Umgebung aufgestellt oder als "Offline"-Root-CA betrieben werden, kann ein evtl. vorhandenes AD zur Veröffentlichung von Zertifikaten und Sperrlisten benutzen |
| Enterprise Root-CA | oberste Ebene in einer Zertifizierungshierarchie, stellt sich selbst ein Zertifikat aus ("self signed"), benötigt ein Active Directory zur Verwaltung von Benutzern und Computern und muss als Domain Controller konfiguriert werden, Vertrauensbeziehungen können über Gruppenrichtlinien innerhalb der Windows-Domäne automatisch verbreitet werden |
| Stand-alone CA (untergeordnet) | muss von einer übergeordneten CA mit einem CA-Zertifikat ausgestattet werden, benötigt kein Active Directory (AD), kann aber Zertifikate und Sperrlisten in einem evtl. vorhandenen AD veröffentlichen, kann nur Standard-Zertifikatsvorlagen verwenden |
| Enterprise CA (untergeordnet) | muss von einer übergeordneten CA mit einem CA-Zertifikat ausgestattet werden, AD-Anbindung ist erforderlich, Gruppenrichtlinien und damit die automatische Verbreitung von Vertrauensbeziehungen innerhalb der Domäne können genutzt werden, kann selbst definierte Zertifikatsvorlagen verwenden, muss als Domain Controller konfiguriert werden – innerhalb dieser Windows-Domäne ist Smartcard-Logon möglich |
Eine Root-CA stellt grundsätzliche keine Zertifikate für Endbenutzer beziehungsweise Endeinheiten, sondern ausschließlich für untergeordnete Zertifizierungsstellen aus. Wie Tabelle 1 zeigt, bietet die Enterprise-CA einen größeren Funktionsumfang, wobei besonders die Integrationsmechanismen von Windows-Umgebungen im Vordergrund stehen. Das heißt jedoch nicht unbedingt, dass sich eine Enterprise-CA für alle "Windows-Szenarien" am besten eignen muss: Der reduzierte Funktionsumfang der Stand-alone-CA geht Hand in Hand mit einer leichteren Administration, was in einfacheren Umgebungen vorteilhaft sein dürfte.
Eine Zertifizierungshierarchie muss außerdem nicht zwingend aus CA-Servern des gleichen Typs bestehen. Es ist ohne weiteres möglich Enterprise-, Stand-alone- und Offline-CAs gemischt zu betreiben. Gerade die sicherheitskritische Root-CA muss nicht ständig erreichbar sein, da das Ausstellen von Zertifikaten für untergeordnete Zertifizierungsstellen und das Aktualisieren der Sperrlisten bei einer in der Regel überschaubaren Anzahl von Sub-CAs keine besonders zeitintensive Aufgabe darstellt.
In vielen PKI-Modellen sind Registrierungsstellen (Registration Authorities, RA) vorgesehen. Dann beantragt in der Regel ein "Registrierer" (Personalisation Officer, PO) im Auftrag des Endnutzers Zertifikate bei der CA. Die Registrierungsstelle hat die Aufgabe, die Identität des Antragstellers zu verifizieren und gegenüber der CA zu bestätigen.
Im Microsoft-Modell wird für den PO ein Personalisierer-Zertifikat (Enrollment Agent Certificate) ausgestellt, das er zum Signieren der Zertifikatsanträge benutzt. Da mit einem solchen Zertifikat die Beantragung beliebiger Zertifikate für beliebige Benutzer möglich ist, sollten die Richtlinien für diese Zertifikate sehr restriktiv eingestellt und gehandhabt werden.
Die Certificate Services von Windows Server 2003 unterstützen Key Archival und Recovery, also die Archivierung von Dechiffrier-Schlüsseln zum Zweck der Schlüsselwiederherstellung, wenn der Benutzer seinen geheimen Schlüssel versehentlich löscht oder verliert und im ungünstigsten Fall seine verschlüsselten Daten nicht mehr lesen kann.
Die zu archivierenden geheimen Schlüssel werden dazu mit speziellen, so genannten Key-Recovery-Agent-(KRA-)Zertifikaten chiffriert. Für jeden CA-Server lässt sich einstellen, welche KRA-Zertifikate hierfür zugelassen sind; es findet dann eine Mehrfachverschlüsselung mit allen eingetragenen KRA-Schlüsseln statt.
Das Wiederherstellen archivierter Schlüssel ist durch jeden Benutzer möglich, der im Besitz eines solchen KRA-Zertifikats ist. Das Modell sieht derzeit bei der Schlüsselwiederherstellung keinen Kontrollmechnismus, wie beispielsweise ein Vier-Augen-Prinzip, vor. Das eröffnet Missbrauchsmöglichkeiten für die Key Recovery Agents und – noch schlimmer – für den Fall, dass ein KRA-Zertifikat geknackt wurde.
Daher sind auch für KRA-Zertifikate äußerst strenge Richtlinien erforderlich und zusätzlich sollten besondere (konventionelle) Sicherheitsmaßnahmen für den Zugangsschutz zu den KRA-Zertifikaten sorgen. Soll ein Vier-Augen-Prinzip umgesetzt werden, muss man dies ebenfalls mithilfe anderer Methoden bewerkstelligen, zum Beispiel durch organisatorische Maßnahmen.
Wer hohe Sicherheit benötigt oder vielleicht sogar die strengen Vorgaben des deutschen Signaturgesetzes erfüllen will, kommt an Smartcards als Signaturerstellungseinheit und sicherem Schlüsselspeicher nicht vorbei. Die Umsetzung der Microsoft Certificate Services weist jedoch gerade bei der Ausstellung von Zertifikaten auf Smartcards durch Registrierungsstellen und bei der Schlüsselarchivierung Defizite auf: Einerseits sind, wie bereits erwähnt, die Zertifikatsvorlagen, die eine Smartcard Enrollment Station nutzen kann, auf zwei mögliche Vorlagen eingeschränkt.
Zum anderen funktioniert die Schlüsselarchivierung beim Ausstellen von Zertifikaten auf Smartcards schlichtweg überhaupt nicht, da die geheimen Schlüssel direkt auf der Karte generiert werden und keine Möglichkeit besteht, die dort erzeugten Schlüssel nachträglich zu exportieren, um sie archivieren zu können.
Sollen diese Defizite behoben werden, kommt man um eigene Lösungen nicht herum: Soll das Ausstellen von Zertifikaten über Registrierungsstellen möglich sein, muss ein neues Intermediary (s. o.) entwickelt werden, das es gestattet, weitere Zertifikatsvorlagen auszuwählen und durch einen PO zu signieren. Auch das Problem der Schlüsselarchivierung kann nur durch ein speziell entwickeltes Exit-Modul behoben werden: Die Schlüsselgenerierung könnte dann zentral auf dem Server erfolgen. Dadurch läge zunächst ein Software-Zertifikat vor, dessen geheimer Schlüssel archiviert und anschließend auf eine Smartcard exportiert werden kann.
Neben dem Funktionsumfang spielt natürlich auch die Sicherheit der CA-Services eine entscheidende Rolle. Ein Schwachpunkt unter Windows-2000-Server waren die uneingeschränkten Berechtigungen des Administrator-Accounts. Dies hat Microsoft erkannt und mit der Windows-Server-2003-CA ein Rollenmodell für die CA-Administration eingeführt, das die Berechtigungen der verschiedenen Administrator-Accounts trennt und strikt gegeneinander abgrenzt. Diese "Gewaltenteilung" ist konform zur Definition der Version 1.0 der Certificate Issuing and Management Components Family of Protection Profiles (CIMC) des National Institute of Standards and Technology (NIST), online zu finden unter ![[externer Link]](../../../../images/link.gif)
http://csrc.nist.gov/pki/documents/CIMC_PP_20011031.pdf. Dieser Standard definiert die Anforderungen an Komponenten, die X.509-Zertifikate ausstellen, sperren oder verwalten. Tabelle 2 zeigt die definierten Rollen mit ihren entsprechenden Berechtigungen.
| Rolle | Berechtigungen | Beschreibung |
|---|---|---|
| CA Administrator (Administrator) | CA-Administration und Konfiguration | Konfiguration und Wartung der CA, Vergabe der CA-Rollen an Benutzer, Erneuerung des CA-Zertifikats |
| Certificate Manager (Officer) | Zertifikate ausstellen und verwalten | Bewilligung von Zertifikats- und Sperranträgen |
| Backup Operator (Operator) | Dateien und Verzeichnisse sichern/wiederherstellen | Durchführen von System- und CA-Sicherungen sowie Wiederherstellung gesicherter Daten |
| Auditor (Auditor) | Verwaltung der Sicherheits- und Audit-Logfiles | Konfiguration und Verwaltung von Audit-Logfiles |
Standardmäßig ist die Rollentrennung nach der Installation des CA-Services allerdings nicht aktiviert und alle beschriebenen Rollen sind auf den lokalen Administrator-Account vereinigt, bei Integration des Servers in eine Domäne auch auf den Domänen- und den Enterprise-Administrator. Wird die Rollentrennung eingeschaltet, prüft die CA für jeden Benutzer, ob diesem mehr als eine Rolle zugeteilt ist. Sofern das der Fall ist, verweigert die CA dem Benutzer den Zugriff auf den CA-Service und erzwingt somit eine saubere Trennung der Funktionen.
Natürlich steht es dem "allmächtigen" lokalen Server-Administrator frei, mehrere Benutzer im System anzulegen und die CA-Rollen darauf zu verteilen, sodass letztendlich die Trennung faktisch wieder aufgehoben wird. Dem kann man lediglich dadurch entgegenwirken, dass ein Auditor ernannt wird, der auf jeden Fall verschieden von der Person des Administrators beziehungsweise Certificate Managers sein muss. Hierauf sollte man bei der Definition der (organisatorischen) Sicherheitsrichtlinien unbedingt achten.
Unerlässlich für die Sicherheit der CA-Services ist zudem die physische Sicherheit des Servers. Hier empfiehlt es sich, abhängig vom Einsatzszenario, CA-Typ und der erwarteten Menge auszustellender Zertifikate eine Kombination der folgenden Sicherheitsmechanismen zu implementieren:
www.microsoft.com/technet/security/prodtech/win2003/w2003hg/sgch01.asp). Der Security Guide definiert drei Sicherheitsklassen: Legacy Client Environment (Level 1), Enterprise Client Environment (Level 2) und High Security Environment (Level 3). Sofern die Infrastruktur dies zulässt, sollte ein CA-Server immer im High-Security-Environment betrieben werden.Die Windows-Certificate-Services sind inzwischen verhältnismäßig ausgereift und gut einsetzbar. In reinen Windows-Umgebungen ist eine Integration problemlos und transparent möglich. Mit einer Windows-Server-2003-CA erreicht man bereits mit wenig Konfigurationsaufwand eine sehr gute Abdeckung von Standard-Anforderungen, beispielsweise in den Bereichen Authentifizierung (Windows-Smartcard-Logon, SSL-Authentifizierung) und S/MIME (sichere E-Mail).
Für speziellere Anforderungen, etwa ein individuelles Zertifikatslayout, der Verwendung von Smartcards als sichere Schlüsselspeicher oder eine Schlüsselarchivierung, muss man je nach Anforderung mit mehr oder weniger hohem Aufwand für Konfiguration, Entwicklung und Integration rechnen.
Die Certificate Services unterstützen alle gängigen Vertrauensmodelle in PKI-Strukturen, wie baumförmige PKI-Hierarchien mit dedizierten Wurzelinstanzen, flache PKI-Strukturen mit Vertrauensbeziehungen durch Cross-Zertifizierung sowie Mischformen. Ab der Implementation der Certificate Services in Windows Server 2003 steht zur Administration auch eine Rollentrennung zur Verfügung.
Insgesamt darf die Sicherheit eines CA-Servers jedoch nie ausschließlich durch Technik getrieben werden. Die technische Sicherheit muss vielmehr ein Abbild der organisatorischen Sicherheitsvorgaben sein, die bereits bei der PKI-Planung (ob mit oder ohne Microsoft-CA) zwingend aufgestellt werden müssen. Die Certificate Services können letztlich immer nur so sicher sein, wie es die Richtlinien vorgeben und wie man die Umsetzung der Vorgaben durchführt und kontrolliert.
Aktuelle Virenscanner und das Einspielen der neuesten Patches sollte für sicherheitskritische Server ohnehin selbstverständlich sein. Darüber hinaus sollte man eine Härtung des Betriebssystems auf Softwareseite erwägen. Auf keinen Fall dürfen physische Sicherheitsvorkehrungen (Diebstahlschutz, Zugangskontrolle und -beschränkung, Schutz vor Katastrophen) sowie organisatorische Regelungen zur Sicherheit (Berechtigungskonzepte, Notfallpläne, Risikoanalysen, Audits) außer Acht bleiben.
Windows Server 2003 bietet ausreichend viele Konfigurationseinstellungen und Parameter, mit denen sich die Sicherheit der Microsoft-CA erhöhen lässt. Diese angebotenen Mechanismen tatsächlich zu nutzen, obliegt wie immer dem Betreiber.
Dipl.-Ing. Oliver Klinger ist Senior Consultant IT-Security bei Secardeo.
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2004#1, Seite 10
| 