Konta usługi Azure Storage

Konto magazynu Azure to podstawowy zasób zapewniający dostęp do głównych usług magazynowania Azure: Blob Storage (magazyn obiektów), Azure Files (zarządzane udziały plików), Queue Storage (kolejki komunikatów), Table Storage (magazyn NoSQL typu klucz-wartość) oraz Azure Data Lake Storage Gen2 (hierarchiczna przestrzeń nazw na potrzeby analityki). Jedno konto magazynu może jednocześnie obsługiwać wszystkie te usługi i zapewnia unikatową przestrzeń nazw w Azure — nazwa konta staje się częścią adresu URL każdego zawartego w nim obiektu.

Azure oferuje kilka typów kont magazynu: Standard general-purpose v2 (GPv2) — zalecany typ w większości scenariuszy; obsługuje wszystkie usługi magazynowania i opcje nadmiarowości przy standardowej wydajności. Premium block blobs — magazyn oparty na dyskach SSD, przeznaczony do scenariuszy wymagających bardzo małych opóźnień operacji Blob Storage. Premium file shares — udziały Azure Files oparte na dyskach SSD, przeznaczone do obciążeń wymagających dużej liczby operacji wejścia-wyjścia na sekundę, takich jak bazy danych lub katalogi domowe. Premium page blobs — magazyn SSD dla dysków systemowych i dysków danych maszyn wirtualnych Azure (dyski zarządzane korzystają z niego wewnętrznie). W większości przypadków należy rozpocząć od konta Standard GPv2.

Azure Storage automatycznie replikuje dane, aby chronić je przed awariami sprzętu. Dostępne są cztery opcje nadmiarowości: LRS (Locally Redundant Storage) — trzy synchroniczne kopie w jednym centrum danych. ZRS (Zone-Redundant Storage) — trzy synchroniczne kopie w trzech strefach dostępności w jednym regionie. GRS (Geo-Redundant Storage) — LRS w regionie podstawowym oraz asynchroniczna replikacja do regionu pomocniczego (LRS). GZRS (Geo-Zone-Redundant Storage) — ZRS w regionie podstawowym oraz asynchroniczna replikacja do regionu pomocniczego. Większa nadmiarowość oznacza wyższą trwałość i większy koszt.

Warstwę nadmiarowości należy wybrać na podstawie wymagań dotyczących RTO, RPO i budżetu: LRS — najtańsza opcja, trwałość na poziomie 11 dziewiątek, brak ochrony przed awarią centrum danych. Należy jej używać w środowiskach deweloperskich i testowych lub w przypadku danych, które można odtworzyć. ZRS — chroni przed awarią centrum danych i dobrze sprawdza się w przypadku danych produkcyjnych w jednym regionie. GRS/GZRS — chroni przed niedostępnością całego regionu Azure; dane są replikowane asynchronicznie do sparowanego regionu. W przypadku krytycznych danych biznesowych, które muszą przetrwać katastrofę regionalną, właściwym wyborem jest GRS lub GZRS, mimo dodatkowych kosztów.

Azure Storage oferuje dwie warstwy wydajności: Standard — oparta na dyskach twardych (HDD), odpowiednia dla większości obciążeń i zapewniająca niższy koszt za GB. Premium — oparta na dyskach półprzewodnikowych (SSD), przeznaczona do scenariuszy wrażliwych na opóźnienia, wymagających operacji wejścia-wyjścia trwających kilka milisekund. Magazyn Standard jest rozliczany za każdy przechowywany GB; warstwa Premium kosztuje więcej za GB, ale zapewnia stałą i przewidywalną wydajność. W przypadku zasobów internetowych, kopii zapasowych, dzienników i archiwów odpowiednia będzie warstwa Standard. W przypadku maszyn wirtualnych z bazami danych intensywnie korzystającymi z operacji wejścia-wyjścia lub udziałów plików używanych przez użytkowników komputerów stacjonarnych lepszym wyborem będzie Premium.

Nazwy kont magazynu muszą być globalnie unikatowe w całym Azure (ponieważ stanowią część publicznej nazwy DNS, takiej jak mystorageacct.blob.core.windows.net). Nazwa musi mieć od 3 do 24 znaków i zawierać wyłącznie małe litery i cyfry — bez łączników, podkreśleń i wielkich liter. Ponieważ nazwy muszą być globalnie unikatowe, popularne słowa i nazwy marek są już zajęte. Dobrą praktyką jest połączenie prefiksu firmy, środowiska (prod/dev) i przeznaczenia (store/media), a następnie dodanie losowego sufiksu, jeśli jest to konieczne: np. contosoprodmedia7x2.

