Udostępnij przez

Kontrola dostępu dla zarządzanego modułu 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 twojej firmy, należy zabezpieczyć zarządzane moduły zabezpieczeń sprzętu (HSM), zezwalając tylko autoryzowanym aplikacjom i użytkownikom na dostęp do danych.

Ten artykuł zawiera omówienie modelu kontroli dostępu zarządzanego HSM. Wyjaśniono w nim uwierzytelnianie i autoryzację oraz opisano sposób zabezpieczania dostępu do zarządzanych modułów HSM. Aby uzyskać praktyczne wskazówki dotyczące implementacji, zobacz Bezpieczny dostęp do zarządzanych modułów HSM.

Uwaga

Dostawca zasobów usługi Azure Key Vault obsługuje dwa typy zasobów: skarbce i zarządzane moduły HSM. Kontrola dostępu opisana w tym artykule dotyczy tylko zarządzanych modułów HSM. Aby dowiedzieć się więcej na temat kontroli dostępu dla skarbców usługi Key Vault, zobacz Zapewnianie dostępu do kluczy, certyfikatów i sekretów usługi Key Vault przy użyciu kontroli dostępu opartej na rolach platformy Azure.

Model kontroli dostępu

Dostęp do zarządzanego modułu HSM jest kontrolowany za pomocą dwóch interfejsów:

  • Płaszczyzna sterowania
  • Płaszczyzna danych

Na płaszczyźnie sterowania zarządzasz samym modułem HSM. Operacje na tej płaszczyźnie obejmują tworzenie i usuwanie zarządzanych modułów HSM oraz pobieranie zarządzanych właściwości modułu HSM.

Na płaszczyźnie danych pracujesz z danymi przechowywanymi w zarządzanym module HSM. Oznacza to, że pracujesz z kluczami szyfrowania opartymi na module HSM. Możesz dodawać, usuwać, modyfikować i używać kluczy do wykonywania operacji kryptograficznych, zarządzania przypisaniami ról w celu kontrolowania dostępu do kluczy, tworzenia pełnej kopii zapasowej modułu HSM, przywracania pełnej kopii zapasowej i zarządzania domeną zabezpieczeń z interfejsu płaszczyzny danych.

Aby uzyskać dostęp do zarządzanego modułu HSM w obu płaszczyznach, wszyscy wywołujący muszą mieć odpowiednie uwierzytelnianie i autoryzację. Uwierzytelnianie ustanawia tożsamość obiektu wywołującego. Autoryzacja określa, które operacje może wykonywać obiekt wywołujący. Obiekt wywołujący może być jednym z podmiotów zabezpieczeń zdefiniowanych w identyfikatorze Entra firmy Microsoft: użytkownik, grupa, jednostka usługi lub tożsamość zarządzana.

Obie płaszczyzny używają identyfikatora Entra firmy Microsoft do uwierzytelniania. W przypadku autoryzacji używają różnych systemów:

  • Płaszczyzna sterowania korzysta z kontroli dostępu opartej na rolach (RBAC) platformy Azure, czyli systemu autoryzacji opartego na usłudze Azure Resource Manager.
  • Płaszczyzna danych korzysta z zarządzanego systemu autoryzacji RBAC na poziomie HSM, który jest zaimplementowany i egzekwowany na poziomie zarządzanego modułu HSM.

Po utworzeniu zarządzanego modułu HSM wnioskodawca udostępnia listę administratorów warstwy danych (obsługiwane są wszystkie podmioty zabezpieczeń). Tylko ci administratorzy mogą uzyskiwać dostęp do zarządzanej płaszczyzny danych HSM w celu wykonywania kluczowych operacji i zarządzania przypisaniami ról płaszczyzny danych (zarządzana kontrola dostępu oparta na rolach w module HSM).

Modele uprawnień dla obu płaszczyzn używają tej samej składni, ale są stosowane na różnych poziomach, a przypisania ról dotyczą różnych zakresów. Kontrola płaszczyzny zarządzania RBAC w Azure jest wymuszana przez Azure Resource Manager, a lokalna kontrola płaszczyzny danych RBAC w zarządzanym module HSM jest wymuszana przez sam ten moduł.

