1 ZIEL: ENGE INTEGRATION EINER PKI MIT EINEM IDENTITY & PROVISIONING MANAGEMENT SYSTEM (IPM) PKI-PROZESSE Tokenverwaltung...

Transkript

1 IPM mit integrierter PKI Inhalt 1 ZIEL: ENGE INTEGRATION EINER PKI MIT EINEM IDENTITY & PROVISIONING SYSTEM (IPM) BI-CUBE PKI PKI-PROZESSE Tokenverwaltung Tokenzuweisung Aktivierung des Zertifikatslogon Tokensperrung FallBack-Lösung für ZertifikatsLogon Aufgaben des RA Officers*:...5 ABBILDUNGEN: Ablaufdarstellung für den Usereintritt mit Token - Rollout Ablaufdarstellung für den Usereintritt mit Token- Rollout (alternative Tokenzuweiung)

2 IPM mit integrierter PKI 1 Ziel: Enge Integration einer PKI mit einem Identity & Provisioning Management System (IPM) Um eine PKI mit vertretbarem Aufwand betreiben zu können, ist eine enge Integration in ein IPM- System sinnvoll. Die im IPM vorhandenen Funktionen wie User-Verwaltung, AD-Integration und ein Rollenund Prozessmanagement stellen bereits einen wesentlichen Teil der für das Management digitaler Signaturen erforderlichen Funktionen bereit und ermöglichen eine weitgehende Automatisierung der PKI-Prozesse. Es sollte eine PKI bereitgestellt werden, die aus Sicht des Verwaltungsaufwandes eine deutliche Rationalisierung bei gleichzeitiger Verbesserung des Niveaus der Security insbesondere im Bereich der gesicherten User-Identifikation bringen sollte. Von besonderer Bedeutung war dabei die Integration der PKI- Prozesse in das Prozessmanagement des Provisioning. Die Prozesse zur Tokenverwaltung und Tokenzuweisung wurden damit voll in das Mitarbeiter- Eintrittsverfahren integriert. Von wurde weiterhin die Aktivierung des Zertifikatslogon und die Steuerung der Tokensperrung übernommen. Die Aufgaben des RA Officers (Registration Authority Officer) wurden als spezielle Aktivitäten integriert, so dass auch hier eine weitgehende Automatisierung ermöglicht werden konnte. Da statistisch gesehen, jeden Tag 4-5% der User keinen Token bzw. keine Smartcard verfügbar haben (vergessen, verlegt, verloren unbrauchbar usw.) ist eine FallBack-Lösung für das Zertifikats-Logon unverzichtbar. Für diesen Fall stellt in seinem Web-Frontend den Leitern eine Freigabe zur Verfügung, die eine Kennwort-Autentifizierung für einen Tag ermöglicht. Von besonderer Bedeutung ist auch eine effektive und revisionssichere Verwaltung der Token bis zur Zuteilung. Hier wurde auf Basis einer Vereinbarung mit dem Lieferanten eine automatisierte Übernahme der Seriennummern ermöglicht und eine chargenweise Verteilung auf die einzelnen Konzernunternehmen organisiert und im Ressourcenmanagement von abgebildet. Damit kann der Übergabeprozess vor Ort und am ersten Arbeitstag realisiert werden. Mit diesem Verfahren ist es gelungen, die doch recht aufwendigen Verwaltungsprozesse einer PKI fast durchgehend zu automatisieren und diese damit handhabbar zu machen.

3 2 PKI Auf Basis des Windows Signatur-Servers ist in eine PKI nutzbar. Die Verwaltung der PKI erfolgt als ein Subsystem (s. Bild unten als Beispiel für die Entrust PKI) Es wird am User unterschieden, ob er die Signatur auf einer - SmartCard oder als - managed certificate erhält. Letzteres ist die einfachere Variante, die dem User das Zertifikat am PC-Arbeitsplatz zur Verfügung stellt. Es wird wie das SSO-Profil vom Server nach der Authentifikation auf den PC runtergeladen und kann dann zur Signierung, Verschlüsselung und auch zur gesicherten Anmeldung an entsprechende Applikationen genutzt werden. 3 PKI-Prozesse 3.1 Tokenverwaltung Die Token werden angeliefert mit einem bestimmten Seriennummernrange oder mit einer ASCII-Liste aller Seriennummern, die dann in den Ressourcenmanager übernommen werden. Anschließend folgt der Check des Auditors, ob alle Token aufgenommen wurden (Stichproben).

