Udostępnij przez

Kontrole zarządzania kluczami

W tym artykule opisano kluczowe mechanizmy kontroli zarządzania scenariuszami suwerennej chmury, koncentrując się na zagadnieniach dotyczących zabezpieczeń i kompromisach między różnymi podejściami do zarządzania kluczami i niezależnością. Zawiera ona wskazówki dla organizacji oceniające miejsce przechowywania kluczy kryptograficznych i zarządzania nimi na podstawie niezależności, zgodności i wymagań operacyjnych.

Aby uzyskać kompleksowe informacje na temat kluczowych rozwiązań do zarządzania platformy Azure, w tym szczegółowych porównań produktów i wskazówek dotyczących wyboru, zobacz:

Zarządzany moduł HSM usługi Azure Key Vault na potrzeby niezależności kluczy

Klucze kryptograficzne są niezbędne do ochrony poufnych danych i zapewnienia integralności i autentyczności transakcji cyfrowych. Organizacje oceniające kluczowe podejścia do zarządzania scenariuszami suwerennej chmury muszą zrozumieć dostępne opcje i ich kompromisy.

Usługa Azure Key Vault Managed HSM zapewnia suwerenność kluczy dzięki zabezpieczeniom zweryfikowanym zgodnie z normą FIPS 140-3 poziom 3, oferując pełną kontrolę nad kluczami, izolację pojedynczego dzierżawcy i domeny zabezpieczeń kontrolowane przez ciebie — przy zachowaniu umów dotyczących poziomu usług platformy Azure i eliminacji kosztów operacyjnych związanych z zarządzaniem fizycznymi modułami HSM. Aby uzyskać więcej informacji, zobacz Moduł HSM zarządzany w usłudze Azure Key Vault.

Platforma Azure nadal rozszerza swój portfel zarządzania kluczami, aby sprostać zróżnicowanym wymaganiom w zakresie niezależności. W tym artykule omówiono również zarządzanie kluczami zewnętrznymi jako podejście koncepcyjne, w którym klucze są hostowane w modułach HSM należących do klienta fizycznie oddzielonych od infrastruktury chmury, w celu zapewnienia kontekstu oceny różnych modeli suwerenności.

Architektura ochrony kluczy

Podczas oceniania kluczowych rozwiązań do zarządzania ważne jest zrozumienie wektorów ataków, które mogłyby naruszyć bezpieczeństwo klucza:

Wyodrębnianie materiału klucza prywatnego: materiał klucza prywatnego jest chroniony przez wiele mechanizmów zapewnianych przez fizyczny moduł HSM. Wyodrębnianie kluczy może prowadzić do ataków w trybie offline, w których osoba atakująca potrzebuje kopii zaszyfrowanych danych i kluczy prywatnych z modułu HSM. Domyślnie moduł HSM chroni materiał klucza prywatnego lub klucze prywatne zarówno wewnątrz, jak i poza modułem HSM. W celu ochrony moduły HSM korzystają ze środowisk zabezpieczeń lub partycji w celu zabezpieczenia materiału klucza wewnątrz modułu HSM i poza nim. Funkcja opakowania i odpakowywania (szyfrowanie lub odszyfrowywanie klucza szyfrowania danych) klucza powinna być uruchamiana tylko wewnątrz zaufanego środowiska modułu HSM. Ponadto dostępne są również chronione kopie zapasowe i chroniony magazyn kluczy zewnętrznych. Moduł HSM zajmuje się ochroną, owijając cały materiał i pozostawiając klucz maskujący, który jest znany tylko partycji, z której klucz został uwolniony. Zwykle tylko kombinacja klucza maskowania i kopii zapasowej klucza (HSM) może uwidocznić klucz prywatny. Jednak w niektórych przypadkach klucze mogą być oznaczone jako możliwe do wyeksportowania, umożliwiając pozostawienie modułu HSM w stanie niechronionym.

