Grüße von der langen Bank – Dauerbaustellen der Security (10) : Ich, du, er, sie, es, IT : Identity- und Access-Management (IAM)

Von Bettina Weßelmann und Johannes Wiele, München

Mit welch heißem Eisen man es beim Themenkomplex Identitäts- und Accessmanagement (IAM) zu tun hat, zeigt sich schnell, wenn man einfach eine Liste der damit verbundenen Teilaufgaben und der zugehörigen Schlagworte anlegt:

• sichere Kennwörter
• Single-Sign-on
• Need-to-Know-Prinzip
• Privileged-Access-Management
• Schutz von Anwenderdaten
• Biometrie
• Endgeräte-Erkennung
• Active Directory und LDAP
• User-Provisioning
• Autorisierung
• Löschen der Rechte ausgeschiedener Mitarbeiter
• Etablierung von Rollenkonzepten

…

Es könnte noch eine Weile so weitergehen – dabei steht jeder der genannten Begriffe bereits für sich genommen für respektable IT- und Datenschutzprojekte.

Zugleich spielen „digitale Identitäten“ für praktisch jeden Aspekt der IT- und Informationssicherheit eine Rolle: Es geht immer darum, nur diejenigen Menschen und Systeme auf „Assets“ in einer IT-Infrastruktur zugreifen zu lassen, die aktuell damit arbeiten und deshalb Zugriffsrechte eingeräumt bekommen müssen. In der modernen IT müssen dabei nicht mehr nur Informationen vor Missbrauch geschützt werden, sondern auch „Dinge“, die über interne und weltweite Netze erreichbar sind – etwa Produktionsanlagen oder Produkte in den Händen von Konsumenten.

Weitere Komplexitätsebenen entstehen durch die Auslagerung von Applikationen und Servern in die Cloud und die damit verbundene Aufgabe, interne Anmeldedaten auch für externe Systeme nutzbar zu machen (s. a. S. 28), sowie durch den mobilen Zugriff auf Unternehmens-Ressourcen mit den unterschiedlichsten Endgeräten.

Im Interview zu diesem Beitrag (siehe Kasten auf S. 24) zeichnet Angelika Steinacker ein lebhaftes Bild vom Aufgabenkomplex, den modernes IAM bildet – und von der Bedeutung, die die Bewältigung des Themas für moderne Organisationen hat. Unternehmen, die die Herausforderung nicht selbst erkennen, müssen sich dennoch damit auseinandersetzen, denn mehr oder weniger konkrete und harte Anforderungen zu IAM befinden sich in praktisch jeder Industrienorm und jedem Gesetz, das sich mit Informationssicherheit oder Datenschutz befasst.

Der Zwang, einen professionellen Umgang mit digitalen Identitäten nachweisen zu müssen, ist einer der häufigsten Auslöser für Versuche, die unterschiedlichen Ansätze des Umgangs mit Rechten und Identitäten in einem gewachsenen Unternehmen nachträglich einem möglichst umfassenden IAM-Konzept zu unterwerfen – und genau solch ein Projekt hat dann das Zeug dazu, sich zur Dauerbaustelle ohne jegliche Aussicht auf „freie Fahrt“ zu entwickeln.

Die Situation

Irgendeine Art von Identitätsmanagement (IdM) findet in jeder Organisation statt, allerdings häufig in heterogener Form und in voneinander getrennten „Silos“. Selbst wenn es bereits Lösungen für Single-Sign-on gibt und die dazu notwendige Basis-Infrastruktur vorhanden ist, bleiben einzelne Arbeitsbereiche oft unberücksichtigt.

