Zabezpieczanie konta Azure Storage

Azure Storage zapewnia skalowalne, trwałe przechowywanie w chmurze dla blobów, plików, kolejek i tabel w jednym koncie pamięciowym. Ponieważ konto magazynowe może przechowywać dane o bardzo różnym poziomie wrażliwości i często jest celem ataków eksfiltracyjnych i ransomware, należy podjąć świadome działania w celu ochrony konta, przechowywanych przez nie danych oraz tożsamości do nich dostępnych.

Ten artykuł zawiera zalecenia dotyczące bezpieczeństwa, które pomogą chronić Twoje konto Azure Storage. Te zalecenia dotyczą wszystkich usług danych na koncie (Blobs, Files, Queues i Tables). Wskazówki dotyczące każdej usługi danych można znaleźć w powiązanych artykułach dotyczących bezpieczeństwa na końcu tego artykułu.

Zalecenia dotyczące zabezpieczeń w tym artykule implementują zasady Zero Trust: "Weryfikuj dokładnie", "Stosuj dostęp o najmniejszych uprawnieniach" i "Zakładaj, że doszło do naruszenia". Aby uzyskać kompleksowe wskazówki dotyczące zerowego zaufania, zobacz Centrum wskazówek dotyczących zerowego zaufania.

Zabezpieczenia specyficzne dla usługi

Azure Storage ma cechy architektoniczne, które kształtują sposób bezpiecznego wdrożenia. Decyzje dokonywane przy tworzeniu konta – model wdrożenia, rodzaj, redundancja i konfiguracja endpointu – są trudne do zmiany później i wpływają na bezpieczeństwo każdego obciążenia korzystającego z konta.

Architektura kont pamięci masowej

  • Użyj modelu wdrożeniowego Azure Resource Manager: Utwórz nowe konta pamięci masowej, korzystając z modelu wdrożeniowego Azure Resource Manager. Konta usługi Resource Manager obsługują kontrolę dostępu opartą na rolach platformy Azure (RBAC), tożsamość zarządzaną, autoryzację danych przy użyciu identyfikatora Microsoft Entra ID, blokady zasobów, tagi i zasady — z których żadne nie są dostępne w klasycznym modelu wdrażania. Migruj pozostałe konta klasyczne. Więcej informacji można znaleźć w artykule Migruj klasyczne konto pamięci masowej do Azure Resource Manager.

  • Oddzielne konta pamięci masowej według obciążenia, środowiska i wrażliwości: Stwórz osobne konta dla rozwoju, preprodukcji i produkcji oraz osobne konta dla danych o różnych klasyfikacjach wrażliwości. Konto magazynu jest granicą zaufania opartą na kluczu współdzielonym oraz granicą zasad — mieszanie obciążeń w ramach jednego konta zwiększa skalę skutków naruszenia i utrudnia modelowanie dostępu zgodnie z zasadą najmniejszych uprawnień.

  • Używaj jednego konta na region dla izolacji regionalnej: Umieszczanie kont w regionie, gdzie działają ich obciążenia konsumpcyjne, zmniejsza przepływ danych między regionami i upraszcza granice zgodności. W projektach wieloregionalnych łącz konta regionalne z georedundantnym przechowywaniem lub replikacją obiektów, zamiast obsługiwać wszystkie regiony z jednego konta. Aby uzyskać więcej informacji, zapoznaj się z redundancją usługi Azure Storage.

Odpowiednie wykorzystanie Azure Storage

  • Nie używaj kluczy konta Azure Storage jako długotrwałych danych uwierzytelniających aplikacji: Klucze konta storage dają pełną kontrolę nad kontem i nie mogą być ograniczone. Aplikacje powinny używać Microsoft Entra ID z zarządzanymi tożsamościami lub, gdy Entra ID nie jest opcją, z krótkotrwałymi tokenami podpisu udostępniania współdzielonego dostępu użytkownika (SAS). Aby uzyskać więcej informacji, zobacz Autoryzowanie dostępu do danych w usłudze Azure Storage.

  • Nie używaj Azure Storage jako uniwersalnego magazynu sekretów: sekrety, łańcuchy połączeń i certyfikaty należą do Azure Key Vault, który zapewnia rotację, polityki dostępu, ochronę modułów bezpieczeństwa sprzętu (HSM) oraz ścieżki audytowe. Aby uzyskać więcej informacji, zobacz Omówienie usługi Azure Key Vault.

