PKI Implementierung. PKI Teil II: Implementierung Elke Stangl Microsoft Consulting Services. Planung und Design

Transkript

1 PKI Implementierung PKI Teil II: Implementierung Elke Stangl Microsoft Consulting Services Unterschiede w2k-.net PKI-Planung und Design Implementierung der Hierachie Vertrauen zwischen Organisationen Installation der CAs Festlegungen für Zertifikate Beantragung von Zertifikaten Routine-Administration und Wartung, Disaster Recovery Vorteile der PKI unter Windows.NET Server 2003 Differenzierter wechselseitiger Trust zwischen CAs: Qualified Subordination Flexible Anpassung der Eigenschaften von Zertifikaten durch modifizierbare "v2" Certificate Templates. Auto-Enrollment auch für Benutzer Zentrale Ablage von privaten Schlüsseln, Wiederherstellung von priv. Schlüsseln nach Disaster Windows-Versionen im Überblick V2 Templates Key Archival, Recovery Nur Web- Enrollment Auto- Enrollment.NET Enterpr. Edition Nur Enterprise CA.NET Std. Edition w2k Server XP Pro Client w2k.net CA CA User Comp. Comp. Comp. Comp. User Comp. W2k Client w2k.net CA CA Nur Web- Enrollment Comp. Comp. Delta CRL Qualified Subordination Planung und Design Business-Szenario und Anforderungen an Zertifikate festlegen Richtlinien auf hohen Niveau, rechtliche Aspekte Design der CA-Infrastruktur Strategie für Erneuerung der Zertifikate Plan für Management / Betrieb Anforderungen festlegen: Anwendungen und Nutzer Encrypting File System Internet Authentication Digital Signatures Software Restriction Policy Smart Card Logon Windows.NET Certificate Services Wireless Security Secure IP Security Software Code Signing Services Benutzer Computer 1

2 Anforderungen festlegen: Organisation Externer Zugriff: Vergabe von Zert. für Externe, Validierung von extern vergebenen Zertifikaten? Verfügbarkeit: Zu welchen Zeiten und an welchen Orten? Übergeordnetes Security-Konzept der Organisation? Rechtliche Anforderungen: Wofür haftet die Organisation? Anforderungen festlegen: Technik Technische Umsetzung der Security-Policy, Security- Anforderungen externer Partner Administration von CAs und Zertifikaten Aufteilung der benötigten Services auf mehrere CAs Hardware, Software (unterschiedliche Hersteller) Infrastruktur: Gebäude, Zutritt Design der CA-Hierachie Root-Hierachie: Security, Administration Skalierbarkeit Unterteilung in Root, Intermediate (Policy) und Issuing CA (nach Standorten, Zweck, admin. Verantwortung) Cross-Certification B2B: Vereinigen unter einer CA oder Einschränken des Trusts Festlegen der Vertrauensgrenzen, Interoperabilität Beispiel: Rollen der CAs Festzulegen: Lebensdauern Schlüssellängen Prozess für Vergabe Prozess für Erneuerung Smartcards für Administratoren Webserver SSL Root CA (standalone) Policy CA (Enterprise) Computer Vertrauen in Root-Zertifikate "self-signed" von der Root-CA selbst Gekennzeichnet als vertrauenswürdig Zu einem Speicher vertrauter Zertifikate hinzugefügt (Root Store) Gültigkeitsbereich: Der ganze Forest Eine Domain Eine einzelne Maschine Ein Benutzer oder Service Festlegen von Root- Zertifikaten Manuell zu einem Zert.-Speicher hinzugefügt (Maschine, Benutzer, Service) Windows Update (w2k), Update Root Certificates (XP) Definiert in Domain Group Policy Publiziert im Config. Container des Forest (Installation einer CA oder manuell) 2

