Geschützter Zugriff mit WS-Federation-Services
Sicherheit in der Public Cloud
Viele Unternehmen verzichten auf die Public Cloud, da sie sich um die Sicherheit sensibler Daten sorgen. Aktuelle Lösungen auf Basis von WS-Standards können diese Bedenken ausräumen. Sie ermöglichen einen einfachen, übergreifenden Zugriff auf verschiedene Angebote.Für B2B-Anwendungen sind Public Clouds aufgrund der hohen Sicherheitsanforderungen meist tabu. Dabei bieten sie auch hier zahlreiche Vorteile. Zum Beispiel lassen sich Daten einfacher zwischen Unternehmen austauschen, die Zusammenarbeit wird deutlich effizienter. Vor allem bei Unternehmen aus der gleichen Branche bietet die Cloud ein hohes Rationalisierungspotenzial. Dies funktioniert zum Beispiel bereits in den Bereichen Automotive, Versicherung oder Energieversorgung. Durch firmenübergreifende Web-Anwendungen lassen sich Projekte, Tätigkeiten, Abteilungen oder Geschäftszweige, die nicht zum Kerngeschäft gehören, auslagern und über gemeinsame Schnittstellen nutzen. Hier kommen auch Dienstleister als eine Art Treuhänder ins Spiel, indem sie als neutrale Stelle für den übergreifenden Zugang sorgen. Doch wer darf mit welchen Rechten auf welche Anwendungen und Daten zugreifen? Der Benutzerkreis ist zunächst durch eine strenge Authentisierung einzugrenzen. Bislang wird dies überwiegend manuell erledigt. Die Basis bildet meist das im Unternehmen als Anmeldestruktur genutzte Active Directory. Die darin gespeicherten teils persönlichen oder geschäftskritischen Benutzerdaten möchte ein Unternehmen aber keinesfalls vollständig mit anderen Firmen oder gar Wettbewerbern teilen, oft dürfen sie dies aufgrund des Datenschutzes auch nicht. Die zur gemeinsamen Nutzung von Services notwendigen und freigabefähigen Mitarbeiterdaten sind dann einzeln auszuwählen und anschließend zum Provider zu übertragen. Dazu dienen oft selbst entwickelte Anwendungen, die jedoch selten aktuellen Sicherheitsstandards entsprechen. Zudem sind Änderungen in der Mitarbeiterstruktur ständig zu aktualisieren und erneut zu übertragen. Wenn jedoch eine gemeinsame Nutzung von Anwendungen einen so hohen Einrichtungs- und Management-Aufwand erzeugt und dabei auch noch so wenig Sicherheit gewährleistet, wie günstig ist dann die Cloud-Anwendung tatsächlich? Bei dieser Überlegung stellen Unternehmen in der Regel fest, dass eine Auslagerung unwirtschaftlich ist und die Nachteile deutlich größer sind als die möglichen Vorteile. "Federation Trust": Vertrauen = Vertrag Die erstmalige Festlegung der freizugebenden Daten und Rechte wird wohl bis auf Weiteres manuell erfolgen, da hier strenge Sicherheits- und Datenschutzrichtlinien zu beachten sind. Zudem ist erst eine Vertrauensbeziehung zwischen Unternehmen und Cloud-Anbieter oder zwischen den Unternehmen notwendig. Ein entsprechendes Abkommen regelt, welche Rollen anzumelden und welche Identitäten nachzuweisen sind sowie wohin Benutzerdaten geschickt werden. Bei Applikations- oder Unternehmensverbünden ließe sich dies in Zukunft aber zentral regeln, wodurch eine automatische Freischaltung weiterer Cloud-Services erfolgen würde. Bislang müssen die Beteiligten jedoch erst die Rahmenbedingungen abklären. Für die Anmeldung gilt es, einen gemeinsamen Standard sowie gemeinsame Schlüsselsätze für die elektronische Signatur zu definieren. Die entsprechende Festlegung erfolgt über ein Federation-Protokoll. Durch einen "Federation Trust" werden die Rollen und Rechte mit dem Partner vereinbart und auf der Zielseite in lokale Rollen und Rechte umgewandelt. Die Übertragung der persönlichen Daten erfolgt über eine verschlüsselte und signierte XML-Datei. Die IT-Abteilung muss daher Signaturen nicht mehr auf das ganze Unternehmen ausrollen, das Vertrauen beschränkt sich auf die Anmelde-Server (Secure-Token-Services). Von diesem Schlüsselaustausch sind die Server und Clients dann nicht mehr betroffen. Große Rollouts wie zur Jahrtausendwende im PKI-Sektor sind nicht zu erwarten. Das Federation-Verfahren bietet zahlreiche Vorteile: Erstens authentisiert sich der Mitarbeiter im eigenen Unternehmen mit den gewohnten Mechanismen, zum Beispiel Passwort oder Active Directory. Die beim Zugriff auf die Zielanwendungen geöffneten Tickets werden dann über den Federation-Service elektronisch signiert und übertragen. Zweitens lässt sich die Sicherheits-Policy über eine zentrale Stelle durchsetzen. Der Anmelde-Server stellt fest, welche Rolle ein Partner in der jeweiligen Anwendung übernehmen kann. Drittens wird nur bestimmten Rollen und Mitarbeitern vertraut und nicht mehr allen im Partnerunternehmen. Durch vorhandene Standardmodule im Windows-Server schließlich lässt es sich schnell installieren und erfordert praktisch keine Wartung oder Administration, da die Rechte lokal vom Partner gepflegt und durch den Federation-Service übertragen werden. Der Anmeldeprozess läuft folgendermaßen ab: Nach der Anmeldung im eigenen Unternehmen wird die geschützte XML-Datei erzeugt, die Name, Gruppe und Rolle des Mitarbeiters enthält. Diese wird an den Anmelde-Server gesendet, der die elektronische Signatur prüft. Die Zielanwendung beim Service-Provider liest dann die entsprechenden Namen und Rollen aus. Dabei werden die Rollen in der XML-Datei in lokale Rollen am Anmelde-Server übersetzt. Zum Beispiel wird der "Mitarbeiter im Vertrieb" dann zum "zertifizierten Einkäufer". Auf Basis dieser Identität erhält der Mitarbeiter durch das so genannte Claim Mapping dann die zugehörigen Rechte für die Web-Anwendung. Zauberformel WS-* Für den Austausch der entsprechenden Daten steht bereits seit der Jahrtausendwende WS-* als Standard bereit, entwickelt von Oasis (Organization for the Advancement of Structured Information Standards). Er definiert unter anderem SAML-Token und SOAP-Aufrufe sowie WS-Security-Protokolle mit Signaturen und Verschlüsselung. Der Übertragungsstandard WS-Trust dient dabei zum Austausch von Identifizierungsinformationen. Das WS-Federation-Protokoll ermöglicht eine umfassende Vereinbarung bestimmter Rechte zwischen Unternehmen. Es gibt viele Anbieter von WS-Federation-Lösungen wie CA, Ping Identity, Oracle, Microsoft oder Apple. Auch Java, große öffentliche Cloud-Anbieter wie Salesforce, Produkte wie Office 365 und Sharepoint oder öffentliche Identity Provider wie Google ID, Facebook ID oder Windows Live ID unterstützen den Standard. Entsprechend sind alle diese Angebote miteinander kompatibel. Zum Beispiel kann sich ein Nutzer mit seiner Google ID auch bei dafür freigeschalteten Unternehmensdiensten anmelden. So lassen sich damit zum Beispiel der aktuelle Lieferstatus einer Bestellung abrufen oder der eigene Stromzähler virtuell ablesen. Bislang sind dazu die Anforderung und das Senden eines Passworts per E-Mail nötig. Dies ist nicht nur unsicherer, sondern auch umständlicher. Passwörter obsolet Den meisten Anwendern ist dieser Mechanismus einer "Anmeldung mit Facebook" bereits bekannt, ohne zu wissen, dass es sich um Federation handelt. Bei der Anmeldung werden sie gefragt, welche persönlichen Daten sie für welche Services freigeben und auf welche Dienste sie damit zugreifen möchten. Entsprechend überträgt die Anwendung nur die benötigten Angaben wie Name, E-Mail oder Adresse im Anmelde-Token. Bei B2B-Anwendungen erledigt der Administrator diese Vorgaben. Der Mitarbeiter merkt daher nichts von der Datenübertragung, da diese bei der Anmeldung automatisch erfolgt. Er öffnet einfach nur die Partneranwendung. Mit Federation-Services lassen sich aufwändige manuelle Authentisierungsprozesse automatisieren. Damit können sich Administratoren auf ihre Kernaufgaben konzentrieren und Unternehmen Public-Cloud-Services einfach, sicher und günstig nutzen.
Lesen Sie mehr zum Thema