Każde konto magazynu ma dwa 512-bitowe klucze dostępu, które zapewniają pełny dostęp administracyjny do wszystkich zasobów na koncie. Klucze te należy traktować jak hasła — przechowywać je w Azure Key Vault, a nie w kodzie ani plikach konfiguracyjnych. Azure generuje dwa klucze, aby można było przeprowadzić rotację kluczy bez przestojów: należy zaktualizować aplikacje tak, aby korzystały z klucza 2, ponownie wygenerować klucz 1, przełączyć aplikacje na klucz 1, a następnie ponownie wygenerować klucz 2. W celu uzyskania bardziej szczegółowej kontroli dostępu należy zamiast udostępniania kluczy głównych używać Shared Access Signatures (SAS) lub Azure RBAC.

Azure RBAC (Role-Based Access Control) to zalecany sposób autoryzowania dostępu do danych w magazynie bez udostępniania kluczy. Należy przypisać rolę Storage Blob Data Reader, aby zezwolić na dostęp tylko do odczytu do Blob Storage, lub Storage Blob Data Contributor, aby zezwolić na odczyt i zapis. Role te przypisuje się użytkownikom, grupom lub tożsamościom zarządzanym Entra ID, dzięki czemu dostęp jest powiązany z uwierzytelnioną tożsamością, a nie ze współdzielonym sekretem. Autoryzacja RBAC dla magazynu jest dostępna dla usług Blob, Queue i Table (nie dla File — ta usługa korzysta z protokołów SMB/NFS i własnych mechanizmów kontroli dostępu).

Domyślnie konta magazynu akceptują połączenia z dowolnej sieci. W celu zapewnienia bezpieczeństwa produkcyjnego należy ograniczyć dostęp za pomocą Storage Account Firewall: zezwolić wyłącznie na określone zakresy publicznych adresów IP lub podsieci sieci wirtualnej. Aby zapewnić najwyższy poziom bezpieczeństwa, należy całkowicie wyłączyć dostęp z publicznego internetu i użyć Private Endpoint — prywatnego adresu IP w sieci VNet, który kieruje ruch do konta magazynu przez prywatną sieć szkieletową Azure, bez wystawiania go w publicznym internecie. Private Endpoints to zalecane rozwiązanie w przypadku kont magazynu zawierających dane wrażliwe lub podlegające regulacjom.

Azure Storage oferuje wbudowane funkcje ochrony danych przed przypadkowym usunięciem: Blob soft delete — usunięte obiekty blob i ich wersje są przechowywane przez konfigurowalny okres (od 1 do 365 dni) i można je odzyskać bez przywracania z kopii zapasowej. Blob versioning — każde zastąpienie obiektu tworzy nową wersję, dzięki czemu można przywrócić dowolną wcześniejszą wersję obiektu blob. Container soft delete — przypadkowo usunięte kontenery można odzyskać. Funkcje te są domyślnie wyłączone i należy je włączyć dla produkcyjnych kont magazynu zawierających ważne dane, które nie są objęte inną kopią zapasową.

Azure Monitor automatycznie zbiera metryki dla każdego konta magazynu: całkowitą zajętą pojemność, liczbę transakcji, liczbę bajtów danych przychodzących i wychodzących oraz opóźnienie kompleksowe. Można je wyświetlać w bloku Insights portalu Azure dla danego konta magazynu, który udostępnia gotowe wykresy pojemności, dostępności i wydajności. Aby uzyskać szczegółowy audyt dostępu, należy włączyć Storage Diagnostic Logs w celu rejestrowania każdej operacji odczytu, zapisu i usuwania w miejscu docelowym dzienników — jest to przydatne podczas analiz bezpieczeństwa i raportowania zgodności.

Sprawdź swoją wiedzę na temat zagadnień Microsoft Azure Fundamentals (AZ-900) omówionych w tej lekcji.

W tej lekcji poznali Państwo: konto magazynu jest głównym zasobem dla wszystkich usług magazynowania Azure i jest identyfikowane przez globalnie unikatową nazwę, opcje nadmiarowości — LRS, ZRS, GRS i GZRS — zapewniają coraz wyższy poziom trwałości przy coraz wyższym koszcie, a także dostęp powinien być kontrolowany za pomocą RBAC i prywatnych punktów końcowych, a nie przez udostępnianie głównych kluczy dostępu. W następnej części szczegółowo omówimy Blob Storage — magazyn obiektów Azure przeznaczony do danych nieustrukturyzowanych.