3 Enterprise vs. Stand-Alone Standalone CA AD-Integration Nein Ja Enrollment-Methode Web-Formular Enterprise CA Cert.-MMC oder Web-Formular Certificate Templates Keine Unterstützt Subject-Information Manuelle Eingabe AD-generiert Vergabe von Zertifikaten (Issuance) Server, auf dem CA- Service läuft Publikation von CRL und Zertifikat ins AD Manuelle Freigabe Workgroup- oder Domain-Member Manuell Anhängig von ACL auf Template Domain-Member Automatisch Abbildung im AD Public Key Group Policy: Computer oder Benutzer Configuration Configurations Container: Services AIA, CDP, Certificate Templates, Certificate Authorites, Enrollment Services, neu in.net: KRA (Key Recovery Agents), OID (Object ID für spezielle Richtlinien bei der Zertifikatsvergabe) MMC Certificate Templates: nur.net Public Key Group Policies Computer Configuration: Windows Settings Security Settings Public Key Policies enthält Container Encrypted Data Recovery Agents Automatic Certificate Request Settings Trusted Root Certification Authorites Enterprise Trust Autoenrollment Settings (kein Container) User Configuration: Windows Settings Security Settings Public Key Policies enthält Container Enterprise Trust Autoenrollment Settings (kein Container) Certificate Policy und Certificate Practice Statement Root CA Security Policy Certificate Policy Statement Certificate Practice Statement Security Policy: Was/wer muss geschützt werden? Was/wer ist vertrauenswürdig? Certificate Policy Statement: Anwendung der Security Policy auf CA Cert. Practice Statement: Technische Implementierung des Cert. Policy Statement Publizieren des CPS auf den CAs, meistens als http-url 4 Issuing CA Policy CA Certificate Policy Statement Zweck des/der Zertifikate Authentifizierung der Benutzer Rechtliche Folgen bei Kompromittierung der CA Verwaltung privater Schlüssel Verantwortlichkeiten der Benutzer Voraussetzungen für Vergabe und Erneuerung von Zertifikaten Minimale Schlüssellängen Certificate Practice Statements (CPS) Identifizierung der CA: CA-Name, Servername, DNS-Adresse Arten der vergebenen Zertifikate Richtlinien für Vergabe, Erneuerung, Wiederherstellung von Zert. Kryptographische Details, CSPs Lebensdauer der Zertifikate Physische Sicherheit Richtlinien für Erneuerung des CA- Zertifikates 3

4 Security-Anforderungen für Offline-Root-CA (Physisch) Sicherer Ort für CA und Schlüssel- Hardware Sicherheit Hardware Security Module (HSM) für Schlüsselerzeugung (CSP) und speicher Längerer Schlüssel "Two-factor authentication" Security-Richtlinien Rollentrennung für Admins "Two-Factor Authentication" Hardware Key Storage Realisierungsmöglichkeiten: Server ausgeschaltet Netzwerkkabel ausgesteckt Server on, CA-service gestoppt Wechselfestplatte HSM mit Operator-Karte CAPolicy.inf-Datei Definiert die Konfiguration der CA, zu erstellen vor der Installation Root CA %Windir% [PolicyName] OID= Notice = Legal Policy Statement Text URL= CAPolicy.inf Hinweise auf Certificate Practice Statement Schlüssellänge Lebensdauer des selfsigned Zertifikates des CA Richtlinien für Offline-Root- CAs Root-CA = Member oder Workgroup- Server NIE mit dem LAN verbunden (CD-Setup) In CAPolicy.inf vermeiden: Keine Festlegung von CDP, AIA, "constraints" Computername kann nicht mehr geändert werden Lokale Installation von IIS Verwendung von Hardware CSP or HSM Schlüssellänge muss von allen Applikationen unterstützt werden Gültigkeitszeitraum: Jahre CA-Detailinformationen (Installation der CA) Eindeutiger Common Name, kein FQDN wie für SSL-Server-Zertifikate Common Name < 64 Zeichen (X.500) Leerzeichen = %20 Lange Lebensdauer: Jahre Schlüssel bit Datenbank und Logfiles können für Root-CAs auch auf der System- Platte abgelegt werden Weitere Konfiguration der Offline-Root-CA CA-MMC, Eigenschaften der CA Wahl von Policy und Exit Modules Policy: Status von beantragten Zertifikaten immer "Pending" Auditing von CA-Event im Security Log Lebensdauer der vergebene Zertifikate: HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Services\ CertSvc\ Configuration\RootCA Values: ValidityPeriodUnits, Value Certificate Revocation Lists Zertifikate können vor Ablauf Ihrer Lebensdauer nicht gelöscht, sondern nur "widerrufen" werden Widerruf = Eintrag des Zertifikates in eine CRL Pfad zur CRL = CRL Distribution Point = CDP, muss im Zertifikat inkludiert werden Ablauf des Zertifikates Zertifikat wird aus der CRL gelöscht 4

