IT-Riskmanagement in der 4. Dimension: IdM-as-a-Service

Transkript

1 IT-Riskmanagement in der 4. Dimension: IdM-as-a-Service Autor: Professor Dr. Dr. Gerd Rossa ism Institut für System-Management GmbH Oldendorfer Str Rostock Zusammenfassung Bei SaaS (Software as a Service) aus der Cloud wird Software nicht mehr als Lizenz erworben, sondern via Internet in Mietform betrieben. Die Bezahlung erfolgt in der Regel nutzungsabhängig. Aktuellen Analystenprognosen und Studien zufolge wird sich SaaS als zusätzliche Option zum traditionellen Lizenzmodell etablieren. SaaS hat einen entscheidenden Kostenvorteil, da nur die reine Funktionalität genutzt wird und diese auch noch nur lastabhängig vergütet werden kann. Ferner entfällt die Bereitstellung von Hard- und Systemsoftware und damit deren Kostenfaktor. Ein weiterer Aspekt ist der deutlich verringerte personelle Aufwand an Ausbildung und Systembetreuung, ein Aufwand, der auf Grund der komplexen Logik und unternehmensweiten Auswirkung oft unterschätzt wird und bei knapp bemessenem IT- Fachpersonal den Erfolg des Projekts gefährden kann. Mit dem Anbieter einer SaaS-Lösung aus der Cloud für Identity Management (IdM) sollten SLA in Bezug auf die Transaktions-Sicherheit und -Performance vereinbart werden. Im Prinzip bietet eine IdM-SaaS-Lösung dem Nutzer nur Vorteile. Dennoch bestehen Vorbehalte gegenüber dieser Nutzungsform, die sich insbesondere in 2 Argumenten manifestieren: 1. Unterschwellig wird diese Nutzungsform als Sicherheitsproblem gesehen. 2. Vielen Verantwortlichen ist ein festes Budget lieber als eine variable, wenn wahrscheinlich auch geringere, nutzungsabhängige Vergütung. Dass die Nutzung von Software aus der Cloud (SaaS) diverse Vorteile bietet, ist unbestritten. Diese Betriebsweise ermöglicht es vor allem dem Mittelstand, komplexe Lösungen zu nutzen, wozu sie aus Sicht des erforderlichen fachlichen IT-Betreuungspersonals in der Regel nicht in der Lage sind. Somit sind Cloudlösungen nicht begrenzt auf große Unternehmen. Im Gegenteil, sie erschließen auch dem Mittelstand komplexe Lösungen und den Anbietern leistungsfähiger IdM-Lösungen damit ein weiteres Marktsegment. Dennoch existieren diverse Argumentationen zu SaaS-Lösungen im Allgemeinen und zu IdM als SaaS-Lösung im Besonderen. Der Diskussion dieser Themen ist dieser Beitrag gewidmet. P. Schartner J. Taeger (Hrsg.) DACH Security 2011 syssec (2011) pp-pp.

2 2 IT-Riskmanagement in der 4. Dimension: IdM-as-a-service 1 Identity Management aus der Cloud Eine in mehreren Dimensionen wichtige Besonderheit einer SaaS(Software as a Service)- Lösung aus der Cloud besteht darin, dass der Nutzer nicht mehr Lizenznehmer ist und damit keine spezifische Form von Eigentum an der Software erwirbt, sondern sich dieselben Funktionen in Form von Services einkauft. Der Einkauf von Services bietet ein deutlich höheres Maß an Flexibilität in der teilweisen Nutzung von Komponenten einer komplexen Lösung bis hin zu einem deutlich unproblematischeren Wechsel des Anbieters. Dieser Vorteil wird allerdings durch den Zwang zu einer adäquaten Vertragsgestaltung erkauft. Für die Qualität der Services sind SLA zu definieren, die Einhaltung der Compliance- Anforderungen sicherzustellen und die Rechte der Stabsorgane des Kunden (z.b. Interne Revision) zu spezifizieren. Allgemein besteht die Meinung, dass ein Service aus der Cloud immer billiger als der Eigenbetrieb sein muss. Auf Grund der doch recht umfassenden Synergie-Möglichkeiten eines Dienstleisters kann dies im Prinzip auch so sein. Aber: Das Gesetz der Ökonomie verbietet es im Prinzip, für wenig Geld viel Wert erhalten zu wollen. Deshalb ist die Nutzung bzw. der Nutzen einer Software als SaaS nicht nur unter Kostenaspekten zu sehen. Vom Dienstleister werden in der Regel 2 Abrechnungsarten angeboten: Pauschal: Auf dieser Basis wird aus verwalteten Usern und Zielsystemen sowie genutzten Prozessen ein monatlicher User-Betrag in Rechnung gestellt. Transaktionen: Hier gilt der Grundsatz: nur was genutzt wird, ist zu vergüten. Dafür werden für die wesentlichen Transaktionen entsprechende Beträge festgesetzt. Für die SLA-Vereinbarungen mit dem Kunden werden vom Provider mehrere Versionen angeboten, die sich in der bereitgestellten Prozessor- und DB-Leistung unterscheiden und dadurch eben unterschiedliche Laufzeiten bedingen. Als ein Unsicherheitsfaktor ist die Bandbreite und aktuelle Last der Internetverbindung zu berücksichtigen. Dieser Fakt ist schwer quantifizierbar. Deshalb können einzelne Transaktionen durchaus die in den SLA vereinbarten Zeitlimits überschreiten, ohne dass dies beim Dienstleister liegt. Dieser Umstand kann beim Kunden u.u. Kosten verursachen, um die Bandbreitenanforderungen erfüllen zu können, die erforderlich sind, um die Cloud effektiv nutzen zu können. 2 Vielfacher Nutzen insbesondere für KMU Bei einer IdM-SaaS-Lösung entsteht für den Kunden kein direkter Aufwand für die Installation sowie die Konfiguration der Lösung und der spezifischen Modellierung. Der Einsatz und die Ausbildung eines aus mindestens 2 Personen bestehenden Betreuungsteams entfallen vollständig. Tests der Modellierungen von Rollen und Prozessen entfallen für den Kunden. Abhängig vom gewählten Supportlevel kann vom SaaS-Anbieter auch die Betreuung der Endkunden übernommen werden. Dem Kunden stehen immer die aktuellen Programmversionen und damit die neuesten Funktionen zur Verfügung. Auch entfällt der mitunter doch beträchtliche Migrationsaufwand beim Releasewechsel.

