Zabezpieczanie dostępu do zarządzanych modułów HSM
Zarządzany moduł HSM usługi Azure Key Vault to usługa w chmurze, która chroni klucze szyfrowania. Ponieważ te dane są poufne i krytyczne dla działania firmy, należy zabezpieczyć dostęp do zarządzanych modułów HSM, zezwalając tylko autoryzowanym aplikacjom i użytkownikom na dostęp do niego. Ten artykuł zawiera omówienie modelu kontroli dostępu zarządzanego modułu HSM. Wyjaśniono w nim uwierzytelnianie i autoryzację oraz opisano sposób zabezpieczania dostępu do zarządzanych modułów HSM.
Ten samouczek przeprowadzi Cię przez prosty przykład, który pokazuje, jak osiągnąć rozdzielenie obowiązków i kontroli dostępu przy użyciu kontroli dostępu opartej na rolach platformy Azure i zarządzanego modułu HSM lokalnej kontroli dostępu opartej na rolach. Aby dowiedzieć się więcej o modelu kontroli dostępu zarządzanego modułu HSM, zobacz Temat Managed HSM access control model (Kontrola dostępu zarządzanego modułu HSM).
Wymagania wstępne
Aby wykonać kroki opisane w tym artykule, musisz mieć następujące elementy:
- Subskrypcja Microsoft Azure. Jeśli go nie masz, możesz utworzyć konto bezpłatnej wersji próbnej.
- Interfejs wiersza polecenia platformy Azure w wersji 2.25.0 lub nowszej. Uruchom polecenie
az --version
, aby dowiedzieć się, jaka wersja jest używana. Jeśli konieczna będzie instalacja lub uaktualnienie interfejsu, zobacz Instalowanie interfejsu wiersza polecenia platformy Azure. - Zarządzany moduł HSM w ramach subskrypcji. Zobacz Szybki start: aprowizuj i aktywuj zarządzany moduł HSM przy użyciu interfejsu wiersza polecenia platformy Azure, aby aprowizować i aktywować zarządzany moduł HSM.
Azure Cloud Shell
Na platforma Azure hostowane jest Azure Cloud Shell, interaktywne środowisko powłoki, z którego można korzystać w przeglądarce. Do pracy z usługami platformy Azure można używać programu Bash lub PowerShell w środowisku Cloud Shell. Aby uruchomić kod w tym artykule, możesz użyć wstępnie zainstalowanych poleceń usługi Cloud Shell bez konieczności instalowania niczego w środowisku lokalnym.
Aby uruchomić środowisko Azure Cloud Shell:
Opcja | Przykład/link |
---|---|
Wybierz pozycję Wypróbuj w prawym górnym rogu bloku kodu lub polecenia. Wybranie pozycji Wypróbuj nie powoduje automatycznego skopiowania kodu lub polecenia do usługi Cloud Shell. | |
Przejdź do witryny https://shell.azure.com lub wybierz przycisk Uruchom Cloud Shell, aby otworzyć środowisko Cloud Shell w przeglądarce. | |
Wybierz przycisk Cloud Shell na pasku menu w prawym górnym rogu witryny Azure Portal. |
Aby użyć usługi Azure Cloud Shell:
Uruchom usługę Cloud Shell.
Wybierz przycisk Kopiuj w bloku kodu (lub bloku poleceń), aby skopiować kod lub polecenie.
Wklej kod lub polecenie do sesji usługi Cloud Shell, wybierając Ctrl+Shift V w systemach Windows i Linux lub wybierając pozycję Cmd+Shift++V w systemie macOS.
Wybierz Enter, aby uruchomić kod lub polecenie.
Logowanie się do platformy Azure
Aby zalogować się do platformy Azure przy użyciu interfejsu wiersza polecenia, możesz wpisać:
az login
Aby uzyskać więcej informacji na temat opcji logowania za pośrednictwem interfejsu wiersza polecenia, zobacz Logowanie się za pomocą interfejsu wiersza polecenia platformy Azure
Przykład
W tym przykładzie opracowujemy aplikację, która używa klucza RSA 2048-bitowego do operacji podpisywania. Nasza aplikacja działa na maszynie wirtualnej platformy Azure z tożsamością zarządzaną. Zarówno klucz RSA używany do podpisywania jest przechowywany w zarządzanym module HSM.
Zidentyfikowaliśmy następujące role, które zarządzają, wdrażają i przeprowadzają inspekcję aplikacji:
- Zespół ds. zabezpieczeń: pracownicy DZIAŁU IT z biura CSO (dyrektor ds. zabezpieczeń) lub podobni współautorzy. Zespół ds. zabezpieczeń jest odpowiedzialny za odpowiednie bezpieczne przechowywanie kluczy. Klucze RSA lub EC do podpisywania oraz klucze RSA lub AES na potrzeby szyfrowania danych.
- Deweloperzy i operatorzy: pracownicy, którzy opracowują aplikację i wdrażają ją na platformie Azure. Członkowie tego zespołu nie są częścią personelu ochrony. Nie powinni mieć dostępu do poufnych danych, takich jak klucze RSA. Tylko wdrażana aplikacja powinna mieć dostęp do tych poufnych danych.
- Audytorzy: Ta rola jest dla współautorów, którzy nie są członkami działu rozwoju ani personelu ogólnego IT. Przeglądają użycie i konserwację certyfikatów, kluczy i wpisów tajnych, aby zapewnić zgodność ze standardami zabezpieczeń.
Istnieje inna rola, która znajduje się poza zakresem naszej aplikacji: administrator subskrypcji (lub grupy zasobów). Administrator subskrypcji konfiguruje początkowe uprawnienia dostępu dla zespołu ds. zabezpieczeń. Zapewniają one dostęp do zespołu ds. zabezpieczeń przy użyciu grupy zasobów, która ma zasoby wymagane przez aplikację.
Musimy autoryzować następujące operacje dla naszych ról:
Zespół ds. zabezpieczeń
- Utwórz zarządzany moduł HSM.
- Pobieranie domeny zabezpieczeń zarządzanego modułu HSM (na potrzeby odzyskiwania po awarii)
- Włącz rejestrowanie.
- Generowanie lub importowanie kluczy
- Utwórz zarządzane kopie zapasowe modułu HSM na potrzeby odzyskiwania po awarii.
- Ustaw lokalną kontrolę dostępu opartą na rolach zarządzanego modułu HSM, aby przyznać użytkownikom i aplikacjom uprawnienia do określonych operacji.
- Okresowo przerzucaj klucze.
Deweloperzy i operatorzy
- Uzyskaj odwołanie (identyfikator URI klucza) od zespołu ds. zabezpieczeń klucza RSA używanego do podpisywania.
- Programowe opracowywanie i wdrażanie aplikacji, która uzyskuje dostęp do klucza programowo.
Audytorzy
- Przejrzyj daty wygaśnięcia kluczy, aby upewnić się, że klucze są aktualne
- Monitorowanie przypisań ról w celu zapewnienia, że dostęp do kluczy mogą uzyskiwać tylko autoryzowani użytkownicy/aplikacje
- Przejrzyj dzienniki zarządzanego modułu HSM, aby potwierdzić prawidłowe użycie kluczy zgodnie ze standardami zabezpieczeń danych.
Poniższa tabela zawiera podsumowanie przypisań ról do zespołów i zasobów w celu uzyskania dostępu do zarządzanego modułu HSM.
Rola | Rola płaszczyzny zarządzania | Rola płaszczyzny danych |
---|---|---|
Zespół ds. zabezpieczeń | Współautor zarządzanego modułu HSM | Administrator zarządzanego modułu HSM |
Deweloperzy i operatorzy | Brak | Brak |
Audytorzy | Brak | Zarządzany audytor kryptograficzny modułu HSM |
Zarządzana identyfikacja maszyny wirtualnej używanej przez aplikację | Brak | Zarządzany użytkownik kryptograficzny modułu HSM |
Tożsamość zarządzana konta magazynu używanego przez aplikację | Brak | Szyfrowanie zarządzanego modułu HSM |
Trzy role zespołu muszą mieć dostęp do innych zasobów wraz z uprawnieniami zarządzanego modułu HSM. Aby wdrożyć maszyny wirtualne (lub funkcję Web Apps usługi aplikacja systemu Azure), deweloperzy i operatorzy muszą mieć Contributor
dostęp do tych typów zasobów. Audytorzy potrzebują dostępu do odczytu do konta magazynu, na którym są przechowywane zarządzane dzienniki modułu HSM.
Aby przypisać role płaszczyzny zarządzania (RBAC) platformy Azure, możesz użyć witryny Azure Portal lub dowolnego z innych interfejsów zarządzania, takich jak interfejs wiersza polecenia platformy Azure lub program Azure PowerShell. Aby przypisać role zarządzanej płaszczyzny danych modułu HSM, musisz użyć interfejsu wiersza polecenia platformy Azure. Aby uzyskać więcej informacji na temat ról płaszczyzny zarządzania, zobacz Role wbudowane platformy Azure. Aby uzyskać więcej informacji na temat ról płaszczyzny danych zarządzanego modułu HSM, zobacz Role wbudowane RBAC lokalne dla zarządzanego modułu HSM.
Fragmenty kodu interfejsu wiersza polecenia platformy Azure w tej sekcji są tworzone przy użyciu następujących założeń:
- Administrator firmy Microsoft Entra utworzył grupy zabezpieczeń do reprezentowania trzech ról: Zespół ds. zabezpieczeń Firmy Contoso, DevOps aplikacji Firmy Contoso i Audytorzy aplikacji Firmy Contoso. Administrator dodał użytkowników do odpowiednich grup.
- Wszystkie zasoby znajdują się w grupie zasobów ContosoAppRG .
- Dzienniki zarządzanego modułu HSM są przechowywane na koncie magazynu contosologstorage .
- Zarządzany moduł HSM firmy ContosoM i konto magazynu contosologstorage znajdują się w tej samej lokalizacji platformy Azure.
Administrator subskrypcji przypisuje Managed HSM Contributor
rolę zespołowi ds. zabezpieczeń. Ta rola umożliwia zespołowi ds. zabezpieczeń zarządzanie istniejącymi zarządzanymi modułami HSM i tworzenie nowych. Jeśli istnieją zarządzane moduły HSM, muszą mieć przypisaną rolę "Administrator zarządzanego modułu HSM", aby móc nimi zarządzać.
# This role assignment allows Contoso Security Team to create new Managed HSMs
az role assignment create --assignee-object-id $(az ad group show -g 'Contoso Security Team' --query 'id' -o tsv) --assignee-principal-type Group --role "Managed HSM Contributor"
# This role assignment allows Contoso Security Team to become administrator of existing managed HSM
az keyvault role assignment create --hsm-name ContosoMHSM --assignee $(az ad group show -g 'Contoso Security Team' --query 'id' -o tsv) --scope / --role "Managed HSM Administrator"
Zespół ds. zabezpieczeń konfiguruje rejestrowanie i przypisuje role audytorom i aplikacji maszyny wirtualnej.
# Enable logging
hsmresource=$(az keyvault show --hsm-name ContosoMHSM --query id -o tsv)
storageresource=$(az storage account show --name contosologstorage --query id -o tsv)
az monitor diagnostic-settings create --name MHSM-Diagnostics --resource $hsmresource --logs '[{"category": "AuditEvent","enabled": true}]' --storage-account $storageresource
# Assign the "Crypto Auditor" role to Contoso App Auditors group. It only allows them to read.
az keyvault role assignment create --hsm-name ContosoMHSM --assignee $(az ad group show -g 'Contoso App Auditors' --query 'objectId' -o tsv) --scope / --role "Managed HSM Crypto Auditor"
# Grant the "Crypto User" role to the VM's managed identity. It allows to create and use keys.
# However it cannot permanently delete (purge) keys
az keyvault role assignment create --hsm-name ContosoMHSM --assignee $(az vm identity show --name "vmname" --resource-group "ContosoAppRG" --query objectId -o tsv) --scope / --role "Managed HSM Crypto Auditor"
# Assign "Managed HSM Crypto Service Encryption User" role to the Storage account ID
storage_account_principal=$(az storage account show --id $storageresource --query identity.principalId -o tsv)
# (if no identity exists), then assign a new one
[ "$storage_account_principal" ] || storage_account_principal=$(az storage account update --assign-identity --id $storageresource)
az keyvault role assignment create --hsm-name ContosoMHSM --role "Managed HSM Crypto Service Encryption User" --assignee $storage_account_principal
W tym samouczku są wyświetlane tylko akcje istotne dla kontroli dostępu w większości przypadków. Inne akcje i operacje związane z wdrażaniem aplikacji na maszynie wirtualnej, włączanie szyfrowania przy użyciu klucza zarządzanego przez klienta dla konta magazynu, tworzenie zarządzanego modułu HSM nie jest tutaj wyświetlane, aby zachować przykład skoncentrowany na kontroli dostępu i zarządzaniu rolami.
W naszym przykładzie opisano prosty scenariusz. Scenariusze rzeczywiste mogą być bardziej złożone. Możesz dostosować uprawnienia do magazynu kluczy w zależności od potrzeb. Zakładaliśmy, że zespół ds. zabezpieczeń udostępnia kluczowe i tajne odwołania (URI i odciski palca), które są używane przez pracowników devOps w swoich aplikacjach. Deweloperzy i operatorzy nie wymagają dostępu do płaszczyzny danych. Skupiliśmy się na sposobie zabezpieczania magazynu kluczy. Podczas zabezpieczania maszyn wirtualnych, kont magazynu i innych zasobów platformy Azure należy wziąć pod uwagę podobne zagadnienia.
Zasoby
- Dokumentacja kontroli dostępu opartej na rolach platformy Azure
- Kontrola dostępu oparta na rolach platformy Azure: role wbudowane
- Zarządzanie kontrolą dostępu opartą na rolach platformy Azure przy użyciu interfejsu wiersza polecenia platformy Azure
Następne kroki
Aby zapoznać się z samouczkiem wprowadzającym dla administratora, zobacz Co to jest zarządzany moduł HSM?.
Aby uzyskać więcej informacji na temat rejestrowania użycia na potrzeby rejestrowania zarządzanego modułu HSM, zobacz Rejestrowanie zarządzanego modułu HSM.