Planungshandbuch - Sichern von Wireless LANs mit Zertifikatsdiensten

Auf dieser Seite

	Einführung
	Definieren der Zertifikatsanforderungen
	Entwerfen der Zertifizierungstellen-Hierarchie
	Konfigurieren von Zertifikatsprofilen
	Erstellen eines Zertifikatverwaltungsplans
	Zusammenfassung

Einführung

Im vorhergehenden Kapitel wurde ein logischer Entwurf für eine sichere WLAN-Lösung beschrieben, die auf einer PKI (Public Key Infrastructure, Infrastruktur öffentlicher Schlüssel) aufbaut. In diesem Kapitel wird der Prozess des Entwerfens einer PKI auf der Grundlage der Microsoft® Windows® 2003-Zertifikatsdienste für diese Lösung beschrieben. Um die Kosten für die Bereitstellung und Verwaltung möglichst niedrig zu halten, ist der Lösungsentwurf relativ einfach gehalten und so gestaltet, dass problemlos Zertifikate für sichere WLAN-Clients und für die WLAN-Infrastruktur ausgestellt werden können.

Das Hauptziel besteht zwar darin, eine PKI zu entwerfen, die sichere WLANs unterstützt, Sie sollten aber dabei bedenken, dass eine PKI auch ein wichtiger Bestandteil der Gesamtsicherheitsinfrastruktur Ihrer Organisation sein und dementsprechend künftig von vielen anderen Anwendungen in Ihrer Umgebung genutzt werden kann. Um Ihre Investitionen in diese Infrastruktur zu schützen, ist der hier vorgestellte Lösungsentwurf erweiterbar. Das bedeutet, dass der Entwurf zwar vielleicht nicht für die Ausstellung aller Zertifikatstypen geeignet ist, dass Sie ihm aber später zusätzliche Funktionen und Kapazitäten hinzufügen können, um so noch umfassenderen Sicherheitsanforderungen gerecht zu werden.

Dieses Kapitel hat die folgenden drei Hauptziele. Zunächst werden die Entscheidungen für den Lösungsentwurf und die zugrunde liegenden Überlegungen vorgestellt. Als Nächstes erhalten Sie einige Hintergrundinformationen zur Planung, anhand derer Sie leichter einschätzen können sollen, ob diese Entscheidungen auch für Ihre PKI korrekt sind. Als Drittes werden Wege zur Erweiterung der Grundlösung aufgezeigt, um so Sicherheitsanforderungen gerecht zu werden, die im Rahmen dieser Lösung nicht berücksichtigt werden.

Formulierungen wie "Bei dieser Lösung wird ... verwendet" bzw. "Bei diese Lösung kommt ... zum Einsatz" oder "Dieser Entwurf verwendet ..." in diesem Kapitel beziehen sich auf Entscheidungen zum Lösungsentwurf, die dann in den Kapiteln dieses Handbuchs, die sich mit dem Aufbau und dem Betrieb der Lösung befassen, implementiert werden.

Formulierungen wie "sollten Sie entscheiden ..." stehen an den Stellen, an denen Sie entsprechend den Anforderungen in Ihrer Organisation eine Entscheidung treffen müssen. Solche Formulierungen treten vor allem dann auf, wenn es um Möglichkeiten der Erweiterung der Lösung geht, mit denen die noch größeren Sicherheitsanforderungen in Ihrer Organisation erfüllt werden sollen. Daher enthalten einige Themen auch eine detailliertere Erläuterung, damit Sie besser verstehen können, welche Implikationen die einzelnen Schritte haben, und nicht zu Referenzzwecken auf andere Ressourcen zurückgreifen müssen.

Voraussetzungen für das Kapitel

Sie benötigen gute Kenntnisse der allgemeinen Prinzipien der PKI und der in diesem Zusammenhang verwendeten Terminologie. Wenn Sie mit dieser Technologie noch nicht vertraut sind, lesen Sie sich die entsprechenden Dokumente durch, auf die im Abschnitt "Weitere Informationen" am Ende dieses Kapitels verwiesen wird.

Bevor Sie mit diesem Kapitel fortfahren, sollten Sie sich mit dem Kapitel "Designing a Public Key Infrastructure" im Microsoft Windows Server 2003 Deployment Kit beschäftigen. Wo Sie dieses Kapitel finden, erfahren Sie im Abschnitt "Weitere Informationen" am Ende dieses Kapitels. Dieses Kapitel entspricht von der Gliederung her dem Kapitel "Designing a Public Key Infrastructure" im Deployment Kit, um Ihnen beim Auffinden der relevanten Hintergrundinformationen und ausführlicheren Beschreibungen zu helfen.

Im Abschnitt "Weitere Informationen" finden Sie auch Links zu weiteren Informationen zum Thema "Planen und Entwerfen einer Windows Server 2003-PKI".

Kapitelübersicht

Das Planen und Bereitstellen einer PKI, die sowohl den aktuellen als auch den zukünftigen Anforderungen Ihrer Organisation gerecht wird, ist keine einfache Aufgabe. Normalerweise besteht die Aufgabe einer PKI nicht darin, nur ein einzelnes, isoliertes Sicherheitsproblem zu lösen. Vielmehr soll die PKI in einer Organisation sowohl verschiedene interne Sicherheitsanforderungen als auch geschäftliche Sicherheitsanforderungen erfüllen, die sich aus der Zusammenarbeit mit externen Kunden oder Geschäftspartnern ergeben.

Die folgende Abbildung zeigt die Gliederung des Kapitels.

Abbildung 4.1: Gliederung des Kapitels für die Planung von Zertifikatsdiensten

Der Prozess der Planung umfasst die folgenden vier Hauptschritte:

Zum Seitenanfang

Definieren der Zertifikatsanforderungen

In diesem Abschnitt wird angegeben, für welche Zwecke die PKI Zertifikate ausstellt und welche Sicherheitsanforderungen für die einzelnen Zwecke jeweils gelten.

Erstellen einer Zertifikatverwendungserklärung

Beim Entwerfen Ihrer PKI sollten Sie alle Entscheidungen darüber, wie Zertifikate in Ihrem Unternehmen ausgestellt und verwendet werden, dokumentieren. Diese Entscheidungen werden in so genannten "Zertifikatsrichtlinien" und "Zertifikatsverwendungserklärungen" (Certification Practice Statement, CPS) aufgezeichnet.

Formal gesehen ist eine Zertifikatsrichtlinie (Certificate Policy, CP) ein Satz von Regeln, die von der PKI befolgt werden. Die Richtlinie zeichnet z. B. die Anwendbarkeit eines Zertifikats auf eine bestimmte Gruppe von Clients oder Anwendungen mit normalen Sicherheitsanforderungen auf. EineZertifikatsverwendungserklärung(CPS) dagegen ist eine Erklärung der Verfahren, mit deren Hilfe die ausgestellten Zertifikate in einer Organisation verwaltet werden. Sie beschreibt, wie die Zertifikatsrichtlinien im Kontext der Systemarchitektur und der Betriebsverfahren des Unternehmens interpretiert werden. Zertifikatsrichtlinien sind organisationsweit gültige Dokumente, während Zertifikatsverwendungserklärungen CA-spezifisch sind. (Dabei kann jedoch für mehrere CAs eine gemeinsame Zertifikatsverwendungserklärung gelten, wenn diese dieselbe Aufgabe erfüllen, z. B. wenn Sie die CA-Last aus Gründen der Geschwindigkeit oder der Ausfallsicherung auf mehrere Server verteilen.)

In einigen Organisationen und bei manchen Verwendungszwecken von Zertifikaten gelten Zertifikatsrichtlinien und Zertifikatsverwendungserklärungen als rechtsgültige Dokumente und werden als Haftungsausschlussdokumente herangezogen. Sie erfordern daher normalerweise eine fachmännische Rechtsberatung, die den Rahmen dieses Kapitels sprengen würde. Es besteht jedoch keine zwingende Notwendigkeit, diese beiden Dokumente im Rahmen des PKI-Entwurfs zu erstellen. Sofern keine speziellen rechtlichen oder geschäftlichen Gründe dafür vorliegen, sollten Sie sich den zeitlichen und finanziellen Aufwand für die Erstellung und Verwaltung formeller Zertifikatsrichtlinien und Zertifikatsverwendungserklärungen ersparen.

Auch wenn Sie keine formelle Zertifikatsrichtlinie bzw. Zertifikatsverwendungserklärung benötigen, sollten Sie Ihre Zertifikatsrichtlinien und Betriebsverfahren dennoch dokumentieren. Die Zertifikatsrichtlinien sollten in die Sicherheitsgesamtrichtlinien Ihres Unternehmens und die Betriebsverfahren in die Sicherheitsverwaltungsverfahren aufgenommen werden. Dies ließe sich als informelle CPS bezeichnen.

Auf der Grundlage des geplanten Verwendungszwecks Ihrer PKI sollten Sie entscheiden, ob eine formelle Richtlinienerklärung und eine Zertifikatsverwendungserklärung erstellt werden muss. Wird eine formelle Zertifikatsverwendungserklärung benötigt, müssen Sie sie wahrscheinlich veröffentlichen und in Ihre CA-Zertifikate Verweise darauf einfügen. Diese Lösung enthält zwar keine Hinweise für das Verfassen einer formellen Zertifikatsverwendungserklärung, Sie finden jedoch Anweisungen zu deren Veröffentlichung in Kapitel 7, "Implementieren der Infrastruktur öffentlicher Schlüssel". Informelle Zertifikatsverwendungserklärungen müssen normalerweise nicht veröffentlicht werden.

Im weiteren Verlauf dieses Kapitels wird häufiger darauf hingewiesen, dass Entscheidungen in Ihrer CPS festgehalten werden sollten. Diese Anweisungen gelten sowohl für formelle als auch für informelle CPS.

Hinweise auf zusätzliche Quellen mit Informationen zum Erstellen einer CPS finden Sie im Abschnitt "Weitere Informationen" am Ende dieses Kapitels.

Bestimmen von Zertifikatsanwendungen

Als Erstes müssen beim Entwerfen einer PKI die Anwendungen festgelegt werden, für die Zertifikate verwendet werden sollen. Sie sollten für jede Anwendung die erforderlichen Zertifikatstypen und die ungefähre Anzahl der erforderlichen Zertifikate dokumentieren. Zu diesem Zeitpunkt müssen Sie noch keine Einzelheiten zu den Zertifikaten angeben, eine kurze Beschreibung genügt.

Die sichere WLAN-Lösung erfordert Zertifikate für drahtlose Clients und für die Windows RADIUS-Server (Remote Authentication Dial-In User Service). Der Microsoft-RADIUS-Server ist eine Komponente von Windows Server, die als "Internetauthentifizierungsdienst" (Internet Authentication Service, IAS) bezeichnet wird.

Die erforderlichen Zertifikatstypen sind in der folgenden Tabelle aufgeführt. Wenngleich nicht zwingend für diese Lösung erforderlich, stellt die PKI auch Domänencontrollern Zertifikate aus (hierbei handelt es sich um die Standardeinstellung, wenn eine Unternehmens-CA unter Windows 2003 in der Gesamtstruktur installiert ist).

Tabelle 4.1: Zertifikatsanforderungen für sichere WLAN-Lösungen

Zukünftig können Sie die PKI so erweitern, dass Zertifikate für die in der folgenden Tabelle aufgeführten Anwendungen ausgestellt werden.

Tabelle 4.2: Mögliche zukünftige Zertifikatsanforderungen

Definieren von Zertifikatsclients

Für die im vorherigen Abschnitt aufgeführten Anwendungen müssen Sie die Clients definieren, die die Zertifikate verwenden werden. Der Begriff "Client" bezieht sich in diesem Zusammenhang auf Personen, Softwareprozesse und Geräte, die die von der PKI ausgestellten Zertifikate verwenden. Clients sind z. B. Benutzer, Server, Arbeitsstationen und Netzwerkgeräte. Um zu verstehen, wie die ausgestellten Zertifikate verwendet werden, müssen Sie die folgenden beiden Hauptkategorien von Clients betrachten: Zertifikatantragsteller (bzw. Endeinheit) und andere Zertifikatsbenutzer.

Endeinheiten sind Clients, denen von der PKI ein Zertifikat ausgestellt wurde. Das Zertifikat enthält in seinen Feldern Antragsteller bzw. Alternativer Antragstellername einen oder mehrere Einträge, anhand derer der Client als Eigentümer dieses Zertifikats identifizierbar ist (z. B. Hostname, E-Mail-Adresse oder differenzierter Verzeichnisname). Die andere Kategorie der Zertifikatsbenutzer sind Clients, die z. B. die Zertifikate der Endeinheiten überprüfen oder sie in einem Verzeichnis nachsehen können müssen, für die die PKI aber nicht zwingenderweise Zertifikate ausstellen muss.

Dieser Unterschied kann gut an einem allgemeinen Beispiel erläutert werden: Internetbenutzer, die etwas auf einer sicheren Website kaufen, sind Benutzer des SSL-Zertifikats (Secure Sockets Layer) der Website. Die Website ist damit eine Zertifikatendeinheit; ihre Identität www.woodgrovebank.com wird im Feld Antragsteller des Zertifikats verschlüsselt. Nur der Zertifikatantragsteller hat Zugriff auf die Verwendung des privaten Zertifikatschlüssels. Anderen Benutzern des Zertifikats ist dies nicht möglich. Hinweis: Antragsteller von Zertifikaten sind fast immer auch Benutzer ihrer eigenen Zertifikate und, normalerweise, auch von Zertifikaten anderer.

