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

Artykuł
09/01/2024

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 pełnomocnik ma tylko uprawnienia, które muszą wykonać. 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 oczekują na przypisanie roli, których potrzebują.
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. Na 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 jako administrator subskrypcji platformy Azure.

Alicja przypisuje rolę administratora dostępu użytkowników do aplikacji Dara.
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.

Pełnomocnik ma nieograniczony dostęp w zakresie 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ę do dowolnego użytkownika w zakresie, w tym do siebie.
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ć Dara na tworzenie niektórych przypisań ról w jej imieniu, ale nie wszystkich przypisań ról. Na przykład Alice może ograniczyć role, do których Dara może przypisywać i ograniczać podmioty zabezpieczeń, do których 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.

Alicja przypisuje rolę Administratora kontroli dostępu opartej na rolach do Dara. Alicja dodaje warunki, aby Dara mogła przypisywać tylko role Współautor kopii zapasowych lub Czytelnik kopii zapasowych do grup Marketing i Sales.
Dara może teraz przypisywać role Współautor kopii zapasowych lub Czytelnik kopii zapasowych do grup Marketing i Sales.
Jeśli Dara próbuje przypisać inne role lub przypisać dowolne role do różnych podmiotów zabezpieczeń (takich jak użytkownik lub tożsamość zarządzana), przypisanie roli nie powiedzie się.

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:

Tworzenie przypisania roli w określonym zakresie
Usuwanie przypisania roli w określonym zakresie
Odczytywanie zasobów wszystkich typów, z wyjątkiem wpisów tajnych
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ć
Ograniczenie ról i typów podmiotów zabezpieczeń (użytkowników, grup lub jednostek usługi), które mogą być przypisane role
Ogranicz role i określone podmioty zabezpieczeń, które mogą być przypisane role
Określanie różnych warunków dla akcji dodawania i usuwania przypisania 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.

Określanie uprawnień wymaganych przez pełnomocnika
- Jakie role mogą przypisywać pełnomocnik?
- Do jakich typów podmiotów zabezpieczeń można przypisać role pełnomocnika?
- Do których podmiotów zabezpieczeń można przypisać role?
- Czy można delegować usunąć wszystkie przypisania ról?
Rozpoczynanie nowego przypisania roli
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ń.
Wybierz pełnomocnika

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

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.

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

Aby uzyskać więcej informacji, zobacz Delegowanie zarządzania przypisaniem ról platformy Azure do innych osób z warunkami.

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

az role assignment create

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%

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'}))"
    }
  }
}

Przypisania ról — tworzenie

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"
  }
}

Przypisywanie roli z warunkiem do delegowania

Po określeniu warunku ukończ przypisanie roli.
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:

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 zabezpieczeń (użytkowników, grup lub jednostek usługi) lub określonych podmiotów zabezpieczeń, które mogą być przypisane do ról usługi 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 mieć przypisania roli z akcją danych Microsoft.Storage i warunkiem ABAC, który używa 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 dotyczące licencji

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

Udostępnij za pośrednictwem