Migrowanie do RBAC platformy Azure z zasad dostępu

Usługa Azure Key Vault oferuje dwa modele kontroli dostępu: kontrolę dostępu opartą na rolach (RBAC) platformy Azure i model zasad dostępu. Kontrola dostępu oparta na rolach (RBAC) platformy Azure jest domyślnym i zalecanym modelem kontroli dostępu dla usługi Azure Key Vault. Porównanie dwóch metod autoryzacji można znaleźć w temacie Kontrola dostępu oparta na rolach (RBAC) platformy Azure a zasady dostępu.

Ten artykuł zawiera niezbędne informacje do migracji magazynu kluczy z modelu opartego na zasadach dostępu na model RBAC w platformie Azure.

Mapowanie zasad dostępu do ról platformy Azure

Kontrola dostępu oparta na rolach (RBAC) w Azure posiada kilka wbudowanych ról, które można przypisać do użytkowników, grup, podmiotów zabezpieczeń oraz tożsamości zarządzanych. Jeśli wbudowane role nie spełniają konkretnych potrzeb Twojej organizacji, możesz utworzyć własne niestandardowe role na platformie Azure.

Wbudowane role usługi Key Vault dla kluczy, certyfikatów i zarządzania dostępem do sekretów:

• Administrator magazynu kluczy
• Czytelnik usługi Key Vault
• Operator czyszczenia Key Vault
• Oficer certyfikatów usługi Key Vault
• Użytkownik certyfikatu usługi Key Vault
• Oficer kryptograficzny Key Vault
• Użytkownik kryptograficzny usługi Key Vault
• Użytkownik szyfrowania usługi kryptograficznej Key Vault
• Użytkownik wydania usługi kryptograficznej Key Vault
• Oficer wpisów tajnych usługi Key Vault
• Użytkownik sekretów Key Vault

Aby uzyskać więcej informacji na temat istniejących wbudowanych ról, zobacz Role wbudowane platformy Azure

Zasady dostępu do magazynu można przypisywać indywidualnie z wybranymi uprawnieniami lub ze wstępnie zdefiniowanymi szablonami uprawnień.

Wstępnie zdefiniowane szablony uprawnień zasad dostępu:

• Klucz, wpis tajny, zarządzanie certyfikatami
• Zarządzanie kluczami i tajemnicami
• Zarządzanie tajemnicami i certyfikatami
• Zarządzanie kluczami
• Zarządzanie tajemnicami
• Zarządzanie certyfikatami
• SQL Server Connector
• Azure Data Lake Storage lub Azure Storage
• Azure Backup
• Klucz klienta usługi Exchange Online
• Klucz klienta usługi SharePoint Online
• Azure Information BYOK

Uzyskiwanie dostępu do szablonów zasad do mapowania ról platformy Azure

Mapowanie zakresów przydziału

Kontrola dostępu oparta na rolach platformy Azure dla usługi Key Vault umożliwia przypisanie ról w następujących zakresach:

• Grupa zarządzania
• Subskrypcja
• Grupa zasobów
• Zasób usługi Key Vault
• Pojedynczy klucz, wpis tajny i certyfikat

Zasady dostępu są ograniczone do przypisywania zasad tylko na poziomie zasobów usługi Key Vault.

Ogólnie rzecz biorąc, najlepszym rozwiązaniem jest posiadanie jednego magazynu kluczy na aplikację i zarządzanie dostępem na poziomie magazynu kluczy. Istnieją scenariusze, w których zarządzanie dostępem w innych zakresach może uprościć zarządzanie dostępem.

• Infrastruktura, administratorzy zabezpieczeń i operatorzy: zarządzanie grupą magazynów kluczy na poziomie grupy zarządzania, subskrypcji lub grupy zasobów przy wykorzystaniu polityk dostępu do magazynu wymaga utrzymania polityk dla każdego magazynu kluczy. Kontrola dostępu oparta na rolach platformy Azure umożliwia utworzenie jednego przypisania roli w grupie zarządzania, subskrypcji lub grupie zasobów. To przypisanie będzie miało zastosowanie do wszystkich nowych magazynów kluczy utworzonych w tym samym zakresie. W tym scenariuszu zaleca się używanie usługi Privileged Identity Management z dostępem just in time w celu zapewnienia stałego dostępu.

• Aplikacje: istnieją scenariusze, w innych przypadkach aplikacja musi udostępniać tajne informacje innym aplikacjom. Aby uniknąć udzielania dostępu do wszystkich wpisów tajnych, należy utworzyć oddzielne zasady dostępu do magazynu. Kontrola dostępu oparta na rolach platformy Azure umożliwia przypisywanie roli z zakresem pojedynczego wpisu tajnego zamiast korzystania z pojedynczego magazynu kluczy.

Jak przeprowadzić migrację