Bei Assessments tauchen überdies zuweilen IdM-Inseln auf, die dem Management oder den IT-Verantwortlichen der fraglichen Organisation gar nicht bekannt sind: Da hat beispielsweise der Leiter der Entwicklungsabteilung eine Datenbank für Codemodule angelegt, deren Zugriffsrechte er höchstpersönlich vergibt. Oder eine Fachabteilung bedient sich einer zwar formal vielleicht sogar sicheren, im Unternehmenskontext aber gar nicht auf Risiken hin betrachteten Datenaustauschplattform in der Cloud und regelt die Zugänge in eigener Regie. Näheres Hinsehen fördert bei Analysen manchmal erstaunlich viele Unternehmensangehörige zutage, die sich in irgendeiner Form „ganz nebenbei“ und jenseits der geregelten Bahnen mit Aspekten des Identitätsmanagements befassen und dabei auch Anwenderdaten erfassen und horten.

Dabei ist, wie Angelika Steinacker aufzeigt, schon die Vielfalt der „offiziellen“ IdM-Verantwortlichen in Unternehmen nur schwer überschaubar und vor allem nur mit Mühe dazu zu bringen, an einem Strang zu ziehen. Die einen müssen aufgrund ihrer Sicht auf ihre User-Population für ein möglichst strenges Zugriffsmanagement plädieren, die anderen befürchten mit Blick auf ihre Klientel eine abschreckende Wirkung von wie auch immer gearteten sicheren Anmeldeprozeduren. Für die einen hat die Einschränkung von Zugriffsrechten Priorität, für die anderen ein ungehinderter Zugang zu businessrelevanten Daten und Systemen.

Wird ein Vereinheitlichungsprojekt in Gang gebracht, das auf die aus gutem Grund unterschiedlichen Sichtweisen keine Rücksicht nimmt, werden Akteure, deren Bedürfnisse unterzugehen drohen, alles tun, um das Voranschreiten des Vorhabens zu unterbinden. Vor allem Projekte, die aus rein technischer Sicht auf IAM gestartet und primär „Bottom-up“ aus der Perspektive der IT-Abteilung gesteuert werden [1], laufen gern in diese Falle. Statt über die digitalen Identitäten, ihren Wert, ihre Bedeutung und den Umfang der damit verbundenen Datenerhebungen zu reden, verlieren sich Unternehmen dann in endlosen Diskussionen über den Umgang mit den Daten im Einzelfall oder singulären „Use-Cases“.

Ursachenforschung

Die Gründe für die beschriebene Situation sind relativ einfach gelagert, so komplexe Folgen sie auch haben: Identitätsmanagement ist eine organisatorische Planungsaufgabe mit großer Tragweite. Die Entwicklung der IT-Landschaften mit ihrer schnellen Adaption immer neuer Verfahren und Applikationen schreitet so rasant voran, dass das IAM nicht nachkommt – was paradox ist, denn gerade die schnelle Entwicklung der IT macht die Notwendigkeit für übergreifende IAM-Konzepte spürbar.

Bei der Einführung neuer Lösungen besteht dann häufig die Alternative, sie entweder von vornherein einem eventuell bereits vorhandenen IAM-Konzept zu unterwerfen (potenziell langwierig, projektverzögernd) oder sie (kurzfristig vermeintlich zielführender) „bis auf Weiteres“ mithilfe eingebauter IAM-Funktionen zu betreiben oder nur notdürftig an die vorhandene Infrastruktur anzubinden. So wächst über die Zeit die Zahl nachträglich zu vereinheitlichender, isolierter IAM-Ansätze in einer Organisation.

Der zweite Grund ist die bereits angedeutete Kommunikationsproblematik: IAM ist keine Angelegenheit, die sich auf die technische IT abwälzen lässt, sondern eine unternehmensweite Abstimmungsaufgabe. Fehlt eine Institution, die dazu auf übergeordneter Ebene aktiv werden kann und die unterschiedlichen Akteure an einen Tisch holt, kann kein professionelles, risiko-adäquates IAM im Sinne eines Informationssicherheits-Managements entstehen.

Dauerbaustellen der Security – Infos zur Serie

