Zabezpiecz swój Azure Blob Storage

Azure Blob Storage przechowuje ogromne ilości nieustrukturyzowanych danych obiektowych w kontenerach. Często jest celem eksfiltracji danych, ataków ransomware i incydentów publicznego ujawnienia danych. Ten artykuł zawiera zalecenia dotyczące bezpieczeństwa specyficzne dla kontenerów blobów, blobów oraz hierarchicznych przestrzeni nazw Azure Data Lake Storage.

Note

Ten artykuł omawia praktyki bezpieczeństwa specyficzne dla Azure Blob Storage. Wskazówki dotyczące bezpieczeństwa na poziomie konta znajdziesz w artykule Zabezpiecz swoje konto Azure Storage.

Bezpieczeństwo sieci

  • Niestandardowe domeny frontowe, statyczne strony internetowe oraz wszelkie publicznie udostępniane treści blobowe w Azure Front Door: zakończ TLS w Azure Front Door za pomocą zarządzanego certyfikatu, włącz WAF i ogranicz dostęp do publicznej sieci konta magazynowego, tak aby tylko Front Door mógł dotrzeć do źródła. Własna funkcja domeny niestandardowej w Azure Storage nie obsługuje zarządzanych certyfikatów TLS, a Front Door dodaje ochronę WAF, ograniczenie szybkości i logowanie, których brakuje anonimowemu dostępowi do kontenerów. Więcej informacji można znaleźć w artykule Use Azure Front Door with Azure Storage blobs.

  • Wyłącz punkt końcowy statycznej witryny internetowej, gdy nie jest używany: Kontener $web pozostaje publicznie dostępny do odczytu, gdy funkcja statycznej witryny internetowej jest włączona, nawet jeśli allowBlobPublicAccess ma wartość false. Wyłącz funkcję statycznej strony na kontach, które jej nie potrzebują. Aby uzyskać więcej informacji, zobacz Hostowanie witryn statycznych w usłudze Azure Storage.

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

Anonimowy dostęp publiczny

SAS na poziomie BLOB-level i ABAC

  • Używaj sygnatury dostępu współdzielonego (SAS) delegowanej przez użytkownika zamiast sygnatury dostępu współdzielonego usługi do uzyskiwania dostępu do obiektów blob: Sygnatura dostępu współdzielonego (SAS) delegowana przez użytkownika jest podpisywana przy użyciu poświadczeń Microsoft Entra. Unieważnienie klucza delegacji użytkownika natychmiast unieważnia każdą sygnaturę SAS wystawioną na jego podstawie, zapewniając możliwość unieważnienia, której nie oferują sygnatury SAS usługi ani konta. Aby uzyskać więcej informacji, zobacz Tworzenie sygnatury dostępu współdzielonego (SAS) delegowanego przez użytkownika.

  • Zakres usługi SAS z politykami przechowywania dostępu dla możliwości odwołalności: Jeśli musisz użyć SAS usługi, powiąż go z polityką dostępu przechowywanego na kontenerze. Następnie możesz zmodyfikować lub usunąć politykę, aby cofnąć każdy SAS, który się do niej odwołuje. Jeśli nie ma zasad, SAS usługi można unieważnić tylko przez zmianę kluczy konta, co wpływa na wszystkie pozostałe SAS na tym koncie. Aby uzyskać więcej informacji, zobacz Definiowanie przechowywanych zasad dostępu.

  • Użyj tagów indeksu blobów, aby warunkować dostęp za pomocą ABAC: Połącz tagi indeksu blob z warunkami kontroli dostępu opartymi na atrybutach (ABAC), aby przyznać dostęp do odczytu tylko blobom o określonych wartościach tagów – na przykład Classification=Public. Takie podejście pozwala na przypisanie jednej roli do obsługi wielu dzwoniących bez udzielenia dostępu do wrażliwych danych oznaczonych. Więcej informacji można znaleźć w artykule Autoryzuj dostęp do blobów używając warunków ABAC.

