Bereitstellen und Unterstützen einer PKI bei Microsoft

Veröffentlicht: Dezember 2002

Viele Techniken und Produkte für die Absicherung von Unternehmensnetzwerken verwenden eine Form der Kryptografie. Eine Public Key Infrastructure (PKI) ist dabei erforderlich, um die an den kryptografisch gesicherten Transaktionen beteiligten Parteien anhand von Zertifkaten zu authentifizieren.

Auch die OTG (Operations and Technology Group), die interne IT-Abteilung von Microsoft, implemetierte bei der Absicherung des eigenen Unternehmensnetzwerks verschiedene kryptografische Techniken. Voraussetzunng hierfür war das Vorhandensein einer unternehmensweiten PKI, über die die Schlüssel-basierten Sicherheitsdienste bereitgestellt werden konnten.

Erfahren Sie in diesem Whitepaper, wie die OTG bei der Bereitstellung der PKI vorging und welche Maßnahmen sie für den weiteren Support getroffen hat.

Auf dieser Seite

Bereitstellen und Unterstützen einer PKI bei Microsoft

Kurzzusammenfassung

Einführung

Bereitstellungsmethode

Microsoft Operations Framework

Das MOF-Prozessmodell

Das MOF-Teammodell

Das MOF-Risikomodell

Implementierungsplanung

Definieren der Anforderungen für die Zertifizierungsstelle

Risikobeurteilung

Hosting

Kosten

Software von Drittanbietern

Fachkenntnisse des Teams

Problemlose Integration

Definieren der Registrierungsrichtlinie

Festlegen der Stammzertifizierungsstelle

Festlegen der Zertifizierungsstellenhierarchie

Sicherstellen der Integrität des Zertifizierungsstellenservers

Schützen des privaten Schlüssels der Zertifizierungsstelle

Verwalten integrierter Stämme

Bereitstellung

Bereitstellen von Microsoft Windows 2000-Zertifikatdiensten

Bereitstellen von Microsoft Windows Server 2003-Zertifikatdiensten

Verwendete Produkte und Technologien

Gewonnene Erkenntnisse und zukünftige Pläne

Zusammenfassung

Weitere englischsprachige Informationen

Bereitstellen und Unterstützen einer PKI bei Microsoft

(Engl. Originaltitel: Deploying PKI at Microsoft )

Zum Seitenanfang

Kurzzusammenfassung

Viele der Techniken und Produkte, die zum Sichern eines Unternehmensnetzwerks verfügbar sind, verwenden eine Form der Kryptografie. Eine Infrastruktur öffentlicher Schlüssel (Public Key Infrastructure oder PKI) ist erforderlich, um die Zertifikate zur Verfügung zu stellen, die zum Authentifizieren der Gültigkeit aller an einer kryptografisch gesicherten, elektronischen Transaktion beteiligten Parteien erforderlich sind. Microsofts interne IT-Gruppe namens OTG (Operations and Technology Group) musste mehrere Initiativen, für die kryptografische Techniken erforderlich waren, implementieren, um das Unternehmensnetzwerk zu sichern. Dieses erforderte daher das Vorhandensein einer unternehmensweiten PKI zum Bereitstellen auf Schlüsseln basierender Sicherheitsdienste.

Microsoft verwendet Zertifikate für mehrere PKI-fähige Produkte in dieser Infrastruktur. Daher ist Zertifikatausstellung sowohl innerhalb der Organisation als auch für externe Partner erforderlich. Als die Anzahl der Zertifikate verwendenden Anwendungen bei Microsoft weiter stieg, hat OTG die Microsoft® Windows® 2000-Zertifikatdienste bereitgestellt, um eine Zertifizierungsstelle zur Verfügung zu stellen. Eine Zertifizierungsstelle fungiert als Garant für die Beziehung zwischen dem öffentlichen Schlüssel des Subjekts und den Identitätsinformationen des Subjekts, die in den von der Zertifizierungsstelle ausgestellten Zertifikaten enthalten sind.

Beim Bereitstellen einer PKI müssen drei Optionen berücksichtigt werden: Beauftragen eines Zertifizierungsstellen-Drittanbieters mit der PKI, Bereitstellen einer eigenen Unternehmens-PKI oder Erstellen eines Hybridmodells, in dem die Stammzertifizierungsstelle von einem Drittanbieter bereitgestellt wird, die ausstellenden Zertifizierungsstellen jedoch intern sind.

OTGs Implementierungsziele für die Microsoft PKI-Lösung umfassten erhöhte Sicherheit, Anwendungskompatibilität, Interaktion mit unterstützten Diensten wie drahtloses LAN und SSL (Secure Sockets Layer), sowie verringerte Zertifizierungskosten. OTG wollte die Sicherheitsschwachstellen minimieren und die internen Anwendungstests verbessern. Alle Microsoft-Anwendungen werden intern vor der Marktfreigabe bereitgestellt und getestet.

OTG hat festgestellt, dass das Entwickeln einer eigenen Unternehmens-PKI diesen Implementierungszielen am besten Rechnung trägt, die Abhängigkeit von Dritten verringert, die interne Anforderung nach sicheren Interaktionen erfüllt, vertrauenswürdige Beziehungen mit Geschäftspartnern zur Verfügung stellt und den Zertifikataustausch über Internetbrowserprodukte ermöglicht. Außerdem ermöglicht die selbst betriebene Microsoft-PKI, dass jedes neue Microsoft-Produkt auf Kompatibilität und Interoperabilität mit Windows 2000 und den Windows Server 2003-PKI-Diensten getestet werden kann.

Outsourcing wurde überprüft, eignete sich jedoch nicht für die Zwecke von OTG. Outsourcing würde bedeuten, dass ein Teil der Verantwortung für OTGs Vertrauen und Sicherheit außerhalb von Microsoft liegen würde. Außerdem war die bei einer Outsourcinglösung entstehende Notwendigkeit, Desktopclientsoftware von Drittanbietern auszuführen und zu verwalten, für OTG nicht akzeptabel. Während der Auswertung erkannte OTG außerdem, dass Drittanbieter Gebühren pro Zertifikat verlangten. Für Microsoft wurden diese Kosten als hoch eingeschätzt, und sie könnten vom Anbieter willkürlich geändert werden.

Durch das Ausführen eigener Zertifizierungsstellen konnte OTG die Infrastruktur auf sicherere Weise verwalten und die Kosten verringern, die durch das Ausstellen von Zertifikaten und Verwalten einer externen Zertifizierungsstellenbeziehung anfallen. Durch das Implementieren einer Unternehmens-PKI kann OTG auf Standards basierende Kryptografietechnologien verwenden, um die Unternehmensressourcen von Microsoft zu sichern, z. B. verschlüsselte Dateisysteme, drahtlose Kommunikation, E-Mail, Remotezugriff und Webserververbindungen.

Die einfach zu verwaltende, auf Standards basierende und skalierbare PKI-Lösung von OTG führte zu einem Verfahren zum Austausch vertraulicher Daten, Kompatibilität mit anderen Microsoft-Anwendungen und verringerten Infrastrukturkosten.

Zum Seitenanfang

Einführung

Dieses Whitepaper beschreibt die Bereitstellung von Microsoft Zertifikatdiensten in der Produktionsumgebung von Microsoft. Der Leser sollte mit den Grundlagen von Sicherheitssystemen auf der Basis öffentlicher Schlüssel, ihren Vorteilen und den für ihre Implementierung erforderlichen Komponenten vertraut sein (siehe "An Introduction to the Windows 2000 Public Key Infrastructure" (englischsprachig) im Abschnitt "Weitere Informationen" am Ende dieses Dokuments).

OTGs dokumentiertes Ziel besteht im Bereitstellen einer IT-Umgebung, die aus Diensten, Anwendungen und einer Infrastruktur besteht, und die Microsoft-Mitarbeitern weltweit an mehr als 400 Standorten Verfügbarkeit, Datenschutz und Sicherheit zur Verfügung stellt. Diese Gruppe ist für das Ausführen der internen Netzwerke des Unternehmens, der Telekommunikationssysteme, der Unternehmensserver und aller Geschäftsbereichsanwendungen verantwortlich. Außerdem ist OTG für das Testen der Microsoft-Unternehmensprodukte in der Produktionsumgebung zuständig, bevor diese öffentlich verfügbar gemacht werden.

Sicherheit besitzt nicht nur in allen Bereichen der Produktentwicklung, sondern auch innerhalb von Microsofts eigener Unternehmensinfrastruktur weiterhin die höchste Priorität. Durch Implementieren einer Unternehmens-PKI kann OTG z. B. die folgenden, auf Standards basierenden kryptografischen Technologien verwenden, die das Microsoft-Unternehmensnetzwerk sichern: verschlüsseltes Dateisystem (Encrypted File System oder EFS), ein sicheres drahtloses Netzwerk (802.1x), sichere E-Mail über S/MIME (Secure Multipurpose Internet Mail Extensions), sicheren Remotezugriff (Smartcards) und sichere Verbindungen mit Webservern über SSL (Secure Sockets Layer).

Eine PKI ist eine Reihe von Diensten, die von einer Sammlung von miteinander verbundenen Komponenten zur Verfügung gestellt werden. Diese arbeiten zusammen, um auf öffentlichen Schlüsseln basierende Sicherheitsdienste wie Datenschutz, Authentifizierung und Zulassung bereitzustellen. Eine PKI bietet eine starke Form der Authentifizierung, da private Identifikationsschlüssel lokal gespeichert werden. Es sind keine Datenbanken erforderlich, die wertvolle vertrauliche Informationen enthalten. Indem externe Berechtigungen mit einer minimalen Anzahl von Vertrauensstellungen verwendet werden, wird die Notwendigkeit verringert, das Befolgen der vorgeschriebenen Richtlinien und Verfahren mehrerer Drittanbieter zu überprüfen.

Kryptografische Algorithmen kombinieren beliebige Dateneingaben und einen Verschlüsselungsschlüssel mathematisch, um verschlüsselte Daten zu generieren. Bei der traditionellen, symmetrischen Schlüsselkryptografie sind die Verschlüsselungs- und Entschlüsselungsschlüssel identisch und verwenden daher sicherheitssensitive Daten gemeinsam. Diese Schlüssel müssen ausgetauscht werden, bevor die Parteien, die mittels Kryptografie kommunizieren möchten, verschlüsselte Daten austauschen können. Das sichere Austauschen dieser Schlüssel kann schwierig sein, und es verzögert die Kommunikation. Da jeder Sender einen Schlüssel mit jedem Empfänger gemeinsam haben muss, lässt sich symmetrische Schlüsselkryptografie für große Implementierungen nicht gut skalieren.

Das grundlegende Merkmal der Kryptografie mit öffentlichen Schlüsseln ist, dass sich die Verschlüsselungs- und Entschlüsselungsschlüssel unterscheiden. Der Verschlüsselungsschlüssel ist für das Durchführen des Entschlüsselungsvorgangs nicht relevant. Ein anderer, mathematisch verwandter, jedoch nicht mit dem Verschlüsselungsschlüssel identischer Schlüssel ist für das Entschlüsseln der Daten erforderlich. Bei der Kryptografie mit öffentlichen Schlüsseln benötigt jeder Client ein Schlüsselpaar, das aus einem öffentlichen und einem privaten Schlüssel besteht. Indem der öffentliche Schlüssel anderen Benutzern zur Verfügung gestellt wird, können Benutzer die Daten verschlüsseln, die nur von der Person entschlüsselt werden können, die im Besitz des privaten Schlüssels ist. Sie können anderen Benutzern das Senden von verschlüsselten Daten an Sie ermöglichen, die nur mit Hilfe Ihres privaten Schlüssels entschlüsselt werden können. Ebenso können Benutzer Daten unter Verwendung ihres eigenen privaten Schlüssels so umwandeln, dass andere Benutzer deren Ursprung mit Ihrem öffentlichen Schlüssel überprüfen können. Die zuletzt genannte Funktion bildet die Grundlage für digitale Signaturen.

Die Verschlüsselung mit Hilfe symmetrischer Schlüsselkryptografie ist ein schneller Vorgang, der einen effizienten Algorithmus zum Verschlüsseln großer Datenmengen verwendet. Kryptografie mit öffentlichen Schlüsseln wird häufig zum Austauschen der symmetrischen Schlüssel verwendet, die anschließend für die Datenverschlüsselung eingesetzt werden.

Kryptografie mit öffentlichen Schlüsseln ermöglicht das Durchführen normaler Geschäftsoperationen in einer verteilten Umgebung mit optimiertem Datenschutz sowie verbesserter Sicherheit und Vertrauenswürdigkeit. Mit PKI können Benutzer diese Vorteile nutzen. PKI bietet ein konsistentes Verfahren zum Verwalten, Verteilen und Verwenden von Kryptografie mit öffentlichen Schlüsseln in nicht zusammenhängenden Netzwerken und Organisationen.

Viele der Techniken, die zum Sichern eines Unternehmensnetzwerks verfügbar sind, verwenden eine Form der Kryptografie und erfordern eine Infrastruktur, um ihre Vorteile zur Verfügung zu stellen. Viele der Technologien, die Microsoft zum Sichern des Unternehmensnetzwerks implementieren musste, verlangten das Vorhandensein einer PKI, um Sicherheitsdienste bereitstellen zu können, die auf öffentlichen Schlüsseln basieren.

Zum Seitenanfang

Bereitstellungsmethode

Das Bereitstellen neuer Technologien ist die Kernkompetenz und oberste Priorität von OTG. Zwar ähneln einige Aspekte des Verwaltungsvorgangs anderen Projekten, jedoch verlangen die mit der Bereitstellung einer PKI verbundenen Risiken eine strenge Projektverwaltungsmethode. Das Verwalten einer Softwarebereitstellung der Unternehmensklasse erfordert eine sorgfältige Planung im Vorfeld. Das Implementierungsteam benötigt einen realistischen Zeitplan, genau definierte Ziele, ein gründliches Verständnis der Produktabhängigkeiten, sowie die Personalressourcen zum Verwalten und Implementieren der Bereitstellung.

OTG verwendete während der Planungs-, Implementierungs- und Betriebsprozesse des Einrichtens einer PKI für das Unternehmen Microsoft einen Vorgang, der Microsoft Operations Framework (MOF) ähnlich ist.

Zum Seitenanfang

Microsoft Operations Framework

MOF ist eine Zusammenstellung bewährter Methoden mit Leitprinzipien und Modellen. MOF bietet Standards für das Erreichen der Zuverlässigkeit, Verfügbarkeit, Supportfähigkeit und Verwaltbarkeit einer IT-Lösung zur Verfügung. Diese Richtlinien für bewährte Methoden werden aus den Verfahren der Microsoft Consulting Services, der Microsoft IT-Gruppe, der ITIL (Information Technology Infrastructure Library) und der Geschäftspartner von Microsoft gesammelt. MOF wurde so konzipiert, dass die folgenden Ziele erreicht werden:

• Verwenden von Ideen, die sich im Einsatz bewährt haben.
• Nutzen branchenspezifischer, bewährter Methoden.
• Bereitstellen einer erweiterbaren Grundlage für Betriebswissen.
• Auseinandersetzen mit Personen, Prozessen und Technologien.
• Einbeziehen des Feedbacks von Kunden und Partnern.
• Erhöhen der IT-Flexibilität, damit das Unternehmen schnell an sich ändernde Bedingungen angepasst werden kann.
• Verwalten von End-to-End-Diensten, einschließlich Prozessen und Verfahren, statt nur Verwalten von Servern und Technologien.