Aby przeprowadzić migrację magazynu kluczy z zasad dostępu do kontroli dostępu opartej na rolach platformy Azure (Azure RBAC), wykonaj następujące kroki:

• Przygotowanie: Upewnij się, że masz odpowiednie uprawnienia i spis aplikacji.
• Inwentaryzacja: Dokumentuj wszystkie istniejące zasady dostępu i uprawnienia.
• Tworzenie ról RBAC platformy Azure: przypisz odpowiednie role RBAC platformy Azure do każdego podmiotu zabezpieczeń.
• Włącz kontrolę dostępu na podstawie ról platformy Azure: przełącz magazyn kluczy, aby używać modelu kontroli dostępu na podstawie ról platformy Azure.
• Weryfikowanie: przetestuj dostęp, aby zapewnić wszystkim aplikacjom i użytkownikom zachowanie odpowiedniego dostępu.
• Monitorowanie: konfigurowanie monitorowania i zgłaszania alertów w przypadku problemów z dostępem.

Wymagania wstępne

Przed rozpoczęciem migracji upewnij się, że masz następujące elementy:

1. Wymagane uprawnienia: musisz mieć następujące uprawnienia w repozytorium kluczy:

   • Microsoft.Authorization/roleAssignments/write uprawnienia, uwzględnione w rolach właściciela i administratora dostępu użytkowników
   • Microsoft.KeyVault/vaults/write uprawnienia uwzględnione w roli Współautor usługi Key Vault

   Uwaga

   Role klasycznego administratora subskrypcji (administrator usługi i Co-Administrator) nie są obsługiwane.

2. Spis aplikacji i tożsamości: Sporządź listę wszystkich aplikacji, usług i użytkowników, którzy uzyskują dostęp do magazynu kluczy, oraz udokumentuj wszystkie bieżące zasady dostępu i uprawnienia, które udzielają.

Spis bieżących zasad dostępu

Udokumentować wszystkie istniejące zasady dostępu, zwracając uwagi na podmioty zabezpieczeń (użytkowników, grupy, jednostki usługi) i ich uprawnienia.

# List all current access policies
az keyvault show --name <vault-name> --resource-group <resource-group-name> --query properties.accessPolicies

# List all current access policies
$vault = Get-AzKeyVault -VaultName "<vault-name>" -ResourceGroupName "<resource-group-name>"
$vault.AccessPolicies

Utwórz równoważne przypisania ról Azure RBAC

Dla każdego podmiotu zabezpieczeń z zasadą dostępu utwórz co najmniej jedno przypisanie roli RBAC platformy Azure na podstawie wymienionej powyżej tabeli mapowania.

# Example for Key Vault Administrator role:
az role assignment create --role "Key Vault Administrator" --assignee "<object-id-or-email>" --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.KeyVault/vaults/<vault-name>"

# Example for Key Vault Secrets Officer:
az role assignment create --role "Key Vault Secrets Officer" --assignee "<object-id-or-email>" --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.KeyVault/vaults/<vault-name>"

# Example for Key Vault Crypto Officer:
az role assignment create --role "Key Vault Crypto Officer" --assignee "<object-id-or-email>" --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.KeyVault/vaults/<vault-name>"

# Example for Key Vault Certificates Officer:
az role assignment create --role "Key Vault Certificates Officer" --assignee "<object-id-or-email>" --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.KeyVault/vaults/<vault-name>"

# Example for Key Vault Administrator role:
New-AzRoleAssignment -RoleDefinitionName "Key Vault Administrator" -ObjectId "<object-id>" -Scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.KeyVault/vaults/<vault-name>"

# Example for Key Vault Secrets Officer:
New-AzRoleAssignment -RoleDefinitionName "Key Vault Secrets Officer" -ObjectId "<object-id>" -Scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.KeyVault/vaults/<vault-name>"

# Example for Key Vault Crypto Officer:
New-AzRoleAssignment -RoleDefinitionName "Key Vault Crypto Officer" -ObjectId "<object-id>" -Scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.KeyVault/vaults/<vault-name>"

# Example for Key Vault Certificates Officer:
New-AzRoleAssignment -RoleDefinitionName "Key Vault Certificates Officer" -ObjectId "<object-id>" -Scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.KeyVault/vaults/<vault-name>"

Włącz Azure RBAC

Po utworzeniu wszystkich niezbędnych przypisań ról przełącz skrytkę, aby używała modelu uprawnień RBAC Azure.

# Switch the vault to Azure RBAC
az keyvault update --name <vault-name> --resource-group <resource-group-name> --enable-rbac-authorization true

# Switch the vault to Azure RBAC permission model
$vault = Get-AzKeyVault -VaultName "<vault-name>" -ResourceGroupName "<resource-group-name>"
Update-AzKeyVault -VaultName $vault.VaultName -ResourceGroupName $vault.ResourceGroupName -EnableRbacAuthorization $true

