Zabezpieczamy Twoją aplikację, żeby dane były chronione, a system dostępny każdego dnia
Sprawdzamy kod i konfigurację, wdrażamy poprawki i domykamy techniczną stronę RODO, żeby aplikacja działała stabilnie i zgodnie z prawem. Wiesz przy tym, kto ma dostęp do Twoich danych, jak długo trzymamy kopie i co dzieje się w pierwszej dobie po zgłoszeniu naruszenia.
Pilnujemy szczegółów, które najczęściej decydują o bezpieczeństwie Twoich danych
Zwykle liczą się drobiazgi: publicznie dostępny katalog z kodem, aktywne konto administratora po osobie, która odeszła z zespołu, wtyczka bez wsparcia producenta czy środowisko testowe z prawdziwymi danymi widoczne w wyszukiwarce. Sprawdzamy każdy taki punkt i domykamy go, zanim stanie się problemem, żeby Twoje dane pozostały pod ochroną.
Czytamy kod i sprawdzamy, jak aplikacja reaguje na dane wysyłane wprost do niej, z pominięciem ekranu użytkownika — tam kryją się usterki, których nie widać na pierwszy rzut oka. Dostajesz listę miejsc do poprawy z nazwą pliku, opisem i priorytetem, dzięki czemu wiesz, co naprawić najpierw i ile to zajmie.
Przegląd kodu
XSS, SQL injection, IDOR, endpointy bez sprawdzenia uprawnień
Dostępy i sekrety
Imienne konta z MFA, sekrety w menedżerze haseł, rotacja po zmianie w zespole
Serwer i TLS
nginx, TLS 1.2/1.3, HSTS, certyfikaty Let's Encrypt z autoodnawianiem
Dane i retencja
Logi 90 dni, kopie 30 dni, test odtworzenia raz na kwartał
Czym się zajmujemy
Od jednorazowego audytu, przez sprzątanie po infekcji, po utrzymanie środowiska.
Audyt aplikacji i sklepu
Aplikacja, panel i integracje. Raport porządkuje znaleziska według priorytetu i nakładu godzin.
Przegląd kodu
Analizę robimy ręcznie, bo najpoważniejsze błędy dotyczą logiki działania aplikacji — automat ich nie wychwyci, choć formalnie wszystko działa.
Sekrety, klucze i konta
Hasła i klucze dostępu przenosimy z kodu do bezpiecznego menedżera, przeglądamy uprawnienia i wymieniamy klucze, żeby dostęp do systemu miały tylko właściwe osoby.
Utwardzenie serwera
Konfigurujemy serwer (nginx, TLS 1.2/1.3, HSTS i CSP), a panel oraz usługi wewnętrzne chowamy z publicznego adresu, żeby połączenie było szyfrowane, a dostęp ograniczony do zaufanych osób.
Kopie i odtworzenie
Kopie trzymamy poza serwerem produkcyjnym i szyfrujemy przed wysyłką, a raz na kwartał odtwarzamy je na czystej maszynie, żebyś miał pewność, że w razie awarii da się je szybko przywrócić.
Sprzątanie po infekcji
Usuwamy ukryte furtki z WordPressa i domykamy wykorzystaną lukę, żeby po sprzątaniu system był czysty i infekcja nie wróciła.
Co sprawdzamy w audycie
Lista, którą przechodzimy zawsze. Do tego punkty wynikające z budowy konkretnej aplikacji.
- Kodowanie znaków na wejściu i wyjściu — w szablonach, w panelu i w polach klientów
- Zapytania do bazy budowane w bezpieczny, parametryzowany sposób, żeby dane od użytkownika nie mogły zmienić ich działania
- Sprawdzanie uprawnień przy każdym żądaniu do serwera, żeby dostęp do danych miały wyłącznie osoby do tego uprawnione
- Miejsca, w których mogą przypadkiem zostać hasła i klucze — w kodzie, w historii zmian i w konfiguracji strony
- Walidacja kwot, rabatów i uprawnień po stronie serwera
- Weryfikacja powiadomień z innych systemów (webhooków) i odporność na ich powtórne wywołanie, żeby np. jedna płatność nie zapisała się dwa razy
- Serwer: wersje zależności, nagłówki, certyfikaty i dostęp do konsoli hostingu
Co regularnie znajdujemy w audycie
To usterki, które w audytach powtarzają się najczęściej — sprawdzamy je u Ciebie w pierwszej kolejności.
- Aktywne konta administracyjne po osobach, które odeszły kilka miesięcy wcześniej
- Zależności i wtyczki w wersjach bez wsparcia bezpieczeństwa producenta
- Brak drugiego składnika logowania i brak limitu nieudanych prób
- Kopie zapasowe na tym samym serwerze co produkcja, przez co awaria serwera zabiera też kopię
- Kopia bazy produkcyjnej na środowisku testowym, bez anonimizacji
- Staging bez blokady indeksowania i bez blokady wysyłki maili na zewnątrz
- Adresy e-mail i całe treści żądań zapisywane do logów bez filtrowania
- Hasła hashowane algorytmem MD5 lub SHA1, czasem bez soli
- Endpointy API bez uwierzytelnienia, bo pilnował ich tylko interfejs
- Powiadomienia z innych systemów (webhooki) przyjmowane bez weryfikacji, że pochodzą z zaufanego źródła
- Katalog
.git, zrzuty bazy i archiwa ZIP pod publicznym adresem - Brak wymuszonego szyfrowania połączeń (HSTS, CSP) i certyfikat odnawiany ręcznie, łatwy do przeoczenia
Osiem pytań, które warto nam zadać przed podpisaniem umowy
Te same zadajemy dostawcom, którzy dostają dostęp do naszej infrastruktury.
Kto ma dostęp do Twojego kodu i Twoich 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 w menedżerze haseł, z dostępem per projekt — nigdy w repozytorium ani na komunikatorze. Klucze rotujemy po każdej zmianie w zespole.
Gdzie fizycznie leżą Twoje dane?
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.
Jak długo trzymamy kopie zapasowe i logi?
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.
Czy dane produkcyjne trafiają na środowisko testowe?
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.
Jak kod trafia na produkcję i jak szybko łatamy podatności?
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.
Co robimy, gdy system padnie w nocy
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.
Co się dzieje, gdy dojdzie do naruszenia ochrony danych?
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.
Czy Twój kod widzą narzędzia AI?
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.
Co trzymamy, gdzie i jak długo
Tabela dotyczy naszej infrastruktury. Dane w Twoich systemach zostają u Ciebie.
| Co | Gdzie leży | Jak zabezpieczone | Jak długo |
|---|---|---|---|
| Kod i historia zmian | Twoje repozytorium na GitHubie | Imienne konta, MFA, wymuszony przegląd zmian | Kopia robocza znika 30 dni po współpracy |
| Kopie bazy produkcyjnej | Zdalny storage w EOG | Szyfrowane przed wysyłką, klucz poza serwerem | 30 dni |
| Zrzut bazy przed wdrożeniem | Serwer wdrożeniowy | Szyfrowany dysk, dwa imienne konta | 14 dni |
| Logi aplikacyjne | Serwer aplikacji | Filtr pól z hasłami, tokenami i numerem PESEL | 90 dni |
| Sekrety i konfiguracja | Menedżer haseł, dostęp per projekt | Rotacja po zmianie w zespole | Do końca współpracy |
Co zostaje u nas, gdy kończymy współpracę
W ciągu 30 dni usuwamy kopie repozytorium, zrzuty baz i pliki robocze, a potwierdzenie wysyłamy na piśmie, z datą. Dostajesz listę kont do dezaktywacji i kluczy do rotacji. Umowę powierzenia z art. 28 RODO podpisujemy, zanim dostaniemy pierwsze hasło, żeby zasady były jasne od samego początku współpracy.
Czego nie robimy — i czym możemy to udowodnić
Trzy rzeczy, których u nas nie znajdziesz
Nie mamy certyfikatu ISO 27001 ani raportu SOC 2 i nie zamierzamy udawać, że mamy. Jeśli Twój dział zakupów wymaga takiego dokumentu, powiedz o tym na pierwszej rozmowie — nie jesteśmy wtedy właściwą firmą.
Nie prowadzimy testów penetracyjnych. To osobna specjalizacja z własnym warsztatem i własną odpowiedzialnością. Wskazujemy firmę, która robi to zawodowo, wdrażamy poprawki z jej raportu i prosimy o retest tych samych punktów.
Nie deklarujemy „pełnej zgodności z RODO”. Zgodność dotyczy Twojej organizacji — rejestru czynności, podstaw prawnych, umów. My odpowiadamy za mechanizmy po naszej stronie i za to, żeby aplikacja ich nie łamała. Polityki prywatności nie piszemy: dostarczamy prawnikowi fakty, na których ją oprze.
Sprawdź to sam, w jedną minutę
Wpisz curl -I https://twojadomena.pl i sprawdź, czy jest nagłówek Strict-Transport-Security. Tak samo sprawdzamy każdy system, który wdrażamy — i tak samo możesz sprawdzić nas. Na życzenie odsyłamy tego samego dnia roboczego:
- Wzór umowy powierzenia — do przekazania prawnikowi przed rozmową o zakresie
- Listę podprocesorów z nazwami: hosting, poczta, monitoring, kopie zapasowe
- Przykładowy raport z przeglądu kodu, z zanonimizowanego projektu
- Checklistę przekazania projektu innej firmie — tę samą, której użyjemy, jeśli odejdziesz
- Wynik ostatniego testu odtworzenia kopii: datę, czas przywrócenia, co poszło nie tak
Jak wygląda audyt, krok po kroku
Zakres i zasady testów
Spisujemy wersje, zależności, integracje i to, kto ma do czego dostęp. Ustalamy, czego nie wolno ruszać.
Analiza i próby nadużyć
Przegląd kodu i kontrolowane próby nadużyć na kopii środowiska. Każde znalezisko dostaje priorytet i szacunek godzin.
Poprawki
Naprawy wdrażamy najpierw poza produkcją, z testami regresji. Kolejność uzgadniamy z Tobą.
Retest i utrzymanie
Sprawdzamy ponownie te same punkty i zamykamy raport. Dalej monitoring, aktualizacje, kopie.
Gdy incydent już trwa, kolejność ma znaczenie
Najpierw zabezpieczamy kopię stanu i logi, potem odcinamy dostęp i szukamy punktu wejścia. Lukę zamykamy, zanim usuniemy złośliwy plik, żeby problem nie wrócił. Serwis przywracamy na końcu: wymieniamy hasła i klucze, sprawdzamy ukryte konta i doklejone przekierowania.
Pytania, które padają najczęściej
Dostaniemy coś więcej niż wydruk ze skanera?
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.
Dlaczego nie pokazujecie nazw klientów ani zrzutów ekranu?
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. Twoje wdrożenie zostaje objęte tą samą dyskrecją.
Czy raport możemy dać innej firmie do wykonania poprawek?
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.
Podejrzewamy, że strona jest zainfekowana. Od czego zacząć?
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.
Ostatnia aktualizacja tej strony: sierpień 2026
Zmiany merytoryczne oznaczamy. Jeśli zmieni się okres retencji, dostawca hostingu albo procedura zgłaszania naruszeń, napiszemy o tym wprost.
Zyskaj pewność, że Twoja aplikacja i dane są pod ochroną
Napisz, na czym stoi Twoja aplikacja i co Cię niepokoi. Odsyłamy zakres audytu i termin. Przy podejrzeniu włamania odzywamy się tego samego dnia.
Porozmawiajmy