Der Datenverlust bei Twitter verleiht der Frage nach der Sicherheit von Daten in einer Cloud Dringlichkeit. Welche Maßnahmen ergreift etwa Google, wie wirksam sind sie und welche Alternativen gibt es?
Das Thema Sicherheit ist für Firmen, die sich die Nutzung von Cloud-Angeboten überlegen, der wichtigste Aspekt[1]. Die Anbieter dagegen versuchen es möglichst elegant zu umgehen. Wer danach fragt, muss sich hochgezogene Augenbrauen und den unausgesprochen Vorwurf gefallen lassen, dass er einfach nicht verstanden habe, wie die neue Welt funktioniere.
Seit ein paar Tagen ist die Kritik an den Kritikern jedoch etwas leiser geworden. Der Grund: Der Datenverlust bei Twitter[2]. Dass einer der Vorzeigefirmen des Web 2.0, die natürlich der reinen Lehre folgend konsequent auf Cloud-Angebote setzt, publikumswirksam firmeninterne Daten gestohlen und Dritten zur Veröffentlichung angeboten wurden[3], sorgte für gewaltigen Aufruhr. Google, in dessen Cloud-Angeboten die Daten lagen, fühlte sich sogar genötigt, dazu Stellung zu nehmen[4]. Da sich der Hacker mittels Techniken zur Passwortausspähung Zugang verschafft hatte, ist dieses Problem auch Dreh- und Angelpunkt der Google-Hinweise zu Schutzmaßnehmen.
Wie bei vielen anderen Diensten (und übrigens auch bei vielen Firmen) sind bei Google Mail vergessene Passwörter die häufigste Supportanfrage. Das Zurücksetzen oder Vergeben eines neuen Codes sollte natürlich so einfach wie möglich sein, andererseits muss es auch so sicher wie möglich ablaufen. Ein Spagat, der nicht immer leicht zu meistern ist. Google empfiehlt zwar beim Einrichten eines Accounts, auch eine Sicherheitsfrage auszuwählen und eine zweite Mailadresse anzugeben. Beides lässt sich aber mit genügend krimineller Energie und etwas Fleiß erraten beziehungsweise knacken.
Das scheint auch Google bemerkt zu haben. So wurden etwa Mitte Januar Möglichkeiten für Google-Apps-Kunden geschaffen[5], damit Sicherheitsverantwortliche von Firmen für die Accounts ihrer Mitarbeiter eine gewisse Passwortlänge vorgeben können und die Stärke des vom Anwender gewählten Passworts für den Administrator einsehbar ist. So kann er gegebenenfalls auf den Nachbesserungsbedarf hinweisen.
Mitarbeiter von Google-Apps-Kunden können sich kein neues Passwort von Google bereitstellen lassen. Sie müssen Änderungen jeweils mit ihrem Domain-Administrator abklären. Außerdem nutzt Google[7] bereits seit 2006 SAML[8]-Single-Sign-On, um mit Smart-Card-Anbietern und Spezialisten für Zwei-Faktor-Authentifizierungslösungen wie RSA zusammenzuarbeiten. Um diese Möglichkeiten zu nutzen zu können, sind aber seitens des Kunden gewisse Investitionen notwendig.
Fazit vieler Experten[9] daher: Der Vorfall werfe eher Fragen bezüglich der Reife von Twitter als Unternehmen auf, als Cloud-Computing als solches zu diskreditieren. Dennoch werden auch Stimmen laut[10], die nachdrücklich darauf hinweisen, dass es für einen Hacker in jedem anderen als einem Cloud-Szenario wesentlich schwieriger gewesen wäre, interne Informationen lediglich mit dem erneuerten Passwort eines Google-Mail-Accounts auszuspähen.