Nieautoryzowane użycie usługi: chociaż moduł HSM chroni klucze, osoby atakujące mogą nadużywać usługi bez konieczności wycieku kluczy. Nieautoryzowani użytkownicy, którzy mogą korzystać z funkcji opakowywania/rozpakowywania interfejsu API zarządzania kluczami (obsługującego HSM), mogą ujawnić klucz szyfrowania danych (DEK), wysyłając zaszyfrowany klucz DEK do usługi, co może naruszyć bezpieczeństwo danych chronionych przez ten klucz. Chociaż moduł HSM chroni materiał klucza prywatnego, interfejs API przed modułem HSM, który wchodzi w interakcję między usługą wywołującą a modułem HSM, również musi być chroniony.

Zabezpieczanie kluczy wymaga zarówno ochrony granicy modułu HSM, jak i otaczających usług i architektur, które współdziałają z modułem HSM.

Zarządzany moduł HSM usługi Azure Key Vault

Azure Key Vault Managed HSM to w pełni zarządzana, oparta na chmurze usługa HSM zapewniająca bezpieczeństwo zgodne z normą FIPS 140-3 poziom 3, izolację pojedynczego dzierżawcy i pełną kontrolę nad kluczami kryptograficznymi. Ta usługa zapewnia kluczową niezależność przy zachowaniu prostoty operacyjnej. Aby uzyskać szczegółowe informacje na temat usługi, jej możliwości i architektury, zobacz Co to jest zarządzany moduł HSM usługi Azure Key Vault?

Usługa spełnia kluczowe wymagania dotyczące zabezpieczeń za pośrednictwem architektury poufnego przetwarzania:

Architektura zarządzanego modułu HSM

Najważniejsze informacje o architekturze zabezpieczeń

Zarządzany moduł HSM usługi Azure Key Vault korzysta z poufnego przetwarzania na platformie Azure w celu utworzenia środowiska zgodnego lub przekraczającego zabezpieczenia zewnętrznego modułu HSM. Aby uzyskać szczegółowe informacje techniczne, zobacz Szczegóły techniczne zarządzanego HSM.

  • Dla każdej instancji używanej przez ciebie tworzone jest zaufane środowisko wykonawcze (TEE).
  • TeE opiera się na zewnętrznym zaufaniu i kluczach spoza kontroli firmy Microsoft (Intel Software Guard Extensions (SGX)).
  • Wszystkie tajne dane używane przez usługę są generowane wewnątrz wystąpienia zabezpieczonego przez TEE.
  • Brak wpisów tajnych w postaci zwykłego tekstu w aktywnej pamięci na hostach fizycznych
  • Żaden człowiek lub system poza zaufanym środowiskiem nie ma poświadczeń modułu HSM
  • Dostęp do usługi jest ograniczony programowo do instancji Microsoft Entra ID klienta.
  • Tylko klienci mogą żądać, pobierać i odszyfrowywać domenę zabezpieczeń (w tym klucz maskowania). Te informacje nie są przechowywane w chmurze.
  • Materiał klucza prywatnego w module HSM jest ustawiony na niemożliwy do przesłaniania, chyba że zażądano bezpiecznego wydania klucza. Zwykłe klucze są nieeksportowalne, dlatego moduł HSM nie ujawnia materiału klucza prywatnego w stanie niemaskowanym.
  • Moduł HSM ma dziennik inspekcji, aby przeglądać interakcje na partycji HSM.

Ocena zabezpieczeń przed atakami

Ponieważ moduł HSM i klucze są hostowane w ramach infrastruktury platformy Azure, ważne jest, aby ocenić ochronę przed dwoma podstawowymi wektorami ataków:

Wyodrębnianie materiału klucza prywatnego:

  • Moduł HSM Marvel Liquid ze standardowym oprogramowaniem układowym służy do zapewnienia ochrony materiału kryptograficznego klucza prywatnego
  • Poświadczenia do samego modułu HSM nie są czytelne dla człowieka i są przechowywane wyłącznie w zaufanych środowiskach wykonywania systemu
  • Klucz maskujący chroniący materiały klucza prywatnego znajduje się wyłącznie w posiadaniu klienta — jest chroniony przez klucze generowane i zarządzane przez ciebie — a za bezpieczeństwo klucza maskującego odpowiada klient. To rozdzielenie gwarantuje, że klucze (kopie zapasowe) i klucz maskowania (ochrona tych kluczy) są przechowywane w dwóch różnych miejscach.
  • Chociaż platforma Microsoft Azure może wykonywać pełne kopie zapasowe fizycznego modułu HSM (w tym wszystkich partycji), ta kopia zapasowa jest chroniona przez każdy klucz maskowania partycji (do którego ma dostęp tylko klient, chroniony przez pary kluczy tworzone przez klienta i zarządza nim)
  • Zamierzone lub niezamierzone ujawnienie domeny zabezpieczeń nie zapewnia dostępu do kluczy. Aby uzyskać dostęp do klucza prywatnego, atakujący musieliby uzyskać dostęp do kopii zapasowej (klucza), domeny bezpieczeństwa oraz kluczy generowanych przez klienta, używanych do ochrony domeny bezpieczeństwa.
  • Zamierzone lub niezamierzone ujawnienie kopii zapasowej nie umożliwi atakującemu uzyskania dostępu do materiałów klucza prywatnego, ponieważ musiałby on również mieć domenę bezpieczeństwa oraz klucze wygenerowane przez klienta, używane do ochrony tej domeny, które nie powinny być przechowywane na platformie Azure.

Nieautoryzowany dostęp lub użycie:

  • Dostęp do usługi jest ograniczony do uwierzytelniających tokenów podpisanych tożsamości Microsoft Entra klienta. Usługa używa dwóch list ACL: RBAC platformy Azure do tworzenia i usuwania wystąpień oraz RBAC modułu HSM dla ról modułu HSM. W przypadku korzystania z jednego identyfikatora Entra ID właściciel subskrypcji platformy Azure nie może przejąć wymuszonej kontroli nad zarządzanym modułem HSM, jeśli nie masz dostępu do tego modułu.
  • Rola awaryjnego administratora HSM istnieje dla grupy "Globalni administratorzy Entra ID". Niezależnie od uprawnień w subskrypcjach platformy Azure dostęp do instancji zarządzanej HSM umożliwia globalnemu administratorowi Entra ID przejęcie kontroli nad modułem HSM. Nie zapewnia im dostępu do materiałów kluczy prywatnych, ale umożliwia zmianę listy ACL modułu HSM. Wymagana jest ostrożność w zakresie członkostwa administratorów globalnych.
  • Poświadczeń (każdej grupy) partycji HSM nie ujawnia się, dzięki czemu nieautoryzowane systemy lub osoby nie mogą ich niewłaściwie używać.
  • Certyfikaty TLS (https) są generowane przez i wewnątrz zaufanego środowiska wykonawczego, dzięki czemu klucz prywatny połączeń TLS usługi jest dostępny wyłącznie dla wystąpienia.
  • Usługa front-end działa w pełni w poufnych obliczeniach, a dostęp zewnętrzny dla innych systemów lub ludzi jest niemożliwy. Nie można przenieść wystąpienia do hosta, którego bezpieczeństwo zostało naruszone, ponieważ parametry TEE mogą ulec zmianie. Ponadto dostęp do "magazynu kluczy tajnych", który przechowuje poświadczenia i klucze prywatne usługi, jest możliwy tylko na oryginalnym fizycznym procesorze ze względu na użycie klucza uszczelnienia w TEE.

Dodatkowe funkcje zabezpieczeń:

  • Usługa posiada wbudowane mechanizmy nadmiarowości. Każda utworzona usługa zarządzanego modułu HSM tworzy 3 (indywidualne) instancje zaplecza. Wymiana kluczy między wystąpieniami jest zabezpieczona przez klucz szyfrowania bazy danych (współużytkowany między wszystkimi wystąpieniami) a kluczem maskowania partycji HSM, zapewniając, że materiał klucza prywatnego może być wymieniany tylko między wystąpieniami w tej samej usłudze i że materiały kluczy prywatnych są dostępne tylko w przypadku importowania do partycji HSM należących do tego samego wystąpienia usługi.
  • Procedury zarządzania i operacyjne modułów HSM są ograniczone do kontrolerów usługi Azure Fabric. W związku z tym nie można przeprowadzić operacji poza zakresem, które nie są zintegrowane z usługą. Bezpośredni dostęp do partycji (a zatem do kluczowych operacji lub operacji obejmujących całą partycję) jest ograniczony do poszczególnych instancji w ramach odpowiednich modułów TEE. Żaden człowiek ani żadna osoba spoza sieci nie ma dostępu do partycji, ponieważ dane uwierzytelniające do partycji są znane tylko każdej instancji.

