Agilität kann bedeuten, dass Firmen auf einem fremden Computer die eigene Sicherheit torpedieren. Ein Kommentar von Terry Ray, CTO von Imperva. [...]
Immer mehr Betriebe wollen ihre Unternehmensdaten in die Cloud verlegen. Und mehr noch, diese Begeisterung für die Cloud ist branchenübergreifend. Es ist schwer, noch einen Sektor zu finden, der nicht über Cloud-Migration nachdenkt. Laut Prognosen von Cisco wird der weltweite Datenverkehr in den Rechenzentren bis 2021 zu 94 Prozent in der Cloud verarbeitet werden.
Noch vor wenigen Jahren sah dies ganz anders aus. Wenn man damals ein Unternehmen fragte, ob es plane, in die Cloud zu gehen, standen die Chancen auf ein „Ja“ lediglich bei 50:50. Die Betriebe fürchteten, dass es der Cloud grundsätzlich an Sicherheit fehle – aufgrund der alten Binsenweisheit, dass die Cloud „ein fremder Rechner“ ist.
Die großen Cloud–Dienstleister hörten auf ihre Kunden, verstärkten Sicherheit und Compliance und zeigten dabei laufend, wie Cloud-Lösungen die geschäftliche Agilität fördern können. Heute ist die Technologie bereits ein fester Bestandteil der meisten Organisationen. Allerdings: Bei vielen von ihnen hat dadurch die Sicherheit gelitten und ihre eigenen Befürchtungen fallen auf sie zurück.
AWS Buckets: Ein Loch ist im Eimer
Im Folgenden führe ich eines der vielen denkbaren, archetypischen Cloud-Sicherheitsdesaster aus, um die Situation zu veranschaulichen. Ein IT–Administrator schaut sich in seinem Büro und Rechenzentrum um, sieht alle seine lokalen Sicherheitslösungen – Datenbanksicherheit, Intrusion-Prevention-System, Anti-Malware-Software, Firewalls, physische Sicherheitsmaßnahmen etc. Er folgert daraus, dass seine Cloud–Umgebung ebenso sicher ist (oder verhält sich zumindest so). Deshalb implementiert er in der Cloud–Umgebung keine zusätzlichen Sicherheitsebenen – und macht womöglich auch noch Fehler bezüglich der Sicherheitskonfigurationen.
Klingt ziemlich unvernünftig, oder? Doch das Problem ist leider weit verbreitet. Allein bei Amazon Web Services sind schätzungsweise 7 Prozent der AWS S3 Buckets so konfiguriert, dass uneingeschränkt auf sie zugegriffen werden kann. Die Daten zahlreicher IT-Abteilungen wurden 2017 öffentlich preisgegeben, weil ihre AWS S3 Buckets falsch konfiguriert worden waren (entweder von ihnen selbst oder von einem externen Dienstleister, der dadurch ihre Daten in Gefahr brachte). Auf der Liste stehen Consulting-Firmen wie Accenture, Militärdienstleister wie Booz Allen Hamilton, Telekommunikationsanbieter wie Verizon und Orange, Finanzinstitute wie Capital One, Einzelhändler wie Walmartund Unternehmen aus dem Unterhaltungssektor wie WWE, Viacomund die Australian Broadcast Corporation.
Pannenserie in der Cloud
Selbst wenn man annimmt, dass die Fehler des IT-Administrators aus dem oben genannten Beispiel wie durch ein Wunder keine fatalen Folgen haben – was passiert danach?
Um beim Beispiel zu bleiben: Nun schaut sich einer der leitenden Entwickler um, sieht das Gleiche wie der IT–Administrator und zieht ebenfalls den Schluss, dass er sich in einer „sicheren Umgebung“ befindet. Also nimmt er – jeder Tastenanschlag kostet schließlich wertvolle Zeit – ein schon früher verwendetes, leicht zu erratendes Passwort (sofern er sich überhaupt die Mühe macht, das voreingestellte Passwort zu ändern). Anschließend macht er sich daran, Produktionsdaten in die Cloud hochzuladen (in einem wirklich sicheren Entwicklungszyklus (SDLC) sollte er nicht einmal Zugriff auf diese Daten haben). Anschließend lädt er seinen Code in sein GitHub-Repository – wobei er völlig vergisst, dass der Code sensible API-Schlüssel enthält.
Nun kommt ein externer Hacker und startet einen Wörterbuchangriff, um in das GitHub-Repository des leitenden Entwicklers einzudringen. Wenn dieser Angriff Erfolg hat – was möglicherweise nur Sekunden dauert –, erhält der Hacker Zugriff auf die Benutzernachweise des Entwicklers, dringt damit in die AWS Buckets des Betriebs ein und erpresst Lösegeld für die Unternehmensdaten.
Dieser Vorgang ist vergleichbar mit einer Situation, in der man die Haustür abschließt, aber den Schlüssel unter den Fußabstreifer legt – und keine Alarmanlage, keinen Wachhund und keine sonstigen „inneren“ Sicherheitsvorkehrungen hat für den Fall, dass sich ein Einbrecher einfach Zugang durch die Tür verschafft.
Nicht mein Problem?
Die Aussage, dass die Cloud ein fremder Rechner ist, ist also nicht falsch – ähnlich, wie eine Mietwohnung fremdes Eigentum ist. In diesem Falle mietet jemand die Ressourcen, und der „Vermieter“ mag für bestimmte Wartungsaufgaben verantwortlich sein. Doch wenn der Mieter seinen Schlüssel weitergibt, die Fenster offenlässt oder die Tür nicht absperrt, sind die Schäden und Verluste sein eigenes Problem.
Insgesamt lässt sich festhalten: Die Cloud ist sicher – oder kann es zumindest sein. Dagegen sind sehr viele Cloud–Implementierungen nicht sicher – weil Unternehmen die Sicherheitsbedenken rund um den „fremden Rechner“ in eine sich selbst erfüllende Prophezeiung verwandelt haben. Insbesondere hat sich die Einstellung zur Cloud weiterentwickelt: statt „nicht mein Computer“ meinen viele heute „nicht mein Problem“. Die oben beschriebenen Sicherheitsverletzungen wurden allesamt durch Nutzer verursacht. Alles, was die Cloud–Dienstleister tun können, ist, Benutzerfreundlichkeit zu gewährleisten, Schulungen anzubieten und dann hoffen, dass Unternehmen sich ausreichend vorbereiten und absichern.
Es ist Sache der Firmen – großer wie auch kleiner – erstens: ihre Cloud–Dienstleister zu überprüfen und zweitens einen kompetenten Experten für Cloud-Konfiguration im Haus zu haben, der dafür sorgt, dass ihre Cloud–Umgebungen sicher sind. Im dritten Schritt sollten Firmen Tools für Sichtbarkeit und Incident-Response installieren, damit ihre Cloud–Umgebungen auch sicher bleiben. Mit anderen Worten: Wenn Unternehmen in der Cloud sind oder in die Cloud ziehen, dann sollten sie die Verantwortung für die Sicherheit nicht einfach abgeben. Schließlich mag es nicht der eigene Rechner sein, aber es sind die eigenen Firmendaten.
Be the first to comment