Whitepaper Identity Management im Kontext mit (relativ) selbständigen Units am Zentralsystem

Transkript

1 Identity Management im Kontext mit (relativ) selbständigen Units am Zentralsystem T e c h n o l o g i e n L ö s u n g e n T r e n d s E r f a h r u n g

2 Inhalt 1 ALLGEMEINE ANFORDERUNGEN Schutz von Unternehmens- bzw. Kundendaten Gesicherte Authentifizierung USE CASES Finalist / Zulieferer Konzernzentrale bzw. Landeszentrale / Händler Beispiel Automotive Versicherungen / freie Makler Outsourcing von IT - Systemen / Supportunterstützung Reedereien / Schiffe BUSINESS MODEL Strukturierung der Unternehmen Rechte - Management Multi Level Struktur info@secu-sys.de Web: Seite 2 von 8

3 1 Allgemeine Anforderungen Es gibt Unternehmensstrukturen, die neben einer Zentrale diverse relativ selbständige Units verwalten. Solche Konstellationen finden sich im Verhältnis zwischen Endproduzenten und Lieferanten, Konzern- bzw. Landeszentralen und deren Händlernetzen, Versicherungskonzernen und ihren Agenturen bzw. Maklern, im Bereich des IT Outsourcing sowie Transport und Touristik (z.b. Reedereien mit angeschlossenen Logitikunternehmen und Schiffen) und vielen mehr. Damit verbunden sind stets hohe Anforderungen an den Schutz von Unternehmens- bzw. Kundendaten, sowie eine gesicherte Überprüfung der Identität von Benutzern: 1.1 Schutz von Unternehmens- bzw. Kundendaten Kennzeichnend für dieses Business Model ist, dass die meist (juristisch) selbständigen Units Zugriff auf zentrale Unternehmensdaten haben und diese Zugriffe dediziert zu berechtigen sind und kontrolliert werden müssen, um unberechtigte Nutzung von Unternehmensdaten zu verhindern. 1.2 Gesicherte Authentifizierung U.U. sind bestimmte Rechte mit personenbezogenen Zertifikaten verbunden, womit eine gesicherte Authentifizierung gegeben sein muss, um die unberechtigte Weitergabe dieser Accounts an nichtzertifizierte User zu verhindern. 2 Use Cases Dieses Modell trifft standardmäßig und beispielhaft für folgende Situationen zu: 2.1 Finalist / Zulieferer Der Finalist betreibt ein Identity Management (IdM) - System und bindet seine Zulieferer mit dedizierten Rechten in seine IT-Anwendungen ein. Die Verwaltung der Mitarbeiter des Zulieferers, die Zugriff auf diese Systeme haben sollen, soll jedoch auf den Zulieferer selbst delegiert werden, da dieser in seiner direkten Sachkenntnis am besten zeitnah und aufgabenbezogen die entsprechenden Verwaltungen vornehmen kann. Dies sind zwei Kategorien von Aufgaben: 1. Die Verwaltung der Mitarbeiter des Zulieferers mit ihren Daten als User im IdM 2. Die Verwaltung der aufgabenbezogenen Berechtigungen der Mitarbeiter des Zulieferers in den Systemen des Finalisten Grundprinzip ist, dass es keine sog. Gruppen - User gibt, sondern jeder Mitarbeiter personalisiert im System seine Berechtigungen hat. Damit ist eine eindeutige und personenbezogene Nachvollziehbarkeit auch in der dezentralen Unit gegeben. info@secu-sys.de Web: Seite 3 von 8