Das MOF-Prozessmodell beschreibt einen Lebenszyklus, der im Zusammenhang mit einer beliebigen Dienstlösung auf Änderungen beliebiger Größe angewendet werden kann. Im folgenden Diagramm wird der Lebenszyklus der Änderung, einschließlich der vier Quadranten und der vier Überprüfungsphasen des MOF-Prozesses, dargestellt.

Abbildung 1: Das MOF-Prozessmodell

Beim Erstellen von IT-Lösungen müssen normalerweise zwei Teams verfügbar sein und vorbereitet werden. Anfangs wird ein Projektteam zusammengestellt, das für einen begrenzten Zeitraum basierend auf dem Projekt zusammenarbeitet. Es ist für das Planen, Erstellen und Implementieren der Lösung verantwortlich. Anschließend wird das permanente Team eingerichtet, das für die tägliche Ausführung der Lösung, sowie etwaige Erweiterungen verantwortlich ist. MOF wurde zur Unterstützung dieser Betriebsteams konzipiert.

Zum Seitenanfang

Das MOF-Prozessmodell

Dieses Modell stellt IT-Umgebungen vereinfacht dar, um die Prozesse zu erkennen, die ein Betriebsteam beim Verwalten von IT-Diensten durchführen wird. Das effektivste Verfahren zum Verwalten von Änderungen in einer IT-Umgebung besteht im gemeinsamen Sammeln und Testen verwandter Änderungen. MOF definiert diese Sammlungen von Änderungen als Versionen, von denen jede als eine Einheit verwaltet wird. Das MOF-Prozessmodell beschreibt den Lebenszyklus einer Version.

Jede Version muss jeden der Quadranten des MOF-Prozessmodells einschließlich der Überprüfungen durchlaufen. Die Überprüfung "Genehmigte Version" findet vor der Installation der Version statt, die Überprüfung "Funktionsbereitschaft der Version" bei der endgültigen Installation. Die Überprüfungen "Betrieb" und "Service Level Agreement (SLA)" erfolgen nach der Einführung einer Version, um die Abläufe und die Leistung im Vergleich zu akzeptablen, definierten Dienstebenen zu beurteilen.

Die Version durchläuft nach Bestehen der Überprüfung "Genehmigte Version" den Quadranten "Änderung". Der Quadrant "Änderung" definiert bewährte Methoden zum Installieren und Konfigurieren der Version, z. B. optimale Vorgehensweisen für das Change und Configuration Management (CCM oder Änderungs- und Konfigurationsmanagement). Außerdem sind hier bewährte Methoden für die Dokumentation enthalten, bei denen eine Form einer gemeinsamen Configuration Management-Datenbank (CMDB) verwendet wird. Das Verwalten einer genauen CMDB gewährleistet die Systemidentifikation, das Berücksichtigen jedes Konfigurationselements, sowie das Vorhandensein von Informationen für Verwaltungsberichte.

Der Quadrant "Betrieb" definiert den täglichen Betrieb einer Version in der Produktionsumgebung. Dieser Quadrant geht davon aus, dass die Version in der Produktionsumgebung betrieben wird, und seine bewährten Methoden beziehen sich z. B. auf Sicherheit und Systemverwaltung, sowie Dienstüberwachung.

Die Überprüfung "Betrieb" wird regelmäßig durchgeführt. Es handelt sich um eine Überprüfung der Fähigkeit des IT-Personals, einen bestimmten Dienst zu verwalten. Diese Überprüfung bietet außerdem eine Dokumentation zum Erstellen einer Wissensdatenbank und stellt Kenngrößen für den Unternehmenswert zur Verfügung.

Die bewährten Methoden des Quadranten "Support" beziehen sich auf die Probleme oder Fragen, die sich während des Betriebs ergeben. Das Ziel des Quadranten "Support" ist das Beheben von Vorfällen und Problemen. Dieser Quadrant umfasst Funktionen für Kundendienstvorfälle und Problem Management.

Die Überprüfungen "SLA" finden regelmäßig statt, um die Fähigkeiten des Personals zum Erfüllen definierter Dienststufen zu bewerten. Es werden Maßnahmen für die Bereiche ergriffen, die die Überprüfung nicht bestehen, oder für Änderungen, die an den SLAs vorgenommen werden müssen.

Schließlich definiert der Quadrant "Optimierung" bewährte Methoden zur Bewertung der aktuellen Leistung und zur Vorhersage langfristigerer Anforderungen. Dies umfasst taktische Informationen hinsichtlich des Capacity und Availability Management (Kapazitäts- und Verfügbarkeitsverwaltung). Diese taktischen Funktionen identifizieren die Notwendigkeit von Versionen. Die Überprüfung "Genehmigte Version" ist die letzte Überprüfung für die vorgeschlagenen Änderungen. Nach einer erfolgreichen Überprüfung beginnt ein neuer Zyklus mit dem Quadranten "Änderung".

Der erste Schritt beim Implementieren des MOF-Prozessmodells bei Microsoft bestand in der Vorbereitung einer Überprüfung "Genehmigte Version". Im Fall der PKI-Bereitstellung bezog sich der Begriff Version auf die gesamte PKI.

PKI ermöglicht das Durchführen folgender Aufgaben:

• Verwalten von Schlüsseln. Eine PKI vereinfacht das Ausstellen neuer Schlüssel, das Erneuern oder Sperren vorhandener Schlüssel, sowie das Verwalten des Vertrauensgrads, den Schlüssel von verschiedenen Herausgebern besitzen.
• Veröffentlichen von Schlüsseln. Eine PKI stellt ein sicheres Mittel zum Binden der öffentlichen Schlüssel an eine Benutzeridentität oder Computeridentität dar. Ohne die Möglichkeit, Schlüssel abzurufen und hinsichtlich ihrer Gültigkeit sicher zu sein, können Benutzer keine öffentlichen Schlüsseldienste verwenden.
• Verwenden von Schlüsseln. Eine PKI stellt ein benutzerfreundliches Verfahren für die Verwendung von Schlüsseln durch Benutzer zur Verfügung. Nicht nur, indem Schlüssel dorthin verschoben werden, wo sie benötigt werden, sondern auch durch Bereitstellen einfach zu verwendender Anwendungen, die kryptografische Operationen mit öffentlichen Schlüsseln durchführen und auf diese Weise das Bereitstellen verbesserter Sicherheit für E-Mail, E-Commerce und Netzwerke ermöglichen.

OTG hat eine PKI entwickelt, die die Anforderungen der Benutzer erfüllt. Diese Version wurde für eine Überprüfung "Genehmigte Version" an das obere Management übergeben.

Die Funktionen des MOF-Quadranten "Änderung" wurden erfüllt, indem ein Change Management-Verfahren eingerichtet wurde, das Benutzer über das Vorhandensein der OTG-PKI benachrichtigt. Das Verfahren ermöglicht dann die Benachrichtigung der richtigen Zertifizierungsstellenclients, wenn diese von einer Änderung betroffen sind. Nicht domänengebundene Geräte wie Pocket PCs müssen über einen Webbrowser auf eine bestimmte interne Zertifizierungsstellen-Webseite verweisen, wenn eine Kommunikation mit der Zertifizierungsstelle erforderlich ist. Wenn diese Zertifizierungsstelle außer Betrieb sein oder ihr Namen geändert werden sollte, muss eine Änderungskontrolle ausgegeben werden, damit diese Benutzergruppen wissen, was passieren wird, und wann, für welche Zeitspanne und wie das Problem umgangen werden kann.

Configuration Management wurde verwendet, um die Zertifizierungsstellenserver mit den entsprechenden Patches zu versehen. Alle Patches wurden mit einer Versuchszertifizierungsstelle getestet, bevor die Bereitstellung auf Produktionszertifizierungsstellen erfolgte. Zwar hatte OTG Prozesse für die Sicherheitspatchverwaltung vorbereitet, die Patches mussten jedoch auf Zertifizierungsstelleninteraktionen auf bestimmten Hardwareplattformen unter besonderen Bedingungen getestet werden. Die Zertifikatserver in der OTG-PKI sind z. B. innerhalb von Microsoft insofern einzigartig, als sie Hardwarekryptografiebeschleuniger verwenden.

Die Sicherheits- und Systemverwaltungsfunktionen des MOF-Quadranten "Betrieb" wurden erfüllt, indem eine neue Sicherheitsgruppe für CA-Manager erstellt wurde, deren Mitglieder nur einige ausgewählte Benutzer der IT-Informationssicherheit waren. Nur die Gruppe für die CA-Manager erhielt Berechtigungen für die Zertifizierungsstelle. Standardmäßig erhalten Mitglieder der lokalen Sicherheitsgruppe Administratoren sowie Mitglieder der globalen Sicherheitsgruppe Domänenadministratoren und Unternehmensadministratoren Verwaltungsberechtigungen für die Zertifizierungsstelle. Die Gruppen Unternehmensadministrator und Domänenadministrator wurden aus der Zugriffssteuerungsliste (Access Control List oder ACL) für die Zertifizierungsstelle entfernt. Anschließend wurde Überwachung implementiert, damit ein Unternehmensadministrator sich nicht selbst unerkannt der Gruppe für die CA-Manager hinzufügen konnte. Diese Vorgehensweise ermöglicht eine geringere Anzahl von Eigentümern der Zertifizierungsstellen und stellt sicher, dass nur ausgewählte Spezialisten Änderungen an der Zertifizierungsstellenkonfiguration durchführen können. Außerdem zeigt sie, dass das Überwachen eines Konfigurationsverlaufs einfach einzurichten und zu verfolgen ist.

Die Funktionen des MOF-Quadranten "Support" wurden durch das Einrichten eines Eskalationswegs für Benutzer berücksichtigt, die sich mit Fragen bezüglich der Zertifizierungsstellen an den Helpdesk wenden. Dies kann z. B. der Fall sein, wenn der Browser eines Benutzers angibt, dass die Zertifikatsperrliste nicht verfügbar ist, die durch eine Intranetwebsite mit SSL an seinen Browser übergeben wurde. Der Helpdesk versendet während der Geschäftszeiten eine Aliasadresse per E-Mail und ruft außerhalb der Geschäftszeiten die Pagernummer des PKI-Teams an. OTG hat definiert, welche Mitarbeiter an erster, zweiter und dritter Stelle und unter welchen Umständen über Pager informiert werden.

Die Funktionen des MOF-Quadranten "Optimierung" werden durch regelmäßige SLA-Überprüfungen für die PKI berücksichtigt. Als z. B. die Bereitstellung sicherer E-Mail für 50.000 Mitarbeiter stattfand, führte OTG die Bereitstellung so durch, dass die Zeiten in der Warteschlange minimiert wurden - die Zeit in der Warteschlange ist eine der SLA-Kenngrößen. Als die Zeit in der Warteschlange anstieg, fügte OTG entsprechend Personal hinzu, um die Zeit in der Warteschlange erneut auf die SLA-Vorgaben zu reduzieren.

OTG erkannte außerdem, dass zu viele Zertifizierungsstellen bereitgestellt wurden. Durch neue Hardware konnten die Funktionen mehrerer Zertifizierungsstellen in einer Zertifizierungsstelle kombiniert werden. Eine neue MOF-Version wurde entworfen und vorgestellt, um einige zu selten verwendete Zertifizierungsstellen außer Betrieb zu nehmen und Zertifikatvorlagen mit anderen Zertifizierungsstellen zusammenzuführen. Die Version konfigurierte außerdem die PKI neu, um das Ausstellen vieler Zertifikate in der Gesamtstruktur des Active Directory®-Verzeichnisdienstes von nur zwei Zertifizierungsstellen durchführen zu lassen. Zwei Zertifizierungsstellen werden aus Redundanzgründen zur Verfügung gestellt - wenn eine Zertifizierungsstelle ausfällt, kann die verbleibende Zertifizierungsstelle weiterhin alle erforderlichen Zertifikate ausstellen.

Der Bedarf für eine zweite, hybride PKI-Hierarchie wurde zu einem frühen Zeitpunkt der Bereitstellung der PKI erkannt. Diese hybride Hierarchie sollte ändern, wie SSL-Zertifikate für SSL-fähige, kundenorientierte Websites auf Microsoft.com ausgestellt werden. Eine neue MOF-Version, die eine mit einer öffentlichen Zertifizierungsstelle verknüpfte Zwischen-Stammzertifizierungsstelle hinzufügte, wurde vorgeschlagen, überprüft und implementiert.

Zum Seitenanfang

Das MOF-Teammodell

Das MOF-Teammodell vereinfacht die Ansicht von Teamrollen und hilft dem Management, Mitarbeiter effektiv zu organisieren. Es enthält grundlegende Prinzipien, die Teams beim Ausführen und Betreiben von verteilten Datenverarbeitungsumgebungen auf der Microsoft-Plattform unterstützen. Das MOF-Teammodell definiert die folgenden sechs Teamrollen:

• Die Rolle "Version", die sicherstellt, dass Änderungen rechtzeitig durchgeführt werden.
• Die Rolle "Infrastruktur", die die Verwaltung der Elemente zur Verfügung stellt, aus denen die IT-Lösung besteht.
• Die Rolle "Support", die ein Team übernimmt, welches Funktionen für Helpdesk und Problem Management ausübt.
• Die Rolle "Betrieb", die für den täglichen Betrieb und die Systemverwaltung verantwortlich ist, um die IT-Lösung auszuführen und zu verwalten.
• Die Rolle "Sicherheit", die den Schwerpunkt auf den Schutz des Netzwerks und Sicherheitslücken legt, die sich auf eine schwache physische Sicherheit beziehen.
• Die Rolle "Partner", die IT-Partner und Dienstanbieter umfasst, die als virtuelle Mitglieder des IT-Personals arbeiten.

OTG hat das Anwenden der bewährten Methoden im Teammodell sichergestellt, indem virtuelle Teams eingesetzt wurden. Virtuelle Teams werden bei Microsoft häufig eingesetzt, insbesondere für Technologiebereitstellungen. Virtuelle Teams bestehen aus Microsoft-Mitarbeitern, die miteinander größtenteils über E-Mail und andere Technologien für die Zusammenarbeit wie z B. Microsoft SharePointT Team Services und SharePoint Portal Server kommunizieren.

Zum Seitenanfang

Das MOF-Risikomodell

Das dritte und letzte MOF-Modell ist das Risikomodell. Ebenso wie die anderen MOF-Komponenten wendet das Risikomodell bewährte Techniken auf das Risiko- und tägliche Krisen-Management an. Das MOF-Risikomodell zieht seinen Nutzen aus dem Prinzip eines strukturierten und wiederholbaren Prozesses. Das Risikomodell wurde entwickelt, um Organisationen beim Ausführen ihrer Lösungen hinsichtlich des Risikomanagements zu unterstützen. Es weist folgende Prinzipien für erfolgreiches proaktives Risikomanagement im Betrieb auf:

• Kontinuierliches Beurteilen von Risiken. Das Team beendet niemals die Suche nach neuen Risiken, und bekannte Risiken werden regelmäßig neu bewertet.
• Integrieren des Risikomanagements in jede Rolle und jede Funktion. Alle Benutzer übernehmen einen Teil der Verantwortung für das Risikomanagement, und jeder IT-Prozess wird vor dem Hintergrund des Risikomanagements konzipiert.
• Positives Umgehen mit der Risikoidentifizierung. Die Teammitglieder sollten Risiken identifizieren können, ohne Kritik fürchten zu müssen.
• Verwenden von risikobasierter Zeitplanung. Wenn Änderungen der Reihe nach vorgenommen werden, sollte das Team die riskantesten Änderungen nach Möglichkeit zuerst durchführen, damit für Änderungen, die nicht freigegeben werden können, keine Zeit und Ressourcen verschwendet werden.
• Festlegen eines akzeptablen Formalitätsniveaus. Erstellen eines Prozesses, der vom Team verstanden und tatsächlich angewendet wird.