Weryfikowanie dostępu

Przetestuj dostęp do sejfu, aby upewnić się, że wszystkie aplikacje i użytkownicy nadal mogą wykonywać wymagane operacje.

# Try to list secrets to verify access
az keyvault secret list --vault-name <vault-name>

# Try to get a secret to verify access
az keyvault secret show --vault-name <vault-name> --name <secret-name>

# Try to list secrets to verify access
Get-AzKeyVaultSecret -VaultName "<vault-name>"

# Try to get a secret to verify access
Get-AzKeyVaultSecret -VaultName "<vault-name>" -Name "<secret-name>"

Konfigurowanie monitorowania i zgłaszania alertów

Po migracji skonfiguruj odpowiednie monitorowanie, aby wykryć wszelkie problemy z dostępem:

# Enable diagnostics logging for Key Vault
az monitor diagnostic-settings create --resource <vault-id> --name KeyVaultLogs --logs "[{\"category\":\"AuditEvent\",\"enabled\":true}]" --workspace <log-analytics-workspace-id>

# Get the vault resource ID
$vaultResourceId = (Get-AzKeyVault -VaultName "<vault-name>" -ResourceGroupName "<resource-group-name>").ResourceId

# Enable diagnostics logging for Key Vault
$logs = @()
$logs += New-AzDiagnosticSettingLogSettingsObject -Category "AuditEvent" -Enabled $true
Set-AzDiagnosticSetting -ResourceId $vaultResourceId -Name "KeyVaultLogs" -WorkspaceId "<log-analytics-workspace-id>" -Log $logs

Zarządzanie migracją za pomocą usługi Azure Policy

Za pomocą usługi Azure Policy możesz zarządzać migracją RBAC platformy Azure w skrytkach. Możesz utworzyć niestandardową definicję zasad, aby przeprowadzać inspekcję istniejących magazynów kluczy oraz wymusić, aby wszystkie nowe magazyny kluczy używały kontroli dostępu opartej na rolach (Azure RBAC).

Tworzenie i przypisywanie definicji polityki dla Azure RBAC usługi Key Vault

1. Przejdź do zasobu zasad
2. Wybierz pozycję Przypisania w obszarze Tworzenie po lewej stronie strony usługi Azure Policy
3. Wybierz Przypisz zasady na górze strony
4. Wprowadź następujące informacje:
   • Zdefiniuj zakres zasad, wybierając subskrypcję i grupę zasobów
   • Wybierz definicję zasad: "[wersja zapoznawcza]: Azure Key Vault powinien używać kontroli dostępu na podstawie ról w Azure.
   • Definiowanie żądanego efektu zasad (Inspekcja, Odmowa lub Wyłączone)
5. Ukończ zadanie, przeglądając i tworząc je.

Po przypisaniu polisy wykonanie skanowania może potrwać do 24 godzin. Po zakończeniu skanowania można zobaczyć wyniki zgodności na pulpicie nawigacyjnym usługi Azure Policy.

Narzędzie Porównawcze Polityki Dostępu do Azure RBAC

Narzędzie PowerShell do porównywania zasad dostępu usługi Key Vault z przypisanymi rolami RBAC na platformie Azure, aby ułatwić migrację do kontroli dostępu opartej na rolach platformy Azure. Celem narzędzia jest zapewnienie kontroli kondycji podczas migrowania istniejącej usługi Key Vault do kontroli dostępu opartej na rolach platformy Azure w celu zapewnienia, że przypisane role z podstawowymi akcjami danych obejmują istniejące zasady dostępu.

Rozwiązywanie typowych problemów

• Opóźnienie przypisania roli: Przypisania ról mogą propagować się przez kilka minut. Zaimplementuj logikę ponawiania prób w aplikacjach.
• Utracone przypisania ról po odzyskiwaniu: przypisania ról nie są zachowywane po odzyskaniu magazynu po usunięciu nietrwałym. Po odzyskaniu musisz ponownie utworzyć wszystkie przypisania ról.
• Błędy odmowy dostępu: Sprawdź, czy:
  • Prawidłowe role są przypisywane w odpowiednim zakresie
  • Jednostka usługi lub tożsamość zarządzana mają dokładne wymagane uprawnienia
  • Reguły dostępu do sieci nie blokują połączenia
• Skrypty napotykają błędy po migracji: zaktualizuj wszystkie skrypty, które używały zasad dostępu, aby zamiast tego korzystać z przypisań ról.

Dowiedz się więcej

• Omówienie kontroli dostępu opartej na rolach platformy Azure
• Samouczek dotyczący ról niestandardowych
• Zarządzanie tożsamością uprzywilejowaną