Delegowanie zarządzania dostępem do platformy Azure innym osobom

Aby udzielić dostępu do zasobów platformy Azure, należy przypisać role platformy Azure w kontroli dostępu opartej na rolach (RBAC) platformy Azure. Jeśli na przykład użytkownik musi utworzyć witryny internetowe i zarządzać nimi w ramach subskrypcji, przypiszesz rolę Współautor witryny internetowej.

Przypisywanie ról platformy Azure w celu udzielenia dostępu do zasobów platformy Azure jest typowym zadaniem. Jako administrator możesz uzyskać kilka żądań udzielenia dostępu, które chcesz delegować do innej osoby. Chcesz jednak upewnić się, że delegat ma tylko uprawnienia, które są potrzebne do wykonywania pracy. W tym artykule opisano bezpieczniejszy sposób delegowania zarządzania przypisaniem ról do innych użytkowników w organizacji.

Dlaczego deleguj zarządzanie przypisaniem ról?

Oto kilka powodów, dla których warto delegować zarządzanie przypisaniami ról do innych:

• Otrzymujesz kilka żądań przypisywania ról w organizacji.
• Użytkownicy są zablokowani, czekając na przypisanie potrzebnej roli.
• Użytkownicy w odpowiednich działach, zespołach lub projektach mają więcej wiedzy na temat tego, kto potrzebuje dostępu.
• Użytkownicy mają uprawnienia do tworzenia zasobów platformy Azure, ale potrzebują dodatkowego przypisania roli, aby w pełni korzystać z tego zasobu. Przykład:
  • Użytkownicy z uprawnieniami do tworzenia maszyn wirtualnych nie mogą natychmiast zalogować się do maszyny wirtualnej bez roli Logowanie administratora maszyny wirtualnej lub Logowanie użytkownika maszyny wirtualnej. Zamiast śledzić administratora w celu przypisania im roli logowania, bardziej wydajne jest, jeśli użytkownik może przypisać rolę logowania do siebie.
  • Deweloper ma uprawnienia do tworzenia klastra usługi Azure Kubernetes Service (AKS) i usługi Azure Container Registry (ACR), ale musi przypisać rolę AcrPull do tożsamości zarządzanej, aby móc ściągać obrazy z usługi ACR. Zamiast śledzić administratora w celu przypisania roli AcrPull, bardziej wydajne jest przypisanie roli przez dewelopera.

Jak obecnie można delegować zarządzanie przypisaniami ról

Role Właściciel i Administrator dostępu użytkowników to wbudowane role, które umożliwiają użytkownikom tworzenie przypisań ról. Członkowie tych ról mogą zdecydować, kto może mieć uprawnienia do zapisu, odczytu i usuwania dla dowolnego zasobu w subskrypcji. Aby delegować zarządzanie przypisaniem ról do innego użytkownika, możesz przypisać użytkownikowi rolę Właściciel lub Administrator dostępu użytkowników.

Na poniższym diagramie pokazano, jak Alice może delegować obowiązki związane z przypisywaniem ról do Dary. Aby uzyskać szczegółowe instrukcje, zobacz Przypisywanie użytkownika na administratora subskrypcji Azure.

1. Alicja przypisuje rolę Administratora Dostępu Użytkowników do Dary.
2. Dara może teraz przypisać dowolną rolę do dowolnego użytkownika, grupy lub jednostki usługi w tym samym zakresie.

Jakie są problemy z bieżącą metodą delegowania?

Poniżej przedstawiono podstawowe problemy z bieżącą metodą delegowania zarządzania przypisaniem ról do innych osób w organizacji.

• Delegat ma nieograniczony dostęp w obszarze przypisania roli. Narusza to zasadę najniższych uprawnień, która naraża Cię na szerszą powierzchnię ataków.
• Pełnomocnik może przypisać dowolną rolę dowolnemu użytkownikowi w ramach swoich uprawnień, w tym sobie samemu.
• Pełnomocnik może przypisać role Właściciel lub Administrator dostępu użytkowników do innego użytkownika, który może następnie przypisywać role innym użytkownikom.

Zamiast przypisywać role Właściciel lub Administrator dostępu użytkowników, bezpieczniejszą metodą jest ograniczenie możliwości delegata do tworzenia przypisań ról.

Bezpieczniejsza metoda: Delegowanie zarządzania przypisaniem ról przy użyciu warunków

