Identitäts- und Zugriffsverwaltung

Von Frederick Chong

Fredrick Chong erläutert die Konzepte und die Vorteile einer Service Oriented Architecture (SOA - Diensteorientierte Architektur), im Besonderen in Bezug auf die technischen Herausforderungen bei der Identitäts- und Zugriffsverwaltung. Außerdem möchte er dem Leser die allgemeinen Probleme bei der Identitätsverwaltung verdeutlichen. Dieser Artikel enthält auch Links zu englischsprachigen Seiten.

Auf dieser Seite

 Übersicht
 Einführung
 Anatomie einer digitalen Identität
 Grundstruktur der Identitäts- und Zugriffsverwaltung
 Herausforderungen der Identitäts- und Zugriffsverwaltung
 Verwalten von Benutzungsberechtigungen
 Überwachung
 Schlussfolgerung

Übersicht

Heutzutage kennen viele technische Entscheidungsträger in großen IT-Umgebungen die Konzepte und Vorteile der Service Oriented Architecture (SOA). Trotzdem sind bisher sehr wenige IT-Unternehmen in der Lage, die theoretischen Grundlagen von SOA in der IT-Praxis umzusetzen.

Im letzten Jahr versuchten einzelne Softwarearchitekten in meinem Team, die für die Praxis wesentlichen Punkte von SOA in den folgenden Bereichen herauszuarbeiten: Identitäts- und Zugriffsverwaltung, Diensteverwaltung, Entitätsaggregation und Prozessintegration. Einerseits müssen in diesen vier Hauptbereichen bedeutende technische Herausforderungen gelöst werden, andererseits bieten genau sie die IT-Basis, anhand der Unternehmen die Vorteile von SOA erkennen können.

Durch unseren regelmäßigen Austausch mit Softwarearchitekten in den Unternehmen sind wir in der Lage, die praktischen Herausforderungen der SOA in diesen Bereichen zu erkennen, zu analysieren und zu kategorisieren. Unser Team organisiert die Strategic Architect Forums, die weltweit mehrmals im Jahr stattfinden. Bei diesen Veranstaltungen führen wir kleine Diskussionsrunden mit dem Ziel, die Probleme der Kunden zu erkennen und daraus den Bedarf an technischen Anleitungen zu ermitteln. Das Feedback unserer Kunden war sehr eindeutig: Immer wieder wurden Probleme beim Verwalten von Entitäten, Aggregieren von Daten, Verwalten von Diensten und Integrieren von Geschäftsprozessen als die hauptsächlichen Hindernisse bei der Realisierung effizienterer und flexiblerer Unternehmen genannt.

Außerdem führt unser Team zusammen mit Kunden Proof-of-Concept-Projekte durch, um dabei mehr über reale Anforderungen und Implementierungsprobleme zu erfahren. Aus dieser Kombination von allgemeiner und intensiver Zusammenarbeit mit Kunden leiten wir im Architecture Strategy Team unsere Schlussfolgerungen für die vier IT-Hauptbereiche ab, in die investiert werden sollte.

Dieser Artikel bietet in erster Linie eine Übersicht über die technischen Herausforderungen in einem dieser Bereiche, der Identitäts- und Zugriffsverwaltung. Außerdem soll er dem Leser die häufigsten Probleme im Zusammenhang mit diesem umfassenden Thema verdeutlichen.

 

Einführung

Die Identitäts- und Zugriffsverwaltung (I&AM - Identity and Access Management) ist ein relativ neuer Begriff, der von verschiedenen Leuten unterschiedlich interpretiert wird. Häufig haben IT-Spezialisten diesen Begriff unter bestimmten Identitäts- und Sicherheitsproblemen eingeordnet, mit denen sie gerade konfrontiert waren. Beispielsweise wurde I&AM als Synonym für Single Sign-On (SSO - einmalige Anmeldung), Kennwortsynchronisierung, Metaverzeichnis, einmalige Webanmeldung, rollenbasierte Benutzungsberechtigungen und ähnliche Ideen verwendet.

Dieser Artikel soll dem Leser eine kurze, jedoch umfassende Übersicht über die Bedeutung von I&AM geben. Um das zu erreichen, haben wir die Informationen in diesem Artikel so gegliedert, dass sie beim Beantworten der folgenden Fragen helfen:

• Was ist eine digitale Identität?

• Was ist unter Identitäts- und Zugriffsverwaltung zu verstehen?

• Was sind die technischen Hauptkomponenten von I&AM?

• Wie stehen die Komponenten von I&AM miteinander in Beziehung?

• Wo liegen die wesentlichen Architektur-Herausforderungen in I&AM?

 

Anatomie einer digitalen Identität

Heutzutage können Personen auf viele verschiedene Arten identifiziert werden. Beispielsweise über Führerscheine, Reisepässe und Smartcards für Mitarbeiter oder Vereinsmitglieder. Diese Ausweise enthalten normalerweise Informationen, die relativ eindeutig für den Besitzer sind, z. B. Name, Adresse und Foto, sowie Informationen über die ausstellende Stelle, z. B. das Zeichen der lokalen Abteilung eines Autoherstellers.

Während die meisten Menschen das Identitätskonzept in der realen Welt gut verstehen, trifft dies nicht für die Definition von digitalen Identitäten zu. Als Grundlage für den weiteren Artikel wird in diesem Abschnitt unsere Vorstellung von digitalen Identitäten beschrieben (siehe Abbildung 1). Unsere Definition einer digitalen Identität besteht aus den folgenden Teilen:

• Bezeichner Eine bestimmte Information, die die Person dieser Identität im gegebenen Kontext eindeutig identifiziert.₁ Beispiele für Bezeichner sind E-Mail-Adressen, Distinguished Names (X500) und Globally Unique Identifiers (GUIDs).

• Anmeldeinformationen Private oder öffentliche Daten, mit denen die Authentizität einer Identität geprüft werden kann. Beispielsweise muss Anja bei der Anmeldung ihr Kennwort eingeben, und beweist dadurch, dass sie die diesem Konto zugeordnete Benutzerin ist. Dieser Mechanismus funktioniert, da nur das Authentifizierungssystem und Anja das entsprechende Kennwort für Anjas Konto wissen sollten. Ein anderes Beispiel für Anmeldeinformationen sind ein privater Schlüssel und das zugehörige X509-Zertifikat des öffentlichen Schlüssels.

• Hauptattribute Daten, mit denen die Identität beschrieben werden kann. Hauptattribute werden möglicherweise in mehreren Geschäfts- oder Anwendungskontexten verwendet. Beispielsweise sind Adressen und Telefonnummern allgemeine Attribute, die von verschiedenen Geschäftsanwendungen verwendet und referenziert werden.

• Kontextspezifische Attribute Daten, mit denen die Identität beschrieben werden kann, die jedoch ausschließlich im selben Kontext verwendet und referenziert werden, in dem die Identität verwendet wird. Beispielsweise sind in einer Firma die Informationen über die von einem Mitarbeiter gewünschten Krankenkassenleistungen ein kontextspezifisches Attribut, das für die Versicherungs-, jedoch nicht unbedingt für Finanzdienstleister des Unternehmens interessant ist.

Abbildung 1. Anatomie einer digitalen Identität