Ochrona danych

  • Używaj zakresów szyfrowania blobów, aby wyizolować szyfrowanie dla konkretnych kontenerów lub blobów: Zakresy szyfrowania pozwalają stosować różne klucze lub polityki rotacji kluczy na poziomie kontenera lub blobu w ramach jednego konta. Ta funkcja jest przydatna w przypadku obciążeń wielodostępnych korzystających ze wspólnego konta, ale wymagających kontroli nad kluczami dla poszczególnych dzierżawców. Więcej informacji można znaleźć w artykule Encryption scopes for Blob Storage.

  • Użyj szyfrowania po stronie klienta dla danych blob, które nigdy nie mogą pojawić się na serwerze w tekście jawnym: Zaszyfruj zawartość blob w kliencie przed przesłaniem. SDK integruje się z Azure Key Vault lub Managed HSM do zarządzania kluczami. Połącz z CMK po stronie serwisowej dla warstwowej ochrony. Więcej informacji można znaleźć w artykule Szyfrowanie po stronie klienta dla blobów.

Niezmienność i WORM

  • Skonfiguruj zasady retencji opartej na czasie dla danych podlegających regulacjom: Zastosuj retencję opartą na czasie na poziomie kontenera lub wersji, aby uniemożliwić modyfikowanie lub usuwanie obiektów blob przez określony okres. Niezmienność na poziomie wersji zapewnia precyzyjniejszą kontrolę i można ją włączać lub rozszerzać w poszczególnych wersjach. Aby uzyskać więcej informacji, odwiedź Przechowywanie niezmiennych danych blob krytycznych dla działalności firmy.

  • Stosuj blokady prawne do bezterminowego przechowywania wynikającego z wymogów prawnych lub potrzeb dochodzeniowych: Blokady prawne uniemożliwiają usunięcie danych, dopóki upoważniony użytkownik wyraźnie nie zwolni blokady, bez ustalonego okresu obowiązywania. Aby uzyskać więcej informacji, odwiedź Przechowywanie niezmiennych danych blob krytycznych dla działalności firmy.

  • Zablokuj zasady przechowywania, aby nie można było ich modyfikować: Użytkownicy z odpowiednimi uprawnieniami mogą skrócić lub usunąć odblokowaną zasadę przechowywania. Zablokowanie polityki sprawia, że okres retencji jest jednokierunkowy. Blokuj dopiero po zweryfikowaniu okresu obowiązywania polisy. Więcej informacji można znaleźć w artykule Konfiguruj polityki niezmienności dla kontenerów.

Replikacja obiektów i operacje kopiowania

  • Ogranicz replikację obiektów do kont źródłowych, które kontrolujesz: Skonfiguruj listę dozwolonych kont źródłowych konta docelowego tak, aby tylko znane, zaufane konta źródłowe mogły przesyłać dane. Aby uzyskać więcej informacji, zobacz Konfigurowanie replikacji obiektów.

  • Zapobiegaj replikacji obiektów między dzierżawami: Nie zezwalaj na zasady replikacji, których konta źródłowe i docelowe znajdują się w różnych dzierżawach Microsoft Entra. To ograniczenie uniemożliwia autoryzowanemu użytkownikowi konfigurację replikacji do zewnętrznego dzierżawcy. Aby uzyskać więcej informacji, zobacz Jak zapobiegać replikacji obiektów w dzierżawach Microsoft Entra.

  • Ogranicz dozwolony zakres operacji kopiowania: Skonfiguruj konto tak, aby zezwalało na operacje kopiowania tylko z kont źródłowych w tym samym dzierżawcy lub tej samej subskrypcji. Ta konfiguracja blokuje wspólną ścieżkę eksfiltracji – kopiowanie z konta prywatnego do konta kontrolowanego przez atakującego. Więcej informacji można znaleźć w artykule Dozwolony zakres operacji kopiowania.

Kopia zapasowa i przywracanie

  • Włącz wersjonowanie blobów, aby zachować wcześniejsze wersje podczas zapisu i usuwania: Po włączeniu wersjonowania każda operacja zapisu lub usuwania tworzy nową wersję i zachowuje poprzedni stan. Możesz uzyskiwać dostęp do wersji i je przywracać. Aby uzyskać więcej informacji, zobacz Wersjonowanie obiektów blob.

  • Włącz soft delete dla blobów i kontenerów: Soft delete zachowuje usunięte bloby i kontenery przez określony okres retencji, dzięki czemu możesz je przywrócić w tym czasie. Konfiguruj osobno miękkie usuwanie na poziomie kontenera i blob-a i włącz oba. Więcej informacji można znaleźć w artykule Soft delete for blobs oraz Soft delete for containers.

  • Włącz przywracanie do określonego punktu w czasie dla kont obiektów blob blokowych: Przywracanie do określonego punktu w czasie działa z wersjonowaniem i usuwaniem nietrwałym, aby przywrócić zakres obiektów blob blokowych do określonego momentu w przeszłości. Ta funkcja jest pomocna w odzyskiwaniu po ransomware. Przywracanie do określonego punktu w czasie wymaga włączenia funkcji wersjonowania, miękkiego usuwania obiektów blob oraz strumienia zmian. Aby uzyskać więcej informacji, zobacz Przywracanie do punktu w czasie dla blokowych obiektów blob.

  • Włącz feed zmian do audytu i analizy kryminalistyki: Feed zmian to uporządkowany, niezmienny dziennik każdej zmiany w blobach na koncie. Oprócz umożliwienia przywracania do określonego momentu zapewnia trwały zapis audytowy na potrzeby dochodzeń. Aby uzyskać więcej informacji, zobacz Obsługa kanału zmiany w Azure Blob Storage.