Risiken sind täglicher Bestandteil des IT-Betriebs, und Risikomanagement dient zum Schutz des zukünftigen Betriebs. MOF nennt die fünf Schritte des Risikomanagementprozesses: Identifizieren, Analysieren, Planen, Nachverfolgen und Steuern. Jedes identifizierte Risiko durchläuft diesen Prozess, wie in Abbildung 2 dargestellt.

Abbildung 2: Das MOF-Risikomodell

OTG wendete das MOF-Risikomodell beim Auswerten der Optionen an, nachdem der Bedarf für Änderungen in der Infrastruktur erkannt wurde. Das Befolgen des MOF-Risikomodells stellt weitgehend sicher, dass vorgeschlagene Änderungen die Überprüfung "Genehmigte Version" bestehen.

Zum Seitenanfang

Implementierungsplanung

Der Bedarf für eine PKI wurde bei Microsoft erkannt, als OTG mehrere Benutzeranforderungen vorlagen, die die Bereitstellung kryptografischer Technologien verlangten.

Beispielsweise lagen die folgenden Anforderungen vor:

• Strenge Authentifizierung mit Smartcards.
• Vertraulichkeit und Integrität übertragener Daten mit IPSec (Internet Protocol Security).
• Vertraulichkeit gespeicherter Daten mit EFS.
• Sichere E-Mail mit S/MIME.
• Sichern der Webverbindungen mit SSL oder TLS (Transport Layer Security).
• Einrichten der Zulassung durch digitale Signaturen.

Diese Sicherheitstechnologien werden durch die Implementierung einer PKI unterstützt.

Zum Seitenanfang

Definieren der Anforderungen für die Zertifizierungsstelle

Nachdem der Bedarf für eine PKI erkannt wurde, begannen die OTG-Designer den Prozess, indem sie die Anforderungen für die Zertifizierungsstelle definierten. Sicherheit spielt immer eine übergeordnete Rolle, und es muss ein akzeptabler Risikoumfang ermittelt werden. Die Gefährdung eines Systems, das Zertifikate ausstellt, kann ernsthafte Folgen haben. Dies bezieht sich auf Systeme, die Zertifikate direkt für Benutzer oder Anwendungen ausstellen, sowie auf Systeme, die Zertifikate für andere Zertifikatserver ausstellen, um diese für das Ausstellen von Benutzer- oder Anwendungszertifikaten zu autorisieren. Zwar können Zertifikate, deren Sicherheit nicht mehr gewährleistet ist, gesperrt werden, dies ist jedoch keine wünschenswerte Situation. Das wiederholte Sperren ausgestellter Zertifikate ist ein Indikator für fehlerhafte oder inadäquate Sicherheitsverfahren und kann zum Verlust des Benutzervertrauens führen.

Zum Seitenanfang

Risikobeurteilung

Das Definieren der einem Risiko ausgesetzten Objekte unterstützt das Ermitteln der Sicherheitsanforderungen für die Zertifizierungsstelle. In einem Netzwerk kann z. B. geistiges Eigentum vorhanden sein, dessen Sicherheit gewährleistet sein muss, da es ansonsten möglicherweise zu katastrophalen Verlusten kommen kann, wenn dieses geistige Eigentum Konkurrenten zugänglich gemacht wird. Kryptografische Techniken zum Schutz dieser Daten sind bedeutungslos, wenn die Sicherheit der Zertifizierungsstelle gefährdet werden kann. Wenn Angreifer z. B. physisch oder über das Netzwerk Kontrolle über die Zertifizierungsstelle erlangen können, können sie möglicherweise Zugriff auf den privaten Schlüssel der Zertifizierungsstelle erhalten. Wenn dieser private Schlüssel verwendet wird, um die Identität der Zertifizierungsstelle zu übernehmen, könnte der Angreifer Zertifikate ausstellen, die den öffentlichen Schlüssel des Angreifers an eine beliebige Benutzer- oder Computeridentität binden. Angreifer, die die Identität einer Zertifizierungsstelle übernehmen, können weit reichenden Schaden durch Diebstahl von Informationen, Unterbrechen der Netzwerkdienste oder Zerstören von Netzwerkressourcen verursachen. Ein Zertifizierungsstellenschlüssel, dessen Sicherheit nicht gewährleistet ist, unterminiert und hebt die Gültigkeit aller Sicherheitsmaßnahmen auf, die von der Zertifizierungsstelle und beliebigen Zertifizierungsstellen unter dieser in der Hierarchie bereitgestellt werden. Das Benutzervertrauen wird ebenfalls geschwächt, wenn die Sicherheit gefährdet ist, und Unternehmen verbringen erhebliche Zeit nicht nur mit dem erneuten Ausstellen gültiger Zertifikate, sondern auch mit dem Wiederherstellen des Benutzervertrauens in die Sicherheit von Daten, die über die PKI ausgetauscht werden. Unternehmen müssen einen adäquaten Grad an Schutz für die Zertifizierungsstelle und ihren privaten Schlüssel zur Verfügung stellen. Was adäquat ist, sollte auf der Analyse des Werts der geschützten Daten und der Risikobereitschaft der Organisation basieren.

Zum Seitenanfang

Hosting

Die nächste Entwurfsentscheidung für OTG war die Auswahl eines PKI-Modells basierend auf den Anforderungen hinsichtlich Sicherheit und Kosten, sowie den gebotenen Diensten. Es musste eine Entscheidung getroffen werden, ob Microsoft die PKI selbst ausführen oder auslagern sollte.

Eine ausgelagerte PKI kann teilweise oder vollständig ausgelagert werden. Eine teilweise ausgelagerte PKI ermöglicht einem Unternehmen das Delegieren des gesamten Authentifizierungsvorgangs oder eines Teils dieses Vorgangs an einen Drittanbieter. Auf diese Weise kann ein Unternehmen einen Teil der Kontrolle über die Zertifikatverwaltung behalten. Eine vollständig ausgelagerte PKI ermöglicht einem Unternehmen das Auslagern (Outsourcing) der Authentifizierung der digitalen Zertifikate, sowie des Ausstellungsvorgangs. Ein Drittanbieter richtet eine Zertifizierungsstelle ein und betreibt diese im Auftrag des Unternehmens. Autorisiertes Microsoft-Personal kann normalerweise über eine webbasierte Schnittstelle auf die Zertifizierungsstelle zugreifen, um Zertifikatanforderungen zu genehmigen, Berichte anzuzeigen und Zertifikate zu sperren, während der Drittanbieter den täglichen Betrieb, die Systemwartung und Upgrades durchführt.

Zum Seitenanfang

Kosten

Entscheidungen hinsichtlich des Entwurfs, die für das Outsourcing der PKI berücksichtigt werden müssen, beziehen sich auch auf das Ermitteln der Anzahl der erforderlichen Zertifikate. Einige Drittanbieter rechnen auf der Basis einzelner Zertifikate ab. Unternehmen, die einen webaktivierten Server einsetzen, oder IPSec zum Verschlüsseln von Daten zwischen der eigenen und einer Partnerorganisation implementieren, wünschen möglicherweise den Overhead nicht, der mit dem Ausführen einer selbst betriebenen PKI verbunden ist, und betrachten die Kosten für Outsourcing daher als minimal. Ein Unternehmen mit vielen webaktivierten Produkten hingegen findet möglicherweise die Kosten für Outsourcing im Vergleich zu den mit der Entwicklung einer eigenen PKI verbundenen Kosten immens.

In einigen Fällen wird Sicherheit selbst dann das Hauptentscheidungskriterium für den Entwurf sein, wenn eine unternehmensinterne PKI teurer ist. Ein Lieferant, der im Rüstungsbereich arbeitet, wird z. B. die Sicherheit gewährleisten wollen, und ist möglicherweise nicht willens, sich auf die Verfahren und Vorgehensweisen eines Drittanbieters zu verlassen. Für diesen Lieferanten sind die Kosten für Outsourcing möglicherweise geringer als das Ausführen einer internen PKI. Die Abhängigkeit von der Sicherheit des Drittanbieters ist jedoch nicht akzeptabel.

Zum Seitenanfang

Software von Drittanbietern

Jede Outsourcing-Entscheidung beinhaltet den Bedarf für Software von Drittanbietern, insbesondere, wenn die Software des Drittanbieters für viele Clients bereitgestellt und verwaltet werden muss. Zwar sind die Kosten für die Software häufig gering, oder die Software ist sogar kostenlos, ihre Bereitstellung kann jedoch viele Prozesse beinhalten und zeitaufwändig sein, wodurch die Infrastruktur- und Verwaltungskosten wiederum erhöht werden.

OTG hat ermittelt, dass eine mit den Microsoft Zertifikatdiensten selbst ausgeführte PKI, externe Software und die Abhängigkeit von der Sicherheitsumgebung eines Drittanbieters überflüssig macht. Zum damaligen Zeitpunkt enthielt nur Microsoft Windows 2000 Zertifikatdienste - die Betriebssystemauswahl war daher einfach. Sowohl Windows 2000 als auch Windows Server 2003 enthalten zurzeit die Dienste, die zum Erstellen einer funktionalen Unternehmens-PKI erforderlich sind. Die Zertifikatdienste von Windows Server 2003 sind mit früheren Produktversionen kompatibel und weisen im Vergleich zu der Windows 2000-Version Optimierungen auf. Beim Erstellen neuer Hierarchien oder Ersetzen vorhandener Zertifizierungsstellenserver verwendet OTG die Zertifikatdienste von Windows Server 2003.

Zum Seitenanfang

Fachkenntnisse des Teams

Bei der Untersuchung, ob Outsourcing der PKI stattfinden soll, müssen die aktuellen Fachkenntnisse in der IT-Organisation bewertet werden. Das Unternehmen kann z. B. über IT-Personal verfügen, das die für die Bereitstellung der PKI-Funktionen erforderlichen Server und Dienste problemlos implementieren kann, jedoch über keinerlei Erfahrung mit der Planung einer PKI verfügt. In diesem Fall ist zumindest das Outsourcing des Entwurfs an erfahrene Berater erforderlich.

Zum Seitenanfang

Problemlose Integration

Ein weiterer Faktor beim Auswählen einer selbst betriebenen PKI ist die problemlose Integration in die vorhandene Umgebung. Windows 2000 und Windows Server 2003 können in die meisten Netzwerkumgebungen integriert werden und erfordern nur sehr wenig oder keine Überarbeitung für das Produktionsnetzwerk.

OTG hat beim Auswerten der Outsourcing-Anforderungen der Zertifizierungsstelle mehrere Angebote von Drittanbietern geprüft. Alle Drittanbieter stellten Zertifikate und Schlüssel für kryptografische Anwendungen auf einer Pro-Client-Kostenbasis, einige auf einer Pro-Client/Pro-Anwendung-Kostenbasis zur Verfügung. Das Outsourcing einer PKI erzwingt immer eine Abhängigkeit von der Sicherheit und Verwaltung des ausgewählten Drittanbieters. OTGs Beurteilung ermittelte sowohl Kosten als auch Sicherheit als Entscheidungskriterien für die Auswahl des Modells zum Betreiben der PKI.

OTG entschied sich aus folgenden Gründen, die Microsoft-Unternehmensstammautorität selbst zu signieren und die PKI selbst zu betreiben:

• Sicherheit. In jeder Umgebung erfordert das Verwalten einer Stammautorität außerordentliche Sicherheitsmaßnahmen. Die Stammzertifizierungsstelle sollte immer offline und physisch gesichert sein. Die Stamm- und Zwischenzertifizierungsstellen bei Microsoft sind physisch in Offline-Tresoren gesichert.
• Kosten. In einem Unternehmen der Größe Microsofts mit vielen kryptografischen Anwendungen, die öffentliche Schlüssel verwenden, und Clientsystemen, ist jedes Pro-Client-Kostenmodell unerschwinglich.

Zum Seitenanfang

Definieren der Registrierungsrichtlinie

Beim Definieren der Registrierungsrichtlinie ermittelte OTG die kryptografischen Anwendungen und Techniken, die bei Microsoft verwendet werden.

Jede auf öffentlichen Schlüsseln basierende Anwendung oder Technik kann Zertifikate auf verschiedene Weisen verwenden. Einige Anwendungen erfordern z. B., dass Benutzer über Zertifikate verfügen, während bei anderen die Computer über Zertifikate verfügen müssen. Die meisten Anwendungen generieren ein Schlüsselpaar und müssen dann den öffentlichen Schlüssel in ein Zertifikat integrieren. Die Registrierung kann mehrere Methoden umfassen; aus diesem Grund ist die sorgfältige Analyse jeder einzelnen Anwendung oder Technik, die implementiert wird, wichtig.

Abbildung 3: Zertifikatregistrierung

Normalerweise verwenden kryptografische Anwendungen oder Techniken, bei denen eine Person identifiziert werden muss, Benutzerzertifikate. Beispiele hierfür sind Smartcards, die für die Authentifizierung eines Benutzers verwendet werden, oder verschlüsselte Speicherprodukte, bei denen nur der verschlüsselnde Benutzer den Inhalt entschlüsseln kann. Eine PKI ist für die Verwendung von EFS nicht erforderlich, jedoch verbessert die Verwendung öffentlicher Schlüssel die EFS-Verwaltbarkeit.

Computerzertifikate werden normalerweise von kryptografischen Anwendungen oder Techniken verwendet, die einen bestimmten Computer identifizieren müssen. Beispiele hierfür sind das Sichern der Kommunikation zwischen bestimmten Systemen in einem Netzwerk mit IPSec, oder das Sichern von VPN-Tunneln über ein öffentliches Netzwerk. Beim Sichern einer Website mit SSL werden ebenfalls Computerzertifikate verwendet.

Die Anzahl der für jeden Benutzer oder Computer erforderlichen Zertifikate hängt außerdem von der Verwendungsweise der einzelnen Zertifikate ab. In einigen Fällen erfüllt ein Zertifikat alle Anforderungen. In anderen Fällen können mehrere Zertifikate erforderlich sein. Bei Microsoft verfügt ein typischer Benutzer z. B. über vier Zertifikate pro Jahr: ein Zertifikat zum Sichern von E-Mail, ein Zertifikat für Smartcardanmeldung, ein Zertifikat für EFS und möglicherweise ein weiteres Zertifikat für drahtlose 802.1X-Verbindungen.

Registrierungen für Benutzer- und Computerkonten in Ihrer Domäne oder einer Domäne eines Partners werden anders als Zertifikatregistrierungen für öffentliche Benutzer und Computer verarbeitet. Für EFS kann z. B. intern Active Directory zum Bereitstellen der Zertifikate für Benutzer über Gruppenrichtlinien verwendet werden. Wenn Sie jedoch clientseitige Zertifikatzuordnung auf einer öffentlich zugänglichen Website einsetzen, müssen Sie einen öffentlich zugänglichen Zertifikatverteilungspunkt implementieren. Dieser öffentlich zugängliche Zertifikatverteilungspunkt kann entweder die Zertifizierungsstelle eines Drittanbieters oder eine webaktivierte, selbst ausgeführte Zertifizierungsstelle sein.