Bezpieczeństwo sieci

Konta pamięci masowej są domyślnie dostępne przez internet. Zmniejszenie powierzchni ataku sieciowego to najskuteczniejsza zmiana, jaką możesz wprowadzić, aby chronić konto przed nieautoryzowanym dostępem, wyciągiem danych i rozpoznaniem.

  • Wyłącz dostęp do konta pamięci masowej w sieci publicznej: Gdy klienci są całkowicie w Azure lub dostępni przez Private Link, ustaw dostęp do sieci publicznej konta na Disabled, aby akceptowane były tylko żądania przez prywatne endpointy. Aby uzyskać więcej informacji, zobacz Konfigurowanie zapór i sieci wirtualnych usługi Azure Storage.

  • Używaj prywatnych punktów końcowych do dostępu z sieci wirtualnych: Prywatny endpoint przypisuje prywatny adres IP z twojej sieci wirtualnej do konta pamięci masowej i kieruje ruch przez szkielet Microsoft. W połączeniu z wyłączonym dostępem do sieci publicznej, prywatne punkty końcowe eliminują ekspozycję na internet. Aby uzyskać więcej informacji, zobacz Używanie prywatnych punktów końcowych dla usługi Azure Storage.

  • Ogranicz publiczny dostęp za pomocą zapory pamięci, gdy prywatne punkty końcowe nie są praktyczne: Jeśli klienci muszą dotrzeć do konta przez sieć publiczną, ustaw domyślną akcję zapory na Odmówienie i pozwól tylko na określone zakresy IP, podsieci sieci wirtualnej (przez punkty końcowe usług) lub instancje zasobów wymagające dostępu. Aby uzyskać więcej informacji, zobacz Konfigurowanie zapór i sieci wirtualnych usługi Azure Storage.

    • Zezwalaj zaufanym usługom firmy Microsoft na dostęp do konta, gdy go potrzebują: Reguły zapory domyślnie blokujące dostęp blokują żądania z innych usług platformy Azure (na przykład Azure Backup, Log Analytics i Microsoft Defender for Storage), a także z portalu Azure i potoków diagnostycznych. Dodaj opcję Zezwalaj na usługi Azure na liście zaufanych usług, aby uzyskać dostęp do tego wyjątku dla konta magazynowego, tak aby usługi pierwszej strony, na których polegasz, mogły dotrzeć do konta bez otwierania go na publiczny internet. Aby uzyskać więcej informacji, zobacz Udziel dostępu do zaufanych usług Azure.

    • Przyznawaj dostęp do określonych instancji zasobów zamiast ogólnie zaufanych usług: Preferuj reguły instancji zasobów, które autoryzują określony zasób platformy Azure i jego tożsamość zarządzaną, zamiast ogólnego wyjątku „Zezwalaj na zaufane usługi firmy Microsoft”. Reguły instancji zasobów tworzą mniejszą powierzchnię zaufania. Aby uzyskać więcej informacji, zobacz Udostępnianie dostępu z instancji zasobów Azure.

  • Skojarz konta magazynu z granicą bezpieczeństwa sieci: Granica bezpieczeństwa sieci definiuje logiczne granice między zasobami typu platforma jako usługa (PaaS) i domyślnie blokuje ruch spoza granicy, zapewniając ochronę warstwową wykraczającą poza reguły zapory dla poszczególnych kont. Więcej informacji można znaleźć w artykule Obwód zabezpieczeń sieciowych dla usługi Azure Storage.

  • Wymusz minimalną wersję TLS 1.2 lub nowszą: Skonfiguruj minimalną wersję TLS dla konta magazynowego, aby odrzucała klientów negocjujących starsze, przestarzałe wersje. Więcej informacji można znaleźć w artykule Konfiguruj minimalną wymaganą wersję Transport Layer Security (TLS) dla konta pamięci masowej.

  • Wymagaj bezpiecznego transferu (HTTPS): Włącz właściwość Secure transfer required , aby odrzucić każde żądanie przez HTTP. Ten wymóg dotyczy zarówno punktów końcowych REST, jak i dostępu SMB do Azure Files. Więcej informacji można znaleźć w artykule Wymagaj bezpiecznego transferu dla konta magazynowego.

    • Niektóre scenariusze, takie jak starsze klienty SMB czy narzędzia starsze, wymagają HTTP. W takich przypadkach izoluj tych klientów w kontrolowanym segmencie sieci i jak najszybciej przenieś ich z HTTP.

  • Ogranicz replikację obiektów między dzierżawcami i operacje kopiowania: Skonfiguruj konto pamięci masowej tak, aby zezwalało na operacje kopiowania i replikacji obiektów tylko z kont źródłowych w tym samym dzierżawcu lub tylko z dozwolonych kont źródłowych. Ta konfiguracja uniemożliwia użytkownikom posiadającym uprawnienia płaszczyzny danych przemieszczanie danych między granicami dzierżaw. Więcej informacji można znaleźć w artykule Dozwolony zakres operacji kopiowania oraz Zapobieganie replikacji obiektów między dzierżawcami Microsoft Entra.

  • Używaj tagów usług VNet dla reguł wychodzących do Azure Storage: Gdy ograniczasz ruch wychodzący z sieci wirtualnej do Azure Storage, używaj tagu Storage service (lub wariantu specyficznego dla regionu) zamiast sztywno zakodowanych zakresów IP. Microsoft utrzymuje tag usługi w miarę rozwoju przestrzeni IP. Aby uzyskać więcej informacji, zobacz Omówienie tagów usługi Azure.

  • Wybierz globalną sieć Microsoft na potrzeby routingu ruchu przychodzącego: Skonfiguruj preferencję routingu sieciowego konta magazynu jako routing sieciowy firmy Microsoft, aby ruch przychodzący wchodził do sieci szkieletowej Microsoft w punkcie obecności najbliższym klientowi i pozostawał w sieci Microsoft na całej trasie. Routing internetowy szybciej opuszcza sieć Microsoft i zwiększa ekspozycję na publiczną ścieżkę internetową. Aby uzyskać więcej informacji, zobacz Konfigurowanie preferencji routingu sieciowego dla usługi Azure Storage.

