Wie viele Schichten hat die Sicherheit Ihrer Dateien? Hinter den Kulissen des Open-Source-Stacks bei WebDisk

WebDisk Blog · Kategorie: Sicherheit · Lesezeit: ~9 Minuten

Kurz gefasst:- Die Sicherheit von WebDisk ist nicht ein einzelnes Produkt, sondern ein System aus Schichten – fünf technologische und eine menschliche: Application-Firewall und Netzwerksonde am Rand, Sensoren innerhalb der Systeme, zentrale Ereigniskorrelation und automatische Alarmierung rund um die Uhr.- Wir stützen es auf bewährte Open-Source-Projekte – u. a. Suricata, Wazuh, Falco, open-appsec – und das Ganze beobachten wir auf einem einzigen Bildschirm.- Alles verbindet ein Grundsatz: keine einzelne Schutzmaßnahme ist unfehlbar – deshalb sichert jede Schicht die übrigen ab.

Wenn Sie jemandem Ihre Dateien anvertrauen, kaufen Sie in Wirklichkeit zwei Dinge: Technologie und Wachsamkeit. Über die Technologie haben wir in den vorherigen Teilen dieser Serie geschrieben – über Verschlüsselung, Zugriff ohne statische Schlüssel und Kopien, die sich nicht löschen lassen. Heute laden wir Sie hinter die Kulissen des zweiten Teils ein: wie das System aussieht, das Tag und Nacht über unsere Plattform wacht – und warum wir es aus Open-Source-Bausteinen gebaut haben. Im Englischen nennt man einen solchen Verbund zusammenarbeitender Werkzeuge Stack – und bei diesem Wort bleiben wir hier.

Was bedeutet mehrschichtige Verteidigung (Defense in Depth)?

In der Sicherheit glauben wir nicht an einzelne Wunderlösungen. Wir glauben an die mehrschichtige Verteidigung (Defense in Depth) – ein Prinzip, das älter ist als die Informatik und aus jeder Bank bekannt ist: Der Tresorraum hat Mauern, dann Panzertüren, dann einen Safe, und alles wird von Kameras und Sensoren überwacht. Ein Einbrecher müsste jede Schicht nacheinander überwinden – und jede von ihnen hat einen eigenen Alarm.

Unsere Plattform funktioniert genauso. Bevor eine Anfrage aus dem Internet Ihre Dateien erreicht, durchläuft sie aufeinanderfolgende Kontrollpunkte; und selbst wenn einer versagen sollte, beobachten die weiteren Schichten, was danach geschieht – und schlagen Alarm, um die Zeit zwischen Ereignis und Reaktion maximal zu verkürzen.

Warum bauen wir Sicherheit auf Open Source auf?

Alle Schlüsselelemente unseres Sicherheits-Stacks sind Projekte mit offenem Quellcode. Das ist eine bewusste Entscheidung – aus drei Gründen:

1. Transparenz. Bei geschlossenen Produkten muss man Sicherheit auf Treu und Glauben hinnehmen. Bei offenen lässt sich jeder Mechanismus überprüfen, und die Prozesse zum Melden und Beheben von Fehlern sind öffentlich: Man sieht nicht nur den Code, sondern auch, wie das Projekt auf gefundene Schwachstellen reagiert.
2. Unabhängigkeit. Wir sind keine Geisel von Lizenzen oder Preislisten. Wir können Komponenten so abstimmen, kombinieren und austauschen, wie es unsere Architektur erfordert – nicht so, wie es der Vertrag erlaubt.
3. Branchenstandards. Suricata, Wazuh oder Falco sind Werkzeuge, auf die sich Sicherheitsteams seit Jahren stützen – indem wir sie nutzen, nutzen wir auch die Erfahrung der gesamten Branche.

Ein ehrlicher Vorbehalt: Open Source allein schafft keine Sicherheit – es schafft Überprüfbarkeit. Sicherheit entsteht aus Konfiguration, Feinabstimmung und der täglichen Arbeit mit diesen Werkzeugen. Und genau von dieser Arbeit handelt der Rest dieses Artikels.

Schicht eins: der Rand – eine Firewall, die lernt