Eran Feigenbaum, Director of Security for Google Apps (Bild: Google).
Festzuhalten bleibt aber auch[11], dass sich Nutzer nicht einfach ändern, nur weil sich die Technologie ändert: Wer früher sein Passwort auf einem Post-It unter die Tastatur geklebt hat, wählt jetzt nicht plötzlich und freiwillig eine zwölfstellige, unaussprechliche Kombination aus Zahlen, Buchstaben und Sonderzeichen, um den Zugang zu seinem Arbeitsbereich in der Cloud zu schützen. Der Faktor Mensch bleibt auch im neuen Szenario ein Sicherheitsrisiko.
Die Übernahme von Postini[12] vor zwei Jahren war für Google nicht nur ein Schritt, um das Angebotsportfolio um Managed-E-Mail-Security und externe Spamfilterung zu erweitern. Es war vielmehr - wie sich übrigens schon kurz darauf zeigte [13] -, ein wichtiger Schritt, um den gesamten Bereich Google Apps sicherer zu machen - oder zumindest bei den Kunden mehr Vertrauen zu schaffen.
Denn im Gegensatz zu den Security-Anbietern, die seit Jahren mit neuen Features, Funktionen und Technologien gegen immer neue Bedrohungen um Kunden werben, gibt sich Google recht zugeknöpft, wenn man Details zum Sicherheitskonzept seiner Cloud-Computing-Angebote erfahren möchte.
Die Antworten klingen fast stereotyp: Allein durch die schiere Größe könne sich Google intensiver um die Absicherung der Daten kümmern, als ein einzelnes Unternehmen. Im Gegensatz zu Firmen mit ihren heterogenen Infrastrukturen besitze Google als "im Web geborene" Organisation eine homogene, leichter zu verwaltende und schneller zu patchende Infrastruktur. Audits unabhängiger Prüfer würden regelmäßig die hohe Qualität der Sicherheitsvorkehrungen und -prozesse bescheinigen.
Und immer wieder: "Wir sehen, was im Web passiert und können daher auf Bedrohungen vielfach schneller reagieren als selbst die Antiviren-Spezialisten", sowie "die Innovationsgeschwindigkeit in der Cloud ist höher, das Sicherheitsniveau daher besser". Sinngemäß argumentierte so vergangene Woche auf einer Presseveranstaltung in München auch Eran Feigenbaum, Director of Security for Google Apps.
Denkt man diese Argumentationskette konsequent weiter - und spitzt zugegebenermaßen etwas zu -, dann könnte man auch sagen, dass alle Firmen, die heute noch in teure und komplex zu verwaltende, interne Sicherheitslösungen investieren, auf dem Holzweg sind. Schließlich können sie – folgt man Feigenbaums Logik - wegen ihrer begrenzten Ressourcen nie eine so hohe Sicherheitsstufe erreichen, wie der Internetgigant. Stehen also Symantec, McAfee, Trend Micro, Checkpoint, Astaro, Watchguard und die anderen Anbieter von IT-Sicherheitslösungen für Firmen unmittelbar vor der Pleite? Auf die Frage, ob Cloud-Angebote firmeninterne Sicherheitslösungen mittelfristig überflüssig machen, kann am besten Symantec[14] eine Antwort geben. Erstens ist das Unternehmen der umsatzstärkste Anbieter in dem Segment, zweitens hat er seit der Übernahme von Messagelabs[15] selbst einer der großen[16] SaaS- und Cloud-Anbieter. War der Messagelabs-Kauf also lediglich der letzte Strohhalm, um das Unternehmen in die neue Zeit zu retten?
Patrick Heinen, Enterprise Technical Account Manager bei Symantec, sieht das natürlich anders. Er liefert aber auch einige gute Gründe für seine Meinung. "Cloud-Angebote müssen bei Firmen erst einmal Akzeptanz finden. Was im Consumer-Umfeld funktioniert und akzeptabel ist, lässt sich nicht ohne weiteres auf Unternehmen übertragen." Und für die Akzeptanz sei erst einmal wichtig, dass der schwammige Begriff "Cloud" besser definiert wird.