Hinweis: "Endeinheit" ist der technisch korrekte Begriff, in diesem Kapitel wird aber durchweg der eingängigere Begriff "Zertifikatantragsteller" verwendet.

Sowohl für Zertifikatantragsteller als auch für Zertifikatsbenutzer sollten Sie alle Clienttypen in Kategorien einteilen, indem Sie die folgenden Fragen beantworten:

Diese Kategorisierung hat Einfluss auf viele Entwurfsentscheidungen, zum Beispiel auf die Art und Weise der Ausstellung des Zertifikats, auf das Maß an Vertrauen, das in ein bestimmtes Zertifikat gesetzt werden kann, und auf die Art der Veröffentlichung von Informationen zu Zertifikatssperren.

Die Clientkategorien dieser Lösung sind in den folgenden Tabellen aufgeführt.

Tabelle 4.3: Kategorien von Zertifikatantragstellern (Endeinheiten)

Bei dieser Anwendung sind die Benutzer der Zertifikate dieselben Clients, nur die Rollen sind umgekehrt. Der IAS-Server beispielsweise wird zum Benutzer der Clientzertifikate und muss diese überprüfen. Die Überprüfung umfasst normalerweise die Kontrolle, dass das Zertifikat mit einer vertrauenswürdigen Stamm-CA verbunden ist und dass die vom Client bereitgestellte Signatur mit dem öffentlichen Schlüssel des Zertifikats des Clients übereinstimmt. Das Zertifikat wird u. U. auch einer Überprüfung auf Sperrung unterzogen. Eine eingehende Erläuterung zu diesem Thema finden Sie im Dokument Troubleshooting Certificate Status and Revocation (in englischer Sprache).Verweise auf alle Quellen finden Sieim Abschnitt "Weitere Informationen" am Ende dieses Kapitels.

Tabelle 4.4: Kategorien von Zertifikatsbenutzern

Den Tabellen oben können Sie die Plattformen und die Aufgaben entnehmen, die unterstützt werden müssen. Obwohl in diesem WLAN-Szenario nicht der Fall, müssen Sie bei anderen Anwendungen in Ihrer Umgebung möglicherweise die Zertifikatssuche oder -überprüfung durch Clients im Internet bzw. die Registrierung von Nicht-Windows-Plattformen aus unterstützen. Da für viele dieser Punkte bereits im frühen Entwurfsstadium Entscheidungen getroffen werden müssen, ist es wichtig, dass Sie sich Gedanken über mögliche künftige Zertifikatsanforderungen machen.

Bei dieser Lösung gelten folgende Annahmen bezüglich künftiger Anforderungen:

Obwohl der Entwurf momentan nicht alle diese Anforderungen zwangsläufig berücksichtigt, lassen sich entsprechende Maßnahmen mühelos darin integrieren.

Definieren von Zertifikats-Sicherheitsanforderungen

Die Sicherheit eines Zertifikats wird auch als Sicherungslevel bezeichnet. Er gibt gewissermaßen an, wie stark der Inhaber des Zertifikats an das Zertifikat selbst gebunden ist. Der Level gibt an, inwieweit Sie davon ausgehen können, dass die das Zertifikat verwendende Person (bzw. das Gerät) mit dem im Zertifikat genannten Inhaber identisch ist. Der Sicherungslevel dient vor allem als Maß für zwei Dinge:

Diese beiden Aspekte sind eng miteinander verknüpft, denn es besteht kein Grund, in kostspielige Maßnahmen zum Schutz privater Schlüssel zu investieren, wenn Sie sich über die Identität des Inhabers des privaten Schlüssels nicht 100%ig sicher sind. Ebenso ist eine mühselige Registrierung mit ausführlicher Prüfung von Hintergrundinformationen und DNA-Fingerabdrücken nur von geringem Wert, wenn der private Schlüssel anschließend nicht sicher gespeichert wird.

Die Verwirklichung eines höheren Sicherungslevels für ein Zertifikat kostet Geld und ist für viele Einsatzzwecke von Zertifikaten nicht notwendig. Wenn Ihnen bei einem Zertifikat die Zusicherung ausreicht, dass es einem autorisierten Domänenbenutzer gehört, dann sind Domänenanmeldeinformationen absolut akzeptabel als Registrierungsbeleg, um ein Zertifikat zu registrieren.

Die Bedeutung der verwendeten Sicherungslevels sollten Sie in Ihrer Zertifikatsrichtlinie und in Ihren Zertifikatsverwendungserklärungen festhalten.

In der folgenden Tabelle sind für die vorliegende Lösung drei Sicherungslevels definiert.

Tabelle 4.5: Sicherungslevel für Zertifikate

Bei diesen Kategorien gibt es gewisse Überschneidungen. Es handelt sich dabei nicht um rein technische Unterteilungen, sondern im Grunde um Richtlinienunterteilungen. In Ihrer Organisation richten sich die Kategorien nach den Richtlinienentscheidungen, die Sie bezüglich des Umgangs mit den Zertifikaten treffen. Im Allgemeinen können Sie davon ausgehen, dass Zertifikate mit hohem Sicherungslevel seltener vorkommen, solche mit Standardlevel dagegen häufiger.

Wichtig: In diesem Kapitel werden statt der Begriffe "niedriger Wert" und "niedriger Sicherungslevel" die Begriffe "Standardwert" und "Standardsicherung" (auch "Standardzusicherung") verwendet, da "niedrig" einen gewissen negativen Beigeschmack hat und der Begriff "Standard" der eigentlichen Bedeutung besser gerecht wird.

Sie können die in der Tabelle oben definierten Sicherungskategorien weiter konkretisieren, indem Sie die einzelnen Kategorien in verschiedene Antragstellertypen unterteilen. Gängige Kategorien dafür sind:

Der Grund für diese Unterscheidung liegt darin, dass für die verschiedenen Inhabertypen unterschiedliche Zertifikatsrichtlinien gelten; d. h. die Bedingungen, unter denen ein Zertifikat ausgestellt, gesperrt oder erneuert wird, unterscheiden sich. Selbst wenn Sie für eine bestimmte Kategorie keine Zertifikatspläne haben, sollten Sie die Zertifikatsrichtlinien festhalten, die für die betreffende Kategorie gelten würden, damit Ihre Richtlinien und Ihr CPS richtig vorbereitet sind. In der folgenden Tabelle sind die Ergebnisse der Kombination von Sicherungslevels und Inhaberkategorien aufgeführt.

Tabelle 4.6: Zertifikatssicherheitskategorien

Hinweis: Wenn Sie keine Verwendung für eine bestimmte Kategorie haben, müssen Sie sie auch nicht erstellen. Sie können ein einfacheres oder auch ein komplexeres Klassifizierungssystem verwenden, und nicht jede Kombination muss einen Zertifikatstyp zur Folge haben, den Sie dann auch ausstellen.

Von der Technik her ließen sich diese unterschiedlichen Arten von Zertifikatantragstellern durchaus alle gleich handhaben. In der Regel werden Sie jedoch unterschiedliche Sicherheitsrichtlinien für unterschiedliche Inhabertypen festlegen; firmeneigene Angestellte zum Beispiel werden anders behandelt werden als Mitarbeiter anderer Unternehmen. Die verschiedenen Zertifikatsrichtlinien (und deren Aufnahme in unterschiedliche CPS) beeinflussen möglicherweise die Entscheidungen darüber, wie Ihre CAs für die Ausstellung dieser unterschiedlichen Zertifikatstypen strukturiert werden sollen. Dies wird zu einem späteren Zeitpunkt im Kapitel behandelt.

Ferner sollten Sie sich überlegen, ob ein und derselbe Administrator letztendlich für Zertifikate verantwortlich sein soll, die diesen drei Kategorien von Zertifikatbenutzern (oder "Endentitäten" in PKI-Terminologie) ausgestellt werden. In vielen Organisationen ist die Person, die bestätigen kann, dass ein Computer ein legitimes Domänenmitglied ist, nicht dieselbe Person, die die Identität eines Partnerunternehmens bestätigen kann. Diese Verantwortungsbeziehungen sollten Sie in Ihrer CPS dokumentieren.

Definieren der Sicherheit von Anwendungszertifikaten

Anhand der im vorigen Abschnitt definierten Zertifikatssicherheitskategorien können die Zertifikatstypen für den Entwurf klassifiziert werden. Siehe dazu die folgende Tabelle.

Tabelle 4.7: Zertifikatssicherheitsanforderungen

Diese allgemeinen Anforderungen werden beim Erstellen spezifischer Zertifikatsprofile im Abschnitt "Konfigurieren von Zertifikatsprofilen" weiter unten im Kapitel noch genauer gefasst.

Kombinieren von Zertifikatszwecken

Es ist möglich, mehrere Anwendungsfunktionen (oder Verwendungszwecke) in einem Zertifikat zusammenzufassen, so dass Sie mit einem einzigen Zertifikat E-Mails signieren, sich im Netzwerk anmelden und Zugriff auf eine Anwendung gewähren können. Die Kombination von Verwendungszwecken führt zu einem geringeren Verwaltungs- und Speicheraufwand auf den Zertifikats- und Verzeichnisservern.

Mehrzweckzertifikate haben allerdings auch Nachteile. Unterschiedliche Anwendungen erfordern beispielsweise möglicherweise jeweils ein eigenes Genehmigungsverfahren für das Zertifikat. Die meisten Gründe für die Verwendung mehrerer Zertifikate sind technischer Natur, doch der Hauptgrund ist in der Regel der, dass bei unterschiedlichen Anwendungen auch unterschiedliche Sicherheitsstufen für das Zertifikat erforderlich sind. Das heißt, das Zertifikat ist mit unterschiedlichen Sicherungslevels an den Zertifikatantragsteller gebunden. Unterschiede können in den folgenden Punkten bestehen:

Daher ist es normalerweise am besten, Zertifikatsverwendungen mit gleichem Sicherheitslevel zu kombinieren. Der Zertifikatstyp zur Clientauthentifizierung, der in dieser Lösung verwendet wird, kann auch für andere Standardanwendungen, wie z. B. IPsec und die Computerauthentifizierung, verwendet werden. Wenn Sie Anforderungen für andere Zertifikatsverwendungen definiert haben, können Sie diese einbeziehen und die Zertifikate neu ausstellen. Die Zertifikate müssen dann zwangsweise erneuert werden, was per Zertifikatsvorlagendefinition in die Wege geleitet werden kann.

Die IAS-Serverzertifikate werden jedoch nur als Zertifikate mit mittlerem Sicherungslevel angesehen. Die Bedrohung, die von einem nicht autorisierten Serverzertifikat ausgeht, ist wesentlich größer als die Bedrohung durch ein unzulässiges Clientzertifikat. Aus diesem Grund ist es sinnvoll, Serverzertifikate mit mehr Sorgfalt zu behandeln. Microsoft empfiehlt daher, diese Zertifikate nicht für Anwendungen mit Standardsicherungslevel zu verwenden.

Zum Seitenanfang

Entwerfen der Zertifizierungstellen-Hierarchie

Zur Unterstützung der zertifikatbasierten Anwendungen Ihres Unternehmens müssen Sie ein Gefüge verknüpfter CAs schaffen, die je nach Bedarf für das Ausstellen, Überprüfen, Erneuern und Sperren von Zertifikaten verantwortlich sind. Die CAs wiederum sind zur Erfüllung solcher Aufgaben wie die Authentifizierung von Zertifikatantragstellern sowie die Veröffentlichung von Zertifikaten und Zertifikatssperrinformationen auf eine zugrunde liegende IT-Infrastruktur angewiesen.

Ziel beim Aufbau einer CA-Infrastruktur ist es, den Benutzern zuverlässige Dienste bereitzustellen, den Administratoren die Verwaltung möglichst einfach zu machen und für Flexibilität zu sorgen, um gegenwärtige und künftige Bedürfnisse zu erfüllen. Zugleich soll ein optimales Maß an Sicherheit für das Unternehmen gewährleistet werden.

Auswählen eines Vertrauensmodells

Als Erstes müssen Sie beim Entwerfen Ihrer CA-Infrastruktur festlegen, welches Vertrauensmodell Ihren Anforderungen am ehesten gerecht wird. Die beiden Grundmodelle sind "Hierarchisches Vertrauen" (Hierarchal Trust) und "Netzwerkvertrauen" (Network Trust). Elemente dieser beiden Modelle lassen sich aber auch in einem gemischten Modell (Hybrid Trust) kombinieren. Weitere Informationen zu diesen Modellen erhalten Sie im Kapitel "Designing a Public Key Infrastructure" des Windows Server 2003 Deployment Kit. Einen entsprechenden Link finden Sie im Abschnitt "Weitere Informationen".

Die in diesem Handbuch vorgestellte Lösung arbeitet mit einem hierarchischen Vertrauensmodell. Dies hat folgende Gründe:

Ein einzelner Stamm ist für die vorgeschlagene Lösung ausreichend.