Wenn der Computer, der Zertifikate erfordert, innerhalb der Firewall positioniert ist und über ein Domänenkonto verfügt, können die automatischen Registrierungsfunktionen von Active Directory verwendet werden. Gruppenrichtlinien unter Windows 2000-Active Directory unterstützen die automatische Registrierung für Computerzertifikate. Wenn die automatische Registrierung konfiguriert wird, werden die angegebenen Zertifikattypen automatisch für alle Computer ausgestellt, die sich im Geltungsbereich der Gruppenrichtlinie befinden und über Registrierungsberechtigung für diesen Zertifikattyp verfügen. Zertifikate werden bei der nächsten Anmeldung des Computers am Netzwerk ausgestellt. Gruppenrichtlinien unter Windows Server 2003 unterstützen die automatische Registrierung für Benutzer- und Computerzertifikate.

Computer außerhalb der Firewall müssen manuelle Registrierungstechniken, wie den Zugriff auf eine webaktivierte Zertifizierungsstelle, verwenden. In diesem Fall muss die Sicherheit der webaktivierten Zertifizierungsstelle sorgfältig untersucht werden, wenn die Platzierung in einem überwachten Subnetz erfolgt, das als DMZ (Demilitarized Zone oder demilitarisierte Zone) bezeichnet wird. Techniken zum Sichern dieser Zertifizierungsstelle sind z. B. RADIUS (Remote Authentication Dial-In User Service) oder Authentifizierung am Zertifikatveröffentlichungspunkt. In diesem Fall sind eine weitere Untersuchung, sowie möglicherweise das Erstellen besonderer Firewallregeln, erforderlich.

Schließlich hat OTG die Registrierungs- und Erneuerungsanforderungen für jedes Zertifikat ausgewertet. Die Erneuerung kann für alle Zertifikatclients automatisch erfolgen, die ihre Zertifikate automatisch registrieren. Für die manuell registrierten Clients musste ein manueller Erneuerungsprozess implementiert werden.

OTG hat ermittelt, dass für Microsoft die Ausstellung der folgenden internen Benutzerzertifikate erforderlich war:

Für Administratoren:

• EFS-Wiederherstellungszertifikate.
• Smartcard-Registrierungs-Agent-Zertifikate.

Für Endbenutzer:

• S/MIME-Signaturzertifikate.
• S/MIME-Verschlüsselungszertifikate.
• 802.1X-Clientauthentifizierungszertifikate.
• Smartcard-Anmeldezertifikate.
• EFS-Zertifikate.

Microsoft benötigte die folgenden internen Computerzertifikate für IT-verwaltete Computer:

• IPSec-Zertifikate.
• Domänencontrollerzertifikate.
• SSL-Zertifikate.

OTG erkannte außerdem Bedarf für eine Zertifizierungsstelle, die zum digitalen Signieren und Verschlüsseln von E-Mail zwischen Microsoft-Mitarbeitern und externen Empfängern verwendet wird. Durch die Möglichkeit der externen Verwendung der von dieser Zertifizierungsstelle ausgestellten Zertifikate mussten bestimmte Informationen außerhalb der Unternehmensnetzwerkumgebung zur Verfügung gestellt werden.

Zum Seitenanfang

Festlegen der Stammzertifizierungsstelle

Vor der Planung der Zertifizierungsstellenhierarchie musste OTG eine Entscheidung hinsichtlich der Stammzertifizierungsstelle treffen. Wie bereits erläutert, kann diese Stammzertifizierungsstelle durch einen Drittanbieter ausgeführt oder selbst betrieben werden.

Beim Verwenden eines öffentlichen Stamms eines Drittanbieters kann eine einfache B2C-Architektur (Business-to-Consumer) verwendet werden. Die meisten Internetbrowser, einschließlich Microsoft Internet Explorer, enthalten integrierte Stämme . Dies bedeutet, dass der Browserhersteller bereits Vertrauensstellungen für viele der öffentlichen Stämme, die im Internet betrieben werden, konfiguriert hat. Wenn ein Webserver über ein SSL-Zertifikat verfügt, das mit einem Drittanbieterhost verkettet ist, dem alle Internetbrowser im Web vertrauen, können kryptografische Geschäfte mit Hilfe von SSL mit beliebigen Benutzern durchgeführt werden. Viele kommerzielle Zertifizierungsstellen haben ihre Stammzertifikate bereits in kryptografischen Clients wie Internet Explorer installiert. Diese bereits installierten Stammzertifikate ermöglichen den Clients, den von der Zertifizierungsstelle ausgegebenen Zertifikaten zu vertrauen. Dies bedeutet, dass das Auswählen einer dieser kommerziellen Zertifizierungsstellen als Stammzertifizierungsstelle die Clientkonfiguration vereinfacht.

Wenn der Client jedem Zertifikat vertraut, das von dem Drittanbieterhost zur Verfügung gestellt wird, werden komplexere kryptografische B2B-Beziehungen schwieriger zu konfigurieren. Für eine Organisation ist es möglicherweise erforderlich, dass ein Geschäftspartner nur einer Untermenge aller Zertifikate vertraut, die innerhalb dieser Organisation verwendet werden. Ein Partner muss z. B. den Zertifikaten vertrauen, die von SSL zum Schutz der Kommunikation mit einer bestimmten Website verwendet werden, nicht jedoch Zertifikaten, die von SSL für andere Websites eingesetzt werden. Wenn der Stamm vertrauenswürdig ist, ist die gesamte Hierarchie vertrauenswürdig. Außerdem können die Kosten einen Faktor für große Organisationen oder Organisationen mit hoher Webpräsenz darstellen, weil die meisten Drittanbieter mit ihren Kunden auf der Basis einzelner Zertifikate abrechnen.

Selbst ausgeführte Stammzertifizierungsstellen ermöglichen die einfache Übernahme der komplexen Anforderungen an B2B-Kommunikation, indem der Geschäftspartner so konfiguriert wird, dass er der entsprechenden selbst ausgeführten Zertifizierungsstelle vertraut. Die Konfiguration der B2C-Kommunikation wird komplizierter, weil die integrierten Stämme in Browsern keine Vertrauensstellungen für die selbst ausgeführte Stammzertifizierungsstelle enthalten.

OTG hat ursprünglich einen selbstsignierten Stamm konfiguriert, später jedoch aufgrund der hohen Kosten der SSL-Zertifikatanforderungen für Microsofts öffentlichkeitsorientierte Websites entschieden, eine parallele Hierarchie unter einem öffentlichen Stamm hinzuzufügen.

Unabhängig davon, welchen Typ von Stammzertifizierungsstelle eine Organisation auswählt, müssen zahlreiche Erwägungen berücksichtigt werden:

• Zuerst müssen die Anforderungen an die Zertifizierungsstellenkapazität, -leistung und -skalierbarkeit ausgewertet werden. Bei der anfänglichen Ausstellung von Zertifikaten für die Benutzer oder Computer, die diese benötigen, ist die Anzahl der auszustellenden Zertifikate hoch, ebenso wie die belegte Netzwerkbandbreite. Da es sich hierbei um viele Hunderte von Zertifikaten, oder sogar Tausende pro Minute, handeln kann, müssen die belegten Netzwerkressourcen aktiv verwaltet werden. Wenn sich die Zertifikatclients erneut für ihre Zertifikate registrieren, diktieren die Zertifikaterneuerungszyklen den laufenden Registrierungszeitplan. Auf diese Weise kann das IT-Personal den Netzwerkbedarf im Lauf der Zeit angleichen.

Die Stammzertifizierungsstelle sollte niemals zum Ausstellen von Zertifikaten für die Zertifikatclients verwendet werden. Eine geografische Verteilung kryptografischer Clients würde übermäßige Bandbreite für die Stammzertifizierungsstelle bedeuten und verlangen, dass die Stammzertifizierungsstelle immer online ist. Eine Stammzertifizierungsstelle, die online ist, ist ein nicht akzeptables Sicherheitsrisiko für jedes Unternehmen, das eine PKI ausführt.

Da die Stammzertifizierungsstelle nur zum Ausstellen von Zertifikaten an eine ausstellende Zertifizierungsstelle oder eine Zwischenzertifizierungsstelle verwendet wird, muss die Kapazität und Leistung aller ausstellenden Zertifizierungsstellen sorgfältig überwacht und verwaltet werden. Die Kapazität und Leistung kann durch sorgfältige Versionsverwaltung und Projektplanung verwaltet werden. Die Leistung der Stammzertifizierungsstelle ist weniger wichtig, da sie nur verwendet wird, wenn eine neue Zwischenzertifizierungsstelle oder ausstellende Zertifizierungsstelle online geschaltet, der Ablaufzeitpunkt zuvor ausgestellter Zertifikate erreicht, oder ihre Zertifikatsperrliste veröffentlicht wird.

• Ein großer Teil der Leistungsfähigkeit einer Windows 2000- oder Windows Server 2003-PKI beruht auf der Integration mit Active Directory. Bei Microsoft müssen die Offlinestamm- und die Zwischenzertifizierungsstellen eigenständige Zertifizierungsstellen sein, die ausstellenden Onlinezertifizierungsstellen können jedoch trotzdem Unternehmenszertifizierungsstellen sein.

Die Active Directory-Struktur ist ein weiteres Schlüsselelement im Entwurfsvorgang. Der Active Directory-Dienst stellt ein einfaches Verfahren zum Implementieren automatischer Registrierung zur Verfügung. Wenn der Plan für die PKI eine unter den Zertifikatdiensten von Windows 2000 oder Windows Server 2003 implementierte Zertifizierungsstelle umfasst, ist eine Active Directory-Gesamtstruktur die Grenze für die PKI.

• Die Zertifikatdienste von Microsoft Windows 2000 und Windows Server 2003 bieten zwei Arten von Zertifizierungsstellenrichtlinien: eigenständige und Unternehmensrichtlinien. Beim Entwerfen einer PKI muss eine Entscheidung getroffen werden, ob in der Hierarchie eigenständige oder Unternehmensrichtlinien bereitgestellt werden, oder eine Mischung aus beidem.

Durch die Installation dieser Zertifizierungsstellentypen durch einen Active Directory-Stammdomänenadministrator oder Organisationsadministrator, werden Container und Objekte erstellt, die PKI-Informationen in Active Directory enthalten. Durch die Installation von Unternehmens-Stammzertifizierungsstellen wird außerdem automatisch das Stammzertifikat in Active Directory platziert, und alle Clients im Unternehmen erhalten automatisch Kopien des Zertifikats dieser Zertifizierungsstelle. Zertifikate der Unternehmens-Stammzertifizierungsstelle werden automatisch in Active Directory gespeichert. Zertifikate der eigenständigen Stammzertifizierungsstelle können mit dem Windows 2000 Resource Kit-Tool dsstore.exe in Active Directory gespeichert werden.

Die Hauptunterschiede zwischen einer Unternehmenszertifizierungsstelle und einer eigenständigen Zertifizierungsstelle sind die Notwendigkeit von Active Directory, die Authentifizierungsmechanismen und die Verwendung von Zertifikatvorlagen. Unternehmenszertifizierungsstellen verwenden RPC-Identitätswechsel (Remote Procedure Call oder Remoteprozeduraufruf) für das Authentifizieren von Anforderern, sowie zum Vergleichen des Clientzugriffstokens mit der Zugriffssteuerungsliste (Access Control List oder ACL), die für eine Zertifikatvorlage in Active Directory festgelegt wurde, und erfordern aus diesem Grund Active Directory. Zertifikatvorlagen werden zum Erstellen von Zertifikaten für einen bestimmten Zweck verwendet und können auf bestimmte Gruppen von Benutzern oder Computern durch Verwenden einer Zugriffssteuerungsliste beschränkt werden, die in Active Directory festgelegt wird.

Eigenständige Zertifizierungsstellen verlangen Active Directory nicht. Für Standardkonfigurationen eigenständiger Zertifizierungsstellen sind Verwaltungsmaßnahmen erforderlich, um die Identität des Anforderers zu überprüfen und das Zertifikat auszustellen. Alle Anforderungen werden bei eigenständigen Zertifizierungsstellen standardmäßig als "ausstehend" festgelegt und müssen über das MMC-Snap-In (Microsoft Management Console) Zertifizierungsstelle überprüft und ausgestellt werden. Dies ist für große Unternehmen wie Microsoft unpraktisch, insbesondere in Anbetracht der großen Anzahl von Computern, die auf Routinebasis für Produktentwicklung und zu Testzwecken neu erstellt werden und daher neue Zertifikatanforderungen auslösen.

OTG hat aus Sicherheitsgründen beschlossen, dass die Microsoft-Stammzertifizierungsstelle niemals mit dem Netzwerk verbunden sein wird. Dies bedeutet, dass sie niemals einer Domäne beitreten und nicht als Unternehmenszertifizierungsstelle installiert werden kann.

Die Zertifizierungsstellenarchitektur von OTG besteht aus einer Hierarchie von eigenständigen Offline- und Online-Unternehmenszertifizierungsstellen. Die Zertifikate der eigenständigen Offlinezertifizierungsstelle werden in der entsprechenden Active Directory-Gesamtstruktur mit dem Resource Kit-Tool dsstore.exe veröffentlicht.

Zum Seitenanfang

Festlegen der Zertifizierungsstellenhierarchie

Beim Festlegen der Zertifizierungsstellenhierarchie hat OTG die beiden Anforderungen berücksichtigt, die Stammzertifizierungsstelle zu schützen und Zertifikate zur Verfügung zu stellen.

Die Zertifizierungsstellenhierarchie enthält mehrere Zertifizierungsstellen mit klar definierten über- und untergeordneten Elementen. In diesem Modell werden die untergeordneten Zertifizierungsstellen durch Zertifizierungsstellenzertifikate zertifiziert, die durch das direkt übergeordnete Element ausgestellt werden. Sie binden den öffentlichen Schlüssel einer Zertifizierungsstelle an ihre Identität. Die oberste Zertifizierungsstelle in der Hierarchie wird als Stammzertifizierungsstelle bezeichnet.

Wenn ein Client einer Stammzertifizierungsstelle vertraut (indem das Zertifikat der Stammzertifizierungsstelle in seinem Informationsspeicher Vertrauenswürdige Stammzertifizierungsstellen gespeichert wird), vertraut er auch jeder untergeordneten Zertifizierungsstelle in der Hierarchie - es sei denn, einer untergeordneten Zertifizierungsstelle wurde das Zertifikat durch die ausstellende Zertifizierungsstelle gesperrt, oder das Zertifikat ist abgelaufen. Daher ist die Stammzertifizierungsstelle die wichtigste Vertrauensbasis in einer Organisation und sie sollte dementsprechend gesichert und verwaltet werden.

Der Vorteil dieses Modells besteht darin, dass die Überprüfung von Zertifikaten nur Vertrauenswürdigkeit in einer kleinen Anzahl von Zertifizierungsstellen erfordert. Es bietet Flexibilität, weil mehrere untergeordnete Zertifizierungsstellen ermöglicht werden, die ihrerseits über untergeordnete Elemente verfügen können. Es gibt verschiedene praktische Gründe für das Bereitstellen mehrerer untergeordneter Zertifizierungsstellen: Zertifizierungsstellen, die Zertifikate nur für eine bestimmte Verwendung ausstellen, Zertifizierungsstellen, die Zertifikate für einen bestimmten Standort ausstellen, oder das Vorhandensein verschiedener Zertifikatrichtlinien für verschiedene Geschäftseinheiten.

Dieser Entwurf ermöglicht OTG das regelmäßige Erneuern von Schlüsseln und Zertifikaten für die Zwischen- und ausstellenden Zertifizierungsstellen, die einem hohen Angriffsrisiko unterliegen, ohne dass eine Änderung der etablierten Stammvertrauensstellungen erforderlich ist.

