IAM im Multi-Cloud-Umfeld

Föderationsansätze richtig wählen

14. März 2016, 7:00 Uhr | Andreas Schindler, Principal Cloud Architect und Teamleiter Cybersecurity and Enterprise Mobility bei Fritz & Macziol, www.fum.de./wg

Single Sign-on (SSO) bringt Unternehmen und IT-Abteilungen ebenso Vorteile wie den Benutzern der Anwendungen. Um davon auch in Situationen mit mehreren Clouds profitieren zu können, gilt es, das lokale Identity- und Access-Management (IAM) mit anderen Mechanismen zur Authentifizierung und Autorisierung zusammenzuführen.

"Yet another password and user identity" ist der Schrecken nicht nur vieler IT-Anwender, sondern auch der IT-Abteilungen: Es gehört in vielen Unternehmen noch zum Alltag, macht aber allen Beteiligten das Leben schwer. Oft müssen sich die Mitarbeiter in nahezu jeder neuen Anwendung mit einer anderen Kennung und einem zugehörigen Passwort plagen, für das vielleicht zu allem Überfluss noch unterschiedliche Richtlinien über verwendbare Zeichen, Länge und Erneuerungszyklen gelten. So ist es oft nicht nur zeitraubend und lästig, akzeptable Passwörter zu finden, sondern nahezu unmöglich, sich diese zu merken. Als Folge nehmen Fehleingaben zu und die Risiken bei der Verwendung steigen. Denn die Benutzer sehen sich gezwungen, ihre Passwörter mit wenig Rücksicht auf Geheimhaltung zu notieren. Gleiches gilt für den Bereich der System- und Service-Konten oder Skripts, welche fest codierte Benutzerkennungen und Passwörter beinhalten. Vorgaben von Wirtschaftsprüfern, die kritischen Systeme und Anwendungen mittels zentral verwalteter Identitäten und komplexer Passwortrichtlinien zu schützen, werden heute nur selten erfüllt.
Ein durchgängiges Identity- und Access-Management über die gesamte System- und Anwendungslandschaft hinweg wäre auch für interne IT-Abteilungen wünschenswert. Denn es senkt neben den Sicherheitsrisiken auch die Support-Aufwendungen und damit verbundene Kosten. Doch die Implementierung ist nicht immer einfach - etwa beim viel zitierten lokalen Warenwirtschaftssystem, wo oft noch eigene Benutzerverzeichnisse und separate Login-Prozesse dominieren. Die Komplexität steigt, wenn Partnerunternehmen oder Endkunden direkten Zugriff auf die Datenbestände der Warenwirtschaftslösung wie aktuelle Lagerbestände oder Liefertermine erhalten wollen. Eine der größten Herausforderungen liegt darin, den Status und die Informationen eines jeden einzelnen (externen) Benutzers im jeweiligen Anwendungs-Verzeichnisdienst aktuell zu halten. Allen Beteiligten SSO anzubieten ist auch in solchen Szenarien zwar möglich, jedoch oft mit hohen Aufwendungen und Kompromissen verbunden.
 
AAA-Protokolle und -Standards
Welche Protokolle und Standards sich für Authentifizierung, Autorisierung und letztlich auch zur Abrechnung (im Englischen: Authentication, Authorization, Accounting, kurz AAA oder "Triple-A" genannt) am besten eignen, hängt von zahlreichen Randbedingungen ab. Dazu zählt zum Beispiel, welche Benutzergruppen welche Anwendungen mit welchen Geräten verwenden, oder ob es um Web-fähige Anwendungen geht und welche Techniken die Anwendungen für die Authentifizierung und Autorisierung bereits unterstützen. Daneben sind natürlich noch die allgemeinen Strategie-, Security- und Compliance-Vorgaben des Unternehmens zu berücksichtigen.
Spätestens wenn Unternehmen einzelne Anwendungen in die Cloud transferieren, neue Anwendungen in der Cloud realisieren oder SaaS/PaaS/IaaS-Angebote von Cloud-Anbietern anbinden wollen, bemerken sie, dass sie nicht mehr so einfach auf die bewährten Verzeichnisdienste zurückgreifen können. Diese Multi-Cloud-Umgebung mit klassischen Mitteln zu bedienen ist im Grunde genommen nicht vollumfänglich möglich.
Hier bieten sich Lösungsansätze wie Federation-Services und Claim-based Identities an. Bei Bedarf lassen sie sich durch Erweiterungen wie Mehr-Faktor-Authentifizierung ergänzen, ohne die Eingabehürden für den Benutzer in unakzeptable Höhen zu treiben. Der Benutzer aus einer Partnerfirma könnte sich so am Warenwirtschaftssystem über seine gewohnte Benutzerkennung authentifizieren.
Für weitere Autorisierungsentscheidungen würde die lokale, aber auch die Cloud-basierte Anwendung die erforderlichen Benutzerattribute (Abteilung, Standort oder Rolle) direkt zur Verfügung gestellt bekommen. Technisch gesehen funktioniert dies durch die Nutzung von Security Tokens, die auf der einen Seite eine erfolgreiche Authentifizierung bestätigen und auf der anderen Seite alle relevanten Benutzerinformationen zur späteren Zugriffsentscheidung durch die Anwendung umfassen.
 