Der gesamte Traffic aus dem Internet trifft zuerst auf unsere Edge-Server. Dort arbeiten zwei unabhängige Mechanismen:

WAF (Web Application Firewall) – eine Application-Firewall auf Basis des Projekts open-appsec, die die an unsere Anwendungen gerichteten HTTP-Anfragen analysiert. Im Unterschied zu klassischen Firewalls mit einer Liste starrer Regeln nutzt open-appsec maschinelles Lernen: Es baut ein Modell des normalen Verhaltens jedes Dienstes auf, um Abweichungen zu erkennen – auch solche, die noch in keiner Signaturdatenbank stehen. Den Betriebsmodus wählen wir pro Dienst und Modellreife: Einen Teil der Dienste schützt die Firewall aktiv und blockiert verdächtige Anfragen, die übrigen laufen im Lern- und Erkennungsmodus, in dem der Traffic analysiert wird und die unten beschriebenen weiteren Schichten speist – die Blockierung schalten wir ein, sobald das Modell des jeweiligen Dienstes ausgereift ist.

Suricata – eine Netzwerksonde, die den Traffic auf Paketebene analysiert. Sie arbeitet mit Zehntausenden von Erkennungsregeln – fortlaufend aktualisiert: Sie erkennt Scan-Muster, Versuche, bekannte Schwachstellen auszunutzen, und verdächtiges Protokollverhalten. Sie arbeitet am gesamten Rand unserer Infrastruktur – nicht nur vor den Anwendungen, sondern auch vor den Hilfsdiensten.


Schicht zwei: das Innere – Sensoren dort, wo die Arbeit stattfindet

Eine Firewall am Rand genügt nicht – gute Sicherheit geht davon aus, dass sie irgendwann jemand umgehen könnte. Deshalb arbeitet die zweite Sensorlinie innerhalb der Plattform:

Falco wacht in Echtzeit über laufende Container und Systeme – auf der Ebene des Betriebssystem-Kernels (eBPF-Technologie). Es erkennt Verhaltensweisen, die nicht vorkommen sollten: einen Prozess, der plötzlich sensible Dateien liest, einen Container, der versucht, einen unerwarteten Befehl auszuführen, ungewöhnliche Netzwerkaktivität. Das ist das Gegenstück zum Bewegungsmelder im Tresorraum – selbst wenn jemand die Tür überwunden hat, hinterlässt er drinnen Spuren, und genau diese Spuren fangen wir ab.

Hinzu kommt die Überwachung der Integrität von Systemdateien auf den Schlüsselservern der Plattform (eine unautorisierte Konfigurationsänderung hinterlässt eine Spur) sowie klassische Mechanismen der Systemhärtung – vom automatischen Blockieren von Adressen, die Passwörter zu erraten versuchen, bis hin zu restriktiven Berechtigungen.

Schicht drei: Wozu dient ein SIEM und wie korreliert Wazuh Ereignisse?

Ein einzelner Sensor sieht nur seinen Ausschnitt. Die Stärke des Gesamtsystems ist die Korrelation: Ereignisse – von der Firewall, von der Netzwerksonde, von den Runtime-Sensoren, aus den Betriebssystemen – fließen in ein zentrales System der Klasse SIEM auf Basis des Projekts Wazuh, gespeist von Agenten, die über die gesamte Serverflotte verteilt sind.

Hier fügen sich einzelne Signale zu einer Geschichte zusammen: Ein fehlgeschlagener Login auf einem Server ist Rauschen; dieselbe Quelle, die Ports scannt, die Firewall berührt und auf drei Systemen Passwörter durchprobiert – das ist bereits ein Angriffsmuster. Wazuh klassifiziert Ereignisse nach Schweregrad und kann bei bestimmten Szenarien automatisch reagieren – ohne auf einen Menschen zu warten.

Parallel fließen die Logs in eine zentrale Analyseplattform, wo sie gespeichert und durchsuchbar sind – denn in der Sicherheit ist die Möglichkeit, den Ablauf der Ereignisse sekundengenau zu rekonstruieren, ebenso wichtig wie die Erkennung selbst.

Schicht vier: Wir suchen Lücken bei uns selbst – bevor sie jemand anderes findet