Was ist Identitäts- und Zugriffsverwaltung?
Die Burton Group definiert Identitätsverwaltung folgendermaßen: "Identitätsverwaltung ist der Satz von Geschäftsprozessen zur Erstellung, Wartung und Verwendung von digitalen Identitäten sowie eine unterstützende Infrastruktur."₂

In diesem Artikel definieren wir Identitäts- und Zugriffsverwaltung (I&AM) folgendermaßen:

"Identitäts- und Zugriffsverwaltung bezieht sich auf die Prozesse, Technologien und Richtlinien zur Verwaltung digitaler Identitäten und die Steuerung des Zugriffs auf Ressourcen mithilfe von Identitäten."

Aus den dargestellten Definitionen können wir folgende wichtige Punkte ableiten:

• I&AM bezieht sich auf die Verwaltung des vollständigen Lebenszyklus₃ digitaler Identitäten. Eine Identitätsverwaltung auf Unternehmensebene sollte nicht aus einzelnen Insellösungen mit verschiedenen Sicherheitstechnologien bestehen, sondern aus einem gut integrierten Geflecht von Technologien, das in jeder Phase des Lebenszyklus einer Identität auf die Besonderheiten der entsprechenden Szenarios eingeht. Diese Szenarios werden in einem späteren Abschnitt dieses Artikels näher erläutert.

• I&AM umfasst keineswegs nur Technologie, sondern besteht aus drei unentbehrlichen Elementen: Richtlinien, Prozesse und Technologien. Richtlinien beziehen sich auf die Einschränkungen und Standards, die befolgt werden müssen, um Vorschriften zu erfüllen und optimale Geschäftsmethoden zu befolgen; Prozesse beschreiben die Schrittfolgen, die zum Abschließen von Geschäftsaufgaben oder -funktionen führen; Technologien sind die automatisierten Tools, die dabei helfen, Geschäftsziele unter Berücksichtigung der Einschränkungen und Anweisungen der Richtlinien effizienter und präziser zu verwirklichen.

• Die Beziehung zwischen diesen Elementen von I&AM kann als das Dreieck in Abbildung 2 dargestellt werden. Hierbei ist hervorzuheben, dass alle drei Elemente voneinander abhängig sind. In einem bestimmten I&AM-System stellen die Kantenlängen die relativen Proportionen der Elemente zueinander dar. Eine Änderung der Proportionen eines Elements hat zwangsläufig eine Änderung mindestens eines weiteren Elements zur Folge, damit das Dreieck weiterhin einen Fokuspunkt hat (im Dreieck als Schnittpunkt dargestellt).

• Die Dreiecksanalogie ist ebenfalls sehr gut geeignet, um die Beziehungen und Interaktionen zwischen Richtlinien, Prozessen und Technologien in einem funktionierenden I&AM-System zu beschreiben. Jedes Unternehmen ist anders, und die für ein Unternehmen richtige Mischung von Technologien, Richtlinien und Prozessen ist für ein anderes Unternehmen möglicherweise nicht unbedingt ausgewogen. Deshalb muss für jedes Unternehmen die eigene Balance herausgefunden werden, die sich durch die Eindeutigkeit seines Dreiecks darstellt.

• Das I&AM-System eines Unternehmens bleibt im Laufe der Zeit nicht statisch. Neue Technologien werden eingeführt und übernommen, neue Geschäftsmodelle und Einschränkungen sorgen dafür, dass die Firmenleitung aktiv werden muss. Wie bereits erwähnt, muss eine neue Balance gefunden werden, wenn sich eines der Elemente ändert. Deshalb müssen Sie sich bewusst machen, dass I&AM der Weg ist, nicht das Ziel.

Abbildung 2. Grundlegende Elemente eines Systems zur Identitäts- und Zugriffsverwaltung

 

Grundstruktur der Identitäts- und Zugriffsverwaltung

Wie in den vorherigen Abschnitten erwähnt, ist die Identitäts- und Zugriffsverwaltung ein sehr umfangreiches Thema, das technische und nicht technische Bereiche umfasst. Im weiteren Verlauf des Artikels werden die technischen Aspekte der Identitäts- und Zugriffsverwaltung erläutert.

Auch wenn wir uns auf den (immer noch sehr umfassenden) technischen Bereich dieses Themas beschränken, ist es nützlich, für die weitere Diskussion eine gewisse Struktur einzuhalten. Zur Besprechung dieses Themas verwenden wir die Grundstruktur in Abbildung 3, in der mehrere logische Hauptkomponenten von I&AM gezeigt werden.

In dieser Grundstruktur werden drei Hauptgruppen technologischer Komponenten hervorgehoben:

• Identitäts-Lebenszyklus-Verwaltung

• Zugriffsverwaltung

• Verzeichnisdienste

Die Komponenten dieser Technologiegruppen werden verwendet, um bestimmte wiederkehrende Anforderungen an Lösungen zur Identitätsverwaltung zu erfüllen. In den folgenden Abschnitten beschreiben wir die Rollen, die diese Komponenten spielen.

Verzeichnisdienste
Wie bereits erwähnt, besteht eine digitale Identität aus einigen logischen Typen von Daten: Bezeichnern, Anmeldeinformationen und Attributen. Diese Daten müssen sicher gespeichert und organisiert werden. Verzeichnisdienste stellen die Infrastruktur zur Erfüllung dieser Anforderungen bereit. Oft werden der Zugriff und die Verwendung von Geschäftsanwendungen sowie die IT-Infrastruktur eines Unternehmens mit Benutzungsberechtigungen und Sicherheitsrichtlinien gesteuert. Benutzungsberechtigungen sind die Rechte und Privilegien, die mit einem Benutzer oder einer Gruppe verknüpft sind. Sicherheitsrichtlinien beziehen sich auf die Standards und Einschränkungen, unter denen IT-Ressourcen betrieben werden.

Eine Richtlinie über die Kennwortkomplexität ist ein Beispiel für eine Sicherheitsrichtlinie. Ein anderes Beispiel ist die Vertrauenskonfiguration für eine Geschäftsanwendung, die z. B. den vertrauenswürdigen Fremdanbieter beschreibt, auf den sich die Anwendung bei der Authentifizierung und Identifizierung der Benutzer der Anwendung verlässt. Benutzungsberechtigungen und Sicherheitsrichtlinien müssen ebenso wie digitale Identitäten gespeichert, ordnungsgemäß verwaltet und ermittelt werden. Meistens bieten Verzeichnisdienste eine gute Grundlage für die Erfüllung dieser Anforderungen.

Zugriffsverwaltung
Zugriffsverwaltung bezieht sich auf den Prozess der Zugriffssteuerung und -gewährung zur Erfüllung von Ressourcenanforderungen. Dieser Prozess wird normalerweise durch eine Folge von Authentifizierungs-, Autorisierungs- und Überwachungsaktionen durchgeführt. Authentifizierung ist der Prozess, in dem Identitätsansprüche überprüft werden. Autorisierung ist die Festlegung, ob einer Identität gestattet wird, eine Aktion durchzuführen oder auf eine Ressource zuzugreifen. Bei der Überwachung wird ein Rechenschaftsbericht erstellt, in dem die eingetretenen Sicherheitsereignisse aufgezeichnet werden. Zusammen sind Authentifizierung, Autorisierung und Überwachung auch als die "goldenen Sicherheitsstandards" bekannt. (Da diese Begriffe im Englischen alle mit dem chemischen Symbol für Gold (Au) beginnen: Authentication, Authorization und Auditing.)