Ważne

Udzielenie podmiotowi zabezpieczeń dostępu do płaszczyzny kontroli nie oznacza udzielenia mu dostępu do płaszczyzny danych. Na przykład główna jednostka zabezpieczeń z dostępem do warstwy sterowania nie ma automatycznie dostępu do kluczy ani przypisań ról w warstwie danych. Ta izolacja jest zgodnie z projektem, aby zapobiec nieumyślnemu rozszerzaniu uprawnień, które mają wpływ na dostęp do kluczy przechowywanych w zarządzanym module HSM.

Istnieje jednak wyjątek: Członkowie roli administratora globalnego firmy Microsoft Entra mogą zawsze dodawać użytkowników do roli Administratora zarządzanego modułu HSM na potrzeby odzyskiwania, na przykład wtedy, gdy nie ma już żadnych prawidłowych kont administratora zarządzanego modułu HSM. Aby uzyskać więcej informacji, zobacz Microsoft Entra ID best practices for securing the Global Administrator role (Najlepsze rozwiązania dotyczące zabezpieczania roli administratora globalnego).

Na przykład administrator subskrypcji (ponieważ ma uprawnienia Współautor do wszystkich zasobów w subskrypcji) może usunąć zarządzany moduł HSM w ramach subskrypcji. Jeśli jednak nie mają dostępu do płaszczyzny danych przyznanej za pośrednictwem lokalnej kontroli dostępu opartej na rolach zarządzanego modułu HSM, nie mogą uzyskać dostępu do kluczy ani zarządzać przypisaniami ról w zarządzanym module HSM w celu udzielenia sobie lub innym osobom dostępu do płaszczyzny danych.

Uwierzytelnianie usługi Microsoft Entra

Po utworzeniu zarządzanego HSM w subskrypcji platformy Azure, zarządzany HSM jest automatycznie skojarzony z dzierżawą Microsoft Entra w ramach subskrypcji. Wszyscy użytkownicy na obu płaszczyznach muszą być zarejestrowani w ramach tego dzierżawcy i uwierzytelnić się, aby uzyskać dostęp do zarządzanego modułu HSM.

Aplikacja uwierzytelnia się przy użyciu Microsoft Entra ID przed wywołaniem jednej z płaszczyzn. Aplikacja może używać dowolnej obsługiwanej metody uwierzytelniania w zależności od typu aplikacji. Aplikacja uzyskuje token dla zasobu w płaszczyźnie w celu uzyskania dostępu. Zasób jest punktem końcowym na płaszczyźnie sterowania lub płaszczyźnie danych w zależności od środowiska platformy Azure. Aplikacja używa tokenu i wysyła żądanie interfejsu API REST do zarządzanego punktu końcowego modułu HSM. Aby dowiedzieć się więcej, przejrzyj cały przepływ uwierzytelniania.

Korzystanie z jednego mechanizmu uwierzytelniania dla obu płaszczyzn ma kilka korzyści:

  • Organizacje mogą centralnie kontrolować dostęp do wszystkich zarządzanych modułów HSM w swojej organizacji.
  • Jeśli użytkownik opuści organizację, natychmiast utraci dostęp do wszystkich zarządzanych modułów HSM w organizacji.
  • Organizacje mogą dostosowywać uwierzytelnianie przy użyciu opcji w identyfikatorze Entra firmy Microsoft, takich jak włączenie uwierzytelniania wieloskładnikowego na potrzeby dodatkowych zabezpieczeń.

Punkty końcowe zasobów