Stamm eines Drittanbieters oder interner Stamm?

Als Vertrauensanker für die PKI kann ein interner Stamm verwendet werden, oder es können dafür die Dienste einer kommerziellen CA in Anspruch genommen werden. Die Verwendung des Stamms eines Drittanbieters bedeutet, dass die ausstellenden CAs von der kommerziellen Stamm-CA zertifiziert werden (normalerweise über einen oder mehrere Zwischen-CAs). Die Vertrauensanker aller ausgestellten Zertifikate liegen daher letztendlich bei dieser externen Stamm-CA.

Hinweis: Auch wenn dies in diesem Handbuch nicht explizit ausgeführt wird, können alle Zertifizierungsangelegenheiten in Ihrer Organisation an eine kommerzielle Zertifizierungsstelle ausgelagert werden. Dabei können Sie entweder einen verwalteten Vor-Ort-Service in Anspruch nehmen oder die Zertifikate direkt vom Zertifikatanbieter beziehen. Außer für kleine Organisationen oder für sehr eingeschränkte Zertifikatzwecke ist dies finanziell gesehen jedoch meist nicht sehr sinnvoll. Diese Entscheidung hat auch nichts mit der Frage zu tun, ob ein interner Stamm oder lieber ein Stamm eines Drittanbieters verwendet werden sollte, obwohl diese beiden Entscheidungen häufig durcheinander geworfen werden.

Die Verwendung eines kommerziellen Stamms für Ihre intern ausgestellten Zertifikate hat eine Reihe von Vorteilen:

Allerdings gibt es bei dieser Vorgehensweise auch einige Nachteile:

Falls Sie viele Zertifikate ausstellen müssen, denen Benutzer außerhalb Ihres Unternehmens vertrauen sollen, sollten Sie es trotz dieser Nachteile in Erwägung ziehen, zumindest einen Teil der PKI einem kommerziellen Stamm unterzuordnen (auch wenn das die Erstellung zweier getrennter Hierarchien erfordert).

Für den Großteil der im Unternehmen verwendeten Zertifikate wird bei dieser Lösung eine Hierarchie verwendet, die auf einer internen Stamm-CA basiert. Dies bringt folgende Vorteile mit sich:

Wenn Sie nicht in der Lage sind, die vertrauenswürdigen Stämme Ihrer Zertifikatsbenutzer problemlos zu verwalten, sollten Sie über die Verwendung eines externen Stamms nachdenken. In dieser Lösung wird die Verwendung von Zertifikaten von Drittanbietern und die Verwendung eines externen Stamms für die folgenden Dienste vorgeschlagen:

Definieren von Vertrauensstellungen externer Zertifikate

Im vorherigen Abschnitt war vom Vertrauen in die Zertifikate anderer Unternehmen die Rede. Diesbezüglich müssen Sie weitere Punkte bedenken, um festzulegen, wie das Vertrauen in Zertifikate in Ihrem Unternehmen gehandhabt werden soll. Das Wort "Vertrauen" bezieht sich in diesem Zusammenhang vor allem auf die folgenden drei wichtigen Bedingungen:

Bei Zertifikaten bezieht sich der erste Punkt auf die das Zertifikat ausstellende Stelle, der zweite Punkt auf die Verwendungszwecke und andere Zertifikatseigenschaften, die Sie möglicherweise überwachen möchten. Der Zeitraum schließlich wird entweder durch die Gültigkeitsdauer des Stamm-CA-Zertifikats definiert oder manchmal durch die Gültigkeitsdauer eines speziellen, wechselseitig vertrauenswürdigen Zertifikats, das Sie erstellen.

Die standardmäßigen Vertrauensstellungen, die Ihr Unternehmen mit Außenstehenden unterhält, müssen Sie wahrscheinlich ändern, wenn Sie eine neue Geschäftsbeziehung mit einem Unternehmen aufbauen oder eine Funktion für die Benutzer aktivieren möchten (zum Beispiel die Einstufung von Webzertifikaten als vertrauenswürdig, um sichere HTTP-Sitzungen zu ermöglichen). Im Folgenden finden Sie Beispiele für einige Aufgaben, die Sie möglicherweise ausführen möchten:

Es gibt mehrere Wege zur Erledigung dieser Aufgaben:

Bei dieser Lösung wird der Dienst zur Aktualisierung von Stammzertifikaten bei den CAs deaktiviert. Überlegen Sie sich, ob dieser Dienst auf den anderen Computern in Ihrer Organisation deaktiviert werden soll. Sie sollten außerdem darüber nachdenken, ob mithilfe der Gruppenrichtlinie die Standardstämme der Drittanbieter für alle Domänenbenutzer deaktiviert werden sollen. Genauere Informationen dazu finden Sie in Kapitel 7, "Implementieren der Infrastruktur öffentlicher Schlüssel".

Das Stamm-CA-Zertifikat der PKI in dieser Lösung wird durch Importieren in das Active Directory an die Clients verteilt. Weitere Informationen dazu finden Sie im nächsten Abschnitt.

Verteilen des Stammzertifizierungsstellen-Zertifikats

Stamm-CA-Zertifikate werden automatisch an Mitglieder der Active Directory-Gesamtstruktur verteilt. Durch den Import des CA-Zertifikats in den Container für Zertifizierungsstellen wird dieses Zertifikat bei den Mitgliedern (Computern und Benutzern) aller Domänen in der Gesamtstruktur in deren lokalen Speicher für vertrauenswürdige Stamm-CAs installiert. Diese Methode empfiehlt sich bei allen internen Stamm-CAs, bei denen ein strukturweiter Vertrauensumfang erforderlich ist.

In der Regel müssen Sie neben den internen Stämmen auch Stämme mit einem begrenzteren Vertrauensumfang verteilen. Weitere Informationen zu diesem Thema finden Sie im Abschnitt "Erweitern der Zertifizierungsstelleninfrastruktur" weiter unten in diesem Kapitel.

Um das Stamm-CA-Zertifikat an Benutzer und Computer auf anderen Plattformen oder außerhalb der Gesamtstruktur zu verteilen, müssen Sie das Zertifikat manuell installieren oder auf andere Art und Weise an sie verteilen.

Definieren der Rollen von Zertifizierungsstellen

Nachdem Sie das Vertrauensmodell definiert und eine Stamm-CA-Strategie ausgewählt haben, können Sie nun mit der Planung der restlichen CA-Infrastruktur fortfahren. Dazu müssen Sie die verschiedenen Rollen definieren, die die CAs in Ihrer Organisation übernehmen sollen. Sie können die CAs als Stamm-CAs oder als untergeordnete CAs konfigurieren. Untergeordnete CAs wiederum können ausstellende CAs oder Zwischen-CAs (insofern, als dass sie als Zwischenschritt zwischen ausstellenden CAs und Stamm-CAs fungieren) sein.

Stamm-CA

Die Rolle der Stamm-CA ist in jedem Unternehmen sehr wichtig. Dieser Rolle vertrauen alle Benutzer und Geräte in Ihrer Organisation ausdrücklich. Viele Sicherheitsentscheidungen (z.  B. bei der Frage, ob sich jemand anmelden darf, ob einer E-Mail vertraut werden soll oder ob ein Wertpapiergeschäft in Höhe von 10 Mio. € zugelassen werden soll) sind letztlich abhängig von der Sicherheit dieses Stamms und dem privaten Schlüssel, der die Identität preisgibt. Da so viele Vorgänge vom Stamm abhängen, kann das Ändern eines Stammschlüssels und -zertifikats ein sehr komplexer und fehleranfälliger Vorgang sein, der über einen längeren Zeitraum zum zwischenzeitlichen Ausfall von Diensten für Anwendungen und Benutzer führen kann.

Daher wird dringend empfohlen, den privaten Schlüssel der Stamm-CA möglichst gut zu schützen. Eine der besten Möglichkeiten hierzu besteht darin, die CA vom Netzwerk zu trennen, so dass der Zugriff auf die CA nur einem sehr begrenzten Personenkreis möglich ist. (Diese Schutzmaßnahme sollte mit entsprechenden Maßnahmen zur Einschränkung des physischen Zugriffs auf den Server kombiniert werden.) Noch besser lassen sich die Schlüssel einer CA mit einer speziellen Kryptografiehardware (Hardware Security Module, HSM) schützen. Dieses bietet zusätzliche Schlüsselsicherheit für Offline-CAs sowie ein deutlich höheres Maß an Sicherheit für Online-CAs.

Die in diesem Handbuch beschriebene Lösung verwendet eine Offline-Stamm-CA.

Wichtig: Für Ihre Stamm-CA sollten Sie den Einsatz einer HSM in Betracht ziehen, um die CA-Schlüssel besser zu schützen. Sie können HSMs zwar auch nach dem Installieren Ihrer CA hinzufügen, es ist jedoch viel einfacher und sicherer, dieses gleich am Anfang zu tun. Wenn Sie später eine HSM hinzufügen, sollten Sie den Schlüssel Ihrer CA erneuern, auch wenn viele Hersteller den Import des bestehenden Schlüssels erlauben.

Zwischenzertifizierungsstellen und ausstellende Zertifizierungsstellen

Wenn Sie die Stamm-CA offline schalten, eignet sich diese nicht zum täglichen Ausstellen von Zertifikaten. Um CAs zu erstellen, mit deren Hilfe Sie Zertifikate für den täglichen Gebrauch ausstellen können, zertifiziert die Stamm-CA untergeordnete CAs, die Zertifikate in ihrem Auftrag ausstellen. Dadurch kann eine untergeordnete CA die Glaubwürdigkeit der Stamm-CA erben, ohne dass deren Schlüssel Sicherheitsrisiken ausgesetzt wird.

Dieser Vorgang lässt sich noch weiter führen. Statt Zertifikate direkt auszustellen, zertifiziert die untergeordnete CA eine weitere Ebene mit CAs, die Zertifikate an Endentitäten (Benutzer und Computer) ausstellen. Dies sorgt nicht nur für eine weitere Sicherheitsstufe für den Stamm-CA-Schlüssel, sondern ermöglicht es Ihnen auch, das Risiko auf die untergeordneten CA-Zweige zu verteilen. Eine Zwischen-CA kann zum Beispiel interne ausstellende CAs zertifizieren, während eine andere Zwischen-CA CAs zertifiziert, die externe Zertifikate ausstellen. Diese Methode hat die folgenden Vorteile:

Zusätzliche Ebenen mit Zwischen-CAs machen die PKI zwar insgesamt sicherer, doch das wird mit zusätzlicher Komplexität, zusätzlicher Hard- und Software und höheren Verwaltungskosten erkauft (die in der Regel viel höher sind als die Kosten für Hardware oder Softwarelizenzen). Bei vielen Anwendungen rechtfertigen die Sicherheitsanforderungen keine dreistufige Hierarchie. Das gilt insbesondere dann, wenn die CA-Schlüssel mit HSMs geschützt werden.

Die in diesem Handbuch beschriebene Lösung verwendet eine zweistufige Hierarchie. Der Lösungsentwurf besitzt eine akzeptable Ausgewogenheit zwischen guter Sicherheit und Erschwinglichkeit, gleichzeitig ist er auch flexibel genug für zukünftige Zertifikatsanwendungen (siehe dazu die Informationen im Abschnitt "Definieren der Zertifikatsanforderungen" weiter oben in diesem Kapitel).

Hinweis: Unter Umständen gibt es gesetzliche Bestimmungen, wonach dreistufige Hierarchien zu verwenden sind, auf die aber in diesem Handbuch nicht eingegangen wird. Diese Bestimmungen haben selbstverständlich Priorität gegenüber anderen Überlegungen.

Vorgeschlagene Zertifizierungsstellenhierarchie

Die folgende Abbildung veranschaulicht die vorgeschlagene Hierarchie. Die aktuelle Implementierung umfasst die Stamm-CA und eine ausstellende CA. Die ausstellende CA wird hauptsächlich (mitunter als "technisch" bezeichnete) Zertifikate mit Standardsicherungslevel für Computer oder Benutzer und höherwertige Zertifikate für Computer ausstellen.

Abbildung 4.2: Zertifizierungsstellenhierarchie
Bild in voller Größe anzeigen

Dieser Entwurf ermöglicht Ihnen bei relativ geringen Hardware-, Software- und Verwaltungskosten die Bereitstellung einer voll funktionalen PKI, die eine sichere WLAN-Authentifizierung (802.1X) unterstützt.

Hinweis: Sie können diesen einfachen Infrastrukturentwurf auf unterschiedliche Weise erweitern und ihn so an andere Anforderungen anpassen. Entsprechende Hinweise finden Sie im Abschnitt "Erweitern der Zertifizierungsstelleninfrastruktur".

Die ausstellende CA wird zunächst zum Ausstellen der folgenden Zertifikatstypen konfiguriert (in der Grafik oben sind diese fett umrandet dargestellt):

Bei den ersten beiden handelt es sich um Standardzertifikate. Sie werden auf der Basis der Domänenanmeldeinformationen des Benutzers oder Computers automatisch ausgestellt. Der Besitz solcher Zertifikate bedeutet noch keine stärkere Bindung an den Inhaber als der Besitz eines gültigen Benutzernamens und Kennworts für die Domäne. Dennoch ist es wichtig zu beachten, dass es bei Verwendung von Zertifikaten statt Domänennamen und -kennwörtern sicherheitsmäßig und technisch gesehen Vorteile gibt.