Die PKI bestand anfangs aus 13 Zertifizierungsstellen, die mit den Windows 2000-Zertifikatdiensten implementiert und wie in Abbildung 4 unten gezeigt bereitgestellt wurden. Beachten Sie, dass 'x2' bedeutet, dass aus Redundanzgründen zwei Server installiert wurden.

Abbildung 4: Ursprünglicher PKI-Entwurf bei Microsoft

Dieser ursprüngliche Entwurf beinhaltete, dass die Microsoft-Unternehmensstammautorität sowie die beiden Zwischenzertifizierungsstellen niemals mit dem Netzwerk verbunden werden und in einem Offline-Sicherheitstresor gesichert bleiben. Die physische Sicherheit in Kombination mit eingeschränktem Zugriff gewährleistet, dass die Sicherheit der digitalen Identität des Unternehmens nicht gefährdet wird. Der Zweck der Stammzertifizierungsstelle und der beiden Zwischenzertifizierungsstellen besteht darin, die Zertifikate der in der Hierarchie untergeordneten Zertifizierungsstellen zu signieren (und ggf. zu sperren). Dabei handelt es sich um einen manuellen Vorgang, der physischen Zugang zu den entsprechenden Tresoren erfordert.

Der Entwurf sah vor, dass die der Microsoft-Intranetzertifizierungsstelle und der Microsoft-Extranetzertifizierungsstelle untergeordneten Zertifizierungsstellen für das Ausstellen von Zertifikaten für Endbenutzer verantwortlich sind und jederzeit online und für Dienstanforderungen verfügbar sein müssen. Aufgrund dieser Anforderung bezüglich hoher Verfügbarkeit wurden aus Redundanzgründen zwei Zertifizierungsstellen pro Funktion zur Verfügung gestellt.

Die folgenden Stamm- und untergeordneten Zertifizierungsstellen waren vorhanden:

• Die Microsoft-Unternehmensstammautorität. Dies war der Stamm der PKI-Unternehmenshierarchie. Sie wurde zum Signieren, Zertifizieren und Sperren untergeordneter Zertifizierungsstellen verwendet.

OTG hat für die Zertifizierungsstelle eine Lebensdauer von acht Jahren mit einem Veröffentlichungsintervall von 90 Tagen für die Zertifikatsperrliste definiert. Die Zertifikatsperrliste wird in einem externen HTTP-Pfad und in Active Directory veröffentlicht.

• Die Microsoft-Intranet-Zwischenzertifizierungsstelle zertifizierte alle anderen Zertifizierungsstellen, die für interne Zwecke verwendet wurden.
• Die Microsoft-Extranet-Zwischenzertifizierungsstelle zertifizierte alle anderen Zertifizierungsstellen, die für externe Zwecke verwendet wurden.

OTG hat für die Zertifizierungsstelle eine Lebensdauer von acht Jahren mit einem Veröffentlichungsintervall von 90 Tagen für die Zertifikatsperrliste für beide Zwischenzertifizierungsstellen definiert. Die Zertifikatsperrlisten wurden unter HTTP und in Active Directory veröffentlicht.

Die folgenden ausstellenden Zertifizierungsstellen wurden verwendet:

• Die Microsoft-Intranet-Netzwerkzertifizierungsstelle stellte Endeinheitenzertifikate für Dienste aus, die sich auf allgemeine Server-, Benutzer- oder Netzwerkverwaltung beziehen. Sie veröffentlicht ihre Zertifikatsperrliste in Active Directory.
• Die Microsoft-Intranet-Computerzertifizierungsstelle stellte Endeinheitenzertifikate für Computer aus, die sich in der Unternehmensgesamtstruktur befinden. Sie veröffentlicht ihre Zertifikatsperrliste in Active Directory.
• Die Microsoft-Intranet-FTE-Benutzerzertifizierungsstelle stellte Endeinheitenzertifikate für Vollzeitmitarbeiter (FTE-Benutzer oder Full-Time Employees) im Unternehmensnetzwerk für allgemeine Clientauthentifizierung und EFS aus. Diese Zertifizierungsstelle veröffentlicht ihre Zertifikatsperrliste in Active Directory.
• Die Microsoft-Intranet-Nicht-FTE-Benutzerzertifizierungsstelle stellte Endeinheitenzertifikate für Nicht-FTE-Benutzer im Unternehmensnetzwerk für allgemeine Clientauthentifizierung, EFS und Smartcardanmeldung aus. Die Zertifikatsperrliste wurde in Active Directory veröffentlicht.
• Die Microsoft-Personal-E-Mail-Zertifizierungsstelle stellte Endeinheitenzertifikate aus, die für das digitale Signieren und Verschlüsseln von E-Mail verwendet werden. Diese Zertifizierungsstelle veröffentlicht ihre Zertifikatsperrliste auf einer externen HTTP-Site und in Active Directory.

OTG definierte eine zweijährige Lebensdauer für jede dieser ausstellenden Zertifizierungsstellen.

Nach der Bereitstellung erkannte OTG, dass die oben beschriebene Hierarchie zu viele Zertifikatserver enthielt. Der Entwurf der aktuellen Hierarchie weist eine geringere Anzahl ausstellender Intranetzertifizierungsstellen auf, die jedoch jedes beliebige der erforderlichen Zertifikate ausstellen können.

Abbildung 5: Überarbeiteter PKI-Entwurf bei Microsoft

Der neue Entwurf, der in Abbildung 5 dargestellt ist, behält die gleiche definierte Lebensdauer von zwei Jahren für jede der ausstellenden Zertifizierungsstellen bei. Die Zertifikatsperrliste wird in Active Directory veröffentlicht. Die Zertifikatsperrliste wird außerdem in einem externen HTTP-Pfad veröffentlicht, wenn die Zertifizierungsstelle Zertifikate ausstellt, die außerhalb der Microsoft Corporation verwendet werden können. Die Zertifikatsperrliste für die Zertifizierungsstelle, die Zertifikate für S/MIME-E-Mail ausstellt, wird z. B. in einem HTTP-Pfad veröffentlicht, damit Clients im Internet die Zertifikatsperrliste erreichen können.

Lebensdauer eines Zertifikats. Die Zertifikatlebensdauer für die Stamm- und die Zwischenzertifizierungsstellen wurde festgelegt, bevor diese die Zertifikate ihrer untergeordneten Zertifizierungsstellen signierten. Diese Lebensdauer des Zertifikats bestimmt die Lebensdauer der untergeordneten Zertifizierungsstelle.

Die folgende Tabelle gibt die ursprünglichen Zertifikatlebensspannen an, die bei Microsoft konfiguriert wurden:

Zertifizierungsstelle	Lebensspannen der Zertifikate	Lebensdauer der Zertifizierungsstelle
Microsoft-Unternehmensstammautorität	4 Jahre	8 Jahre
Microsoft-Intranetzertifizierungsstelle	2 Jahre	8 Jahre
Microsoft-Extranetzertifizierungsstelle	2 Jahre	8 Jahre
Microsoft-Intranet-Netzwerkzertifizierungsstelle	1 Jahr	2 Jahre
Microsoft-Intranet-Computerzertifizierungsstelle	1 Jahr	2 Jahre
Microsoft-Intranet-FTE-Benutzerzertifizierungsstelle	1 Jahr	2 Jahre
Microsoft-Intranet-Nicht-FTE-Benutzerzertifizierungsstelle	6 Monate	2 Jahre
Microsoft-Personalsignatur-Zertifizierungsstelle	6 Monate	2 Jahre

Lebensdauer der Zertifikatsperrliste. Eine Zertifikatsperrliste besitzt eine festgelegte Lebensdauer, und eine neue Zertifikatsperrliste muss veröffentlicht werden, bevor die alte Zertifikatsperrliste abläuft. Zertifikatdienste übernehmen automatisch die Sperrlistenveröffentlichung für die Onlinezertifizierungsstellen. Die IT-Gruppe hat die Lebensspanne der Sperrlisten für die Onlinezertifizierungsstellen mit 24 Stunden für Benutzerzertifizierungsstellen und einer Woche für die E-Mail- und Computerzertifizierungsstellen konfiguriert.

Da sowohl Windows 2000- als auch Windows Server 2003-Zertifikatdienste vorhanden sind, ist ein Puffer im Sperrlisten-Veröffentlichungsintervall enthalten, der eine bestimmte Zeitspanne definiert, für die vorhandenen Zertifikatsperrlisten nach ihrer nächsten geplanten Sperrlistenveröffentlichung gültig bleiben. Der Zweck dieses Zertifikatsperrlisten-Überlappungszeitraums besteht darin, Zeit für manuelles Veröffentlichen und die Replikation der neu erstellten Zertifikatsperrlisten zu gewinnen, bevor das Original abläuft, sowie dem Vermeiden einer Lücke bei der Verfügbarkeit einer gültigen Zertifikatsperrliste.

Standardmäßig wird der Zertifikatsperrlisten-Überlappungszeitraum als 10 Prozent des Zertifikatsperrlisten-Veröffentlichungsintervalls mit maximal 12 Stunden definiert. Als OTG die Zertifikatsperrlisten-Veröffentlichungsintervalle auf einen kleineren Wert als den Standardwert von einer Woche verringerte, bot diese Überlappung jedoch keinen ausreichenden Puffer, um die vollständige Replikation in der gesamten Netzwerkinfrastruktur zu ermöglichen. In diesem Fall definierte OTG das Zertifikatsperrlisten-Veröffentlichungsintervall manuell als 24 Stunden und den Zertifikatsperrlisten-Überlappungszeitraum als 8 Stunden.

Um den Überlappungszeitraum manuell zu konfigurieren, müssen die Registrierungsschlüssel in Windows Server 2003 bearbeitet werden. Die zu bearbeitenden Einträge finden Sie unter

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\ Configuration\Name_der_Zertifizierungsstelle\

Die Werte lauten

'CRLOverlapUnits'=dword und 'CRLOverlapPeriod'=string.

Die Daten für 'CRLOverlapUnits'=dword sollten numerisch sein und im Dezimalformat vorliegen. Bei den Daten für 'CRLOverlapPeriod' handelt es sich um eine Textzeichenfolge. Diese kann einen der folgenden Zeiträume angeben: Jahre, Monate, Wochen, Tage oder Stunden.

Beachten Sie, dass die Werte in Windows 2000 nicht in der Registrierung enthalten sind und manuell hinzugefügt werden müssen.

Die Zertifikatsperrlistenveröffentlichung für die Offlinezertifizierungsstellen erfolgt manuell. Die Lebensdauer der Sperrlisten für die Offlinezertifizierungsstellen beträgt bei Microsoft 90 Tage. Das PKI-Betriebsteam muss einen Tresor betreten, um die Zertifikatsperrliste aus diesen Offlinezertifizierungsstellen manuell zu veröffentlichen, weil diese normalerweise abgeschaltet sind und niemals über Netzwerkverbindung verfügen.

Zertifikatrichtlinienanweisung. Zertifizierungsstellen verfügen über Zertifikatrichtlinienanweisungen (Certificate Policy Statements oder CPS). Diese werden von der Electronic Commerce and Information Technology Division der American Bar Association definiert als "eine Aussage über die Praktiken, die eine Zertifizierungsstelle beim Ausstellen von Zertifikaten verwendet". Sie schreiben die Verwendung der Zertifizierungsstelle, das Ausmaß der garantierten Sicherheit und die rechtlichen Verpflichtungen vor. Für die OTG-Lösung wurde eine Zertifikatpraxisanweisung (Certificate Practice Statement oder CPS) entwickelt. Dabei handelt es sich um eine gemeinsame Bemühung der Rechtsabteilung von Microsoft und OTG Information Security, weil die CPS Informationen hinsichtlich der Haftung enthält, falls die Sicherheit gefährdet werden sollte. Verweise auf elektronische Versionen dieser Anweisungen sind Teil der Zertifikate. Verweise auf die CPS wurden vor der Installation der Zertifikatdienste durch Bearbeiten der Datei CAPolicy.inf hinzugefügt.

Zum Seitenanfang

Sicherstellen der Integrität des Zertifizierungsstellenservers

Entscheidungen hinsichtlich der Sicherheit, die für eine Zertifizierungsstelle erforderlich ist, verlangen das Ermitteln der Risiken eines Angriffs auf die Zertifizierungsstelle sowie der Kosten, die durch die Gefährdung der Sicherheit einer Zertifizierungsstelle entstehen. Wenn das Risiko eines Angriffs auf die Zertifizierungsstelle hoch ist und die durch die Gefährdung der Sicherheit einer Zertifizierungsstelle entstehenden Kosten ebenfalls hoch sind, rechtfertigt dies höhere Kosten für Sicherheitsmaßnahmen zum Schutz der Zertifizierungsstelle. Für Stammzertifizierungsstellen wird normalerweise höherer Schutz als für ausstellende Zertifizierungsstellen zur Verfügung gestellt.

Nachdem das Risiko eines Angriffs bewertet wurde, müssen die Kosten für alle Sicherheitsschutzmaßnahmen für die Stammzertifizierungsstelle gerechtfertigt werden. Sicherheitsschutz muss nicht teuer sein, insbesondere nicht in kleineren Unternehmen. Der Schutz kann ausreichend sein, wenn die Offline-Stammzertifizierungsstelle in einem sicheren Computerschrank untergebracht ist oder Wechselmedien verwendet werden, die in einem Tresor aufbewahrt werden.

Aus Sicherheitsgründen hat die IT-Gruppe festgelegt, dass die Stammzertifizierungsstelle und die beiden Zwischenzertifizierungsstellen (die Microsoft-Intranetzertifizierungsstelle und die Microsoft-Extranetzertifizierungsstelle) niemals mit dem Netzwerk verbunden werden dürfen und im Offline-Sicherheitstresor gesichert bleiben.

Die ausstellenden Zertifizierungsstellen, die der Microsoft-Intranetzertifizierungsstelle und der Microsoft-Extranetzertifizierungsstelle untergeordnet sind, werden im Online-Sicherheitstresor gesichert.

Zum Seitenanfang

Schützen des privaten Schlüssels der Zertifizierungsstelle

FIPS sind Standards und Richtlinien, die vom National Institute of Standards and Technology (NIST) für die Verwendung in Regierungsbehörden herausgegeben werden. FIPS 140-1 definiert die "Sicherheitsanforderungen für kryptografische Module".

Im Lieferumfang der Zertifikatdienste von Microsoft Windows 2000 ist ein Software-CSP (Cryptographic Service Provider oder kryptografischer Dienstanbieter) enthalten, der mit den Anforderungen von U.S. Federal Information Processing Standard (FIPS) 140-1 konform ist.

Die vom Software-CSP in Windows 2000 generierten Schlüsselpaare werden in der Registrierung archiviert. Dies bedeutet im Fall eines Angriffs auf das System ein erhebliches Sicherheitsrisiko. Mit diesen Schlüsseln könnte ein Angreifer die Zertifizierungsstelle erneut erstellen und scheinbar gültige Zertifikate ausstellen. Dies ist ein typisches FIPS 140-1-Sicherheitsrisiko der Stufe eins, das auf FIPS 140-1, Stufe zwei, herabgestuft werden kann, indem der physische Zugriff auf das Windows 2000-System erschwert und überprüfbar gemacht wird.

Weitere Informationen zu FIPS 140-1 finden Sie auf der National Institute of Standards and Technology-Website (englischsprachig), auf die im Abschnitt "Weitere Informationen" dieses Whitepapers verwiesen wird.