Aby uzyskać szczegółowe informacje na temat architektury zarządzanego modułu HSM, funkcji zabezpieczeń i najlepszych rozwiązań, zobacz:

Architektura zarządzania kluczami zewnętrznymi

Zarządzanie kluczami zewnętrznymi to podejście koncepcyjne, w którym organizacje używają własnych sprzętowych modułów zabezpieczeń (HSM) do operacji kryptograficznych podczas korzystania z usług w chmurze, fizycznie oddzielając klucze od infrastruktury danych i chmury.

Ta sekcja zawiera kontekst edukacyjny na potrzeby zrozumienia architektur zarządzania kluczami zewnętrznymi, ich zagadnień dotyczących zabezpieczeń i kompromisów operacyjnych. Ten wzorzec architektury można porównać z usługami HSM zarządzanymi przez chmurę, takimi jak zarządzany moduł HSM usługi Azure Key Vault podczas oceniania wymagań dotyczących niezależności. Aby uzyskać informacje o możliwościach zarządzania kluczami platformy Azure, zobacz:

Architektury przechowania kluczy zewnętrznych

Składniki architektury

Architektura magazynu kluczy zewnętrznych zwykle obejmuje cztery składniki:

  • Usługa w chmurze: Ta usługa wywołuje usługę zarządzania kluczami, aby zapewnić niezaszyfrowany klucz szyfrujący danych (DEK) wymagany do przetwarzania/odblokowywania danych. Usługa w chmurze zazwyczaj używa zarządzanej tożsamości, aby umożliwić dostęp do docelowego klucza szyfrującego.
  • Oparta na chmurze usługa zarządzania kluczami: ten składnik jest zwykle wymagany, ponieważ większość usług w chmurze jest ściśle zintegrowana z usługą zarządzania kluczami dostawcy. Usługa zarządzania kluczami może obsługiwać klucze hostowane w chmurze lub posiadać klucze referencyjne, które wskazują na klucz zewnętrzny.
  • Proxy zarządzania kluczami: Ponieważ organizacje mogą wybierać własne moduły HSM (dostawca/typ), konieczne jest dokonanie translacji między usługą zarządzania kluczami a rzeczywistym wywołaniem modułu HSM. Serwer proxy ma (zewnętrzny) adres URL, do którego usługa zarządzania kluczami przekazuje wywołania zawijania/odpakowywania, a serwer proxy musi przekonwertować te na określone wywołania interfejsu API HSM dostawcy. W wielu przypadkach serwer proxy wykonuje również konwersję i walidację tożsamości, ponieważ dostawca tożsamości HSM może się różnić od tożsamości zarządzanej w usłudze chmurowej.
  • Moduł HSM: różne moduły HSM mogą być używane w zapleczu, ale ponieważ wymagany jest ciągły dostęp, wybrany moduł HSM musi być zawsze w trybie online, a dostęp musi być udzielany na podstawie zasad usługi lub kont użytkowników (zarządzanych przez serwer proxy). Ze względu na to, że usługi w chmurze wymagają regularnego użycia kluczy, Moduł Bezpieczeństwa Sprzętowego (HSM) zazwyczaj nie jest w stanie używać opartych na kworum kontrolek uwierzytelniania wieloskładnikowego (takich jak karty inteligentne) do procedur zawijania i rozpakowywania.

Zagadnienia operacyjne

W architekturach zewnętrznych magazynów kluczy klienci mają pełną kontrolę nad fizycznym modułem HSM i jego procesami operacyjnymi, w tym nad uwierzytelnianiem wieloskładnikowym (MFA) i wieloetapowymi procesami zatwierdzania operacji administracyjnych, takich jak tworzenie kluczy, tworzenie kopii zapasowych i przywracanie danych.

Organizacje są w pełni odpowiedzialne za hostowanie i zabezpieczanie składników serwera proxy, które odgrywają istotną rolę w komunikacji usług. Oprogramowanie serwera proxy musi poprawnie tłumaczyć wywołania interfejsu API i często wykonywać tłumaczenia tożsamości między usługami w chmurze i użyciem klucza HSM. Chociaż serwery proxy są często udostępniane przez dostawców hsM, specyfikacje oparte na otwartych standardach umożliwiają implementacje niestandardowe.