3 IT-Riskmanagement in der 4. Dimension: IdM-as-a-service 3 Die Nutzung von IdM-SaaS aus der Cloud ist deshalb vor allem für Kunden bis ca User eine wirtschaftlich äußerst sinnvolle Variante. Besonders kleinen und mittleren Unternehmen eröffnen sich ganz neue Chancen und Perspektiven. Über Cloud Computing können sie nun Dienste in einer Quantität, Qualität und Aktualität nutzen, wie es bislang nur großen Unternehmen möglich war. Ohne oder nur mit kleiner IT-Abteilung ausgestattet, ist es für sie von großem Vorteil, sich nicht um Betrieb und Wartung der Software kümmern zu müssen. Zudem können Sie sich auch den Aufwand für Ausbildung und Systembetreuung sparen. 3 Spezielle Architekturanforderungen Systemarchitektur für ein IdM aus der Cloud Im Gegensatz zu den bisher genutzten Applikationen aus der Cloud weist ein IdM aus der Cloud eine deutlich komplexere Architektur auf. Diese Besonderheit besteht in einer geteilten Architektur zwischen dem zentralen Service-System und den einzelnen Kunden. Die Systemarchitektur trennt die Datenverwaltungs- und Prozessfunktionalität des IdM von der eigentlichen Nutzung durch den Kunden. Die Architektur eines IdM aus der Cloud geht deshalb von einem Betrieb des Systems beim SaaS-Anbieter aus. Dieser betreibt die Datenbank und die zentralen Services. Die Zielsysteme des Kunden werden über verschiedene Verfahren durch das IdM mit User- und Berechtigungsdaten versorgt. Dies wird durch die sogenannten Connectoren realisiert. Das zentrale IdM-Cloud-System ist beim SaaS-Anbieter installiert. Für die Zugänge zu den Input- und Output-Connectoren sind entsprechend sichere Kommunikationskanäle aufzusetzen, die einerseits dem Kunden den Zugang zu seinen Verwaltungsfunktionen, andererseits in den Zielsystemen des Kunden die Provisionierung ermöglichen. Die eigentliche technische Herausforderung einer SaaS-Lösung ergibt sich auf folgenden Gebieten: 1. in der Lösung der Wirkungsweise der Connectoren auf die Zielsysteme des Kunden 2. im Aufbau sicherer Kommunikationskanäle 3. in der sicheren Datenhaltung und mandantenbezogenen Trennung der Daten Für die Output-Connectoren (OC) sind grundlegende Änderungen erforderlich, da eine Teilkomponente (Provider) jedes Connectors beim Endnutzer direkt in Verbindung mit den Zielsystemen des Kunden installiert sein muss. Diese Provider übernehmen beim Nutzer das Provisioning in die Zielsysteme. Bei dieser Problematik sind 2 Aspekte zu berücksichtigen: 1. eine gesicherte Kommunikation zwischen zentralem Connector und dem dezentralen Provider via Internet 2. die Technologie der Provider, welche im Wesentlichen von den Möglichkeiten einer Schnittstelle zu den jeweiligen Zielsystemen abhängt Direkte Connectoren wie ODBC, API usw. sind im IdM aus der Cloud nicht einsetzbar und werden durch eine Technologie ersetzt, die in der Lage ist, das Internet als Transportschicht zu nutzen.