Verteidigung heißt nicht nur, auf einen Angriff zu warten. Ein fester Bestandteil unserer Arbeit ist die aktive Suche nach eigenen Schwachstellen:

• Schwachstellenscanner durchleuchten regelmäßig die gesamte Infrastruktur – von den Betriebssystemen über Webanwendungen bis zur TLS-Konfiguration.
• Sicherheit der Lieferkette: Jedes Release unserer Anwendungen durchläuft eine Pipeline, die ein Komponentenverzeichnis (SBOM) erzeugt, und die Abhängigkeiten werden automatisch auf bekannte Schwachstellen geprüft – noch bevor sie in die Produktion gelangen.
• Erkannte Schwachstellen landen in einem einzigen, zentralen System, das sie nach Schweregrad ordnet und die Behebungsfristen überwacht – je schwerwiegender die Schwachstelle, desto kürzer die Frist.
• Zertifikate und Verschlüsselung werden ununterbrochen überwacht – von einem ablaufenden Zertifikat wissen wir lange, bevor es irgendjemand von außen bemerkt.

Schicht fünf: alles auf einem Bildschirm – und unter externer Aufsicht

Jedes Element des Stacks meldet seinen Zustand an ein zentrales Monitoring auf Basis von Grafana und Prometheus. Das Team sieht laufend den Zustand jeder Schicht: ob die Sonde arbeitet, ob die Firewall den Traffic analysiert, ob ein Sensor aufgehört hat zu berichten. Unten ein Ausschnitt einer echten Ansicht des Traffics, den unsere Netzwerksonde analysiert:


Das System alarmiert automatisch zu jeder Tages- und Nachtzeit – Benachrichtigungen erreichen das Team sofort, unabhängig davon, ob gerade jemand auf den Bildschirm schaut. Und weil „Wer bewacht den Wächter?“ im Monitoring die entscheidende Frage ist, wird das Monitoring-System selbst überwacht von einem unabhängigen, außerhalb unserer Infrastruktur arbeitenden Wächter, der selbst dann Alarm schlagen würde, wenn unsere gesamte Plattform verstummen sollte.

Einen Teil dieser Sichtbarkeit geben wir übrigens an Sie weiter: Die öffentliche Seite status.webdisk.io zeigt laufend die Verfügbarkeit unserer Dienste – ohne Beschönigung, direkt aus dem Monitoring-System.


Die wichtigste Schicht: Menschen und Gewohnheiten

Werkzeuge ersetzen keine Arbeitskultur. Der Stack ergibt Sinn, weil hinter ihm tägliche Praxis steht:

• Regeln und Ausnahmen werden feinjustiert – ein System, das tausendmal am Tag ohne Grund schreit, bringt Menschen bei, Alarme zu ignorieren; unsere Detektionen durchlaufen einen Abstimmungszyklus, bis ein Alarm auch wirklich Alarm bedeutet,
• die Konfiguration des Stacks lebt als Code in Repositories – Änderungen sind versioniert und reproduzierbar,
• Verfahren und Risikobewertungen (einschließlich DPIA für datenverarbeitende Funktionen) sind schriftlich festgehalten und werden aktualisiert, und unser Compliance-Programm bauen wir auf anerkannten Sicherheitsrahmenwerken auf,
• und schließlich – wir gehen von der Fehlbarkeit unserer eigenen Schutzmaßnahmen aus. Das ist kein Pessimismus, sondern Methode: Jede Schicht existiert, weil eine andere irgendwann versagen kann.

Dieser letzte Grundsatz gilt auch für uns selbst. Deshalb veröffentlichen wir security.txt und eine Richtlinie zur Meldung von Schwachstellen: Wenn Sie Sicherheitsforscher sind und bei uns eine Schwachstelle finden, sagen Sie es uns – wir hören es lieber von Ihnen, als es aus einem Vorfall zu erfahren.

Häufige Fragen

