IT-Sicherheit weltweit-Praxisbeispiel Single Sign-On
Werbung
IT-Sicherheit weltweit – Praxisbeispiel Single Sign-On Sebastian Glandien - Hamburg - 22.09.2014 1 Gründe für Single Sign-On 2 Gründe für Single Sign-On Ausgangslage Der Zugriff auf Applikationen bei Hapag-Lloyd ist durch Passworte geschützt Die User-Verwaltung und -Berechtigung wird zentral vom IT Access and Security Management verwaltet, alle Anträge werden in einer Datenbank gesammelt Die Passworte selbst werden von verschiedenen Systemen verwaltet: • Microsoft Active Directory im Windows-Umfeld • Host-LDAP / RACF für die selbstentwickelten Kernapplikationen • Applikations-spezifisch, wie z.B. für SAP Abhängig von diesen Systemen haben Passworte unterschiedliche • Bildungsregeln • Komplexität • Gültigkeitsdauer • Historie Konsequenzen: • Passworte werden aufgeschrieben • Passworte werden angeglichen • Im Monat gibt es durchschnittlich ca. 500 passwortbezogene Service-Requests beim IT Service Desk • Ein Single Sign-On (SSO) soll diese Probleme entschärfen 3 Gründe für Single Sign-On Was ist Single Sign-On? „Single Sign-on […] bedeutet, dass ein Benutzer nach einer einmaligen Authentifizierung an einem Arbeitsplatz auf alle Rechner und Dienste […] zugreifen kann, ohne sich jedes Mal neu anmelden zu müssen.“ Quelle: Wikipedia (www.wikipedia.org) Nach einer einmaligen Authentifizierung können Programme ohne weitere Anmeldungen verwendet werden, der Single Sign-On Mechanismus übernimmt die Authentifizierung des Anwenders Passworte werden im Hintergrund verwaltet Der Anwender muss nur noch ein Passwort für die Anmeldung am PC kennen 4 Gründe für Single Sign-On Erwarteter Nutzen Kostenreduzierung durch geringere Anzahl passwortbezogener Service-Requests: • Reduzierung der Anzahl der aktuell ca. 500 IT-Service Desk Calls pro Monat um 75% • Die Wartezeit der Bearbeitungsdauer entfällt • Der interne Aufwand für das regelmäßige Wechseln der Kennworte entfällt IT-Service Desk Calls pro Monat Wartezeit pro Call Entfall Zeit für Passwort-Wechsel Reduzierung 75% 75% 75% Akt. Anzahl 500 Calls 500 Stk. 5500 Anwender Dauer 20 Min. 5 Min. Verbesserung der Sicherheit , da Passworte nicht mehr notiert werden Verbesserung der Sicherheit , da Passworte für unterschiedliche Systeme nicht mehr künstlich vereinheitlicht werden 5 Einsparung 375 Calls 125 Std. 344 Std. Gründe für Single Sign-On Grundsätzliche Anforderungen an ein Single Sign-On bei Hapag-Lloyd Umsetzung des 80:20-Prinzips: • 20% der weltweit verfügbaren Applikationen decken 80% des Arbeitsumfelds ab • Non-Standard-Lösungen werden nicht von SSO berücksichtigt Nur das Windows-Passwort soll bekannt sein Revisionssichere Berechtigung für Applikationen • Zentrale Datenbank für alle diesbezüglichen Transaktionen • Keine User-Verwaltung über das SSO-Tool, alle Informationen werden Standard 80% über Stammdaten-Anlieferungen bereitgestellt Passworte • Übertragung und Speicherung erfolgt nur verschlüsselt • Anwender hinterlegen ihre Passworte selbst Non-Standard 20% Es finden keine Anpassungen an den Applikationen statt Bereitstellen eines Self-Services für Funktionen, für die heute der IT Service Desk bemüht wird Offline-Nutzung durch Firmen Notebooks muss möglich sein 6 Das Single Sign-On Projekt 7 Das Single Sign-On Projekt Entwicklung des Fachkonzepts Aufbauend auf dem PoC wurde gemeinsam mit der iSM Secu-Sys AG ein Fachkonzept erarbeitet, in dem die Anforderungen von Hapag-Lloyd beschrieben sind • • • • • • • 8 Bereitstellen von Applikationen gegliedert nach Passwort-Gruppen Unterschiedliche Nutzungsvarianten für SSO Bereitstellung eines Web-Portals Integration in die Hapag-Lloyd Directory Infrastruktur Einführung von Zwei Faktoren Authentifizierung User Self-Services Betrieb von SSO als Managed Service Das Single Sign-On Projekt Integration in die Hapag-Lloyd Directory Infrastruktur Vorgabe für die Einführung von SSO ist, dass keine User-Verwaltung über bi-Cube erfolgt. Alle Informationen werden über Stammdaten-Anlieferungen bereitgestellt: • Anwenderdaten und –attribute werden aus dem Host-LDAP übernommen • Hinzufügen bzw. Entfernen von Berechtigungen erfolgt per Webservice direkt aus dem zentralen Tool zur Hapag-Lloyd User-Verwaltung • Die Zuordnung der User-IDs in die Hapag-Lloyd Organisationsstruktur erfolgt aus der entsprechenden Datenbank • Die Zuordnung der User-IDs zu lokalen IT-Koordinatoren erfolgt anhand einer Datenbank LDAP LDAP/RACF Berechtigungen AD / Windows Organisation ITC 9 SAP Das Single Sign-On Projekt Integration in die Hapag-Lloyd Directory Infrastruktur Schnittstellen zu Benutzerverwaltungen: • LDAP- bzw. RACF-Schnittstelle zum Ändern des Host-Passworts • SAP-Konnektor zum Ändern des SAP-Passworts • Direkte Integration für Passwort-Änderungen am Windows-PC Am 23.03.2013 schlug der Mechanismus zum automatischen Passwortwechsel zu und änderte in Folge einer Kette unglücklicher Umstände alle LDAP- und SAP-Kennworte Ein SSO ist ein sehr mächtiges System, entsprechend wurden Schutzmaßnahmen implementiert LDAP LDAP/RACF Berechtigungen AD / Windows Organisation ITC 10 SAP Das Single Sign-On Projekt Bereitstellung eines Web-Portals Ziel des SSO-Projekts ist es, so viele Anwender wie möglich zur Nutzung von Single Sign-On mit automatischem Kennwort-Wechsel zu überzeugen Bedenken bestehen seitens der User ausschließlich bezüglich des Umstands, ungeplant von einem fremden PC auf Hapag-Lloyd Webseiten zugreifen zu müssen und das Passwort nicht zu kennen Aus diesem Grund wird ein Webportal bereitgestellt: • Anmeldung erfolgt mittels bekannten Windows-Kennwort • Von SSO verwaltete Kennworte können geändert werden 11 Das Single Sign-On Projekt Einführung von Zwei-Faktoren Authentifizierung Faktoren bei der Authentifizierung: • Etwas wissen: Kenntnis einer Information, zum Beispiel eines Passwortes • Etwas haben: Verwendung eines Besitztums, zum Beispiel eines Tokens • Etwas sein: Gegenwart des Benutzers selbst, zum Beispiel in Form biometrischer Merkmale Für den Zugriff auf bi-Cube Single Sign-On soll ein Token als zweiter Faktor eingesetzt werden: • Obligatorisch für die Anmeldung am Webportal • Optional für die Anmeldung am PC Die Bereitstellung eines Token erfolgt • per Token-Generator auf einem USB-Stick • durch Versand über SMS oder Email • via Mobile Token als Smartphone-App Wissen Biometrie Besitz 12 Das Single Sign-On Projekt User Self-Services Um die Anzahl passwortbezogener Service-Requests beim IT Service Desk zu reduzieren, wird ein entsprechender User Self-Service angeboten: • Für den Fall, dass das aktuelle Windows-Kennwort vergessen wurde kann aus dem Windows Anmelde-Bildschirm der Self Service gestartet werden • Die Authentifizierung erfolgt anhand von Sicherheitsabfragen, deren Antworten nur der Anwender kennt (forgot password auf nahezu jeder Website) • Ein neues Einmalkenwort wird wahlweise per SMS, per Email auf ein Hapag-Lloyd Smartphone oder per Email an den lokalen IT-Koordinator gesendet Für die Anmeldung an Web-Portal steht ein Self-Service zum Anfordern eines Tokens (Zwei-Faktoren Authentifizierung) zur Verfügung • Ein Token wird wahlweise per SMS oder per Email auf ein Hapag-Lloyd Smartphone gesendet Über einen Wizzard können sich Anwender eigene Applikationen für die Nutzung mit dem SSO-Client definieren: • Für diese Applikationen ist der Anwender selbst verantwortlich • Zusätzliche Motivation der Anwender zur Nutzung von SSO 13 Das Single Sign-On Projekt Betrieb von SSO als Managed Service Der Betrieb der SSO Server-Applikation wird von der iSM Secu-Sys AG als managed Service durchgeführt • • • • • 14 Basis-Betrieb der Server und der Infrastruktur durch IBM Ausbildung des IT Service Desk für 1st Level Support Integration durch iSM in die Workflows und Tools für Incident/ Problem/ Change Absicherung der Betriebsleistung durch SLAs Monatliches Service Meeting Das Single Sign-On Projekt Weltweiter Roll Out Der Hapag-Lloyd interne Roll Out des SSO-Clients erfolgte per Software-Verteilung: • Weltweit 125 Lokationen • Insgesamt 6900Clients • Zeitraum: April und Mai 2013 Begleitende Maßnahmen: • • • • • 15 Vorgelagerter Pilottest mit Mitarbeitern der IT und aus dem weltweiten Business Integration der dezentralen IT-Koordinatoren in den Roll Out (Multiplikatoren) Bereitstellen eines eLearning im Intranet zur User-Selbstregistrierung Artikel in der Mitarbeiter-Zeitschrift Veröffentlichung der gesamten Dokumentation im Intranet Single Sign-On in der Praxis 16 Praktische Ergebnisse nach Single Sign-On Einführung Sicherheit Kosten Funktionalität • Keine „unsicheren“ Kennwörter mehr • Zentrale Kontrolle der Passworte durch Single Sign-On • Schnelle Nutzerdeakivierung durch Kennwortwechsel • 2 Faktorauthentifizierung • Verringerung der Service Desk Calls für Passwortanfragen um ca. 50% • Schneller Anwendungszugriff • Einfache Kennwortverwaltung • Webbasierter User Self-Service für alle Kennwortverwaltungsfunktionen (Reset, Change und Unlock) 17 Rollout eines Single Sign-On Single Sign-On erfordert ein individuelles Changemanagement Hürden des Rollouts: • Max Mustermann denkt: „Mein Passwort gehört mir!“ • Falsche Vorstellungen zum Thema Single Sign-On SSO synchronisiert keine Kennwörter • Weltweit differenzierte Akzeptanz und Nutzung • der vollständige Funktionsumfang von SSO ist sehr umfangreich Wie rolle ich Single Sign-On aus?: • Individuelle Dokumentation (Handbuch, Nutzen, Use-Cases beschreiben) für alle (Service Desk, Nutzer und ITCs) • Step-by-Step: Use-Case für Use-Case Lokation für Lokation Service für Service • Konzentration auf den Standardnutzer (80/20 Regel) • Single Sign-On sollte verpflichtend sein 18 Ausblick 19 Zentrales Passwortmanagement mit Single Sign-On Vergabe der Kennwörter ausschließlich über Single Sign-On bzw. User Self-Service • Anlage neuer Nutzer durch IAM • Kennwortwechsel und -zurücksetzen für alle IT-Systeme Hapag-Lloyd Kennwortrichtlinien werden somit • restriktiv durchgesetzt • einheitlich kontrolliert und • können flexibel angepasst werden (zentrale Konfiguration + dezentrale Verteilung) 20 Sicherer Anwendungszugriff Verwendung der bi-Cube 2-Faktorauthentifizierung zum sicheren Zugriff auf Hapag-Lloyd 2-Faktorauthentifizierung mittels Token: • per Token-Generator auf einem USB-Stick • durch Versand über SMS oder Email • via Mobile Token als Smartphone-App Integration in das bi-Cube Web Portal • inkl. webbasiertem Single Sign-On 21
