Architektura bezpieczeństwa: Anatomia słabości.

W poprzednim artykule [link] pisałem o  nawykach, które tworzą iluzję odporności. Dziś napiszę o lukach, bo największe luki w architekturze rodzą się z milczących założeń, domyślnych ustawień i złożoności, która zamiast chronić - mnoży ryzyko. Bez weryfikacji tych miejsc odporność systemu jest tylko na papierze.

Co naprawdę psuje bezpieczeństwo architektury?

Największym wrogiem nie są braki w dokumentacji, tylko milczące założenia. To, co uznaliśmy za oczywiste; to, o co nikt nie zapytał na etapie projektowania; to, co „każdy wie”. Kilka domyślnych ustawień, które przeżyły trzy migracje i pięciu właścicieli. Kilka skrótów, bo „deadline”. Do tego nasze ulubione modne hasła, które przykrywają niewygodne detale:

► chmura „domyślnie bezpieczna”
► „Zero Trust wdrożone”,
► „MFA wszędzie”.

Brzmi dobrze. A potem przychodzą fakty.

Nie trzeba długo szukać przykładów, wystarczy:

► jeden SSRF (Server-Side Request Forgery) i nieprzemyślana konfiguracja wokół metadanych instancji, by role i tokeny otworzyły wrota do danych, które nigdy nie miały wyjść na świat,

► kilka kont bez wymuszonego MFA, nie u nas, u zewnętrznego dostawcy, by nagle ten właśnie zaufany partner, z którym od lat współpracujemy stał się naszym największym ryzykiem,

► aktualizacja agenta bezpieczeństwa, która pójdzie w złą stronę i pół świata staje na niebieskim ekranie.

Nie dlatego, że narzędzia są złe. Dlatego, że architektura opiera się na zależnościach.

Na usta ciśnie mi się znany cytat z kultowego filmu Shrek, lekko zmodyfikowany pod IT:
Shrek: Systemy IT są… mniej więcej jak cebula!
Osioł: Bo się od nich płacze?
Shrek: NIE! Warstwy! Cebula ma warstwy! Dociera? Systemy mają warstwy…

Każdy system IT składa się z warstw i połączeń: usługi zależą od baz danych, bazy od infrastruktury, a infrastruktura od narzędzi zarządzania. Administrator też jest jedną z warstw, jak i również proces czy procedura.
Jeśli jedna warstwa zawiedzie, może pociągnąć za sobą całość. I nieważne, jak solidny jest pojedynczy komponent, jeśli wszystkie krytyczne elementy spoczywają na jednym wspólnym punkcie, to ten punkt staje się najsłabszym ogniwem.

Kiedy pytam organizacje o ich odporność, nie interesuje mnie, jak wygląda ostatni raport z audytu, tylko czy potrafią odpowiedzieć na proste, wręcz niewygodne pytania:
► Co stanie się, jeśli zawiodą kontrolery domeny?
► Jak architektura reaguje na incydenty wewnętrzne?
► Czy nasze założenia o granicach systemu są nadal aktualne w epoce pracy zdalnej i chmury?
► Jakie komponenty pozostają poza radarem, bo są starsze, ukryte albo niepasujące do standardowych schematów?

To właśnie w takich miejscach kryją się słabości, które mogą sparaliżować cały biznes. Doświadczenie pokazuje, że odporna architektura nie powstaje dzięki stosowi narzędzi, tylko dzięki kulturze zadawania pytań.
I nie chodzi o pytania akademickie, ale te niewygodne, które podważają oczywistości. Architektura jest bezpieczna nie wtedy, kiedy mamy checklistę zgodności, ale wtedy, gdy potrafimy zakwestionować każdy element i wytłumaczyć, dlaczego akurat tak został zaprojektowany. Gdy ktoś ma odwagę powiedzieć: „a co, jeśli się mylimy?”.

Paradox of Complexity

Bezpieczeństwo musi odpowiadać na potrzeby, nie na modę. Nie chodzi o to, żeby zawsze wdrażać najcięższe działa. Bezpieczeństwo dostosowuje się do realnych potrzeb i ryzyka, a nie do tego, co akurat jest modne w katalogach vendorów.
Nie strzelamy z armaty do wróbla. Jeżeli proces biznesowy wymaga ochrony na określonym poziomie, to architektura powinna ten poziom zapewniać, ale nie więcej i nie mniej. W przeciwnym razie albo przepalamy zasoby, albo tworzymy iluzję bezpieczeństwa.

Coraz częściej mamy do czynienia ze zjawiskiem Paradox of Complexity. Dokładamy kolejne narzędzia i rozwiązania bezpieczeństwa, wierząc, że każde z nich zmniejsza ryzyko. W praktyce bywa odwrotnie. Każda nowa warstwa to dodatkowa konfiguracja, integracja i utrzymanie.
Złożoność architektury staje się ryzykiem samym w sobie: mnogość funkcji i punktów integracji zwiększa szansę, że coś przeoczymy, źle ustawimy albo nie zauważymy kolizji.

Paradoks polega na tym, że dokładając kolejne produkty, możemy zamiast zmniejszać ryzyko to podnosić je.

Przykłady:

► Log4j (CVE-2021-44228) - organizacje z wieloma nakładającymi się narzędziami skanowania i monitorowania wcale nie reagowały szybciej. Chaos procesów i brak spójności sprawił, że łatki były wdrażane fragmentarycznie, a odpowiedzialność rozmyta.
► Chmurowe polityki dostępu (IAM, Identity and Access Management) - nadmierna granularność reguł zwiększa ryzyko błędnej konfiguracji. W teorii chroni lepiej, w praktyce bywa groźniejsze niż prostsze podejście.

Podsumowanie

Największe luki nie rodzą się z braku narzędzi, ale z założeń, których nikt nie zweryfikował.

Druga lekcja brzmi: To nie spektakularne błędy, ale codzienne skróty i niezweryfikowane założenia podważają bezpieczeństwo architektury.

Skoro znamy miejsca pęknięć, to jak to przełożyć diagnozę - tu i teraz?

W kolejnym artykule pokażę, jak decyzje o tożsamości i detekcji przekładają się na odporność - zanim zaczniesz myśleć o narzędziach.

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.