Projektowanie architektury bezpieczeństwa IT

Projektowanie architektury bezpieczeństwa IT porządkuje dostęp, segmentację i monitoring, ograniczając ryzyko oraz wspierając ciągłość działania firmy.

Incydent związany z przejętym kontem administratora rzadko zaczyna się od spektakularnego włamania. Częściej wynika z nadmiernych uprawnień, braku silnego uwierzytelniania, nieodseparowanej sieci lub niewidocznej aktywności w systemach. Projektowanie architektury bezpieczeństwa IT ma zapobiegać właśnie takim scenariuszom: nie przez dokładanie kolejnych narzędzi, lecz przez świadome ułożenie mechanizmów ochrony wokół najważniejszych procesów, zasobów i tożsamości organizacji.

Dla dużego przedsiębiorstwa, jednostki samorządowej czy operatora infrastruktury miejskiej bezpieczeństwo nie jest odrębną warstwą technologiczną. Jest elementem środowiska ICT, w którym współdziałają sieci IP, aplikacje, katalogi tożsamości, urządzenia końcowe, systemy komunikacji, usługi chmurowe oraz, w wielu przypadkach, technologie operacyjne. Dobra architektura pozwala tym elementom działać pod kontrolą, także wtedy, gdy jeden z nich zostanie naruszony.

Architektura zaczyna się od decyzji o ryzyku

Zakup rozwiązania klasy MFA, PAM, EDR czy SIEM może być uzasadniony, ale sam w sobie nie tworzy architektury. Problem pojawia się, gdy technologie są wdrażane punktowo, bez wspólnego modelu dostępu, klasyfikacji zasobów i zasad reagowania. Powstaje wtedy zbiór produktów, który może generować alerty, ale niekoniecznie ogranicza drogę atakującego do krytycznych danych lub usług.

Punktem wyjścia powinno być ustalenie, co organizacja chroni i jakie skutki miałoby zakłócenie działania. W praktyce chodzi nie tylko o dane osobowe czy system finansowo-księgowy. Równie istotne mogą być system obiegu dokumentów, środowisko obsługi mieszkańców, łączność dyspozytorska, systemy zarządzania obiektem, zdalny dostęp serwisantów albo infrastruktura wspierająca produkcję.

Ocena ryzyka powinna przełożyć się na konkretne decyzje projektowe. Które systemy wymagają separacji? Kto może uzyskać do nich dostęp? Czy dostawca zewnętrzny otrzymuje stałe konto, czy dostęp czasowy? Jak organizacja rozpozna nietypowe użycie uprzywilejowanych poświadczeń? Bez odpowiedzi na te pytania architektura pozostaje diagramem, a nie mechanizmem kontroli ryzyka.

Projektowanie architektury bezpieczeństwa IT wokół tożsamości

Tożsamość stała się podstawowym obwodem bezpieczeństwa. Użytkownik pracuje poza siedzibą, korzysta z aplikacji SaaS, łączy się z zasobami z urządzenia mobilnego, a administrator zarządza środowiskiem hybrydowym. W takim modelu samo zaufanie wynikające z lokalizacji w sieci nie wystarcza.

Podejście Zero Trust zakłada, że każde żądanie dostępu należy oceniać na podstawie tożsamości, kontekstu i poziomu ryzyka. Nie oznacza to automatycznie przebudowy całej infrastruktury w jednym projekcie. Oznacza konsekwentne przechodzenie od szerokiego, trwałego dostępu do dostępu minimalnego, weryfikowanego i możliwego do rozliczenia.

Najczęściej pierwszym krokiem jest uporządkowanie katalogu użytkowników i kont technicznych. Organizacja powinna wiedzieć, które konta należą do pracowników, które do usług, które są współdzielone oraz kto odpowiada za ich cykliczny przegląd. Następnie warto wdrożyć wieloskładnikowe uwierzytelnianie dla dostępu do systemów krytycznych, poczty, usług zdalnych i paneli administracyjnych. Tam, gdzie wymagany jest wyższy poziom odporności na phishing, uzasadnione jest wykorzystanie standardu FIDO2 oraz uwierzytelniania passwordless.

Szczególnej ochrony wymagają konta uprzywilejowane. Administrator domeny, operator systemu kopii zapasowych czy osoba zarządzająca zaporami sieciowymi nie powinni korzystać z tych samych poświadczeń do bieżącej pracy i zadań administracyjnych. System PAM pozwala wydzielić sesje uprzywilejowane, nadawać dostęp just-in-time, rejestrować działania oraz ograniczać ekspozycję haseł. To rozwiązanie wymaga jednak przygotowania procesowego - inwentaryzacji ról, właścicieli systemów i procedur awaryjnych. Bez tego może zostać odebrane jako przeszkoda operacyjna zamiast kontroli, która chroni organizację.

Segmentacja ogranicza zasięg incydentu

W wielu środowiskach atakujący po uzyskaniu dostępu do jednej stacji roboczej może relatywnie łatwo przemieszczać się do serwerów, systemów zarządzania lub urządzeń infrastruktury. Przyczyną nie musi być pojedynczy błąd konfiguracji. Często jest nią historycznie płaska sieć, tworzona w czasach, gdy priorytetem była wyłącznie komunikacja między systemami.

Segmentacja nie polega na podzieleniu sieci na dużą liczbę VLAN-ów dla samego podziału. Jej celem jest kontrola dozwolonych przepływów między strefami. Stacja użytkownika nie potrzebuje pełnej komunikacji z serwerem administracyjnym, a system gościnny nie powinien mieć trasy do środowiska wewnętrznego. W przypadku infrastruktury OT wymagania są jeszcze bardziej restrykcyjne, ponieważ dostępność procesów operacyjnych musi być chroniona bez ryzyka nieplanowanego zatrzymania.