Die IAS-Server-Authentifizierung ist als Zertifikat mit mittlerem Sicherungslevel eingestuft, da IAS-Server eine hohe Sicherheitsfunktion ausüben. Bei der Ausstellung eines Zertifikats dieses Typs wird normalerweise die Gültigkeit der Anforderung zusätzlich geprüft, zudem ist die Genehmigung eines Certificate Managers erforderlich.

Hinweis: Im Kapitel weiter hinten, das sich mit dem Aufbau beschäftigt und die Erstellung dieses Zertifikatstyps beschreibt, wird die Anforderung der Genehmigung durch einen Certificate Manager deaktiviert gelassen. Das erlaubt es den IAS-Servern, ablaufende Zertifikate automatisch zu erneuern, und verhindert, dass der Dienst bei Ablauf des Zertifikats deaktiviert wird. Sofern die entsprechenden Prozesse vorhanden sind, um die Zertifikatsanforderungen angemessen zu überprüfen und zu genehmigen, sollten Sie möglicherweise die Genehmigung durch einen Certificate Manager erforderlich machen.

Hardware- und Softwareanforderungen für Zertifizierungsstellen

In diesem Abschnitt werden die Hardware- und Softwareanforderungen für die CAs behandelt.

Stamm-CA

Die Hardwareanforderungen für eine Stamm-CA sind minimal. Der Computer muss lediglich die für Windows Server 2003 erforderlichen Mindestanforderungen erfüllen. Die Stamm-CA-Hardware muss sich vor allem durch langfristige Zuverlässigkeit und Wartungsfreundlichkeit auszeichnen. Die Stamm-CA residiert typischerweise auf einem Computer mit langer Lebensdauer, der aber die meiste Zeit ausgeschaltet ist. Wenn der Computer allerdings eingeschaltet wird, soll er zuverlässig starten. Um auf mögliche Hardwareausfälle reagieren zu können, sollten die Komponenten problemlos ausgetauscht werden können und möglichst noch Jahre nach dem Auslaufen des Modells verfügbar sein.

Vor diesem Hintergrund empfiehlt Microsoft Folgendes:

Die zusätzlichen Funktionen der Enterprise Edition von Windows Server 2003 sind für die Stamm-CA nicht erforderlich. Aus diesem Grund wird in der in diesem Handbuch beschriebenen Lösung die Windows Server 2003 Standard Edition verwendet.

Ausstellende Zertifizierungsstelle

Die Leistungsanforderungen für die ausstellende CA sind relativ gering, da sie normalerweise nur wenige Aufgaben erfüllt. Selbst bei hoher Auslastung, so legen Leistungsmessungen nahe, liegt bei einer Unternehmens-CA der Engpass normalerweise bei der Zusammenarbeit mit Active Directory (nicht bei der CA selbst). Daher sind die Leistungsanforderungen an die Hardware eher gering. Wie bei der Stamm-CA sind Zuverlässigkeit und Wartungsfreundlichkeit bei der Wahl der Hardware die entscheidenden Faktoren.

Bei den Zertifikatsdiensten wird die gleiche Datenbanktechnologie verwendet wie bei Active Directory, das bedeutet, dass viele der geltenden Leistungsrichtlinien identisch sind. Eine gute Richtschnur für die meisten Unternehmen ist, die gleiche Hardwarespezifikation wie bei Active Directory-Domänencontrollern zu verwenden.

Weitere Informationen zur Leistung von CAs erhalten Sie im Abschnitt "CA Capacity, Performance, and Scalability" im Kapitel "Designing a Public Key Infrastructure" des Windows Server 2003 Deployment Guide. Einen Link zu diesem Abschnitt finden Sie unter "Weitere Informationen" am Ende dieses Kapitels.

In Kapitel 7, "Implementieren der Infrastruktur öffentlicher Schlüssel", finden Sie einen Vorschlag für ein Hardwareprofil. Neben den oben genannten Richtlinien für die Stamm-CA empfiehlt Microsoft, bei der Auswahl der Serverhardware für die ausstellende CA Folgendes zu berücksichtigen:

Im Gegensatz zur Stamm-CA benötigt die ausstellende CA auch die zusätzlichen Funktionen der Windows Server 2003 Enterprise Edition, damit bearbeitbare Zertifikatsvorlagen und die automatische Registrierung von Benutzerzertifikaten unterstützt werden.

Ausfallsicherheit durch mehrere ausstellende Zertifizierungsstellen

In diesem Abschnitt werden die technischen Gründe erläutert, die die Installation mehrerer ausstellender CAs nahe legen. Für die Registrierung verschiedener Zertifikatstypen durch unterschiedliche ausstellende CAs wird es vermutlich auch sicherheitstechnische und firmenpolitische Gründe geben. Diese Gründe werden in einem späteren Abschnitt dieses Kapitels erläutert.

Eine einzelne ausstellende CA ohne weitere Hardwareforderungen reicht aus, um die oben beschriebenen Zertifikatstypen für Zehntausende von Clients auszustellen. Es ist daher unwahrscheinlich, dass Sie rein aus Leistungsgründen mehrere ausstellende CAs benötigen. Sie sollten sich allerdings überlegen, ob Sie aufgrund der Verfügbarkeitsanforderungen für die ausstellenden CAs mehrere CAs zur Registrierung derselben Zertifikatstypen bereitstellen müssen.

Bei einer CA bestehen nicht die gleichen Verfügbarkeitsprobleme wie bei vielen anderen Diensten. Die Clients müssen die CA nicht kontaktieren, um ein Zertifikat zu verwenden oder zu überprüfen. Die Clients nehmen nur dann direkt Kontakt zu der CA auf, wenn die CA Folgendes tun soll:

Die jeweiligen Verfügbarkeitsanforderungen sind in der folgenden Tabelle aufgeführt.

Tabelle 4.8: Verfügbarkeitsanforderungen für CA-Dienste

Hinweis: In der Tabelle oben beziehen sich die Zeitdauer für die Wiederherstellung einer CA und die CA-Verfügbarkeit auf alles, was die Fähigkeit der CA beeinträchtigt, den Endbenutzern Dienste bereitzustellen. Das ist nicht allein auf Serverausfälle beschränkt. Der Ausfall von Netzwerkverbindungen zwischen Standorten ist zum Beispiel eine viel wahrscheinlichere Ursache für den Ausfall eines Dienstes. Bei der Entscheidung über das Maß der erforderlichen Dienstverfügbarkeit sollten Sie alle Faktoren berücksichtigen, die sich auf die Bereitstellung von Diensten auswirken können.

Sofern Sie die Sicherung und Wiederherstellung der CAs vernünftig handhaben, werden nur die Registrierungs- und einige Erneuerungsanforderungen die Entscheidung beeinflussen, ob zur Gewährleistung von Dienstausfallsicherheit mehrere CAs verwendet werden sollen. Sie müssen die Kosten durch den Ausfall dieser Dienste und die Kosten für die Installation und Verwaltung zusätzlicher CAs gegeneinander abwägen.

Neben einer besseren Verfügbarkeit hat die Verwendung mehrerer ausstellender CAs auch den Vorteil, dass die Zertifikatausstellung schneller erfolgt und die Größe der CRLs halbiert wird. Diese Faktoren sind jedoch für die in diesem Handbuch beschriebene Lösung nicht von Bedeutung. Bei dieser Lösung wird die Ausfallsicherheit gewährleistet, indem die CAs sorgfältig verwaltet und entsprechende Verfahren zur Sicherung und Wiederherstellung eingebaut werden. Für diese Lösung ist daher nur eine einzige ausstellende CA erforderlich.

Schützen der Zertifizierungsstellenschlüssel mit HSMs

Eine wichtige Verbesserung, mit der Sie die Sicherheit der in diesem Handbuch vorgestellten Grundlösung erhöhen können, bestünde darin, HSMs für den Schutz der privaten Schlüssel aller CAs einzusetzen. Dieses Verfahren ist zwar in der Regel kostenintensiv die HSMs können leicht mehr kosten als der CA-Server , doch der Zugewinn an Sicherheit für Ihre Umgebung ist erheblich. Durch diese Maßnahme können Sie den Zugriff auf die CA-Schlüsselvorgänge ausschließlich auf autorisierte Benutzer beschränken. Sicherheitsrelevante Vorgänge (z. B. das Exportieren und Sichern der CA-Schlüssel) sind typischerweise durch mehrere Smartcards geschützt. Dies ist sicherer, als wenn man sich nur auf softwarebasierte Schlüssel verlässt, die von jedem Mitglied der lokalen Gruppen "Administrators" bzw. "Backup Operators" aus der CA kopiert werden können.

Abgesehen von den enormen Sicherheitsvorteilen können HSMs auch die CA-Vorgänge beschleunigen, indem sie die Arbeitslast von der CPU auf dedizierte Prozessoren zur Beschleunigung der kryptografischen Prozesse verlagern.

Zertifizierungsstellensicherheit

In diesem Abschnitt geht es um die Absicherung der CAs (einschließlich der Betriebssystem- und physischen Absicherung), um die Sicherheitsüberprüfung und –überwachung sowie das Delegieren von CA-Verwaltungsaufgaben mithilfe von Rollen.

Betriebssystemsicherheit

Die CA wird mithilfe von Windows-Sicherheitsrichtlinien gesichert. Die Einstellungen basieren auf der Serverrolle "Zertifizierungsstelle" im Windows Server 2003-Sicherheitshandbuch.

Weitere Informationen zu den in dieser Rolle verwendeten Einstellungen finden Sie in Kapitel 7, "Implementieren der Infrastruktur öffentlicher Schlüssel".

Die Sicherheitseinstellungen für die Stamm-CA werden direkt mithilfe der Sicherheitsvorlagen übernommen, die Einstellungen für die ausstellende CA dagegen mit "Gruppenrichtlinie".

Physische Absicherung

Die physische Absicherung der CA-Server ist von größter Bedeutung. Solange Sie den physischen Zugriff auf die Server nicht kontrollieren können, bleiben alle Maßnahmen zum Schutz des Netzwerks oder Betriebssystems wirkungslos.

Die Stamm-CA sollte an einem Standort residieren, an dem der Zugriff auf den Server einer strikten Kontrolle unterliegt. Auf die CA muss nur äußerst selten zugegriffen werden (zwei- bis dreimal pro Jahr), und der Server muss auch nur zu diesen Zeitpunkten eingeschaltet werden. Das heißt, dass Sie den Server in einem sicheren Raum aufstellen können, der nicht über die herkömmliche Einrichtung eines Serverraums verfügen muss. (So benötigt der Raum zum Beispiel keine Netzwerkanschlüsse, keine ausgeklügelten Serverracks und keine spezielle Energieverwaltung/Temperaturregelung.)

Die ausstellende CA sollte ebenfalls an einem Ort residieren, an dem der physische Zugriff streng kontrolliert wird. Die physische Absicherung ist wichtig, denn ein Angreifer, der physischen Zugriff auf ein Computersystem hat, kann dieses (über die über das Netzwerk möglichen Angriffe hinaus) auf vielfältige Weise manipulieren. Da dieser Server durchgängig online sein muss, müssen Sie ihn in einem für den Serverbetrieb standardmäßig ausgestatteten Raum (mit Temperaturregelung, Energieverwaltung, Luftfilterung und Feuerlöscheinrichtungen) aufstellen.

Sofern möglich, wählen Sie für beide Server Standorte, die so wenig wie möglich durch Feuer, Überflutung u. Ä. gefährdet sind.

Gleichermaßen wichtig ist es, den physischen Zugriff auf Sicherungskopien, Schlüsselmaterial und andere Konfigurationsdaten zu kontrollieren und deren physischen Schutz zu gewährleisten. Bewahren Sie diese Informationen an einem anderen Ort als die Server auf, damit für den Fall, dass der gesamte Standort unzugänglich wird (z. B. nach einer Naturkatastrophe oder einem Brand), die CAs wiederhergestellt werden können.

Sicherheitsverwaltung der Zertifizierungsstellen

Eine Zertifikatsinfrastruktur ist potenziell ein sehr wertvolles Anlagegut. Wie hoch dessen Wert ist, hängt davon ab, wofür Ihre Organisation die Zertifikate verwendet nicht nur in der Gegenwart, sondern auch in den kommenden Jahren. Aus diesem Grunde sollten Sie bei der Installation, Konfiguration und Verwaltung der CAs strengere Sicherheits- und Prüfmaßnahmen ergreifen als beim Aufbau anderer IT-Infrastrukturen. Diese Maßnahmen sollten mindestens den Maßnahmen für einen Domänencontroller entsprechen. In einigen Fällen werden Sie sogar feststellen, dass Sie eine noch höhere Sicherheit benötigen.

Welches Vertrauen Sie in eine CA setzen, richtet sich danach, wie sehr Sie in deren sichere Einrichtung und Verwaltung vertrauen. Wenn Sie nicht garantieren können, dass der private Schlüssel der CA nicht heimlich kopiert wurde, können Sie nie wirklich sicher sein, ob ein vermeintlich von dieser CA ausgestelltes Zertifikat nicht doch eine Fälschung ist.