Es gibt verschiedene technische Probleme, auf die Softwarearchitekten möglicherweise treffen, wenn sie Authentifizierungs-, Autorisierungs- und Überwachungsmechanismen entwerfen und in die Anwendungsarchitektur integrieren:

• Einmalige Anmeldung (SSO)

• Vertrauenswürdigkeit und Föderation

• Benutzungsberechtigungen

• Überwachung

Diese Herausforderungen und ihre Lösungen beschreiben wir später in diesem Dokument ausführlicher.

Abbildung 3. Logische Komponenten von I&AM

Identitätslebenszyklusverwaltung
Der Lebenszyklus einer digitalen Identität kann in ähnliche Phasen eingeteilt werden wie die Lebenszyklen von Alltagsgegenständen:

• Erstellung

• Verwendung

• Vernichtung

In jeder Phase des Lebenszyklus einer Identität gibt es typische Szenarios, die sich für eine automatisierte Verwaltung anbieten. Beispielsweise müssen bei der Erstellung einer digitalen Identität die Identitätsdaten an die Identitätssysteme weitergegeben und initialisiert werden. In anderen Szenarios müssen die Benutzungsberechtigungen einer Identität möglicherweise erweitert werden, wenn der von der Identität dargestellte Benutzer befördert wird.

Wenn die digitale Identität letztendlich nicht mehr aktiv verwendet wird, sollte ihr Status geändert oder die Identität aus dem Datenspeicher gelöscht werden.

Alle Ereignisse im Lebenszyklus einer digitalen Identität müssen sicher, effizient und korrekt verwaltet werden, und genau darum geht es bei der Identitätslebenszyklusverwaltung.

Abbildung 4. Ebenen von Anforderungen an die Identitätslebenszyklusverwaltung

Die Anforderungen an eine Identitätslebenszyklusverwaltung können auf verschiedenen Ebenen diskutiert werden (siehe Abbildung 4). Auf der Ebene der Identitätsdaten finden Sie die Typen der zu verwaltenden Daten. Auf Grundlage unserer vorherigen Definition einer digitalen Identität umfassen die relevanten Daten Anmeldeinformationen (wie Kennwörter und Zertifikate) und Benutzerattribute (wie Name, Adresse und Telefonnummern). Neben Anmeldeinformationen und Attributen sind ebenfalls Daten für Benutzungsberechtigungen zu verwalten. Diese Benutzungsberechtigungen werden später ausführlicher beschrieben, zuerst einmal betrachten wir Benutzungsberechtigungen vereinfacht als die einer Identität zugewiesenen Rechte und Privilegien.

Die in der nächsthöheren Ebene der Darstellung aufgelisteten Anforderungen geben die Arten von Operationen wieder, die auf Identitätsdaten durchgeführt werden können. Create, Read, Update und Delete (CRUD - Erstellen, Lesen, Aktualisieren und Löschen) sind Datengrundoperationen, die aus dem Datenbankbereich übernommen wurden. Wir verwenden hier diese Grundoperationen, da sie auf sehr praktische Weise eine Klassifizierung der Arten von Identitätsverwaltungsoperationen ermöglichen. Beispielsweise können wir Änderungen am Kontostatus, an Benutzungsberechtigungen und an Anmeldeinformationen unter der Datengrundoperation "Aktualisieren" zusammenfassen.

Die nächste Ebene der Darstellung enthält zwei Identitätslebenszyklus-Administrationsmodelle: Benutzerverantwortung und Delegierung. In traditionellen IT-Unternehmen wird die Administration der Computer von einer zentralisierten Gruppe von Systemadministratoren durchgeführt. Im Laufe der Zeit wurde in den Unternehmen erkannt, dass es möglicherweise gute ökonomische und organisatorische Gründe gibt, auch andere Administrationsmodelle zu verwenden. Beispielsweise ist es oft effektiver und effizienter, wenn die Mitarbeiter selbst in der Lage sind, einige ihrer persönlichen Daten zu aktualisieren, z. B. Attribute wie Adresse und Telefonnummern. Im benutzerverantwortlichen Administrationsmodell sind solche individuellen Bearbeitungen möglich. Der Mittelweg zwischen dem benutzerverantwortlichen und dem zentralisierten Administrationsmodell ist die delegierte Administration. Im delegierten Modell wird die Verantwortlichkeit der Identitätslebenszyklusadministration auf dezentralisierte Administratorgruppen aufgeteilt. Die häufigsten Kriterien, nach denen der Umfang der Delegierung festgelegt wird, sind Organisationsstruktur und Administratorrollen. Ein Beispiel für die delegierte Administration auf Grundlage der Organisationsstruktur ist die Hierarchie der Administratoren auf Unternehmens-, Bereichs- und Abteilungsebene in einem großen Unternehmen.

Mit den obigen Lebenszyklus-Administrationsmodellen können eine Vielzahl von Geschäftsszenarios unterstützt werden (siehe Abbildung 4). Beispielsweise müssen für neue Mitarbeiter oft Konten erstellt und bereitgestellt werden. Im Gegensatz dazu muss der aktuelle Status des Kontos möglicherweise geändert werden, wenn ein Mitarbeiter nicht länger beschäftigt wird. Außerdem können Arbeitsplatzwechselszenarios verschiedene Auswirkungen auf digitale Identitäten haben. Wenn ein Mitarbeiter beispielsweise befördert wird, müssen möglicherweise Titel geändert und Benutzungsberechtigungen erweitert werden. Nun, da wir die Anforderungen an die Identitätslebenszyklusverwaltung besser verstehen, sind wir in der Lage, uns mit den Herausforderungen zu beschäftigen, die in diesem Zusammenhang auftreten können.

Abbildung 5. Aktueller Stand: Unternehmen mit mehreren Identitätssystemen

Die Darstellung in Abbildung 5 bezieht sich auf die Tatsache, dass ein typischer Benutzer in einem Unternehmen normalerweise mit mehreren digitalen Identitäten umgehen muss, die möglicherweise unabhängig voneinander gespeichert und verwaltet werden. Dieser aktuelle Stand ist Teil der fortlaufenden Entwicklung, die jede Geschäftsorganisation durchläuft. Ereignisse wie Fusionen und Übernahmen können inkompatible Systeme in die vorhandene IT-Infrastruktur einführen, und sich entwickelnde Geschäftsanforderungen können durch Anwendungen von Fremdanbietern erfüllt werden, die jedoch nicht gut in die vorhandenen Anwendungen integriert sind.

Man könnte annehmen, dass es für Unternehmen viel einfacher wäre, die vorhandenen Systeme abzuschaffen und ein völlig neues System aufzubauen. Jedoch ist dieser Weg selten eine praktikable Lösung. Wir müssen bedenken, dass vorhandene Identitätssysteme möglicherweise schon lange im Einsatz sind. Deshalb müssen wir andere Lösungen finden, um die beiden Hauptprobleme zu lösen, die aus der Verwaltung von Daten mit verschiedenen Identitätssystemen entstehen:

1. Duplizierung von Informationen: Identitätsinformationen sind oft auf mehreren Systemen dupliziert vorhanden. Beispielsweise werden Attribute wie Adressen und Telefonnummern oft in mehreren Systemen einer Umgebung gespeichert und verwaltet. Bei duplizierten Identitätsdaten kann es leicht vorkommen, dass die Daten nicht mehr übereinstimmen, wenn Aktualisierungen auf einem System vorgenommen werden, jedoch nicht auf den anderen.

2. Mangel an Integration: Die Gesamtheit der Attribute, Anmeldeinformationen und Privilegien eines bestimmten Benutzers ist oft über mehrere Identitätssysteme verteilt. Beispielsweise können für einen bestimmten Mitarbeiter die Personalinformationen in einem SAP-HR-System, das Netzwerkzugriffskonto in einem Active Directory und die Berechtigungen für Legacy-Anwendungen auf einem Mainframe gespeichert sein. In vielen Szenarios der Identitätslebenszyklus-Verwaltung ist es erforderlich, dass Identitätsinformationen von verschiedenen unterschiedlichen Systemen abgerufen und an ebensolche verteilt werden müssen. Wir fassen die oben genannten Probleme unter dem Begriff "Identitätsaggregationsherausforderung" zusammen, der in einem späteren Abschnitt ausführlicher erläutert wird.

 

Herausforderungen der Identitäts- und Zugriffsverwaltung

Einmalige Anmeldung (SSO) Ein typischer Benutzer in einem Unternehmen muss sich mehrfach anmelden, um auf die verschiedenen, für die Arbeit notwendigen Geschäftsanwendungen zuzugreifen. Aus Sicht des Benutzers sind mehrfache Anmeldungen und die Notwendigkeit, sich mehrere Kennwörter zu merken, eines der Hauptärgernisse im Umgang mit den Anwendungen. Aus Sicht der Verwaltung erhöhen vergessene Kennwörter zuerst einmal die Verwaltungskosten, und in Kombination mit schlechten Angewohnheiten, die Benutzer im Umgang mit Kennwörtern haben (z. B. sich diese auf Notizzettelchen am Monitor zu "merken") sind Sicherheitsverletzungen leichter möglich. Aufgrund der offensichtlich unlösbaren Probleme, die durch mehrere Identitäten entstehen, wurde das Konzept der einmaligen Anmeldung (SSO), also die Möglichkeit, sich nur einmal anzumelden und damit Zugriff auf mehrere Systeme zu erhalten, in Identitätsverwaltungsprojekten so etwas wie der "Heilige Gral".

Lösungen mit einmaliger Anmeldung
Im Großen und Ganzen gibt es fünf Klassen von SSO-Lösungen. Dabei ist keine Lösung für alle Anwendungsszenarios geeignet. Die richtige Lösung ist unter anderem von folgenden Faktoren abhängig: Wo sind die Anwendungen installiert, für die SSO erforderlich ist? Welche Einschränkungen entstehen durch die Infrastruktur (z. B. Beschränkungen durch die Firewall)? Besteht die Möglichkeit, die Anwendungen zu ändern? Hier die fünf Kategorien von SSO-Lösungen:

1. Web-SSO

2. Im Betriebssystem integrierte Anmeldung

3. Föderierte Anmeldung

4. Zuordnung von Identitäten und Anmeldeinformationen

5. Kennwortsynchronisierung

Web-SSO-Lösungen sind für Anmeldungen an Webanwendungen konzipiert. Bei diesen Lösungen werden nicht authentifizierte Benutzer eines Browsers zum Eingeben der Anmeldeinformationen auf Anmeldewebsites umgeleitet. Nach der erfolgreichen Authentifizierung werden HTTP-Cookies ausgegeben, mit denen Webanwendungen authentifizierte Benutzersitzungen überprüfen können. Microsoft Passport ist ein Beispiel für eine Web-SSO-Lösung.

Im Betriebssystem integrierte Anmeldung bezieht sich auf Authentifizierungsmodule und -Schnittstellen, die Teile des Betriebssystems sind. Das Windows-Sicherheitssubsystem stellt solche Funktionen durch Systemmodule wie Local Security Authority (LSA - Lokale Sicherheitsautorität) und Security Specific Providers (SSP - Sicherheitsspezifische Anbieter) zur Verfügung. SSPI bezeichnet die Programmierschnittstellen für die SSPs. Desktopanwendungen, die zur Benutzerauthentifizierung die SSPI-APIs verwenden, können dann die Windows-Desktopanmeldung übernehmen, um Anwendungen mit einmaliger Anmeldung zu realisieren. In verschiedenen UNIX-Implementierungen bietet die GSSAPI diese SSO-Funktionalität.

Für die föderierte Anmeldung ist es erforderlich, dass die Authentifizierungsinfrastrukturen der Anwendung Vertrauensbeziehungen verstehen und über Standardprotokolle kommunizieren können. Kerberos und der zukünftige Active Directory-Föderationsdienst sind Beispiele für Föderationstechnologien. Föderierte Anmeldung bedeutet, dass die Authentifizierungsverantwortung an einen vertrauenswürdigen Anbieter delegiert wird. Anwendungsbenutzer müssen sich nicht erneut anmelden, solange der Benutzer von einer föderierten (z. B. einer vertrauenswürdigen) Authentifizierungsinfrastrukturkomponente authentifiziert wurde.

Lösungen mit einer Zuordnung von Identitäten und Anmeldeinformationen verwenden normalerweise Anmeldeinformationscaches, um die Identitäten und Anmeldeinformationen zu verwalten, die für den Zugriff auf entsprechende Listen von Anwendungssites verwendet werden. Der Cache kann bei einer Änderung der Anmeldeinformationen (z. B. des Kennworts) manuell oder automatisch aktualisiert werden. Vorhandene Anwendungen müssen für Identitätszuordnungslösungen eventuell angepasst werden. Wenn es nicht möglich ist, eine Anwendung anzupassen, kann möglicherweise ein Softwareagent installiert werden, um die Anmeldeereignisse der Anwendung zu überwachen. Wenn der Agent ein Anmeldeereignis registriert, findet er die Benutzeranmeldeinformationen im Cache und gibt diese automatisch in der Anmeldeaufforderung der Anwendung ein.

Die Kennwortsynchronisierung wird verwendet, um Kennwörter in den Datenbanken mit den Anmeldeinformationen der Anwendungen zu synchronisieren, so dass Benutzer und Anwendungen Kennwörter nicht mehrfach ändern müssen. Kennwortsynchronisierung ist als Silotechnologie und nicht wirklich für einmalige Anmeldung konzipiert, ermöglicht jedoch einige praktische Funktionen, auf die Anwendungen zurückgreifen können. Beispielsweise kann eine Anwendung der mittleren Ebene mit Kennwortsynchronisierung davon ausgehen, dass das Kennwort eines Anwendungsbenutzers auf den verschiedenen Systemen, auf die sie zugreifen muss, dasselbe ist, so dass die Anwendung für den Zugriff auf Ressourcen auf diesen Systemen nicht verschiedene Kennwörter abrufen muss.

 

