Ile warstw ma bezpieczeństwo Twoich plików? Za kulisami stacku open source w WebDisk
Blog WebDisk · kategoria: Bezpieczeństwo · czas czytania: ~9 minut
W skrócie:- Bezpieczeństwo WebDisk to nie jeden produkt, tylko system warstw: zapora aplikacyjna i sonda sieciowa na brzegu, czujniki wewnątrz systemów, centralna korelacja zdarzeń i automatyczne alarmowanie przez całą dobę.- Budujemy go na sprawdzonych projektach open source – m.in. Suricata, Wazuh, Falco, open-appsec – a całość obserwujemy na jednym ekranie.- Wszystko spina jedna zasada: żadne pojedyncze zabezpieczenie nie jest niezawodne – dlatego każda warstwa asekuruje pozostałe.
Gdy powierzasz komuś swoje pliki, kupujesz tak naprawdę dwie rzeczy: technologię i czujność. O technologii pisaliśmy w poprzednich odcinkach tego cyklu – o szyfrowaniu, dostępie bez stałych kluczy i kopiach, których nie da się skasować. Dziś zapraszamy za kulisy tej drugiej części: jak wygląda system, który dzień i noc czuwa nad naszą platformą – i dlaczego zbudowaliśmy go z klocków open source. Po angielsku taki zestaw współpracujących narzędzi nazywa się stackiem — i tego słowa będziemy się tu trzymać.
Filozofia: skarbiec za murami
W bezpieczeństwie nie wierzymy w pojedyncze cudowne rozwiązania. Wierzymy w obronę warstwową (defense in depth) – zasadę starszą niż informatyka, znaną z każdego banku: skarbiec ma mury, potem drzwi pancerne, potem sejf, a wszystko śledzą kamery i czujniki. Włamywacz musiałby pokonać każdą warstwę po kolei – a każda z nich ma osobny alarm.
Nasza platforma działa tak samo. Zanim żądanie z internetu dotrze do Twoich plików, przechodzi przez kolejne punkty kontroli; a nawet gdyby któryś zawiódł, kolejne warstwy obserwują, co dzieje się dalej – i podnoszą alarm, maksymalnie skracając czas między zdarzeniem a reakcją.
Dlaczego open source?
Wszystkie kluczowe elementy naszego stacku bezpieczeństwa to projekty o otwartym kodzie. To świadoma decyzja z trzech powodów:
- Przejrzystość. W zamkniętych produktach bezpieczeństwo trzeba brać na wiarę. W otwartych – każdy mechanizm można sprawdzić, a procesy zgłaszania i łatania błędów są publiczne: widać nie tylko kod, ale i to, jak projekt reaguje na znalezione słabości.
- Niezależność. Nie jesteśmy zakładnikiem licencji ani cennika. Możemy stroić, łączyć i wymieniać komponenty tak, jak wymaga tego nasza architektura – nie tak, jak pozwala umowa.
- Standardy branżowe. Suricata, Wazuh czy Falco to narzędzia, na których zespoły bezpieczeństwa opierają się od lat – korzystając z nich, korzystamy też z doświadczenia całej branży.
Jedno uczciwe zastrzeżenie: open source sam w sobie nie daje bezpieczeństwa — daje weryfikowalność. Bezpieczeństwo powstaje z konfiguracji, strojenia i codziennej pracy z tymi narzędziami. I właśnie o tej pracy jest reszta tego artykułu.
Warstwa pierwsza: brzeg – zapora, która się uczy
Cały ruch z internetu trafia najpierw na nasze serwery brzegowe. Tam pracują dwa niezależne mechanizmy:
WAF (Web Application Firewall) – zapora aplikacyjna oparta na projekcie open-appsec, która analizuje żądania HTTP kierowane do naszych aplikacji. W odróżnieniu od klasycznych zapór z listą sztywnych reguł, open-appsec wykorzystuje uczenie maszynowe: buduje model normalnego zachowania każdej usługi, by wychwytywać odstępstwa – także takie, których nie ma jeszcze w żadnej bazie sygnatur. Tryb pracy dobieramy per usługa i dojrzałość modelu: część usług zapora chroni aktywnie, blokując podejrzane żądania, a pozostałe pracują w trybie nauki i detekcji, w którym ruch jest analizowany i zasila kolejne warstwy opisane niżej – blokowanie włączamy, gdy model danej usługi dojrzeje.
Suricata – sonda sieciowa, która analizuje ruch na poziomie pakietów. Pracuje na dziesiątkach tysięcy reguł detekcji aktualizowanych na bieżąco: rozpoznaje wzorce skanowania, próby wykorzystania znanych podatności, podejrzane zachowania protokołów. Działa na całym brzegu naszej infrastruktury – nie tylko przed aplikacjami, ale i przed usługami pomocniczymi.
Warstwa druga: wnętrze – czujniki tam, gdzie dzieje się praca
Zapora na brzegu nie wystarczy – dobre bezpieczeństwo zakłada, że kiedyś ktoś może ją ominąć. Dlatego druga linia czujników pracuje wewnątrz platformy:
Falco czuwa nad działającymi kontenerami i systemami w czasie rzeczywistym – na poziomie jądra systemu operacyjnego (technologia eBPF). Wykrywa zachowania, które nie powinny się zdarzyć: proces, który nagle czyta wrażliwe pliki, kontener, który próbuje uruchomić nieoczekiwane polecenie, nietypową aktywność sieciową. To odpowiednik czujnika ruchu w skarbcu – nawet jeśli ktoś pokonał drzwi, w środku zostawia ślady, a właśnie te ślady wychwytujemy.
Do tego dochodzi monitorowanie integralności plików systemowych na kluczowych serwerach platformy (nieautoryzowana zmiana konfiguracji zostawia ślad) oraz klasyczne mechanizmy utwardzania systemów – od automatycznego blokowania adresów próbujących zgadywać hasła po restrykcyjne uprawnienia.
Warstwa trzecia: jeden obraz – SIEM, który składa sygnały w całość
Pojedynczy czujnik widzi tylko swój wycinek. Siłą całego systemu jest korelacja: zdarzenia – z zapory, z sondy sieciowej, z czujników runtime, z systemów operacyjnych – spływają do centralnego systemu klasy SIEM opartego na projekcie Wazuh, zasilanego przez agentów rozsianych po całej flocie serwerów.
To tu pojedyncze sygnały układają się w historię: nieudane logowanie na jednym serwerze to szum; to samo źródło skanujące porty, dotykające zapory i próbujące haseł na trzech systemach – to już wzorzec ataku. Wazuh klasyfikuje zdarzenia według wagi, a przy określonych scenariuszach potrafi zareagować automatycznie – bez czekania na człowieka.
Równolegle logi płyną do centralnej platformy analitycznej, gdzie są przechowywane i przeszukiwalne – bo w bezpieczeństwie równie ważna jak wykrycie jest możliwość odtworzenia przebiegu zdarzeń co do sekundy.
Warstwa czwarta: szukamy dziur u siebie – zanim znajdzie je ktoś inny
Obrona to nie tylko czekanie na atak. Stały element naszej pracy to aktywne szukanie własnych słabości:
- Skanery podatności regularnie prześwietlają całą infrastrukturę — od systemów operacyjnych po aplikacje webowe i konfigurację TLS.
- Bezpieczeństwo łańcucha dostaw: każde wydanie naszych aplikacji przechodzi przez pipeline generujący spis komponentów (SBOM), a zależności są automatycznie sprawdzane pod kątem znanych podatności – jeszcze zanim trafią na produkcję.
- Wykryte podatności trafiają do jednego, centralnego systemu, który porządkuje je według wagi i pilnuje terminów naprawy – im poważniejsza podatność, tym krótszy termin.
- Certyfikaty i szyfrowanie są monitorowane bez przerwy – o wygasającym certyfikacie wiemy na długo, zanim zauważy go ktokolwiek z zewnątrz.
Warstwa piąta: wszystko na jednym ekranie – i pod zewnętrznym nadzorem
Każdy element stacku raportuje swoją kondycję do centralnego monitoringu opartego na Grafanie i Prometheusie. Zespół widzi na bieżąco stan każdej warstwy: czy sonda działa, czy zapora analizuje ruch, czy któryś czujnik przestał raportować. Poniżej fragment prawdziwego podglądu ruchu analizowanego przez naszą sondę sieciową:
System alarmuje automatycznie o każdej porze dnia i nocy – powiadomienia trafiają do zespołu natychmiast, niezależnie od tego, czy ktoś akurat patrzy w ekran. A ponieważ „kto pilnuje strażnika?” to w monitoringu pytanie zasadnicze – sam system monitoringu jest nadzorowany przez niezależnego strażnika działającego poza naszą infrastrukturą, który podniósłby alarm nawet wtedy, gdyby cała nasza platforma zamilkła.
Część tej widoczności oddajemy zresztą Tobie: publiczna strona status.webdisk.io pokazuje na bieżąco dostępność naszych usług – bez upiększeń, prosto z systemu monitoringu.
Warstwa najważniejsza: ludzie i nawyki
Narzędzia nie zastąpią kultury pracy. Stack ma sens, bo stoi za nim codzienna praktyka:
- reguły i wyjątki są strojone – system, który krzyczy tysiąc razy dziennie bez powodu, uczy ludzi ignorowania alarmów; nasze detekcje przechodzą przez cykl strojenia, aż alarm znaczy alarm,
- konfiguracja stacku żyje w repozytoriach jako kod – zmiany są wersjonowane i odtwarzalne,
- procedury i oceny ryzyka (w tym DPIA dla funkcji przetwarzających dane) są spisane i aktualizowane, a program zgodności budujemy w oparciu o uznane ramy bezpieczeństwa,
- i wreszcie – zakładamy zawodność własnych zabezpieczeń. To nie pesymizm, tylko metoda: każda warstwa istnieje dlatego, że jakaś inna może kiedyś zawieść.
Ta ostatnia zasada dotyczy także nas samych. Dlatego publikujemy security.txt i politykę zgłaszania podatności: jeśli jesteś badaczem bezpieczeństwa i znajdziesz u nas słabość, powiedz nam o tym – wolimy usłyszeć to od Ciebie niż dowiedzieć się z incydentu.
Co z tego wynika dla Ciebie
Policzmy: brzeg, wnętrze, korelacja, własne testy, monitoring – pięć warstw technologii i jedna ludzka. Ten system pracuje w tle za każdym razem, gdy wgrywasz plik do WebDisk Files albo wysyłasz komuś link przez WebDisk Send. Nie musisz o nim wiedzieć – i właśnie o to chodzi. A tam, gdzie bezpieczeństwo styka się z Twoimi decyzjami, oddajemy Ci konkretne narzędzia, które opisaliśmy w poprzednich częściach cyklu: szyfrowanie w spoczynku (SSE), dostęp bez stałych kluczy (STS) i magazyny WORM z funkcją Anty-Ransomware.
Bezpieczeństwo to proces, nie stan – dlatego ten zestaw nieustannie ewoluuje: dochodzą nowe detekcje, nowe warstwy, nowe testy. Jeśli masz pytania o to, jak chronimy Twoje dane – albo chcesz porozmawiać o wymaganiach bezpieczeństwa w swojej organizacji – napisz do nas.
Artykuł jest częścią cyklu o bezpieczeństwie danych w usługach WebDisk. Poprzednie części: szyfrowanie w spoczynku (SSE-S3, SSE-KMS, SSE-C), dostęp do S3 przez STS/SSO oraz S3 Object Lock i ochrona Anty-Ransomware.