Microsoft hat sich entschlossen, das mit dem Speichern privater Schlüssel verbundene Risiko durch Verwenden von Hardware-CSPs in allen bereitgestellten Zertifizierungsstellen zu verringern. Hardware-CSPs dienen zwei unterschiedlichen Zwecken: Sie bieten zusätzliche Sicherheit für kryptografische Schlüssel, und sie beschleunigen kryptografische Algorithmen und entlasten auf diese Weise die kryptografische Verarbeitung durch die Server-CPUs. Hardware-CSPs schützen private Schlüssel in spezieller, fälschungssicherer Hardware. Dies erhöht ihre Sicherheit, sowie die Sicherheit der Zertifizierungsstelle und von dieser signierten Zertifikaten beträchtlich. Die verwendeten kryptografischen Hardwarebeschleuniger sind für die Konformität mit FIPS 140-1, Stufe drei, zertifiziert. Dies ist wichtig beim Einrichten von Vertrauensstellungen zwischen Microsoft und Geschäftspartnern, z. B. den US-Regierungsbehörden.

Die Hardware-CSPs bei Microsoft können 75 1024-Bit-Schlüsselsignaturen pro Sekunde durchführen, die IT-Gruppe verwendet die Hardware-CSPs jedoch nur für Schlüsselsicherheit, nicht für Beschleunigung.

Zum Seitenanfang

Verwalten integrierter Stämme

Integrierte Stämme sind vom Browserhersteller so vorkonfiguriert, dass sie vielen der öffentlichen Stämme vertrauen, die im Internet ausgeführt werden. Die Clientauthentifizierung eines Servers findet statt, wenn der Client die kryptografischen Signaturen auf dem Zertifikat des Servers und allen Zertifikaten von Zwischenzertifizierungsstellen mit einem Zertifikat der Stammzertifizierungsstelle vergleicht, das im vertrauenswürdigen Stammspeicher auf dem Client gespeichert ist. Die Server-Authentifizierung des Clients findet statt, wenn der Server die kryptografischen Signaturen auf dem Zertifikat des Clients und allen Zertifikaten von Zwischenzertifizierungsstellen mit einem Zertifikat der Stammzertifizierungsstelle vergleicht, das im vertrauenswürdigen Stammspeicher auf dem Server installiert ist.

In kleinen Organisationen oder in Umgebungen, wo es sich als notwendig erweist, vielen verschiedenen Zertifizierungsstellen zu vertrauen, stellen die integrierten Standardstämme unmittelbar einsetzbare Funktionen für die sichere Kommunikation zur Verfügung.

In Organisationen, die ihre Zertifizierungsstellenhierarchie unter einem selbstsignierten Stamm erstellen, muss das Zertifizierungsstellenzertifikat dem Speicher für vertrauenswürdige Stammzertifikate in ihren kryptografischen Clients hinzugefügt werden. Einige Organisationen werden sich dafür entscheiden, alle vertrauenswürdigen, öffentlichen Stammzertifikate aus ihren kryptografischen Clients zu entfernen. Das Ergebnis sind Organisationen, die den selbstsignierten Stamm als einzigen Stamm besitzen, dem ihre Clients vertrauen. Andere Organisationen können den öffentlichen Stämmen auf eingeschränkte Weise, z. B. nur für E-Mail und für Benutzer außerhalb des Namespaces des Unternehmens, vertrauen. Unternehmen sollten Vertrauensstellungen basierend auf ihrer Analyse des Risikos verwalten, das das Vertrauen oder Nichtvertrauen eines bestimmten Stammes mit sich bringt.

Active Directory wirkt in diesem Bereich unterstützend, indem Gruppenrichtlinieneinstellungen zur Verfügung gestellt werden, die die integrierten Vertrauensstellungen konfigurieren können. Eine Gruppenrichtlinieneinstellung wird auf Active Directory-Clients über ein Gruppenrichtlinienobjekt angewendet. Ein Gruppenrichtlinienobjekt kann mit einem Active Directory-Standort, einer -Domäne oder einer -Organisationseinheit verknüpft werden, damit seine Einstellungen auf Benutzer- oder Computerobjekte angewendet werden können, die an diesen Orten gespeichert sind. Gruppenrichtlinienobjekte enthalten einige auf die PKI bezogene Einträge: Einstellungen der automatischen Zertifikatsanforderung , Vertrauenswürdige Stammzertifizierungsstellen , Organisationsvertrauen und Agenten für Wiederherstellung von verschlüsselten Daten . Die in einem Gruppenrichtlinienobjekt konfigurierten Einstellungen, die für Computer definiert werden, werden mit allen Benutzern gemeinsam verwendet, die sich am Computer anmelden, sowie mit allen Diensten, die auf dem Computer ausgeführt werden. Die in einem Gruppenrichtlinienobjekt konfigurierten Einstellungen, die für Benutzer definiert werden, gelten nur auf Benutzerebene.

Wenn das Gruppenrichtlinienobjekt mit den entsprechenden Einstellungen bei der Anmeldung auf den Active Directory-Client angewendet wird, werden die Zertifikate für den angegebenen Unternehmensstamm vom auf dem Verzeichnisdienst basierenden Unternehmensstammspeicher in den lokalen Zertifikatspeicher für vertrauenswürdige Stammzertifizierungsstellen heruntergeladen.

Die Gruppenrichtlinieneinstellungen werden von Clients angewendet, die über die clientseitigen Active Directory-Erweiterungen verfügen. Die clientseitigen Erweiterungen sind zurzeit nur für auf Windows 2000 und Windows XP basierende Computer verfügbar. Ein Unternehmen, das viele verschiedene Betriebssysteme, wie die Betriebssysteme Microsoft Windows NT® oder Microsoft Windows 9 x ausführt, muss andere Verfahren zum Verwalten des Zertifikatspeichers, wie z. B. Anmeldeskriptbefehle verwenden.

Anfangs wurden die integrierten Stämme bei Microsoft verwaltet, indem Anmeldeskripts zum Leeren des Zertifikatspeichers für vertrauenswürdige Stammzertifizierungsstellen und anschließenden erneuten Auffüllen des Speichers mit den entsprechenden Vertrauensstellungen verwendet wurden.

Durch die Einführung der neuen Windows Server 2003-Gruppenrichtlinieneinstellungen ist es nun möglich, die Speicher für vertrauenswürdige Stämme mit einem Gruppenrichtlinienobjekt zu leeren und anschließend erneut aufzufüllen. Ebenso wie die Windows 2000-Gruppenrichtlinie gilt jedoch die Windows Server 2003-Gruppenrichtlinie nur für Active Directory-Clients mit den entsprechenden clientseitigen Erweiterungen, d. h. Windows 2000 und Windows XP.

Bei Microsoft enthalten die Zertifikatspeicher für vertrauenswürdige Stammzertifizierungsstellen auf den Clients nur Stammzertifizierungsstellen, die erforderlich sind, damit Benutzer ihre Aufgaben durchführen können. Die IT-Gruppe entfernt alle integrierten Stämme mit Ausnahme der Stämme, die für den Zugriff auf Legacyanwendungen oder Websites erforderlich sind, und füllt diesen Speicher dann erneut mit Stammzertifizierungsstellen auf, die die einzelnen Benutzer für ihre Aufgaben benötigen. Zu diesem Zweck werden Gruppenrichtlinienobjekte für Computer verwendet, die Windows 2000 und Windows XP ausführen. Für Computer, die frühere Versionen von Windows ausführen, verwendet OTG Anmeldeskripts.

Alle Unternehmen, die eine PKI verwenden, müssen jeden einzelnen integrierten Stamm in der Clientsoftware, die sie verwenden werden, untersuchen. Als Entwickler erstmals Webbrowser implementierten, war die Möglichkeit der Benutzer, auf beliebige Websites zugreifen zu können, eine der Hauptanforderungen, und alle Browserhersteller implementierten integrierte Stämme im Hinblick auf Browserfunktionen statt auf Sicherheit. Als dann E-Commerce und Online-Banking immer beliebter wurden und die Priorität von Sicherheit stieg, wurde es zunehmend wichtiger, alle Stammzertifizierungsstellen, denen der Browser vertraut, zu untersuchen.

Um die Entscheidung zu vereinfachen, welchen Stammzertifizierungsstellen vertraut werden soll, und als Reaktion auf Befürchtungen hinsichtlich der Risiken der Verwendung einer häufig falsch verstandenen und wenig vertrauenswürdig erscheinenden Technologie, haben das American Institute of Certified Public Accountants (AICPA) und das Canadian Institute of Certified Accountants (CICA) eine Sammlung von Prinzipien und Kriterien für die Verwendung in webbasierten Geschäftsvorgängen entwickelt. Diese Prinzipien und Kriterien werden als Web Trust (Webvertrauen) bezeichnet und basieren auf bewährten Methoden, die von AICPA und CICA ermittelt wurden. Web Trust bedeutet, dass geprüfte Buchhalter in den USA und ihre internationalen Kollegen Onlinegeschäfte auf ihre Rechtmäßigkeit untersuchen und ermitteln, ob ihre Transaktionen sicher durchgeführt werden, die von Benutzern gesammelten Informationen dem Datenschutz unterliegen, ihre Geschäftspraktiken Kunden vollständig offen gelegt werden und ein Mechanismus zum Lösen von Kundenbeschwerden vorhanden ist.

Weitere Informationen zu Web Trust finden Sie im Abschnitt "Weitere Informationen" am Ende dieses Dokuments.

Zum Seitenanfang

Bereitstellung

Vor der Bereitstellung der Windows 2000-PKI untersuchte die IT-Gruppe die Netzwerkdiagramme für das Unternehmensnetzwerk von Microsoft, um die Testumgebung mit möglichen Szenarien während der umfassenden Bereitstellung zu vergleichen und eine Gegenüberstellung durchzuführen.

Die IT-Gruppe legte den Grundstein für die PKI, indem eine mit Microsoft Windows 2000 Certificate Server implementierte Hierarchie von Zertifizierungsstellen bereitgestellt wurde. Zwar enthält Microsoft Windows NT 4.0 in Kombination mit Internet Information Server (IIS) 4.0 Zertifikatdienste, die IT-Gruppe entwarf die PKI jedoch als Beweis für ihr Konzept auf dem damals aktuellsten Betriebssystem, Windows 2000.

Windows 2000 bietet einen umfassenden Mechanismus zum Ausstellen von Zertifikaten, durch den Microsoft die Vorteile der PKI-Technologie vollständig nutzen kann. Aufgrund der Einhaltung von Industriestandards werden die Zertifikatdienste von Windows 2000 mit beinahe jeder Software von Drittanbietern, die öffentliche Schlüssel verwenden kann, zusammenarbeiten.

Windows 2000 bietet folgende PKI-Features:

• Anwendungen und Dienste, die öffentliche Schlüssel verwenden können. Dies sind z. B. die Internetinformationsdienste, Internet Explorer, der Microsoft Outlook® 2000-Client für Messaging und Zusammenarbeit, Microsoft Outlook Express, EFS, IPSec und Smartcardanmeldung.
• Integration mit Active Directory. Active Directory kann als Veröffentlichungspunkt für Computerzertifikate und Zertifikatsperrlisten verwendet werden.
• Microsoft Zertifikatdienste. Die Zertifikatdienste ermöglichen einer Organisation das Ausstellen eigener Zertifikate und das Implementieren einer eigenen PKI.
• Smartcard-Unterstützung. Ermöglicht einer Organisation das Verwenden von Smartcards für Schlüsselspeicherung und kryptografische Operationen (zusätzlich zu Anmeldungen).
• Richtlinien öffentlicher Schlüssel in der Gruppenrichtlinie. PKI-Gruppenrichtlinien ermöglichen Administratoren die Kontrolle über die externen Zertifizierungsstellen, denen Benutzer und Computer vertrauen können.

Zum Seitenanfang

Bereitstellen von Microsoft Windows 2000-Zertifikatdiensten

Die Hardware der Offline-Stammzertifizierungsstelle wurde im Offline-Sicherheitstresor installiert. Die Offlineserver bei Microsoft wurden unter Beachtung der Standardrichtlinien für Dienstprogrammserver erstellt. Die Offline-Stammzertifizierungsstellen werden selten und ausschließlich zum Ausstellen einzelner Zertifikate verwendet. Die IT-Gruppe hat ermittelt, dass die Offlinezertifizierungsstellen-Server über einen internen SCSI-Bus (Small Computer System Interface) für die Verbindung mit dem Hardware-CSP verfügen müssen, um die Sicherheitsstufe der Microsoft-PKI auf FIPS 140-1, Sicherheitsstufe drei, zu erhöhen. Die Hardware der Offline-Zwischenzertifizierungsstelle unterliegt den gleichen Richtlinien.

Die Hardware der ausstellenden Onlinezertifizierungsstelle wurde im Onlinesicherheitstresor installiert. Als Hardwarestandards galten die Standardhardwarespezifikationen für Dienstprogrammserver. Verwendet wurde ein Compaq ProLiant 1850R mit zwei Intel Pentium III-Prozessoren und 192 MB RAM. Der Server enthielt außerdem einen Compaq Array Controller sowie zwei während des Betriebs austauschbare Festplattenlaufwerke mit 9,1 GB. Auf jedem Server wurde ein Hardware-CSP installiert.

Windows 2000 Advanced Server, sowie alle damals aktuellen Hotfixes und Service Packs, wurden auf jedem der Zertifizierungsstellenserver installiert. Die Onlinezertifizierungsstellen wurden anschließend als Mitgliedsserver in der Active Directory-Gesamtstruktur des Unternehmensnetzwerks installiert.

Die Stamm- und Zwischenzertifizierungsstellen-Server sind nicht Teil des Unternehmensnetzwerks oder in Active Directory integriert. Die ausstellenden Zertifizierungsstellenserver sind im Netzwerk für Benutzer und Partnerorganisationen sichtbar. Die ausstellenden Zertifizierungsstellenserver führen die Zertifikatverwaltungsprozesse einschließlich Ausstellung und Sperrung aus.

Die IT-Gruppe hat anschließend das Feature Microsoft Zertifikatdienste auf jedem der Zertifizierungsstellenserver installiert und konfiguriert. Zuerst wurden die Stammzertifizierungsstellen ganz oben in der Hierarchie diesem Verfahren unterzogen, dann folgten absteigend die Zwischenzertifizierungsstellen und schließlich die ausstellenden Zertifizierungsstellen.

Die IT-Gruppe hat die PKI durch nur einen Mitarbeiter bereitgestellt, jedoch können der physische Standort der Zertifizierungsstellenserver und die Zeitpläne bei anderen Bereitstellungen zu einem erhöhten Personalbedarf führen.

Während der Installation und Konfiguration der Microsoft Zertifikatdienste und der Hardware-CSPs hat die IT-Gruppe Folgendes konfiguriert:

Veröffentlichen von Offlinezertifizierungsstellen in Active Directory. Die Offline-Stammzertifizierungsstelle wurde in Active Directory mit dsstore.exe veröffentlicht, einem Befehlszeilen-Dienstprogramm, das zum Veröffentlichen von Zertifikaten von eigenständigen Zertifizierungsstellen in Active Directory zur Verfügung steht.

Für die Offline-Zwischenzertifizierungsstellen wurde der Zugriff auf Stelleninformationen (Authority Information Access oder AIA) ebenfalls in Active Directory veröffentlicht. Diese Angabe nennt Speicherorte, von denen Benutzer das Zertifikat für die Zertifizierungsstelle erhalten können.

Sperrlisten-Verteilungspunkt. Der Sperrlisten-Verteilungspunkt (CRL Distribution Point oder CDP) ist Teil jedes ausgestellten Zertifikats. Die Onlinezertifizierungsstellen verlangen während der Installation der Zertifizierungsstelle manuelle Eingaben mit Hilfe des Installations-Assistenten.

