Architektura bezpieczeństwa: Tożsamość i detekcja. 

Granice systemu wyznacza dziś tożsamość, a odporność zaczyna się tam, gdzie detekcja projektowana jest jak kod. To nie narzędzia decydują o sile architektury, ale decyzje o tym, kto i w jaki sposób ma prawo działać w systemie oraz czy organizacja widzi to, co naprawdę się dzieje.

W tym artykule, pokażę Ci różne rozwiązania i podejścia, ale nie traktuj ich jako gotowej recepty do natychmiastowego wdrożenia. Każda organizacja działa w innym kontekście, ma inne procesy, priorytety i ograniczenia. To, co sprawdza się w jednej firmie, w innej może być zbędnym ciężarem albo wręcz źródłem dodatkowego ryzyka.

Moim celem nie jest dać Ci listę obowiązkowych narzędzi, ale otworzyć przestrzeń do refleksji i pokazać wachlarz możliwości. Dopiero Ty, znając realne potrzeby swojego biznesu, poziom dojrzałości zespołu i apetyt na ryzyko, możesz zdecydować, które z tych podejść mają sens w Twoim otoczeniu, a które lepiej zostawić na później albo całkowicie pominąć.

Architektura to przede wszystkim tożsamość

Granice systemów zniknęły. Kiedyś mówiliśmy: „Jesteś w naszej sieci, więc ci ufamy”. Dziś sieć nie ma już wyraźnych granic, mamy chmurę, pracę zdalną, partnerów i integracje. Dlatego tożsamość, czyli to kim jesteś i jakie masz uprawnienia w danym momencie, stała się fundamentem.

Zero Trust nie polega na firewallach i filtrowaniu IP oraz portów, ale na pytaniach:
► Czy każdy dostęp (człowieka, usługi czy skryptu automatyzacji) jest sprawdzany pod kątem kontekstu?
► Czy uprawnienia są naprawdę minimalne i nadawane tylko wtedy, gdy są potrzebne, zamiast wisieć „na zawsze”?
► Czy mamy plan awaryjny na wypadek, gdy system uwierzytelniania się zepsuje, żeby nie zatrzymać całej firmy?

Deklaracje o Zero Trust łatwo wpisać do prezentacji, ale prawdziwa architektura zaczyna się od porządku w tożsamości i odwagi ograniczania przywilejów.

Detekcja i reakcja to część architektury, a nie czynność „po fakcie”

W wielu firmach detekcja incydentów jest traktowana jako obowiązek SOC-u (Security Operations Center), a nie jako integralny element architektury. To błąd, jeśli bezpieczeństwo kończy się na „operacji po fakcie”, a SOC służy tylko do wykrywania incydentów, to w praktyce oznacza, że system był bezbronny w czasie rzeczywistym.

Architektura odporna nie zaczyna się od SIEM-a (Security Information and Event Management), ale od założenia, że zdolność do wykrycia anomalii musi być projektowana razem z systemem, nie obok niego.

Logi, które nie mają kontekstu ani spójności czasowej, są jak puzzle z różnych pudełek, może i coś widać, ale nikt nie wie co. Dlatego logowanie musi być spójne, bogate w dane kontekstowe (kto, co, kiedy, gdzie, jak), powiązane z tożsamością i procesem biznesowym. Telemetria nie może kończyć się na aplikacji, potrzebujemy jej również z brokerów API (Application Programming Interface), IdP (Identity Provider), warstwy danych i sieci.

Detekcja nie powinna być „czarną magią” w rękach kilku analityków. W nowoczesnej architekturze reguły detekcji są kodem:
► mają wersjonowanie,
► przechodzą code review,
► są testowane jednostkowo i rozwijane w repozytorium obok kodu systemu.

Dzięki temu reguły są zrozumiałe, powtarzalne i skalowalne.
A co najważniejsze, dają się aktualizować tak samo szybko, jak reagujemy na nowe zagrożenia. Reguły SIEM powinny być również obecne w procesie aktualizacji/zmiany konfiguracji źródeł, które dostarczają logów. np. czy reguły dla firewalla, po wgraniu na nim nowej wersji oprogramowania, nadal działają w ten sam sposób.

Reguły detekcji układają scenariusze reakcji, które wynikają z mapowania zagrożeń, ale również z procedur wewnątrz firmy. Czyli SOC nie czeka aż się wydarzy incydent, tylko jest krok wcześniej. Dba o to, aby błędy w stosowaniu wewnętrznych procedur nie doprowadziły do powstania incydentu np. czy helpdesk nie wyłączył użytkownikowi MFA, bo ten musiał oddać telefon do naprawy, nie było zastępczego, a na prywatnych nie chciał sobie instalować aplikacji z kodami (przypadek prawdziwy, skrzynka pocztowa została przejęta).

W tej logice bezpieczeństwo staje się częścią cyklu życia oprogramowania jak i wewnętrznych procesów i procedur. Działy bezpieczeństwa nie są „inspektorami końcowymi”, tylko współtwórcami reguł i polityk. To zmienia sposób myślenia: z „czy mamy narzędzie” na „czy nasza architektura wie, że coś jest nie tak i odpowiednio to zasygnalizuje”. A to z kolei prowadzi do zupełnie innego poziomu gotowości zorientowanego nie na gaszenie pożarów, ale na zapobieganie ich powstawaniu.

Podsumowanie

Odporna architektura tożsamości i detekcji to nie kwestia narzędzi, ale nawyków decyzyjnych. Granice systemu wyznacza dziś tożsamość. Odporność zaczyna się tam, gdzie detekcja staje się kodem.

Trzecia lekcja brzmi: Architektura odporności zaczyna się od świadomego zarządzania tożsamością i od detekcji wpisanej w projekt od pierwszego dnia.

Skoro wiemy już, kto i co, to jak to przetestować operacyjnie?
W kolejnym artykule pokażę, jak zabezpieczyć łańcuch dostaw, kopie zapasowe i segmentować sieć?

Karol Kij
Dyrektor Działu Rozwiązań Cyberbezpieczeństwa | Ambasador CyberOdporności
CyberShieldON

CyberShieldON – Gdy wiedza spotyka decyzję.
Tutaj cyberbezpieczeństwo to nie tylko technologia, ale też konsekwencje wyborów, ryzyko systemowe i odpowiedzialność.
Łączymy doświadczenie z projektów z refleksją nad tym, jak naprawdę działa organizacja i jak ją chronić. Dzielimy się praktyką, która wytrzymała presję, oraz pytaniami, które zmieniły kierunek działania.

To miejsce jest dla Ciebie, jeśli tworzysz systemy, zarządzasz bezpieczeństwem, projektujesz architekturę i nie zatrzymujesz się na poziomie technologicznym.

Nowe artykuły – regularnie na cybershieldon.pl

Strona www stworzona w kreatorze WebWave.