Die <kes>-Serie „Grüße von der langen Bank“ widmet sich Security-Themen, die in Organisationen gern „vergessen“ oder aus anderen Gründen nicht in Angriff genommen werden – und sich dann bei Sicherheitsprojekten als gefährliche Showstopper erweisen. Alle Beiträge beschreiben die jeweilige Situation, arbeiten mögliche Gründe auf, zeigen die wahrscheinlichen Folgen und versuchen schließlich zu erklären, wie sich Mängel am besten und schnellsten beheben lassen.

<kes>: Für so viele Unternehmen steht ein durchgängiges Identitäts- und Access-Management ganz oben auf der Prioritätenliste – und wird dann doch nur schleppend, teilweise oder gar nicht umgesetzt. Wo liegen die Gründe dafür?

Steinacker: Ein Punkt ist, dass IAM alles und jeden betrifft, und zwar ganz direkt. Andere Sicherheitslösungen – Firewalls etwa – können im Verborgenen operieren und ihre Existenz fällt vor allem Endanwendern kaum einmal auf. Aber an Systemen anmelden muss sich, auf mehr oder weniger lästige Weise, jeder immer und immer wieder. Und er muss sich auch gar nicht so selten durchaus intensiv mit den Auswirkungen von IAM auseinandersetzen – zum Beispiel, wenn er die zu seinem Job passenden Zugriffs- oder Zugangsechte beantragt oder merkt, dass er sie nicht hat und dann eine Lösung suchen muss. Die ganze Branche arbeitet zwar daran, IAM weniger „spürbar“ zu machen, aber die entsprechenden Lösungsansätze sind bei Weitem nicht so weit fortgeschritten wie in anderen Bereichen der IT-Security.

<kes>: Also hat man es vor allem mit Problemen der Akzeptanz und Benutzerfreundlichkeit zu tun?

Steinacker: Die Thematik ist weit umfassender. In den Organisationen haben die unterschiedlichsten Akteure ganz unterschiedliche Auffassungen von einem „guten“ Identitätsmanagement – und haben dabei auch höchst unterschiedliche Zielgruppen im Blick. Endkunden, Partner, Administratoren: In jedem Bereich müssen Sicherheit und Benutzerfreundlichkeit anders ausbalanciert werden und die für diese Gruppen jeweils zuständigen Abteilungen setzen auch unterschiedliche Prioritäten. Die einen denken marketingorientiert und wollen die Consumer nicht durch zu hohe Sicherheitsanforderungen vergraulen, die anderen müssen beim „Privileged Access“ aufgrund von Complianceanforderungen besonders hart sein, eine dritte Gruppe will zugleich Sicherheit demonstrieren und großen Business-Partnern bequeme Zugänge ermöglichen. Ein Unternehmen, das im IAM tatsächlich ganzheitlich und systematisch vorgehen will, muss all diese Gruppen und alle Perspektiven verstehen und mit allen Verantwortlichen sprechen. Dies bedeutet auch: IAM-Projekte, die allein von der Technik ausgehen, kommen selten weit voran.

<kes>: Dann gehört also auch IAM zu den Bereichen, in denen das Gelingen der internen Kommunikation eine besondere Rolle spielt – das ist ein Merkmal vieler „Dauerbaustellen“ der IT.

Steinacker: Richtig. Es kommt aber noch etwas hinzu, was selbst viele erfahrene IT-Spezialisten nicht immer sofort auf dem Radar haben: Es gibt auch technische Identitäten im Netz – etwa Server, Endgeräte und Applikationen. Auch hier gilt es, Rechte und Rollen zu verteilen und zu verwalten. Und die Identitätsinfomationen aller Entitäten, ob menschlich oder technisch, müssen den Sicherheitsmanagement-Verantwortlichen der jeweiligen Organisation gut zugänglich sein. IAM hat Bezug zu wirklich jedem Aspekt der IT-Security.