Podmioty zabezpieczeń uzyskują dostęp do warstw za pośrednictwem punktów końcowych. Mechanizmy kontroli dostępu dla obu płaszczyzn działają niezależnie. Aby udzielić aplikacji dostępu do używania kluczy w zarządzanym HSM, należy przyznać dostęp do płaszczyzny danych za pomocą lokalnego RBAC w zarządzanym HSM. Aby udzielić użytkownikowi dostępu do zasobu Managed HSM do tworzenia, odczytywania, usuwania, przenoszenia tych zasobów oraz edytowania innych właściwości i tagów, należy użyć kontroli dostępu opartej na rolach platformy Azure.

W poniższej tabeli przedstawiono punkty końcowe płaszczyzny sterowania i płaszczyzny danych.

Płaszczyzna dostępu Punkty końcowe dostępu Operacji Mechanizm kontroli dostępu
Płaszczyzna sterowania Cały świat:
management.azure.com:443
 Tworzenie, odczytywanie, aktualizowanie, usuwanie i przenoszenie zarządzanych modułów HSM

Ustawianie zarządzanych tagów modułu HSM		 Kontrola dostępu oparta na rolach w Azure (Azure RBAC)
Płaszczyzna danych Cały świat:
<hsm-name>.managedhsm.azure.net:443
 Klucze: Odszyfrowywanie, szyfrowanie,
rozpakuj, zapakuj, zweryfikuj, podpisz, pobierz, wyświetl, zaktualizuj, utwórz, zaimportuj, usuń, wykonaj kopię zapasową, przywróć, oczyść

Zarządzanie rolą w płaszczyźnie danych (zarządzana lokalna kontrola dostępu oparta na rolach w HSM): Lista definicji ról, przypisywanie ról, usuwanie przypisań ról, definiowanie ról niestandardowych

Tworzenie kopii zapasowej i przywracanie: tworzenie kopii zapasowej, przywracanie, sprawdzanie stanu operacji tworzenia kopii zapasowych i przywracania

Domena zabezpieczeń: pobieranie i przekazywanie domeny zabezpieczeń		 Zarządzany HSM z lokalną kontrolą dostępu opartą na rolach

Płaszczyzna kontrolna i kontrola dostępu oparta na rolach (RBAC) platformy Azure

Na warstwie kontrolnej używasz Azure RBAC, aby autoryzować operacje, które może wykonać osoba wywołująca. W modelu RBAC platformy Azure każda subskrypcja Azure ma instancję Microsoft Entra ID. Udzielasz dostępu użytkownikom, grupom i aplikacjom z tego katalogu. Dostęp jest udzielany do zarządzania zasobami subskrypcji korzystającymi z modelu wdrażania usługi Azure Resource Manager. Aby udzielić dostępu, użyj witryny Azure Portal, interfejsu wiersza polecenia platformy Azure, programu Azure PowerShell lub interfejsów API REST usługi Azure Resource Manager.

Magazyn kluczy można utworzyć w grupie zasobów i zarządzać dostępem przy użyciu identyfikatora Entra firmy Microsoft. Możesz przyznać użytkownikom lub grupom uprawnienia do zarządzania magazynami kluczy w grupie zasobów. Dostęp można udzielić na określonym poziomie zakresu, przypisując odpowiednie role platformy Azure. Aby udzielić użytkownikowi dostępu do zarządzanie magazynami kluczy, należy przypisać użytkownikowi wstępnie zdefiniowaną key vault Contributor rolę w określonym zakresie. Do roli platformy Azure można przypisać następujące poziomy zakresu:

  • Grupa zarządzania: rola platformy Azure przypisana na poziomie subskrypcji ma zastosowanie do wszystkich subskrypcji w tej grupie zarządzania.
  • Subskrypcja: rola platformy Azure przypisana na poziomie subskrypcji ma zastosowanie do wszystkich grup zasobów i zasobów w ramach tej subskrypcji.
  • Grupa zasobów: rola platformy Azure przypisana na poziomie grupy zasobów ma zastosowanie do wszystkich zasobów w tej grupie zasobów.
  • Określony zasób: rola platformy Azure przypisana dla określonego zasobu ma zastosowanie do tego zasobu. W tym przypadku zasób to konkretny magazyn kluczy.