Azure Data Lake Storage

Data Lake Storage dodaje hierarchiczną przestrzeń nazw oraz listy kontroli dostępu (ACL) podobne do POSIX do Blob Storage. ACL i RBAC współpracują ze sobą — RBAC przyznaje ogólny poziom dostępu, a ACL uszczegóławiają go w systemie plików.

  • Używaj RBAC do dostępu gruboziarnistego i ACL do dostępu drobnoziarnistego: Przypisz wbudowane role RBAC na poziomie kontenera lub konta, aby uzyskać szeroki dostęp. Następnie użyj ACL na katalogach i plikach, aby ograniczyć dostęp w kontenerze. Nie używaj wyłącznie ACL dla uprawnień, których użytkownik potrzebuje w całym kontenerze. RBAC jest bardziej efektywny w ocenie i audytach. Aby uzyskać więcej informacji, zobacz Model kontroli dostępu w usłudze Azure Data Lake Storage.

  • Stosuj domyślne ACL na katalogach, aby dziedziczyć uprawnienia na nowych elementach potomnych: Domyślne ACL dotyczą plików i katalogów utworzonych po ustawieniu ACL. Ustaw je na poziomie katalogu, aby uniknąć zarządzania ACL na poszczególnych plikach. Więcej informacji można znaleźć w sekcji Access Control lists in Azure Data Lake Storage.

  • Włącz hierarchiczną przestrzeń nazw przy tworzeniu konta: Nie możesz włączyć hierarchicznej przestrzeni nazw na istniejącym koncie bez migracji. Jeśli wiesz, że dane obciążenie korzysta z semantyki Data Lake Storage, włącz je od razu, zamiast migrować później. Więcej informacji można znaleźć w Azure Data Lake Storage hierarchical namespace.

Rejestrowanie i monitorowanie

  • Alert dotyczący prób dostępu anonimowego po wyłączeniu dostępu anonimowego: Gdy ustawisz allowBlobPublicAccess na false, filtruj dzienniki magazynu pod kątem AuthenticationType == "Anonymous" i generuj alert przy każdym wykryciu. Te trafienia wskazują na błędnie skonfigurowanego klienta lub próbę sondowania. Aby uzyskać więcej informacji, zobacz Monitorowanie usługi Azure Storage.

  • Włącz i reaguj na wyroki skanowania złośliwego oprogramowania w Defender for Storage: Gdy włączasz skanowanie złośliwego oprogramowania, konfiguruj automatyczną reakcję (usuwanie blobów, tag kwarantanny lub ograniczanie przepływu pracy w dalszej fazie) na MalwareScanningResult werdykty, aby zidentyfikowane złośliwe bloby nie mogły być udostępniane konsumentom. Więcej informacji można znaleźć w artykule Odpowiedz na wyniki skanowania złośliwego oprogramowania w Defender for Storage.

  • Śledź zmiany tagów indeksu obiektu blob pod kątem dryfu klasyfikacji: Jeśli używasz tagów indeksu obiektu blob do definiowania warunków dostępu ABAC, zmiany tych tagów bezpośrednio wpływają na to, kto może odczytać obiekt blob. Rejestruj i generuj alerty dotyczące operacji SetBlobTags wykonywanych na kontenerach wrażliwych. Aby uzyskać więcej informacji, zobacz Zarządzanie danymi w usłudze Azure Blob Storage i ich wyszukiwanie przy użyciu tagów indeksu obiektów blob.

Następne kroki

  • Ostatnia aktualizacja o