Technische Produktinfo: Weitere Funktionen im Identity Server von bi-cube

Transkript

1 1 Ein neues Biometrie-Device in der Palette der gesicherten Authentifikationsverfahren des ism Neben dem Token-Verfahren (Secu-Token und SMS.Token) wird die biometrische Authentifikation im Rahmen des Identity Managements im bi-cube Produktsystem weiter ausgebaut. Der neue USB SmartCard und Fingerprintleser ist neben der Bio-Maus das Standard-Biometrie-Device der Identifikationslösungen des ism. Dies Device hat einen sehr schnellen Treiber und eine hochauflösenden Sensor (UPEC) Über einen USB-Slot am Device können auch USB- Token zur Authentifikation (an Stelle der Karte) genutzt werden. Analog zu diesem Device kann auch ein Keyboard mit Karten und FP-Leser eingesetzt werden. 2 Mögliche Einsatz-Szenarien 2.1 Fingerprint und ID auf der Karte Der User hat seine Karte, auf der sein Fingerprint (FP) und ein verschlüsselter ID-Token gespeichert sind. Er steckt die Karte in den Slot, dann wird mittels ID-Token seine Identität ermittelt und das Uaflegen seines Fingers abgefordert, was durch Blinken der LED angezeigt wird. Danach erfolgt die Verifikation des Fingers. Dies wird entweder zur Identifikation an Windows (GINA) genutzt oder im Systemkontext des Rechners zum authentifizierten Start seines SSOs. In beiden Fällen wird im Hintergrund noch geprüft, ob der User gültig ist. Falls er in bi-cube gesperrt ist, erfolgt keine Anmeldung. Wenn er den Arbeitsplatz verlässt, zieht er die Karte und der Rechner wird gesperrt. Ist die Karte wieder im Slot, was ständig überwacht wird, wird die Rechnersperrung aufgehoben. Die Erfassung des Fingerprints erfolgt, wie bisher in bi-cube üblich, im Zentralsystem. Aus dem Zentralsystem kann der Fingerprint dann auf der Karte abgespeichert werden. Bei dieser dualen Verfahrensweise kann sowohl die serverbasierte als auch die kartenbasierte Verifikation des Users mit Hilfe des Fingerprints vorgenommen werden

2 2.2 Nur die ID des Users auf der Karte Das Device kann auch im gemischten Betrieb genutzt werden. Auf der Karte befindet sich nur eine nicht-fälschbare Identifikation des Users. Hier wird ein Zusatz-Kennwort, das verschlüsselt auf der Karte liegt und zentral am User gespeichert und geprüft wird, angeboten: Damit wird die Identifikation des Users ermittelt, die danach mittels Fingerprint verifiziert wird. Dieser Fingerprint wiederum wird immer zentral am Authentication Server geprüft. Die Karte hat in beiden Verfahren weniger die Funktion einer dualen Authentifizierung, als dass sie eine Steuerfunktion im Sinne des Erkennens der Abwesenheit des Users oder des schnellen Userwechsels erfüllt. 2.3 Reine Identifikation des Users per Fingerprint Bei der Identifikation des Users per Fingerprint wird nur der FP abgenommen und zentral in der Datenbank die dazu passende Person ermittelt. Die Reaktionszeit ist natürlich von verschiedenen Faktoren abhängig. Es gibt einige serverbasierte Verfahren zur Beschleunigung des Verfahrens als auch die Möglichkeit des lokalen Cachings aller in der letzten Zeit ermittelten Personen, was dann zuerst versucht wird und nur bei negativem Ergebnis wird in der zentralen Datenbank weiter gesucht. Die Identifikation des Users per Fingerprint kann jedoch nur serverbasiert erfolgen. Die Identifikation als Authentifikationsverfahren hat den Vorteil einer weiteren Komforterhöhung verbunden mit dem Nachteil der längeren Verarbeitungszeit und einer gewissen, wenn auch geringen Fehlerrate, dass eine falsche Person ermittelt wird. 2.4 Abgesetzte biometrische Identifikation als kostenminimierte Variante Unter der Vorraussetzung, dass die User sich direkt am PC anmelden, kann z.b. eine zentrale Erst- Anmeldung im Eingang des Gebäudes oder im Flur nach dem Verfahren Karte und Fingerprint erfolgen. Wenn sich dann der User an seinem PC mit User-ID und Kennwort oder dem Secu-Token anmeldet, ist dem Zentralsystem bekannt, dass der User sich körperlich in dem Bereich der Erst- Anmeldung befindet und der Zugang zum PC wird freigegeben. 2.5 Biometrisch gesichertes Token Wenn im Webzugang ein besonders hohes Security-Niveau erforderlich ist, kann in das Secu-Token der Fingerprints des Users mit integriert werden. Dies ermöglicht am Client eine biometrische Prüfung, ob der richtige User das Token benutzt. Dies ist das einzige Verfahren, das für den Webzugang eine gesicherte biometrische Identifikation ermöglicht