Delegowanie zarządzania przypisaniami ról przy użyciu warunków jest sposobem ograniczenia przypisań ról, które użytkownik może utworzyć. W poprzednim przykładzie Alice może zezwolić Darze na tworzenie niektórych przypisań ról w jej imieniu, ale nie wszystkich. Na przykład Alice może ograniczyć role, które Dara może przypisywać, oraz podmioty, którym Dara może przypisywać role. To delegowanie z warunkami jest czasami określane jako ograniczone delegowanie i jest implementowane przy użyciu warunków kontroli dostępu opartej na atrybutach platformy Azure (Azure ABAC).

Ten film wideo zawiera omówienie delegowania zarządzania przypisaniem ról z warunkami.

Dlaczego deleguj zarządzanie przypisaniem ról przy użyciu warunków?

Oto kilka powodów, dla których delegowanie zarządzania przypisaniami ról do innych osób z warunkami jest bezpieczniejsze:

• Możesz ograniczyć przypisania ról, które może utworzyć delegat.
• Możesz uniemożliwić pełnomocnikowi zezwolenie innemu użytkownikowi na przypisywanie ról.
• Możesz wymusić zgodność zasad organizacji z najniższymi uprawnieniami.
• Zarządzanie zasobami platformy Azure można zautomatyzować bez konieczności udzielania pełnych uprawnień do konta usługi.

Przykład warunków

Rozważmy przykład, w którym Alice jest administratorem z rolą Administratora dostępu użytkowników dla subskrypcji. Alicja chce przyznać Dara możliwość przypisywania określonych ról dla określonych grup. Alicja nie chce, aby Dara miała jakiekolwiek inne uprawnienia do przypisywania ról. Na poniższym diagramie pokazano, jak Alicja może delegować obowiązki związane z przypisywaniem ról do Dary z warunkami.

1. Alicja przypisuje rolę Administratora kontroli dostępu opartej na rolach do Dara. Alicja dodaje warunki, aby Dara mogła przypisywać role Kontrybutora kopii zapasowej lub Czytelnika kopii zapasowych wyłącznie do grup Marketingu i Sprzedaży.
2. Dara może teraz przypisywać role Współautor kopii zapasowych lub Czytelnik kopii zapasowych do grup Marketing i Sales.
3. Jeśli Dara podejmie próbę przypisania innych ról lub przypisania jakichkolwiek ról różnym podmiotom (takim jak użytkownik lub tożsamość zarządzana), przypisanie roli zakończy się niepowodzeniem.

Rola Administratora kontroli dostępu opartej na rolach

Rola Administrator kontroli dostępu opartej na rolach jest wbudowaną rolą przeznaczoną do delegowania zarządzania przypisaniem ról do innych osób. Ma mniej uprawnień niż administrator dostępu użytkowników, co jest zgodne z najlepszymi rozwiązaniami dotyczącymi najniższych uprawnień. Rola Administrator kontroli dostępu opartej na rolach ma następujące uprawnienia:

• Utwórz przypisanie roli w określonym zakresie
• Usuwanie przypisania roli w określonym zakresie
• Odczytywanie zasobów wszystkich typów, z wyjątkiem tajemnic
• Tworzenie i aktualizowanie biletu pomocy technicznej

Sposoby ograniczania przypisań ról

Poniżej przedstawiono sposoby ograniczania przypisań ról przy użyciu warunków. Możesz również połączyć te warunki, aby dopasować je do swojego scenariusza.

• Ogranicz role , które można przypisać

  

• Ogranicz role i typy podmiotów (użytkowników, grup lub jednostek usługi), którym mogą być przypisane role

  

• Ogranicz role i określone podmioty zabezpieczeń, którym można przypisać role

  

• Określ różne warunki dla akcji dodawania i usuwania przypisań roli

  

Jak delegować zarządzanie przypisaniem ról przy użyciu warunków

Aby delegować zarządzanie przypisaniem ról przy użyciu warunków, przypisujesz role zgodnie z bieżącymi czynnościami, ale do przypisania roli jest również dodawany warunek.

1. Określanie uprawnień wymaganych przez pełnomocnika

   • Jakie role mogą przypisywać pełnomocnik?
   • Do jakich typów podmiotów delegat może przypisać role?
   • Do których podmiotów delegat może przypisać role?
   • Czy delegat może usunąć dowolne przypisania ról?

2. Rozpoczynanie nowego przypisania roli

3. Wybieranie roli Administrator kontroli dostępu opartej na rolach

   Możesz wybrać dowolną rolę obejmującą Microsoft.Authorization/roleAssignments/write akcję, ale administrator kontroli dostępu opartej na rolach ma mniej uprawnień.

4. Wybierz pełnomocnika

   Wybierz użytkownika, do którego chcesz delegować zarządzanie przypisaniem ról.