Dieser Sicherungs- oder Vertrauenslevel lässt sich nicht so ohne Weiteres rückwirkend erhöhen; vielmehr müssen Sie von vornherein Vertrauen in alle Interaktionen mit der CA schaffen. So wird z. B. Ihre Organisation der Tatsache, dass der private Schlüssel der CA nicht manipuliert wurde, wesentlich mehr Vertrauen schenken, wenn Sie durch entsprechende Überwachungsaufzeichnungen oder durch andere Beweise belegen können, dass alle Zugriffe auf die CA legitim gewesen sind. So können z. B. sämtliche administrativen Vorgänge an den CAs im Beisein einer Person erfolgen oder auf Video aufgezeichnet werden. Bei Offline-CAs verringert sich die Möglichkeit der Manipulation schon dadurch deutlich, dass sie zu keinem Zeitpunkt eine Verbindung zum Netzwerk herstellen.

Die Notwendigkeit eines solch hohen Sicherungslevels zeigt sich möglicherweise besonders dann, wenn Ihre Organisation in einen Rechtsstreit über die Gültigkeit eines von ihr ausgestellten Zertifikats verwickelt wird. Wenn Sie in solchen Fällen belegen können, dass keine Möglichkeit zur Manipulation der CAs bestand, ist die Chance auf einen erfolgreichen Ausgang des Rechtsstreits viel größer. Eine vollständige Erörterung dieses Themas würde den Rahmen dieses Handbuchs sprengen. Zur Vertiefung dieses Themas sollten Sie sich an Ihre Prüfer und Rechtsberater wenden.

Nachstehend folgen einige Beispiele für Schritte, die Sie unternehmen können, um den Sicherungslevel Ihrer CAs beträchtlich zu steigern:

Derartige Maßnahmen sind vor allem beim Server der Stamm-CA wichtig. Die ausstellende CA kann je nach der Art der auszustellenden Zertifikate einen viel niedrigeren Sicherungslevel aufweisen. Wenn die CA beispielsweise keine hochwertigen Zertifikate ausstellt (sondern nur Standardzertifikate, wie z. B. Computer- und Benutzernetzwerkauthentifizierung), reichen bei dieser CA Sicherheitsmaßnahmen aus, wie sie auch bei einem Domänencontroller durchgeführt werden.

Sofern die Stamm-CA über einen hohen Sicherungslevel verfügt, haben Sie die Möglichkeit, eine ausstellende CA mit höherem Sicherungslevel hinzuzufügen, um später höherwertige Zertifikate auszustellen. Es ist möglich, neben der vorhandenen CA mit Standardsicherungslevel auch CAs mit einem hohen Sicherungslevel ("Hohe Zusicherung") zu unterhalten. Wenn die Stamm-CA jedoch in einer Umgebung mit relativ niedriger Sicherheit installiert und konfiguriert wurde und Sie später hochwertige Zertifikate ausstellen möchten, müssen Sie wahrscheinlich die Stamm-CA neu installieren oder eine neue Stamm-CA erstellen.

Sicherheitsüberwachung und -prüfung

Die Prüfung von Betriebssystem und Zertifikatsdiensten wird bei allen CAs durchgeführt. Damit diese wirksam ist, müssen Sie die Prüfung und alle verdächtigen Elemente überwachen. Eine Erläuterung der Bedeutung der Überwachungsereigniseinträge für Zertifikatsdienste finden Sie in Kapitel 11, "Verwalten der Infrastruktur öffentlicher Schlüssel".

Verwaltungsrollen

Die Delegierung von administrativen Rollen lässt sich gut mithilfe von Zertifikatsdiensten steuern. Diese Möglichkeit wird in dieser Lösung genutzt, um Ihnen bei der Verwaltung der PKI ein hohes Maß an Flexibilität zu bieten. Alle durch die Zertifikatsdienste definierten administrativen Hauptrollen wurden mithilfe einer Domänensicherheitsgruppe oder, bei Offline-CAs, mithilfe einer lokalen Sicherheitsgruppe implementiert. Darüber hinaus wurden in dieser Lösung zwei weitere Rollen und Sicherheitsgruppen definiert, um die Delegierung administrativer Aufgaben bezüglich der PKI-Komponenten von Active Directory zu vereinfachen.

Beachten Sie, dass nicht zwangsläufig eine Eins-zu-Eins-Zuordnung zwischen diesen Rollen und den einzelnen IT-Mitarbeitern in Ihrer Organisation bestehen muss. In den meisten Organisationen werden viele der verfügbaren Rollen von ein und derselben Person übernommen. Dies können Sie einfach implementieren, indem Sie die betreffende Person mehreren oder allen Sicherheitsgruppen hinzufügen, die in der folgenden Tabelle aufgeführt sind. Wenn in Ihrer Organisation dagegen eine komplexere Aufteilung der administrativen Aufgaben vorhanden ist, lässt sich auch dies entsprechend implementieren.

Die implementierten Rollen und ihre Zuordnung zu den Sicherheitsgruppen (sofern implementiert) sind in der folgenden Tabelle aufgeführt.

Tabelle 4.9: Hauptrollen für Zertifikatsdienste

Diese Sicherheitsgruppen werden als universelle Domänengruppen implementiert und in der ausstellenden CA und im Verzeichnis übernommen. Bei der Stamm-CA werden entsprechende Gruppen als lokale Gruppen implementiert (wenngleich es bei einer Offline-CA keine Entsprechung für die Enterprise PKI Admins und Enterprise PKI Publishers gibt). Bei dieser Lösung wird davon ausgegangen, dass für alle CAs im Unternehmen die gleichen Sicherheitsgruppen verwendet werden. Trifft das in Ihrem Unternehmen nicht zu, sollten Sie bei allen Rollen mit CA-weitem Geltungsbereich für jede CA eigene Gruppen implementieren. (Diese müssen natürlich entsprechend umbenannt werden, zum Beispiel: CA Admins Ausstellende CA 1.)

Da Registrierungsautoritäten (oder Enrollment Officers) sowie die Schlüsselarchivierung und –wiederherstellung bei dieser Lösung nicht implementiert wurden, weisen diese Rollen keine definierte Sicherheitsgruppen auf.

Es ist möglich, die Trennung der CA-Rollen bei einer CA zu erzwingen. Wenn diese Trennung aktiviert ist, wird allen Benutzern, die mehreren Rollengruppen angehören, der Zugriff auf die Rechte aller Rollengruppen verweigert. Die Rollentrennung ist nicht in diese Lösung implementiert.

Active Directory-Integration

Sie können CAs in zwei Modi installieren im Unternehmensmodus ("Active Directory-integriert") oder im "eigenständigen Modus". Die Hauptunterschiede sind folgende: Unternehmens-CAs sind zum Speichern von Konfigurationsdaten auf Active Directory angewiesen, können Active Directory als Registrierungsautorität nutzen und ausgestellte Zertifikate automatisch im Verzeichnis veröffentlichen. CAs im eigenständigen Modus können Zertifikate und CRLs im Verzeichnis veröffentlichen, sind jedoch nicht auf das Vorhandensein von Active Directory angewiesen.

Genauere Informationen dazu finden Sie in den Verweisen im Abschnitt "Weitere Informationen" am Ende dieses Kapitels.

Da die Stamm-CA offline ist, kann sie nur im eigenständigen Modus konfiguriert werden. Dies gilt auch für Offline-Zwischen-CAs, sofern Sie beabsichtigen, solche CAs in Ihrer Umgebung bereitzustellen.

Die ausstellende CA wird aus folgenden Gründen als Unternehmens-CA konfiguriert:

Installieren von CAs in Ihren Domänen

Wenn Ihre Organisation über eine Gesamtstruktur mit mehreren Domänen (oder sogar über mehrere Gesamtstrukturen) verfügt, müssen Sie entscheiden, in welchen Domänen die CAs installiert werden sollen. Zu den Faktoren für Ihre Entscheidung können zum Beispiel die Notwendigkeit, die Kontrolle an verschiedene Domänenmanager zu delegieren, oder unterschiedliche gesetzliche Vorgaben für die verschiedenen Teilen Ihrer Organisation gehören, die sich auf die Bereitstellung von Zertifikaten auswirken.

Die gängigste Vorgehensweise besteht darin, die CAs in der Stammdomäne der Gesamtstruktur oder in einer speziellen Verwaltungsdomäne zu installieren. Sie sollten sie in einer Domäne installieren, die über einen langen Zeitraum stabil bleibt. (Es ist nicht möglich, nach dem Installieren den Namen einer CA, die Domänenzugehörigkeit und den DNS-Domänennamen zu ändern.) Sie sollten daher die CAs nicht in Domänen installieren, in denen Sie die Sicherheit oder Integrität des Computerkontos nicht garantieren können. Auch wenn dadurch die zentralisierte Verwaltung einfacher wird, müssen Sie Ihre CAs nicht alle in derselben Domäne installieren.

In dieser Lösung werden die CA-Serverkonten (nur ausstellende Unternehmens-CAs) in der Stammdomäne der Gesamtstruktur oder, falls es sich um eine einzelne Domänengesamtstruktur handelt, in dieser Domäne installiert.

Zuordnen der Zertifikatsverwendungserklärungen zu CAs

Wenn Sie die Veröffentlichung ihrer Zertifikatsverwendungserklärung (CPS) planen, müssen Sie deren Geltungsbereich festlegen. Sie können eine CPS für eine ganze CA-Hierarchie bzw. einen Teil davon oder eine CPS pro CA erstellen.

Die letztgenannte Option zeichnet sich durch die größte Flexibilität aus, bedeutet aber auch einen Mehraufwand, da mehrere CPS verwaltet werden müssen. Übliche Praxis ist es, für jede CA bzw. für jede Gruppe von CAs mit gemeinsamen Zertifikatsrichtlinien, Inhabertypen und Sicherheitsstufen eine eigene CPS zu erstellen. Wo diese Punkte sich von CA zu CA beträchtlich voneinander unterscheiden, müssen Sie möglicherweise mehrere CPS verwenden. Wenn Sie zwecks höherer Ausfallsicherheit oder Leistung mehrere identische CAs bereitstellen, sollten diese natürlich auch identische CPS aufweisen.

Wie oben erläutert, ist es durchaus legitim, eine CPS zu erstellen, sie aber nicht zu veröffentlichen. Wenn Sie zum Beispiel das Gefühl haben, dass die CPS Betriebs- und Sicherheitsinformationen interner Natur enthält, sollten Sie sie besser nicht extern veröffentlichen. Ferner können Sie eine Kurzversion Ihrer CPS veröffentlichen, in der die wichtigen Betriebsrichtlinien der CA aufgelistet werden, aber keine internen Betriebsdetails genannt werden.

Wenn Sie sich dazu entschließen, Ihre CPS zu veröffentlichen, und deren Standort dann im CA-Zertifikat bekannt geben möchten, müssen Sie aus dem offiziellen OID-Namespace, der Ihrer Organisation von der ISO (International Standards Organization) zugewiesen wurde, eine Objektkennung (Object Identifier, OID) für Ihre Zertifikatsrichtlinie beziehen. Ihre Zertifikatsrichtlinie ist organisationsspezifisch, d. h., es wird also eine global eindeutige OID benötigt, um sie zweifelsfrei identifizieren zu können.

Diese Zertifikatsrichtlinien-OID wird als Zertifikatserweiterung in allen Zertifikaten Ihrer Organisation verschlüsselt. Eine Zertifikatserweiterung ist wie eine Art Zertifikatsdatenfeld. Diese Erweiterung enthält auch einen URL, der auf die CPS für die CA weist, die das jeweilige Zertifikat ausgestellt hat.

Ebenfalls gängige Praxis ist es, eine Benutzeranmerkung einzufügen, die grob über Zweck und Herkunft des Zertifikats (diese ist aber auf 200 Zeichen begrenzt und deshalb natürlich keine Alternative zu einem separaten CPS-Dokument) Auskunft gibt.

Genaue Informationen dazu, wie Zertifikatsrichtlinien-OIDs und CPS-URLs in einem Zertifikat verschlüsselt werden, erhalten Sie im RFC 3280, Internet X.509 Public Key Infrastructure Certificate and CRL Profile. Einen entsprechenden Link finden Sie im Abschnitt "Weitere Informationen" am Ende dieses Kapitels.

Nachdem Sie Ihre CPS-OID beschafft und entschieden haben, unter welchem URL die Zertifikatsrichtlinie veröffentlicht werden soll, können Sie diese Informationen in Ihre CA-Zertifikate einfügen. Anweisungen zur Vorgehensweise finden Sie in Kapitel 7, "Implementieren der Infrastruktur öffentlicher Schlüssel".

Unterstützende IT-Infrastruktur

Die PKI in dieser Lösung ist darauf angewiesen, dass andere Infrastrukturdienste korrekt funktionieren. In der folgenden Grafik werden die wichtigsten Dienste Active Directory und IIS und deren Interaktion mit den CAs und Zertifikatsclients dargestellt.

Abbildung 4.3: CA-Interaktion mit IT-Infrastruktur
Bild in voller Größe anzeigen