4 4 IT-Riskmanagement in der 4. Dimension: IdM-as-a-service Abb. 1: Systemarchitektur Kommunikation Der SPML-Connector (Service Provisioning Markup Language) ist bei einem modernen IdM aus der Cloud der Kern der Kommunikationslösung zwischen dem Zentralsystem und den Zielsystemen beim Kunden. SPML ist ein XML-basierter Standard von OASIS, welcher für den Austausch von Benutzer-, Ressourcen- und Service-Informationen genutzt wird. Für die Übertragung von SPML werden die Standards SOAP und HTTP(S) verwendet. Mit Hilfe des SPML-Output-Connectors kann die Kommunikation zwischen dem IdM aus der Cloud und dem Zielsystem über eine standardisierte Schnittstelle erfolgen. Für den Datenaustausch wird hierbei das Request/Response Modell verwendet. Dem SPML-OC stehen entsprechende Templates, unter anderem Add-Request (neuen Datensatz anlegen), Modify-Request (Werte des Datensatzes verändern) und Delete-Request (Datensatz löschen), zur Verfügung. Der SPML-OC reagiert auf entsprechende Nachrichten z.b. zu Systemzuweisungen oder auf Attributänderungen. Aus diesen Daten erstellt der SPML-OC mit Hilfe der Templates SPML- Requests. Diese werden an das verbundene System geschickt und von dort mittels einer Response bestätigt. Daran erkennt der SPML-OC den Status des Requests. Leider "verstehen" nur wenige Standardsysteme SPML. SAP und auch Microsoft stellen z.b. für das AD noch kein SPML-Interface zur Verfügung. In diesen Fällen wird zwischen SPML-

5 IT-Riskmanagement in der 4. Dimension: IdM-as-a-service 5 Client und dem Zielsystem ein entsprechender Provider eingefügt, der die SPML-Nachrichten in das Format des Zielsystems übersetzt. Neben SPML ist LDAP ein im IdM aus der Cloud nutzbares Protokoll. Wenn ein Zielsystem über seiner API entsprechende Webservices bereitstellt, ist auch hier eine Cloud-Lösung möglich. Bestehende Messaging-Programme wie MQ-Series oder ZMQ sind ebenfalls für das Verfahren der geteilten Services einsetzbar. Wichtig ist für alle Verfahren, dass es einen eindeutigen Rückkehrcode für die ordnungsgemäße Abarbeitung des Services gibt. Das reine Absetzen von Scripten ist deshalb nicht ausreichend. Web-Fähigkeit der Verwaltung des IdM aus der Cloud Für den Nutzer eines IdM aus der Cloud sind alle Funktionen, die er zur Verwaltung seiner User und Systeme sowie der Modellierung von z.b. Rollen, Prozessen, Regeln benötigt, im Web bereitzustellen. Die berechtigten Nutzer kommunizieren per Web-Client mit dem System und dies im Wesentlichen mit folgenden Funktionskomplexen: 1. Verwaltung der User in Ergänzung automatischer Schnittstellen zum HR-System (z.b. Verwaltung der Externen) 2. Eigentliche IdM-Funktionen (Kompetenz - Beantragungs- und Freigabeprozesse) 3. Reporting und Compliance-Monitor 4. Pflege der Modellierung der Zielsysteme, Rollen und Prozesse Gesicherter Filetransfer Für einige permanente und temporäre Funktionen eines IdM aus der Cloud ist ein gesicherter Filetransfer zwischen Kunden und Dienstleister erforderlich. Hierfür stehen verschiedene Verfahren zur Verfügung: Vom Nutzer zum SaaS-Dienstleister: Regelmäßige Aktualisierung der Userdaten aus dem HR-System, wenn dies nicht per Web-Service möglich ist Bereitstellung von Migrationsdaten bei der Übernahme weiterer Zielsysteme in das IdM Bereitstellung von Berechtigungsdaten für den allgemeinen DifferenzCheck Vom SaaS-Dienstleister zum Nutzer: In diese Richtung gehen regelmäßig und ereignisbezogen: Daten aus dem Reportgenerator Daten aus dem Compliance-Monitor inkl. Informationen des IKS (Internes Kontrollsystem) Alerts, die sich aus Modellierungsproblemen ergeben, deren Lösung fachlich beim Kunden liegt (z.b. User, für die das System bei der Freigabe keinen Leiter findet) Gesichertes Betriebskonzept Das Ziel eines erweiterten Betriebskonzeptes besteht darin, die Modellierung von dem Produktiv-System zu trennen, um Modellierungsfehler, die gravierende Auswirkungen haben können, zu verhindern. Diese Methode hat für ein IdM aus der Cloud eine hohe Bedeutung erlangt. Mit der Funktionalität leistungsfähiger IdM-Systemen sind die Modellierungsmöglichkeiten so vielfältig und komplex, dass es ohne ausgiebige Tests nicht ratsam ist, Modellierungen gleich nach jedem Schritt in der Produktion wirksam werden zu lassen. Außerdem lässt sich auf diesem Weg eine freigebende Instanz einschalten, die bestimmte Modellierungen