Verwalten von Benutzungsberechtigungen

Verwalten von Benutzungsberechtigungen bezieht sich auf den Satz von Technologien, mit denen Identitäten Zugriffsrechte gewährt und diese widerrufen werden. Dies wird oft mit Autorisierung assoziiert, dem tatsächlichen Vorgang zur Erzwingung der Zugriffsregeln, Richtlinien und Einschränkungen, die mit Geschäftsfunktionen und -daten im Zusammenhang stehen.

Aktuelle Unternehmensanwendungen verwenden oft eine Kombination aus rollenbasierter Autorisierung und geschäftsregelbasierten Richtlinien, um festzulegen, über welche Rechte eine bestimmte Identität verfügt.

In einer verteilten N-Tier-Anwendung können Zugriffsentscheidungen auf jeder Schicht der Anwendungsarchitektur getroffen werden. Beispielsweise könnten auf der Darstellungsebene nur die Befehle angezeigt werden, für die der Benutzer autorisiert ist. Auf der Dienstebene der Architektur könnte der Dienst überprüfen, ob der Benutzer die Autorisierungsbedingungen zum Aufrufen des Dienstes erfüllt. Beispielsweise können nur Benutzer in der Rolle Manager den Dienst "Kreditzusage" aufrufen. Hinter den Kulissen auf Geschäftslogikebene müssen möglicherweise Detailentscheidungen bezüglich der Geschäftsrichtlinien getroffen werden (z. B. "Findet diese Anforderung während der Geschäftszeiten statt?"), und auf der Datenebene müssen die gespeicherten Prozeduren der Datenbank die zurückgegeben Daten möglicherweise auf Grundlage der Beziehung zwischen der den Dienst aufrufenden Identität und den angeforderten Daten filtern.

In Anbetracht des Nutzens und der sich oft überschneidenden Verwendung von rollen- und regelbasierten Autorisierungsschemas, ist es für Anwendungsarchitekten nicht immer klar, wie sie ein Framework zur Verwaltung von Benutzungsberechtigungen modellieren können, in dem beide Schemas sauber integriert sind. In vielen Unternehmen wird das mit getrennten benutzerdefinierten Modulen gelöst.

Abbildung 6. Integration von rollen- und regelbasierter Autorisierung zur Darstellung einer Möglichkeit, wie beide Schemas kombiniert und integriert werden können.

In dieser Darstellung gehen wir von einer Rollendefinition (die normalerweise eine Verantwortlichkeit widerspiegelt) mit zwei Eigenschaftssätzen aus. Ein Eigenschaftssatz umfasst die Identitäten von Mitarbeitern oder Systemen, die diese bestimmte Rolle übernehmen. Beispielsweise werden Anja, Bernd und Karl der Rolle Manager zugewiesen. Der zweite Eigenschaftssatz umfasst die Rechte, über die eine bestimmte Rolle verfügt. Rechte können Geschäftsfunktionen oder Aktionen auf Computerressourcen darstellen. Beispielsweise definiert Betrag übertragen eine Geschäftsfunktion und Datei lesen bezieht sich auf eine Operation auf einer Computerressource. Außerdem können wir jedem Recht einen Satz von Bedingungen (Geschäftsregeln) zuweisen. Beispielsweise könnte dem Recht Betrag übertragen eine Bedingung zugeordnet sein, die Aktion nur zu gestatten, wenn die aktuelle Uhrzeit innerhalb der Geschäftszeiten liegt. Beachten Sie, dass die Bedingung abhängig von dynamischen Eingabedaten sein kann, die nur zur Laufzeit der Anwendung bestimmt werden können.

Außerdem ist es in den meisten Unternehmen wichtig, eine konsolidierte Übersicht über alle Rechte zu haben, über die eine bestimmte Identität verfügt. Um diese Anforderung zu erfüllen, verwenden Anwendungen zur Verwaltung von Benutzungsberechtigungen normalerweise einen zentralisierten Richtlinienspeicher, um eine zentralisierte Verwaltung und Anzeige der Rechte der Benutzer zu erleichtern.

Identitätsaggregation
Die IT-Systeme in Unternehmen wachsen im Laufe der Zeit gemeinsam mit dem Unternehmen. Gründe hierfür können Fusionen und Übernahmen sein oder die Vorlieben und Änderungen der jeweiligen IT-Verantwortlichen. Daraus ergibt sich oft ein Wirrwarr aus nicht verbundenen IT-Systemen, die unerwünschte architektonische Artefakte enthalten. Auch identitätsbezogene Systeme sind Teile solcher gewachsener IT-Strukturen.

Oft verfügen Unternehmen nicht nur über ein Identitätssystem, sondern über mehrere, und jedes dient anderen Geschäftsfunktionen und speichert duplizierte und in Beziehung stehende Daten. Anwendungen, die solche Geschäftsfunktionen integrieren müssen, sind dann gezwungen, die Unterschiede in Einklang zu bringen und die Duplikate zu synchronisieren.

Beispielsweise könnte eine Anwendung für einen Bankkundendienst Kundeninformationen aus einer DB2-Datenbank, einer Oracle-basierten Autorisierungsdatenbank und einem selbst erstellten CRM-System abrufen müssen. In diesem Fall wird für die Anwendung der Begriff "Kunde" von drei verschiedenen Systemen definiert. Attribute, die einen Kunden beschreiben, z. B. Kundenname, Adresse und Sozialversicherungsnummer, sind dabei möglicherweise in mehreren Systemen gespeichert und dupliziert. Andererseits könnten nicht duplizierte Daten wie vom Kunden erworbene Finanzprodukte und der Kontostand des Kunden möglicherweise in getrennten Systemen gespeichert sein. Die Anwendung muss diese Daten aus unterschiedlichen Systemen beziehen, um die erforderliche Übersicht über den Kunden zu erhalten.

Dieses Problem kann scheinbar gelöst werden, indem die zugrunde liegenden Identitätsdaten in ein riesiges Identitätssystem verschoben werden. Jedoch sind dabei viele Hindernisse zu beachten (z. B. das Risiko, dass ältere Anwendungen nicht mehr funktionieren), die verhindern, dass eine solche Lösung jederzeit schnell übernommen werden kann. Unter Identitätsaggregation verstehen wir also die Technologien, die Anwendungen dabei unterstützen, Identitätsinformationen aus verschiedenen Identitätssystemen zusammenzusetzen und dabei die Komplexität des Datenabgleichs, der Datensynchronisierung und der Datenintegration zu vermindern.

Es gibt mehrere technische Herausforderungen, denen sich Technologien zur Identitätsaggregation stellen sollten:

• Aufrechterhaltung von Beziehungen bei Datentransformationen

• Optimierung von CRUD-Datenoperationen

• Synchronisierung von Daten

Die nächsten Unterabschnitte enthalten einen Überblick über diese Entwurfsaspekte.