Die Überwachungs-, Warnungs- und Verwaltungsinfrastruktur ist zwar in der Grafik oben nicht mit dargestellt, aber auch diese Komponenten sind für den erfolgreichen Betrieb der Zertifikatsdienste von großer Bedeutung. Eine genauere Beschreibung dieser Infrastruktur finden Sie in Kapitel 11, "Verwalten der Infrastruktur öffentlicher Schlüssel". In den folgenden Abschnitten werden die Dienste beschrieben, die Active Directory und IIS für die PKI bereitstellen.

Active Directory

Wie im Abschnitt "Active Directory-Integration" weiter oben bereits erläutert, stellt Active Directory eine Reihe unterschiedlicher Dienste bereit, die für die PKI sehr wichtig sind. Dazu gehören das Veröffentlichen und Registrieren von Zertifikaten, das Zuordnen von Zertifikaten zu Konten sowie das Speichern von Vertrauensstellungs- und Konfigurationsinformationen.

All diese Dienste werden Unternehmens-CAs automatisch bereitgestellt. Eigenständige Online-CAs können ebenfalls einige dieser Dienste nutzen. CAs, die offline sind, können hingegen zum Speichern und Abrufen von Daten nicht direkt mit Active Directory interagieren.

In dieser Lösung wird das CA-Zertifikat der Offline-Stamm-CA im vertrauenswürdigen Active Directory-Stammspeicher veröffentlicht. Auf diese Weise wird das Stamm-CA-Zertifikat an den vertrauenswürdigen Stammspeicher aller Active Directory-Clients innerhalb der Gesamtstruktur verteilt.

Die Stamm-CA könnte das Active Directory auch für die folgenden Veröffentlichungsdienste verwenden (was aber in dieser Lösung nicht passiert):

Die ausstellende CA verwendet für alle im Abschnitt "Active Directory-Integration" beschriebenen Dienste Active Directory.

Verwenden von Active Directory für Nicht-Active Directory-Clients

Bei der Unterstützung von PKI-Clients, die einer anderen, nicht vertrauenswürdigen Active Directory-Gesamtstruktur oder gar keiner Active Directory-Gesamtstruktur angehören, sind einige Punkte zu beachten.

Wenn Sie derartigen externen Clients erlauben möchten, CA-Zertifikate und CRLs mithilfe des Lightweight Directory Access Protocol (LDAP) abzurufen, müssen Sie Folgendes berücksichtigen:

Überlegungen zu Internetclients

Auch bei der CDP- und AIA-Konfiguration für Clients außerhalb Ihrer Organisation (wie z. B. Internetclients) sind einige wichtige Aspekte zu berücksichtigen. Genauere Informationen dazu finden Sie im Abschnitt "Konfigurieren von CDP- und AIA-Pfaden" weiter unten in diesem Kapitel.

Wenn Sie Internetclients die Zertifikatssuche bereitstellen müssen, um zum Beispiel die E-Mail-Zertifikatssuche zu unterstützen, müssen Sie möglicherweise ein eigenes LDAP-Verzeichnis für die Internetclients erstellen. Aufgrund des erhöhten Sicherheitsrisikos empfiehlt Microsoft eindringlich, das im vorherigen Abschnitt beschriebene Verfahren nicht zu verwenden, um anonyme LDAP-Abfragen Ihrer internen Active Directory-Gesamtstruktur zuzulassen. Erstellen Sie stattdessen eine eigene Active Directory-Gesamtstruktur, und replizieren Sie die Daten aus der internen Gesamtstruktur. Verwenden Sie dazu das LDIFDE-Tool, ein Metaverzeichnisprogramm (wie etwa Microsoft Metadirectory Services, MMS) oder ein anderes Programm zur Verzeichnissynchronisierung.

Internetinformationsdienste

Die Internetinformationsdienste (IIS) übernehmen in der PKI dieses Entwurfs zwei Aufgaben:

Veröffentlichen von CA-Informationen mithilfe von IIS

In dieser Lösung werden CDP- und AIA-Informationen für die Stamm-CAs und die ausstellenden CAs auf einem Webserver veröffentlicht. Die HTTP-Veröffentlichung erlaubt es der größtmöglichen Zahl von Clients, die erforderlichen Informationen abzurufen.

Die Installation von IIS in der ausstellenden CA für diesen Zweck ist zwar nicht unüblich, aber möglicherweise nicht immer die beste Verfahrensweise. Wenn ein anderer IIS-Server für die Veröffentlichung der CRL- und CA-Informationen eingesetzt werden kann, sollten Sie diesen verwenden. Nach Möglichkeit sollten Sie die Zugriffsoptionen der Benutzer auf die CAs einschränken, denn jedes zusätzliche Protokoll und jeder weitere Dienst in der CA bietet einem Angreifer eine weitere Möglichkeit, auf den Server zuzugreifen. Der Einsatz von IIS in der CA verhindert zudem, dass der CA-Server für Wartungszwecke außer Betrieb genommen wird, denn hierbei handelt es sich möglicherweise um den einzigen gültigen CRL-Speicherort für viele Clients.

Im Einrichtungshandbuch wurde die ausstellende CA verwendet, um IIS für die CRL- und CA-Veröffentlichung zu hosten. Dies geschah, um die Einrichtung zu vereinfachen und möglichst auf zusätzliche Hardware zu verzichten. Microsoft empfiehlt aber, sie, sofern möglich, separat zu stationieren.

Registrieren von Zertifikaten mithilfe von IIS-Registrierungsseiten

Die Verwendung von IIS-Registrierungsseiten empfiehlt sich für die folgenden Szenarien: für die Registrierung von domänenfremden Clients, für die Registrierung von Nicht-Windows-Clients oder für andere Browserclients als Microsoft Internet Explorer.

Die Webregistrierungsseiten sind in einer CA jedoch nicht erforderlich. Sie werden in dieser Lösung standardmäßig auf der ausstellenden CA installiert, können aber stattdessen auch auf einem separaten Webserver installiert werden. (Auf diesem Server muss IIS 5.0 oder höher ausgeführt werden, da anderenfalls ASP-Seiten nicht unterstützt werden). Die Registrierungsseiten vereinfachen zwar einige Registrierungsaufgaben, wenn Sie sie aber gar nicht benötigen, müssen Sie sie auch nicht installieren. Verweise auf weitere Informationen zum Installieren und Verwenden der Webregistrierungsseiten finden Sie im Abschnitt "Weitere Informationen" am Ende dieses Kapitels.

Konfigurieren von CDP- und AIA-Pfaden

Clients benötigen Zugriff auf eine aktuelle CRL, um feststellen zu können, ob ein Zertifikat gesperrt wurden. Außerdem müssen Clients möglicherweise CA-Zertifikate abrufen, um zu überprüfen, ob das Zertifikat einer Endeinheit an einen vertrauenswürdigen Stamm gebunden ist. Jede CA muss in ihren Zertifikaten einen oder mehrere URL(s) angeben, von denen die Clients Informationen zu den Zertifikaten abrufen können.

Wie Sie den CDP und AIA für Ihre einzelnen CAs konfigurieren, hängt von den Clienttypen ab, die Ihre Zertifikate verwenden werden. Sind die Zertifikate nur für die Verwendung durch Benutzer und Computer gedacht, die Mitglieder Ihrer Active Directory-Gesamtstruktur sind? Oder benötigen auch externe Benutzer oder Geräte die Zertifikate? Informationen zum Definieren von Zertifikatsclients finden Sie weiter oben in diesem Kapitel.

Stamm-CA

Die Stamm-CA wird bei dieser Lösung folgendermaßen konfiguriert:

Diese Konfiguration erlaubt es Clients außerhalb der Active Directory-Gesamtstruktur, Zertifikate von dieser CA zu verwenden und CAs unterzuordnen, da sie standardmäßig die HTTP-Pfade verwenden.

Ausstellende Zertifizierungsstelle

Die ausstellende CA wird in dieser Lösung für die Verwendung durch interne Active Directory-Clients optimiert. Die CA wird wie folgt konfiguriert:

Diese Konfiguration ist optimal geeignet für Clients, die sich in derselben Gesamtstruktur befinden wie die CAs. Basis-CRLs werden wöchentlich veröffentlicht, Delta-CRLs täglich. Da der Standardspeicherort für beide Active Directory ist, rufen die Clients diese Listen vom jeweils nächstgelegenen Domänencontroller ab. Dies sorgt für Ausfallsicherheit und optimiert den Netzwerkverkehr.

Einrichten von CDP und AIA zur Unterstützung externer Clients

Für Clients, die einer anderen oder gar keiner Active Directory-Gesamtstruktur angehören (zum Beispiel Router), ist die oben beschriebene Auslegung nicht so optimal. Da diese fremden Clients nicht auf die LDAP-CDPs und –AIAs zugreifen können, kann es zu erheblichen Verzögerungen kommen, wenn externe Benutzer versuchen, die Sperr- und AIA-Informationen zu prüfen. Diese Verzögerungen können bei diesen externen Benutzern zur vorzeitigen Beendigung von Anwendungen führen.

Wenn die Möglichkeit besteht, dass die Zertifikate von Clients außerhalb Ihrer Active Directory-Gesamtstruktur verwendet werden, müssen Sie die CDP- und AIA-Werte so konfigurieren, dass als primäre Pfade statt der LDAP-URLs die HTTP-URLs zum Einsatz kommen.

Damit LDAP-URLs auch durch externe Clients verwendet werden können, müssen Sie Folgendes tun:

Überlegungen zu Internetclients

Wenn Sie vorhaben, Zertifikate außerhalb Ihrer Organisation für die Verwendung im Internet zu verteilen, sind einige weitere Aspekte zu berücksichtigen.

Zertifikate mit internen LDAP-URLs könnten Auskunft über das interne Active Directory und die CA-Strukturen und -Namen geben. Um das zu verhindern, sollten Sie folgendermaßen vorgehen:

In beiden Fällen sollten Sie einen sekundären HTTP-Speicherort für den CRL-Abruf bereitstellen, damit die Clients auf diese Möglichkeit zurückgreifen können, wenn der primäre Speicherort nicht verfügbar ist.

Wo Sie weitere Hinweise zur Verwendung der CRLs und CDPs finden, erfahren Sie im Abschnitt "Weitere Informationen" am Ende des Kapitels.

Erweitern der Zertifizierungsstellen-Infrastruktur

Im Abschnitt "Definieren von Zertifikatssicherheitsanforderungen" wurde die Einteilung von Zertifikaten nach Sicherheitsstufe und Antragstellertyp erörtert. Der Hauptgrund für die Unterteilung nach verschiedenen Antragstellertypen besteht darin, dass für diese sehr wahrscheinlich jeweils unterschiedliche Zertifikatsrichtlinien und Betriebsverfahren gelten (wie in den CPS festgehalten).

In der Regel bezieht sich eine CPS auf eine CA. Es ist zwar möglich, unterschiedliche Richtlinien, die für verschiedene Inhabertypen gelten, in einer einzigen CA zusammenzufassen, aber dies verkompliziert die CPS unnötig und führt häufig zu Fehlern bei der Implementierung. Die Strategie für die Erweiterung dieser PKI zur Ausstellung von Zertifikaten, für die unterschiedliche Richtlinien- und Sicherheitsanforderungen gelten, besteht darin, für die wichtigsten Inhabertypen zusätzliche ausstellende CAs zu erstellen. Dies wird in der folgenden Abbildung veranschaulicht.

Hinweis: Aus der Abbildung geht lediglich hervor, wie Sie die zuvor beschriebene CA-Hierarchie erweitern können. Vielleicht ist in Ihrer Organisation für die künftigen Anforderungen eine viel komplexere oder einfachere Hierarchie erforderlich. Richten Sie sich daher beim Entwerfen zusätzlicher CAs und Zertifikatsfunktionen nach Ihren eigenen Sicherheitsanforderungen, denn bei einer PKI gibt es keinen absolut richtigen oder absolut falschen Entwurf. Beim Planen der Erweiterung der PKI für weitere Zertifikatsanforderungen sollten Sie ähnlich vorgehen, wie dies hier für den einfachen PKI-Entwurf beschrieben wird.

Abbildung 4.4: Erweitern der CA-Hierarchie
Bild in voller Größe anzeigen

Aus dieser Grafik geht hervor, wie die weiter oben beschriebene einfache CA-Hierarchie so erweitert werden kann, dass sie auch anderen Zertifikatsanforderungen gerecht wird. Die neuen CAs und Zertifikatsfunktionen sind auf grauem Hintergrund dargestellt. Die Grafik veranschaulicht außerdem den Verwendungszweck hochwertiger Zertifikate (Schlüssel- und Schlosssymbol). Darüber hinaus geht hervor, dass die Benutzerzertifikat-CAs (intern und extern) nach ihrer Inbetriebnahme die Rolle der Ausstellung von Standardbenutzerzertifikaten von der ersten CA übernehmen.

Bei dieser Strategie zur Erweiterung der CA-Infrastruktur gelten die folgenden Annahmen:

Wenn diese Annahmen für Ihre Organisation nicht zutreffen, benötigen Sie vermutlich eine andere Struktur. Eine eingehende Erörterung der verschiedenen Optionen und Verfahrensweisen zur Erweiterung Ihrer CA-Infrastruktur erhalten Sie im Kapitel "Designing a Public Key Infrastructure" im Windows Server 2003 Deployment Guide. Einen Link zu diesem Kapitel finden Sie im Kapitel "Weitere Informationen" am Ende des Kapitels.