6 6 IT-Riskmanagement in der 4. Dimension: IdM-as-a-service freigibt, bevor diese produktiv wirksam werden. Kern dieser Struktur ist das Entwicklungssystem. Abb. 2: Gesichertes Betriebskonzept Nachvollziehbarkeit Änderungen an den Metadaten eines IdM können weitgehende Auswirkungen haben. Deshalb ist die Nachvollziehbarkeit in Verbindung mit geregelten Freigabeprozessen insbesondere beim IdM aus der Cloud unverzichtbar. Freigabe von Änderungen an Rollen und Prozessmodellen Es sind aus Sicherheitsgründen folgende Kontrollfunktionen erforderlich: Für die Rolle wird ein Owner definiert. Wenn die Security-Classification (SC) der Rolle 4 oder 5 beträgt, darf die Änderung der Fachrolle nur von diesem Owner vorgenommen werden. Die Änderung der SC und anderer relevanter Attribute von Objekten des IdM darf nur auf Basis geregelter Prozesse erfolgen. Über einen allgemeinen Antrag muss eine Änderung vor Übergabe in das P- System genehmigt werden. Der Bearbeiter stellt in einem Formular die beabsichtigten Änderungen zusammen und lässt diese vom Compliance- Officer genehmigen.

7 IT-Riskmanagement in der 4. Dimension: IdM-as-a-service 7 Mandanten versus separate Installationen Eine wichtige Frage bei der Einführung einer SaaS-Lösung für einen Kunden ist die Entscheidung, ob er ein weiterer Mandant einer bestehenden Installation wird oder ein separates System erforderlich ist. Diese Entscheidung basiert auf folgende Kriterien: Ist ein wechselseitiger Zugriff auf Zielsysteme oder User anderer Mandanten erforderlich? Wie stark unterscheiden sich die Modellierungen und vor allem das Regelwerk in den Rollen und Prozessen? 4 Security-Probleme: Lösung und Messbarkeit Für ein IdM aus der Cloud ist ein umfassendes Securitykonzept unumgänglich. Es muss alle Aspekte enthalten, die aus Kundensicht problematisch sein könnten und vor allem deutlich machen, dass das Security-Konzept die Grundlage für verschiedenste Richtlinien und interne Prozesse sowohl beim Dienstleister als auch beim Kunden ist. Die Kundenseite ist dabei unbedingt mit einzubeziehen. Der Dienstleister, der für den Kunden ein IdM betreibt, muss z.b. sicher sein, dass die Systemadministratoren des Kunden nicht am zentralen IdM vorbei in ihren Systemen User und Berechtigungen direkt verwalten. In der Regel sind den Admins diese Rechte zu entziehen und es steht ihnen nur ein sogenannter Notfall-Account zur Verfügung. Andererseits muss der Dienstleister durch einen DifferenzCheck in regelmäßigen Abständen für die Konsistenz beider Ebenen sorgen. Der Kunde ist auch jederzeit berechtigt, beim Dienstleister entsprechende Security-Audits auf Basis des Securitykonzeptes durchzuführen. Security & Compliance bei SaaS Für ein IdM als SaaS ist eine entsprechende Sicherheitsarchitektur aufzusetzen, die dem Nutzer das geforderte Maß an Sicherheit garantiert. Diese Anforderungen können zwischen den Nutzern differenziert sein, da ein hohes Maß an Risiko-Prävention auch erhöhten Aufwand bei beiden Partnern zur Folge hat. In der aktuellen Situation stehen folgende Aufgaben aus dem Bereich Security und Compliance im besonderen Fokus: Reduzierung der Risiken in Bezug auf Missbrauch von Daten Durchgehende Nachweisbarkeit aller Berechtigungen und deren Management Kostenreduzierung durch teilweise Automatisierung der IT-Administrationsprozesse Qualifizierung der IT-Services von Dienstleister gegenüber deren Kunden Diese Aufgaben werden anteilig durch verschiedene Methoden und Organisationslösungen im Gesamtkontext einer in sich konsistenten Sicherheitsarchitektur in der gewünschten Richtung beeinflusst. Das IdM aus der Cloud ist vor einem unauthorisierten Zugriff auf verschiedenen Ebenen zu schützen: 1. Remote-Zugang über den Web-Client 2. Zugang zu den FAT-Clients der Admins 3. Zugang zu technischen Tools 4. Direkter Zugang zu gespeicherten Daten