3 3 Gesicherte Authentifizierung gegen bi-cube IPM mittels RADIUS Das RADIUS-Protokoll ist ein bewährtes Mittel zur Authentifizierung. Das Protokoll wurde insbesondere für den Aufbau von Remote-Verbindungen definiert und wird z.b. vom Microsoft VPN- Server oder vom Cisco Access Server genutzt. Deshalb stellt bi-cube IPM auch einen RADIUS- Server bereit, der mittels RADIUS-Protokoll von beliebigen Access-Control-Servern (z.b. Cisco) genutzt werden kann. 3.1 Systemumgebung Das Gesamtsystem besteht aus dem bi-cube Server mit der bi-cube Datenbank und dem RADIUS-Server im internen Netz der Firma. Der Access Control-Server realisiert den Anschluss an das globale Internet. Mit dem VPN-Client auf der Arbeitsstation des Remote Users erhält dieser dann einen kontrollierten Zugang zum internen Netz. Bild 1 Systemumgebung 3.2 Ablauf Der Remote User wendet sich mit seinem VPN-Client an den Access Server zwecks Verbindungsaufnahme. Dieser fragt die Nutzeridentität und das Kennwort ab und lässt sich die Richtigkeit der Angaben vom RADIUS-Server bestätigen. Dazu liest der RADIUS-Server die Informationen aus einer Datenbank und vergleicht sie mit dem vom Access Server empfangenen. Bei Übereinstimmung wird der Zugriff durch den Nutzer akzeptiert, anderenfalls abgewiesen

4 3.3 Verwendung eines SMS Tokens zur Authentisierung Bei der Arbeit im Internet bietet die Verwendung von Token eine höhere Sicherheit gegenüber mehr oder weniger statischen Kennworten. bi-cube bietet die Möglichkeit, ein SMS-Token anzuwenden. Dabei fordert der Nutzer vor der Verbindungsaufnahme ein solches Token über das bi-cube Web Portal an. Der bi-cube Server sendet dem Nutzer das Token per SMS und trägt es in die Datenbank ein. Der Nutzer empfängt das Token und setzt es bei der Verbindungsaufnahme zum Access Server als Kennwort ein. Bei der Authentifizierung liest der RADIUS-Server das Token aus der Datenbank und kann damit die Authentifizierung vornehmen. Bild 2 Tokenauthentifizierung via RADIUS 3.4 Verwendung des bi-cube Secu-Tokens Eine weitere Möglichkeit besteht in der Verwendung eines Software Tokens. Dabei wird das Token auf der Arbeitsstation des Nutzers generiert und kann vom RADIUS-Server auf seine Gültigkeit geprüft werden. Dazu muss allerdings das Token selbst übertragen werden. Damit ist als Authentifizierungsmethode PAP einzustellen. 3.5 Konfiguration Bei der Konfiguration muss der Access Server auf den bi-cube RADIUS-Server ausgerichtet werden. Als Authentifizierungsmethoden sind PAP oder MS-CHAP2 möglich. In beiden Servern muss das gleiche RADIUS-Geheimnis (secret) konfiguriert werden. Dazu wird in der Konfiguration des RADIUS-Servers die IP-Adresse des Access Servers und das secret angegeben

5 3.6 Nutzung Mit dem Token-Generator wird ein personalisiertes Token erzeugt und dem User als exe. auf einem USB-Stick oder auf seinem Rechner bereitgestellt. Je nach Einstellung kann das Token durch Biometrie oder PIN geschützt werden. D.h. es startet erst, wenn der Fingerprint identifiziert oder die PIN eingegeben und geprüft wurden. Diese Optrion ist auch abschaltbar. In der Nutzung (z.b. bei der Authentifizierung zu einem Portal) muss dann nach Eingabe von User-ID und Passwort das Token bereitgestellt oder ein SMS-Token angefordert werden

