Domyślne ustawienia Azure Storage często nie wystarczą, aby zapewnić pełne bezpieczeństwo naszych danych. Mimo że Microsoft coraz mocniej promuje model Security by Default, kwestie takie jak bezpieczeństwo sieciowe, odchodzenie od kluczy dostępowych na rzecz Managed Identities czy granularna kontrola dostępu, nadal spoczywają w rękach inżynierów. W tym wpisie przeanalizujemy proces hardeningu storage w Azure, od private linków po mechanizmy Threat Protection.
Zarządzanie dostępem
Wyobraź sobie że budujesz skarbiec, możesz zainwestować w najgrubsze ściany i drzwi z tytanu, ale jeżeli rozdasz kopie klucza wszystkim pracownikom, zabezpieczenia traca sens. W świecie Azure Storage tożsamość to twoje główne drzwi, a uprawnienia to klucz. Zanim zaczniesz skupiać się na szyfrowaniu danych czy firewallach na poziomie sieci, musisz odpowiedzieć sobie precyzyjnie na jedno kluczowe pytanie: Kto i na jakich zasadach ma prawo uzyskać dostęp do Twoich danych?
Najważniejszą rzeczą, jeśli chodzi o dostęp do Twoich danych, są odpowiednio przypisane uprawnienia za pomocą Azure RBAC. Powinny być one nadawane w jak najbardziej granularny sposób (unikając ról typu privileged administrator), dając dostęp wyłącznie do tych operacji, które użytkownik faktycznie musi wykonywać w ramach swojej codziennej pracy (np. samo wyświetlanie plików, jeśli nie musi ich usuwać ani modyfikować). Dodatkowo dostęp warto przydzielać w ramach PIM (Privileged Identity Management), czyli tymczasowo, na wniosek użytkownika i po zatwierdzeniu przez upoważnione osoby. Stałe, „wiszące” uprawnienia administracyjne o zbyt szerokim zakresie drastycznie zwiększają powierzchnię ataku (attack surface). W razie włamania ułatwiają one intruzowi eskalację uprawnień oraz ruch boczny (lateral movement) – co zresztą, zgodnie z zasadą Zero Trust, dotyczy wszystkich systemów, nie tylko Azure Storage.
Oprócz osób fizycznych, dostępu do Azure Storage często potrzebują również aplikacje czy usługi. Kiedyś temat ten realizowano za pomocą kluczy dostępowych (access keys) oraz sygnatur SAS (shared access signatures). Były one jednak problematyczne w zarządzaniu, wymagały okresowego rotowania kluczy głównych czy pilnowania odpowiedniej konfiguracji czasowej tokenów. Poza tym zawsze istniało ryzyko, że jeśli dany klucz wycieknie, ktoś bez problemu ominie nasze zabezpieczenia sieciowe i dostanie się do zasobów. Od dłuższego czasu takie podejście uznawane jest za przestarzałe. Obecnie Microsoft zaleca, aby przyznawać aplikacjom dostęp do zasobów poprzez tożsamości zarządzane (Managed Identities) w Entra ID.
Największą zaletą Managed Identities jest całkowity brak haseł, certyfikatów czy kluczy tajnych (client secrets), którymi musiałby zarządzać programista lub administrator, Azure sam dba o rotację poświadczeń w tle. Jeśli jednak nasza aplikacja działa poza Azure (on-premises lub w innej chmurze), zamiast Managed Identity rejestrujemy ją w Entra ID jako tzw. Service Principal i to wtedy uwierzytelnia się ona za pomocą klucza tajnego. W obu przypadkach uprawnienia do danych w kontenerach nadajemy nie poprzez uprawnienia aplikacji w Entra ID, ale precyzyjnie, przypisując tożsamości odpowiednią rolę Azure RBAC bezpośrednio na koncie storage (np. Storage Blob Data Contributor). Daje nam to ogromną kontrolę nad ruchem za pomocą polityk dostępu warunkowego (Conditional Access) oraz pełną widoczność w logach logowań (sign-in logs).
Bezpieczeństwo sieciowe
Zgodnie z zasadą defense in depth, same uprawnienia (choć stanowią pierwszą linię obrony w chmurze) to za mało. Musimy zejść głębiej i zabezpieczyć nasz zasób na każdym poziomie, w tym również sieciowym.
Najważniejszą zasadą jest ograniczenie publicznego ruchu do naszych danych. Najlepiej zrobić to, wyłączając go całkowicie i przypisując naszym zasobom prywatne punkty końcowe (private endpoints). Działają one jak prywatne adresy IP zintegrowane z siecią wirtualną (VNet), która następnie jest połączona z naszą infrastrukturą. Dzięki temu zasób będzie dostępny wyłącznie z sieci prywatnej (LAN) wewnątrz organizacji lub (w scenariuszach czysto chmurowych) z zasobów wdrożonych w odpowiednio spiętych ze sobą (zpeerowanych) sieciach w Azure.
Oczywiście istnieją też scenariusze brzegowe (edge cases), w których dany magazyn danych musi być dostępny publicznie (na przykład dla klienta zewnętrznego lub aplikacji hostowanej poza naszym środowiskiem). W takim wypadku najlepszym rozwiązaniem jest spięcie tunelu VPN typu Site-to-Site (S2S) lub Point-to-Site (P2S) z lokalizacją, która ma mieć dostęp do danych. Jeśli jednak jest to niemożliwe, ostatecznością (choć to podejście również uznawane za legacy) pozostaje wystawienie zasobu na świat, ale z rygorystycznym ograniczeniem ruchu wyłącznie do zautoryzowanych adresów IP (tzw. IP whitelisting).
Dobrą opcją jest także hybrydowe podejście: przypisanie do zasobu prywatnego punktu końcowego (private endpoint) i wystawienie go na świat poprzez przekierowanie ruchu (IP forwarding) na naszym urządzeniu brzegowym. Sprawdzi się to idealnie w sytuacji, gdy zamiast natywnych rozwiązań Azure korzystamy z wdrożonego w chmurze wirtualnego urządzenia sieciowego (tzw. Network Virtual Appliance – NVA), takiego jak na przykład Fortigate. Dzięki temu możemy narzucić dodatkową warstwę ochrony na nasz magazyn danych, wykorzystując zaawansowane funkcje bezpieczeństwa zewnętrznego vendora, takie jak systemy WAF czy IDPS (warto dodać, że analogiczne funkcje inspekcji ruchu są oczywiście dostępne również wtedy, gdy zdecydujemy się na natywne rozwiązanie Azure Firewall w wersji Premium).
Ochrona danych
Jeżeli tożsamość i sieć zawiodą, do akcji wkracza ostatnia linia obrony – kryptografia. Szyfrowanie w Azure Storage odbywa się na dwóch płaszczyznach:
- W spoczynku (at rest): Dane są szyfrowane, gdy „leżą” na dyskach i nie są aktywnie używane. Każda próba uzyskania do nich dostępu wymaga ich odszyfrowania do jawnej postaci.
- W trasie (in transit): Dane są szyfrowane w trakcie przemieszczania się z punktu A do punktu B w sieci, co gwarantuje, że nie zostaną podsłuchane, przechwycone ani zmodyfikowane, zanim dotrą do celu.
Dane w ruchu szyfrowane są przy użyciu protokołu HTTPS (TLS), natomiast w spoczynku za pomocą algorytmu AES-256 i mechanizmu działającego analogicznie do systemu BitLocker w Windows. Co najważniejsze, obie te metody są domyślnie włączone (Security by default), więc nie musimy ich dodatkowo konfigurować podczas tworzenia zasobu.
Warto w tym miejscu pochylić się nad tematem tego, kto właściwie zarządza kluczami służącymi do szyfrowania i deszyfrowania danych w spoczynku. Domyślnie są one utrzymywane przez Microsoft (Microsoft-Managed Keys), ale możemy również wdrożyć model Customer-Managed Keys (CMK), który daje nam pełną kontrolę nad cyklem życia kluczy. W tym drugim scenariuszu klucze przechowywane są w usłudze Azure Key Vault (lub Managed HSM), gdzie możemy rotować je ręcznie lub automatycznie za pomocą odpowiednich polityk.
To, które podejście wybierzemy, zależy od tego, jak dużą kontrolę chcemy mieć nad całym procesem (i bardzo często decyzja ta jest dyktowana sztywnymi wymogami regulacyjnymi). Moim zdaniem, jeśli przepisy prawne lub wewnętrzne procedury bezpieczeństwa nie wymuszają na Tobie samodzielnego, okresowego rotowania kluczy (oraz np. zbierania logów z tego procesu pod audyt), pozostawienie tego w rękach Microsoftu jest w zupełności wystarczającym i po prostu wygodniejszym wyborem.
Warto również wspomnieć, że podczas tworzenia zasobu w Azure Storage mamy możliwość włączenia funkcji o nazwie Infrastructure encryption. Pozwala ona na podwójne zaszyfrowanie naszych danych w spoczynku: pierwszy raz na poziomie samej usługi (płaszczyzny danych Azure Storage), a drugi raz na niższym poziomie infrastruktury (fizycznych dysków w centrum danych Microsoftu). Dzięki temu zyskujemy dwie niezależne warstwy ochrony, nawet gdyby jeden z mechanizmów szyfrujących zawiódł lub powiązane z nim klucze wyciekły, napastnik wciąż musi pokonać drugą barierę. To doskonała opcja dla organizacji, które operują na krytycznych danych i wymagają najwyższego możliwego poziomu bezpieczeństwa (high-security compliance).
Odporność i odzyskiwanie danych
Kiedy myślimy o zagrożeniach dla danych, najczęściej widzimy w wyobraźni zamaskowanego hakera, który siedzi przy czterech monitorach i z prędkością cyborga magicznie wklepuje komendy do CLI. Rzeczywistość bywa jednak o wiele bardziej prozaiczna, najczęstszym zagrożeniem dla danych są sami użytkownicy oraz administratorzy (którzy przez zwykły, ludzki błąd w codziennej pracy usuwają kluczowe pliki), bądź też niespodziewane problemy techniczne. Dlatego tak ważne jest budowanie odporności zasobów i wdrażanie procedur odzyskiwania danych. Choć temat ten może wydawać się czysto operacyjny, warto pamiętać, że integralność oraz dostępność danych to (obok poufności) kluczowe filary triady CIA. Przeciwdziałanie utracie danych jest więc fundamentalną częścią strategii bezpieczeństwa.
Pierwszą pomocą przy pomyłkach są funkcje Soft Delete oraz wersjonowanie w Azure Storage. Ta pierwsza sprawia, że wszystkie usunięte pliki trafiają na określony czas do „kosza” (jeśli w tym okresie zajdzie potrzeba ich odzyskania, administrator może je bez problemu przywrócić). Z kolei wersjonowanie pozwala na przechowywanie wielu historycznych wersji tego samego pliku. Oznacza to, że jeśli plik zostanie przypadkowo zmodyfikowany lub nadpisany przez złośliwe oprogramowanie, możemy w prosty sposób przywrócić jego poprawny stan (na przykład wersję sprzed dwóch dni). Warto jednak pamiętać, że dane przechowywane w „koszu” oraz historyczne wersje plików generują dodatkowe koszty i są rozliczane po standardowej stawce za GB. Uruchomienie tych funkcji masowo, bez wcześniejszej analizy, może drastycznie podnieść rachunek za chmurę.
Druga linia obrony, niezwykle ważna w przypadku kluczowych danych, to Immutable Storage , czyli bezpośrednia odpowiedź Microsoftu na zagrożenia typu ransomware. Funkcja ta realizuje strategię WORM (Write Once, Read Many) i działa trochę podobnie do klasycznych backupów taśmowych. Po skonfigurowaniu odpowiedniej polityki (retencyjnej lub prawnej – legal hold), danych w wybranym kontenerze nie da się zmodyfikować ani usunąć przez określony czas. Co najważniejsze, blokada jest na tyle rygorystyczna, że po jej uruchomieniu nawet administrator z najwyższymi uprawnieniami nie jest w stanie skasować tych plików. Chroni to naszą infrastrukturę przed automatycznie propagującym się ransomware, które próbuje zaszyfrować dane, oraz przed sabotażem ze strony kogoś wewnątrz organizacji.
Na koniec warto wyraźnie rozdzielić dwa pojęcia, które administratorzy nagminnie ze sobą mylą: replikację danych (redundancję) oraz backupy. Azure Storage oferuje nam dwa podstawowe modele replikacji:
- LRS (Locally Redundant Storage): Dane replikowane są trzykrotnie wewnątrz jednego, tego samego centrum danych (data center) w wybranym regionie Azure.
- GRS (Geo-Redundant Storage): Dane są replikowane synchronicznie w regionie podstawowym (jak w LRS), a następnie asynchronicznie przesyłane do drugiego regionu Azure, oddalonego o co najmniej kilkaset kilometrów.
Pierwsze podejście (tańsze) gwarantuje, że w razie awarii pojedynczego szafy serwerowej lub dysków w jednym obiekcie, nasze dane wciąż będą dostępne. Drugie podejście (odpowiednio droższe) pozwala na kopiowanie danych do lokalizacji oddalonej geograficznie przy użyciu prywatnej sieci światłowodowej Microsoftu. Sprawia to, że dane są bezpieczne nawet w przypadku katastrof naturalnych czy konfliktów geopolitycznych w regionie głównym.
Musimy jednak pamiętać o jednym: replikacja to nie kopia zapasowa. Jeśli użytkownik lub złośliwe oprogramowanie usunie bądź zmodyfikuje plik w głównym magazynie, ta operacja zostanie natychmiast zreplikowana również do drugiej, odległej lokalizacji. Replikacja chroni nas przed awarią fizycznej infrastruktury Microsoftu, a nie przed utratą danych wynikającą z błędów ludzkich czy ataków. Dlatego dla kluczowych zasobów krytyczne jest wdrożenie dedykowanego systemu kopii zapasowych, na przykład natywnej usługi Azure Backup (która pozwala na tworzenie niezależnych, odizolowanych punktów przywracania), bądź też sprawdzonych rozwiązań zewnętrznych dostawców.
Wykrywane zagrożeń i monitoring
Gdy odpowiednio zabezpieczymy już dane przechowywane w Azure, kluczowe staje się ich ciągłe monitorowanie i wykrywanie zagrożeń, zanim te przerodzą się w poważny incydent. Z pomocą przychodzi tutaj Microsoft Defender for Storage, który stale monitoruje operacje na naszych plikach. Potrafi on wykrywać podejrzane działania (takie jak nietypowy wolumen pobierania lub wysyłania danych) czy też złośliwe oprogramowanie, które ktoś próbowałby ukradkiem wrzucić do naszego magazynu.
Defender nie tylko zaalarmuje nas o wykryciu anomalii, ale może również automatycznie zablokować zainfekowany plik. Jeśli system wykryje zagrożenie, natychmiast zobaczymy alert w panelu usługi, otrzymamy powiadomienie e-mail, a sam komunikat może zostać automatycznie wypchnięty do naszego systemu SIEM (takiego jak Microsoft Sentinel czy Wazuh), gdzie zespół SOC lub administratorzy będą mogli podjąć natychmiastową reakcję.
Sam Microsoft Defender jest oczywiście usługą dodatkowo płatną, a jego ostateczny koszt zależy od wybranego przez nas modelu rozliczeniowego oraz stopnia monitoringu, jaki chcemy wdrożyć. W podstawowym modelu koszt samego wykrywania zagrożeń na poziomie warstwy biznesowej (Activity Monitoring) to około 9,30 EUR miesięcznie za jedno konto storage, natomiast dodatkowe skanowanie pod kątem złośliwego oprogramowania (Malware Scanning) kosztuje około 0,14 EUR za każdy gigabajt (GB) przeskanowanych danych (ceny podane dla regionu West Europe).
Oprócz Defendera, który skupia się typowo na aktywnym monitorowaniu i reagowaniu na zagrożenia, do dyspozycji mamy również usługę Azure Monitor. Służy ona do zbierania metryk oraz logów telemetrycznych (takich jak całkowity rozmiar danych w GB, liczba zapytań o dostęp do obiektów czy statystyki poszczególnych operacji). Kluczowym elementem tej układanki są także logi logowań (Sign-in logs) oraz logi audytowe w Microsoft Entra ID.