Wyobraźmy sobie poranek, w którym organizacja traci zaufanie do własnego środowiska IT. Systemy produkcyjne są zaszyfrowane, konta administratorów przejęte, a dostępne kopie zapasowe mogły zostać usunięte lub zmodyfikowane. W takiej chwili liczy się odpowiedź na jedno pytanie: czy nadal mamy dane, z których możemy bezpiecznie odbudować działalność?
Właśnie temu służy koncepcja cyfrowego bunkra: wydzielonego miejsca przechowywania krytycznych danych, zaprojektowanego z myślą o przetrwaniu kompromitacji środowiska produkcyjnego. Jego wartość wynika z połączenia kilku niezależnych mechanizmów ochrony. Microsoft Azure dostarcza elementy, z których taką architekturę można zbudować.
Izolacja środowiska backupu za pomocą osobnego tenanta Entra ID i PIM
Granica ochrony zaczyna się od tożsamości i administracji. Bunkier jest utrzymywany w oddzielnym, zabezpieczonym do tego celu tenancie Microsoft Entra ID, z przypisanymi do niego subskrypcjami Azure. Global Administrator z tenantu produkcyjnego nie może wykorzystać mechanizmu podnoszenia uprawnień, aby nadać sobie dostęp do zasobów w tenancie bunkra. Rozdzielenie obejmuje konta administracyjne i mechanizmy odzyskiwania dostępu, tak aby przejęcie tożsamości w organizacji nie otwierało bocznej drogi do chronionego środowiska.
Jedynym kontem administracyjnym w tenancie bunkra jest awaryjne konto Global Administratora, objęte szczególną ochroną i nieużywane w codziennej pracy. Hasło do tego konta jest podzielone na dwie części, przechowywane jako statyczne ciągi znaków na wielofunkcyjnych kluczach sprzętowych. Każda część ma egzemplarz podstawowy i zapasowy (łącznie dwa komplety po dwie części). Fragmenty pozostają pod pieczą różnych opiekunów, a kopie zapasowe są przechowywane oddzielnie. Złożenie pełnego hasła wymaga współdziałania opiekunów obu części.
Te same urządzenia pełnią również funkcję drugiego składnika uwierzytelniania z użyciem mechanizmu obsługiwanego przez Entra ID. Dla tego konta przyjmujemy logowanie hasłem oraz sprzętowym drugim składnikiem (bez włączania logowania passwordless). Przechowywanie fragmentu hasła i obsługa drugiego składnika to dwie odrębne funkcje tego samego tokena. Pomijając konto awaryjne, to wszyscy użytkownicy tenantu bunkra obowiązkowo korzystają z kluczy sprzętowych jako drugiego składnika uwierzytelniania. Każdy użytkownik ma własny klucz oraz osobno przechowywany klucz zapasowy, przygotowany do tej samej funkcji.
Na co dzień nikt nie pracuje w tenancie bunkra, a jeśli musi wykonać tam jakieś operacje (w tym odzyskiwania), robi to z podniesionymi uprawnieniami, uzyskując czasowy dostęp do danych wyłącznie przez Privileged Identity Management (PIM). Aktywacja odpowiednich ról dostępu do danych wymaga uzasadnienia i zatwierdzenia przez uprawnionego przedstawiciela grupy sterującej. Po zakończeniu okresu aktywacji uprawnienia wygasają. Użycie jedynego konta administracyjnego (awaryjnego GA) podlega odrębnej kontroli i rejestrowaniu. Automatyczne zasilanie bunkra działa przez ściśle ograniczone uprawnienia Managed Identity, bez interaktywnej aktywacji PIM.
Niezmienne kopie zapasowe w Azure Blob Storage: WORM, ZRS i GZRS
Fundamentem jest Azure Blob Storage z mechanizmem WORM (Write Once, Read Many). Zapisane dane można odczytywać, ale przez ustalony okres nie można ich nadpisać ani usunąć. Zablokowana polityka niezmienności sprawia, że okresu ochrony nie da się po prostu skrócić decyzją administratora. Dla biznesu oznacza to zachowanie chronionej kopii również wtedy, gdy ktoś uzyska uprawnienia, które w zwykłym magazynie pozwoliłyby ją zniszczyć.
Trwałość danych wzmacnia ZRS (Zone-Redundant Storage). Cała zawartość magazynu jest replikowana synchronicznie pomiędzy co najmniej trzema strefami dostępności w jednym regionie Azure. To ochrona każdego zapisanego bajtu w fizycznie rozdzielonych centrach danych, należących do niezależnych stref z własnym zasilaniem, chłodzeniem i infrastrukturą sieciową. Strefy są zwykle oddalone od siebie o kilometry; każda może obejmować jedno lub więcej centrów danych. Dzięki temu awaria pojedynczej strefy nie powoduje utraty potwierdzonych zapisów.
Szyfrowanie danych i ochrona kluczy w Azure Key Vault Premium (szyfrowanie kopertowe, HSM)
W tej architekturze nadrzędny klucz jest generowany w HSM jako nieeksportowalny. Jego prywatnego materiału nie można pobrać i wynieść jako zwykłego pliku. Uprawniony proces może zlecić operację kryptograficzną, ale nie otrzymuje samego klucza HSM. Dzięki temu samo skopiowanie zawartości magazynu nie daje możliwości odczytania informacji. Równie starannie trzeba więc chronić prawo do użycia klucza, jak dostęp do danych.
Klucz nadrzędny chroniony sprzętowo w Azure Key Vault Premium nie jest uzależniony od pojedynczego urządzenia HSM ani jednego centrum danych. Azure zapewnia redundancję zawartości skarbca w obrębie regionu, a w regionach obsługujących strefy dostępności replikuje ją między strefami synchronicznie. Awaria pojedynczego centrum danych nie oznacza więc utraty klucza. W obsługiwanych regionach sparowanych działa również automatyczna, asynchroniczna replikacja do regionu zapasowego, z zachowaniem sprzętowej ochrony klucza. Nieeksportowalność klucza pozostaje przy tym zachowana: wewnętrzna replikacja usługi nie daje użytkownikowi możliwości pobrania jego prywatnego materiału.
Odporność klucza na utratę trzeba jednak odróżnić od czasu przywrócenia dostępu do niego po awarii całego regionu. Przełączeniem do regionu sparowanego zarządza Microsoft, dlatego plan odtwarzania bunkra powinien uwzględniać także możliwą przerwę w dostępności operacji kryptograficznych.
Zabezpieczenie dostępu do backupów przez Azure Arc, Managed Identity, RBAC i ABAC
Pozostaje kwestia tożsamości systemu, który zasila bunkier. Tutaj rolę pełni Azure Arc. W tym modelu wydzielony serwer działający w lokalnym centrum danych jest rejestrowany przez Azure Arc w subskrypcji powiązanej z tenantem bunkra. Jego Managed Identity powstaje w tym samym tenancie i służy do uwierzytelniania wobec Key Vault oraz Storage. Uprawnienia administratorów tego serwera również muszą odpowiadać przyjętej separacji, ponieważ kontrola nad nim daje możliwość użycia jego tożsamości. Proces nie musi przechowywać stałych haseł ani kluczy dostępu do tych usług w swojej konfiguracji. To ogranicza liczbę sekretów, które mogą wyciec, i upraszcza zarządzanie dostępem w środowisku hybrydowym.
Całość spina świadomie zaprojektowany model uprawnień. RBAC dla Key Vault i Storage określa, kto może zapisywać dane, kto je odczytywać, a kto wykonywać operacje kryptograficzne. Rozdziela się rolę dostarczającą kopie od roli odpowiedzialnej za ich odtworzenie. System wysyłający dane do bunkra nie ma prawa do ich odszyfrowywania.
ABAC (Attribute-Based Access Control) dla Storage uzupełnia te role o trzy warunki dostępu. Po pierwsze, sprawdza, czy tożsamość zapisująca lub odczytująca dane ma wymagane Custom Security Attributes w Microsoft Entra ID. Dotyczy to również Managed Identity, a więc także tożsamości serwera podłączonego przez Azure Arc. Po drugie, uzależnia dostęp od przejścia żądania przez wskazany private endpoint. Po trzecie, ogranicza określone operacje do obiektów o dozwolonym prefiksie nazwy lub ścieżki. Możemy dzięki temu zezwolić danemu systemowi na zapis wyłącznie we własnym obszarze bunkra, a procesowi odtwarzania przyznać odczyt odpowiedniego zakresu danych.
Te warunki stosujemy łącznie: właściwa tożsamość, zatwierdzona droga dostępu i dozwolony zakres danych dla konkretnej operacji. Ich skuteczność wymaga kontroli nad nadawaniem atrybutów i uprawnień oraz wykluczenia alternatywnych ścieżek autoryzacji omijających te ograniczenia. Separacja administracji bunkra od administracji produkcji ma tu znaczenie równie duże jak wybór usług.
Prywatna łączność z zapasowymi łączami: ExpressRoute i private endpoints
Do bunkra prowadzą prywatne połączenia ExpressRoute z dwóch lokalizacji on-premises. Każda lokalizacja korzysta z własnego obwodu, a obwody doprowadzamy do dwóch różnych punktów styku z siecią Microsoft. To dedykowana usługa telekomunikacyjna zapewniająca dostęp do globalnej sieci szkieletowej Microsoft. Ruch do bunkra omija publiczny Internet: biegnie przez sieć operatora do Microsoft, a następnie jego siecią szkieletową do regionu, w którym znajduje się magazyn danych.
Każdy obwód ExpressRoute ma dwie redundantne „nitki” do dwóch routerów brzegowych Microsoft. W naszym modelu obie działają w trybie Active-Active, z wymianą tras przez BGP. Dwie lokalizacje i dwa obwody oznaczają więc po dwie aktywne ścieżki na każdy obwód. Redundancję utrzymujemy także po stronie operatora i infrastruktury lokalnej, aby wspólny router lub trasa kablowa nie stały się pojedynczym punktem awarii.
Testowanie odzyskiwania danych i przedpłaty na usługi Azure dla większej odporności na cyberataki
Odporność bunkra obejmuje także jego finansowanie. Subskrypcje kupujemy bezpośrednio od Microsoft, z oddzielnie kontrolowanym dostępem do rozliczeń. W miarę dostępności takiego modelu w wybranej umowie przewidujemy przedpłatę na zużycie Azure (prepayment), aby ograniczyć zależność utrzymania bunkra od bieżącej obsługi płatności podczas kryzysu. Wymaga to nadzoru nad saldem, terminem ważności środków i kosztami usług nieobjętych przedpłatą. Samo zobowiązanie do wydatków, takie jak MACC, nie oznacza jeszcze opłacenia usług z góry.
Dlatego cyfrowy bunkier należy oceniać poprzez zdolność do odtworzenia działalności. Potrzebne są regularne próby odzyskiwania danych, ochrona kluczy przed usunięciem oraz pewność, że zachowujemy także kopie sprzed momentu kompromitacji. Niezmienność chroni zapisany stan — również wtedy, gdy do magazynu trafiły już uszkodzone dane.
Biznesową wartością takiej architektury jest zachowanie możliwości działania w sytuacji, w której zwykłe zabezpieczenia zawiodły. WORM chroni niezmienność kopii, replikacja strefowa i geograficzna zwiększa odporność na awarie, szyfrowanie u źródła chroni poufność, a HSM zabezpiecza nadrzędny klucz. Tożsamość, uprawnienia i prywatna komunikacja kontrolują dostęp do całości.