Qualifizierte Unterordnung

Mithilfe der erstellten Zertifikatdefinitionen können Sie ohne weitere Anpassungsschritte Zertifikatsvorlagen definieren und Zertifikate ausstellen. Sie sollten aber bei der Erweiterung Ihrer PKI den Umfang begrenzen, in dem Ihre CAs Zertifikate ausstellen können, indem Sie die Delegierung der Zertifikate Ihrer ausstellenden CA einschränken.

Mithilfe der gekennzeichneten Unterordnung, die in diesem Kapitel weiter oben erörtert wurde, lässt sich der Umfang und Zweck von Vertrauensstellungen in Ihrer Organisation kontrollieren. Erstellen Sie dazu Kreuzzertifikate zwischen Ihrer CA-Infrastruktur und der Infrastruktur der externen Organisationen. Auf die gleiche Weise können Sie die Zertifikatstypen und bestimmte Attribute von Zertifikaten in der eigenen CA-Hierarchie begrenzen. Eine weitere Erörterung dieses Themas würde den Rahmen dieses Handbuchs sprengen. Weiterführende Informationen erhalten Sie im Dokument Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003. Einen entsprechenden Link finden Sie am Ende dieses Kapitels.

Für die in dieser Lösung verwendete PKI ist keine qualifizierte Unterordnung innerhalb der CA-Hierarchie notwendig.

Zum Seitenanfang

Konfigurieren von Zertifikatsprofilen

In diesem Abschnitt wird erläutert, wie Zertifikate so konfiguriert werden, dass sie die weiter oben in diesem Kapitel definierten Anforderungen erfüllen.

Definieren von Zertifikatsparametern

Sie sollten für jeden benötigten Zertifikatstyp das jeweilige Zertifikatsprofil dokumentieren. Anschließend können Sie die Profilparameter in den Zertifikatsvorlagen konfigurieren, die die von Ihrer CA ausgestellten Zertifikatstypen steuern.

Hinweis: Bei eigenständigen CAs werden keine Zertifikatsvorlagen verwendet. Sie müssen die Anforderung mit einem Tool wie Certreq.exe, mithilfe des Formulars auf den Webregistrierungsseiten oder mittels eines entsprechenden Skripts erstellen. Bei Verwendung einer eigenständigen CA sollten Sie dennoch die Zertifikatsprofile für jeden einzelnen Zertifikatstyp definieren und die Profile zum Aufbauen der Zertifikatsanforderungen an eine eigenständige CA verwenden.

Die Definition eines Zertifikatsprofils umfasst folgende Punkte:

Die Schlüssellänge, die Gültigkeitsdauer, die Optionen für die Schlüsselerstellung sowie die Registrierungs- und Autorisierungsrichtlinien werden durch die erforderliche Zertifikatssicherheitsstufe und die Anwendungsanforderungen bestimmt, die weiter oben genannt wurden.

Definieren der Zertifikats- und Schlüssellebensdauer

Die Zertifikatslebensdauer wird durch eine Reihe von Faktoren beeinflusst, zum Beispiel durch den Zertifikatstyp, die Sicherheitsanforderungen Ihres Unternehmens, die Standardverfahren in Ihrer Branche und gesetzliche Bestimmungen. Im Allgemeinen wird bei längeren Schlüsseln eine längere Zertifikats- und Schlüssellebensdauer unterstützt.

Hinsichtlich Schlüssellänge und -typ gibt einige Beschränkungen:

Bei der Wahl der Zertifikats- und Schlüssellebensdauer müssen Sie überlegen, wie manipulationsanfällig die Schlüssel sind und welche mögliche Konsequenzen eine Manipulierung hätte. Folgende Faktoren spielen bei der Wahl der Lebensdauer von Zertifikaten und Schlüsseln eine Rolle:

Die Schlüssellebensdauer und Erneuerungszeiträume, die in dieser Lösung für die CAs und Endeinheiten verwendet werden, sind in der folgenden Tabelle aufgeführt.

Tabelle 4.10: Zertifikat- und Schlüssellebensdauer

Hinsichtlich der Schlüssellänge gelten 1024-Bit-Schlüssel derzeit als praktisch nicht entschlüsselbar. Sie sollten eigentlich weit über die 2 Jahre hinaus sicher sein, die für die Endeinheit vorgeschlagen werden. Schlüssel mit einer Länge von 512 Bit dagegen gelten inzwischen nicht mehr als sicher, außer vielleicht für Anwendungen mit sehr geringen Sicherheitsanforderungen. Daher werden 512-Bit-Schlüssel in dieser Lösung nicht verwendet.

Die Stärke des Schlüssels der ausstellenden CA stellt einen Kompromiss zwischen Sicherheit und Leistungsfähigkeit dar. Ein Schlüssel dieser Länge hat gegenwärtig eine Lebensdauer, die weit über den vierjährigen Erneuerungszeitraum hinausreicht.

Bei der Stamm-CA bestehen keine wirklichen Leistungsbeschränkungen, daher können Sie die Schlüsselstärke auf die maximalen 16 Kilobit einstellen. Aus Gründen der Kompatibilität wird sie aber in dieser Lösung viel niedriger eingestellt. Doch selbst so sind 4096-Bit-Schlüssel weit über den Erneuerungszeitraum von 8 Jahren hinaus sicher.

RSA-Schlüssel werden bei allen CAs verwendet; der Schlüsseltyp für die Endeinheiten dagegen wird von den jeweiligen Anwendungsanforderungen bestimmt.

Es ist zwar möglich, ein Zertifikat mit demselben Schlüssel zu erneuern, unter normalen Umständen wird dies aber nicht empfohlen. In dieser Lösung wird bei jeder Zertifikatserneuerung ein neues Schlüsselpaar generiert.

Von CAs ausgestellte Zertifikate dürfen keine Gültigkeitsdauer aufweisen, die länger ist als die verbleibende Gültigkeitsdauer der ausstellenden CA und aller übergeordneten CAs bis hin zum Stamm. Wenn zum Beispiel das CA-Zertifikat in 6 Monaten abläuft, können Sie nur Zertifikate mit einer maximalen Lebensdauer von 6 Monaten ausstellen. In dieser Lösung wird daher vorgeschrieben, die CA-Zertifikate nach der Hälfte ihrer Lebensdauer zu erneuern. Die Gültigkeitsdauer aller Zertifikate, die von einer CA ausgestellt werden, sollte höchstens halb so lang sein wie die Lebensdauer des CA-Zertifikats.

Das ergibt eine gestaffelte maximale Gültigkeitsdauer von 4, 8 und 16 Jahren für Endeinheiten, ausstellende CAs bzw. Stamm-CAs. In dieser Lösung bleiben die Zertifikate für Endeinheiten auf eine maximale Gültigkeitsdauer von 2 Jahren beschränkt. Dies ermöglicht das Einfügen einer zusätzlichen Ebene mit Zwischen-CAs, ohne dass sich größere Auswirkungen auf die Lebensdauerhierarchie ergeben.

Zuordnen von Sicherheitsanforderungen zu Zertifikatsparametern

Die folgende Tabelle zeigt die weiter oben genannten Zertifikatstypen und die Zuordnung der jeweiligen Sicherheitskategorie zu den Zertifikatsprofilparametern.

Tabelle 4.11: Zertifikatparameter

Hinweise: 
Die in der Spalte Ausstellungsrichtlinie genannte Richtlinie "Niedrig" bezieht sich auf die vordefinierte Zertifikatsrichtlinie "Niedrige Zusicherung" in den Zertifikatsdiensten. Diese entspricht der Standardzusicherung bzw. dem Standardsicherungslevel, auf die bzw. den weiter oben eingegangen wurde.
Der Wert "Benannt" in der Spalte CSPs (Cryptographic Service Providers, Kryptografiedienstanbieter) gibt an, dass die vom Zertifikatstyp zugelassenen CSPs in der Vorlage festzulegen und nicht vom Client zu entscheiden sind. Die Clientcomputer- und Serverzertifikate haben spezifische CSP-Anforderungen.

Zuordnen von Zertifikatsanforderungen zu Zertifikatsvorlagen-Parametern

Bei vielen Anwendungen müssen die Zertifikate auf eine ganz bestimmte Weise konfiguriert sein. Unter Umständen muss der Inhabername auf eine bestimmte Art formatiert sein, oder es müssen bestimmte Anwendungsrichtlinien-OIDs enthalten sein, oder das Zertifikat muss einer spezifischen Ausstellungsrichtlinie entsprechend ausgestellt worden sein. Zumindest wird es erforderlich sein, dass die Schlüsselnutzung ordnungsgemäß definiert wurde. All diese Parameter müssen Sie sich vom Anwendungsinhaber (oder Hersteller) beschaffen, um Ihr Zertifikatsprofil definieren zu können.

Die Anwendungsanforderungen für die in dieser Lösung erforderlichen Zertifikate sind in den folgenden Tabellen aufgeführt. Die Tabellen enthalten die Zertifikatseigenschaften und die CA-Parameter (wie in den Zertifikatsvorlagen konfiguriert). Nicht alle möglichen Eigenschaften sind aufgelistet.

Hinweis: Alle unten aufgeführten Zertifikattpyen orientieren sich eng an einer der integrierten Vorlagentypen. Statt die Originalvorlagen zu bearbeiten, sollten Sie Kopien der integrierten Vorlagen erstellen und diese Kopien für die Festlegung der erforderlichen Einstellungen verwenden. So können Sie bei Bedarf leicht wieder auf die integrierten (und nicht geänderten) Vorlagen zurückgreifen.

Tabelle 4.12: Clientauthentifizierung Benutzer

Tabelle 4.13: Clientauthentifizierung Computer

Tabelle 4.14: Serverauthentifizierung mit 802.1X

Erstellen von Zertifikatsvorlagen

Active Directory in Windows Server 2003 enthält einen Satz vordefinierter Zertifikatsvorlagen für viele häufige Funktionen. Wenn Sie eine Unternehmens-CA installieren, ist diese standardmäßig bereits für das Ausstellen vieler dieser integrierten Zertifikatstypen konfiguriert. Eine Beschreibung dieser integrierten Vorlagen erhalten Sie in der Produktdokumentation zu Windows Server 2003 Enterprise Edition. Im Abschnitt "Weitere Informationen" am Ende dieses Kapitels finden Sie einen Link zu dieser Dokumentation.

In der in diesem Handbuch vorgestellten Lösung wurden die meisten dieser Standardvorlagen aus der CA entfernt. Das bedeutet, sie wurden aus dem Vorlagenordner in der CA-Verwaltungskonsole entfernt, was aber nicht heißt, dass Sie die Vorlagendefinitionen aus dem Verzeichnis löschen dürfen.

Sie können die vordefinierten Vorlagen verwenden, wenn diese Ihren Anforderungen entsprechen. Für die meisten zertifikatbasierten Windows-Anwendungen (wie z. B. EFS, VPN-Authentifizierung u. a.) gibt es eine entsprechende Vorlage. Wenn Sie andere Arten von Zertifikaten ausstellen müssen, ist es in der Regel besser, auf Ihre konkreten Anforderungen abgestimmte Vorlagen zu erstellen. Wenn Sie die vordefinierten Vorlagen ohne ein Grundverständnis ihrer Funktionen verwenden, riskieren Sie es, ungewollte Funktionen zu aktivieren. Das Computerzertifikat zum Beispiel, das zur einfachen Clientauthentifizierung gedacht ist, lässt sich auch als Webserverzertifikat benutzen.

Zum Erstellen einer neuen Vorlage sollten Sie eine vordefinierte Vorlage aussuchen, die Ihren Zertifikatsprofilanforderungen nahe kommt, und davon ein Duplikat erstellen, das dann als Grundlage Ihrer neuen Vorlage dient. Zum Konfigurieren der Vorlagen müssen einfach nur die Attribute ausgewählt werden, die den in diesem Abschnitt definierten Zertifikatsprofilen entsprechen.

Hinweis: Das Erstellen ganz neuer Vorlagen ist nicht möglich. Sie müssen immer eine Kopie einer vorhandenen Vorlage erstellen und diese Kopie dann entsprechend bearbeiten. Computervorlagen müssen immer aus anderen Computervorlagen abgeleitet werden. Dies gilt auch für Benutzervorlagen. Es ist nicht möglich, die beiden Vorlagentypen untereinander auszutauschen.

Sorgen Sie im Rahmen der Konfigurationsverwaltung dafür, dass sämtliche Änderungen der Vorlagenparameter protokolliert werden.

Zum Seitenanfang

Erstellen eines Zertifikatverwaltungsplans

Nachdem Sie Zertifikate für Ihr Unternehmen konfiguriert haben, müssen Sie einen Plan für die Verwaltung der Zertifikate während ihrer gesamten Nutzung erstellen. Dabei sind folgende Entscheidungen zu treffen:

Auswählen von Registrierungs- und Erneuerungsverfahren

Sie können Zertifikate mit den folgenden Verfahren registrieren (und auch erneuern):