Zarządzanie tożsamością i dostępem

Konta pamięci masowej obsługują dwa modele autoryzacji: Microsoft Entra ID (oparty na tożsamości, audytowalny, odwoływalny) oraz Shared Key (symetryczny sekret z pełnym dostępem do konta). Przenoś obciążenia do usługi Microsoft Entra ID wszędzie tam, gdzie to możliwe, i traktuj klucz współdzielony jako starszy mechanizm rezerwowy.

  • Użyj Microsoft Entra ID do autoryzacji dostępu do danych: autoryzacja Microsoft Entra ID wykorzystuje tokeny OAuth 2.0 i integruje się z dostępem warunkowym, zarządzanymi tożsamościami oraz śladami audytu RBAC. Pod każdym względem jest lepszy od klucza wspólnego w przypadku dostępu do płaszczyzny danych. Aby uzyskać więcej informacji, zobacz Autoryzowanie dostępu do danych w usłudze Azure Storage.

  • Nie zezwalaj na autoryzację klucza współdalonego: Ustaw allowSharedKeyAccess właściwość tak, false aby konto odrzucało każde żądanie podpisane kluczami do konta. Akceptowane są wyłącznie żądania Microsoft Entra ID oraz, w stosownych przypadkach, żądania SAS delegowania użytkownika. Aby uzyskać więcej informacji, zobacz Zapobieganie autoryzacji klucza współdzielonego dla konta usługi Azure Storage.

  • Przypisuj role RBAC w możliwie najmniejszym uzasadnionym zakresie: W miarę możliwości przypisuj wbudowane role płaszczyzny danych usługi Storage (na przykład Storage Blob Data Reader, Storage Queue Data Contributor) w zakresie kontenera, udziału, kolejki lub tabeli, a nie na poziomie konta lub subskrypcji. Więcej informacji można znaleźć w artykule Autoryzuj dostęp do blobów za pomocą kontroli dostępu opartej na rolach Azure.

  • Używaj sygnatury SAS z delegowaniem użytkownika zamiast sygnatury SAS usługi lub sygnatury SAS konta, gdy użycie SAS jest wymagane: Sygnatura SAS z delegowaniem użytkownika jest podpisywana przy użyciu poświadczeń Microsoft Entra, a nie klucza konta, dlatego unieważnienie klucza delegowania użytkownika natychmiast unieważnia wszystkie sygnatury SAS wystawione na jego podstawie. Tokeny SAS usługi i konta podpisane kluczami konta nie mogą zostać indywidualnie unieważnione. Aby uzyskać więcej informacji, zobacz Udzielanie ograniczonego dostępu do zasobów usługi Azure Storage przy użyciu sygnatur dostępu współdzielonego (SAS).

  • Jeśli musisz używać kluczy konta, chroń je i rotuj: Przechowuj klucze konta w Azure Key Vault, pobieraj je w czasie działania zamiast osadzać w konfiguracji, i rotuj w określonym tempie. Miej udokumentowaną procedurę rotacji, która zapobiega przestojom dzięki używaniu obu kluczy podczas rolloveru. Aby uzyskać więcej informacji, zobacz Zarządzanie kluczami dostępu do konta magazynu.

  • Przypisuj uprzywilejowane role magazynu w trybie just-in-time za pomocą rozwiązania Microsoft Entra Privileged Identity Management (PIM): W przypadku ról, które umożliwiają wprowadzanie zmian w płaszczyźnie zarządzania magazynem (takich jak Współautor konta magazynu lub Właściciel), wymagaj aktywacji PIM z zatwierdzeniem i uwierzytelnianiem wieloskładnikowym zamiast stałych przypisań. Aby uzyskać więcej informacji, zobacz Co to jest microsoft Entra Privileged Identity Management?.