Przy projektowaniu warto rozdzielić co najmniej strefę użytkowników, serwerów, zarządzania, dostępu zdalnego, usług publicznych, środowisk deweloperskich oraz urządzeń OT lub IoT, jeśli występują. Następnie należy opisać konieczne relacje komunikacyjne i egzekwować je przez zapory, listy kontroli dostępu, mechanizmy kontroli aplikacyjnej lub rozwiązania Network Access Control. Im bardziej krytyczna strefa, tym mniej powinno być wyjątków i tym lepiej powinny być one udokumentowane.

Pełna mikrosegmentacja może znacząco podnieść poziom kontroli, lecz nie zawsze jest pierwszym racjonalnym krokiem. W środowisku z wieloma starszymi aplikacjami najpierw trzeba rozpoznać realne zależności komunikacyjne. Zbyt szybkie blokowanie ruchu może przerwać działanie systemu biznesowego lub usługi publicznej. Dlatego projekt powinien uwzględniać etap obserwacji, testy, wdrożenie pilotażowe i plan wycofania zmian.

Widoczność musi prowadzić do działania

Organizacja nie jest w stanie reagować na zdarzenia, których nie rejestruje lub nie potrafi powiązać. Logi z kontrolerów domeny, systemów PAM, zapór, usług pocztowych, punktów końcowych i aplikacji krytycznych powinny tworzyć spójny obraz aktywności. Samo centralne gromadzenie danych nie wystarczy, jeśli nie określono, które sygnały wymagają reakcji i kto podejmuje decyzję poza godzinami pracy.

W dojrzałej architekturze monitoring obejmuje zarówno wykrywanie zagrożeń, jak i weryfikację skuteczności kontroli. Przykładowo, nieudane próby MFA mogą wskazywać na próbę przejęcia konta, a nietypowe użycie konta serwisowego - na nadużycie poświadczeń. Z kolei rosnąca liczba wyjątków w regułach zapory może świadczyć o utracie dyscypliny architektonicznej.

Warto ustalić cztery elementy operacyjne: źródła telemetryczne, przypadki użycia dla detekcji, procedury eskalacji oraz właścicieli decyzji. Dopiero ich połączenie pozwala zespołowi SOC lub wewnętrznemu zespołowi bezpieczeństwa skrócić czas wykrycia i ograniczenia incydentu. W przypadku organizacji o ograniczonych zasobach kadrowych usługa operacyjna może uzupełnić kompetencje zespołu, ale odpowiedzialność za priorytety biznesowe i akceptację ryzyka pozostaje po stronie organizacji.

Odporność obejmuje także odzyskiwanie działania

Architektura bezpieczeństwa powinna zakładać, że część zabezpieczeń kiedyś zawiedzie. Dlatego kopie zapasowe, odtwarzanie systemów i komunikacja kryzysowa muszą być projektowane razem z kontrolami prewencyjnymi. Backup dostępny z tej samej domeny administracyjnej, która została przejęta przez ransomware, może nie zapewnić realnej możliwości odtworzenia.

Dojrzały model uwzględnia separację kopii, ochronę ich integralności, ograniczenie uprawnień do ich usuwania oraz regularne testy odtworzeniowe. Test nie powinien ograniczać się do sprawdzenia, czy plik można przywrócić. Należy potwierdzić, czy odtworzona usługa działa poprawnie, czy zależności aplikacyjne są dostępne i czy zespół potrafi wykonać procedurę w wymaganym czasie.

Takie podejście jest szczególnie istotne dla instytucji świadczących usługi publiczne oraz przedsiębiorstw, w których wielogodzinna niedostępność systemów przekłada się na konsekwencje finansowe, prawne lub reputacyjne. Parametry RTO i RPO powinny wynikać z faktycznych potrzeb procesów, a nie z założeń technicznych przyjętych bez udziału właścicieli biznesowych.

Wdrożenie jako program, nie jednorazowy projekt

Najlepszy projekt architektury nie przyniesie efektu, jeżeli nie zostanie osadzony w procesach zakupowych, zmianowych i operacyjnych. Każda nowa aplikacja, integracja partnera czy usługa chmurowa powinna przejść proporcjonalną ocenę wymagań bezpieczeństwa. Nie chodzi o mnożenie formalności, ale o eliminowanie sytuacji, w której krytyczny system trafia do produkcji bez właściciela, MFA, zasad logowania i planu utrzymania.

Skuteczne wdrożenie zwykle rozpoczyna się od analizy stanu obecnego oraz ustalenia architektury docelowej. Kolejny etap to roadmapa podzielona na działania o największym wpływie na ryzyko: zabezpieczenie tożsamości, uporządkowanie kont uprzywilejowanych, segmentacja krytycznych przepływów, centralizacja logów i przygotowanie odzyskiwania. Taka kolejność pomaga osiągać mierzalne efekty bez paraliżowania modernizacji całego środowiska.

SprintTech realizuje tego typu działania w perspektywie pełnego środowiska ICT - od oceny ryzyka i projektu, przez integrację mechanizmów ochrony, po wsparcie operacyjne. Jest to istotne tam, gdzie decyzje bezpieczeństwa wpływają jednocześnie na sieć, dostęp użytkowników, systemy komunikacji i ciągłość usług.

Warto rozpocząć od jednego pytania, które porządkuje dalszą pracę: czy organizacja potrafi wskazać, kto, z jakiego urządzenia i na jakiej podstawie uzyskuje dostęp do jej najważniejszych zasobów? Jeżeli odpowiedź nie jest jednoznaczna, to właśnie tam znajduje się najbardziej praktyczny punkt startu dla projektu architektury bezpieczeństwa.