Was ist Defense in Depth (mehrschichtige Verteidigung)? Das ist ein aus jeder Bank bekanntes Prinzip: Der Tresorraum hat Mauern, Panzertüren, einen Safe, und alles wird von Kameras und Sensoren überwacht – ein Einbrecher muss jede Schicht nacheinander überwinden, und jede hat einen eigenen Alarm. In der IT bedeutet das viele unabhängige Schutzmaßnahmen, von denen jede die übrigen absichert: Selbst wenn eine versagt, beobachten die nächsten, was weiter geschieht, und schlagen Alarm.

Warum baut WebDisk Sicherheit auf Open-Source-Werkzeugen auf? Aus drei Gründen: Transparenz (jeder Mechanismus und jeder Prozess zur Fehlerbehebung lässt sich überprüfen), Unabhängigkeit von Lizenzen und Preislisten sowie Rückgriff auf Branchenstandards – Suricata, Wazuh oder Falco sind Werkzeuge, auf die sich Sicherheitsteams seit Jahren verlassen. Open Source allein schafft jedoch keine Sicherheit – es schafft Überprüfbarkeit; Sicherheit entsteht aus Konfiguration, Feinabstimmung und der täglichen Arbeit mit diesen Werkzeugen.

Worin unterscheidet sich eine WAF auf Basis von maschinellem Lernen von einer klassischen regelbasierten Firewall? Eine klassische Firewall vergleicht Anfragen mit einer Liste starrer Regeln und Signaturen bekannter Angriffe. Eine Firewall auf Basis von maschinellem Lernen – wie open-appsec in unserem Stack – baut ein Modell des normalen Verhaltens jedes Dienstes auf und erkennt Abweichungen davon, auch Angriffe, die noch in keiner Signaturdatenbank stehen.

Wozu dient ein SIEM und wie erkennt es einen Angriff, den ein einzelner Sensor nicht sieht? Ein SIEM sammelt Ereignisse aus allen Schichten – Firewall, Netzwerksonde, Runtime-Sensoren, Betriebssystemen – und korreliert sie zu einem Gesamtbild. Ein einzelner fehlgeschlagener Login ist Rauschen, aber dieselbe Quelle, die Ports scannt und auf drei Systemen Passwörter durchprobiert, ist bereits ein Angriffsmuster. Unser auf Wazuh basierendes SIEM klassifiziert Ereignisse nach Schweregrad und reagiert bei bestimmten Szenarien automatisch, ohne auf einen Menschen zu warten.

Wie meldet man eine Sicherheitslücke bei WebDisk? Wir veröffentlichen die Datei security.txt sowie eine Richtlinie zur Meldung von Schwachstellen. Wenn Sie Sicherheitsforscher sind und bei uns eine Schwachstelle finden, sagen Sie es uns – wir hören es lieber von Ihnen, als es aus einem Vorfall zu erfahren.

Was bedeutet dieser Sicherheits-Stack für Ihre Dateien?

Zählen wir nach: Rand, Inneres, Korrelation, eigene Tests, Monitoring – fünf technologische Schichten und eine menschliche. Dieses System arbeitet im Hintergrund – bei jedem Upload einer Datei in WebDisk Files oder bei jedem Versand eines Links über WebDisk Send. Sie müssen nichts davon wissen – und genau das ist der Punkt. Und dort, wo Sicherheit Ihre Entscheidungen berührt, geben wir Ihnen die konkreten Werkzeuge an die Hand, die wir in den vorherigen Teilen der Serie beschrieben haben: Verschlüsselung im Ruhezustand (SSE), Zugriff ohne statische Schlüssel (STS) und WORM-Speicher mit Anti-Ransomware-Funktion.

Sicherheit ist ein Prozess, kein Zustand – deshalb entwickelt sich dieser Stack ständig weiter: Es kommen neue Detektionen, neue Schichten, neue Tests hinzu. Wenn Sie Fragen dazu haben, wie wir Ihre Daten schützen – oder über die Sicherheitsanforderungen in Ihrer Organisation sprechen möchten – schreiben Sie uns.

Dieser Artikel ist Teil einer Serie über Datensicherheit in den WebDisk-Diensten. Die vorherigen Teile: Verschlüsselung im Ruhezustand (SSE-S3, SSE-KMS, SSE-C), Zugriff auf S3 über STS/SSO sowie S3 Object Lock und Anti-Ransomware-Schutz.