Audyt bezpieczeństwa aplikacji i danych.

Wyłącznie imienne konta z kluczami SSH i MFA. Do produkcji loguje się dwoje nazwanych ludzi, reszta pracuje na środowisku testowym. Konta wygasają w dniu zakończenia współpracy. Sekrety i pliki .env trzymamy wyłącznie w menedżerze haseł, z dostępem per projekt, poza repozytorium i komunikatorami. Klucze rotujemy po każdej zmianie w zespole.

W serwerowniach na terenie EOG — Warszawa albo Frankfurt. Dysk serwera szyfrowany, ruch po TLS 1.2/1.3 z wymuszonym HSTS. Kopie szyfrujemy przed wysyłką na zdalny storage, a klucze do nich trzymamy poza serwerem, którego dotyczą. Listę podprocesorów z nazwami wysyłamy na życzenie.

Pełna kopia raz na dobę, przyrostowa co godzinę, retencja 30 dni. Raz na kwartał odtwarzamy kopię na czystym serwerze i mierzymy czas przywrócenia, bo dopiero odtworzona kopia daje pewność, że zadziała w razie awarii. Logi trzymamy 90 dni, bez haseł, tokenów i numerów PESEL: filtrujemy po nazwach pól, zanim cokolwiek trafi na dysk.

Nie w oryginalnej postaci. Przed zrzutem uruchamiamy skrypt anonimizujący adresy e-mail, telefony, numery dokumentów i dane płatnicze; zostaje on w Twoim repozytorium. Produkcja, staging i środowiska lokalne mają osobne bazy, klucze i konta pocztowe. Staging nie wysyła maili na zewnątrz.

Każdy pull request przechodzi przegląd drugiej osoby — nikt nie wypuszcza własnego kodu na produkcję. CI uruchamia testy, analizę statyczną i skan zależności (composer audit, npm audit). Zależności aktualizujemy co miesiąc, a podatności o wskaźniku CVSS 9.0 i wyżej łatamy w 72 godziny, również w weekend.

Przed wdrożeniem robimy zrzut bazy i oznaczamy wersję. Wycofanie to jedno polecenie i mniej niż minuta przestoju. Na produkcję nie wdrażamy w piątek po 15:00. Monitoring wpinamy w Twój kanał na Slacku — alert o błędzie 500 widzisz w tej samej minucie co my. Na awarię krytyczną odpowiadamy w 4 godziny robocze.

O podejrzeniu naruszenia informujemy Cię w 24 godziny od wykrycia, żebyś zdążył ze zgłoszeniem do UODO w ustawowych 72. Dostajesz zakres i kategorie danych, przedział czasu, listę systemów oraz opis tego, co już zamknęliśmy. Przy włamaniu najpierw zabezpieczamy logi, bo to one pozwalają ustalić, którędy ktoś wszedł, i zamknąć tę drogę na dobre.

Korzystamy z biznesowych wersji narzędzi AI, w których dostawca umownie wyklucza trenowanie modeli na przesyłanych danych. Sekretów, plików .env ani danych produkcyjnych do nich nie wklejamy. Jeśli Twoja polityka zabrania tego w całości, pracujemy bez nich i mówimy o tym przed startem.

Skaner traktujemy jako punkt wyjścia do właściwej analizy. Najpoważniejsze błędy dotyczą logiki działania aplikacji: żądanie do serwera bez sprawdzenia uprawnień, identyfikator, który da się podmienić, dane z przeglądarki przyjęte na słowo. Automat ich nie wychwyci, bo formalnie wszystko działa, dlatego przeglądamy kod ręcznie i pokazujemy Ci, co realnie wymaga poprawy.

Bo znalezisko z audytu to w praktyce instrukcja obsługi luki — opublikowane szkodzi właścicielowi systemu również po naprawie, bo ten sam błąd siedzi zwykle w kilku miejscach tego samego kodu. Dlatego mówimy o klasach błędów, liście kontrolnej audytu i własnych zasadach dostępu — tych samych, które stosujemy u Ciebie.

Tak, raport jest Twój i nie ma w nim zapisów, które by to blokowały. Każda pozycja ma lokalizację w kodzie i opis naprawy, więc zrobi to Twój zespół albo dowolny wykonawca.

Odezwij się do nas, zanim cokolwiek wyczyścisz. Nienaruszone pliki i logi pozwalają nam ustalić, którędy ktoś wszedł, i zamknąć tę drogę. Zabezpieczamy stan, szukamy punktu wejścia, usuwamy ukryte furtki i domykamy lukę, żeby system wrócił do stabilnej pracy.