Zabezpiecz magazyn tabel Azure

Azure Table Storage udostępnia magazyn danych NoSQL typu klucz-wartość dla ustrukturyzowanych, nierelacyjnych danych. Bezpieczeństwo tabel ma wspólne podstawy z innymi usługami danych w usłudze Azure Storage, ale ma też kilka cech szczególnych — w tym odrębny mechanizm autoryzacji Microsoft Entra ID oraz częściowe pokrywanie się z interfejsem API tabel usługi Azure Cosmos DB — które zasługują na uwagę.

Note

Ten artykuł dotyczy praktyk bezpieczeństwa specyficznych dla Azure Table Storage. Wskazówki dotyczące bezpieczeństwa na poziomie konta znajdziesz w artykule Zabezpiecz swoje konto Azure Storage.

Zabezpieczenia specyficzne dla usługi

Zarówno Azure Table Storage, jak i Azure Cosmos DB for Table API udostępniają podobny model danych tabel, ale ich możliwości bezpieczeństwa znacznie się różnią. Wybierz platformę spełniającą Twoje wymagania bezpieczeństwa na początku projektu. Migracja danych między nimi nie jest banalna.

  • Używaj Azure Cosmos DB for Table, gdy potrzebujesz dedykowanej przepustowości, globalnej dystrybucji lub bardziej szczegółowej izolacji sieci na tabelę: Cosmos DB for Table API to odrębny zasób z własnymi prywatnymi punktami końcowymi, zaporą sieciową i konfiguracją IAM, niezależną od jakiegokolwiek konta magazynowego. Daje to izolowany promień wybuchu, gdy obciążenie Table ma inne wymagania sieciowe lub administracyjne niż obciążenia współdzielące Twoje konto pamięci ogólnego przeznaczenia. Aby uzyskać więcej informacji, zobacz Introduction to Azure Cosmos DB for Table.

  • Korzystaj z Azure Table Storage, gdy potrzebujesz współlokacji na poziomie konta z blobami, plikami i kolejkami: Table Storage znajduje się w kontach ogólnego przeznaczenia, więc na wszystkich czterech usługach danych obowiązuje jeden zestaw reguł sieciowych, prywatnych punktów końcowych i polityk tożsamości. Cosmos DB for Table to osobny zasób z niezależną konfiguracją zabezpieczeń.

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

  • Użyj Microsoft Entra ID do autoryzacji operacji z danymi tabel: autoryzacja Entra ID eliminuje potrzebę posiadania kluczy kont w kodzie aplikacji i zapewnia ślady audytowe oparte na tożsamości. Przypisz wbudowane role Storage Table Data Reader lub Storage Table Data Contributor na poziomie tabeli, jeśli to możliwe. Więcej informacji można znaleźć w artykule Autoryzuj dostęp do tabel z użyciem Microsoft Entra ID.

  • Przypisanie ról zakresowych do konkretnych tabel: Obsługiwany jest zakres na poziomie tabeli dla wbudowanych ról danych tabelowych. Gdy usługa potrzebuje dostępu tylko do jednej tabeli, przypisz rolę do zasobu tabeli zamiast do konta.

  • Zakres tokenów SAS do określonych zakresów partycji i wierszy: Tabela SAS obsługuje ograniczenia dotyczące klucza partycji i zakresu klucza wierszowego. Użyj ich, aby token ograniczał dostęp do wierszy pojedynczego tenanta w tabeli wielodostępnej lub do konkretnego wycinka danych. 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).

  • Przyznaj tylko wymagane uprawnienia do określonych operacji na tabeli: SAS tabeli obsługuje osobno uprawnienia query, add, update i delete. Wywołujący typu reader powinien przechowywać wyłącznie query, nigdy update ani delete.

Ochrona danych

Table Storage przechowuje encje jako płaskie zbiory właściwości, bez list ACL dla poszczególnych encji. Weź pod uwagę bezpieczeństwo w strategii partycjonowania, zamiast próbować modernizować kontrolę dostępu.

  • Partycjonuj tabele zgodnie z granicami dostępu: Gdy tabela obsługuje wielu tenantów lub wiele poziomów klasyfikacji, wybierz klucz partycji, który grupuje encje według tenanta lub klasyfikacji. Połącz to z ograniczeniami zakresu klucza partycji w SAS, aby wymusić izolację dzierżawców bez osobnej tabeli dla każdego dzierżawcy.

  • Nie przechowuj sekretów ani zbędnych danych osobowych we właściwościach encji: Encje są widoczne dla każdego podmiotu zabezpieczeń, który ma dostęp query lub read do tabeli lub partycji. Przechowuj sekrety w Azure Key Vault z odniesieniami w encji i minimalizuj dane osobowe umieszczane w obiektach możliwych do zapytań.

  • Szyfruj wrażliwe wartości właściwości na warstwie aplikacji: Dla wartości właściwości, które muszą pozostać poufne, zaszyfruj wartość w kliencie kluczem z Key Vault przed wstawieniem lub aktualizacją. To szyfrowanie jest niezależne od szyfrowania po stronie pamięci masowej zastosowanego do całej tabeli. Aby uzyskać więcej informacji, zobacz About keys (Informacje o kluczach).

Rejestrowanie i monitorowanie

  • Włącz ustawienia diagnostyczne dla operacji tabelowych: Wyślij StorageRead, StorageWrite, i kategorie StorageDelete do Log Analytics. Uwaga o nieoczekiwanych metodach autoryzacji, szczególnie o dostępie do klucza współdzielonego na kontach, gdzie powinien być wyłączony. Więcej informacji można znaleźć w artykule Monitoring Azure Table Storage.

  • Alert na operacje usuwania lub aktualizacji o dużej liczbie danych: Aktywność masowa DeleteEntity lub UpdateEntity odbiegająca od poziomu wyjściowego tabeli może wskazywać na zniszczenie lub manipulację danymi. Ustal punkt odniesienia i zwracaj uwagę na odchylenia.

Następne kroki

  • Ostatnia aktualizacja o