<kes>: Ist es denn realistisch, für all diese Einsatzgebiete dann eine gemeinsame, alle und alles umfassende Management-Lösung anzupeilen?

Steinacker: Das lässt sich durchaus nicht immer umsetzen. Ich plädiere deshalb dafür, die Identitätsinformationen zu allen Entitäten in einem gemeinsamen Repository, einem „Data-Hub“, zu halten, auch wenn sie von unterschiedlichen Systemen angewendet werden. Der Hub bietet dann standardisierte Abbilder der relevanten digitalen Identitäten; und zwar zunächst einmal ganz unabhängig von den konkreten Einsatzszenarien. Man könnte diese Abbilder auch als Teilmenge der „digitalen Twins“ realer Entitäten in einer IT-Infrastruktur bezeichnen – „Teilmenge“ deshalb, weil die Funktionen der Entitäten hier keine Rolle spielen. So lässt sich zumindest auf einer höheren Abstraktionsebene mit Templates arbeiten und es wird möglich, die Identitätseigenschaften von Entitäten zu vergleichen, abteilungs- und zielgruppenübergreifend über sie zu sprechen und Verfahren des Umgangs damit zu entwickeln, die die Kriterien eines echten Sicherheitsmanagements erfüllen.

<kes>: Wir hören da heraus: Eine gemeinsame Diskussions- und Handlungsbasis herzustellen ist wichtig, um festgefahrene IAM-Projekte in Gang zu bringen. Wie schafft man das praktisch?

Steinacker: Workshops sind wichtig. Man muss die Beteiligten mit ihren unterschiedlichen Perspektiven dazu bringen, sich zusammenzusetzen. Bei den Diskussionen um Ziele und ihre Umsetzung muss man dann einige Energie darauf verwenden, den Scope angestoßener Projekte im Auge zu behalten. Er darf nicht wachsen und wachsen, bis gar nichts mehr geht, aber zugleich darf der Blick auf den großen Zusammenhang nie verloren gehen. Hier eine Balance zu finden, gehört zu den echten Herausforderungen des Projektmanagements in diesem Bereich. Und, wie schon angedeutet: Man darf nicht allein technisch denken. Die mit IAM-Projekten verbundenen Aufgaben liegen zu 70 bis 80 Prozent außerhalb des Bereichs „Technik“ und sind eher organisatorisch geartet oder betreffen Prozesse. Change-Management etwa spielt eine besondere Rolle.

<kes>: Welche Rolle spielt das Phänomen des „Internet of Things“ (IoT) für moderne IAM-Ansätze?

Steinacker: Es macht alles noch einmal größer und komplexer. Praktisch bringt es die vorhandene Technik oder bereits durchgeplante Konzepte vor allem im Bereich des Zugriffsmanagements häufig an die Grenzen der Skalierbarkeit – zumindest dann, wenn die Organisationen überhaupt die Notwendigkeit erkennen, die mit IoT verbundene Flut an neuen Geräten und Diensten im Identitäts- und Access-Management zu berücksichtigen.

Dann gilt es, über neue Auswirkungen eines Versagens von IAM nachzudenken. Wir sprechen bei IoT einerseits über „Geräte“, die klein und unscheinbar sein können, aber Unmengen von Daten bereitstellen können und somit hohe Missbrauchsrisken bergen. Wir sprechen aber auch über Entitäten von der Größe und physischen Präsenz eines Autos, einer Produktionsstraße oder eines Hauses. Es geht derzeit gar nicht so sehr darum, dass „Dinge“ oder „Geräte“ auf Organisationen oder Informationen zugreifen sollen, sondern darum, dass Akteure aus den Kommunikationsnetzen heraus auf Dinge zugreifen und dabei immensen Schaden anrichten können – man denke an Szenarien, bei denen Angreifer die Steuerung eines Fahrzeugs, eines medizinischen Geräts oder eines Industrieroboters übernehmen.