5 Publikation von CRLs (CDP) Internet Externer Web-Server (DMZ) Firewall Firewall Möglichkeiten: Active Directory, LDAP Web-Server, HTTP z.b. gleicher Server wie cps.htm FTP-Server File-Server, UNC-Pfade Active Directory FTP- Server Interner Web- Server Offline Root CA File- Server CDP und AIA-Erweiterungen AIA = (Authority Information Access) = Publikationspunkt für Zertifikat der CA CA MMC, Eigenschaften der CA, Extensions Alle Pfade ausser dem lokalen Pfad löschen LDAP URL für AD-Clients hinzufügen HTTP URL für andere Clients hinzufügen AIA und CDP in allen vergebenen Zertifikaten inkludieren LDAP-Publikation mit Certutil.exe Manuelle Publikation nach HTTP-URLs Implementierung einer Subordinate CA Lebenszyklus von Zertifikaten Vergabe von Zertifikaten an CAs Vergabe von Zertifikaten an Benutzer / Computer Widerruf von Zertifikaten Evtl. Mit Status "Certificate Hold" Erneuern von Zertifikaten (gleicher oder anderer Schlüssel) Auslaufen von Benutzer / Computer Zertifikaten Auslaufen von CA-Zertifikaten Überprüfung von Zertifikaten durch Clients Informationen sammeln Pfad validieren An der Subordinate CA: Certificate Services installieren Request für Root-CA erzeugen Request als Datei speichern Datei über Datenträger zur Offline-Root- CA transportieren Webrequest über Webformular absetzen Submit the request to the offline CA Freigabe durch den CA Administrator issues the certificate Zertifikat auf Datenträger speichern Auf der Subordinate CA installieren Certificate Services starten Revocation- Check 1. CA Zertifikate aus Cache, Group Policy, Enterprise Policy, Anwendungen, AIA URLs. 2. Überprüfung der Zertifikate in der Hierachie bis zu einer Root-CA. 3. Überprüfen des Widerruf-Status Windows 2000: Nach dem Aufbau der gesamten Kette Windows XP/.NET: Während dem Aufbau der Kette Validierungs-Kriterien Zeit Format Inhalt Test Signatur (Hash) Revocation- Check Root-Check Policy-Check "Critical extensions" Kriterium Heutiges Datum innerhalb der Lebensdauer des Zertifikates Standard X.509 Version 1 bis Version 3 Alle Felder ausgefüllt Inhalt wurde nicht modifiziert Nicht widerrufen Die Zert.-Kette endet in einem gültigen Root-Zertifikat Die Verwendung des Zertifikates enrspricht den definierten Einschränkungen Alle Extensions werden von allen Applikationen erkannt 5

6 Widerrufen von Zertifikaten CRLs für End-Zertifikate Merkmal Basis CRLs Delta CRLs Seit der letzten Beinhaltete Alle Basis-CRL widerrufenen Zertifikate widerrufene Zertifikate Zertifikate Gründe für Widerruf: Kompromittierung eines Benutzeroder Computer-Zertifikates Kompromittierung eines CA- Zertifikates Beendigung der Tätigkeit eines Benutzers für eine Organisation Ausserbetriebnahme einer CA Ausgabe eines Ersatz-Zertifikates, z.b. Beim Verlust einer Smartcard. Publikations- Intervall Seltener Häufiger Größe Größer Kleiner Clients 1. CDP für Enterprise CA Alle Windows Clients Nur Windows XP und Windows.NET Clients AD AD oder HTTP Delta CRLs Widerruf Cert5 Delta CRL #2 Basis CRL #1 5 Time Widerruf Cert7 Client-Betriebssystem Netzwerk-Belastung durch CRL-Download Größe der Delta CRLs Typische Widerruf-Frequenz Registry-Einstellungen: CRLOverlapPeriod CRLOverlapUnits ClockSkewMinutes 5,7 Delta CRL #3 3 3,5,7 Basis CRL #4 Certificate Templates Festlegen von Format, Inhalt und Zweck eines Zertifikates Behandlung von Requests Erlaubnis für Enrollments (DACLs) Ablage im AD Configuration Container Daher nur von Enterprise CAs nutzbar Version 1 oder 2 V2: modifizierbar, nur.net V1: w2k und.net Werden auf bestimmten CAs publiziert, z.t. per Default publiziert Beispiele: V2 Templates Benutzer Computer Ein Zweck Basic EFS Client authentication Web server IPSec Mehrfach nutzbar Administrator User Smart card user Computer Domain controller Eigenschaften von V2 Templates Gültigkeit: Validity und Renewal Period Zweck: Signatur, Verschlüsselung, Smart-Card-Logon oder Kombination Kryptografie: Schlüssellänge, CSP Archivieren des Private Key (Auto)-Enrollment Subject Name (CN, Full), optionaler alternativer Name 6