5. Dodaj warunek

   Istnieje wiele sposobów dodawania warunku. Na przykład można użyć szablonu warunku w witrynie Azure Portal, edytora zaawansowanych warunków w witrynie Azure Portal, programie Azure PowerShell, interfejsie wiersza polecenia platformy Azure, aplikacji Bicep lub interfejsie API REST.

   Szablon

   Wybierz z listy szablonów warunków. Wybierz Konfiguruj, aby określić role, typy podmiotów lub podmioty.

   Aby uzyskać więcej informacji, zobacz Delegowanie zarządzania przypisywaniem ról platformy Azure innym osobom z określonymi warunkami.

   

   Edytor warunków

   Jeśli szablony warunków nie działają w twoim scenariuszu lub jeśli chcesz mieć większą kontrolę, możesz użyć edytora warunków.

   Aby zapoznać się z przykładami, zobacz Przykłady delegowania zarządzania przypisaniem ról platformy Azure przy użyciu warunków.

   

   Azure PowerShell

   New-AzRoleAssignment

   $roleDefinitionId = "f58310d9-a9f6-439a-9e8d-f62e7b41a168"
   $principalId = "<principalId>"
   $scope = "/subscriptions/<subscriptionId>"
   $condition = "((!(ActionMatches{'Microsoft.Authorization/roleAssignments/write'})) OR (@Request[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {5e467623-bb1f-42f4-a55d-6e525e11384b, a795c7a0-d4a2-40c1-ae25-d81f01202912} AND @Request[Microsoft.Authorization/roleAssignments:PrincipalType] ForAnyOfAnyValues:StringEqualsIgnoreCase {'User'})) AND ((!(ActionMatches{'Microsoft.Authorization/roleAssignments/delete'})) OR (@Resource[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {5e467623-bb1f-42f4-a55d-6e525e11384b, a795c7a0-d4a2-40c1-ae25-d81f01202912} AND @Resource[Microsoft.Authorization/roleAssignments:PrincipalType] ForAnyOfAnyValues:StringEqualsIgnoreCase {'User'}))"
   $conditionVersion = "2.0"
   New-AzRoleAssignment -ObjectId $principalId -Scope $scope -RoleDefinitionId $roleDefinitionId -Condition $condition -ConditionVersion $conditionVersion
   

   Azure CLI

   az utwórz przypisanie roli

   set roleDefinitionId="f58310d9-a9f6-439a-9e8d-f62e7b41a168"
   set principalId="{principalId}"
   set principalType="User"
   set scope="/subscriptions/{subscriptionId}"
   set condition="((!(ActionMatches{'Microsoft.Authorization/roleAssignments/write'})) OR (@Request[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {5e467623-bb1f-42f4-a55d-6e525e11384b, a795c7a0-d4a2-40c1-ae25-d81f01202912} AND @Request[Microsoft.Authorization/roleAssignments:PrincipalType] ForAnyOfAnyValues:StringEqualsIgnoreCase {'User'})) AND ((!(ActionMatches{'Microsoft.Authorization/roleAssignments/delete'})) OR (@Resource[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {5e467623-bb1f-42f4-a55d-6e525e11384b, a795c7a0-d4a2-40c1-ae25-d81f01202912} AND @Resource[Microsoft.Authorization/roleAssignments:PrincipalType] ForAnyOfAnyValues:StringEqualsIgnoreCase {'User'}))"
   set conditionVersion="2.0"
   az role assignment create --assignee-object-id %principalId% --assignee-principal-type %principalType% --scope %scope% --role %roleDefinitionId% --condition %condition% --condition-version %conditionVersion%
   

   Biceps

   param roleDefinitionResourceId string
   param principalId string
   param condition string
   
   targetScope = 'subscription'
   
   resource roleAssignment 'Microsoft.Authorization/roleAssignments@2020-04-01-preview' = {
     name: guid(subscription().id, principalId, roleDefinitionResourceId)
     properties: {
       roleDefinitionId: roleDefinitionResourceId
       principalId: principalId
       principalType: 'User'
       condition: condition
       conditionVersion:'2.0'
     }
   }
   

   {
     "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
     "contentVersion": "1.0.0.0",
     "parameters": {
       "roleDefinitionResourceId": {
         "value": "providers/Microsoft.Authorization/roleDefinitions/f58310d9-a9f6-439a-9e8d-f62e7b41a168"
       },
       "principalId": {
         "value": "{principalId}"
       },
       "condition": {
         "value": "((!(ActionMatches{'Microsoft.Authorization/roleAssignments/write'})) OR (@Request[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {5e467623-bb1f-42f4-a55d-6e525e11384b, a795c7a0-d4a2-40c1-ae25-d81f01202912} AND @Request[Microsoft.Authorization/roleAssignments:PrincipalType] ForAnyOfAnyValues:StringEqualsIgnoreCase {'User'})) AND ((!(ActionMatches{'Microsoft.Authorization/roleAssignments/delete'})) OR (@Resource[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {5e467623-bb1f-42f4-a55d-6e525e11384b, a795c7a0-d4a2-40c1-ae25-d81f01202912} AND @Resource[Microsoft.Authorization/roleAssignments:PrincipalType] ForAnyOfAnyValues:StringEqualsIgnoreCase {'User'}))"
       }
     }
   }
   

   API REST

   Tworzenie przypisań ról

   PUT https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleAssignments/f58310d9-a9f6-439a-9e8d-f62e7b41a168?api-version=2020-04-01-Preview
   
   {
     "properties": {
       "roleDefinitionId": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/f58310d9-a9f6-439a-9e8d-f62e7b41a168",
       "principalId": "{principalId}",
       "condition": "((!(ActionMatches{'Microsoft.Authorization/roleAssignments/write'})) OR (@Request[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {5e467623-bb1f-42f4-a55d-6e525e11384b, a795c7a0-d4a2-40c1-ae25-d81f01202912} AND @Request[Microsoft.Authorization/roleAssignments:PrincipalType] ForAnyOfAnyValues:StringEqualsIgnoreCase {'User'})) AND ((!(ActionMatches{'Microsoft.Authorization/roleAssignments/delete'})) OR (@Resource[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {5e467623-bb1f-42f4-a55d-6e525e11384b, a795c7a0-d4a2-40c1-ae25-d81f01202912} AND @Resource[Microsoft.Authorization/roleAssignments:PrincipalType] ForAnyOfAnyValues:StringEqualsIgnoreCase {'User'}))",
       "conditionVersion": "2.0"
     }
   }
   