Vielleicht sollte man tatsächlich nicht nur von IoT sprechen, sondern auch von der Identität der Dinge – IdoT. Wie professionell wir das schaffen, hat große Bedeutung für die heutige und zukünftige Unternehmenssicherheit. Das ist keine unlösbare, aber durchaus eine große Aufgabe – nicht umsonst ist laut IDC der IAM-Markt bereits jetzt der größte Security-Teilmarkt überhaupt.

Risiken und Nebenwirkungen

IAM betrifft alles und jeden in einer IT-gestützten Organisation – also haben Mängel auf diesem Gebiet auch das Potenzial, überall fast beliebig große Sicherheitslücken aufzureißen. Die Gefahren beginnen beim ganz konkreten
unerlaubten oder unerwünschten Zugriff auf Informationen sowie dem damit verbundenen Missbrauch und enden bei der Unfähigkeit, entsprechende Vorfälle untersuchen zu können, was den Erfolg bei Audits infrage stellt. Ohne professionelles IAM kann im Endeffekt kein Unternehmen behaupten, wirksames Informationssicherheits-Management zu betreiben.

Mangelhaftes IAM verhindert überdies nicht nur wirksame Präventionsmaßnahmen, also den vorausschauenden Schutz von Daten und Systemen, sondern auch die heute immer wichtigere „Detektion“, also das Erkennen laufender Angriffe, die trotz aller Sorgfalt die Vorkehrungen der Perimetersicherheit überwinden konnten.

Dazu ein plastisches Beispiel aus der Praxis des Autorenteams: In einem Unternehmen wird ein „Proof of Concept“ für ein Security-Incident- und -Event-Management-(SIEM)-System durchgeführt. Berater haben eine Appliance installiert und für den allerersten Test mit nur wenigen Log-Quellen im Unternehmen verbunden. Log-Quellen sind die „Sinne“ eines SIEM-Systems, das die gelieferten Daten unter anderem auf Anomalien hin auswertet.

Solange ein SIEM-System allerdings nicht speziell an die Umgebung angepasst ist, die es beobachten soll, und auch keine Kontextinformationen über die angeschlossenen Lieferanten von Log-Daten hat, kann es nur auf sehr generische Auffälligkeiten reagieren. Genau das tut es im Fall unseres Beispiels unmittelbar nach der Scharfschaltung: Es warnt vor einem User in Fernost, der im Millisekundentakt Anfragen an eine Datenbank stellt. Der User ist im Directory als „persönlich“ gelistet, aber ein Mensch kann gar nicht so schnell immer neue Zugriffsversuche starten.

Die Zuschauer reagieren hektisch: Ist vielleicht tatsächlich eine Attacke im Gang? Es dauert lange, allzu lange, mehr über den Akteur herauszufinden. Am Ende stellt sich heraus: Eine Entwicklerin, die zu allem Überfluss gar nicht mehr im Unternehmen arbeitet, hat irgendwann ein Testskript gestartet und mit ihrer eigenen digitalen Identität arbeiten lassen. Dann hat sie vergessen, den „Geist“ wieder aus dem Netz zu verbannen.

Zwei Aspekte mangelhaften Identitätsmanagements werden sichtbar: Ein maschineller User konnte unter der Maske eines persönlichen Anwenders operieren und die digitale Identität der Urheberin blieb auch nach ihrem Weggang bestehen. Man könnte nun sagen, das SIEM habe das Problem doch erkannt, und somit sei alles gut – Risiken bestanden durch die Mängel aber sehr wohl. Und die Zeitspanne bis zur Aufklärung des Falls war viel zu lang, um etwa in einem tatsächlichen „Brute-Force“- Angriffsfall noch Schaden verhindern zu können.

Konfliktpotenzial

Der bereits erwähnte Interessenkonflikt zwischen IAM-Verantwortlichen, die den Zugriff auf spezielle Ressourcen möglichst ungehindert gestalten wollen, und jenen, denen Sicherheit über alles geht, kann im Einzelfall auf tatsächlich unvereinbare Sicherheitsziele verweisen.

