Skalowanie zarządzania przypisaniami ról platformy Azure przy użyciu warunków i niestandardowych atrybutów zabezpieczeń

Artykuł
11/15/2023

Kontrola dostępu oparta na rolach (RBAC) platformy Azure ma limit przypisań ról na subskrypcję. Jeśli musisz utworzyć setki lub nawet tysiące przypisań ról platformy Azure, możesz napotkać ten limit. Zarządzanie setkami lub tysiącami przypisań ról może być trudne. W zależności od scenariusza może być możliwe zmniejszenie liczby przypisań ról i ułatwienie zarządzania dostępem.

W tym artykule opisano rozwiązanie do skalowania zarządzania przypisaniami ról przy użyciu warunków kontroli dostępu opartej na atrybutach platformy Azure (Azure ABAC) i atrybutów zabezpieczeń niestandardowych firmy Microsoft Entra dla podmiotów zabezpieczeń.

Przykładowy scenariusz

Rozważmy firmę o nazwie Contoso z tysiącami klientów, którzy chcą skonfigurować następującą konfigurację:

Dystrybuowanie danych klientów na 128 kontach magazynu ze względów bezpieczeństwa i wydajności.
Dodaj 2000 kontenerów do każdego konta magazynu, na którym istnieje kontener dla każdego klienta.
Reprezentuje każdego klienta przez unikatową jednostkę usługi Firmy Microsoft Entra.
Zezwól każdemu klientowi na dostęp do obiektów w kontenerze, ale nie innych kontenerów.

Ta konfiguracja może potencjalnie wymagać 256 000 przypisań ról właściciela danych obiektu blob usługi Storage w subskrypcji, co wykracza daleko poza limit przypisań ról. Posiadanie wielu przypisań ról byłoby trudne, jeśli nie niemożliwe, do utrzymania.

Diagram showing thousands for role assignments.

Przykładowe rozwiązanie

Sposobem obsługi tego scenariusza w sposób możliwy do utrzymania jest użycie warunków przypisania roli. Na poniższym diagramie przedstawiono rozwiązanie ograniczające 256 000 przypisań ról do tylko jednego przypisania roli przy użyciu warunku. Przypisanie roli znajduje się w wyższym zakresie grupy zasobów, a warunek pomaga kontrolować dostęp do kontenerów. Warunek sprawdza, czy nazwa kontenera jest zgodna z niestandardowym atrybutem zabezpieczeń w jednostce usługi dla klienta.

Diagram showing one role assignment and a condition.

Oto wyrażenie w warunku, które sprawia, że to rozwiązanie działa:

  @Resource[Microsoft.Storage/storageAccounts/blobServices/containers:name]
  StringEquals
  @Principal[Microsoft.Directory/CustomSecurityAttributes/Id:Contosocustomer_name]

Pełny warunek będzie podobny do poniższego. Listę akcji można dostosować do potrzebnych akcji .

(
 (
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/deleteBlobVersion/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/manageOwnership/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/modifyPermissions/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/permanentDelete/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/read'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write'})
 )
 OR 
 (
  @Resource[Microsoft.Storage/storageAccounts/blobServices/containers:name] StringEquals @Principal[Microsoft.Directory/CustomSecurityAttributes/Id:Contosocustomer_name]
 )
)

Dlaczego warto używać tego rozwiązania?

Istnieje kilka mechanizmów kontroli dostępu, których można użyć do zapewnienia dostępu do zasobów płaszczyzny danych.

Klucze dostępu to typowy sposób zapewniania dostępu do zasobów płaszczyzny danych. Klucze dostępu zapewniają uprawnienia do odczytu, zapisu i usuwania osób posiadających klucz dostępu. Oznacza to, że osoby atakujące mogą uzyskać dostęp do poufnych danych, jeśli mogą uzyskać klucze dostępu. Klucze dostępu nie mają powiązania tożsamości, nie mają wygaśnięcia i stanowią zagrożenie bezpieczeństwa do przechowywania.

Podobnie jak klucze dostępu, tokeny sygnatury dostępu współdzielonego (SAS) nie mają powiązania tożsamości, ale wygasają regularnie. Brak powiązania tożsamości reprezentuje takie same zagrożenia bezpieczeństwa, jak klucze dostępu. Aby upewnić się, że klienci nie otrzymują błędów, musisz zarządzać wygaśnięciem. Tokeny sygnatury dostępu współdzielonego wymagają dodatkowego kodu do codziennego zarządzania i działania oraz mogą być znaczącym obciążeniem dla zespołu DevOps.

Kontrola dostępu oparta na rolach platformy Azure zapewnia scentralizowaną szczegółową kontrolę dostępu. Kontrola dostępu oparta na rolach platformy Azure ma powiązanie tożsamości, które zmniejsza ryzyko bezpieczeństwa. Przy użyciu warunków można potencjalnie skalować zarządzanie przypisaniami ról i ułatwić utrzymanie kontroli dostępu, ponieważ dostęp jest oparty na elastycznych i dynamicznych atrybutach.

Oto niektóre korzyści wynikające z tego rozwiązania:

Scentralizowana kontrola dostępu
Łatwiejsza obsługa
Nie polega na kluczach dostępu ani tokenach SAS
Nie wymaga zarządzania dostępem do każdego obiektu
Może potencjalnie poprawić stan zabezpieczeń

Czy możesz użyć tego rozwiązania?

Jeśli masz podobny scenariusz, wykonaj następujące kroki, aby sprawdzić, czy możesz potencjalnie użyć tego rozwiązania.

Krok 1. Określenie, czy spełniasz wymagania wstępne

Aby użyć tego rozwiązania, musisz mieć następujące elementy:

Wiele wbudowanych lub niestandardowych przypisań ról, które mają akcje danych magazynu obiektów blob. Należą do nich następujące wbudowane role:

Krok 2. Identyfikowanie atrybutów, których można użyć w warunku

Istnieje kilka atrybutów, których można użyć w warunku, takich jak:

Nazwa kontenera
Ścieżka obiektu blob
Tagi indeksu obiektów blob [Klucze]
Tagi indeksu obiektów blob [wartości w kluczu]

Możesz również zdefiniować własne niestandardowe atrybuty zabezpieczeń dla użytkowników, aplikacji dla przedsiębiorstw i tożsamości zarządzanych.

Aby uzyskać więcej informacji, zobacz Format i składnia warunku przypisania roli platformy Azure oraz Co to są niestandardowe atrybuty zabezpieczeń w identyfikatorze Entra firmy Microsoft?.

Krok 3. Tworzenie warunku w wyższym zakresie

Utwórz co najmniej jedno przypisanie ról, które używają warunku w wyższym zakresie do zarządzania dostępem. Aby uzyskać więcej informacji, zobacz Dodawanie lub edytowanie warunków przypisywania ról platformy Azure przy użyciu witryny Azure Portal.

Udostępnij za pośrednictwem