Lokales IAM trifft AAA-Mechanismen
Cloud-Service-Anbieter wie Microsoft mit Office 365, Amazon Web Services (AWS) oder Salesforce setzen zur Nutzung ihrer Angebote generell erfolgreiche Authentifizierungen voraus. Diese und viele weitere Cloud-Services unterstützen eine Integration in SSO-Infrastrukturen. Zur Integration dieser Dienste in ein vorhandenes IAM-Umfeld bestehen verschiedene Lösungsansätze, die sich im Leistungsumfang und vor allem im Benutzerkomfort unterschieden. Eine Möglichkeit ist die Bereitstellung (Provisionierung) und Synchronisation von Benutzer- und Passwortinformationen zwischen der Cloud-Umgebung und der lokalen Infrastruktur, die für die Authentifizierung, Autorisierung und Abrechnung sorgt. Abhängig vom Anbieter stehen für diese Aufgabe bereits vorgefertigte Lösungen zur Verfügung, die man mit wenigen Konfigurationsschritten in Betrieb nehmen kann.
Die Zukunft liegt allerdings in der Identity Federation, also der organisationsübergreifenden Nutzung zentraler Identitätsinformationen zum Zweck der Authentifizierung und Autorisierung an Anwendungen und Cloud-Services. Konkret bedeutet dies, dass die AAA-Mechanismen auf Identitäts- und Passwortinformationen der Unternehmens- oder auch Cloud-Verzeichnisdienste wie Azure AD, Facebook oder Yahoo vertrauen. Dies hat den Vorteil, dass es eine Synchronisation und Mehrfachspeicherung von schützenswerten Daten vermeidet.
Genau genommen hat diese Zukunft schon begonnen, denn die Lösungskomponenten solcher Verbunddienste, wie Federation-Services auf Deutsch auch heißen, sind heute bereits im Standard-Produktportfolio namhafter Hersteller wie Microsoft enthalten, zum Beispiel in Windows Server ADFS (Active Directory Federation Services) sowie deren in Azure AD integrierten Pendants.
Weitere Gründe, die für ein Cloud-basiertes Verzeichnis sprechen, sind die teilweise vorkonfigurierten Federation-Services zu vielen namhaften SaaS-Anbietern sowie bereits integrierte Möglichkeiten für Mehr-Faktor-Authentifizierungen, umfangreiche Compliance-Reports sowie die Bereitstellung von Self-Service für Benutzer. Sofern die Anforderung besteht, externe Benutzerkonten zu verwalten, weil Federation-Services nicht verwendbar sind, empfiehlt sich die Nutzung von Cloud-basierten Verzeichnissen.
Inwiefern man auf eine reine Identity Federation setzen kann oder doch weiterhin die Synchronisation von Identitätsinformationen erforderlich sein wird, lässt sich nicht pauschal sagen. Welches Vorgehen richtig ist, hängt von den Anforderungen der jeweiligen Anwendungen selbst ab. Bei all diesen technischen Überlegungen dürfen allerdings die finanziellen Auswirkungen nicht außer Acht gelassen werden. Abhängig vom geforderten Funktionsspektrum können sich die Einzelpreise jeden Monat zu sehr unterschiedlichen Gesamtkosten addieren.
 