Der Sperrlisten-Verteilungspunkt der Offlinezertifizierungsstelle wurde vor der Installation der Zertifikatdienste durch Bearbeiten der Datei CAPolicy.inf geändert. Die Zertifikatsperrlisten für die Offlinezertifizierungsstellen werden ebenfalls in Active Directory mit dem Dienstprogramm dsstore.exe veröffentlicht, das im Windows Server 2003 Resource Kit zur Verfügung steht.

Zertifikate, die ausgestellt werden können. Die ausstellenden Zertifizierungsstellen wurden auf das Ausstellen nur der Zertifikate eingeschränkt, die für ihre Funktion erforderlich sind. Dies wurde durch Löschen unerwünschter Zertifikatvorlagen aus dem Container Richtlinieneinstellung im MMC-Snap-In für Zertifizierungsstellen erreicht.

Die folgende Tabelle listet die Zertifikate auf, die durch die Zertifizierungsstellenserver bei Microsoft im ursprünglichen PKI-Entwurf ausgestellt werden konnten:

Zertifizierungsstelle	Ausgestellte Zertifikate
Microsoft-Unternehmensstammautorität	Untergeordnete Zertifizierungsstelle
Microsoft-Intranetzertifizierungsstelle	Untergeordnete Zertifizierungsstelle
Microsoft-Extranetzertifizierungsstelle	Untergeordnete Zertifizierungsstelle
Microsoft-Intranet-Netzwerkzertifizierungsstelle	Administrator, Signatur für die Zertifikatsvertrauensliste (Certificate Trust List oder CTL), EFS-Wiederherstellung, IPSec offline, Router, Registrierungs-Agent
Microsoft-Intranet-Computerzertifizierungsstelle	Domänencontroller, Computer, Webserver, IPSec online
Microsoft-Intranet-FTE-Benutzerzertifizierungsstelle	Clientauthentifizierung, EFS, Smartcardanmeldung
Microsoft-Intranet-Nicht-FTE-Benutzerzertifizierungsstelle	Clientauthentifizierung, EFS, Smartcardanmeldung
Microsoft-Personalsignatur-Zertifizierungsstelle	Exchange-Verschlüsselung, Exchange-Signatur

Im aktuellen Entwurf sind zwei ausstellende Zertifizierungsstellen vorhanden, die sämtliche in der Tabelle genannten Zertifikate mit Ausnahme der Zertifikate der untergeordneten Zertifizierungsstelle ausstellen können.

Mit der Konfiguration zum Zeitpunkt der Erstellung dieses Dokuments haben von OTG durchgeführte Tests ergeben, dass eine maximale Zertifikatausstellungsrate von zwei Zertifikaten pro Sekunde für ein RAID 5-Datenträgerarray mit den Zertifikatdiensten von Windows 2000 erreicht wird.

Zum Seitenanfang

Bereitstellen von Microsoft Windows Server 2003-Zertifikatdiensten

Die IT-Gruppe hat mehrere neue PKI-Features und -Optimierungen in Windows Server 2003 als Teil der Tests in der tatsächlichen Produktionsumgebung von Microsoft vor der Freigabe bewertet und getestet. Die wichtigsten Verbesserungen der in Windows Server 2003 enthaltenen Zertifikatdienste beziehen sich auf Folgendes:

• Unterstützung für Industriestandards. Die PKI-Dienste von Windows Server 2003 unterstützen alle aktuellen Zertifikatanforderungsnachrichten nach Industriestandard.
• FBCA-Interoperabilität (Federal Bridge CA). Die PKI von Windows Server 2003 erfüllt die Anforderungen für FBCA-Interoperabilität. Nachdem die vollständigen Tests erfolgreich abgeschlossen werden konnten und das Produkt für die Fertigung freigegeben ist, wird die Regierung Microsoft auffordern, die Windows Server 2003-Zertifizierungsstellen in die Betriebs-FBCA zu integrieren.
• Zertifizierungsstellenverwaltung. Ein Feature "qualifizierte Unterordnung" wurde der Zertifizierungsstelle von Windows Server 2003 hinzugefügt. Eine übergeordnete Zertifizierungsstelle kann nun bestimmte Einschränkungen auf eine untergeordnete Zertifizierungsstelle anwenden, z. B. Namenbeschränkungen, Richtlinien, Richtlinienbeschränkungen und Richtlinienzuordnungen. Dies ist in den Fällen sinnvoll, in denen die übergreifende Zertifizierung einer Zertifizierungsstelle mit der Zertifizierungsstelle einer anderen Organisation erforderlich ist und Einschränkungen für die Zertifizierung gelten müssen. Die Zertifizierungsstelle erlaubt die Definition verschiedener Betriebsrollen, damit die Verantwortlichkeiten und dementsprechend die Berechtigungen von Zertifizierungsstellenadministratoren und Zertifikatausstellern getrennt werden können.
• Automatische Registrierung. Die Windows Server 2003-Zertifizierungsstelle kann für die automatische Registrierung von Benutzer- und Computerzertifikaten konfiguriert werden. Benutzer können bei der erstmaligen Anmeldung an einer Domäne Zertifikate verschiedenen Typs erhalten (z. B. EFS, Signatur, E-Mail-Verschlüsselung oder Smartcardanmeldung).
• Delta-Zertifikatsperrlisten. Die Zertifizierungsstelle kann in regelmäßigen Intervallen Delta-Zertifikatsperrlisten generieren. Dies verbessert die Leistung der Zertifikatsperrlistenveröffentlichung, da nur die Änderungen aus der vorherigen Zertifikatsperrliste verteilt werden.
• Schlüsselarchivierung und -wiederherstellung. Die Zertifizierungsstelle kann den privaten Schlüssel eines Benutzers archivieren, wenn er generiert wird. Der Schlüssel wird mit dem öffentlichen Schlüssel der Zertifizierungsstelle verschlüsselt. Alle Wiederherstellungs-Agenten der Zertifizierungsstelle können den verschlüsselten Schlüssel entschlüsseln, damit er dem Benutzer zur Verfügung gestellt werden kann, sollte der Benutzer den privaten Schlüssel verlieren. Dies ist in Unternehmensszenarien sinnvoll, weil der Verlust des Schlüssels häufig vorkommt. Diese Vorgehensweise ändert jedoch das Sicherheitsparadigma: nun ist ein anderer Agent als der Benutzer im Besitz des privaten Schlüssels. Die Schlüsselarchivierung und -wiederherstellung muss einwandfrei verwaltet werden, damit die Vertrauensstellungen nicht gefährdet sind.
• CAPICOM. CAPICOM ist kein Bestandteil der Zertifizierungsstelle, sondern eine einfach zu verwendende Schnittstelle zur CryptoAPI. CAPICOM ermöglicht die Integration von PKI-Funktionen in Anwendungen, indem eine einfache Benutzeroberfläche zum Suchen nach dem Zertifikatspeicher und Verwenden von Zertifikaten zum Signieren oder Verschlüsseln von Daten zur Verfügung gestellt wird. Es ist nun möglich, eine Signier- oder Überprüfungsoperation mit wenigen Zeilen in Microsoft Visual Basic®-Entwicklungssystemcode durchzuführen.

Weitere Informationen zu CAPICOM finden Sie im Abschnitt "Weitere Informationen" am Ende dieses Dokuments.

Alle diese Features sind in Industriestandards wie X.509, LDAP, SSL/TLS, S/MIME, IPSec und in der Erweiterung öffentlicher Schlüssel von Kerberos implementiert, die die Interoperabilität mit Anwendungen und PKIs von Drittanbietern ermöglichen.

Die IT-Gruppe hat jedes zusätzliche Feature und jede Optimierung von Windows Server 2003 als Teil des Bereitstellungsprojekts vor der Freigabe ausgewertet. Durch umfangreiche Tests konnte die IT-Gruppe beweisen, dass die PKI der Zertifikatdienste von Windows Server 2003 vollständig kompatibel mit der PKI der Zertifikatdienste von Windows 2000 ist. Das Implementieren der Zertifikatdienste von Windows Server 2003 in die vorhandene PKI-Hierarchie besteht einfach im Ersetzen der Windows 2000-Versionen durch Windows Server 2003-Versionen beim nächsten Aktualisierungszyklus für einen Zertifizierungsstellenserver.

Während der Bereitstellung erkannte OTG, dass die vorhandene Hierarchie zu viele Zertifikatserver enthielt. Microsoft-Intranet - Netzwerk, Microsoft-Intranet - Computer, Microsoft-Intranet - FTE-Benutzer, Microsoft-Intranet - Nicht-FTE-Benutzer und Microsoft-Personal-E-Mail. Die neue Hierarchie, die in Abbildung 5 gezeigt wird, weist nur zwei ausstellende Intranetzertifizierungsstellen auf, die jedes beliebige der erforderlichen Zertifikate ausstellen können.

Abbildung 6: Windows Server 2003-PKI-Entwurf bei Microsoft

Der neue Entwurf behält die gleiche definierte Zertifizierungsstellen-Lebensdauer von zwei Jahren mit einem Zertifikatsperrlisten-Veröffentlichungsintervall von 24 Stunden für jede dieser ausstellenden Zertifizierungsstellen bei. Die Zertifikatsperrliste wird in Active Directory veröffentlicht. Die Zertifikatsperrliste wird außerdem in einem externen HTTP-Pfad veröffentlicht, wenn die Zertifizierungsstelle Zertifikate ausstellt, die außerhalb der Microsoft Corporation verwendet werden können. Die Zertifikatsperrliste für die Zertifizierungsstelle, die Zertifikate für S/MIME-E-Mail ausstellt, wird z. B. in einem HTTP-Pfad veröffentlicht, damit Clients im Internet die Zertifikatsperrliste erreichen können.

Als Teil der Testausführung vor der Freigabe erkannte die IT-Gruppe den Bedarf für eine Zwischenzertifizierungsstelle mit einer Zertifikatskette, die zu einem Stamm eines Drittanbieters führt, um Zertifikate für öffentlich verfügbare Webserver ausstellen zu können.

Diese zweite PKI-Hierarchie, die in Abbildung 6 gezeigt wird, wird neben der ursprünglichen PKI-Hierarchie ausgeführt und zurzeit mit den Zertifikatdiensten von Windows Server 2003 erstellt. Der IT-Entwurf für die sekundäre Hierarchie umfasst eine Stammzertifizierungsstelle außerhalb von Microsoft. Es besteht keine dauerhafte Verbindung mit dem externen, öffentlichen Stamm. Die externe, öffentliche Stammzertifizierungsstelle signiert die Zertifikate, die innerhalb von OTGs zusätzlicher Zertifikathierarchie verwendet werden, einmal. Diese Zwischenzertifizierungsstelle stellt ein Zertifikat für ausstellende Zertifizierungsstellen aus, die dann Zertifikate für Microsofts öffentlich zugängliche Websites ausstellen.

Abbildung 7: PKI-Entwurf mit Drittanbieterstamm.

Diese zweite PKI-Hierarchiebereitstellung ähnelt in allen anderen Aspekten der ursprünglichen PKI-Bereitstellung, die zuvor beschrieben wurde. Diese zusätzliche Hierarchie ermöglicht der IT-Gruppe das Ausstellen von SSL-Zertifikaten für öffentlich verfügbare Microsoft-Webserver. Diese SSL-Zertifikate müssen nicht von einem Drittanbieter erworben werden.

Zum Seitenanfang

Verwendete Produkte und Technologien

Die Bereitstellung der Windows 2000- und Windows Server 2003-PKI bei Microsoft ermöglicht die Verwendung kryptografischer Techniken und Anwendungen für sichere Kommunikation und andere Sicherheitsmechanismen. Als die IT-Gruppe das Projekt begann, bestand Bedarf, die zum Steuern der Zertifizierung der eingesetzten Kryptografieanwendungen mit öffentlichen Schlüsseln verwendeten Methoden zusammenzuführen und Unterstützung für diese sowie für zukünftige Techniken zu bieten. Die PKI wurde mit Produkten bereitgestellt, die Zertifizierungsstellenfunktionen nach Industriestandard auf einfach zu installierende Weise zur Verfügung stellen und problemlos in die aktuelle Netzwerkinfrastruktur integriert werden konnten. Die gewählte Methode musste außerdem vereinfachte Verwaltung von Schlüsseln und des Dienstes selbst bieten.

Die Windows 2000-Zertifikatdienste und das Betriebssystem Windows 2000 Advanced Server wurden für die Bereitstellung der ersten PKI-Hierarchie ausgewählt. Windows NT 4.0 mit IIS 4.0 und installierten Zertifikatdiensten kann ebenfalls grundlegende PKI-Funktionen zur Verfügung stellen.

Als Teil des kontinuierlichen Dienstverwaltungsfreigabe- und Überprüfungszyklus wurde die hybride PKI angegeben. Diese wird mit Windows Server 2003 implementiert. Für die hybride PKI-Hierarchie und bei jedem erforderlichen Ersatz in der ursprünglichen Architektur werden die Zertifikatdienste von Windows Server 2003 verwendet.

Die kryptografischen Clienttechniken und Anwendungen, die die von der PKI zur Verfügung gestellten Zertifikate verwenden, umfassen Folgendes:

• S/MIME implementiert in Outlook 2000 und 2002.
• Smartcardanmeldung für Windows 2000 Professional und Windows XP Professional.
• IPSec, implementiert in Windows 2000 Professional und Windows XP Professional.
• IPSec und VPN-Tunnel für Router.
• EFS in Windows 2000 Professional, Windows XP Professional und Windows Server 2003.
• SSL/TLS implementiert auf Windows 2000- und Windows Server 2003-Webservern.

Onlinezertifizierungsstellen werden regelmäßig gesichert. Sollte ein Zertifizierungsstellenfehler auftreten, wird die Zertifizierungsstelle aus der letzten Sicherung wiederhergestellt. Beim Entwerfen der Sicherungsrichtlinien für die Zertifizierungsstelle wurde ein benutzerdefiniertes Beendigungsmodul entwickelt. Dieses Beendigungsmodul führt eine zentralisierte Protokollierungsfunktion in Echtzeit mit Hilfe einer SQL ServerT-Datenbank durch. Diese Datenbank protokolliert die Ausstellung von Zertifikaten und ermöglicht komplexe Abfragen zu Nachverfolgungs- und Überwachungszwecken.

Nach der Wiederherstellung aus der Sicherungskopie kann das Protokoll überprüft werden, damit die nach der Sicherung ausgestellten Zertifikate einwandfrei in die Datenbank der Zertifizierungsstelle eingegeben werden können. Das benutzerdefinierte Beendigungsmodul unterstützt diese Funktion.

Die IT-Gruppe verwendete beim Einrichten der ursprünglichen Windows 2000-PKI eine Kapazitätsplanung. Die Zertifikatserver wurden nur für das Ausstellen von Zertifikaten konzipiert. Der Zugriff auf Zertifikatserver erfolgt normalerweise nur während der Registrierung. Clients müssen in der Regel nicht auf die Zertifizierungsstelle zugreifen, wenn sie Zertifikate in Anwendungen überprüfen. Die einzige zu erwartende hohe Auslastung eines Zertifikatservers in diesem Entwurf findet bei der Verwendung automatisch registrierter Zertifikate statt, wenn die automatische Registrierung in einer Domäne erstmals aktiviert wird.