Ochrona danych

Azure Storage domyślnie szyfruje wszystkie dane w spoczynku za pomocą kluczy zarządzanych przez Microsoft. Rekomendacje zawarte w tej sekcji dodają kontroli nad klientem, chronią przed przypadkowymi lub złośliwymi modyfikacjami oraz ograniczają ekspozycję danych podczas transportu i spoczynku.

  • Konfiguruj klucze zarządzane przez klienta (CMK) do szyfrowania w spoczynku: Użyj klucza zarządzanego w Azure Key Vault lub Managed HSM jako klucza do szyfrowania konta. CMK pozwala obracać, audytować i cofać klucz szyfrujący niezależnie od kluczy zarządzanych przez Microsoft. Obsługuje wymagania dotyczące zgodności, które wymagają kontroli klienta nad kluczami. Aby uzyskać więcej informacji, zobacz Klucze zarządzane przez klienta na potrzeby szyfrowania usługi Azure Storage.

  • Włącz szyfrowanie infrastruktury dla podwójnego szyfrowania obronnego w głębi: szyfrowanie infrastruktury stosuje drugą, usługowo zarządzaną warstwę szyfrowania na podstawowej warstwie szyfrowania. Musisz ją włączyć przy tworzeniu konta. Więcej informacji można znaleźć w artykule Włącz szyfrowanie infrastruktury dla podwójnego szyfrowania danych.

  • Używaj zakresów szyfrowania do izolowania szyfrowania dla konkretnych kontenerów lub blobów: Zakresy szyfrowania pozwalają stosować różne klucze lub polityki rotacji kluczy na poziomie kontenera lub blob-a w ramach jednego konta. Ta funkcja jest przydatna w przypadku obciążeń wielodzierżawnych, które korzystają ze wspólnego konta, ale wymagają indywidualnego zarządzania kluczami dla każdego dzierżawcy. Więcej informacji można znaleźć w artykule Encryption scopes for Blob Storage.

  • Włącz szyfrowanie Azure Storage dla wszystkich danych w trakcie transportu: Połącz Secure transfer required = enabled (zobacz bezpieczeństwo sieci) z minimalną wersją TLS 1.2 lub nowszą. Razem zapewniają, że konto odrzuca zarówno połączenia nieszyfrowane, jak i słabo zaszyfrowane.

  • Stosuj szyfrowanie po stronie klienta dla najbardziej wrażliwych danych: dla danych, których tekst jawny nigdy nie może pojawić się na serwerze, zaszyfruj go w kliencie przed przesłaniem. Szyfrowanie po stronie klienta jest uzupełnieniem szyfrowania po stronie usługi i może być używane razem z CMK do ochrony warstwowej. Informacje o obsłudze pakietu SDK i wzorcach dla poszczególnych usług znajdują się w artykule Powiązane artykuły dotyczące zabezpieczeń.

  • Chroń konto pamięci za pomocą blokady zasobów: Zastosuj blokadę CanNotDelete lub ReadOnly , aby zapobiec przypadkowemu lub złośliwemu usunięciu lub rekonfiguracji samego konta. Blokady dotyczą zasobu konta, a nie danych w nim zawartych, więc uzupełniają – a nie zastępują – miękkie usuwanie i niezmienność. Aby uzyskać więcej informacji, zobacz Jak zastosować blokadę usługi Azure Resource Manager do konta magazynowego.

