CW: Erklären Sie kurz, wie AWS und das Retail-Geschäft von Amazon zusammenhängen.
STEPHEN SCHMIDT: AWS ist als Dienstleister für das Retail-Geschäft von Amazon.com tätig. Wir stellen Speicher und IT-Services für den Shop bereit, verkaufen das Gleiche aber auch an die breite Öffentlichkeit. Eine beliebte Falschannahme ist, dass AWS Teile der IT-Infrastruktur des Retail-Geschäfts an Dritte vermiete. Das stimmt nicht. Unsere Systeme standen immer schon für sich allein.
CW: Von welcher Größenordnung sprechen wir?
SCHMIDT: Unser bekanntester Service, der Cloud-Speicher Amazon S3 (Simple Storage Service), verwaltet rund 835.000 Transaktionen pro Sekunde. In der S3-Cloud befinden sich insgesamt über 1,3 Billionen Objekte.
CW: Wie rechnen Sie die Services ab?
SCHMIDT: Nach Verbrauch pro Stunde. Weil die Kosten damit transparent sind, können auch kleine Unternehmen oder Privatpersonen unsere Dienste in Anspruch nehmen. Dieses Verbrauchsmodell setzt sich im Markt durch - viele unserer Security-Partner wie Symantec, Trend Micro, Sophos, Astaro, Citrix oder Riverbed, deren Lösungen Sie früher nur als Komplettpaket lizenzieren konnten, bieten ihre Services auf unseren Plattformen ebenfalls stundenbasiert an. Anwender sind damit flexibler. Wer ungefähr einschätzen kann, wie viel er verbraucht, kann auch sogenannte "reservierte Instanzen" buchen - die kosten einen einmaligen Sockelbetrag und einen zusätzlichen Stundenbetrag, der günstiger ist als der übliche Tarif.
CW: Abgesehen von der Skalierbarkeit - warum sollten Unternehmen auf Cloud-Services setzen?
SCHMIDT: Durch das Cloud Computing bekommt die IT eine ganz neue Sichtbarkeit. Beispiel Sicherheit: Die beginnt damit, zu verstehen, was ein Unternehmen besitzt. Sie können nichts schützen, von dem Sie nicht wissen, dass es da ist, um was es sich handelt, wo es sich befindet und wer es besitzt. Viele CIOs haben uns berichtet, dass in ihren traditionellen IT-Umgebung zumeist jährliche Inventuren vorgenommen werden. Dabei wird erfasst, welche Systeme innerhalb des Unternehmensnetzes vorhanden sind. Nicht bekannt ist aber, welche Computer unter jedem einzelnen Schreibtisch stehen oder welche mobilen Geräte im WLAN eingewählt sind. Ganz anders in der Cloud: Weil alles API-gesteuert ist, müssen Kunden uns ganz genau sagen, wo sie welche Daten hin haben möchten - beispielsweise in die Rechenzentren innerhalb der EU. Wir verteilen Informationen nicht einfach weltweit, wie es uns gerade passt, sondern benötigen detaillierte Anweisungen.
- Herausforderung Cloud Security
Cloud-Computing-Umgebungen stellen in Bezug auf die Sicherheit IT-Verantwortliche und Systemverwalter vor neue Herausforderungen. Nach Angaben von Intel sind besonders folgende Faktoren zu berücksichtigen: - Mangel an Kontrolle:
Eine dynamische Technik wie Cloud Computing verschiebt die Grenzen der Unternehmens-IT über das hauseigene Rechenzentrum hinaus, etwa durch Einbeziehen von Public-Cloud-Services. Da - Unzureichende Transparenz:
In einer Cloud-Umgebung ist es wegen der hohen Komplexität schwieriger, Compliance-Vorgaben umzusetzen und die entsprechenden Audits vorzunehmen. - Virtualisierung:
Durch die wachsende Zahl von Virtual Machines steigt das Sicherheitsrisiko, weil alle diese Komponenten verwaltet werden müssen, Stichworte Patch-Management, Implementierung von Schutzsoftware, Einspielen von Updates und so weiter. - Ort der Datenspeicherung:
Rechtliche Vorgaben wie etwa das Bundesdatenschutzgesetz verlangen die Speicherung von Daten in Cloud-Rechenzentren, die innerhalb der EU angesiedelt sind und ausschließlich den hier geltenden Gesetzen unterliegen. Das erschwert die Wahl eines Cloud-Service-Providers. - Public Clouds:
Bei der Nutzung von Public Clouds sind spezielle Sicherheitsanforderungen zu berücksichtigen, etwa bezüglich des Schutzes der Daten, die beim Provider lagern, sowie beim Transport der Daten über Weitverkehrsverbindungen und das Internet. - Zugriff auf die Cloud von privaten Systemen aus:
Trends wie der Einsatz von privaten Endgeräten für betriebliche Zwecke erschweren die Absicherung des Zugriffs auf Cloud-Computing- Ressourcen. Eine Lösung ist der Einsatz von Mobile-Device- Management-Software. - Audits und Überwachung von Sicherheits-Policies:
Compliance- Regeln wie SOX (Sarbanes-Oxley Act), EuroSOX, HIPAA (Health Insurance Portability and Accountability Act) und PCI DSS (Payment Card Industry Data Security Standard) erfordern regelmäßige Überprüfungen der IT-Sicherheitsvorkehrungen. Speziell in Public- und Hybrid-Clouds, in denen neben einem Unternehmen ein Cloud-Service- Provider im Spiel ist, sind entsprechende Audits aufwendig. - Risiken durch gemeinsame Nutzung von Ressourcen:
In Cloud- Umgebungen teilen sich mehrere Kunden (Public Clouds, Community Clouds) physische IT-Ressourcen wie CPU, Speicherplatz und RAM. Wird ein Hypervisor kompromittiert, können die Anwendungen mehrerer Kunden betroffen sein.
Granulare Einstellmöglichkeiten
Das Reporting über das IT-Inventar kann dann auf Wunsch wöchentlich, täglich, stündlich oder sogar minütlich erfolgen. Das vereinfacht übrigens auch den Auditing-Prozess. Auch die Zugriffsberechtigungen lassen sich häufig feiner einstellen als in On-Premise-Umgebungen. Wer Geschäftsunterlagen in Amazon S3 speichert, kann diese mit einem Ablaufdatum versehen, das die gesetzliche Aufbewahrungsfrist von beispielsweise sieben Jahren berücksichtigt, und die Daten anschließend automatisch in eine andere Speicherbereich verschieben lassen. Zudem ist es möglich, Informationen hinzuzufügen, nach denen nur eine ganz bestimmte Person diese Daten nach einer erfolgreichen Multi-Faktor-Authentifizierung löschen darf. Eine andere Einstellung könnte sein, dass nur Person A von seinem Dienstcomputer im Büro aus zwischen 9 und 17 Uhr auf die Information zugreifen darf. Derart granulare Kontrolleinstellungen sind in traditionellen IT-Systemen kaum möglich.
CW: Sind Daten bei AWS sicherer als im eigenen Unternehmen?
SCHMIDT: Viele Kunden berichten uns, dass sie bei uns mehr Möglichkeiten haben, ihre Sicherheitsvorstellungen durchzusetzen als in internen On-Premise-Umgebungen.
CW: Ist die eigene Private Cloud untern Anwendern nicht beliebter als die Public Cloud, wie AWS sie anbietet?
SCHMIDT: Nein. Schauen Sie sich beispielsweise unseren Kunden SAP an, der sehr viele Daten über unsere Cloud-Services verarbeitet und gerade erst seine komplette Software-Suite auf den AWS-Betrieb hat zertifizieren lassen. Das war kein Pappenstiel und zeigt, wie sehr der Konzern an uns glaubt. Kunden, die sich um Datenhaltung, Datensicherheit und Datentrennung sorgen, mögen sich unser Virtual-Private-Cloud-Produkt anschauen, das die Skalierbarkeit und Flexibilität von AWS mit der Funktionalität eines Inhouse-Rechenzentrums verknüpft. Hier können die Kunden ihre eigenen IP-Adressbereiche verwenden, mit bereits vorhandenen Management-Tools weiterarbeiten oder die auch für ihre On-Premise-Dienste festgelegten Firewall-Regelsets nutzen.
SLAs sind verhandelbar - und faktenfest
CW: Ein großes Hindernis für Anwender, in die Cloud zu gehen, stellen undurchsichtige und mutmaßlich unverhandelbare Service-Level-Agreements (SLAs) dar. Lassen Sie mit sich reden?
SCHMIDT: Es stimmt nicht, dass wir SLAs nicht verhandeln. Alle unsere großen Kunden werden Ihnen erzählen, dass wir gerne mit ihnen über die Verträge verhandelt haben. Wichtig ist uns folgende Feststellung: Unsere SLAs sind kein unbelastbares Marketing, wie es andere Cloud-Service-Provider häufig bevorzugen. Wir verwenden valide und nachprüfbare Zahlen und Fakten. So geben wir die garantierte Haltbarkeit von Daten, die in der S3-Cloud gespeichert werden, mit 99,999999999 Prozent an ("elf Neunen") - und eben nicht mit 100 Prozent. Das kommt daher, dass wir genau ausgerechnet haben, wie viele Bits auf wie vielen Laufwerken mit wie vielen Schnittstellen, Netzwerkkabeln für wie lange ausfallen dürfen, damit sie erhalten bleiben. Wir setzen keine SLAs auf, die nur gut aussehen - auf unsere SLAs können sich die Kunden verlassen.
CW: Wie sprechen Sie die deutschen und europäischen Anwender im Neukundengeschäft an?
SCHMIDT: Für unsere europäischen Kunden ist es wichtig, dass AWS Mitglied des Safe-Harbor-Programms der Europäischen Union ist. Damit ist für sie sichergestellt, dass wir uns als Cloud-Provider an bestimmte Regularien und Policies halten. Das betrifft die den EU-Datenschutzgesetzen entsprechende sichere und einheitliche Speicherung und Übertragung von Daten über das gesamte Unternehmen hinweg.
CW: Welche Szenarien bildet AWS in Europa ab?
SCHMIDT: Alle unsere Systeme wurden so entwickelt, dass sie die Daten der Kunden getrennt speichern. Anwender können den Zugriff so weit wie eben möglich eingrenzen oder auch völlig offen gestalten. Der Kunde entscheidet es ganz allein. Einige unserer Kunden aus der Spieleindustrie unterstützen Fernsehsendungen mit cloud-gestützten Gaming-Services, die so vielen Menschen wie möglich zugänglich gemacht werden sollen. Andere wie beispielsweise der Nürnberger Flughafen, der seine Passagierdaten über AWS verarbeitet, beschränken den Zugriff auf entsprechend privilegierte Nutzer.
CW: Wie läuft die Entwicklung neuer Services ab?
SCHMIDT: Dazu sind verschiedene Maßnahmen nötig. Zunächst kommt das Service-Design. Mein Team berät die Entwickler über die notwendigen Schritte, noch bevor eine einzige Zeile Code geschrieben wird. Nur so erreichen wir die Sicherheit der Daten, die Datentrennung zwischen verschiedenen Kunden und die Befehlswege, die für Zertifizierungen nötig sind. Wenn sie mit der Entwicklung von Softwarepaketen beginnen, nehmen wir regelmäßige Tests und Revisionen vor, damit beispielsweise Verschlüsselungstechnologie korrekt implementiert wird oder Zugangssysteme so funktionieren, wie sie sollen.
Wenn die Fertigstellung eines Services näher rückt, kommen Penetrationstests sowohl durch unser eigenes Expertenteam als auch durch externe Dienstleister hinzu. Letztere konzentrieren sich dabei auf zwei verschiedene Verfahren: Beim "White box testing" nehmen sie unsere internen Entwicklungsstufen samt Quellcode unter die Lupe, beim "Black box testing" agieren sie wie ein normaler Nutzer und versuchen, beispielweise per DoS-Attacke oder direkt über das Service-Interface in das System einzubrechen. Die Penetrationsverfahren werden auch nach dem Going-live eines Dienstes in regelmäßigen Intervallen wiederholt. Wir machen das nicht nur, um die Sicherheit unserer Kunden zu gewährleisten, sondern auch, um weltweit geltende Compliance-Vorschriften wie beispielsweise PCI DSS erfüllen zu können. Ein weiterer Grund ist, dass wir durch die Regierungen der USA und Großbritanniens zertifiziert worden sind, die ebenfalls regelmäßige Penetrationstests verlangen.