6 Diese Authentifizierung ist auch in einer Citrix-Welt einsetzbar! SMS Token anfordern

7 4 Token-Verfahren für externe Nutzer Alle bisherigen Verfahren gehen davon aus, dass der zu identifizierende Nutzer im System (AD usw.) bekannt ist und vielfältige Rechte haben kann. Einige Anwendungen (z.b. Bank-Kunden im Online-Banking) werden in der internen IT-Struktur nicht als User verwaltet. Sie haben ausschließlich Zugang zu dem Bank-Portal. Deshalb haben sie keinen direkten User-Account im AD usw. Eine komfortable und sichere Methode ist hierfür das PIN-gesicherte Token. Erst nach Eingabe der PIN startet der Tokengenerator. Das PIN-gesicherte Token kann dem Nutzer vom Ausgeben auf einem Memo-Stick generiert werden. Eine Option ist eine Sicherung, dass der Token nur auf dem übergebenen USB-Stick lauffähig ist, also nicht kopiert werden kann.der Token hat eine Laufzeit von 5 min. Innerhalb dieser Zeit muss es am Server zur Prüfung vorliegen

8 5 bi-cube PKI Technische Produktinfo: Auf Basis des Windows PKI-Servers ist in bi-cube eine PKI nutzbar. Die Verwaltung der PKI erfolgt als ein Subsystem (s. Bild unten als Beispiel für die Entrust PKI). Beschreibung des Ablaufes 5.1 Tokenverwaltung Die Token werden angeliefert mit einem bestimmten Seriennummernrange oder mit einer ASCII-Liste aller Seriennummern, die dann in den bi-cube Ressourcenmanager übernommen werden. Check des Auditors ob alle Token aufgenommen wurden (Stichproben). 5.2 Tokenzuweisung Dem User wird in bi-cube 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. bi-cube 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 (Registration Authority 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 bi-cube eintragen und bekommt den ihm zugeordneten Rohtoken. Der User generiert seine Keys beim RA-Officer

9 5.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 bi-cube aktiviert. Das ist mit dem Workflow der Zertifikatsausgabe so gekoppelt, dass durch bi-cube im AD eine entsprechende Einstellung vorgenommen wird. 5.4 Tokensperrung Da die PKI aus bi-cube -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. 5.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-Authentifizierung 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. Hierzu wird im IPM Web ein Verfahren angeboten, das dem Leiter gestattet, die Anmeldung für einen Tag mit Kennwort 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 veranlasst. Gleichzeitig wird auch der Umkehr-Vorgang durch eine zweite Message ausgelöst. Während dieses Tages wird das Zertifikat auf on hold gesetzt und die neue CRL wird automatisch publiziert. 5.6 Aufgaben des RA Officers*: - 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 * Funktion des RA Officers wird durch Innenrevision wahrgenommen bzw. festgelegt

10 Ablaufdarstellung für den Usereintritt mit Token - Rollout Tokenlieferung Seriennummer User Benutzer wird in bi-cube erfasst 1. Zertifikatsauswahl Signatur, Encryption, Authentifizierung bi-cube 2. bi-cube 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. bi-cube druckt Geheimbrief Daten: Username Büroadresse Authenticationcode 4. Referenznummer AuthenticationCode 6. Refernznummer per Zertifikat 10. Personalabteilung/ Hauptbanken 7. trägt Seriennummer im Ressourcen bi-cube ein bi-cube Ressourcen Manager User gibt Authenticationpassword ein 8. bi-cube 9. 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

11 5.7 Enge Integration einer PKI mit einem Identity und Provisioning System Ziel war es, die PKI Lösungen von Microsoft in das Provisioningtool bi-cube ( zu integrieren. Es sollte eine PKI zum Einsatz gebracht 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 bi-cube wurde weiterhin die Aktivierung des Zertifikatslogon und die Steuerung der Tokensperrung übernommen. Die Aufgaben des RA Officers 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 kein Token / 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 bi-cube 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 bi-cube abgebildet. Damit konnte 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 erst richtig handhabbar zu machen