Ocena zabezpieczeń przed atakami

Organizacje rozważające zewnętrzne magazyny kluczy muszą ocenić ochronę przed tymi samymi wektorami ataków:

Wyodrębnianie materiału klucza prywatnego:

  • Kopia zapasowa modułu HSM (zawierająca wszystkie klucze w stanie zaszyfrowanym) i klucz maskowania (aby odszyfrować kopię zapasową) znajdują się w tej samej lokalizacji, zarządzanej przez tę samą jednostkę i chronionej przez tego samego dostawcę tożsamości (z usługą MFA lub bez uwierzytelniania wieloskładnikowego)
  • Poświadczenia czytelne dla człowieka są wymagane do przejęcia własności modułu HSM w celu wykonywania codziennych zadań, takich jak kopie zapasowe, rotacja kluczy, monitorowanie i akcje partycji głównej modułu HSM.
  • Składnik proxy jest składnikiem zastrzeżonym, open source lub samodzielnie zarządzanym, który ma pełny dostęp do modułu HSM, kluczy i interakcji. Naruszenie zabezpieczeń usługi proxy może prowadzić do naruszenia bezpieczeństwa kluczowych materiałów. W zależności od tego, jak bezpieczny serwer proxy został zaprojektowany/zapisany, serwer proxy może mieć uprawnienia do "użycia wszystkich kluczy" — co sprawia, że jego zakres zagrożenia jest większy.
  • Serwer proxy zarządzania kluczami hostuje zewnętrzny dostępny adres URL chroniony za pomocą certyfikatu TLS. Ważne jest, aby komunikacja między usługą zarządzania kluczami w chmurze i serwerem proxy zarządzania kluczami nie została przerwana ani naruszona podczas zwracania klucza szyfrowania (niezaszyfrowanego).

Nieautoryzowane użycie usługi:

  • Przechowywanie lub obsługa poświadczeń do rzeczywistego użycia modułu HSM (operacje zawijania/odpakowywania) przez serwer proxy stanowi ryzyko kradzieży poświadczeń. Za pomocą tych poświadczeń nieautoryzowany system może wykonywać bezpośrednie wywołania modułu HSM dla operacji zawijania/odpakowywanie bez walidacji.
  • Usługa zarządzania kluczami w chmurze wymaga zaufania jako składnika w architekturze. Usługa przekazuje żądania z usług w chmurze do serwera proxy zarządzania kluczami, używając klucza referencyjnego. Naruszenie tej usługi może zezwalać na nieautoryzowane zastępowanie kluczy lub niewłaściwe instrukcje zawijania/odpakowania.
  • Usługa zarządzania kluczami oparta na chmurze jest odpowiedzialna za autoryzowanie usługi w chmurze w celu użycia klucza odwołania. Po wywołaniu klucza odwołania przekazane żądanie do serwera proxy zarządzania kluczami nie musi znać usługi wywołującej lub mieć możliwość zweryfikowania, czy żądanie zostało prawidłowo autoryzowane — inne niż weryfikowanie żądania usługi zarządzania kluczami.

Inne kwestie wymagające rozważenia:

  • Organizacje są w pełni odpowiedzialne za pozyskiwanie, hostowanie i konserwowanie złożonych, nadmiarowych infrastruktury HSM i proxy, w tym szkolenia, procedury operacyjne i zarządzanie ryzykiem zarówno w przypadku niezamierzonych, jak i zamierzonych zdarzeń zabezpieczeń.
  • Organizacje kontrolują zasady modułu HSM, w tym możliwość oznaczania kluczy jako eksportowalnych, co może zmniejszyć bezpieczeństwo, jeśli nie jest prawidłowo zarządzane.
  • Utrata kluczy, dostępność usługi serwera proxy lub łączność interfejsu API powodują natychmiastowy i nieodzyskiwalny brak dostępu do danych dla zależnych usług chmurowych.

Uwaga / Notatka