8 8 IT-Riskmanagement in der 4. Dimension: IdM-as-a-service Der normale IT-Anwender bewegt sich in den Ebenen 1 und max. 2. Ihm werden dafür selektiv Funktionen bereitgestellt, die er zur Erfüllung seiner Aufgaben in den unternehmensspezifischen Geschäftsprozessen benötigt. Diese selektive und aufgabenbezogene Bereitstellung von IdM-Funktionen wird durch das Rollenmodell direkt und aufgabenbezogen erledigt. Systemübergreifendes Access-Management Innerer Kern eines IdM aus der Cloud ist die gesicherte Authentifizierung der Person. Dies geschieht in den überwiegenden Fällen immer noch mit der Kombination User-ID und Passwort, obwohl seit langem bekannt ist, dass dieses Verfahren den Anforderungen an Zuverlässigkeit der Identifikation der Person nicht ausreichend entspricht. Deshalb haben die Admins oft ausschließlich mittels Biometrie oder anderen gesicherten Authentifizierungen Zugang zu den Kundensystemen. Diverse andere Sicherheitseinstellungen, deren Nutzung durch entsprechende Policies zwingend vorgeschrieben ist und auch partiell für die User des Kunden gelten, sind z.b. Ein User mit Admin-Rechten darf sich nicht selbst administrieren Bestimmte Modellierungsänderungen sind über ein Antragsverfahren durch den Kunden freizugeben, z.b. Antrag für neue Rollen oder Rollenänderungen Die Funktion einer Doppelrolle im Antragsprozess (Antragsteller=Genehmiger) wird entsprechend einer Policy geregelt Für Abweichungen, die sich im DifferenzCheck ergeben, gelten eindeutige Regeln der Auflösung dieser Abweichungen Verstöße gegen die Regeln der Segregation of Duties (SoD) sind aufzulösen Automatisierung als Beitrag zur Sicherheit Jeder automatisierte IdM-Prozess aus der Cloud ist ein Beitrag zur Sicherheit, da jeglicher manuelle Eingriff mit gewollten oder ungewollten Verstößen gegen die Security-Richtlinien vermieden wird. Schutz vor Datendiebstahl Dem Schutz vor Verlust von Kunden- oder auch Personaldaten kommt eine hohe Bedeutung zu. Datendiebstahl erfolgt in der Regel durch direkten Zugriff auf Datenbanken. Diese Zugriffsebene steht nur Administratoren zur Verfügung. Maßnahmen zur Verhinderung: Verschlüsselung relevanter String-Daten Trennung der Personen-Identifikationsdaten von den Business-Daten Professionelle IdM bieten eine Komponente zur Verwaltung privilegierter Accounts IT und Compliance IT-Compliance ist ein Aspekt der allgemeinen Compliance-Vorgaben und hat die Einhaltung von Verhaltensmaßregeln, Gesetzen und Richtlinien im IT-Bereich sicherzustellen. Hierbei spielen IdM-Lösungen, die eine umfassende Verwaltung aller User und deren Berechtigungen steuern, eine wesentliche Rolle. IdM-Systeme erhöhen vor allem Prozess-Sicherheit durch die weitgehende Automatisierung der Berechtigungsverwaltung, die übergreifende Kontrolle der Funktionstrennung (Segregation of Duties) und die Sicherung der umfassenden Nachvollziehbarkeit aller Beantragungen, Freigaben und Zuordnungen. Internes Kontrollsystem (IKS) im IdM Ein IdM stellt in seiner zentralen Position über allen Usern und deren Berechtigungen in den Zielsystemen des Kunden ein System mit einem hohen Risikopotential dar, dem entsprechend

