Security in der Cloud
Sicher in und mit der Wolke arbeiten
Die Cloud verspricht viele Vorteile, aber es halten sich auch hartnäckige Gerüchte um verheerende Sicherheitslücken. Mit den richtigen Konzepten, Architekturen und Softwarelösungen lassen sich diese jedoch minimieren, und Unternehmen profitieren gleichzeitig mehrfach von der neu gewonnenen Sicherheit.
Cloud-Computing ist in aller Munde – verständlicherweise, denn dieses Architekturkonzept scheint
nun endlich die Versprechen einzulösen, die die Hersteller mit unterschiedlichen Ansätzen zu
verteiltem Rechnen, ebensolcher Datenhaltung und einem verteiltem Dienstangebot schon seit Jahren
immer wieder geben. Ein wesentlicher Grund für diesen Optimismus ist die Tatsache, dass nun endlich
ausreichend erprobte Standards für die Kommunikation, Integration, Interaktion und
Interoperabilität vorhanden sind. Weiterhin existiert der Zwang, die bestehende Infrastruktur mit
ihren Diensten kostengünstig zu erweitern und diese sinnvoll auszulasten.
Allen Vorteilen, die auf technischer oder geschäftskritischer Ebene existieren, steht das
kaum kalkulierbare Bedrohungspotenzial gegenüber: Eine unzureichende Sicherheitsarchitektur im
Unternehmen kann dafür verantwortlich sein, dass (sensitive) Daten und Prozesse auf Knopfdruck
ungewollt buchstäblich um die Welt reisen können – und dafür, dass Eindringlinge von überall her
bis ins Allerheiligste eines Unternehmens vordringen. Daher ist eine Betrachtung der Gefahren, des
Risikos, der Risikominimierung und der sich ergebenden Bewertung des Nutzens unabdingbar.
Cloud-Kategorien: Public, Private, Hybrid
Um eine grobe Abschätzung des Bedrohungspotenzials zu gewinnen, ist zunächst eine
Kategorisierung der verschiedenen Cloud-Ansätze hilfreich: Stellt man als erstes die "private" der "
öffentlichen" Cloud gegenüber, so werden in Analogie zu Intranet und Internet gut die
unterschiedlichen Risikogrößenordnungen klar. Aber auch bei dieser Analogie ist der Vergleich
Intranet gleich "sicher" eine gefährliche Sichtweise.
Die Sicherheitsrelevanz lässt sich gut an einem Beispiel darstellen: Bei dem Modell der
öffentlichen Cloud lässt sich prinzipiell nicht exakt festhalten, aus welcher Quelle die
angebotenen Dienste oder deren Teile stammen. Dies bedeutet, dass zwar der primäre Dienstanbieter
bekannt ist, jedoch dieser wiederum auf weitere Anbieter zurückgreift. Auch brisant ist, welche
Daten an diese weitergeleitet werden. So bietet beispielsweise ein Dienst zur
Fahrtroutenermittelung eine integrierte Wetterdatenvorhersage für Start- und Zielorte. Beide
Dienste sind kostenpflichtig. Welche für die Abrechnung benötigten Daten werden von wem benötigt.
Wer ist der Eigentümer dieser Daten? Ist eine Korrelation verschiedener Daten möglich, und wie
sieht das mögliche Ergebnis aus?
Eine funktionale Erweiterung kann zum Beispiel die Auslagerung der Datenhaltung innerhalb
einer privaten oder öffentlichen Cloud darstellen. Offensichtlich ergeben sich hier
Herausforderungen für die Datensicherheit, Vertraulichkeit, Speicher-Management und Backup-Konzepte
inklusive Schlüsselverwaltung, jedoch dürfen juristische Bestimmungen, die etwa länderübergreifende
Richtlinien umfassen, nicht vernachlässigt werden. Dürfen personenbezogene Daten über Ländergrenzen
hinweg verteilt werden? In Abhängig von der Rechtslage des betreffenden Landes sind für die Daten
eventuell ganz unterschiedliche Regelungen für den Datenschutz vorgesehen, also etwa für den
Zugriff der Behörden auf diese (sensitiven) Daten.
Befindet sich die Infrastruktur dagegen komplett innerhalb eines Unternehmens, dann spricht
man von einer privaten Cloud. Jedoch kann auch diese länderübergreifend implementiert werden,
wodurch sich die bereits angesprochenen rechtlichen Fragen ergeben. In Abhängigkeit der Nutzung des
Cloud-Dienste-Angebots kann sie eventuell nur bedingt von der Mächtigkeit des Konzepts profitieren.
Eine gute Balance soll die zuvor erwähnte Hybrid Cloud als Mischmodell aus beiden Ansätzen bieten.
Um es anwenden zu können, bedarf es einer Datenklassifizierung und Separation der Daten (Stichwort:
Data Segregation) in für die öffentliche Cloud geeignete und ungeeignete. Dies ist zwar kein
triviales Problem, aber eines, das im Prinzip bei jeder Form von Outsourcing gelöst werden muss.
Identitäts- und Access-Management in der Wolke
Zu den wichtigsten Security-Aufgaben im Umfeld von Cloud-Computing gehört die Regelung der
Benutzeridentitäten und die der Zugriffsrechte. Eine sinnvolle Lösung gelingt nicht ohne eine
vereinbarte Granularität der Rechte und deren Vergabe, was einen nicht unerheblichen Aufwand für
die Definition der Benutzerrollen, -gruppen und deren Verwaltung nach sich zieht. Außerdem besteht
der Zwang zur Aktualität: Sowohl die Nutzerinformationen als auch deren Gruppierungen müssen in
Abhängigkeit der angebotenen, sensitiven oder kostenintensiven Dienste eine hohe Aktualität
aufweisen. Und sei es nur, um so genannten Ghost Usern, also den Karteileichen, den Zugang zu den
Systemen zu verwehren oder einen Missbrauch durch "vernachlässigte" Kontendaten zu vermeiden.
Es liegt auf der Hand, dass die Realisierung eines umfassenden Identitäts-Management am
besten mit Lösungen gelingt, die auf der einen Seite selbst in ein unternehmensübergreifendes
Sicherheitskonzept integrierbar sind, und zwar architektonisch und funktional, und die auf der
anderen Seite sinnvolle und erforderliche Einzelfunktionen mitbringen und abbilden, um gleichzeitig
eine Minimierung der Einzelkomponenten sicherzustellen Wie viele Forderungen gilt dies selbstredend
für jede Form eines Enterprise-Security-Konzepts, verschärft jedoch für Cloud-Sicherheit. Aus dem
Haus IBM/Tivoli kommen zu diesem Zweck beispielsweise die Tivoli Access Manager Produktfamilie, der
Tivoli Identity Manager (TIM) und der Tivoli Federated Identity Manager (TFIM). Eine Software im
Stile eines Access-Managers fungiert gewissermaßen als oberste Instanz für das Zugriffs-Management,
indem sie das Durchsetzen von Sicherheits-Policies (Richlinien) auf Web-basierende Ressourcen
ausdehnt (Bild 1). Dazu gehören unter anderem die Validierung von User-Identity-Informationen, die
Authentifizierung und Autorisierung innerhalb der Cloud.
Geht man davon aus, dass in einer beliebig verteilten Service-Cloud keine zentrale
Benutzerdatenquelle besteht oder dies aus gesetzlichen Gründen gar nicht möglich ist, so muss die
Forderung nach der (ausschließlich) benötigten Benutzerinformation durch eine entsprechende
Provisionierungs- und Benutzer-Management-Lösung zufriedenstellend gelöst werden. Denn nur dadurch
lässt sich eine effiziente Verwaltung bei gleichzeitiger Sicherstellung der erforderlichen
Informationen für Authentifizierung, Autorisierung und Accounting sicherstellen.
Abhängig von Verteilung, Anzahl der Diensteanbieter, des Angebots und der Nutzung ist der
Einsatz mehrerer so genannter IDM-Systeme eine sinnvolle, aber nicht einfach zu lösende
Herausforderung. Im Gegensatz dazu steht die Lösung für eine private Cloud, deren Benutzer von nur
einer IDM-Instanz verwaltet werden. Eine häufig angestrebte Reduktion der Komplexität soll sich
durch Konsolidierung der Identitäts-Pools durch eine zentralisierte Datenhaltung in Verbindung mit
dem Identitäts-Management erzielen lassen. Dies wird sich jedoch in einer Cloud auf Grund der
Verteilung und auch aus rechtlichen Gründen des Datenschutzes nur begrenzt umsetzen lassen.
Werden moderne, serviceorientierte Architekturen (SOAs) umgesetzt, dann lassen sich
Vertrauensbeziehungen zwischen verschiedenen Geschäftsdomänen mithilfe des Federated Identity
Managers verwirklichen (Bild 2). Ein großer Vorteil: Für den Anwender lässt sich dieselbe
Zugangsmethode (Authentifizierung und Autorisierung) sowohl für Cloud- als auch für verteilte
SOA-basierende Anwendungslandschaften nutzen, für ihn ist die Abbildung des Dienstangebots
transparent. Der TFIM stellt dazu die Funktionalität basierend auf offenen Standards zur Verfügung.
TFIM, eine J2EE-Anwendung, arbeitet ebenfalls in der Architektur eines Servicemodells, das auf dem
Websphere-Applikations-Server basiert. Die Konnektivität mit der Windows-Welt ist über die
Integration in Microsoft Dotnet gegeben. Die Software nutzt dazu ein Kerberos-Token-Modul. Wichtig
ist im angestrebten Einsatzumfeld auch eine Anbindungsoption an Mainframe-Umgebungen. Dazu dient
ein RACF-basierender Zugriff. Weiterhin sind implementiert: SAML (Security Assertion Markup
Language), Liberty ID-FF, Webservice Federation, Web-Service Provisioning und
Web-Services-Trust-Spezifikationen für Federated Single Sign-on. Bemerkenswerterweise kann ein
einzelnes TFIM-System all diese Standards gleichzeitig unterstützen.
Datenaustausch in der Wolke
Aus den genannten Argumenten geht klar hervor, dass die Betrachtung der Sicherheit, wie sie
für traditionelle Architekturen gefordert ist, beim Cloud-Computing stets um die Komponente "
Datenaustausch" zwischen den Cloud-Komponenten und den Teilnehmern (Dienstanbieter, Dienstnutzer)
erweitert werden muss. Es genügt zudem nicht, den Service-Provider als vertrauenswürdig
einzustufen; vielmehr gilt es, den gesamten Prozessablauf des Informationsaustauschs und soweit
erforderlich bis hin zur Kapselung des Dienstes zu kennen und in der Lage zu sein, diesen auf
Konformität hin zu überwachen.
Security-Checkliste für Cloud-Computing
- Die Marktforscher von Forrester Research haben einen umfangreichen Fragenkatalog
zusammengestellt, mit dessen Hilfe Unternehmen den Sicherheitsstatus ihres Providers bewerten
können. Hier die wichtigsten Punkte im Zusammenhang mit Datensicherheit sowie Identity- und
Access-Management: - Wie ist die Trennung meiner Daten von den denen anderer Kunden realisiert?
- Wo sind meine Daten gespeichert?
- Wie ist der Zugriff auf die Daten und die User-Authentifizierung geregelt?
- Auf welchem Weg gelangen die Daten aus unserem Unternehmen zum Provider?
- Wie transportiert der Provider die Daten weiter?
- Können Dritte (zum Beispiel weitere Diensteanbieter) auf die Daten zugreifen?
- Besteht die Möglichkeit zu einem Sicherheits-Check für das Provider-Netzwerk durch unser
Unternehmen? - Wie häufig führt der Provider solche Checks durch?
- Wie sichert der Provider User-IDs und Credentials?
- Wie organisiert der Provider das Anlegen und Löschen der Benutzerkonten?
- Unterstützt der Provider Single Sign-on, und wenn ja, nach welchen Standards?
- Unterstützt der Provider Federation, und wenn ja, nach welchen Standards?
- Kann der Provider garantieren, dass durch Logs keine kritischen Informationen an Dritte
gelangen?
Suzan Aydin ist Market Manager Tivoli bei IBM Deutschland.
Lesen Sie mehr zum Thema
