Starke Authentifizierung in Public Clouds
Föderierte Identitäten
Immer stärker verlagern die Unternehmen auch kritische Daten und Anwendungen in die Cloud. Die Absicherung der Zugänge zu Cloud-Applikationen gewinnt daher zunehmend an Bedeutung. Doch die Authentifizierung muss nicht nur zuverlässig und sicher, sondern auch praktikabel sein.Viele Unternehmen nutzen mittlerweise Public Clouds wie Amazon AWS oder Microsoft Azure und SaaS-Angebote wie Google Apps, Salesforce oder Office365 für einen Teil ihrer Anwendungen. Manche Applikationen lagern sie komplett in die Cloud aus, bei anderen dient die Cloud als Backup in einem Hochverfügbarkeitsszenario oder als zusätzliche Ressource in Spitzenzeiten. Dabei veranlassen erwartete Kosteneinsparungen, die Flexibilität und Skalierbarkeit von Cloud-Lösungen und mittlerweile auch positive Erfahrungen mit relativ unkritischen Anwendungen die Unternehmen mehr und mehr, auch kritische Daten und Anwendungen in die Cloud zu verlagern. Doch jede Wolke wirft auch Schatten. Mit der Migration kritischer Anwendungen auf Server jenseits der eigenen Firewall greifen bestehende Sicherheitsmaßnahmen plötzlich nicht mehr. Die Unternehmen haben zum Schutz ihrer Daten viel Geld und Arbeit in Firewalls, Intrusion-Detection-Systeme, Antivirenlösungen und starke Authentifizierung investiert, um nun festzustellen, dass die zu schützenden Daten plötzlich außerhalb ihres unmittelbaren Einflussbereichs liegen. Die Absicherung der in die Cloud verlagerten Daten und Anwendungen ist daher eine wichtige Komponente jedes Migrationskonzepts. Erschreckend ist daher, dass viele Cloud- und SaaS-Angebote nur einen Benutzernamen und ein statisches Passwort für die Anmeldung verlangen. Das mag allenfalls für völlig unkritische Anwendungen akzeptabel sein. In diesem Fall übernimmt der SaaS-Provider das Management der Anmeldeinformationen, was einfach und bequem ist, aber natürlich auch die unsicherste Methode. Bedenkt man zudem, dass die meisten Mitarbeiter mit identischen Passwörtern auf unterschiedlichste Anwendungen zugreifen, setzt eine solch einfache Authentifizierung auch kritischere Anwendungen einem Risiko aus, sofern diese ebenfalls über statische Passwörter zugänglich sind. Auch unter Compliance-Gesichtspunkten ist der Zugang mit statischen Passwörtern und einem externen User-Management problematisch, weil kein zentrales Logging und Reporting von Anmeldeversuchen möglich ist. Ermöglicht man den Zugang zu solchen Cloud-Anwendungen nur über das VPN, behalten alle installierten Systeme für den Perimeterschutz ihre Funktion und das Unternehmen die Kontrolle. Allerdings müssen die Anwender sich dann zweimal anmelden, einmal am VPN und einmal bei der Cloud-Anwendung, was zu Akzeptanzproblemen führt. Zudem wird diese Lösung schnell zum Alptraum der Administratoren, vor allem, wenn das Unternehmen sich dem BYOD-Trend (Bring Your Own Device) angeschlossen hat. Schließlich gilt es, auf allen zum Zugang genutzten Geräten entsprechende VPN-Clients zu installieren und zu verwalten. Zudem bedingt dieser Ansatz einen gewissen Schulungsaufwand bei den Endanwendern. Modelle der starken Authentifizierung An einer starken Mehrfaktor-Authentifizierung für Public-Cloud-Anwendungen geht also kein Weg vorbei. Grundsätzlich kann jeder Cloud- und SaaS-Anbieter eine eigene Lösung implementieren, wie es beispielsweise Microsoft mit Active Authentication jüngst für Azure eingeführt hat. Damit lassen sich nicht nur die Zugänge zu Office365 und Dynamics CRM Online absichern, sondern über ein entsprechendes SDK auch der zu eigenen auf Azure gehosteten Applikationen. Kleinere Cloud- und SaaS-Anbieter können eine solche Lösung auch selbst als Cloud-Service beziehen, um sich den Aufbau und die Verwaltung einer Authentifizierungsinfrastruktur zu sparen. Ein solcher Ansatz bietet auf jeden Fall eine deutlich höhere Sicherheit als der mit statischen Passwörtern, doch er wirft auch einige Probleme auf. Zum einen nutzen viele Unternehmen mehrere Public Clouds und Online-Anwendungen, für die sie dann jeweils einen eigenen Authentifizierungsmechanismus nutzen müssen. Zudem lässt sich die Cloud-Authentifizierung so nicht in das unternehmensweite Identity- und Access-Management (IAM) integrieren. Die Benutzung unterschiedlicher Authentifizierungssysteme für die eigene und die Cloud-Umgebung oder gar mehrere Clouds ist auf lange Sicht kaum praktikabel. Ein wesentlich günstigerer Weg zu mehr Sicherheit in der Cloud ist die so genannte Identity Federation. Ziel der Identity Federation ist es, Benutzern einer Domäne ohne ein redundantes User-Management den nahtlosen Zugang zu Daten und Anwendungen in einer anderen Domäne zu geben. Das Konzept basiert auf einem Identity Provider, der Zugang zum Directory-Service hat, die Authentifizierung der Benutzer übernimmt und mehrere Service-Provider durch Credential Mapping mit den von ihnen erwarteten Zugangsdaten versorgen kann. Auf diese Weise kann ein Unternehmen eine Single-Sign-on-Umgebung schaffen, in der ein Benutzer sich mit seinen Anmeldeinformationen am Unternehmensnetz anmelden und gleichzeitig ohne weiteren Login auch alle Cloud-Applikationen nutzen kann. Identity Federation ermöglicht dem Unternehmen, das User-Management komplett unter eigener Kontrolle zu halten und die Art der Authentifizierung unabhängig von den Cloud- und SaaS-Anbietern festzulegen und vor allem zu vereinheitlichen. Zudem erhält man auf diese Weise ein zentrales Log aller Anmeldeversuche auf internen und externen Systemen, was bei unabhängigen Login-Prozeduren praktisch unmöglich ist. Dennoch ist Identity Federation allein nicht unbedingt der sicherste Weg in die Cloud, denn wenn auch der Federation-Server oder Identity Provider sich mit statischen Passwörtern zufrieden gibt, ist bei der Anmeldung am Cloud-Service sicherheitstechnisch wenig gewonnen. Kommt Identity Federation für den Zugang zu kritischen Daten und Applikationen zum Einsatz, sollte daher der Federation-Server eine starke Authentifizierung mit Einmal-Passwörtern erzwingen. Neben dem Federation-Server ist also auch ein Authentifizierungs-Server erforderlich, wobei der Federation-Server als Radius-Client im Authentication-Server zu registrieren ist. Viele Federation-Server lassen sich dann so konfigurieren, dass sie für bestimmte Cloud-Anwendungen eine Zwei-Faktor-Authentifizierung erzwingen, während für andere ein statisches Passwort genügt. Manche erlauben auch, für spezifische Anwendungen die SSO-Funktionalität auszuschalten. Auf diese Weise kann man bei besonders kritischen Cloud-Anwendungen bei jedem Zugang eine Neuanmeldung mit aktuellem Einmalpasswort erzwingen, um die Sicherheit weiter zu erhöhen. Nutzt man Identity Federation mit Einmalpasswörtern, empfiehlt es sich, den Federation-Server in der DMZ zu installieren, da er schließlich als Proxy für die Cloud-Services dienen muss, den Authentifizierungss-Server jedoch innerhalb der geschützten Umgebung zu platzieren. Identity Federation mit starker Mehrfaktor-Authentifizierung ist eine sichere und relativ einfach zu verwaltende Lösung für alle Unternehmen, die sich den Aufbau einer IAM- und Authentifizierungsinfrastruktur erlauben können. Kleinere Anwenderunternehmen können davon jedoch nicht im gleichen Maße profitieren. Allerdings gibt es mittlerweile auch öffentliche Federation-Services, die Single Sign-on mit starker Authentifizierung bieten. Hier müssen allerdings die Anbieter vor Web-Anwendungen diesen Service aktiv in ihre Umgebung einbinden, was aber nur einen geringen Aufwand bedeutet.
Lesen Sie mehr zum Thema