Nachdem die Clients die Zertifikate registriert haben, verringert sich die Auslastung erheblich und beschränkt sich hauptsächlich auf das Veröffentlichen der Zertifikatsperrlisten und die Erneuerung von Zertifikaten. Die Last kann sich bei der Implementierung neuer kryptografischer Produkte, wie einem unternehmensweiten Rollout von Smartcards, erhöhen. Tests haben gezeigt, dass die Windows 2000-Zertifikatdienste auf ungefähr zwei Zertifikate pro Sekunde beschränkt sind, 7.200 Zertifikate pro Stunde liegen mit Ausnahme der anfänglichen Aktivierung der automatischen Registrierung weit über jeder erwarteten Last. Im Fall der erstmaligen Registrierung warnten Change Management-Verfahren Benutzer, dass ihre Zertifikatanforderungen einfach in eine Warteschlange eingeordnet wurden. Im Lauf der Zeit erreichen die Anforderungen einen stabilen Status, der die Kapazität des Zertifikatservers nicht übersteigt.

Für Windows Server 2003 zeigen die Tests der Zertifikatdienste eine Zunahme der Anzahl der Zertifikate, die pro Stunde ausgestellt werden können. Diese Feststellung belegt, dass Aktualisierungen des PKI-Serverbetriebssystems keine negativen Auswirkungen auf den Entwurf hinsichtlich des Ausstellens von Zertifikaten mit sich bringen.

Prozessor und Arbeitsspeicher sollten kein Problem darstellen. Der angegebene Server war ursprünglich ein Dienstprogramm-Standardserver mit zwei Prozessoren mit 550 MHz, 128 MB RAM und 5 GB Festplattenspeicher.

Der Speicherplatz ist in diesem Entwurf ein mögliches Problem und wird genau überwacht. Jedes Zertifikat belegt ungefähr 10 KB Speicherplatz in der Datenbank. Im Windows 2000-Entwurf gab es keine Möglichkeit, die Datenbank von abgelaufenen Zertifikaten zu bereinigen, daher nahm die Größe der Zertifikatdatenbank kontinuierlich zu. Die Zertifikatdienste von Windows Server 2003 bieten jedoch die Möglichkeit, abgelaufene Zertifikate zu entfernen und Speicherplatz in der Datenbank freizugeben. Der Speicherplatz von 5 GB auf dem Datenbanklaufwerk bietet Platz für 500.000 Zertifikate.

Von Anfang an berücksichtigte der IT-Entwurf für die PKI den Bedarf für eine Infrastruktur zum Beibehalten der Sicherheit gemäß FIPS 140-1, Sicherheitsstufe drei, damit die Sicherheit für Vertrauensstellungen außerhalb von Microsoft gewährleistet werden konnte. Zwar stellt der integrierte Software-CSP in Windows 2000 FIPS 140-1, Sicherheitsstufe eins, zur Verfügung, und die sicheren Microsoft-Online- und Offline-Tresore erhöhen den Standard auf FIPS 140-1, Sicherheitsstufe zwei. Die IT-Gruppe entschied jedoch, dass Sicherheitsstufe drei erreicht werden musste. Zu diesem Zweck werden Hardware-CSPs in allen Zertifizierungsstellen in den Windows 2000- und Windows Server 2003-Implementierungen installiert.

Sechs Mitarbeiter verwalten zum Zeitpunkt der Veröffentlichung des vorliegenden Dokuments den laufenden IT-PKI-Betrieb. Zwei Mitarbeiter im Bereich PKI-Engineering stellen neue kryptografische Lösungen bereit, ihr Aufgabengebiet umfasst z. B. das Verwalten der PKI, das Implementieren neuer Versionen, das Erkennen von Schwachstellen in der aktuellen Infrastruktur und das Vorschlagen neuer Versionen. Die verbleibenden vier Mitarbeiter unterstützen die Endbenutzergemeinde, indem sie Problemberichte bereitstellen, Probleme beheben und ggf. Probleme weiterleiten. Sie führen außerdem die Verwaltung der Zertifizierungsstellen durch, z. B. erstellen sie Sicherungen der Offlinezertifizierungsstellen.

Zum Seitenanfang

Gewonnene Erkenntnisse und zukünftige Pläne

Durch sorgfältiges Auswerten und Bereitstellen einer PKI, die auf den Zertifikatdiensten von Windows 2000 und Windows Server 2003 basiert, konnte die IT-Gruppe wertvolle Erkenntnisse gewinnen, die auf die meisten anderen PKI-Bereitstellungspläne angewendet werden können. Viele dieser Erkenntnisse wurden während der tatsächlichen Bereitstellung gewonnen, einige als Ergebnisse der Bereitstellung.

• Das Verwenden von Schlüsselwiederherstellung in Windows Server 2003, an Stelle der Dateiwiederherstellung in Windows 2000, verringert die Auslastung des Wiederherstellungs-Agenten des Dateidienstes.
• Eine realistische Einschätzung der Anzahl der Zertifizierungsstellen, die bereitgestellt werden müssen. Es ist nicht erforderlich, separate Zertifizierungsstellen für verschiedene Anwendungen zu erstellen. Jede Zertifizierungsstelle kann alle Zertifikate ausstellen, die in der Gesamtstruktur verwendet werden. Die IT-Gruppe erkannte, dass die ursprünglichen Pläne das Bereitstellen einer zu großen Anzahl von Zertifizierungsstellen vorsah. Die Außerbetriebnahme einiger, zu wenig verwendeter Zertifizierungsstellen und das Zusammenführen ihrer Zertifikatvorlagen mit anderen Zertifizierungsstellen führte nicht zu negativen Auswirkungen auf die Leistung, sondern erbrachte erhebliche Einsparungen bei der Serverhardware und der laufenden Verwaltung. In Bereitstellungen für neue Gesamtstrukturen kann die IT-Gruppe alle Zertifikate über nur eine einzige Zertifizierungsstelle ausstellen, jedoch wird eine zweite Zertifizierungsstelle aus Redundanzgründen immer verwendet.
• Erwägen der Implementierung einer Zwischenzertifizierungsstelle mit einem öffentlichen Stamm für öffentlichkeitsorientierte Webdienste. Das ausschließliche Implementieren einer selbstsignierten Stammzertifizierungsstelle kann dazu führen, dass teure SSL-Zertifikate von einem Drittanbieter erworben werden müssen. In dieser Bereitstellung mussten SSL-Zertifikate für jede Website einzeln von einer öffentlichen Zertifizierungsstelle erworben werden. Die IT-Gruppe hat einen neuen Zwischenstamm implementiert, der mit einer öffentlichen Zertifizierungsstelle verkettet ist. Dem Zwischenstamm ist eine ausstellende Zertifizierungsstelle untergeordnet, die SSL-Zertifikate für die öffentlichkeitsorientierten Webserver von Microsoft ausstellen kann. Das Ausstellen der erforderlichen SSL-Zertifikate durch einen Drittanbieter stellte in Microsofts Fall einen erheblichen Kostenfaktor dar. Unter Berücksichtigung des Infrastruktur-Overheads und der Verwaltungskosten des Teams, führt die interne PKI der OTG-Gruppe noch immer zu erheblichen Einsparungen.
• Windows CE 3.0, das Betriebssystem, auf dem die Pocket PC-Plattform aufbaut, unterstützt keine DSA-Schlüssel (Digital Signature Algorithm). Um Benutzer von Pocket PCs, sowie die laufende Produktentwicklung zu unterstützen, erstellte die IT-Gruppe eine neue, ausstellende Zertifizierungsstelle für Pocket PC-Geräte, die direkt, ohne zwischengeschaltete DSA-Schlüssel, mit dem Unternehmensstamm verkettet sind. Zwar verwendet die PKI bei Microsoft nur RSA-Schlüssel, die IT-Gruppe unterstützt jedoch eine Entwicklungs-Testgesamtstruktur, die DSA-Schlüssel ausführt, um Microsofts Kunden, die aus bestimmten Gründen ebenfalls DSA-Schlüssel ausführen müssen, das Konzept zu beweisen.
• Entwickeln einer engen Arbeitsbeziehung zum Hersteller des Hardware-CSPs. Die IT-Gruppe hat ein Problem mit den Hardware-CSPs erkannt, durch das der Zertifizierungsstellendienst nach einer Ausführungszeit von ungefähr 36 Stunden fehlschlägt. Durch das Beenden und anschließende erneute Starten des Zertifizierungsstellendienstes durch eine geplante Batchdatei in einem Intervall von 24 Stunden konnte dieses Problem umgangen werden. Schließlich wurde das Problem durch ausgezeichnete Kommunikation mit dem Hersteller und entsprechende Reaktion des Herstellers behoben.

Die IT-Gruppe bemüht sich unablässig um die Verbesserung der IT-Infrastruktur bei Microsoft. Pläne für die Zukunft umfassen Unterstützung für die automatische Registrierung von S/MIME-Zertifikaten, wenn ein Benutzer an mehreren Computern arbeitet.

Zum Zeitpunkt der Erstellung dieses Dokuments plant die OTG-Gruppe ein Pilotprojekt mit Microsoft Operations Manager (MOM) zum Überwachen der Veröffentlichung der Zertifikatsperrlisten für Anfang 2003.

Zum Seitenanfang

Zusammenfassung

Die IT-Gruppe hat durch Entwerfen, Implementieren und Unterstützen einer PKI mit Hilfe eines selbstsignierten Stammzertifizierungsstellen-Zertifikats und einer separaten hybriden PKI für die Aktivierung weborientierter SSL-Zertifikate ihre Ziele für die Microsoft PKI-Implementierung erreicht: verbesserte Sicherheit, Anwendungskompatibilität und geringere Infrastrukturkosten. Die selbst ausgeführte PKI-Lösung bei Microsoft ist einfach zu verwalten, entspricht Industriestandards und kann skaliert werden, um die Anforderungen einer wachsenden Infrastruktur zu erfüllen.

Erhöhte Sicherheit. Die Mitarbeiter von Microsoft verwenden tagtäglich kryptografische Techniken und Anwendungen. Die Anmeldung am internen Netzwerk erfolgt über Smartcards. Das sichere, drahtlose LAN hat das Sicherheitsniveau für Benutzer mobiler Geräte verbessert. Die Möglichkeit der Verwendung von S/MIME beim Austauschen von E-Mail verleiht Benutzern die Sicherheit, dass niemand außerhalb des Unternehmens für sie bestimmte E-Mail-Nachrichten lesen kann. Über die Intranet- und Internetwebsite können Benutzer vertrauliche Daten auf sichere Weise austauschen.

Anwendungs- und Dienstkompatibilität. Das Bereitstellen einer selbst betriebenen Microsoft-PKI ermöglicht, dass jedes neue Microsoft-Produkt auf Kompatibilität und Interoperabilität mit den Windows 2000- und Windows Server 2003-PKI-Diensten getestet werden kann, bevor die Marktfreigabe erfolgt.

Verringerte Zertifizierungskosten. Das aus sechs Personen bestehende Team, das die PKI bei Microsoft ausführt, hat die Kosten verringert. Vor der Implementierung der aktuellen Infrastruktur waren die Kosten für das Nutzen einer öffentlichen Zertifizierungsstelle eines Drittanbieters für die Zertifikatübermittlung auf der Basis einzelner Zertifikate hoch. Außerdem hat das neue, bei Microsoft implementierte PKI-Modell die erforderliche Supportinfrastruktur verringert.

Problemlose Verwaltung. Da sowohl Windows 2000 als auch Windows Server 2003 gebrauchsfertige PKI-Funktionen bieten, war eine selbst ausgeführte PKI-Lösung außerdem einfach zu implementieren und zu verwalten.

Auf Standards basierende Technologien. Durch das Implementieren einer Unternehmens-PKI kann OTG auf Standards basierende Kryptografietechnologien verwenden, um die Unternehmensressourcen von Microsoft zu sichern, z. B. verschlüsselte Dateisysteme, drahtlose Kommunikation, E-Mail, Remotezugriff und Webserververbindungen.

Skalierbarkeit. OTGs hybride Zertifizierungsstellenhierarchie ist mit einer öffentlichen Zertifizierungsstelle verkettet. In dieser Hierarchie ausgestellte Zertifikate sind mit einer öffentlichen Zertifizierungsstelle verkettet, eine Microsoft-interne ausstellende Zertifizierungsstelle stellt die Zertifikate jedoch aus.

Zum Seitenanfang

Weitere englischsprachige Informationen

Besuchen Sie folgende Website, um das Whitepaper An Introduction to the Windows 2000 Public Key Infrastructure anzuzeigen:https://www.microsoft.com/windows2000/techinfo/howitworks/security/pkiintro.asp

Die MOF-Kurzübersicht finden Sie auf folgender Website:

https://www.microsoft.com/technet/itsolutions/tandp/opex/default.asp

Weitere Informationen zu FIPS-Publikationen finden Sie auf folgender Website:

http://csrc.nist.gov/cryptval/140-1.htm

Weitere Informationen zu CPA-Webvertrauensstellungen finden Sie auf folgender Website:

http://www.cpawebtrust.org

Weitere Informationen zu CAPICON finden Sie auf folgender Website:

https://msdn.microsoft.com/library/en-us/dnsecure/html/intcapicom.asp

Besuchen Sie folgende Website, um weiteres IT Showcase-Material anzuzeigen: https://www.microsoft.com/technet/itsolutions/msit/default.mspx.

Fragen, Kommentare oder Vorschläge zum vorliegenden Dokument oder Anforderungen weiterer Informationen zu Microsoft IT Showcase bitte per E-Mail-Nachricht (in Englisch) an: showcase@microsoft.com

Weitere Informationen

Die in diesem Dokument enthaltenen Informationen repräsentieren die behandelten Themen aus der Sicht der Microsoft Corporation zum Zeitpunkt der Veröffentlichung. Da Microsoft auf sich ändernde Marktanforderungen reagieren muss, stellt dies keine Verpflichtung seitens Microsoft dar, und Microsoft kann die Richtigkeit der hier dargelegten Informationen nach dem Zeitpunkt der Veröffentlichung nicht garantieren.

Dieses Dokument dient nur zu Informationszwecken. MICROSOFT SCHLIESST FÜR DIE IN DIESEN UNTERLAGEN ENTHALTENEN ANGABEN UND DATEN JEDE GEWÄHRLEISTUNG AUS, SEI SIE AUSDRÜCKLICH ODER KONKLUDENT.

Die Benutzer/innen sind verpflichtet, sich an alle anwendbaren Urheberrechtsgesetze zu halten. Unabhängig von der Anwendbarkeit der entsprechenden Urheberrechtsgesetze darf ohne ausdrückliche schriftliche Erlaubnis der Microsoft Corporation kein Teil dieses Dokuments für irgendwelche Zwecke vervielfältigt oder in einem Datenempfangssystem gespeichert oder darin eingelesen werden, unabhängig davon, auf welche Art und Weise oder mit welchen Mitteln (elektronisch, mechanisch, durch Fotokopieren, Aufzeichnen usw.) dies geschieht.

Es ist möglich, dass Microsoft Rechte an Patenten bzw. angemeldeten Patenten, an Marken, Urheberrechten oder sonstigem geistigen Eigentum besitzt, die sich auf den fachlichen Inhalt dieses Dokuments beziehen. Das Bereitstellen dieses Dokuments gibt Ihnen jedoch keinen Anspruch auf diese Patente, Marken, Urheberrechte oder auf sonstiges geistiges Eigentum, es sei denn, dies wird ausdrücklich in den schriftlichen Lizenzverträgen von Microsoft eingeräumt.

© 2002 Microsoft Corporation. Alle Rechte vorbehalten.

Microsoft, Active Directory, Outlook, SharePoint, Visual Basic, Windows und Windows NT sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern.

Die in diesem Dokument aufgeführten Namen bestehender Firmen und Produkte sind möglicherweise Marken der jeweiligen Eigentümer.

Zum Seitenanfang

| Home | Technische Artikel | Community