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

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ę:

• Dystrybuować dane klientów na 128 kontach przechowywania 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 Storage Blob w subskrypcji, co znacznie przekracza limit przypisań ról. Posiadanie tylu przyporządkowań ról byłoby trudne, jeśli nie niemożliwe, do utrzymania.

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 obejmuje szerszy zakres grupy zasobów, a warunek wspomaga kontrolę dostępu do kontenerów. Warunek sprawdza, czy nazwa kontenera jest zgodna z niestandardowym atrybutem zabezpieczeń w obiekcie usługi dla klienta.

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 dla 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 z tożsamością, nie mają daty wygaśnięcia i stanowią zagrożenie dla bezpieczeństwa, jeśli są przechowywane.

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. Musisz zarządzać terminem ważności, aby upewnić się, że klienci nie otrzymują błędów. Tokeny sygnatury dostępu współdzielonego wymagają dodatkowego kodu do codziennego zarządzania i obsługi oraz mogą być znaczącym obciążeniem dla zespołu DevOps.

Kontrola dostępu oparta na rolach w Azure umożliwia scentralizowaną, precyzyjną kontrolę dostępu. Kontrola dostępu oparta na rolach Azure ma wią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 dotyczące danych przechowywanych w magazynie obiektów blob. Należą do nich następujące wbudowane role:

  • Kontrybutor danych Storage Blob
  • Właściciel danych usługi Storage Blob
  • Czytelnik danych obiektu blob Storage

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

Są różne atrybuty, których można użyć w swoim warunku, takie jak:

• Nazwa kontenera
• Ścieżka blob
• Tagi indeksu blobów [Klucze]
• Tagi indeksu obiektów blob [Wartości w kluczach]

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. Utwórz warunek w wyższym zakresie

Utwórz jedno lub więcej przypisań 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.

Następne kroki

• Co to jest kontrola dostępu oparta na atrybutach platformy Azure (Azure ABAC)?
• Co to są niestandardowe atrybuty zabezpieczeń w identyfikatorze Entra firmy Microsoft?
• Zezwól na odczyt obiektów blob na podstawie tagów i niestandardowych atrybutów zabezpieczeń (podgląd)