Aby uzyskać funkcje ochrony danych specyficzne dla usług danych (niezmienność blobów i polityki WORM, zakres szyfrowania blobów), zobacz odpowiadający podartykuł w powiązanych artykułach o bezpieczeństwie.

Rejestrowanie i monitorowanie

Konta przechowywane są częstym celem kradzieży poświadczeń, prób ewakuacji i błędnej konfiguracji. Potrzebujesz ciągłego rejestrowania i wykrywania zagrożeń, aby szybko wykrywać i reagować na ataki.

  • Włącz Microsoft Defender for Storage: Defender for Storage zapewnia wykrywanie zagrożeń, skanowanie złośliwego oprogramowania podczas przesyłania w poszukiwaniu blobów oraz wykrywanie wrażliwych danych. Oznacza anomalne wzorce dostępu, znane złośliwe adresy IP i wyjścia z Tor oraz nietypową aktywność uwierzytelniającą. Włącz to na poziomie subskrypcji lub konta pamięciowego. Więcej informacji można znaleźć w artykule Przegląd Microsoft Defender for Storage.

    • Włącz skanowanie w poszukiwaniu złośliwego oprogramowania dla przekazywanych obiektów blob na kontach akceptujących niezaufane treści: Skanowanie w poszukiwaniu złośliwego oprogramowania analizuje przekazane obiekty blob oraz oznacza lub usuwa złośliwe treści, zanim zostaną one udostępnione kolejnym odbiorcom. Więcej informacji można znaleźć w artykule Skanowanie złośliwego oprogramowania w Defender for Storage.

    • Umożliwienie wykrywania zagrożeń w danych wrażliwych: Wykrywanie wrażliwych danych klasyfikuje dane na koncie i priorytetowo traktuje alerty dotyczące kontenerów zawierających wrażliwe informacje. Więcej informacji można znaleźć w sekcji Odkrywanie wrażliwych danych w Defender for Storage.

  • Wyślij ustawienia diagnostyczne do przestrzeni roboczej Log Analytics: Skonfiguruj ustawienia diagnostyczne na koncie i każdej usłudze danych (Bloby, Pliki, Kolejki, Tabele) do wysyłania StorageRead, StorageWrite, oraz StorageDelete logów oraz wszystkich metryk do Log Analytics. Przechowuj logi przez okres wymagany przez twoje obowiązki w zakresie zgodności. Aby uzyskać więcej informacji, zobacz Monitorowanie usługi Azure Storage.

  • Audyt, jak każde żądanie jest autoryzowane: Logi pamięci masowej rejestrują, czy każde żądanie zostało autoryzowane za pomocą Microsoft Entra ID, Shared Key, SAS lub anonimowo. Regularnie analizuj dzienniki, aby wykrywać nieoczekiwane metody autoryzacji, zwłaszcza użycie Shared Key po jego wyłączeniu lub dostęp anonimowy po jego wyłączeniu. Więcej informacji można znaleźć w artykule Monitor requests against Azure Storage.

  • Alert dotyczący istotnych zdarzeń zabezpieczeń: Skonfiguruj alerty usługi Azure Monitor dla zdarzeń, takich jak regeneracja kluczy, zmiany reguł zapory, zmiany dostępu do sieci publicznej, użycie klucza Shared Key na kontach, na których powinno być ono wyłączone, oraz alerty usługi Defender for Storage. Aby uzyskać więcej informacji, zobacz Rejestrowanie alertów w usłudze Azure Monitor.

  • Przekaż dzienniki do centralnego systemu SIEM: Aby umożliwić reagowanie na poziomie przedsiębiorstwa, przekaż dzienniki usługi Storage z usługi Log Analytics do Microsoft Sentinel lub innego systemu SIEM, aby można było skorelować zdarzenia związane z magazynem z sygnałami z obszaru tożsamości, sieci i punktów końcowych. Więcej informacji można znaleźć w artykule Connect Azure Storage to Microsoft Sentinel.