Patrick Heinen, Enterprise Technical Account Manager bei Symantec (Bild: Symantec).
Langfristig habe das Konzept aber schon seine attraktiven Seiten, räumt Heinen ein. "Eine Art Thin Client für den Zugriff und der Betrieb der Applikationen in einem zentralen, gut gesicherten Rechenzentrum hat durchaus Vorteile." Die Voraussetzungen dafür, stabile und redundante Verbindungen, seien heute aber noch nicht überall gegeben.
Außerdem würden die von Google zugesagten 99,9 Prozent Verfügbarkeit erstens vielen Firmen nicht ausreichen und seien zweitens Augenwischerei. Denn dazu kämen ja noch Ausfälle und Engpässe auf dem Weg zum Rechenzentrum. Insgesamt ergäben sich so Werte, die für viele Unternehmen einfach nicht akzeptabel seien.
Heinens Fazit: Alle Firmenaktivitäten in die Cloud zu verlagern, komme für die meisten Unternehmen nicht in Frage. In Teilbereichen - etwa beim Backup - sehe das dagegen anders aus. Solange aber der wesentliche Teil der Daten zumindest auch innerhalb der Unternehmens-Firewalls bearbeitet und gelagert werde, seien dafür auch Sicherheitslösungen notwendig.
Außerdem habe erst kürzlich der von Google selbst ausgerufene Native Client Security Contest[17] gezeigt, dass auch das vom Suchgiganten präferierte Konzept[18], möglichst alle Anwendungen im Browser laufen zu lassen, um sie so auch Cloud-fähig zu machen, nicht ohne Sicherheitslücken sei.
Der Gewinner des Wettbewerbs, Mark Dowd, ein Mitarbeiter der zu IBM gehörenden ISS-X-Force-Labs[19], sieht das allerdings etwas anders[20]: Zwar seien einige Sicherheitslücken gefunden worden, das sei aber normal. Aus seiner Sicht mache jeder Programmierer Fehler. Insgesamt zeigte er sich aber positiv überrascht vom Sicherheitsniveau des Google-Konzepts. Angesichts der kurzen Zeit, die das erst im Dezember 2008 als Forschungsprojekt vorgestellte Native-Client-Konzept entwickelt wird, ist Dowds Aussage als großes Lob zu werten.
Native-Client soll es Computern ermöglichen[21], Web-Applikationen vom Internet direkt herunterzuladen und dort mit derselben hohen Geschwindigkeit auszuführen wie "native" Software, die auf dem Rechner installiert ist. Zur Sicherheit untersucht Native Client Anwendungen vor dem Start und blockiert Software, die versucht, bestimmte verbotene Aktionen auszuführen. Akzeptierte Software läuft anschließend in einer Sandbox.
Programmierumgebungen für derzeitige Web-Applikationen, etwa Flash, JavaScript und ActiveX, bieten dagegen nur begrenzte Rechenleistung und bringen eine ganze Reihe eigener Sicherheitslücken mit. Sie sind damit aus der Sicht von Google eine Bremse auf dem Weg zu vollkommen Cloud-basierten Geschäftsmodellen. Weitgehend mit Cloud-basierten Angeboten arbeitende Firmen sind also weitgehend noch Zukunftsmusik. Auch wenn nicht zu übersehen ist, dass Google die bestehenden Defizite zwar nicht zugibt, aber sie im Stillen und schnell zu beseitigen versucht.
Microsoft mit seiner Azure-Plattform ist dabei zwar etwas später dran[22], hat aber auch nicht den Bonus der coolen Webcompany: Was Google viele noch verzeihen, würden sie Microsoft nie durchgehen lassen. Redmond tut daher gut daran, seien Angebote gründlicher zu prüfen und zwar etwas später, sie dafür aber voraussichtlich von Anfang an mit einem breiteren Funktionsumfang und vor allem einer tieferen Integration in die bisher schon verbreiteten Produkte aus dem eigenen Haus auszustatten.
Was aber schon funktioniert und von vielen Firmen praktiziert wird, ist die Verlagerung ihrer Mailbearbeitung in die Cloud. Vor kurzem hieß das zwar noch "Managed Mail Security Services" - im Prinzip war es aber dieselbe Dienstleistung. Genau in diesen Bereich ist Google auch mit dem Kauf von Postini eingestiegen. Weltweit zu den stärksten Mitbewerbern gehörte in diesem Segment die von Symantec gekaufte Firma Messagelabs. In Deutschland sind untere anderem Eleven[23] oder Retarus[24] in diesem Feld aktiv.
Google-Manager Feigenbaum konnte zwar bei dem Besuch in München beeindruckende Zahlen vorlegen. Beispielsweise kommen zur Google-Kundschaft täglich 3000 neue Kunden dazu. Außerdem warb er damit, dass Firmen mit einem Outlook-Plug-In[25] und neuerdings auch einem Notes-Migrationstool[26] auch gewachsene Kommunikationsgewohnheiten abbilden können. Weiter konnte Feigenbaum den Chemiekonzern Valeo[27], 15.000 Nutzer beim Lebensmittelkonzern Heinz[28] sowie den Automobilzulieferer Valeo[29] als Kunden vorweisen. Mit der Nennung weiterer deutscher Kunden tat er sich jedoch schwer.
Der Grund ist einfach: Gerade die großen Firmen wissen, dass Google (Postini), übrigens genau wie Symantec (Messagelabs), US-amerikanische Firmen sind, die sich an die Gesetze ihres Landes halten müssen. Wo die Server stehen, über die die Mails laufen - ob in den USA oder Europa - ist dabei übrigens zweitrangig: Wenn Gesetze US-Behörden erlauben, diesen Kommunikationsweg zu prüfen, dann werden sich weder Google noch Symantec noch ein anderer Anbieter mit Sitz in den USA dagegen sperren. Für manche Firmen ist dieser Aspekt zweitrangig, andere sind aber nicht damit einverstanden.
Kritik muss sich Google auch beim Thema Verschlüsselung gefallen lassen, da die lediglich mittels SSL oder TLS möglich ist. Dabei wird jedoch nur der Übertragungsweg, nicht aber die Nachricht selbst verschlüsselt. Die Frage, ob Google-Mitarbeiter dann Kunden-Mails lesen oder nicht, ist eigentlich unerheblich. Aus Sicht von Juristen und Wirtschaftsprüfern ist oft schon negativ anzumerken, dass sie es könnten. Diesbezüglich haben andere Anbieter noch Vorteile. Beispielsweise bietet Retarus die Möglichkeit, die beiden De-facto-Standards PGP oder SMIME zu nutzen, um Mails komplett zu verschlüsseln.
Auch für eine andere deutsche Besonderheit, die im Zusammenhang mit dem Datenschutz steht, hat Google nur eine unzureichende Antwort. Die in Quarantäne verschobenen Spam-Mails erfordern ein umständliches Login und ohne Internet-Zugang ist auch kein Zugriff möglich. In manchen Firmen oder Behörden müssen Nutzer aber Zugriffsmöglichkeiten haben. Lokale Anbieter haben auch das besser geregelt.
Durch die Zielsetzung, Kunden möglichst weit in die Cloud zu ziehen, hat Google außerdem einige Schwächen bei Unternehmen, die lediglich bestimmte Dienste in Anspruch nehemn wollen, etwa den Virenscan oder die Spam-Filterung für E-Mails. Beispielsweise hält sich Google bei der Angabe von Verzögerungszeiten bis zur Zustellung auffällig zurück. Auch für den Fall, dass der Mailserver beim Kunden ernsthafte Probleme bekommt, scheint man nicht gut vorbereitet zu sein.
Ein verbreitetes Ärgernis, nämlich Mails an nicht existente Empfänger, stellt Google nur gegen Aufpreis ab. Notwendig dazu ist ein sogenannter Directory Filter, der solche Mails abblockt, bevor sie die Infrastruktur eines Kunden erreichen. Auch hier haben lokale Anbieter noch einen Vorsprung vor dem weltweiten Konzern. Bei Retarus etwa sei das im Standardpaket enthalten, teilt das Unternehmen auf Anfrage mit.
Und zu guter Letzt ist es ja mit E-Mail in den meisten Fällen nicht getan. Unternehmen haben in der Regel weitere Dienste im Einsatz, über die sie mit Geschäftspartnern und Kunden kommunizieren. Dazu gehört etwa auch das oft belächelte, aber immer noch quicklebendige EDI. Wer seine IT wirklich entlasten will, der sucht sich eventuell dann doch einen Dienstleister, der auch die Kontrolle dieser Dienste übernehmen kann.
URLs in diesem Artikel:
[1] = http:/
[2] = http:/
[3] = http:/
[4] = http:/
[5] = http:/
[6] = http:/
[7] = http:/
[8] = http:/
[9] = http:/
[10] = http:/
[11] = http:/
[12] = http:/
[13] = http:/
[14] = http:/
[15] = http:/
[16] = http:/
[17] = http:/
[18] = http:/
[19] = http:/
[20] = http:/
[21] = http:/
[22] = http:/
[23] = http:/
[24] = http:/
[25] = http:/
[26] = http:/
[27] = http:/
[28] = http:/
[29] = http:/