Chociaż wskazano zewnętrzny dostęp do serwera proxy zarządzania kluczami, ruch ten może być hostowany w sieciach kontrolowanych przez ciebie lub dostawcę usług w chmurze, takich jak połączenia bezpośrednie i połączenia WAN, i nie wymaga publicznego dostępu do Internetu.

Ocenianie podejść do zarządzania kluczami

Zagadnienia dotyczące modelu zaufania i zabezpieczeń

Zaufanie do zarządzania kluczami wykracza poza fizyczną lokalizację kluczowego materiału. Niezależnie od podejścia zaufanie jest wymagane w metodach szyfrowania, oprogramowaniu układowym i usługach, które pośrednidzą między korzystaniem z aplikacji a magazynem kluczy.

Podejście do zarządzania kluczami zewnętrznymi:

  • Fizyczne oddzielenie kluczy od infrastruktury chmury
  • Wymaga zaufania do składników serwera proxy, które tłumaczą wywołania inicjowane przez chmurę na operacje specyficzne dla modułu HSM
  • Utrzymuje zależność od chmurowych punktów integracji usługi zarządzania kluczami
  • Pełną odpowiedzialność za bezpieczeństwo, niezawodność, trwałość i wydajność w organizacji

Zarządzany moduł HSM usługi Azure Key Vault:

  • Zapewnia kluczową suwerenność dzięki architekturze Azure Confidential Computing z poświadczeniami chronionymi przez Intel SGX
  • Zapewnia ochronę HSM zgodną z normą FIPS 140-3 poziom 3 w centrach danych platformy Azure
  • Umożliwia uwierzytelnianie wieloskładnikowe, procesy wielokrotnego zatwierdzania i wymagania kworum za pomocą Microsoft Entra ID i kworum domeny bezpieczeństwa.
  • Używa unikatowych domen zabezpieczeń z kontrolowanymi przez klienta kluczami maskowania i mechanizmami ochrony
  • Obsługuje standardowy interfejs API usługi Azure Key Vault z RSA-HSM i OCT-HSM typami kluczy i algorytmami
  • Źródło zaufania znajduje się poza dostawcą usług w chmurze (zarówno HSM, jak i procesor Intel CPU)
  • Saldo odpowiedzialności: firma Microsoft obsługuje wydajność, integralność klucza, niezawodność usługi i trwałość; klienci chronią domenę zabezpieczeń i klucze ochrony

Aby uzyskać szczegółowe porównania rozwiązań do zarządzania kluczami platformy Azure, zobacz Jak wybrać odpowiednie rozwiązanie do zarządzania kluczami.

Podsumowanie

Organizacje oceniające kluczowe podejścia do niezależności muszą równoważyć wymagania dotyczące zabezpieczeń, możliwości operacyjne i modele zaufania. Istnieją różne wzorce architektury do ochrony kluczowych materiałów, z których każdy ma odrębne kompromisy.

Usługa Azure Key Vault Managed HSM zapewnia obecnie suwerenność kluczy dzięki ochronie zgodnej z normą FIPS 140-3 poziomu 3 z architekturą poufnego przetwarzania danych, oferując wyłączność użytkowania i kontrolę nad kluczami przez klientów, podczas gdy firma Microsoft zajmuje się obowiązkami operacyjnymi. Architektury zarządzania kluczami zewnętrznymi zapewniają maksymalną kontrolę nad dostępem i zasadami modułu HSM, ale wymagają od organizacji zarządzania złożoną infrastrukturą i utrzymania dostępności usług dla zależnych obciążeń w chmurze.

Organizacje powinny oceniać podejścia oparte na wymaganiach dotyczących zgodności, zdolności operacyjnej, potrzebach integracji i równowadze odpowiedzialności, która jest zgodna z ich celami suwerenności.

Dalsze kroki

  • Klasyfikowanie obciążeń według wymaganej siły kontroli klucza (klucze zarządzane przez platformę → klucze zarządzane przez klienta → klucze zarządzane przez moduł HSM)
  • Dokumentowanie cykli rotacji i wyzwalaczy odwołania w każdej domenie kluczy
  • Ocena możliwości poufnego przetwarzania i bezpiecznego wydania klucza w przypadku obciążeń o wysokiej poufności

Zobacz także

  • Last updated on