4 3.2 Tokenzuweisung Dem User wird in die PKI zugewiesen. Wenn jeder User ein Token erhält, kann diese Transaktion automatisch angestoßen werden. Im Beantragungsfall ist einstellbar, ob ein Leiter (oder anderer Bevollmächtigter) diesen Antrag bestätigt. Bestandteil des Antrags- bzw. Zuteilungsworkflow kann wahlweise noch die Online-Bestätigung einer User-Richtlinie sein. Bevor diese Richtlinie vom User nicht bestätigt wurde, wird der Token nicht ausgeliefert. Es muss dann für den User ausgewählt werden, welchen Token er bekommt. (CSP-Auswahl z.b. etoken Rainbow oder SmartCard) Falls der User noch keinen Windows 2000 Account hat, wird dieser ihm zugewiesen. Der User wird auf der CA (Certification Authority) hinzugefügt. bekommt die Referenznummer und AuthenticationCode zurückgemeldet. Der AuthenticationCode wird in einem Geheimbrief (Blaupause) eingestanzt und an die zuständige Personalabteilung oder Geschäftsstelle gesendet. Der zuständige RA- Officer erhält per die Referenznummer zum Userantrag. Die Personalabteilung ordnet den User einer bei ihr vorhanden Tokenseriennummer zu. Der User muss ein Authenticationpassword für telefonische Sperrungen, in eintragen der User bekommt den ihm zugeordneten Rohtoken. Der User generiert seine Keys beim RA-Officer Alternative Tokenzuweisung sendet per der Personalabteilung Benutzername und Passwort für die erste Anmeldung des Users (Auth-Wechsel für ersten Tag). Die Personalabteilung händigt dem User diese Daten und den Rohtoken (mit Standard-PIN) aus und ordnet den User einer bei ihr vorhanden Tokenseriennummer zu. Der User meldet sich dann mit Benutzername und Passwort an, worauf ein Baloon-Tipp erscheint, welcher ihn zur Smartcardregistrierunng auffordert. Der User muss nun die Smartcard einlegen und seine persönliche PIN festlegen um die Smartcardregistrierung abzuschließen. 3.3 Aktivierung des Zertifikatslogon Im Zusammenhang mit dem PKI-Einsatz ist die Einstellung des LogOn entsprechend zu variieren. Synchron mit dem Zertifikats-RollOut wird diese Funktion in der Windows-Anmeldung durch aktiviert. Das ist mit dem Workflow der Zertifikatsausgabe so gekoppelt, dass durch im AD (Active Directory) eine entsprechende Einstellung vorgenommen wird. 3.4 Tokensperrung Da die PKI aus -Sicht ein Subsystem ist, kann dem User dieses System jederzeit wieder entzogen werden. Diese Information wird durch den Output-Connector direkt an die PKI übergeben und dort entsprechend verarbeitet. 3.5 FallBack-Lösung für ZertifikatsLogon Im realen Einsatz haben täglich ca. 5% der User ihr Zertifikat nicht verfügbar. Dafür ist eine Fallback-Lösung im IPM Web implementiert, die ihm für einen Tag eine Kennwort-Authentifikation ermöglicht. Wenn der Zertifikatssträger (Token oder SmartCard) nicht zur Verfügung steht (Verlust, vergessen oder verlegt), ist diese FallBack-Lösung zu nutzen.

5 Hierzu wird im IPM Web ein Verfahren angeboten, das dem Leiter gestattet die Anmeldung mit Kennwort für einen Tag zu ermöglichen. Dies ist ein Workflow, der durch einen Leiter oder anderen Bevollmächtigten veranlasst wird. Dazu wird eine entsprechende Message generiert, die diesen Authentifikationswechsel auslöst. Gleichzeitig wird auch der Umkehr-Vorgang durch eine zweite Message veranlasst. Während dieses Tages wird das Zertifikat auf on hold gesetzt und die neue CRL wird automatisch publiziert. 3.6 Aufgaben des RA Officers*: Der RA Officer ist eine vertrauenswürdige Person, die in den Ausgabeprozess der digitalen Signatur entsprechen eingebunden ist: Initalisierung des Token Aufruf des RA Clients und Zertifikatsrequests mit Referenznummer und AuthenticationCode (Generierter Encryptionkey wird in CA archiviert) Generierung des Signaturkeys am Token Zertifikate auf den Token schreiben User ändert den default PIN * RA = Registration Authority / Die Funktion des RA Officers wird in der Regel durch Innenrevision wahrgenommen bzw. festgelegt Im Falle der alternativen Tokenzuweisung ( siehe 3.2.1) entfallen die Aufgaben des RA Officers.

6 Ablaufdarstellung für den Usereintritt mit Token Rollout Tokenlieferung Seriennummer User Benutzer wird in erfasst 1. Zertifikatsauswahl Signatur, Encryption, Authentifizierung 2. Ressourcen Manager Userdaten werden an die PKI geschickt 3. User wird im AD angelegt Active Directory Input -> Personen bestimter Rolle Auditor -> Person mit bestimmter Rolle Check, ob alle Token erfasst sind Zertifikat wird publiziert CA 5. druckt Geheimbrief Daten: Username Büroadresse Authenticationcode 4. Referenznummer AuthenticationCode 6. Refernznummer per Zertifikat 10. Personalabteilung/ Hauptbanken 7. trägt Seriennummer im Ressourcen ein Ressourcen Manager User gibt Authenticationpassword ein PersonalAbteilung.) Geheimbrief.) Token (Roh od. mit default PIN- abhängig vom Token) Tasks RA Officer*: User ) Initalsierung des Token 2.) Aufruf des RA Clients und Zertifikatsrequests mit Refernznummer und AuthenticationCode(Generierter Encryptionkey wird in CA archiviert) 3.)Generierung des Signaturkeys am RA Officer Token 4.) Zertikate auf den Token schreiben 5.) User ändert den default PIN * Funktion der RA Officers wird durch Innernrevision wahrgenommen

7 Ablaufdarstellung für den Usereintritt mit Token- Rollout (alternative Tokenzuweiung)