7 ACLs auf Templates Use To Full Control Jegliche Änderungen Read Auffinden des Templates im AD Write Modifizieren der Attribute Absenden von Requests, um ein Enroll Zertifikat auf der Basis dieses Templates zu erhalten oder zu erneuern Autoenroll Absenden eines Requests ohne merkbare Benutzerinteraktion Enrollment von Zertifikaten Durch Benutzer-Interaktion: Certificates MMC, Certificate Request Wizard Webformular: Automatisch: W2k: Domain GPO "Automatic Certificate Request settings".net: Auto-Enrollment Autoenrollment Eigenschaften des Templates konfigurieren. Group Policy auf Domain oder OU setzen: XP/.NET: Computer oder Benutzer Public Key Policies, Autoenrollment Benutzerinteraktion erforderlich bei Smartcard-Zertifikaten Autoenrollment Konfiguration der Templates "Request handling" "Subject Name" Zahl der eventuell benötigten Signaturen (maximal eine) Existierendes Zertifikat als Voraussetzung für Enrollment Validity und Renewal Period (Autoenrollment frühestens nach 20% der Validity Period) Beispiel: Smartcard-User Autoenrollment GPO Template SmartCardUser Benutzerinteraktion erforderlich CSP auswählen Berechtigungen: Read, Enroll, Autoenroll für eine Gruppe Aufnahme eines Benutzers in diese Gruppe erst nach direktem Kontakt SmartCard-User-Zertifikat zum Signieren des Requests für ein anderes Zertifikat verwenden z.b. EFS-Zertifikat, autoenrolled Trust zwischen Organisationen Gemeinsame Root-CA Cross-Certification RootCA-Zertifikate austauschen Cross-CA Zertifikate ausstellen Certificate Trust Lists Signierte Listen vertrauter CAs Eigene Art von Zert. Für Signieren nötig Einschränkung von Lebensdauer Verwendungszweck der Zert. Bestimmte CA (nicht unbedingt Root) Implementierung in Domain GPO (nur).net: Qualified Subordination 7

8 Qualified Subordination Constraints Z.B. Name constraints Contoso.msft Permit=contoso Exclude=nwtraders Nwtraders.msft Permit=nwtraders Exclude=contoso Constraints Einschränkungen: Erlaubte Namen (Name constraint) Tiefe der CA-Hierachie des Partners (Basic constraint) Verwendungszwecke für Zertifikate (Application Policy) Vergabe-Policy für Zertifikate in der Partner-Organisation (Issuance Policy) Qualified Subordination: Best Practices Separate Cross-CA-Zertifikate für jeden Zweck Name contraints, um dem Partner nicht zu erlauben, den eigenen Namespace zu benutzen Basic contraints nie in Root-CA- Zertifikaten definieren Constraints müssen im Einklang mit Security Policy und Cert. Policy stehen Links zu speziellen CPS definieren Implementierung von Qualified Subordination Benötigte Files: Policy.Inf,.Cer der eingeschränkt vertrauenswürden Partner-CA Neues Cert.-Templates für Unterschreiben des eigentlichen CrossCA-Zert. Erstellen (eigene OID) Beantragen eines CrossCA- Zert. Für die andere CA unter Verwendung des Policy.Inf- Files: certreq policy Unterschreiben des Antrages: certreq -sign -cert... Genehmigung, Installation, (automat.) Publikation ins AD Cross-CA Certificate Signing Certificate PKI-Administration Management von Zertifikaten Management der CA Berechtigungen auf Templates setzen Zertifikate enrollen Requests überprüfen Zertifikate vergeben Zertifikate widerrufen CA installieren CA-Zertifikate erneuern Key Recovery Agents bestimmen Sichern und wiederherstellen der CA Auditieren der Certificate Services Publikation von CRLs Trennung der Rollen Verhindern, dass ein Benutzer mehr als eine Rolle einnimmt: certutil -setreg ca\roleseparationenabled 1 Rolle = ACL Manage CA Issue and manage certificates Festlegen von CA Managern und KRAs Zusätzliche Filterung der Certificate Manager nach Gruppen von Benutzern oder Computern möglich 8