(a) Aufrechterhaltung von Beziehungen bei Datentransformationen
Eine Lösung zur Identitätsaggregation kann Anwendungen mit unterschiedlichen Sichten der Identitätsinformationen, die Daten in verschiedenen Systemen ändern, mehrere Vorteile bieten. Der erste Vorteil betrifft den Umstand, dass Anwendungen eine konsolidierte oder eine aggregierte Sicht der Daten aus den einzelnen Systemen erhalten. Um Daten umzuformen und in verschiedenen Sichten darzustellen, muss die Lösung zur Identitätsaggregation Metadaten pflegen, die das Schema beschreiben, das die konsolidierte Sicht und seine Beziehungen zu den Datenschemas der einzelnen Identitätssysteme darstellt.

Sehen wir uns ein spezielles Beispiel für eine Anwendung zur Verwaltung von Identitätslebenszyklen an, die Daten in einigen vorhandenen Systemen verwaltet. Die konsolidierte Ansicht der Verwaltungsanwendung wird in einem neuen Schema dargestellt, das aus neuen und vorhandenen Identitätsattributen besteht.

Abbildung 7. Identitätsschemas in Einklang bringen

Im Beispiel in Abbildung 7 wird für die Anwendung ein neues Identitätsschema definiert. Das neue Schema verweist auf Attribute aus zwei vorhandenen Identitätsschemas und definiert neue, bisher nicht spezifizierte Attribute (Kontonummer, Telefon - Mobil und Einstellungen).

Damit Anwendungen die Daten in den vorhandenen Speichern abfragen und aktualisieren können, müssen wir zwischen den in dem neuen Schema definierten Attributen und den entsprechenden Attributen in den vorhandenen Schemas Beziehungen einrichten. Beispielsweise sind die folgenden Beziehungen einzurichten:

• Referenz Eine Referenz ist eine Information, die eine Dateninstanz eines bestimmten Datenschemas eindeutig identifiziert. Beispielsweise ermöglicht das Attribut Kunden-ID für eine Dateninstanz des Anwendungsschemas in Abbildung 7 die entsprechende Dateninstanz aus dem vorhandenen Schema 1 zu finden. Unterschiedliche Schemas identifizieren ihre eigenen Dateninstanzen möglicherweise anhand verschiedener Referenzen

• Besitz Ein Datenattribut kann in mehreren vorhandenen Schemas definiert sein. Bleiben wir bei dem Beispiel aus Abbildung 7: Die Attribute Name und Adresse sind in beiden vorhandenen Schemas definiert. Im Falle eines Datenkonflikts muss die Anwendung wissen, welche der beiden Versionen die zu übernehmende, maßgebliche Kopie der Daten enthält. Außerdem kann es Szenarios geben, in denen ein Attribut seinen Wert über eine priorisierte Besitzerliste erhält. In diesen Szenarios sollte der Aggregationsdienst das nächste System in der priorisierten Besitzerliste abfragen, wenn der Wert für ein Attribut nicht in der ersten maßgeblichen Quelle vorhanden ist.

• Attributzuordnung Attribute, die in mehreren Datenspeichern definiert sind, haben möglicherweise dieselbe semantische Bedeutung, können jedoch unterschiedliche syntaktische Darstellungen haben. Zum Abfragen oder Aktualisieren eines Datenattributs muss dem Dienst zur Identitätsaggregation bekannt sein, welche Attribute semantisch gleichbedeutend sind. Wenn beispielsweise die Kundennummer in allen drei Schemas definiert, in Identitätsschema 2 jedoch anders benannt ist (KundID) und die Anwendung eine Aktualisierung für die Kundennummer einer Identität durchführt, muss dem System bekannt sein, dass auch das Attribut KundID der Dateninstanz aus Schema 2 zu aktualisieren ist.

(b) Optimierung von CRUD-Datenoperationen
Wie bereits oben erwähnt, ist "CRUD" ein Akronym aus dem Datenbankbereich und steht für Create, Read, Update und Delete (Erstellen, Lesen, Aktualisieren und Löschen). CRUD definiert die Basisoperationen zum Ändern von Daten. CRUD gilt als technische Herausforderung, da die Leistung bei der Durchführung aggregationsbezogener Aktivitäten, die CRUD-Operationen auf mehreren Back-End-Datensystemen ausführen müssen, in Abhängigkeit von den Datenbeziehungen beträchtlich variieren kann.

Im besten Fall können die CRUD-Operationen parallel ausgeführt werden. Dies trifft auf die meisten Situationen zu, in denen die Dateninstanzen mit derselben Referenz aufgelöst werden können und eine Datenreferenz immer auf eine eindeutige Instanz verweist. Wenn beispielsweise die Sozialversicherungsnummer der einzige Schlüssel ist, mit dem Daten aus allen Datenspeichern abgefragt und aggregiert werden, kann diese Abfrage parallel ausgeführt werden.

Im schlechtesten Fall müssen die CRUD-Operationen in den Datenspeichern nacheinander ausgeführt werden. In Situationen, in denen die Referenzen zum Auflösen der Dateninstanzen von anderen Dateninstanzen abhängig sind, muss im Allgemeinen seriell vorgegangen werden. Gehen wir als einfaches Beispiel einmal davon aus, dass wir Daten aus der HR- und der Leistungen-Datenbank aggregieren müssen und die Instanzreferenzen die Mitarbeiternummer und die Sozialversicherungsnummer sind. Wenn uns anfangs als Schlüssel nur die Mitarbeiternummer bekannt ist und die Sozialversicherungsnummer nur aus der HR-Datenbank abgefragt werden kann, müssen wir die Abfrage in der folgenden Reihenfolge seriell durchführen:

• Die HR-Datenbank mit der Mitarbeiternummer als Schlüssel abfragen

• Aus den Ergebnissen dieser Abfrage die Sozialversicherungsnummer extrahieren

• Die Leistungen-Datenbank abfragen

• Die Ergebnisse der Abfragen aggregieren

Replikation ist eine verbreitete Technik, um auf Leistungsverluste zu reagieren, die aufgrund von CRUD-Operationen über mehrere Datenspeicher auftreten. Um dieses Leistungsproblem zu lösen, kann möglicherweise ein Teil der Back-End-Datenattribute mit einem Speicher repliziert werden, der vom Identitätsaggregationsdienst verwaltet wird. Zusätzlich kann die lokale Kopie der replizierten Daten weiter denormalisiert werden, um die CRUD-Leistung zu steigern.

(c) Synchronisierung von Daten
Datensynchronisierung ist in Situationen erforderlich, in denen mindestens eine der beiden folgenden Bedingungen zutrifft:

• In mehreren Back-End-Speichern sind duplizierte Identitätsattribute vorhanden

• Daten werden in einen Identitätsaggregator-Zwischenspeicher repliziert

Jedoch kann die Datensynchronisierung möglicherweise auch weitere Entwurfsprobleme zur Folge haben:

• Auflösung von Datenkonflikten: In Situationen, in denen die Daten aus mehreren Quellen aktualisiert werden können, kann es leicht zu Datenkonflikten kommen. Es gibt unter anderem die folgenden Praktiken, um diese Situationen zu verbessern:

  • Besitzerpriorisierung von Daten, so dass im Falle von Konflikten die maßgebliche Autorität verwendet wird

  • Im Falle eines Konflikts "gewinnt" der letzte Schreibzugriff

  • Synchronisierungstrigger: Zwei allgemeine Ansätze sind zeitplangesteuerte und auf Ereignisbenachrichtigungen basierende Aktualisierungen.