6. Przypisywanie roli z warunkiem do delegowania

   Po tym, jak określisz swój warunek, dokończ przypisywanie roli.

7. Skontaktuj się z pełnomocnikiem

   Poinformuj pełnomocnika, że mogą teraz przypisywać role z warunkami.

Wbudowane role z warunkami

Role Administrator dostępu do danych usługi Key Vault i Administrator dostępu do danych maszyny wirtualnej (wersja zapoznawcza) mają już wbudowany warunek ograniczenia przypisań ról.

Rola Administratora dostępu do danych usługi Key Vault umożliwia zarządzanie dostępem do wpisów tajnych, certyfikatów i kluczy usługi Key Vault. Koncentruje się ona wyłącznie na kontroli dostępu bez możliwości przypisywania ról uprzywilejowanych, takich jak role właściciela lub administratora dostępu użytkowników. Umożliwia to lepsze rozdzielenie obowiązków w scenariuszach, takich jak zarządzanie szyfrowaniem magazynowanych w usługach danych w celu dalszego zachowania zgodności z zasadą najniższych uprawnień. Warunek ogranicza przypisania ról do następujących ról usługi Azure Key Vault:

• Key Vault Administrator
• Oficer certyfikatów usługi Key Vault
• Key Vault Crypto Officer
• Użytkownik szyfrowania usługi kryptograficznej usługi Key Vault
• Użytkownik kryptograficzny usługi Key Vault
• Czytelnik Key Vault
• Oficer wpisów tajnych usługi Key Vault
• Użytkownik sekretów Key Vault

Jeśli chcesz jeszcze bardziej ograniczyć przypisanie roli Administratora Dostępu do Danych usługi Key Vault, możesz dodać własny warunek, aby ograniczyć typy podmiotów (użytkowników, grup lub jednostek usługi) albo konkretnych podmiotów, którym mogą być przypisywane role w Key Vault.

Znane problemy

Poniżej przedstawiono znane problemy związane z delegowaniem zarządzania przypisaniem ról przy użyciu warunków:

• Nie można delegować zarządzania przypisaniami ról dla ról niestandardowych z warunkami przy użyciu usługi Privileged Identity Management.
• Nie można przypisać roli z akcją danych Microsoft.Storage oraz warunkiem ABAC, który korzysta z operatora porównania identyfikatora GUID. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z kontrolą dostępu opartą na rolach platformy Azure.

Wymagania licencyjne

Korzystanie z tej funkcji jest bezpłatne i uwzględnione w subskrypcji platformy Azure.

Następne kroki

• Delegowanie zarządzania przypisaniami ról platformy Azure do innych osób z warunkami
• Co to jest kontrola dostępu oparta na atrybutach platformy Azure (Azure ABAC)?
• Przykłady delegowania zarządzania przypisaniami ról platformy Azure przy użyciu warunków