9 Schlüssel-Archivierung und Wiederherstellung Manuelles Sichern einzelner Schlüssel und Importieren in die CA-Datenbank Automatische Archivierung privater Schlüssel bei der Vergabe von Zertifikaten (abh. Vom Template) Migration von Exchange KMS- Datenbanken Private Schlüssel zum Entschlüsseln der Datenbank werden nicht auf der CA gespeichert Mehrfache Verschlüsselung durch KRAs Archivierung von privaten Schlüsseln Client erzeugt Schlüsselpaar Zertifikat publiziert und retour an den Client Request verschlüsselt mit Exchange-Key der CA Request und "BLOB" für Recovery werden in der CA- Datenbank abgelegt Schlüssel- Validierung (Passen beide zusammen? Symmetrische Verschlüsselung Verschlüsselung mit dem öffentlichen Schlüssel des/der KRA(s) Voraussetzungen für Archivierung Key Recovery Agents bestimmen Template Richtlinien für Vergabe Archivierung durch die CA ermöglichen Einen oder mehrere KRAs definieren Zahl der KRA für die Archivierung festlegen Mehr KRAs verfügbar als nötig Round Robin Archivierung im Cert. Template konfigurieren Wiederherstellen von privaten Schlüsseln 1 5 Privater Schlüssel verloren KRA stellt den privaten Schlüssel wieder her 2 Serial #: 00A036 Certificate Manager findet die Seriennummer des Zertifikates 4 3 PKCS# 7 wird sicher an den KRA übermittelt PKCS#7 Certificate Manager extrahiert das PKCS#7 File Details zur Wiederherstellung 1 KRA-Template entsprechend Polcies modifizieren Gruppe "KRA" Enroll-Berechtigung geben "Pending Request" vom CA-Manager genehmigen lassen Archivierung der CA ermöglichen, KRA- Zertifikate bekanntgeben Zahl der nötigen KRAs festlegen Template für Benutzer anlegen, z.b. Für EFS-Datenverschlüsselung Schlüssel-Archivierung im Template erlauben Datei verschlüsseln (EFS-Eigenschaften zeigt Zertifikat) Details zur Wiederherstellung 2 Szenario: Useraccount mit EFS-Zertifikat existiert nicht mehr Key Recovery Tool (angemeldet als CA- Manager): Suchen nach Zertifikat (Common Name) Anzeigen der KRAs Exportieren (als CA Manager): Certutil getkey <Serien#desEFSZerts> a:\file Als KRA: certutil recoverkey a:\file a:\user.pfx Widerrufen des Zertifikates Als Benutzer mit Recht auf Datenzugriff (organisatorisch + NTFS!) einloggen, Schlüssel (pfx) importieren. 9

10 Best Practices zu Archivierung und Recovery Wertvolle Zertifikate und Signaturschlüssel NICHT archivieren Zahl der CAs mit Archiv-Funktion minimieren Round robin Key Recovery Agents Getrennte Rollen: CA Manager und Key Recovery Agents Zertifikat nach dem Recovery eines privaten Schlüssels sofort widerrufen Privaten Schlüssel des KRAs aus seinem Benutzerprofil entfernen oder auf einer Smartcard speichern Sicherer Transfer des wiederhergestellten privaten Schlüssels Performance-Überlegungen CAs werden nur bei der Vergabe von Zertifikaten belastet, nicht im laufenden Betrieb Belastungsspitzen: Autoenrollment von Computern kurz nach dem Aktivieren der GPO Queuen der Requests 10kB / Zertifikat Beispiel: Offline CA = Desktop-Hardware Enterprise CA = zusätzlicher Service auf vorhandenem Domain-Controller Separater Webserver als CDP Sicherung einer CA Ausrollen der PKI Dokumentation der CA- Konfiguration (Namen, Pfade, Konfig-Files) Backup-Wizard für CA-Zertifikat CA-Schlüsselpaar CA-Datenbank Backup der IIS-Metabase (IIS-MMC) Systemstate eines DCs Planung des Rollouts Training für Admins und Benutzer Installation der CAs Installation von Applikationen Konfiguration von Cert. Templates Festlegen der CDPs Konfiguration der Public Key Group Policy Konfiguration Enrollment Ausgabe von Zertifikaten an CAs, Benutzer und Computer 10