Sicherheit in Cloud-Szenarien
Grenzen für eine grenzenlose Welt
Bei allen Vorteilen stellt die Cloud die Nutzer und Anbieter von öffentlichen, privaten und hybriden Cloud-Konfigurationen vor die wohlbekannten Herausforderungen in Sachen Sicherheit. Die IT muss dieser Entwicklung Rechnung tragen und ihre Schutzmaßnahmen mit Blick auf das zusätzliche Gefährdungspotenzial schärfen.
Cloud-Services stehen für ein bahnbrechendes IT-Konzept, das eine höhere Flexibilität und Skalierung zu besseren Preiskonditionen verspricht. Damit erhält die Unternehmens-IT zwangsläufig einen immer offeneren Charakter. Die einst scharfe Grenzziehung zwischen innen und außen ist mehr und mehr in Auflösung begriffen. Konsequenterweise nimmt die IT-Sicherheit eine prominente Rolle ein, wenn in Unternehmen der Einsatz von Cloud Computing diskutiert wird. Das ist einerseits richtig, denn mit den unterschiedlichen Cloud-Szenarien gewinnt das Thema Sicherheit neue Facetten. Andererseits wird die Diskussion in der Regel zu einseitig mit Fokus auf die Vertrauenswürdigkeit des Cloud-Providers geführt. Dabei vernachlässigen die Unternehmen gerne, dass die eigenen Mitarbeiter eine große Schwachstelle für die Sicherheit sind: zum einen mit krimineller Energie, wie die vielen Meldungen über Datendiebstähle vor Augen führen, zum anderen durch Schludrigkeit, indem man einfachste Sicherheitsregeln ignoriert. Die Security-Regel Nummer eins lautet daher: Unternehmen müssen dem Thema Sicherheit die gebotene Aufmerksamkeit und Sorgfalt entgegenbringen – unabhängig davon, ob sie IT-Leistungen aus interner oder externer Quelle beziehen. Was bedeutet dies für das Cloud Computing? Grundsätzlich drohen beim Bezug von IT-Leistungen aus der „Wolke“ die identischen Sicherheitsrisiken und Angriffsszenarien, mit denen sich Unternehmen bereits in traditionellen IT-Infrastrukturen befassen müssen. Im Vergleich zum herkömmlichen Betrieb liegt die Verantwortung allerdings nicht mehr ausschließlich bei der eigenen IT-Organisation. Je nach Liefermodell oder Service-Konzept teilen sich Unternehmen die Kontrolle nun mit dem Cloud-(Service-)Provider oder geben sie gar zum überwiegenden Teil ab. Im Fall einer Public oder Hybrid Cloud kommen die Risiken einer gemeinsam genutzten Infrastruktur hinzu. Auch kann die Cloud sehr undurchsichtig sein. Mitunter haben Unternehmen geringen oder überhaupt keinen Einblick, wie und wo der Service bereitgestellt wird und wer ihn kontrolliert. Es ist gut möglich, dass ein Service aus einem Mashup mehrerer Dienste von mehreren Anbietern besteht, die zudem physisch in verschiedenen Rechenzentren an unterschiedlichen Standorten gehostet werden. Eine enorme Herausforderung für Unternehmen beim Wechsel zum Cloud Computing besteht im Verlust der direkten Kontrolle. Denn traditionellerweise gehen Prozeduren zur Risikovorsorge vom physischen Zugriff auf Anwendungen und Systeme aus. In der Cloud löst sich mit der Virtualisierungstechnik das „Meine Server, meine Speicher, meine Anwendungen“-Gebahren jedoch auf. Schon in einer im Unternehmen selbst betriebenen Private Cloud lässt sich nicht mehr ohne Hilfsmittel feststellen, wo eine Anwendung physisch arbeitet oder untergebracht ist. Sowohl Benutzer als auch Anbieter von Cloud-Diensten müssen neue Antworten auf die bekannten Fragen zur Autorisierung, Authentifizierung und Zugriffsrichtlinien als auch zu Kontrolle und Compliance-Management finden.
IAM ist unerlässlich
Unabhängig von dem Betreibermodell der Cloud rückt das Management von Identität und Zugriff in den Mittelpunkt. Ausbau und Funktion hängen dabei eng mit der „Art“ der Lieferung zusammen. Der Grund für die große Bedeutung des Identity- and Access-Managements (IAM) ist offensichtlich: Poolt man Ressourcen, sollte die Nutzung in geordneten Bahnen verlaufen. IAM verspricht zum einen, Benutzer und deren Zugriffsrechte für IT-Services effizient und kostengünstig zu verwalten. Zum anderen ermöglicht es, in Kombination mit dem Rollen-Management den verschärften Compliance-Anforderungen bezüglich Berechtigungszertifizierung oder Aufgabentrennung nachzukommen. Eine Private Cloud räumt Unternehmen fraglos die größte Kontrolle ein. Sie lässt sich im Grunde in vielen Punkten mit dem gewohnten Eigenbetrieb vergleichen. Der vermeintlich einfache Umstieg darf jedoch nicht zu Sorglosigkeit führen. Für die Benutzerverwaltung mag in den meisten Fällen die Active-Directory-Basis zunächst vollkommen ausreichen. Aus Compliance-Sicht sind mitunter weitere Fähigkeiten gefragt. Wenn beispielsweise Test- und Produktionssysteme nicht zusammen auf einem Server laufen dürfen, muss die Virtualisierungstechnik eine vergleichbare Separation vorweisen. Und wenn Ressourcen nicht zwangsweise an eine bestimmte physische Basis gebunden sind, sieht der zugeordnete Server-Administrator vielleicht Anwendungen und Daten, für die er keine Berechtigung besitzt und haben darf. Im Falle eines IaaS- oder PaaS-Providers (Infrastructure/Platform as a Service) fällt der Administratorenpunkt doppelt ins Gewicht. Es gibt schließlich Benutzer auf Anwenderseite, die administrative Berechtigungen für die gebuchten IaaS/PaaS-Leistungen besitzen, zudem aber wie gewohnt Verwalter auf Provider-Seite, die sich um die operativen Aufgaben kümmern. Als Service-Bezieher möchte man nun sichergestellt sehen, dass der Anbieter die Integrität und Vertraulichkeit der gespeicherten, verarbeiteten und übertragenen Daten und Anwendungen gewährleistet. Der Provider selbst hat aus eigenen Schutzbedürfnissen heraus gleichfalls ein hohes Interesse an funktionierenden Mechanismen für die Mandantentrennung. Denn wenn einmal der Zugriff auf den Host erfolgreich war, steht das Tor zu den virtuellen Maschinen (VMs) für den unerwünschten Besucher weit offen. Dies führt fraglos zu hohen Anforderungen an eine IAM-Umgebung, die mehr können muss als ausschließlich Identitäten und Rollen zu provisionieren. Sie sollte zusätzlich die Aufgaben der Rollenbildung („Role Mining“) als auch zur Analyse von Interessenkonflikten („Segregation of Duties“, SoD) unterstützen, um ein verlässliches Identitäts-Management zu institutionalisieren. In der Rollenmodellierung („Role Engineerung“) werden dabei, ausgehend von der Ist-Analyse der Zugriffsrechte, in einer Art Reverse Engineerung die Benutzerberechtigungen gruppiert und im Anschluss zu einer Rolle „normalisiert“. Dazu zieht die IAM-Software über LDIF (LDAP Data Interchange Format), CSV (Comma-Separated Values) o.ä. auch Informationen aus anderen Verzeichnissen heran, um die (Benutzer-)Identität mit Berechtigungen in Beziehung zu setzen. Intelligente Data-Mining-Techniken zur Mustererkennung und -analyse unterstützen den Prozess, geeignete Kandidaten zu identifizieren. Verstoßen diese Kandidaten gegen eine Richtlinie, unterbindet eine solche IAM-Lösung automatisch den Provisionierungsprozess. Compliance-Anforderungen lassen sich auf diesem Weg vorausschauend verwalten. Zu einem vollständigen IAM-Konzept mit hoher „Public-Cloud-Tauglichkeit“ zählt eine Rechtetrennung und Server-Härtung im Access-Management, um mit einem differenzierten Super-User-Management im administrativen Bereich den Compliance-Anforderungen zu genügen. Elementarer Bestandteil eines solchen Privileged-User-Managements (PUM) sind sehr fein justierbare Zugriffskontrollen. Sie sorgen beispielsweise dafür, dass ein Administrator nur die Zugriffsrechte erhält, die er genau für seine Arbeit benötigt, oder dass ein Auditor sieht, welcher Superuser sich wann eingeloggt und was er genau getan hat. In Kombination mit der Kontrolle über den Zugriff auf die virtuellen Ressourcen lässt sich ein dynamisches Policy-Management einrichten, das dabei hilft, effizient und regelbasiert Berechtigungen zum Beispiel über zeitlich befristete oder Einmal-Passwörter einzurichten und zu kontrollieren. Je nachdem, um welche Kategorie von Services es sich handelt, die ein Unternehmen über eine Public Cloud bezieht, unterscheiden sich die Anforderungen und die Verortung des Privileged-User-Managements auf Anwenderseite. In IaaS-Szenarien bleibt die Verantwortung für Programme oder Daten beim Anwender, während der Anbieter die physischen Ressourcen unterhalb der virtuellen betreut. Die Verwaltung der Konten der Betriebssystem- oder Datenbankadministratoren bleibt folglich in der Verantwortung des Anwenders. Dagegen gibt ein Unternehmen mit SaaS (Software as a Service) die Kontrolle nahezu vollständig aus den Händen. Um den regulatorischen Pflichten nachzukommen, bleibt dem Anwender wenig anderes übrig, als geeignete organisatorische und vertragliche Absprachen mit dem Provider zu treffen. Denn ein Austausch der PUM-Informationen und Richtlinien, wie er in den Public-Cloud-Szenarien ideal wäre, lässt sich heute noch nicht vollständig automatisiert umsetzen. Für den Public-Cloud-Anbieter ist der PUM-Einsatz in jedem Fall empfehlenswert. Es hilft ihm, die Ressourcen im Mandanten- oder Mehrinstanzenbetrieb zu härten und abzusichern. PUM dient hier zudem als vertrauensbildende Maßnahme, da der Provider über Kontroll- und Protokollierungsfunktionen in regelmäßigen Abständen Sicherheitsberichte für Kunden erstellen kann.
Berechtigungsnachweise
Im Vergleich zu den Autorisierungsaspekten privilegierter Nutzerkreise bietet IAM heute bereits eine Reihe bewährter Verfahren für die Authentifizierung, die von dritter Seite akzeptiert und durchgeschleust werden. Im Groben verwaltet ein Identity-Provider (Identitätsanbieter) als vertrauenswürdige Komponente Authentifizierungsattribute und stellt Berechtigungen aus. Konsument dieser Identitätsinformationen ist die angeforderte Ressource einer Domäne (Service-Provider), die den Nachweis zu Rollen und Gruppenzugehörigkeit als „Schlüssel“ zur Nutzung der gewünschten Ressourcen akzeptiert. Die wichtigsten Standards für ein übergreifendes Single Sign-on (SSO) und dem Austausch von Identitätsattributen sind SAML (Securit Assertion Markup Language) oder – mit einigen Abstrichen – WS-Federation (Web Services Federation). Der Einsatz von Identity Federation ist immer dann von Nutzen, wenn Unternehmen ihre Anwendungen und Daten von lokalen Computern in die öffentliche „Wolke“ migrieren.
Lesen Sie mehr zum Thema
