Cloud und BYOD fordern das Identity-Management

Trends wie Bring your own Device und Cloud-Betriebsmodelle machen das Identity-Management nicht einfacher. Die IT muss die richtige Balance finden zwischen Sicherheit und einem einfachen Zugriff auf Systeme und Daten. [...]

Wie sicher ist Cloud-IAM?
Einige Anbieter schlagen vor, das Identity-Management selbst in die Cloudzu verlagern. Damit ließe sich die Sache vereinheitlichen und vereinfachen, werben sie. Doch die Anwender zögern. „Wenn wir unser Active Directory mit sämtlichen IDs unserer Mitarbeiter und Kunden in die Cloud verlagern, geben wir unsere Kronjuwelen aus der Hand“, sagt Jerry Archer, Chief Security Officer des US-amerikanischen Finanzhauses Sallie Mae. „Wenn das Hackern in die Hande fällt, haben sie alles.“
IM wird noch komplexer werden, glauben die Experten vom Fraunhofer-Institut für offene Kommunikationssysteme. Dazu beitragen könnte vor allem das Internet der Dinge. Künftig würden neben Menschen auch immer mehr Gegenstände und Produkte vernetzt. Auch die Identitäten dieser Objekte gelte es sicher zu steuern.
Doch wie sieht eine gute IAM-Strategie aus? IAM besteht nicht nur aus einem Tool. Es bezeichnet vielmehr eine Reihe unterschiedlicher Technologien, die helfen können, Benutzer zu verwalten und zu authentifizieren, Zugriffe zu autorisieren sowie die dazu gehörigen Zugriffsrechte zu verwalten und das Ganze zu überwachen. Oft spricht man dabei von den 4A – Administration, Authentifizierung, Autorisierung, Auditing.
Klärung der Fachbegriffe
Bei der Benennung der wichtigsten Komponenten fällt der Blick zunächst auf die Bereiche „Identity Provisioning“ und „Access Governance“. Identity-Provisioning-Systeme verwalten die Identitäten und Berechtigungen in verschiedenen Zugriffsschutzsystemen wie Active Directory, LDAP-Server, Datenbanken, aber auch Business-Anwendungen wie SAP. Access Governance stellt Funktionen für die Analyse von Berechtigungen, deren Rezertifizierung (Bestätigung der Richtigkeit) beispielsweise durch die Abteilungsleiter und für die einfache Anforderung durch Endanwender bereit. Weitere wichtige Bereiche sind:
– das Enterprise Single Sign-On für die Anmeldung an vielen Systemen mit nur einer Authentifizierung;
– die Identity Federation für die standardisierte Verbindung unterschiedlicher Systeme innerhalb und außerhalb des Unternehmens;
– Web Access Management vor allem für die zentrale Authentifizierung von Zugriffen auf Web-Anwendungen;
– das dynamische Autorisierungsmanagement, mit dem Anwendungen zur Laufzeit von zentralen Systemen Autorisierungsentscheidungen anfordern können, die auf zentral verwalteten Regeln basieren.
Wo wird es eingesetzt?
Identity Federation ist deshalb interessant, weil damit beispielsweise ein Automobilhersteller eine Anwendung realisieren kann, bei der die Benutzer von den Zulieferern authentifiziert werden, so dass diese Anwendung nur noch die Autorisierung übernehmen muss. Dazu muss diese Anwendung natürlich darauf vertrauen, dass die Zulieferer das auch richtig machen – aber im Gegenzug müssen nicht alle Benutzer beim Automobilhersteller verwaltet werden, was den Verwaltungsaufwand und die Fehlergefahr senkt.
Dynamisches Autorisierungsmanagement ist eines der weniger bekannten IAM-Themen, das aber deutlich an Bedeutung gewinnt. Dabei geht es darum, die Regeln für Autorisierungsentscheidungen eben nicht mehr in Anwendungen selbst zu codieren, sondern auf zentrale Autorisierungssysteme und Regeln zurückzugreifen. Änderungen lassen sich von einem Punkt aus vornehmen – vom neuen Job eines Mitarbeiters bis hin zur Änderung von Limits für die Genehmigung von Verträgen aufgrund geänderter gesetzlicher Vorschriften. Das bringt viele Vorteile für Auditing, Nachvollziehbarkeit und einen reduzierten Änderungsaufwand für Anwendungen.
Die zwölf Gebote der IAM-Einführung
Deutlich wird, dass IAM nichts ist, das einfach nur da ist, wenn sich das Unternehmen eine Software kauft und diese installiert. Die Umsetzung von IAM erfordert eine sorgfältige Planung. Dabei sind zwölf Punkte von besonderer Bedeutung, deren Beachtung die Risiken einer IAM-Einführung deutlich reduzieren kann.
– IAM ist ein vielschichtiges Thema. Und oft haben unterschiedliche Personen ein unterschiedliches Verständnis der IAM-Funktionen. Ein Projekt sollte damit beginnen, IAM zu verstehen, damit man ein Gefühl dafür hat, wo der größte Nutzen entstehen könnte. Und jedes Teilprojekt sollte damit beginnen, dass man klärt, um was es wirklich gehen soll. Projekte, die als „wir wollen Federation“ beginnen, sehen danach oft ganz anders aus und umfassen auch Web Access Management und manches mehr;
– Wenn die IT Geld ausgibt, muss das Business einen Nutzen sehen. Neben der Erfüllung regulatorischer Vorgaben und von Audit-Anforderungen gibt es andere Vorteile, die deutlich gemacht werden müssen. Die Gesamtsicht auf Benutzer – ein Mitarbeiter einer Versicherung kann beispielsweise gleichzeitig auch freiberuflicher Makler und Kunde sein – gehört ebenso dazu wie die Fähigkeit, neue Geschäftspartner sehr schnell anzubinden und damit die Anforderungen an die Agilität des Business zu unterstützen;
– Think big – start small. Diese Regel sollte man immer im Kopf haben. Die verschiedenen Bereiche von IAM sind miteinander meist eng verknüpft. Bevor an einer beliebigen Stelle begonnen wird, gilt es, ein Gesamtbild aufzubauen, das aufzeigt, wie IAM einmal aussehen soll. Dabei bilden sich die Prioritäten meist von allein heraus;
– IAM-Projekte zielen meist primär auf die Mitarbeiter ab. Das ist falsch. Projekte müssen so angelegt sein, dass sie mit allen Identitäten arbeiten können und die Zugriffe auf Systeme und Informationen über alle Zielgruppen hinweg – Mitarbeiter, Partner, Kunden – verwalten können. Die „Identity Explosion“, die Vervielfachung der zu verwaltenden Identitäten muss aber von Anfang an mitbedacht werden, auch wenn die ersten Implementierungen vielleicht dann nur auf Mitarbeiter ausgerichtet sind. Aber sie müssen so gestaltet sein, dass sie wachsen können;
– Als Konsequenz aus „Think big – start small“ resultiert eine strukturierte Vorgehensweise, bei der das Gesamtthema in kleinere, beherrschbare Projekte mit einer engen Verzahnung zerlegt wird;
– IAM ist ein klassisches Querschnittsthema. Es betrifft alle Systemumgebungen. Es betrifft IT-Sicherheit ebenso wie Anwendungsentwicklung. Es betrifft aber auch das Business, das letztlich weiß, wer welche Berechtigungen haben sollte. Deshalb müssen alle Parteien rechtzeitig ins Boot geholt werden;
– Viele Unternehmen, die früh gestartet sind, haben heute ein Identity-Provisioning-System, das oft nicht mehr ausreicht oder vom Hersteller nicht recht weiterentwickelt wurde. Flexible IAM-Architekturen sind daher ein Muss, um die Abhängigkeiten von Herstellern zu reduzieren. Nur so kann das Thema mit bestehenden IT-Systemen wie den Service-Request-Management- und Service-Desk-Lösungen integriert werden und auch weiterhin anpassbar bleiben;
– IAM ist keine eigenständige Technologie. Die Fachbereiche sollen darüber steuern können, wer was tun darf. Sie sollen in der Lage sein, neue Benutzergruppen aufzunehmen. Deshalb muss das, was „herauskommt“, so einfach sein, dass es für die Endanwender funktioniert;
– Ohne die richtigen Organisationsstrukturen, Regelwerke, Richtlinien und Prozesse wird IAM nicht funktionieren. Diese müssen frühzeitig definiert und umgesetzt werden. Die Identifikation von Verantwortlichkeiten in der Business-Organisation ist dabei oft die komplexeste Herausforderung – die viel einfacher wird, wenn man den Wert für das Business erläutern kann und klare, einfache Regeln und Prozesse vorbereitet hat;
– Bei IAM geht es in hohem Maße um die Nachvollziehbarkeit von Zugriffsrechten. Access Governance bietet hier viele Funktionen. Es geht heute aber auch darum, es als Teil der gesamten GRC-Infrastruktur (Governance, Risk Management, Compliance) des Unternehmens zu verstehen und richtig einzubinden;
Komplexe Projekte verlangen ein gutes Projektmanagement. Ihre besten Projektmanager sind dafür gerade gut genug. Schließlich müssen viele Personen an einem Strang ziehen, um Schritt für Schritt Teilprojekte umzusetzen, die sich zu einem großen Ganzen zusammenfügen;
– Schließlich sollte ein Unternehmen nicht den typischen Fehler machen und mit Produkten beginnen. Erst müssen die genauen Anforderungen in jedem einzelnen Teilprojekt bekannt sein – sowohl von Technik als auch Business. Danach lassen sich die richtigen Produkte auswählen. Andersherum geht es meistens schief.
* Martin Bayer arbeitet als Redakteur bei der deutschen Computerwoche. Martin Kuppinger ist Co-Founder und Principal Analyst bei KuppingerCole.