All diese Verfahren sind jeweils für bestimmte Umstände geeignet. Bei dieser Lösung kommen die folgenden Registrierungsverfahren zum Einsatz:

Keines dieser Verfahren eignet sich für komplexere Szenarien, etwa wenn eine Zertifikatsanforderung vor der Übermittlung an die CA von einem Dritten signiert werden muss. Die RPC-basierte Onlineregistrierung wird bei den meisten Nicht-Windows-Plattformen (z. B. Routern) ebenfalls nicht unterstützt. Ebenso wenig möglich ist die automatische Registrierung in Fällen, in denen Sie den Antragstellernamen oder alternativen Antragstellernamen in der Zertifikatsanforderung definieren müssen (anstatt ihn von Active Directory generieren zu lassen).

Um anspruchsvolleren Anforderungen wie diesen gerecht zu werden, ziehen Sie eines der folgenden Verfahren in Betracht:

Zuordnen von Zertifikaten zu Identitäten

Die Zuordnung von Zertifikaten zu den darin genannten Antragstellern ist ein komplexes Thema, dessen Erläuterung den Rahmen dieses Kapitels sprengen würde. Grundsätzlich sind jedoch bei diesem Thema zwei wichtige Aspekte zu berücksichtigen:

Die erste Frage befasst sich damit, wie die Zertifikatsregistrierung erfolgt. Diesem Aspekt widmet sich der nächste Abschnitt "Erstellen von Zertifikatsrichtlinien". Bei der zweiten Frage geht es darum, wie die Zertifikatsbenutzer (Anwendungen und Dienste) die Identität des Zertifikatantragstellers ordnungsgemäß einer anderen von ihnen verwendbaren Identität zuordnen. Beispiele hierfür:

Die Mehrzahl der Zertifikate wird bei der Registrierung automatisch den Active Directory-Sicherheitsprinzipalen (Benutzern und Computern) zugeordnet. Active Directory definiert den Antragstellernamen und den alternativen Antragstellernamen des Zertifikats, um eine implizite Zuordnung zwischen dem Zertifikat und dem im Zertifikat benannten Sicherheitsprinzipalen zu erstellen. Der alternative Antragstellername enthält den UPN bzw. den E-Mail-Namen für einen Benutzer und den SPN (Service Principal Name, Dienstprinzipalnamen) bzw. den DNS-Hostnamen für einen Computer oder einen Computerprozess. Die UPN- und SPN-Werte sind in einer Active Directory-Gesamtstruktur immer eindeutig. Die E-Mail- und DNS-Namen sollten global eindeutig sein, wenngleich Active Directory dies nicht erzwingt. Andere Windows-Dienste, wie z. B. IIS und IAS, können ebenfalls die Zertifikatszuordnung an Benutzer- oder Computeridentitäten ausführen.

Hinweis: Die Zertifikatszuordnung hat nichts mit der Zertifikatsveröffentlichung zu tun. Die Zertifikatszuordnung zeigt an, dass ein Attribut des Zertifikats (normalerweise der alternative Antragstellername) vorhanden ist, das ein Objekt im Verzeichnis eindeutig identifiziert. Anhand dieses Attributs bestimmt der IAS-Server die Identität des Benutzers bzw. Computers, der das Zertifikat vorgelegt hat. Der IAS verwendet diese implizite Zuordnung, statt die Zertifikate im Verzeichnis nachzusehen. Die Zertifikatsveröffentlichung und die daraus folgende Zertifikatssuche beschreiben in Form von Attributen der Benutzer- bzw. Computerobjekte, wo die Zertifikate im Verzeichnis gespeichert sind. Ein Benutzer kann dann nach einer bestimmten Person im Verzeichnis suchen und die Zertifikate abrufen, die zu dieser Person gehören.

Außerdem ist es möglich, mithilfe der Verwaltungskonsole "Active Directory-Benutzer und -Computer" andere Zertifikate manuell in Benutzer- oder Computerobjekte zu importieren bzw. diesen zuzuordnen.

Umgekehrt gibt es viele Beispiele, in denen eine direkte Zuordnung zu einem Verzeichnisobjekt nicht erforderlich ist. Dazu gehören z. B.:

Alle Endeinheiten der in diesem Handbuch vorgestellten Lösung sind direkt (und implizit) Active Directory-Benutzern und -Computern zugeordnet.

Die CAs sind insofern Sonderfälle, als dass sie nicht zwangsläufig Computerobjekten zugeordnet sind. Diese werden fast immer Zertifizierungsstellenobjekten in den Containern für Active Directory-AIA und vertrauenswürdige CAs zugeordnet.

Erstellen von Zertifikatsrichtlinien

Sie sollten mindestens für jede Zertifikatssicherheitskategorie (hoch, mittel und Standard) die Zertifikatsgenehmigungsverfahren definieren. Microsoft empfiehlt dies auch für jede Zertifikatantragstellerkategorie (Computer, interner Benutzer, externer Benutzer). Es ist unwahrscheinlich, dass Sie noch genauer unterteilte Richtlinien definieren müssen. Dokumentieren Sie die festgelegten Richtlinien in Ihrer Zertifikatsrichtlinienerklärung und in Ihrer CPS.

Die verschiedenen Zertifikatsrichtlinien werden verwendet, um den Typ des Zertifikatsgenehmigungsverfahrens und den Sicherheitslevel des privaten Schlüssels anzugeben, der bei der Registrierung eines Zertifikats verwendet wird. Sie können dies (optional) mithilfe der OIDs für verschiedene Richtlinien in das Zertifikat aufnehmen. Das Genehmigungsverfahren sollte dem Wert des ausgestellten Zertifikats entsprechend streng sein. Ziel des Genehmigungs- bzw. Registrierungsverfahrens ist es, ein geeignetes Maß an Vertrauen darin zu schaffen, dass der das Zertifikat Anfordernde mit dem Zertifikatantragsteller identisch ist. Die Schlüsselstärke ist ein Maßstab dafür, inwieweit Sie darauf vertrauen können, dass der private Schlüssel auch privat und im alleinigen Besitz des Zertifikatantragstellers bleibt.

Die in dieser Lösung verwendeten Sicherungslevels für Zertifikate wurden weiter oben im Abschnitt "Definieren von Zertifikatssicherheitsanforderungen" definiert. Den Sicherungslevel der Zertifikate, die Sie ausstellen, können Sie angeben, indem Sie in die Zertifikate eine dem Level entsprechende Zertifikatsrichtlinien-OID einfügen. Anhand der Richtlinie können Anwendungen (und Benutzer) feststellen, wie vertrauenswürdig ein bestimmtes Zertifikat ist.

Die weiter oben definierten drei Sicherungslevel werden den drei vordefinierten Zertifikatsrichtlinien in Windows Server 2003 zugeordnet (in der Zertifikatsvorlagen-MMC werden diese als Ausstellungsrichtlinien bezeichnet). Die folgende Tabelle enthält genaue Informationen zur Verwendung der verschiedenen Zertifikatsrichtlinien in dieser Lösung. Es empfiehlt sich, die Richtlinien-OIDs in Ihre Zertifikatsvorlagen aufzunehmen (zumindest bei Zertifikaten mit mittlerem und hohem Sicherungslevel), so dass Zertifikate mit hoher Zusicherung leichter identifizierbar sind. Zertifikate ohne Zertifikatsrichtlinie gelten als Zertifikate mit Standardsicherungslevel.

Tabelle 4.15: Sicherungslevels von Zertifikatausstellungsrichtlinien

Hinweis: Wenn es den Anforderungen in Ihrer Organisation gerecht wird, spricht nichts dagegen, mehr oder weniger Zertifikatsrichtlinien und Sicherungslevels zu definieren.

Definieren der Richtlinie zur Zertifikatssperrung

Manchmal ist es erforderlich, einem Zertifikat vor dessen Ablauf die Gültigkeit zu entziehen. Das Erstellen von Richtlinien für das Sperren von Zertifikaten umfasst die folgenden Aufgaben:

Zu Ihrer Zertifikatsrichtlinie gehört auch das Definieren der Bedingungen, unter denen das Sperren des Zertifikats gerechtfertigt ist. Diese Bedingungen werden bei unterschiedlichen Zertifikatstypen möglicherweise variieren. Bei Zertifikaten mit unterschiedlichen Sicherungslevels und Inhabertypen sowie bei unterschiedlichen CAs werden sie ganz bestimmt variieren.

Außerdem sollten Sie dokumentieren, wie die Sperrgrundcodes beim Sperren eines Zertifikats verwendet werden. In der folgenden Tabelle werden die verschiedenen Grundcodes beschrieben.

Tabelle 4.16: Zertifikatssperrcodes

Wichtig: Den Grund "Zertifikat blockiert" sollten Sie nur verwenden, wenn dies absolut gerechtfertigt ist. Wird ein Zertifikat gesperrt und später wieder freigegeben, so ist es so gut wie unmöglich, seinen Sperrstatus zu einem bestimmten Zeitpunkt festzustellen (und damit auch die Gültigkeit von Signaturen, die es vornimmt).

Im Rahmen des Sperrverfahrens sollten Sie unbedingt die Antworten auf die folgenden Fragen festhalten. Diese werden normalerweise in einem Änderungs- oder Vorfallsverwaltungsprotokoll gespeichert:

Darüber hinaus gibt es einige technische Parameter, die das Sperren von Zertifikaten regeln. Microsoft empfiehlt, auch diese Parameter in Ihrer CA-Richtlinie zu dokumentieren. Die Parameter in den folgenden Tabellen beziehen sich auf die Stamm-CA und die ausstellenden CAs in dieser Lösung.

Tabelle 4.17: Zertifikatssperrparameter für Stamm-CA

Tabelle 4.18: Zertifikatssperrparameter für ausstellende CAs

Hinweis: Da Delta-CRLs mit relativ kurzer Lebensdauer (ein Tag) verwendet werden, müssen Sie sicherstellen, dass die maximale Active Directory-Replikationswartezeit höchstens halb so lang ist wie der Veröffentlichungszeitraum der Delta-CRL. Anderenfalls könnte das dazu führen, dass die Zertifikatsclients veraltete Sperrinformationen verwenden. Außerdem könnte es die Übertragung von Verzeichnisreplikationsdaten an Standorte mit eingeschränkter Netzwerkbandbreite beeinträchtigen. Stellen Sie den Delta-CRL-Überlappungszeitraum so ein, dass er länger ist als der Zeitraum, der für die Replizierung der Verzeichnisinformationen in Ihrer Gesamtstruktur erforderlich ist.
Wenn die Active Directory-Wartezeit länger als dieser Wert ist oder Sie den zusätzlichen Verzeichnisreplikationsverkehr vermeiden möchten, sollten Sie entweder den Zeitraum für die Veröffentlichung der Delta-CRL verlängern oder keine Delta-CRLs im Verzeichnis veröffentlichen. Bei Änderung der Delta-CRL-Speicherorte müssen Sie eine neue Basis-CRL ausstellen.
Die Replikationswartezeit ist typischerweise viel weniger problematisch, wenn zum Veröffentlichen von Delta-CRLs keine LDAP-URLs, sondern HTTP-Speicherorte verwendet werden.

Planen der Schlüssel- und Datenwiederherstellung

Die Schlüssel- und Datenwiederherstellung wird in diesem Handbuch nicht behandelt. Wenn Sie die Schlüssel- und/oder Datenwiederherstellung benötigen, müssen Sie sie sorgfältig planen und verwalten, um Datenverlust und die versehentliche Veröffentlichung verschlüsselter Daten zu vermeiden.

Lesen Sie dazu die Abschnitte in den Kapiteln "Planning for Data Recovery and Key Recovery" und "Designing a Public Key Infrastructure" im Windows Server 2003 Deployment Kit und die technische Abhandlung "Key Archival and Management in Windows Server 2003" von Microsoft.

Zum Seitenanfang

Zusammenfassung

Dieses Kapitel hat sich mit dem Entwerfen einer PKI (Public Key Infrastructure) für ein sicheres WLAN beschäftigt. Beim Entwerfen der PKI wurde berücksichtigt, dass die PKI in Zukunft wahrscheinlich in vielen Organisationen auch für andere Anwendungen verwendet wird. Die Flexibilität des in diesem Kapitel vorgestellten Entwurfs ermöglicht es, ihn für eine breite Palette zukünftiger Anforderungen zu erweitern. Mithilfe der hier enthaltenen Informationen können Sie eine PKI entwerfen, die auch strengeren Sicherheitskriterien als denen der WLAN-Anwendung gerecht wird.

Die in diesem Kapitel beschriebenen Entwurfsentscheidungen werden in den Einrichtungs- und Betriebshandbüchern zum Implementieren der PKI verwendet. Diese Informationen finden Sie in den Kapiteln 7 und 11 dieser Lösung.

Die verbleibenden Kapitel des Planungshandbuchs enthalten Informationen zum Entwurf der anderen Kernkomponenten dieser Lösung: der RADIUS-Infrastruktur (mit IAS implementiert) und der WLAN-Sicherheitsinfrastruktur.

Weitere Informationen

Die folgenden Dokumente enthalten ausführlichere Hintergrund- und andere Informationen zu vielen, in diesem Kapitel angesprochenen Themen:

Zum Seitenanfang

4 von 6