Lokales AD oder Cloud-basierte Services?
Trotz des unübersehbaren Trends hin zu Cloud-Identitäten werden Verzeichnisdienste wie Windows Server Active Directory noch lange Bestand haben. Grund hierfür ist der erweiterte Funktionsumfang wie das bekannte Kerberos-, NTLM- oder auch LDAP-Protokoll zur Authentifizierung und Autorisierung von Benutzern und Systemen sowie das Management von Benutzerrechten und Systemkonfigurationen mittels Gruppenrichtlinien.
Das heißt konkret: Solange Systeme und Legacy-Anwendungen moderne Protokolle wie OAuth 2.0 oder SAML (Security Assertion Markup Language) nicht unterstützen und klassische Domänenmitgliedschaft erfordern, ist ein Windows Server Active Directory erforderlich. Diese können wie gewohnt in Form bekannter lokaler Installation oder als ergänzende IaaS-basierte Domänen-Controller bereitstehen. Als Alternative bietet Microsoft nun die Azure Active Directory Domain Services, also Windows Active Directory as a Service. Der Leistungsumfang ist vergleichbar mit den gewohnten Active Directory Services, verbunden mit den bekannten Vorteilen von Cloud-Lösungen. Demzufolge entfallen die klassischen Betriebsaufgaben wie Monitoring, Patching, Backup und zeitaufwendiges Troubleshooting von Replikationsfehlern.
 
Abwarten oder aktiv werden?
Aus verschiedenen Gründen werden sich nicht alle Legacy-Anwendungen kurz- oder mittelfristig auf moderne Protokolle umstellen lassen. Langfristig sollte dennoch die strategische Ausrichtung eine entsprechende Veränderung im Zuge der Anwendungs-Lifecycles vorsehen. Langfristiges Ziel ist eine Konsolidierung der Protokolle auf sichere Verfahren, Erhöhung der Endbenutzer-Produktivität und Erfüllung neuer Geschäftsanforderungen.
Bei der Suche nach geeigneten Identity-Federation-Lösungen im Unternehmenseinsatz stehen diverse Themen auf der Prüfliste, darunter die unterstützen Standards und Protokolle, aber auch die Dynamik des Anbieters. Denn besonders im Cloud-Umfeld findet eine rasend schnelle Entwicklung statt, und diese will auch entsprechend kurzfristig in den Herstellerlösungen abgebildet sein. Mittlerweile sind Protokolle wie SAML 2.0 und WS-Fed etablierte Standards für die Authentifizierung und Autorisierung an Web-Anwendungen. Hinzu gekommen sind neue Protokolle wie OAuth 2.0 unter anderem für die Kommunikation der Anwendungen untereinander über Schnittstellen wie RESTful APIs (Representational State Transfer).
Besonders im Bereich mobiler Anwendungen oder auch IoT-Szenarien (Internet of Things) wird OAuth 2.0 eine wichtige Rolle spielen, sofern nicht zwingender Bedarf für den Einsatz von SAML besteht. Damit die Anwendungsentwickler die volle Bandbreite verfügbarer Mittel im Bereich der Authentifizierung und Autorisierung ausschöpfen können, werden stets aktuelle lokale Infrastrukturen für Identity und Federation oder entsprechende Cloud-Services vorausgesetzt. Entsprechend valide gepflegte Benutzerattribute sind dafür natürlich eine unabdingbare Voraussetzung, sofern man neben der Authentifizierung auch moderne Autorisierungsmethoden nutzen will.

Single Sign-on ist auch für SaaS-Angebote möglich. Bild: Microsoft

Ähnlich einem Türsteher erstellt der Security-Token-Service einen "Ausweis", der die verschiedenen Angaben (Claims) eines Gastes beinhaltet. Auf dieser Basis fallen spätere Zugriffsentscheidungen in den Systemen und Anwendungen. Bild: Fritz & Macziol

Lesen Sie mehr zum Thema


Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu Yes Telecom Germany GmbH

Weitere Artikel zu CITEL Electronics GmbH

Weitere Artikel zu Extreme Networks

Weitere Artikel zu CPA Computer Process Automation GmbH

Matchmaker+