9 IT-Riskmanagement in der 4. Dimension: IdM-as-a-service 9 zu begegnen ist. Ein IdM wirkt unternehmensweit, sowohl im positiven als auch im negativen Sinne. Deshalb sollte ein IdM ein eigenes IKS haben. Damit gibt es kein Warten auf die IR, um die Vergangenheit auszuwerten, sondern ein aktives Reagieren. Ziel ist deshalb ein automatisches Risiko- und Compliance-Controlling, das Real-Time wirkt. Lösungen hierzu gibt es in den entsprechenden IdM-Lösungen, z.b. bei bi-cube mit dem IKS, dem Compliance- Monitor und vor allem den bereitgestellten Generischen Prozessmodellen. Die Real-Time Überwachung des IdM basiert auf einem Regelwerk zur Ermittlung auffälliger Vorgänge und Koinzidenzen, der Aufdeckung von Häufungen von sicherheitsrelevanten direkten Operationen, sowie der Häufung von Abweichungen vom Rollenmodell. Die Verstöße gegen die Compliance-Parameter des IdM werden automatisiert an entsprechende Stellen gemeldet. Ein besonders leistungsfähiges IKS stößt auch den geordneten Entzug von nicht Compliancekonformen Berechtigungen an. Organisationsstrukturen und Geschäftsprozesse Eindeutige Organisationsstrukturen und definierte Geschäftsprozesse sind ein wesentlicher Beitrag zur Reduzierung der Risiken im Bereich der IT- und der Berechtigungs- Administration. Rollen, Regeln und Prozesse Um diesen Anforderungen an ein IdM zu entsprechen, muss es ein praxistaugliches und leistungsfähiges Rollenmodell haben. Die wirkliche Praxistauglichkeit ergibt sich aber erst in der direkten Integration mit dem Prozess-Management. Einfache Rollenmodelle entgleiten den Nutzern sehr schnell in eine hohe und unübersichtliche Zahl von Rollen. Im Extremfall hat man dann mehr Rollen als User (!). Die Lösung besteht in der Parametrisierung von Rollen, die jedoch nur im Rahmen der Prozessmodellierung nutzbar ist. Ergänzt werden muss das Rollenmodell mit sogenannten Prozess-Controls und logischen Regeln, die die Konfiguration und den Ablauf eines Prozesses steuern. Die regelbasierte Indizierung von Rollen steuert die Eingrenzung der möglichen Rollen auf das Aufgabengebiet des Users. Somit bilden Rollen, Regeln und Prozesse eine funktionale und logische Einheit. Generische Prozessmodelle im IdM Jeder automatische Prozess ist ein Beitrag zu Compliance & Kostenreduzierung. In der letzten Zeit haben sich entsprechende IdM-Prozessgruppen herausgebildet. Dazu gehören u.a. die Wechselprozesse des Users, die Antragsverfahren zur Zuordnung von Rechten und Ressourcen und die Wiederholungsfreigaben (Re-Prozesse, siehe unten), die ihre Ursache in spezifischen Compliance-Vorgaben wie z.b. SOX haben. Besondere Bedeutung haben die Wechselprozesse des Users, die sich auf den Mitarbeitereintritt, seinen Austritt und die Wechselprozesse der User im Unternehmen beziehen. In der Vergangenheit bedeutete jeder Wechsel der Funktion des Users eine weitere Ansammlung von Kompetenzen (Rechten), obwohl mit einem Wechsel eigentlich einige Kompetenzen nicht mehr benötigt und somit entzogen werden müssten. Weitere wichtige Standardprozesse sind die sofortige Usersperrung, die saubere Behandlung des Wechsels bzw. Wiedereintritts in Konzernstrukturen und die Problematik, dass einige Mitarbeiter Diener zweier Herren, d.h. in mehreren Organisationseinheiten tätig sind. Diese sogenannten Shadow-User stellen ein logisches Problem dar, das von einem effizienten IdM aber lösbar ist.

10 10 IT-Riskmanagement in der 4. Dimension: IdM-as-a-service Das IdM-Prozessmanagement unterstützt Compliance direkt mit den Prozessen der Re-Zertifizierung (Wiederholungsfreigaben eines erteilten relevanten Nutzungsrechts) Re-Validierung (Wiederholungsbestätigung für die Existenz eines Users) Re-Confirmation (Wiedervorlage wichtiger User-Richtlinien zur erneuten Bestätigung) 5 Risken, Regeln und Vorgehensmodelle Undifferenzierte Bedenken Recht schwer zu argumentieren sind Bedenken, die mehr aus dem Gefühl heraus kommen und in der Regel darin münden, dass es doch ein Risiko ist, die Verwaltung von Berechtigungen ALLER wichtigen Zielsysteme des Kunden nach außen zu geben und die Daten nicht im eigenen Rechenzentrum zu wissen. Dieser Argumentation kann nur durch die Ermittlung und Wertung der realen Risiken sowie deren gerichteter Beeinflussung entgegen getreten werden. Allgemeine Risiken Im IT-Risiko-Management sind folgende Risiken zu klassifizieren und in ihrer jeweiligen Ausprägung zu bewerten. Speziell aus Sicht eines IdM können Risiken durch ein IdM verringert werden. Generell ist jeder Schadensfall mit einem mehr oder weniger hohen Image- Verlust verbunden. Tab. 1: Allgemeine Risiken Risiko Schadens-Art Image- Verlust Relevanz für IdM Verlust von Daten Verringerte Betriebsfähigkeit mittel IdM hat wenig Einfluss Missbräuchliche Nutzung von Daten Missbräuchliche Nutzung von IT- Funktionen Verringerte Verfügbarkeit Verstöße gegen Gesetze z.b. Datenschutz Schäden im Wettbewerb durch Verlust von Betriebsgeheimnissen Manipulation von Sachverhalten (z.b. Bilanz) Kriminelle Manipulationen (z.b. Bereicherung) Mitarbeiter können nicht die für Ihre Arbeit erforderlichen IT-Ressourcen nutzen.=> Opportunity-Costs hoch hoch hoch hoch mittel Kann durch IdM maßgeblich beeinflusst werden Ist mit den SoD-Regeln des IdM eindeutig zu verhindern. Beim IdM aus der Cloud ist ein höheres Maß an Sicherheit gegeben als beim Eigenbetrieb. Kann durch SoD-Regeln und funktionsbezogene Rechte verringert werden Ein IdM sorgt dafür, dass die Mitarbeiter (rechtzeitig) alle zur Erledigung ihrer Aufgaben erforderlichen Rechte (und nur diese) haben. Geringe Performance Verlust von Arbeitszeit gering Bei einem IdM aus der Cloud kann dies durch den Kanal Internet negative Auswirkungen auf die Performance haben.

