Czyli jak łączyć architekturę systemów z realnym bezpieczeństwem biznesu
Jeszcze 10 lat temu moja praca polegała głównie na dostarczaniu funkcjonalności. Kod miał działać. Dziś, bogatszy o dekadę doświadczeń, patrzę na projekty IT zupełnie inaczej – przez pryzmat architektury, rentowności i przede wszystkim bezpieczeństwa. DevSecurity to dla mnie nie tylko modne hasło, ale codzienna higiena pracy przy serwerach i kodzie.
Oto jak w praktyce łączę optymalizację backendu z twardymi regułami security, bazując na wdrożeniach m.in. dla BikeAtelier, Sensualnie24 czy Shopon.pl.
1. Fundament: Twarda konfiguracja serwera (Hardening)
Bezpieczeństwo zaczyna się tam, gdzie kończy się domyślna konfiguracja. W przypadku wdrażania własnych serwerów (czy to dedykowanych w kolokacji, czy VPS np. na Oracle Cloud), kluczowe jest odejście od standardów, które znają wszyscy hakerzy.
W moich projektach (np. dla klienta WilkSoft) standardem jest „zamykanie drzwi”:
• Zmiana domyślnego portu SSH i bezwzględne wyłączenie logowania przez roota.
• Konfiguracja fail2ban oraz iptables do aktywnego blokowania prób włamań.
• Separacja uprawnień – przydzielanie sudo tylko wskazanym użytkownikom.
To pierwsza linia obrony. Jeśli nie wpuścisz intruza na poziomie sieci, nie będzie miał szansy testować luk w Twojej aplikacji PHP.
2. Filtracja ruchu: Nie każdy gość jest mile widziany
W e-commerce (jak w przypadku BikeAtelier.pl) ruch to pieniądz, ale tylko ten wartościowy. Częstym problemem są boty, ataki DDoS czy ruch z krajów, które biznesowo nas nie interesują, a generują zagrożenie.
Moje rozwiązanie? Agresywna polityka na poziomie CloudFlare i serwera:
• Blokowanie ruchu z krajów wysokiego ryzyka (np. Rosja, Korea Północna), co natychmiast odciąża serwer.
• Synchronizacja bazy z listami adresów IP sieci TOR, serwerów proxy i znanych spamerów. Wdrożyłem mechanizm filtracji w czasie rzeczywistym, który drastycznie zredukował liczbę podejrzanych wejść i prób ataków.
3. Dane: Im mniej wiesz, tym bezpieczniej śpisz (Data Minimization)
Jednym z najczęściej pomijanych aspektów DevSecurity jest redundancja danych. Przechowywanie starych logów czy statystyk to proszenie się o kłopoty w przypadku wycieku.
Podczas audytu jednego ze sklepów odkryłem ponad 40 milionów rekordów ze statystykami i 1,2 miliona rekordów w logach, które zbierały się latami.
• Działanie: Napisałem skrypt, który cyklicznie czyścił te dane, a konfigurację zmieniłem tak, by logowane były wyłącznie błędy, a nie wszystko jak leci.
• Efekt: Mniejsza baza danych to nie tylko szybszy sklep (optymalizacja performance), ale też mniejsza powierzchnia ataku.
W projekcie Shopon.pl poszedłem o krok dalej w kwestii Privacy by Design. Przy weryfikacji sprzedawców zrezygnowaliśmy z ręcznego procesowania numerów kont. System automatycznie pobierał dane z przelewu aktywacyjnego (1,01 zł) poprzez integrację z PayU, eliminując „czynnik ludzki” i ryzyko wycieku danych wrażliwych podczas ich przepisywania.
4. Kod: Aktualizacja to nie opcja, to konieczność
Dług technologiczny to dziura w bezpieczeństwie. Utrzymywanie starych wersji PHP (np. 5.x) to ryzyko. W moich wdrożeniach standardem jest migracja do najnowszych stabilnych wersji (obecnie PHP 8.x). Dlaczego?
• Bezpieczeństwo: Nowe wersje mają załatane luki.
• Wydajność: PHP 8.x z mechanizmem JIT i OPcache potrafi przyspieszyć wykonywanie kodu nawet o 30%.
Dodatkowo, audyt kodu (Code Review) obejmuje usuwanie zbędnych modułów. Każdy nieużywany moduł w PrestaShop czy WordPress to potencjalna furtka dla hakera. Jeśli czegoś nie używasz – odinstaluj to.
5. Monitoring: Bądź pierwszy, który wie o awarii
Bezpieczeństwo to także dostępność (Availability). Atak często kończy się niedostępnością serwisu. Aby nie dowiadywać się o awarii od wściekłego klienta, buduję własne narzędzia monitorujące. Dla moich projektów stworzyłem aplikację zewnętrzną, która co kilka minut sprawdza status serwerów. Brak odpowiedzi? Natychmiastowy alert na Telegram i e-mail. To pozwala na reakcję zanim problem eskaluje.
DevSecurity to proces ciągłego zarządzania ryzykiem. To przejście od myślenia „czy to działa?” do „czy to jest bezpieczne i odporne?”. Niezależnie od tego, czy wdrażam separację bazy danych na osobny serwer dla wydajności, czy blokuję ruch z Singapuru – cel jest jeden: stabilny, szybki i bezpieczny biznes klienta.