Zgodność i ład

Sterowanie zarządzaniem sprawia, że bezpieczne konfiguracje są domyślne i automatycznie wykrywają dryf. Dla każdego magazynu większego niż kilka kont, egzekwowanie polityki jest jedynym trwałym sposobem na utrzymanie spójności bazowego poziomu.

  • Zastosowanie Azure Policy do egzekwowania podstawowego bezpieczeństwa pamięci masowej: Przypisz wbudowane polityki blokujące niebezpieczne konfiguracje w momencie wdrożenia i audytuj istniejące konta. Wbudowane elementy o wysokiej wartości obejmują: wymaganie bezpiecznego transferu, wymaganie minimalnego TLS 1.2, odmowę dostępu do sieci publicznej, odmowę dostępu do publicznego blob, wymaganie szyfrowania infrastruktury oraz wymóg CMK. Pełną listę można znaleźć tutaj: wbudowane definicje usługi Azure Policy dla Azure Storage oraz kontrole zgodności z przepisami usługi Azure Policy dla Azure Storage.

  • Użyj Microsoft Cloud Security Benchmark (MCSB) jako punktu wyjścia: Dostosuj kontrole pamięci masowej z domenami MCSB v2, aby zapewnić spójną pozycję bezpieczeństwa w różnych usługach. Więcej informacji można znaleźć w artykule Przegląd benchmarku bezpieczeństwa chmury Microsoft.

  • Oznaczaj konta pamięci masowej według właściciela, klasyfikacji danych i środowiska: Polityki zarządzania, zarządzanie kosztami i reagowanie na incydenty zależą od konsekwentnego tagowania. Stosuj tagi przez Azure Policy, aby nie mogły być pomijane przy tworzeniu.

  • Przejrzyj oferty zgodności przed przechowywaniem danych regulowanych: Azure Storage posiada certyfikaty dla wspólnych ram regulacyjnych (HIPAA, PCI DSS, FedRAMP, ISO 27001 i inne). Potwierdź pokrycie dla obciążenia roboczego przed wdrożeniem. Więcej informacji można znaleźć w artykule o ofertach zgodności Azure Storage.

Kopia zapasowa i przywracanie

Redundancja międzyregionalna oraz zweryfikowane procedury przełączania awaryjnego zapewniają odporność na poziomie regionu dla samego konta magazynu. W celu ochrony przed usuwaniem specyficzną dla usługi danych (miękkie usuwanie blobów, wersjonowanie blobów, feed change, przywracanie w czasie, miękkie usuwanie plików i migawki) zobacz odpowiadający podartykuł w sekcji Powiązane artykuły o bezpieczeństwie.

  • Wybierz odpowiednią opcję redundancji dostosowaną do wymagań dotyczących odzyskiwania danych: Magazyn geograficznie nadmiarowy (GRS/RA-GRS/GZRS/RA-GZRS) replikuje dane do sparowanego regionu i obsługuje przełączenie awaryjne inicjowane przez klienta w celu zapewnienia odporności na awarie w regionie. Magazynowanie nadmiarowe strefowo (ZRS/GZRS) chroni przed awariami całej strefy w obrębie regionu. Aby uzyskać więcej informacji, zapoznaj się z redundancją usługi Azure Storage.

  • Nie polegaj na georedundancji jako ochronie przed ransomware: Replikacja georedundantna odwzorowuje dane — a także wszelkie uszkodzenia lub celowe usunięcia — w sparowanym regionie. Połącz GRS z politykami niezmienności, miękkim usuwaniem i wersjonowaniem pod kątem odporności na ransomware i manipulacje. Więcej informacji można znaleźć w artykule o funkcjach ochrony danych w Azure Storage.

  • Ćwicz przełączanie awaryjne inicjowane przez klienta oraz powrót po awarii: W przypadku kont z RA-GRS lub RA-GZRS przeprowadź planowane ćwiczenie przełączenia awaryjnego, aby zweryfikować procedurę odzyskiwania, zanim będzie to potrzebne. Aby uzyskać więcej informacji, zobacz Odzyskiwanie po awarii i przełączanie awaryjne konta magazynowego.

Szczegółowe wytyczne dotyczące bezpieczeństwa dla każdej usługi danych Azure Storage można znaleźć w następstwie:

Następne kroki

  • Ostatnia aktualizacja o