11 IT-Riskmanagement in der 4. Dimension: IdM-as-a-service 11 Risiken im Betrieb eines IdM Die folgende Tabelle stellt eine Risiko-Matrix für den Betrieb eines IdM im Eigen- und im SaaS-Betrieb gegenüber. Unabhängig von der konkreten Ausprägung der Priorisierung eines Risikos und dessen Bewertung ist die Tendenz klar und eindeutig. Ein Dienstleister hat strengere Richtlinien und organisatorische sowie technische Ausschließungen, die das Risikopotential gegenüber dem Eigenbetrieb deutlich abfallen lassen. Risiko Tab. 2: Risiken im Betrieb Priorität Eigen- betrieb Administratoren agieren direkt im Zielsystem Modellierung erfolgt direkt im P-System Abschaltung von wichtigen Compliance-Grundeinstellungen Keine Nutzung des Test-Systems bei neuen Funktionen Keine durchgängige Beachtung des gesicherten Betriebskonzeptes Keine Beachtung der Alert-Meldungen Von Standard-Modellierungsrichtlinien stark abweichende Modellierung Nutzung nicht-dokumentierter Funktionen Nutzung nicht freigegebener Systemsoftware (z.b. DB) Unzureichende Hardware Risiko-Prioritätzahl 52 4 IdM SaaS IdM-spezifische Risiken Überlagert werden diese thematischen Risiken durch die Möglichkeit der ungewollten Fehlbedienung von kritischen Systemen (wozu ein IdM mit Sicherheit gehört) durch ungenügend geschultes bzw. wenig erfahrenes Personal. Eine solche Fehlbedienung kann auf Grund der Breitenwirkung eines IdM große Probleme bzw. Risiken zur Folge haben. In der Minimierung dieses Risikos liegt ein wesentlicher Vorteil eines Dienstleister, der ein IdM aus der Cloud anbietet und betreibt. Die Risiko-Argumentationen einer SaaS-Lösung für ein IdM bestehen in der Regel in folgenden Punkten: 1. Unsere User- und Berechtigungs-Daten liegen nicht mehr bei uns. 2. Die Nutzung dieser Daten unterliegt nicht bzw. nur begrenzt unserer Kontrolle 3. Fremde Administratoren können sich Rechte auf unseren Applikationen beschaffen 4. Garantiert der Dienstleister eine juristische Separation seiner Mandanten-Daten? Wie geht ein Dienstleister mit dieser Argumentation bzw. den Risiken um? Er versucht, eine Trusted Cloud for IdM aufzusetzen und die Eigenschaften einer Trusted Cloud for IdM und die Maßnahmen zu ihrer Realisierung zu definieren und dem Kunden gegenüber zu dokumentieren.

