Zeit Online berichtet über offene, also unverschlüsselte und nicht durch dementsprechende Berechtigungen geschützte Cloudspeicher, aus denen man teils brisante Datensätze – privat wie aus dem Unternehmensbereich – herunterladen kann. Private Daten sind die eine Sache, Firmengeheimnisse, interne Dokumente oder Unterlagen, die rechtliche Konsequenzen haben können, eine ganz andere.
Kriminelle […] missbrauchen [Daten], die aufgrund von Fehlkonfigurationen der Cloudspeicher versehentlich zugänglich sind. […] Ob und inwiefern auch professionelle Spione wie chinesische Geheimdienste auf diesem Weg die Geschäftsgeheimnisse US-amerikanischer und europäischer Unternehmen stehlen und sich an den frei zugänglichen Daten bedienen, ist schwer nachzuweisen. Naheliegend ist es allerdings, […] es braucht keine ausgefeilten Cyberwaffen und keine aufwendigen Hackingangriffe. […] Neben der Konkurrenz, Spionen und Cyberkriminellen könnten auch Ermittlungsbehörden Interesse an einigen der Daten haben […] ZEIT ONLINE konnte unter anderem ein Leak mit 150.000 aufgezeichneten Telefonaten eines Kommunikationsdienstleisters aus Dubai auswerten. Zu den Kunden gehören Callcenter, […] die potenzielle Steuerflüchtlinge aus anderen Ländern beraten.
Zeit Online
Gleich zu Beginn des Zitats wird von einer „Fehlkonfiguration der Cloudspeicher“ gesprochen, die dann „versehentlich zugänglich“ sind. Ich denke, hier ist das Problem angesiedelt: Die Cloudspeicher sind, außer Microsoft lässt wieder einmal die Russen, die Chinesen oder sonst irgendwen in seinen Systemen herumpfuschen, sicher, wenn sie sicher benutzt werden. Doch ist das sichere Nutzen der Cloudspeicher so ohne weiteres möglich? Zumindest mit der nötigen, technischen Expertise? Hier beginnt der Graubereich, den Kai Biermann und Eva Wolfangel in ihrem Artikel beleuchten, denn:
Die technischen Betreiber dieser Datentanker [lehnen] jede Verantwortung für die beschriebenen Probleme ab. In den Geschäftsbedingungen von Amazon und anderen Cloudanbietern wird stets darauf verwiesen, dass die Mieter des Cloudspeicherplatzes für die Sicherheit der dort gespeicherten Daten zuständig sind. Angesichts des Umfangs und der Komplexität des Problems der offenen Container aber ist das möglicherweise zu wenig. Wenn derart viele Unternehmen daran scheitern, ihre Cloudspeicher so zu konfigurieren, dass sie Unbefugten keine Daten preisgeben, steht dahinter vielleicht auch ein systematisches Problem, um das sich die technischen Anbieter kümmern sollten. Offenbar gibt es hier eine Art Sollbruchstelle, die dazu führt, dass massenweise sensible Daten offen im Netz liegen.
Zeit Online
Ich glaube zwar nicht, dass es hier eine Sollbruchstelle gibt, denn diese Art der Darstellung lässt ja den Schluss zu, dass es möglich sein soll, private Daten öffentlich zugänglich zu machen. Ich bin mir aber ziemlich sicher, dass die öffentliche Zugänglichkeit und der private Verschluss von Daten Sache der Konfiguration ist. Speicher – ob nun online oder offline – liefert Daten nur aus. Die Ebene darüber entscheidet, an wen diese gesendet bzw. wem sie verfügbar gemacht werden. Für die Programmierung und Konfiguration sollte der Transfer von Daten immer mit einer Berechtigungsprüfung einhergehen. Im einen Fall ist es das Foto einer Handtasche, das auf der Website eines Onlineshops – für jeden und jede sichtbar – angezeigt werden soll. Im anderen Fall sind es die Adressdaten eines Kunden, die natürlich nur für den Kunden und gegebenenfalls für den Shop-Betreiber und seine Dienstleister zugänglich sein sollten.
Aber gut, was rede ich groß über Datensicherheit. Ich war selbst vor ein paar Jahren mit dem Onlineprojekt eines mittelgroßen, aber durchaus bekannten Unternehmens konfrontiert, dessen Administrationsbereich unter einer sehr eigenartigen, nur schwer zu erratenden URL zu finden, aber durch keinerlei weiteren Schutzmechanismus gesichert war. Ja, richtig gelesen: Man konnte die Website des Unternehmens nach Lust und Laune bearbeiten, da die Administrationsoberfläche des (selbst entwickelten) CMS durch security through obscurity geschützt war. Und nein, das CMS wurde nicht von einem Ferialpraktikanten entwickelt, sondern von einem noch heute für mittelgroße Unternehmen aktiv tätigen IT-Unternehmen.
Ob also nun das „Versehen“, Daten in Cloudspeichern nach außen hin zugänglich zu machen, tatsächlich bei den Anbietern eben dieser Cloudspeicher gesucht bzw. ob ihnen Mitverantwortung übertragen werden sollte, möchte ich in Frage stellen, zumal sie – meiner Erfahrung nach – bei der Konfiguration des Onlinespeichers ohnehin mehrfach darauf hinweisen, diese und jene Schutzmechanismen zu aktivieren bzw. warnen, wenn die dementsprechenden Berechtigungen (bewusst) lasch gesetzt werden. (Das natürlich nur, wenn man ihre entsprechenden Web-Oberflächen nutzt. Nutzt man die Programmschnittstellen, entfallen solche Warnungen. Hier setzt man aber zurecht voraus, dass jemand, der Buckets und andere Datencontainer über eine solche Schnittstelle generiert, weiß, was er oder sie tut.)
Ceterum censeo: Wer Unternehmensdaten in die Cloud lagern will und sich über die Konfiguration seiner Systeme unsicher ist (also: dem beratenden und betreuenden IT-Team nicht traut), sollte ganz grundsätzlich dafür sorgen, dass Daten den eigenen Rechner ausschließlich verschlüsselt verlassen und somit in der Cloud wenn potentiell offen, dann zumindest vollständig verschlüsselt gespeichert werden. Dementsprechende Software (wie zum Beispiel Cryptomator) und Services (wie zum Beispiel die Ende zu Ende-verschlüsselte iCloud) gibt es ja zum Glück. So kommen Unberechtigte vielleicht an die Daten heran, können aber ohne entsprechendem Schlüssel nicht allzu viel damit anfangen. Das erspart Sorgen und lässt auch die DSGVO nicht ganz so brutal durchgreifen.
Wieder ein sehr lesenwerter Beitrag und man mag sich lieber nicht vorstellen, wie es da auf einigen Cloud-Speichern aussieht.
Vor ein paar Wochen habe ich bei Hetzner für unter 5€/Monat einen VPS angemietet und mit Sorgfalt einige Docker-Images installiert. Als Reverse Proxy setze ich Caddy ein. Für die Verwaltung der Docker-Container bietet sich die wirklich gut gemachte, als Community-Version kostenlos erhältliche Software Portainer an.
Es ist naheliegend (und an verschiedenen Stellen im Web auch entsprechend dokumentiert), auch Portainer unter einer Subdomain zugänglich zu machen. Schließlich ist der Zugang zu Portainer passwortgeschützt. Bei meiner Recherche, wie man den Zugang gegen Brute-Force-Angriffe schützen kann, bin ich dann aber auf die deutlich bessere Lösung gestoßen, statt des Reverse Proxy einen Zugang über Wireguard VPN einzurichten. Wie alles, was man zum ersten Mal macht, ist das nicht trivial und hinterlässt eine gewisse Unsicherheit, ob man nicht doch vielleicht eine potentielle Lücke übersehen hat.
Vielleicht magst du mal über Sicherheit von Docker-Containern schreiben? Fast jede exemplarische `docker-compose.yml` enthält `password` als Zugangsschlüssel für die MySQL-Datenbank. Ob jedem klar ist, ob man das austauschen muss?
Wichtig erscheint mir auch der Querverweis, dass eine mangels Verschlüsselung geleakte Datenbank auch wegen DSGVO eine Benachrichtgung der Betroffenen erforderlich macht. Ob das allen bekannt ist, die WordPress „vor zwei Wochen kennen gelernt“ und direkt „weil es so einfach war“ einen Webshop mit WooCommerce aufgesetzt haben?
Danke für deinen Beitrag.
Vielen Dank und ja, ich möchte in der Tat nicht wissen, wie es auf einigen Cloudspeichern aussieht. Von technischen Anleitungen (oder Kommentaren, Stichwort „Sicherheit von Docker-Containern“) nehme ich bewusst hier Abstand. Oft kommen mir einige der Blogposts ohnehin schon zu technisch für ein Publikum vor, das absolut gar keine Ahnung hat, was „Docker“ ist bzw. nicht versteht, warum „password“ kein gutes Passwort ist. – Und derer gibt es viele. Da bleibe ich lieber bei Hinweisen und Andeutungen, die für diejenigen, die über Fachwissen verfügen, die Richtung zu mehr Information deutet, aber eben die anderen nicht verschreckt.
Verschreckend ist aber dein (vor) letzter Absatz, denn die Erfahrung, „weil es so einfach war“ in Zusammenhang mit nicht nur WordPress/WooCommerce, sondern auch anderen Systemen, habe ich schon oft gemacht, wenn mir Personen von massiven, sicherheitsrelevanten Probleme berichtet haben, ihnen aber gar nicht bewusst war (!), dass es sich um solcherlei Probleme handelt. Wie oft habe ich schon jemandem geholfen, etwas, das die Person nicht und nicht hinbekommen hat, zu reparieren („Warum wird da ein Rufzeichen unter meinem Footer angezeigt?“)? Und wie oft hat sich dann schnell herausgestellt, dass es nicht ein Fehler im CMS war, der diese Ausgabe gemacht hat, sondern Skripte, die nicht auf dem Server sein sollten. – Und die Reaktion war immer wieder ähnlich: Ah, das kann man ohnehin löschen, na dann ist ja wieder alles gut. Nein, eine technische Betreuung für meinen Webshop benötige ich nicht. Das wird ja wohl nicht wieder vorkommen und wenn, dann habe ich ja deine Kontaktdaten. 🤦♂️