M 2.232 Planung der Windows 2000/2003 CA-Struktur
Verantwortlich für Initiierung: IT-Sicherheitsmanagement, Leiter IT
Verantwortlich für Umsetzung: Leiter IT, Administrator
Windows 2000/2003 wird mit eigenen PKI-Komponenten ausgeliefert, die den Aufbau einer unternehmensweiten Zertifikatshierarchie ermöglichen. Kernstück einer PKI (Public Key Infrastruktur) ist die so genannte Zertifizierungsstelle (Certificate Authority, CA), die Zertifikate ausstellen kann. Für den Betrieb von Windows 2000/2003 ist der Betrieb einer CA zwar generell nicht notwendig, jedoch immer dann zwingend, wenn bestimmte Eigenschaften oder Funktionen genutzt werden sollen, wie z. B. Anmeldung mit Chipkarte oder abgesicherte Kommunikation zwischen Windows Systemkomponenten über SSL. Windows 2000 und Windows Server 2003 bieten zwei Ausprägungen einer CA an:
- Stand-alone-CA (alleinstehende Zertifizierungsstelle) und
- Enterprise-CA (Organisationsweite Zertifizierungsstelle).
Der Hauptunterschied zwischen den beiden CA-Versionen ist, dass die Enterprise-CA im Active Directory integriert ist und damit vom Active Directory als Verzeichnisdienst profitiert. Beispielsweise werden Zertifizierungsstellen im Active Directory veröffentlicht, und Zertifikate können in großem Umfang automatisch ausgestellt und verteilt werden. Bei der Stand-alone-CA wird die Zertifikatsanforderung immer vom Administrator der CA geprüft. Die Zertifikatserzeugung muss durch den Administrator von Hand angestoßen werden. Die Stand-alone-CA kann auch auf einem nicht vernetzten Rechner installiert und betrieben werden, wohingegen die Enterprise-CA sinnvoll nur auf einem vernetzten Rechner ablaufen kann. Ab Windows Server 2003 Enterprise Edition können bei der Enterprise-CA die Zertifikatsvorlagen individuell angepasst werden.
Beide CA-Versionen eignen sich für den Aufbau von Zertifikatshierarchien und können daher auch als untergeordnete CA fungieren. Für viele infrastrukturelle Zwecke eines LANs ist die Enterprise-CA besser geeignet und sollte im Normalfall bevorzugt werden.
Insbesondere bei der Planung einer behörden- oder unternehmensweiten PKI sollte darauf geachtet werden, dass alle Einsatzszenarien und die dadurch betroffenen Applikationen bekannt sind. Um die technische Machbarkeit abschätzen zu können, empfiehlt es sich, alle Komponenten, die eingesetzt werden sollen, im Vorfeld auf ihre Interoperabilität zu überprüfen.
Eine Auflistung struktureller Planungsaspekte ist auf den BSI-Webseiten unter den Hilfsmittel zum IT-Grundschutz zu finden (siehe Hilfsmittel für die Planung der Windows 2000/2003 CA-Struktur). Generell gilt, dass alle für den Betrieb einer CA relevanten organisatorischen, technischen und auch sicherheitstechnischen Rahmenbedingungen in einem entsprechenden Konzept dokumentiert werden müssen.
Planung des Einsatzes geeigneter Zertifizierungsstellen
Organisatorische Aspekte:
- Die Planung einer PKI erfordert Zeit. In der Regel müssen insbesondere innerorganisatorische Zuständigkeiten geregelt und festgeschrieben werden.
- Der Verwendungszweck von Zertifikaten spielt bei der Planung der CA-Struktur eine wichtige Rolle. So bereitet der Aufbau einer generellen, organisationsweiten Zertifikatsinfrastruktur meist mehr Schwierigkeiten, als der Aufbau einer applikationsbezogenen PKI. Eine applikationsbezogene PKI kann beispielsweise eingesetzt werden, wenn im Rahmen einer netzbasierten Anwendung nur die betroffenen Mitarbeiter zuverlässig identifiziert werden müssen. Ein Beispiel hierfür ist das elektronische Einreichen und Bearbeiten von Urlaubsanträgen, wobei die Anträge nacheinander von verschiedenen Personen digital abgezeichnet, also signiert, werden müssen.
- Werden Zertifikate nur innerhalb einer Behörde bzw. eines Unternehmens genutzt, so sollten diese nur von CAs vergeben werden, die ausschließlich intern genutzte Zertifikate ausstellen. Solche internen CAs dürfen keine Zertifikate nach "außen" geben, z. B. an Personen oder Geräte, die nicht in der Behörde oder dem Unternehmen eingesetzt werden. Eine interne CA sollte nicht von außen über das Internet erreichbar sein, deshalb ist auch keine Überprüfung von nach außen gegebenen Zertifikaten möglich.
- Für extern genutzte Zertifikate und die ausstellenden CAs sind die Nutzungsrichtlinien zu definieren und zu dokumentieren. Es ist dabei insbesondere darauf zu achten, dass entsprechende Anforderungen an die Qualität der Identitätsprüfung gestellt und umgesetzt werden.
Technische Aspekte:
- Es muss geplant werden, welche kryptographischen Verfahren und Algorithmen und welche Schlüssellängen zum Einsatz kommen sollen (siehe auch M 2.162 Bedarfserhebung für den Einsatz kryptographischer Verfahren und Produkte).
- Das Vertrauen in Zertifikate einer CA hängt wesentlich von deren Sicherheitsgrad ab. Daher ist für CAs, die sicherheitskritische Zertifikate erzeugen, besonders auf die physikalische und softwaretechnische Sicherheit zu achten. Sicherheitskritisch sind insbesondere solche Zertifikate, die einen großen Anwenderkreis haben oder von deren Korrektheit weitere sicherheitskritische Anwendungen abhängen.
- Für Zertifikate mit unterschiedlichem Sicherheitsbedarf sollten unterschiedliche CAs eingesetzt werden.
- Beim Einsatz von CA-Hierarchien muss das Gültigkeitsmodell festgelegt werden. Dabei ist es wichtig festzulegen, wie nachgeordnete Zertifikate zu behandeln sind, wenn z. B. das Root-CA-Zertifikat (aus welchen Gründen auch immer) gesperrt werden muss.
- Für die verschiedenen Zertifikatstypen (z. B. Root-CA-Zertifikat, Benutzer-E-Mail-Zertifikat) muss jeweils die maximale Gültigkeitsdauer festgelegt werden. Im Allgemeinen ist es sinnvoll, dass die Gültigkeitsdauer der Zertifikate nicht die Gültigkeitsdauer des Zertifikates der ausstellenden CA überschreitet. Es gibt hier allerdings verschiedene Gültigkeitsmodelle (z. B. so genannte "Kettenmodelle" und "Schalenmodelle"). Beispielsweise kann bei Signaturen nach dem deutschen Signaturgesetz die Gültigkeit der einzelnen Zertifikate länger sein als die Gültigkeit des CA-Zertifikates.
- Die Möglichkeiten und Verfahren nach Ablauf der Gültigkeit eines Zertifikates sind festzulegen. Sind z. B. Verlängerungen möglich oder müssen neue Zertifikate ausgestellt werden?
Neben der Planung einer PKI spielt insbesondere die Sicherheit im laufenden Betrieb der einzelnen PKI-Komponenten eine große Rolle. Die Absicherung einer Zertifizierungsstelle muss dem Schutzbedarf der jeweiligen Anwendung genügen, in der Zertifikate verwendet werden. Empfehlungen dazu finden sich in M 4.144 Nutzung der Windows 2000 CA und unter den Hilfsmittel zum IT-Grundschutz (siehe Hilfsmittel für den Schutz der Zertifikatsdienste unter Windows Server 2003).
Versionsspezifische Planungsaspekte für eine Windows-Server-2003 CA
Verteilung von Zertifikaten:
Der Vorgang des Anforderns und Austellens (kurz: der Verteilung) von Zertifikaten kann automatisch (ohne Benutzereingriff) oder manuell erfolgen. Die automatische Verteilung von Zertifikaten (Auto-Enrollment) basiert auf Active Directory und Gruppenrichtlinien (vergleiche M 2.231 Planung der Gruppenrichtlinien unter Windows 2000 Auto-Enrollment ist ein mächtiges Werkzeug, das die Verwaltung von Zertifikaten von Benutzern (ab Windows Server 2003 Enterprise Edition) und Computern für bestimmte Anwendungen im Organisationsumfeld stark vereinfacht. Häufiges Beispiel ist das Verteilen von Verschlüsselungszertifikaten für das Encrypting File System (EFS) auf Clients. Das Zertifikats-Enrollment wird nur für autentisierte Clients durchgeführt und ist mit entsprechenden Sicherheitsmechansimen und Berechtigungen versehen. Die Einstellungen sind im Gruppenrichtlinienobjekt-Editor unter
- Computerkonfiguration | Windows-Einstellungen | Sicherheitseinstellungen | Richtlinien öffentlicher Schlüssel | Eigenschaften von Einstellungen für die automatische Registrierung
und
- Benutzerkonfiguration | Windows-Einstellungen | Sicherheitseinstellungen | Richtlinien öffentlicher Schlüssel | Eigenschaften von Einstellungen für die automatische Registrierung
zu finden. Standardmäßig fordern nur Domänencontroller automatisch ein Computerzertifikat an. Einige optionale Windows-Komponenten fordern ebenfalls automatisch ein Zertifikat an, z. B. erhält jeder Client mit aktiviertem EFS automatisch ein EFS-Zertifikat. Auto-Enrollment sollte jedoch nur im tatsächlich benötigten Umfang eingesetzt werden, da sonst die Verwaltung erschwert wird und unter anderem auch die Gefahr des Abfangens von Schlüsseln besteht.
Es sollte auf Grundlage der geplanten Applikationen bzw. Windows-Komponenten überlegt werden, welche Zertifikatstypen für welche Benutzer bzw. Computer zugelassen sind und auf welche Weise die Verteilung stattfindet. Entsprechend sind die Gruppenrichtlinien und die Berechtigungen in den Zertifikatsdiensten zu planen.
Archivierung von privaten Schlüsseln:
Die Archivierung von privaten Schlüsseln in der Zertifizierungsstelle (ab Windows Server 2003 Enterprise Edition) sollte nur dann aktiviert werden, wenn ein geeignetes Konzept zur Rollentrennung der PKI-Verwaltung geplant und umgesetzt wurde. Die Archivierung kann die Gefahr des Schlüsselverlusts einzelner Benutzer verringern, allerdings wird das Risiko des Missbrauchs erhöht. Deshalb ist sie nicht zu empfehlen. Die geeignete Strategie ist abhängig von den eingesetzten Anwendungen und Komponenten und sollte durch die PKI-Planung und in einer IT-Sicherheitsrichtlinie festgelegt werden.
Rollentrennung:
Rollentrennung bedeutet, dass die Konzentration mehrerer oder aller kritischer Verwaltungsrollen im Zusammenhang mit PKI auf eine Person, bzw. ein Benutzerkonto, verhindert wird. Dazu muss zunächst die Rollentrennung auf organisatorischer Ebene definiert sein (siehe oben). Auf technischer Seite kann die Rollentrennung durch das System erzwungen werden (ab Windows Server 2003 Enterprise Edition). Die vier Rollen sind:
- Zertifizierungsstellenadministrator
- Zertifikatverwaltung
- Sicherungs-Operator Prüfer
Details zu den Rollen sind im Hilfethema Rollenbasierte Verwaltung der integrierten Windows-Hilfe zu finden.
Ein Benutzerkonto, das vorher zwei oder mehr der genannten Rollen inne hatte, wird durch die Rollentrennung von allen Verwaltungstätigkeiten an der CA ausgeschlossen. Die Rollen müssen durch einen Administrator neu zugeteilt werden. Bei einer fehlerhaften Konfiguration der Rollentrennung ist die CA nicht mehr nutzbar. Wenn diese Funktion eingesetzt werden soll, ist hierfür zunächst ein geeignetes Berechtigungskonzept zu erstellen, welches dann in einem Testszenario erprobt werden sollte.
Ergänzende Kontrollfragen:
- Wurde eine bedarfsgerechte PKI-Planung durchgeführt?
- Ist die CA-Hierarchie mit allen Verantwortlichkeiten und Nutzungsbestimmungen dokumentiert?
- Sind alle Zertifizierungsstellen bzw. Zertifizierungsdienste gemäß dem Schutzbedarf der jeweiligen Anwendungen abgesichert?
- Wurde festgelegt, welcher Benutzer welche Zertifikate erhält?
- Wurden alle Parameter wie etwa die Gültigkeit für alle Zertifikatstypen definiert?
- Wurde ein Berechtigungskonzept für die Trennung der Verwaltungsrollen erstellt?