4 2.2 Konzernzentrale bzw. Landeszentrale / Händler Beispiel Automotive Automobilhersteller betreiben z.b. Landes- oder Gebietszentralen, die dann eigenständige Händler und Werkstätten beliefern. In diesem Umfeld wird noch weitgehend mit Gruppen - Usern gearbeitet, die dann Zugriff zu zentralen Daten für Vertrieb und Technik haben (Lager- und Lieferdaten, Ersatzteile und technische Dokumentationen). Die Kundendaten werden für zentrales Marketing, Reklamationen usw. auch zentral gehalten, aber in der Regel nur händlerbezogen bereitgestellt. Da es sich hier auch um personenbezogene Daten incl. Zahlungsinformationen usw. handelt, sind diese Daten einem besonderen Zugriffsschutz zu unterziehen. Deshalb ist hier unbedingt von Gruppen - Usern zu personen- und aufgabenbezogenen Berechtigungen (Rollen) überzugehen. Ein Schlosser darf nicht die Zahlungsdaten eines Kunden sehen können. 2.3 Versicherungen / freie Makler In einer ähnlichen Situation befinden sich viele Finanzdienstleistungsunternehmen, die mit externen Vertriebsstrukturen arbeiten. Auch hier sind an den Schutz der Kundendaten besonders hohe Anforderungen zu stellen. Auf Veränderungen bei den externen Partnern ist eine umgehende Reaktion erforderlich. Es ist z.b. sicherzustellen, dass der Wechsel bzw. Austritt eines externen Vertriebsmitarbeiters umgehend in seinen Berechtigungen berücksichtigt wird. 2.4 Outsourcing von IT - Systemen / Supportunterstützung Dienstleister betreiben in der Regel Anwendungen von verschiedenen Kunden in einer IT- Infrastruktur. Aus Sicht des Dienstleisters ist es aber auch sinnvoll, ein System zu haben, in dem die User verschiedener Kunden enthalten sind, z.b. für das Error-Management oder den Support. Auch hier ist es sinnvoll, dass die Kunden ihre Mitarbeiter in ihrem Bereich eigenständig verwalten und diesen fachbezogene Rollen zuzuordnen. Zusätzlich kann hier noch der Umstand auftreten, dass bestimmte Rollen an Zertifikate des Dienstleisters gebunden sind. Nur mit einem Zertifikat kann z.b. eine Supportanfrage zu einem bestimmten System abgesetzt oder ein Fehler gemeldet werden. Dadurch werden qalifizierte Meldungen der Nutzer gewährleistet. 2.5 Reedereien / Schiffe Für diesen Business Case gibt es prinzipiell 2 Möglichkeiten bzw. allgemeine Architekturansätze: 1. Die direkte Administration der Zielsysteme auf den Schiffen 2. Die Administration der Zielsysteme auf den Schiffen durch einen bi-cube Kern und dessen Anbindung an das Zentralsystem Er ist zusätzlich durch folgende mögliche Einschränkungen gekennzeichnet: 1. die Datenverbindung zu den Units ist störanfällig, langsam und teuer (z.b. zu Schiffen) 2. die dezentrale Unit hat keine Kapazitäten, um ein IdM vollinhaltlich zu administrieren Der allgemeine Ansatz stellt folgende Funktionalität bereit: In der Unternehmenszentrale wird ein voll ausgebautes zentrales bi-cube installiert, in dem alle User und alle Zielsysteme verwaltet werden sowie das Rollenmodell erstellt wird. In den Units gibt es ein bi-cube Core System mit deutlich eingeschränkter Funktionalität. Seine Konfiguration, Regeln, Security Policies und die Unit - bezogenen Rollen sind fest vorgeben und info@secu-sys.de Web: Seite 4 von 8

5 können nur bei Bedarf von der Zentrale geändert werden. Die User in den Units werden über dezentrale Services verwaltet, die von der Zentrale mit Daten beliefert und getriggert werden. Somit ist das führende User - Verwaltungssystem die Zentrale. In die Units werden nur Teilmengen von Usern repliziert. Im Einzelfall können deshalb die dezentralen Admins über einen Web - Client einzelne User in der Zentrale administrieren, die dann über die Services in die Unit propagiert werden. In der Unit haben einige Mitarbeiter für ihre Unit auch das Recht, den Usern unit - spezifische Rollen zuzuordnen, um den operativen Betrieb zeitnah sicherstellen zu können (z.b. temporäre Vertretung). Scenario 1 Im ersten Fall gibt es nur ein bi-cube und die Connectoren der Zielsysteme auf den Schiffen werden direkt durch die Zentrale angesteuert. Um die geringe Bandbreite und Zuverlässigkeit des Übertragungskanals auszugleichen, wird hier ein sicherer Message - Kanal aufgebaut, der die Daten paketweise und mit Kontrollinformationen überträgt. Im Grundsatz erfolgt aber jede Änderung am User und dessen Rechten entweder direkt durch die Admins der Zentrale oder durch die Nutzung eines Web-Clients auf den Schiffen. Ein Notfallregime ist dergestalt möglich, dass in den Zielsystemen auf den Schiffen wie bisher direkt administriert wird. info@secu-sys.de Web: Seite 5 von 8

