Architektura bezpieczeństwa: Odporność operacyjna w praktyce

System jest tak silny, jak jego najsłabsze ogniwo - w łańcuchu dostaw, w kopii zapasowej, w mostach między IT i OT. Regulacje nie są przeszkodą, ale ramą, która pozwala odróżnić iluzję od realnej odporności.

Łańcuch dostaw oprogramowania - od idei do produkcji

Kiedy mówimy o „software supply chain”, zbyt często myślimy wyłącznie o SCA (Software Composition Analysis) i zależnościach w kodzie. Tymczasem łańcuch zaczyna się dużo wcześniej, w momencie, gdy ktoś formułuje wymagania biznesowe i kończy dopiero wtedy, gdy poprawka trafia na produkcję w sposób bezpieczny, audytowalny i odwracalny.

Bezpieczna architektura oprogramowania wie, z czego jest zbudowana. Mówimy tu o SBOM (Software Bill of Materials), czyli pełnym inwentarzu komponentów i bibliotek, które składają się na aplikację. Ale sam SBOM to za mało. Potrzebujemy mechanizmów zaufanego buildu, który można odtworzyć w identyczny sposób w dowolnym momencie. Potrzebujemy podpisów cyfrowych, by mieć pewność, że artefakty są autentyczne. I potrzebujemy etapowego wdrażania, by każdy rollout można było zatrzymać lub cofnąć bez dramatów.

Odporność w łańcuchu dostaw to też kwestia zarządzania zmianą. Tu pojawiają się pytania:

► Czy wiemy, kto decyduje o tym, kiedy aktualizacja trafia na produkcję?
► Czy mamy plan testowania regresji?
► Czy wiemy, jak szybko możemy bezpiecznie wyłączyć coś, co dopiero co włączyliśmy?

Jeśli nie znamy odpowiedzi na te pytania, to nie mamy odporności, mamy nadzieję, że wszystko pójdzie dobrze.

Tu też pojawia się rola architekta: nie w rysowaniu schematów CI/CD (Continuous Integration/ Continuous Delivery/Deployment), ale w definiowaniu mechanizmów kontroli, jakimi kanałami przepływają artefakty, gdzie są punkty zatwierdzania, jakie są zasady rollbacku. To detale, które decydują, czy aktualizacja naprawia problem, czy tworzy nowy.

Kopie zapasowe - testowana praktyka, a nie formalność

Temat backupów często pojawia się na końcu dyskusji jako coś oczywistego, rutynowego. I właśnie przez to często bywa ignorowany. Znowu błędnie zadajemy pytanie „czy mamy kopię?”.

Właściwym pytaniem powinno być:

► Czy potrafimy ją odtworzyć w czasie, na który umówiliśmy się z biznesem?
► Czy jesteśmy pewni, że ta kopia nie zostanie zaszyfrowana razem z resztą w czasie ataku ransomware.

Dojrzała architektura traktuje backup jak integralną część systemu. Obejmuje nie tylko dane, ale też konfiguracje, tożsamości, polityki bezpieczeństwa, a nawet klucze szyfrujące. Testy kopii to nie raport z backupu - to regularne ćwiczenia, w których zespół musi odtworzyć system „na zegarku” i potwierdzić, że wszystko działa jak należy.

Ważnym elementem są również „czarne scenariusze”, czyli:

► Co jeśli IdP nie działa?
► Czy mamy awaryjne tożsamości w oddzielnej domenie?
► Czy mamy kopię, która nie podlega automatycznym montażom i nie jest osiągalna przez sieć produkcyjną?
► Czy nasze dane mogą być zapisane w formacie niemodyfikowalnym (WORM - Write Once Read Many)?

To nie są teoretyczne pytania, to praktyczne warunki przetrwania.

Ostatecznie backup to nie obowiązek z checklisty. To warunek konieczny, by firma mogła szybko się podnieść po poważnym incydencie. I to właśnie architektura decyduje, czy ta możliwość w ogóle istnieje - nie narzędzie.

IT spotyka OT - a segmentacja to coś więcej niż firewall

Granica między IT a OT (Operational Technology) w wielu firmach staje się coraz bardziej umowna. Dane z produkcji trafiają do systemów BI (Business Intelligence), predykcja awarii opiera się na analizach z chmury, a linie produkcyjne są coraz bardziej zinformatyzowane. W tym świecie klasyczna segmentacja typu „firewall i VLAN (Virtual Local Area Network)” przestaje wystarczać.

Architektura bezpieczeństwa musi uwzględniać nie tylko podział sieci, ale również logikę zaufania między strefami. Mówimy o jednoznacznym kierunku ruchu, kontrolowanych punktach integracji, kanałach komunikacyjnych zaprojektowanych z myślą o błędach tak, by incydent w IT nie przeniósł się automatycznie do środowiska OT.

Kluczowe są:

► Mosty: fizyczne i logiczne - muszą być zrozumiałe, zarejestrowane, kontrolowane i testowane.

► Strefy powinny być zaprojektowane z wyraźną intencją: co może się komunikować z czym i w jakich okolicznościach.

Nawet najbardziej zaawansowany system nie pomoże, jeśli ludzki błąd np. zły update, który może wywołać efekt domina na produkcji.

Podsumowanie

Nawet najlepszy backup i łańcuch nie wystarczą, jeśli architektura nie radzi sobie z granicą IT/OT i nie potrafi użyć regulacji jako ramy, a nie przeszkody.

Czwarta lekcja brzmi: Odporność to nie raporty, ale łańcuch dostaw i backup, które potrafią działać w prawdziwym kryzysie.

Skoro mamy już praktykę operacyjną, to co z koncepcją i strategią?

W kolejnym artykule pokażę, jak regulacje wyznaczają ramy strategicznych decyzji oraz jak przejść od koncepcji do decyzji „tu i teraz”.

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.