12 12 IT-Riskmanagement in der 4. Dimension: IdM-as-a-service Trusted Cloud für IdM Im Grundsatz ist davon auszugehen, dass ein professioneller Betreiber eines IdM auf Grund seiner Erfahrungen und des vorhandenen Personals sowie der strikten internen Security- Richtlinien ein deutlich höheres Maß an Sicherheit organisieren kann, als ein Kunde für sich alleine. Der Dienstleister hat vor allem fachlich hinreichende Kapazitäten zur Verfügung, um die jeweiligen spezialisierten Aufgaben sicher und den Compliance-Anforderungen entsprechend zu erledigen. Für ein IdM in der Trusted Cloud muss es eine interne Regel im IdM geben, dass ein Mitarbeiter des Dienstleisters grundsätzlich keine Systemberechtigungen in Zielsystemen der Kunden haben darf. Um das zu verhindern, gibt es verschiedene Möglichkeiten. Die Regeln an den Fachrollen sind alle mandantenbezogen zu definieren und sind somit für die Admins des Dienstleisters nicht erreichbar. Organisatorische Maßnahmen Die deutsche Cloud Eine Gruppe von organisatorischen Maßnahmen ergeben sich aus den Regeln der Initiative Cloud Services Made in Germany, die im Prinzip sichern sollen, dass der Kunde sich im vertrauten juristischen, sprachlichen und organisatorischen Umfeld bewegt: 1. Das Unternehmen des Cloud Service-Betreibers wurde in Deutschland gegründet und hat dort seinen Hauptsitz. 2. Das Unternehmen schließt mit seinen Cloud Service-Kunden Verträge mit Service Level Agreements (SLA) nach deutschem Recht. 3. Der Gerichtsstand für alle vertraglichen und juristischen Angelegenheiten liegt in Deutschland. 4. Das Unternehmen stellt für Kundenanfragen einen lokal ansässigen, deutschsprachigen Service und Support zur Verfügung. Zusätzlich ist zu fordern: Die Cloud mit den Daten ist nicht irgendwo Die obigen Vorgaben stellen allerdings nicht sicher, dass die Daten sich in einem bestimmten Rechenzentrum in der EU oder besser in Deutschland befinden und auch keine BackUp s außerhalb dieses territorialen Raumes befinden. Der Kunde ist Eigentümer der Daten in der Cloud Der Kunde muss jederzeit berechtigt und in der Lage sein, seine Daten zu übernehmen und die Sicherheit haben, dass diese keine Spuren beim Dienstleister hinterlassen, d.h. alle Sicherungen, Logfiles und Reports sind ebenfalls nachweislich zu übergeben bzw. zu löschen. Warum eine deutsche Cloud gerade für ein IdM wichtig ist, geht aus dieser Information ganz eindeutig hervor ( Wer bei US-Unternehmen Daten in der Cloud abspeichert, ist nirgends vor dem Zugriff der Geheimdienste sicher. Das hat ein hochrangiger Microsoft-Manager aus Großbritannien bei der Vorstellung von Office 365 eingestanden. Ein britischer Microsoft-Manager hat erklärt, dass Cloud-Daten auch außerhalb der USA nicht vor dem Zugriff durch den USA Patriot Act sicher wären. Auf die Frage des britischen IT-Branchendienstes ZDNet UK, ob Microsoft garantieren könne, dass europäische Daten, die in Datenzentren in der EU abgespeichert sei-

13 IT-Riskmanagement in der 4. Dimension: IdM-as-a-service 13 en, auch unter dem Patriot Act nicht aus Europa geholt werden können, sagte Gordon Frazer: "Microsoft kann diese Garantie nicht gewährleisten. Das kann auch kein anderes Unternehmen." Frazer ist Managing Director bei Microsoft Großbritannien. Weil der Softwarekonzern seinen Hauptsitz in den USA habe, unterliege Microsoft den US-Gesetzen. "Doch Kunden werden informiert, wo immer es möglich ist", versicherte Frazer. Das Antiterrorgesetz wurde im Jahr 2001 erlassen. Das Gesetz hebt die Richterkontrolle bei Telefon- oder Internetüberwachung weitgehend auf und erweitert die Abhörrechte des FBI und der CIA deutlich. Telekommunikationskonzerne und Internetprovider müssen die Kundendaten offen legen. Trennung der Verantwortung Der Dienstleister deckt zwei Problembereiche ab, die dem Kunden erfahrungsgemäß den Betrieb der Lösung deutlich vereinfachen, die Verfügbarkeit erhöhen und das Leistungspotential besser ausschöpfen: Analyse, Beratung und Unterstützung bei Modellierungsfragen und -aufgaben Sicherstellung eines konsistenten Betriebs des Systems Einführungsstrategie Die Einführung einer SaaS-Lösung für ein IdM ist, auch wenn diverse sonst übliche Aktivitäten wegfallen, im Rahmen eines Projektes zu planen und abzuwickeln. Das System wird im Rahmen eines 2-stufigen Beratungs-Projektes eingeführt. Der Kunde nutzt nur noch den Web- Client und hat mit der gesamten Betriebsführung nichts weiter zu tun. Technische Maßnahmen Gesicherte Authentifizierung der Admins des Dienstleisters Die Admins des Dienstleisters sind gezwungen sich dual zu authentifizieren, um eine hohe Hürde vor Fremdnutzung dieser Accounts aufzubauen. Im IdM bi-cube ist z.b. zwangsweise die Biometrie eine notwendige Authentifizierung der Admins. Mandantentrennung Ein IdM aus der Cloud bedient typischerweise mehrere Kunden als Mandanten einer Installation. Diese Betriebsart setzt ein IdM voraus, das eine saubere juristische Mandantenverwaltung inkl. entsprechender Exportfunktionen sicherstellt. Es darf keine Funktionen geben, die die Grenzen zwischen den Mandanten überschreiten bzw. durchtunneln. Segregation of Duties (SoD) für die Administratoren Basisregel für Admins ist, dass sich ein Admin nicht selbst bearbeiten kann. Kein Admin sollte über Rechte verfügen, dies es ihm gestatten, einerseits Modelländerungen vorzunehmen und andererseits auch noch einem User Rechte und Rollen zuzuweisen. Mit diesen Regelungen ist mit einem externen Dienstleister in Bezug auf die Admin- Risiken ein deutlich höheres Security-Niveau zu erreichen, als es mit internen Admins möglich wäre. Die Admins der Kunden haben in keiner Weise derart strikt getrennte Rechte (SoD) und haben auch durchaus Rechte in Zielsystemen des Kunden, womit dies nicht generell zu unterbinden ist.