In Kliniken etwa oder im direkten Umfeld von Produktionsanlagen kann es aus Gründen der Abwehr physischer Gefahren unmöglich oder lebensgefährlich sein, strikte Zugriffsbeschränkungen im Sinne eines technisch realisierten Privileged-Access-Managements durchzusetzen. Läuft beispielsweise an einer großen Produktionsstraße etwas schief, müssen auf Zuruf auch Menschen auf Steuerpulte und Parameter zugreifen können, die diese Rechte normalerweise nicht haben. Ein Roboter, der um sich schlägt, muss sofort gestoppt werden können – und wenn im Krankenhaus ein Patient in akute Gefahr gerät, dürfen der Hilfe keine Kennwörter oder die Verfügbarkeit von RFID-Tokens im Wege stehen. Im Gesundheitsbereich setzt man zur Abhilfe häufig Systeme ein, bei denen sich alle Zugriffschranken durch einen Notfallknopf außer Kraft setzen lassen. Wird dieser betätigt, treten allerdings besondere Protokollfunktionen in Kraft.

Was in solchen Fällen ebenfalls noch bleibt, ist ein Identitätsmanagement auf der Basis menschlicher Sinne: Man kennt einander und weiß, wer ans Produktionsband gehört, oder stellt diese Zugehörigkeit anhand des Firmenausweises fest. Feste Verhaltensregeln geben vor, wie zu verfahren ist, wenn eine Person mit ungeklärter Rolle oder unklaren Rechten in einem kritischen Bereich auftaucht. Problematisch ist dieser Ansatz höchstens deshalb, weil traditionelle Ausweise leicht zu fälschen sind – ob die damit verbundenen Risiken größer sind als diejenigen, die von „harten“ Zugriffs- oder Zugangsbarrieren ausgehen, muss jeweils per Assessment geklärt werden.

Interessant ist, dass der immer bedeutsamer werdende Einsatzbereich „Operational Technology“ (OT) nun offenbar dazu führt, dass sich Unternehmen auch mit Facetten des Identitätsmanagements kreativ auseinandersetzen, die auf menschliche Sinne setzen müssen. So gibt es inzwischen Anbieter wie das Start-Up Ticto, das Badges und Badgeholder als Elemente des klassischen Firmenausweises Farbwechsel-Zyklen aussetzt, die gruppenweise unvorhersehbar durch einen Algorithmus gesteuert werden. Ein Team kann dann die Zugehörigkeit einer Person zu seinem Arbeitsbereich daran erkennen, dass alle Ausweise zur gleichen Zeit die gleiche Farbe haben. Auch Alarme im Falle des Betretens eines unzulässigen Bereichs lassen sich schalten.

Der schnelle Weg aus der Sackgasse

• Trennen Sie die Diskussion über das generelle Konzept für digitale Identitäten von der über die konkrete technische Umsetzung. Schaffen Sie einen „Data-Hub“: ein Repository, das abstrakte Abbilder der in der Organisation vorhandenen Identitäten in standardisierter Form beherbergt.
• Sorgen Sie dafür, dass sich konkrete Authentifizierungs-, Autorisierungs- und Identitätsmanagement-Projekte an im Hub verfügbaren Daten und Templates bedienen. So kommt automatisch eine systematisierte Management-Ebene ins Spiel, die sich mit der Vorstellung von einem echten Informationssicherheits-Management-System (ISMS) vereinbaren lässt – und das Identitätskonzept hinter dem IAM wird nicht vom Klein-Klein aller möglichen praktischen Einzellösungen unter differierenden Prioritäten torpediert.
• Die Diskussion über IAM sollte nicht auf der technischen Ebene geführt werden, sondern nah am Management und unter Berücksichtigung aller legitimen Sichtweisen auf die Thematik. Die Auseinandersetzung damit fordert große Bereitschaft zur interdisziplinären Kommunikation, die es herzustellen und zu fördern gilt.