6 Scenario 2 Wenn die Übertragungsbedingungen schlecht sind oder auf den Schiffen sehr häufig Änderungen von Rollen und Rechten notwendig sind, dann kann die Variante der abgesetzten Core - Systeme von bi-cube gewählt werden, die in weiten Zügen eigenständig agieren können aber trotzdem mit dem Zentralsystem in Verbindung stehen. Der bi-cube Core ist in seiner Modellierung fest. Lokal können nur in festgelegten Grenzen die lokalen User administriert und diesen Usern die Rollen zugeordnet bzw. auch entzogen werden. In dieser Konstellation können auch komplexe Freigabeprozesse für Rollen intern auf dem Schiff abgewickelt werden, da die WF - Engine auch lokal läuft und somit keine Kommunikation zur Zentrale erfordert. Voraussetzung dafür ist, dass in die Prozesse keine Personen außerhalb des Schiffs einbezogen sind. Das ist von der Logik zwar möglich, erfordert dann jedoch die Kommunikation mit der Zentrale. info@secu-sys.de Web: Seite 6 von 8

7 3 Business Model Über entsprechende Konfigurationen von bi-cube bietet das bi-cube IPM eine Plattform für diese Use Cases. 3.1 Strukturierung der Unternehmen Hierbei wird eine hierarchische Unternehmensstruktur modelliert, an deren Blättern die selbständigen Units (im Folgenden als Units bezeichnet) angeordnet sind. Bei Bedarf können diese Units eigene Unterstrukturen haben, wenn das Regelwerk der Prozess - Steuerung sinnvoll ist. Eine Unit wird dann bei der Art der Organisationseinheit als solche gekennzeichnet, um daran bestimmte Bedingungen zu binden. Die Typen der OE sind im Customizing frei definierbar. 3.2 Rechte - Management Um nun die dezentrale Verwaltung der User in den Units zu ermöglichen, wird eine Rolle (z.b. User- Admin-Unit) definiert, der die erforderlichen Rechte zur Verwaltung der User zugeordnet werden. Im Zuge der Rollendefinition wird dieser Rolle dann eine OE-Kompetenz (im Bild z.b. Sichtweite_ Lokal ) zugeordnet, womit die Wirkung der Rechte auf die User derselben OE des Rolleninhabers beschränkt ist. Damit wird eine Möglichkeit der Parametrisierung der Rolle genutzt, indem die Rolle nur einmal definiert werden muß und durch die Bindung der OE-Kompetenz an die Rolle wird die jeweilige Einschränkung auf die User realisiert. info@secu-sys.de Web: Seite 7 von 8

8 Bei Bedarf kann in die dezentrale Verwaltung der User in der Unit noch eine Freigabefunktion integriert werden, wenn diese Aufgabe nach dem 4-Augen-Prinzip abgesichert werden soll, was u.u. wichtig sein kann, wenn an bestimmten User-Attributen (z.b. der Funktion) automatisch bestimmte Rechte gebunden sind. Diese Verwaltungsrolle wird von der Zentrale an einen Mitarbeiter der Unit vergeben, der damit dann die Möglichkeit hat, seine Unit eigenständig zu verwalten. Dieser Rolle könnten dann weitere Rechte z.b. die Berechtigung der Zuteilung von Fach-Rollen innerhalb der Unit (z.b. Händler, Buchhalter, Schlosser) mit den jeweiligen Rechten auf den Zentralsystemen zugeordnet werden. Eine andere Möglichkeit wäre aber auch, diese Rechte von der Useradmninistration, die evtl. von einer Sekretärin wahrgenommen wird, zu trennen und einer Manager-Rolle zuzuordnen. Diese wiederum kann z.b. innerhalb der Unit beantragt, muß aber von der Zentrale freigegeben werden. Die von bi-cube angebotenen Modellierungsmöglichkeiten decken alle in diesem Zusammenhang sinnvollen Business Cases ab. Abhängig von der Definition der Process Controls an den Rollen können diese direkt zugeordnet oder freigabepflichtig sein. 3.3 Multi Level Struktur Unter Umständen ist die Gebiets-Zentrale, die bi-cube für ihren Bereich aufgesetzt hat, wiederum Unit aus Sicht der Konzern-Zentrale, d.h. die Gebiets-Zentrale nutzt Ressourcen der Konzernzentrale, die dann ihren eigenen Mitarbeitern oder auch Mitarbeitern der Units bereitgestellt werden sollen. Dazu sind diese Anwendungen in bi-cube als Zielsysteme zu modellieren und die User über entsprechende Connectoren entweder automatisch (falls möglich) oder über den halbautomatischen Prozess (Action 7) zu provisionieren. Diese Systeme werden damit aus bi-cube Sicht so behandelt, als ob sie in der Gebiets-Zentrale zur Verfügung stehen. Die Berechtigungen können ganz normal in Rollen berücksichtigt werden. Web: Seite 8 von 8