Kilka ról jest wstępnie zdefiniowanych. Jeśli wstępnie zdefiniowana rola nie odpowiada Twoim potrzebom, możesz zdefiniować własną rolę. Aby uzyskać więcej informacji, zobacz Azure RBAC: role wbudowane.

Płaszczyzna danych i lokalna kontrola dostępu oparta na rolach dla zarządzanego modułu HSM

Przyznasz jednostce zabezpieczeń dostęp do wykonywania określonych operacji kluczy przez przypisanie roli. Dla każdego przypisania roli należy określić rolę i zakres, dla którego ma zastosowanie to przypisanie. W przypadku lokalnego RBAC zarządzanego modułu HSM dostępne są dwa zakresy:

  • / lub /keys: zakres na poziomie modułu HSM. Podmioty zabezpieczeń, którym przypisano rolę w tym zakresie, mogą wykonywać operacje zdefiniowane w roli dla wszystkich obiektów (kluczy) w zarządzanym module HSM.
  • /keys/<key-name>: zakres na poziomie klucza. Podmioty zabezpieczeń, którym przypisano rolę w tym zakresie, mogą wykonywać operacje zdefiniowane w tej roli tylko dla wszystkich wersji określonego klucza.

Zarządzana kontrola dostępu oparta na rolach modułu HSM ma kilka wbudowanych ról do obsługi różnych scenariuszy kontroli dostępu. Aby uzyskać pełną listę ról i ich uprawnień, zobacz Managed HSM local RBAC built-in roles for Managed HSM (Zarządzanie lokalnymi rolami RBAC dla zarządzanego modułu HSM).

Microsoft Entra Privileged Identity Management (PIM)

Aby zwiększyć bezpieczeństwo ról administracyjnych, użyj usługi Microsoft Entra Privileged Identity Management (PIM). Usługa PIM umożliwia dostęp na żądanie, co zmniejsza ryzyko przyznania stałych uprawnień administracyjnych. Zapewnia również wgląd w przydzielanie ról i wymusza przepływy pracy zatwierdzania dla podwyższonego poziomu dostępu.

Rozdzielenie obowiązków i kontroli dostępu

Najlepszym rozwiązaniem w zakresie zabezpieczeń jest oddzielenie obowiązków między rolami zespołu i udzielanie tylko minimalnego wymaganego dostępu do określonych funkcji zadań. Ta zasada pomaga zapobiegać nieautoryzowanemu dostępowi i ogranicza potencjalny wpływ przypadkowych lub złośliwych akcji.

Podczas implementowania kontroli dostępu dla zarządzanego modułu HSM rozważ ustanowienie tych typowych ról funkcjonalnych:

  • Zespół ds. zabezpieczeń: potrzebuje uprawnień do zarządzania modułem HSM, kontrolowania cykli życia kluczy i konfigurowania ustawień kontroli dostępu.
  • Deweloperzy aplikacji: wymagają odwołań do kluczy kryptograficznych bez konieczności bezpośredniego dostępu do modułów HSM.
  • Usługa/kod: wymaga uprawnień do wykonywania określonych operacji szyfrowania, a jednocześnie jest ograniczony do szerszych funkcji zarządzania kluczami.
  • Audytorzy: Wymaga możliwości monitorowania i rejestrowania dostępu bez uprawnień do modyfikowania ustawień modułu HSM lub kluczy.

Te role koncepcyjne powinny mieć przyznane tylko określone uprawnienia potrzebne do wykonywania swoich obowiązków. Implementacja rozdzielenia obowiązków wymaga przypisań ról płaszczyzny sterowania (Azure RBAC) i płaszczyzny danych (zarządzany lokalny RBAC w HSM).

Aby uzyskać szczegółowy samouczek dotyczący implementowania rozdzielania obowiązków przy użyciu określonych przykładów i poleceń interfejsu wiersza polecenia platformy Azure, zobacz Bezpieczny dostęp do zarządzanych modułów HSM.

Następne kroki

  • Last updated on