Logowanie
Bezpieczeństwo danych w systemie BHP Panic – standard NIST
Jako CLOUDPANIC, naszą najważniejszą misją jest dostarczać bezpieczne, wydajne aplikacje . Specjalizujemy się w budowaniu rozwiązań narażonych na duży ruch, które ze względu na specyfikę biznesu są wyjątkowo narażone na próby ataków. Nasze systemy przetworzyły transakcje o wartości przekraczającej 350 mln zł.
Architektura oparta na standardzie NIST
Kiedy projektowaliśmy architekturę bezpieczeństwa BHP Panic zależało nam na czymś więcej niż checkliście wymagań. NIST dał nam spójny model myślenia: co chronić, jak wykrywać próby ataku i co robić gdy coś pójdzie nie tak. Bezpieczeństwo wbudowaliśmy w każdy etap — od pierwszego commita aż po wdrożenie na produkcję.
Czym jest standard NIST?
NIST (National Institute of Standards and Technology) to amerykański instytut standaryzacyjny. Jego Cybersecurity Framework wyróżnia się tym że zamiast listy wymagań daje model myślenia: Identyfikacja, Ochrona, Detekcja, Reagowanie i Odzyskiwanie.
Zanim zdecydowaliśmy się na NIST rozważałiśmy też inne frameworki — m.in. ISO 27001. Wybraliśmy NIST bo lepiej pasuje do środowisk chmurowych i nie zakłada że cała infrastruktura jest jednorodna.
Zanim zdecydowaliśmy się na NIST rozważałiśmy też inne frameworki — m.in. ISO 27001. Wybraliśmy NIST bo lepiej pasuje do środowisk chmurowych i nie zakłada że cała infrastruktura jest jednorodna.
Ochrona warstwy aplikacyjnej
WAF i firewall nowej generacji
Każde żądanie do aplikacji przechodzi przez Web Application Firewall zanim trafi do któregokolwiek z naszych serwisów. WAF blokuje skanery, próby SQL injection i inne typowe ataki automatycznie — bez naszej interwencji. Reguły aktualizujemy regularnie bo zagrożenia ewoluują szybciej niż kwartalny update. Poza WAF-em mamy firewall nowej generacji z modułem IDS/IPS między strefami aplikacji. Kilka razy wyłapał podejrzaną komunikację zanim zdążyliśmy sami zauważyć ją w logach.
Bezpieczna architektura kontenerowa
Cały system BHP Panic działa w kontenerach. Bazowe obrazy budujemy na minimalistycznych dystrybucjach Linuxa — kilka megabajtów zamiast kilkuset, bez zbędnych narzędzi systemowych. Każdy kontener dostaje tylko te uprawnienia których faktycznie potrzebuje — bez dostępu do powłoki ani możliwości zmiany własnej konfiguracji w trakcie działania. Jeśli atakujący dostanie się do jednego kontenera, nie może stamtąd przeskoczyć do reszty systemu.
Na czym polega konteneryzacja?
Konteneryzacja to sposób uruchamiania aplikacji w specjalnie „spakowanych” środowiskach zwanych kontenerami. Możesz wyobrazić sobie kontener jak pudełko, w którym znajdują się wszystkie potrzebne elementy do działania programu: pliki, biblioteki, konfiguracje. Dzięki temu aplikacja działa zawsze tak samo – niezależnie od komputera, serwera czy chmury, na których zostanie uruchomiona. To trochę tak, jakby wysłać komuś danie w pudełku, które zawiera nie tylko samo jedzenie, ale też dokładnie te talerze i sztućce, których potrzeba, więc wiadomo, że da się je wszędzie zjeść.
Drugą ważną cechą konteneryzacji jest izolacja. Każdy kontener działa osobno, nie mieszając się z innymi aplikacjami. Jeśli jedna aplikacja przestanie działać prawidłowo, nie wpływa to na resztę systemu. w tradycyjnym podejściu programy dzieliły między sobą dużo wspólnych elementów systemowych, przez co problemy lub aktualizacje jednego mogły zaburzyć pracę innych. Kontenery rozwiązują to, zapewniając większe bezpieczeństwo, stabilność i łatwość zarządzania całym środowiskiem.
Drugą ważną cechą konteneryzacji jest izolacja. Każdy kontener działa osobno, nie mieszając się z innymi aplikacjami. Jeśli jedna aplikacja przestanie działać prawidłowo, nie wpływa to na resztę systemu. w tradycyjnym podejściu programy dzieliły między sobą dużo wspólnych elementów systemowych, przez co problemy lub aktualizacje jednego mogły zaburzyć pracę innych. Kontenery rozwiązują to, zapewniając większe bezpieczeństwo, stabilność i łatwość zarządzania całym środowiskiem.
DevSecOps i testy penetracyjne
Stała kontrola bezpieczeństwa
Każdy pull request przechodzi przez analizę SAST zanim trafi do code review. Skaner szuka podatności w kodzie — hardcoded secrets, niebezpieczne operacje na plikach, podstawowe luki logiczne. Zależności sprawdzamy osobno narzędzem SCA bo biblioteki zewnętrzne to osobna kategoria ryzyka i łatwo o tym zapomnieć.
Raz do roku zlecamy zewnętrzny pentest . Ostatni raport przyniósł kilka znalezisk kategorii medium — żadnego critical. Poprawki wdrożyliśmy w ciągu dwóch tygodni. Wolimy wiedzieć co mamy do naprawienia niż żyć z fałszywym poczuciem bezpieczeństwa.
Całe środowisko jest monitorowane. Logi z każdego serwisu trafiają do centralnego systemu który alarmuje nas gdy coś odbiega od normy. Dane szyfrujemy zarówno w spoczynku jak i w transmisji — to nie opcja to warunek.
Raz do roku zlecamy zewnętrzny pentest . Ostatni raport przyniósł kilka znalezisk kategorii medium — żadnego critical. Poprawki wdrożyliśmy w ciągu dwóch tygodni. Wolimy wiedzieć co mamy do naprawienia niż żyć z fałszywym poczuciem bezpieczeństwa.
Całe środowisko jest monitorowane. Logi z każdego serwisu trafiają do centralnego systemu który alarmuje nas gdy coś odbiega od normy. Dane szyfrujemy zarówno w spoczynku jak i w transmisji — to nie opcja to warunek.