Vertrauenswürdigkeit und Föderation
Wie bereits im Abschnitt über einmalige Anmeldung erwähnt, ermöglicht Föderation die einmalige Anmeldung. Jedoch ist Föderation mehr als nur eine SSO-Lösung. Föderation schließt die Delegierung von Verantwortlichkeiten ein. Dies wird mit Vertrauensbeziehungen zwischen föderierten Parteien realisiert. Authentifizierung ist nur eine Form der delegierten Verantwortlichkeit. Autorisierung, Profilverwaltung, Pseudonymdienste und Rechnungswesen sind andere Formen von identitätsbezogenen Funktionen, die möglicherweise an vertrauenswürdige Fremdanbieter delegiert werden können.

Es gibt drei Technologieelemente, die für das Konzept der Föderation grundlegend sind:

• Ein Föderationsprotokoll, das die Kommunikation zwischen den Parteien ermöglicht

• Eine flexible Vertrauensinfrastruktur, die eine Vielzahl von Vertrauensmodellen unterstützt

• Ein erweiterbares Framework zur Richtlinienverwaltung, das die unterschiedlichen Unternehmensanforderungen unterstützt

Föderationsprotokolle sind die "Sprachen", mit deren Hilfe die Föderationsparteien miteinander kommunizieren. Da Föderation impliziert, dass eine Verantwortlichkeit an eine andere Partei delegiert und von dieser durchgeführt wird, muss das Protokoll Einzelpersonen gestatten, bestimmte "Fähigkeiten" zu erlangen: im Wesentlichen die Fähigkeit, fälschungssicher zu überprüfen, ob eine bestimmte Identität einen Vorgang erfolgreich abgeschlossen hat oder über bestimmte Privilegien verfügt. Beispielsweise verfügt eine authentifizierte Identität bei der föderierten Anmeldung über die Fähigkeit, zu überprüfen, ob sich die Person erfolgreich mit einem zugelassenen Authentifizierungsdienst authentifiziert hat.

In einer komplexen Geschäftswelt können verhältnismäßig komplexe Vertrauensschemas mit mehreren Geschäftspartnern erforderlich sein. Föderationstechnologie muss in der Lage sein, das Wesentliche der Vertrauensbeziehungen der realen Welt in einfach zu verstehenden, jedoch leistungsstarken Vertrauensmodellen zu erfassen, die dabei helfen, verschiedene Geschäftsszenarios zu ermöglichen. Es folgen einige allgemeine Vertrauensmodelle (siehe Abbildung 8):

• Hub-and-Spoke

• Hierarchisch

• Peer-to-Peer-Vertrauensnetz

Abbildung 8. Allgemeine Vertrauensmodelle

Das Hub-and-Spoke-Modell ist am einfachsten zu verstehen. In diesem Modell gibt es einen zentralen Vermittler, der für alle föderierten Parteien direkt vertrauenswürdig ist. Die Europäische Union ist ein Beispiel dieses Föderationsmodells: Die EU-Mitgliedsstaaten vertrauen dem EU-Verbund direkt, allgemeine ökonomische Richtlinien vorzugeben und den Handel mit den föderierten Parteien zu fördern.

Im hierarchischen Modell stehen zwei Parteien in einer indirekten Vertrauensbeziehung, wenn für beide in der Hierarchiestruktur jeweils eine Vertrauenskette zu einer gemeinsamen Stammautorität vorhanden ist. Das politische System der USA ist ein Beispiel für dieses Vertrauensmodell. In diesem politischen System gibt es auf den verschiedenen Ebenen der Hierarchie politische Verbünde auf föderaler, staatlicher, regionaler und lokaler Ebene.

Das Peer-to-Peer-Modell stellt eine Sammlung von direkten Ad-hoc-Vertauensbeziehungen dar. Ein gutes Beispiel für dieses Vertrauensmodell sind persönliche Beziehungen zwischen Freunden in der realen Welt. Beachten Sie, dass es auch möglich ist, vorhandene Föderationsnetzwerke zu erweitern oder neue zu formen, die aus verschiedenen Vertrauensmodellen bestehen oder hybride Modelle sind.

Ein grundlegendes Framework zur Verwaltung von Richtlinien muss ermöglichen, dass Richtlinien erstellt, gelöscht, geändert und gefunden werden können. Um föderierte Systeme zu unterstützen, in denen es möglich sein muss, neue Geschäftsmodelle und Partnerschaften schnell zu integrieren, muss das Framework zur Richtlinienverwaltung auch erweiterbar sein, um die Dynamik der Umgebung widerzuspiegeln, die es unterstützen möchte.

Einige Merkmale für Anwendungsrichtlinien, die in einer Föderation relevant sind:

• Vertrauenswürdiger Aussteller von identitätsbezogenen Funktionen

• Die Typen von erforderlichen Funktionen, um eine Methode einer Anwendung aufzurufen

• Die Arten von Identitätsinformationen, die die Anwendung von den Funktionen erwartet

• Die Arten von Privilegien, die eine Identität nachweisen muss, um einen Dienst aufzurufen

 

Überwachung

Bei der Überwachung geht es im Kontext von I&AM um das Speichern von Datensätzen, die angeben, wer in der IT-Infrastruktur zu welchem Zeitpunkt was getan hat. Föderale Reglementierungen wie der Sarbanes-Oxley Act stellen die hauptsächlichen Anforderungen an die identitätsbezogene Überwachung.

(a) IT-Überwachungsvorgang
Der IT-Überwachungsvorgang umfasst normalerweise die folgenden Phasen (siehe Abbildung 9):

• Überwachungserstellung

• Datensammlung und -speicherung

• Analyse und Feedback

Abbildung 9. IT-Überwachungsvorgang

Überwachungspfade können zu verschiedenen Zwecken von verschiedenen Infrastruktur- und Anwendungskomponenten erzeugt werden. Beispielsweise können Firewalls und VPN-Server Ereignisse generieren, damit externe Angriffe leichter erkannt werden können. Middleware-Komponenten können Instrumentationsdaten generieren, damit Leistungsanomalien leichter erkannt werden können. Geschäftsanwendungen können Überwachungsdaten produzieren, um das Debuggen zu unterstützen oder regulative Überwachungsanforderungen einzuhalten.

Nach der Erzeugung der Überwachungsdaten müssen diese gesammelt und gespeichert werden. Für diesen Zweck gibt es diese beiden wesentlichen Modelle: Verteilung und Zentralisierung. Im Verteilungsmodell verbleiben Überwachungsdaten normalerweise auf dem System, auf dem die Daten generiert wurden. Beim zentralisierten Ansatz werden die Daten an eine zentrale Sammel- und Speichereinheit gesendet.

Wenn die Daten gesammelt sind, können sie automatisch oder manuell verarbeitet und analysiert werden. Zweck der Überwachungsanalyse ist es, zu erfahren, mit welchen korrigierenden Maßnahmen die IT-Systeme und -vorgänge gegebenenfalls verbessert werden können.

(b) Entwurfsüberlegungen für Überwachungssysteme
Ausgehend vom typischen Überwachungsvorgang, wie er schon in den vorhergehenden Abschnitten beschrieben wurde, gibt es mehrere Überlegungen, die für den Entwurf von Überwachungssystemen wichtig sind:

