Nutzerfehler und Sicherheitspannen in der Cloud verhindern

com! professional: Häufig gehen die Kunden allerdings selbst fahrlässig mit ihren Daten um. So wurden mehrfach durch die falsche Konfiguration von Amazon S3 sensible Informationen öffentlich zugänglich gemacht, Entwickler publizierten Code auf GitHub, ohne vorher ihre AWS-Zugangsdaten daraus zu entfernen. Wie wollen Sie solche Nutzerfehler verhindern oder wenigstens eindämmen?

Gore: Wir werden nicht aufhören, die Anwender noch besser für die notwendigen Security-Maßnahmen bei der Cloud-Nutzung zu sensibilisieren. Sie müssen verstehen, dass Sicherheit in der Cloud fundamental anders funktioniert als traditionell im Rechenzentrum. Dort wurde bisher in der Regel nur der Perimeter geschützt. Wer die Außengrenze überwunden hatte, der hatte meist ungehindert Zugang zu den Daten. In der Cloud gibt es keine Außengrenze, deshalb muss jeder Zugriff geschützt werden.

com! professional: Wie unterstützen Sie Ihre Kunden bei der Umsetzung von Sicherheitsmaßnahmen?

Gore: Wir bieten fein abgestufte Zugangsregeln, die über das AWS Identity und Access Management (IAM) verwaltet werden können. Man kann sogar festlegen, dass bestimmte Zugriffe nur zu bestimmten Zeiten an bestimmten Tagen erfolgen dürfen. Mit AWS Config können Kunden festlegen, welche Daten öffentlich zugänglich gemacht werden dürfen und welche nicht. Wenn jemand einen S3-Bucket öffentlich macht, erhält der Administrator eine Nachricht und kann die Publizierung autorisieren oder verbieten.

Vor Kurzem haben wir außerdem Amazon Macie gelauncht. Der Service basiert auf Machine Learning und kann automatisch sensible Informationen wie Kreditkartennummern, Namen, Telefonnummern oder Adressen erkennen. Der Kunde erhält einen Report darüber und kann so entscheiden, welche Daten besonders zu schützen, zu verschlüsseln oder zu löschen sind.

com! professional: Vor allem bei Serverless Computing binden sich Anwender sehr stark an einen Cloud-Anbieter. Besteht nicht die Gefahr eines Vendor-Lock-ins, aus dem die Kunden nur sehr schwer wieder herauskommen?

Gore: Serverless ist meiner Ansicht nach der am wenigsten von Vendor-Lock-in gefährdete Service. Ich kann meine Microservices in Node.js schreiben. Dann sind noch zusätzlich drei bis fünf Zeilen Code notwendig, um auf AWS-Funktionen zugreifen zu können. Vendor-Lock-in passiert nur dann, wenn man sich beim Programmieren nicht an Best Practices hält. Bei einem guten Microservice-basierten Applikationsdesign werden die cloudspezifischen Funktionen über APIs aufgerufen. Bei einem Anbieterwechsel müssen dann einfach nur diese APIs angepasst werden, was keinen großen Aufwand darstellt.

Eine andere Möglichkeit ist es, unseren Elastic Container Service (ECS) zu nutzen. Darin kann ich einen Standard-Docker-Container betreiben, den ich natürlich jederzeit auch in einer anderen Container-Umgebung ausführen kann.

com! professional: Wie sieht es mit großen Datenmengen aus? Sie bieten ja einen Service, um Daten in die AWS-Cloud zu migrieren. Gibt es das gleiche Angebot auch, wenn ich die Daten wieder herausbekommen möchte?

Gore: Natürlich, unser Service zur Übertragung großer Datenmengen heißt nicht umsonst AWS Import/Export. Auch die Snowball-Appliance oder unser Database Migration Service lassen sich für die Datenübertragung in beide Richtungen nutzen. Wir glauben nicht an künstliche Barrieren, sondern wollen unseren Kunden die maximale Flexibilität geben.

com! professional: Unterscheiden sich denn die Kosten von Import und Export?

Gore: Die Kosten sind davon abhängig, welchen Service ich nutze.

com! professional: Der großflächige S3-Ausfall im Februar vergangenen Jahres hat den Ruf der AWS-Cloud, immer verfügbar zu sein, beschädigt. Was haben Sie getan, damit so etwas nicht mehr passieren kann?

Gore: Wir tun natürlich unser Bestes, um Ausfälle zu verhindern. Wir haben sehr schnell die betroffenen Kunden informiert und gemeinsam nach Wegen gesucht, die Folgen so gering wie möglich zu halten. Es sind nun mehr Sicherheits-Checks integriert, um zu verhindern, dass so etwas wieder vorkommt. Kunden, die den Best Practices gefolgt sind und ihre Workloads über verschiedene Sites verteilt haben, waren im Übrigen nicht betroffen.

com! professional: Kann man menschliche Fehler denn gänzlich eliminieren?

Gore: Das Kernproblem ist nie eine Person, auch wenn ein Mensch den Fehler ausgelöst hat. In so einem Fall ist das System einfach nicht robust genug, um vor menschlichen Fehlern geschützt zu sein. Wir haben das angepasst und nutzen eine ganze Reihe interner Prozesse, um das zu verhindern.

com! professional: Anwender müssen sehr genau über die AWS-Architektur Bescheid wissen, um ihre Applikationen hochverfügbar zu designen. Wie unterstützen Sie Kunden dabei? Gerade in Deutschland fehlt es ja an Experten für die AWS-Architektur.

Gore: Wir glauben, dass das Wachstum substanziell nur durch Partner kommen kann, und haben ein sehr gutes Partnernetzwerk, das wir stetig ausbauen und mit Partnerprogrammen, Trainings und Zertifizierungen unterstützen. Vergangenen Oktober haben wir einen eigenen Partner Day in Köln abgehalten und auch auf dem diesjährigen AWS Summit in Berlin werden Partnerthemen eine zentrale Rolle einnehmen.

com! professional: AWS ist mit großem Abstand Public-Cloud- Marktführer. Besteht nicht die Gefahr des Selbstgefälligkeit?

Gore: Ich glaube, so etwas kann bei Amazon nicht passieren. Es liegt einfach nicht in den Genen dieses Unternehmens, sich auf Erreichtem auszuruhen. Ich bin jetzt seit fünf Jahren bei AWS und wenn ich mir meine To-do-Liste anschaue, dann wird sie immer länger.

Wir bieten über 100 Services an und die Zahl wächst weiter. Wir hören außerdem sehr genau auf das Feedback unserer Kunden und arbeiten ständig an der Verbesserung unserer Services.