Wege zum IAM

Alle erfolgreichen Anstrengungen, das Problemfeld IAM zu entschärfen, basieren bisher auf Abstraktionsbemühungen. Das „Rollenkonzept“ ist ein gutes Beispiel: Es ermöglicht die Zuordnung von Individuen und Systemen zu standardisierten, häufig vorkommenden Funktionen und Aufgaben, die sie in einem Unternehmensumfeld haben, und verhindert so, dass für jede Identität alle Rechte und Merkmale immer wieder neu erfasst werden müssen.

Ein weiteres Beispiel stellt die Spezifikation „Fast IDentity Online – Universal Authentication Framework“ (FIDO UAF, siehe https://fidoalliance.org/download/) dar, die den Einsatz fast beliebiger integrierter biometrischer Anmeldetechniken von mobilen und anderen Geräten an zentralen Systemen ermöglicht, indem sie eine vereinheitlichte Kommunikationsebene für die tatsächliche Authentifizierung an Onlinediensten bereitstellt. Der Anwender gibt sich an „seinem“ Gerät etwa durch Fingerabdruck- oder Iris-Scan zu erkennen, die FIDO-Technik macht das Ergebnis dann für zentrale Systeme nutzbar (vgl. [2]) – hier wurde also die Infrastruktur-Ebene abstrahiert.

Angelika Steinacker (siehe Interview-Kasten) geht noch einen Schritt weiter: Sie empfiehlt Unternehmen, digitale Identitäten zunächst unabhängig von den konkreten Authentifizierungs- und Autorisierungsanforderungen völlig abstrakt in einem „Data-Hub“ zu erfassen. Die dort abgelegten Daten lassen sich unternehmensgerecht standardisieren, genügen so formal auch strengen ISMS-Anforderungen und stehen dann allen Interessenten in der Organisation zur Verfügung, die konkrete IAM-Probleme zu lösen haben.

Der Vorteil ist, dass sich die Diskussion um die Identitäten von den heterogenen technischen Umsetzungsanforderungen lösen lässt und dass bei der Einführung neuer Systeme oder Applikationen die Identitätsinformationen der möglicherweise Zugriffsberechtigten bereits in Form wiederverwertbarer „Templates“ vorliegen. Wie die Brücke zwischen dem zentralen Repository und der konkreten Anwendung dann jeweils herzustellen ist, mag ein eigenes Thema sein, aber in diesem Kontext muss man dann nicht mehr über die Identitätsinformationen an sich diskutieren – es sei denn, es kommt tatsächlich die Forderung nach bisher unberücksichtigten Details ins Spiel.

Es sei noch einmal betont: Für den Aufbau des Data-Hubs und seines Inhalts müssen alle an einen Tisch gebracht werden, die mit Identitätsmanagement zu tun haben – und das können vom Management über die Personalabteilung und den Datenschutz bis zu den Technikern tatsächlich fast alle Personenkreise sein, die für das Funktionieren einer Organisation Verantwortung tragen.

Bettina Weßelmann (bettina@wesselmann.com) ist Beraterin für Unternehmenskommunikation und Fachautorin mit dem Spezialgebiet Informationssicherheit. Dr. Johannes Wiele (johannes@wiele.com) ist freier Autor sowie GDD-geprüfter Datenschutzbeauftragter und arbeitet als Managing Security-Consultant.

Literatur

[1] Johannes Wiele, Flop-up oder Bottom-down?, Warum Projekte „von unten“ häufig scheitern – eine Provokation, <kes> 2017#6, S. 15
[2] Bettina Weßelmann, Johannes Wiele, Überlast durch Trends und Hypes, Wenn das Innovationsmanagement fehlt, <kes> 2017#1, S. 12