• Ort der Überwachungsgenerierung und -speicherung

• Trennung der Rollen der Überwacher

• Fluss der überwachten Ereignisse

Sobald ein Überwachungspfad generiert wurde, können die Überwachungsdaten lokal auf demselben System gespeichert oder an einen anderen Speicherort übertragen werden. Diese Überlegung ist aus Sicherheitsperspektive sehr wichtig, da Überwachungsdaten leichter geändert oder bearbeitet werden können, wenn sie auf dem überwachten System gespeichert sind. Dieser Punkt kann anhand des folgenden, einfachen Beispiels erläutert werden: Wenn ein System kompromittiert wurde, ist der Angreifer möglicherweise in der Lage, den Überwachungspfad auf dem lokalen System zu bearbeiten, um den Angriff zu verschleiern. Deshalb können solche Angriffe besser erkannt werden, wenn das Überwachungssystem die Daten getrennt auf einem Remotecomputer speichert.

Rollentrennung ist eine äußerst bewährte Methode, um das Auftreten von illegalen Aktivitäten zu minimieren, die aus Aktionen resultieren, die Verantwortlichkeitsüberprüfungen möglicherweise umgehen. Beispielsweise sollte ein Mitarbeiter im Einkauf nicht in der Lage sein, eine Verkaufsanfrage zu genehmigen. Im Bereich der IT-Überwachung ist es weit verbreitet, die Rolle des Systemadministrators von der Rolle des Überwachers zu trennen. Dadurch wird verhindert, dass der Systemadministrator, der auf einem Computer normalerweise "alles" darf, Überwachungspfade über nicht autorisierte Aktivitäten verschleiert.

Im verteilten Entwurfsmodell, in dem Überwachungsdaten auf verschiedenen Systemen generiert und gespeichert werden, kann die Sicherheit weiter erhöht werden, indem nur der Datenfluss von den Überwachungsgenerierungssystemen gestattet ist, nicht jedoch der Datenfluss auf diese Systeme. Durch diese Vorsichtsmaßnahme werden die Möglichkeiten verringert, dass die tatsächlichen Überwachungsdaten durch manipulierte ersetzt werden können.

Infrastrukturen zur Identitätsüberwachung sollten zusätzlich diese Merkmale aufweisen:

• Effizient (in der Regel durch einen nachrichtenbasierten, asynchronen Kommunikationskanal)

• Verfügbar (in der Regel durch Verteilung, Cluster und Fehlertoleranz)

• Präzise (in Bezug auf Speicherung von Datensätzen und Pfaden)

• Anerkannt (zur Anerkennung als Beweis vor Gericht, d. h. in der Regel, dass die Datensätze digital signiert sein müssen)

 

Schlussfolgerung

Unternehmen bestehen aus Mitarbeitern und Systemen, die in IT-Systemen als digitale Identitäten dargestellt werden. Alle Vorgänge in Unternehmen sind Folge von Aktionen, die von oder für diese Identitäten initiiert werden. Ohne Identitäten (sogar anonymen Identitäten) gäbe es keine Aktivitäten, und Unternehmen wären leblose Konstrukte.

Auf der obersten Ebene kann mit SOA die IT-Infrastruktur eines Unternehmens, die Geschäftsaktivitäten ausführt und verwaltet, organisiert werden. Deshalb müssen Unternehmen, die SOA realisieren möchten, herausfinden, wie sie die aktuellen Herausforderungen der Identitäts- und Zugriffsverwaltung lösen. Wir haben Ihnen einen Überblick über die folgenden Schlüsseltechnologien gegeben:

• Erreichen von SSO für Benutzer und Anwendungen

• Aggregieren, Transformieren, Synchronisieren und Bereitstellen von Identitätsdaten aus verschiedenen Identitätssystemen

• Verwalten von Zugriffen auf Geschäftsfunktionen und -daten mit Rollen und Regeln

• Föderieren mit Geschäftspartnern

• Überwachen von identitätsbezogenen Aktivitäten

Außerdem hoffen wir, dass die Diskussion der technischen Herausforderungen dem Leser einige Einblicke in die Produkte und Lösungen in diesem Bereich verschafft haben.

Unsere hauptsächliche Schlussfolgerung ist: Die Identitäts- und Zugriffsverwaltung ist ein Eckpfeiler der Realisierung von SOA. Kein Unternehmen kann von sich behaupten, SOA zu unterstützen, ohne über eine gute Identitäts- und Zugriffsverwaltung zu verfügen.
Referenzen
1. Ein Kontext definiert die Grenzen, innerhalb derer eine Identität verwendet wird. Die Grenzen können geschäfts- oder anwendungsbezogen sein. Beispielsweise kann Anja ihre Arbeitsidentität mit dem Bezeichner "Anja@WallStreetAce.com" verwenden, um sich bei ihrem Arbeitgeber (Wall Street Ace) zu identifizieren, jedoch auch, um an der New Yorker Börse mit Aktien zu handeln. Ihr Arbeitgeber und die New Yorker Börse wären zwei verschiedene Geschäftskontexte, in denen derselbe Bezeichner verwendet wird. SOA Challenges: Entity Aggregation, Ramkumar Kothandaraman, .NET Architecture Center, Mai 2004 (URL:https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/dngrfSOAChallenges-EntityAggregation.asp)

2. Enterprise Identity Management: It's About the Business, Jamie Lewis,The Burton Group Directory and Security Strategies Report, Version 1, 2. Juli 2003

3. Der Begriff "Lebenszyklus" ist bei der Verwendung im Kontext digitaler Identitäten etwas unpassend, da digitale Identitäten normalerweise keinen wiederkehrenden Zyklus durchlaufen. Da der Begriff "Identitätslebenszyklusverwaltung" in der IT-Welt jedoch weit verbreitet ist, folgen wir dieser Terminologie. Microsoft Identity and Access Management Series, Microsoft Corporation, 14. Mai 2004 (URL:https://www.microsoft.com/downloads/details.aspx?FamilyId=794571E9-0926-4C59-BFA9-B4BFE54D8DD8&displaylang=en)

Der Autor
Frederick Chong ist ein Softwarearchitekt im Microsoft Architecture Strategy Team, in dem er Unterstützung bei der Integration von Anwendungen mit Identitäts- und Zugriffsverwaltungstechnologien bietet. Er entwickelte sein Interesse an Sicherheitsfragen, als er in der Arbeitsgruppe für Netzwerksicherheit des IBM T J Watson Research Centers den Prototyp eines Protokolls für den elektronischen Zahlungsverkehr erstellte. Seit dieser Zeit hat er in Microsoft-Produktteams Sicherheitsfunktionen und das Lizenzierungsprotokoll (Licensing Enforcement Protocol) implementiert, sowie mit verschiedenen Unternehmenskunden zusammengearbeitet, um eine Vielzahl von Sicherheitslösungen zu entwerfen und zu implementieren, unter anderem in den Bereichen einmalige Webanmeldung, SSL-VPN und Sicherheitsprotokolle für Webdienste. Er kann unter fredch@microsoft.com (in Englisch) erreicht werden.