Niezależność klucza, dostępność, wydajność i skalowalność w zarządzanym module HSM
Klucze kryptograficzne są głównym elementem zaufania do zabezpieczania nowoczesnych systemów komputerowych, zarówno lokalnych, jak i w chmurze. Dlatego kontrolowanie, kto ma uprawnienia do tych kluczy, ma kluczowe znaczenie dla tworzenia bezpiecznych i zgodnych aplikacji.
Na platformie Azure nasza wizja sposobu zarządzania kluczami w chmurze to kluczowa suwerenność. Suwerenność klucza oznacza, że organizacja klienta ma pełną i wyłączną kontrolę nad tym, kto może uzyskiwać dostęp do kluczy i zmieniać zasady zarządzania kluczami oraz jakie usługi platformy Azure korzystają z tych kluczy. Po podjęciu tych decyzji przez klienta personel firmy Microsoft nie może zmienić tych decyzji przez środki techniczne. Kod usługi zarządzania kluczami wykonuje decyzje klienta, dopóki klient nie poinformuje go o tym, aby zrobił inaczej, a personel firmy Microsoft nie może interweniować.
Jednocześnie uważamy, że każda usługa w chmurze musi być w pełni zarządzana. Usługa musi zapewnić wymaganą dostępność, odporność, bezpieczeństwo i podstawowe obietnice dotyczące chmury oparte na umowach dotyczących poziomu usług (SLA). Aby zapewnić usługę zarządzaną, firma Microsoft musi zastosować poprawki serwerów zarządzania kluczami, uaktualnić oprogramowanie układowe sprzętowego modułu zabezpieczeń (HSM), uzdrowić sprzęt, wykonać tryb failover i wykonać inne operacje z wysokimi uprawnieniami. Jak wiedzą większość specjalistów ds. zabezpieczeń, odmowa dostępu osoby z wysokimi uprawnieniami lub fizycznym dostępem do danych w tym systemie jest trudnym problemem.
W tym artykule wyjaśniono, w jaki sposób rozwiązaliśmy ten problem w usłudze Azure Key Vault Managed HSM, zapewniając klientom zarówno pełną suwerenność klucza, jak i w pełni zarządzane umowy SLA usług przy użyciu technologii poufnego przetwarzania sparowanego z modułami HSM.
Zarządzane środowisko sprzętowe modułu HSM
Pula zarządzanych modułów HSM klienta w dowolnym regionie świadczenia usługi Azure znajduje się w bezpiecznym centrum danych platformy Azure. Trzy wystąpienia są rozłożone na kilka serwerów. Każde wystąpienie jest wdrażane w innym stojaku, aby zapewnić nadmiarowość. Każdy serwer ma zweryfikowaną kartę HSM Marvell LiquidSecurity z wieloma rdzeniami kryptograficznymi fiPS 140-2 poziom 3 . Rdzenie służą do tworzenia w pełni izolowanych partycji HSM, w tym w pełni izolowanych poświadczeń, magazynu danych i kontroli dostępu.
Fizyczne rozdzielenie wystąpień wewnątrz centrum danych ma kluczowe znaczenie dla zapewnienia, że utrata pojedynczego składnika (na przykład przełącznika górnego stojaka lub jednostki zarządzania energią w stojaku) nie może mieć wpływu na wszystkie wystąpienia puli. Te serwery są przeznaczone dla zespołu modułu HSM zabezpieczeń platformy Azure. Serwery nie są udostępniane innym zespołom platformy Azure i na tych serwerach nie są wdrażane żadne obciążenia klientów. Fizyczne mechanizmy kontroli dostępu, w tym zablokowane stojaki, są używane do zapobiegania nieautoryzowanemu dostępowi do serwerów. Te mechanizmy kontroli spełniają standardy FedRAMP-High, PCI, SOC 1/2/3, ISO 270x i inne standardy zabezpieczeń i prywatności oraz są regularnie weryfikowane niezależnie w ramach programu zgodności platformy Azure. Moduły HSM mają zwiększone zabezpieczenia fizyczne, zweryfikowane pod kątem spełnienia wymagań fiPS 140-2 poziom 3. Cała zarządzana usługa HSM jest oparta na standardowej bezpiecznej platformie Azure, w tym na zaufanej uruchamianiu, która chroni przed zaawansowanymi trwałymi zagrożeniami.
Karty HSM mogą obsługiwać dziesiątki izolowanych partycji HSM. Uruchamianie na każdym serwerze jest procesem sterowania nazywanym usługą Node Service. Usługa Node Przejmuje własność każdej karty i instaluje poświadczenia właściciela karty, w tym przypadku firmy Microsoft. Moduł HSM został zaprojektowany tak, aby własność karty nie zapewnia firmie Microsoft dostępu do danych przechowywanych w partycjach klienta. Umożliwia ona tylko firmie Microsoft tworzenie, zmienianie rozmiaru i usuwanie partycji klienta. Obsługuje tworzenie niewidomych kopii zapasowych dowolnej partycji dla klienta. W ślepej kopii zapasowej kopia zapasowa jest owinięta kluczem dostarczonym przez klienta, który może zostać przywrócony przez kod usługi tylko wewnątrz zarządzanego wystąpienia modułu HSM należącego do klienta i którego zawartość nie jest czytelna przez firmę Microsoft.
Architektura zarządzanej puli modułów HSM
Rysunek 1 przedstawia architekturę puli modułów HSM, która składa się z trzech maszyn wirtualnych z systemem Linux, z których każda działa na serwerze HSM we własnym stojaku centrum danych w celu zapewnienia dostępności. Ważne składniki to:
- Kontroler sieci szkieletowej HSM (HFC) to płaszczyzna sterowania dla usługi. HFC napędza automatyczne stosowanie poprawek i napraw dla puli.
- Wyłączna granica kryptograficzna dla każdego klienta składająca się z trzech poufnych enklaw funkcji Intel SECURE Guard (Intel SGX) połączonych z trzema wystąpieniami modułu HSM zgodnymi ze standardem FIPS 140-2 poziom 3. Klucze główne dla tej granicy są generowane i przechowywane w trzech modułach HSM. Jak opisano w dalszej części tego artykułu, żadna osoba skojarzona z firmą Microsoft nie ma dostępu do danych znajdujących się w tej granicy. Dostęp ma tylko kod usługi uruchomiony w enklawie Intel SGX (w tym agent usługi Node), działający w imieniu klienta.
Zaufane środowisko wykonawcze (TEE)
Pula zarządzanych modułów HSM składa się z trzech wystąpień usługi. Każde wystąpienie usługi jest implementowane jako zaufane środowisko wykonawcze (TEE), które korzysta z funkcji Intel SGX i zestawu SDK open enklawy. Wykonanie w ramach środowiska TEE gwarantuje, że żadna osoba na maszynie wirtualnej, która hostuje usługę lub serwer hosta maszyny wirtualnej, ma dostęp do wpisów tajnych klienta, danych lub partycji HSM. Każde środowisko TEE jest przeznaczone dla określonego klienta i uruchamia zarządzanie protokołem TLS, obsługę żądań i kontrolę dostępu do partycji HSM. Nie istnieją poświadczenia ani klucze szyfrowania danych specyficzne dla klienta w postaci zwykłego tekstu poza tym pakietem TEE, z wyjątkiem pakietu domeny zabezpieczeń. Ten pakiet jest szyfrowany do klucza dostarczonego przez klienta i pobiera go po pierwszym utworzeniu puli.
Te es komunikują się między sobą przy użyciu attestowanego protokołu TLS. Testowany protokół TLS łączy możliwości zdalnego zaświadczania platformy Intel SGX z protokołem TLS 1.2. Dzięki temu zarządzany kod HSM w teE ogranicza komunikację tylko do innego kodu podpisanego przez ten sam klucz podpisywania kodu zarządzanego modułu HSM, aby zapobiec atakom typu man-in-the-middle. Klucz podpisywania kodu usługi Zarządzanego modułu HSM jest przechowywany w usłudze Microsoft Product Release and Security Service (która jest również używana do przechowywania, na przykład klucza podpisywania kodu systemu Windows). Klucz jest kontrolowany przez zespół zarządzanego modułu HSM. W ramach naszych obowiązków regulacyjnych i zgodności w zakresie zarządzania zmianami ten klucz nie może być używany przez żaden inny zespół firmy Microsoft do podpisania kodu.
Certyfikaty TLS, które są używane do komunikacji TEE-to-TEE, są wystawiane samodzielnie przez kod usługi wewnątrz teE. Certyfikaty zawierają raport platformy generowany przez enklawę Intel SGX na serwerze. Raport platformy jest podpisany przy użyciu kluczy pochodzących z kluczy połączonych przez intel do procesora CPU podczas jego produkcji. Raport identyfikuje kod, który jest ładowany do enklawy Intel SGX za pomocą klucza podpisywania kodu i skrótu binarnego. W tym raporcie platformy wystąpienia usługi mogą określić, że element równorzędny jest również podpisany przez klucz podpisywania kodu usługi zarządzanego modułu HSM, a niektóre splątanie kryptograficzne za pośrednictwem raportu platformy może również określić, że klucz podpisywania certyfikatu wystawiony samodzielnie musi również zostać wygenerowany wewnątrz środowiska TEE, aby zapobiec podszywaniu się pod zewnętrzne personifikację.
Umowy SLA dotyczące dostępności oferty z pełną kontrolą klucza zarządzanego przez klienta
Aby zapewnić wysoką dostępność, usługa HFC tworzy trzy wystąpienia modułu HSM w wybranym przez klienta regionie świadczenia usługi Azure.
Tworzenie zarządzanej puli modułów HSM
Właściwości wysokiej dostępności zarządzanych pul modułów HSM pochodzą z automatycznie zarządzanych, potrójnie nadmiarowych wystąpień modułu HSM, które są zawsze synchronizowane (lub, jeśli używasz replikacji z wieloma regionami, od zachowania synchronizacji wszystkich sześciu wystąpień). Tworzenie puli jest zarządzane przez usługę HFC, która przydziela pule na dostępnym sprzęcie w regionie świadczenia usługi Azure wybranym przez klienta.
Po zażądaniu nowej puli HFC wybiera trzy serwery w kilku stojakach, które mają dostępne miejsce na kartach HSM, a następnie zaczyna tworzyć pulę:
HFC instruuje agentów usługi Node Na każdym z trzech TEEs, aby uruchomić nowe wystąpienie kodu usługi przy użyciu zestawu parametrów. Parametry identyfikują dzierżawę firmy Microsoft Entra klienta, wewnętrzne adresy IP sieci wirtualnej wszystkich trzech wystąpień i inne konfiguracje usługi. Jedna partycja jest losowo przypisywana jako podstawowa.
Uruchamiane są trzy wystąpienia. Każde wystąpienie łączy się z partycją na lokalnej karcie HSM, a następnie wyzeruje i inicjuje partycję przy użyciu losowo wygenerowanych nazw użytkowników i poświadczeń (aby upewnić się, że partycja nie może być uzyskiwana przez operatora ludzkiego lub innego wystąpienia TEE).
Wystąpienie podstawowe tworzy certyfikat główny właściciela partycji przy użyciu klucza prywatnego wygenerowanego w module HSM. Ustanawia własność puli, podpisując certyfikat na poziomie partycji dla partycji HSM przy użyciu tego certyfikatu głównego. Podstawowy generuje również klucz szyfrowania danych, który jest używany do ochrony wszystkich danych klienta magazynowanych wewnątrz usługi. W przypadku materiału kluczowego używane jest podwójne zawijanie, ponieważ moduł HSM chroni również sam materiał klucza.
Następnie te dane własności są synchronizowane z dwoma wystąpieniami pomocniczymi. Każda pomocnicza kontaktuje się z podstawowym przy użyciu attestowanego protokołu TLS. Klucz podstawowy współudzieli certyfikat główny właściciela partycji z kluczem prywatnym i kluczem szyfrowania danych. Moduły pomocnicze używają teraz certyfikatu głównego partycji do wystawiania certyfikatu partycji do własnych partycji HSM. Po wykonaniu tej czynności będziesz mieć partycje HSM na trzech oddzielnych serwerach, które są własnością tego samego certyfikatu głównego partycji.
Za pośrednictwem sprawdzonego linku TLS podstawowy moduł HSM współużytkowuje z modułami pomocniczymi wygenerowany przez nią klucz opakowujący dane (używany do szyfrowania komunikatów między trzema modułami HSM) przy użyciu bezpiecznego interfejsu API udostępnianego przez dostawcę modułu HSM. Podczas tej wymiany moduły HSM potwierdzają, że mają ten sam certyfikat właściciela partycji, a następnie używają schematu Diffie-Hellman do szyfrowania komunikatów, aby kod usługi firmy Microsoft nie mógł ich odczytać. Wszystko, co może zrobić kod usługi, to transport nieprzezroczystych obiektów blob między modułami HSM.
W tym momencie wszystkie trzy wystąpienia są gotowe do udostępnienia jako pula w sieci wirtualnej klienta. Współużytkują ten sam certyfikat właściciela partycji i klucz prywatny, ten sam klucz szyfrowania danych i wspólny klucz opakowujący dane. Jednak każde wystąpienie ma unikatowe poświadczenia do partycji HSM. Teraz zostaną wykonane ostatnie kroki.
Każde wystąpienie generuje parę kluczy RSA i żądanie podpisania certyfikatu (CSR) dla certyfikatu TLS dostępnego publicznie. Csr jest podpisany przez system infrastruktury kluczy publicznych (PKI) firmy Microsoft przy użyciu publicznego katalogu głównego firmy Microsoft, a wynikowy certyfikat TLS jest zwracany do wystąpienia.
Wszystkie trzy wystąpienia uzyskują własny klucz uszczelniający Intel SGX z lokalnego procesora CPU. Klucz jest generowany przy użyciu własnego klucza unikatowego procesora CPU i klucza podpisywania kodu TEE.
Pula uzyskuje unikatowy klucz puli z kluczy uszczelniających Intel SGX, szyfruje wszystkie jego wpisy tajne przy użyciu tego klucza puli, a następnie zapisuje zaszyfrowane obiekty blob na dysku. Te obiekty blob można odszyfrować tylko przez kod podpisany przez ten sam klucz uszczelniający Intel SGX, który działa na tym samym fizycznym procesorze CPU. Wpisy tajne są powiązane z tym konkretnym wystąpieniem.
Bezpieczny proces uruchamiania jest teraz ukończony. Ten proces umożliwił zarówno utworzenie puli modułów HSM z trzema nadmiarowymi, jak i utworzenie kryptograficznego gwarancji niezależności danych klienta.
Utrzymywanie umów SLA dotyczących dostępności w czasie wykonywania przy użyciu funkcji naprawy usługi poufnej
Historia tworzenia puli opisana w tym artykule może wyjaśnić, w jaki sposób zarządzana usługa HSM może dostarczać jej umowy SLA o wysokiej dostępności, bezpiecznie zarządzając serwerami, które podjęły usługę. Wyobraź sobie, że serwer, adapter HSM, a nawet zasilacz do stojaka, ulegnie awarii. Celem usługi Zarządzanego modułu HSM jest, bez interwencji klienta ani możliwości ujawnienia wpisów tajnych w postaci zwykłego tekstu poza środowiskiem TEE, aby przywrócić pulę do trzech wystąpień w dobrej kondycji. Jest to realizowane za pośrednictwem poufnego naprawiania usługi.
Rozpoczyna się od HFC wykrywania, które pule miały wystąpienia na serwerze, który zakończył się niepowodzeniem. Usługa HFC znajduje nowe serwery w dobrej kondycji w regionie puli w celu wdrożenia wystąpień zastępczych. Uruchamia nowe wystąpienia, które są następnie traktowane dokładnie jako pomocnicza podczas początkowego kroku aprowizacji: inicjowanie modułu HSM, znajdowanie podstawowych, bezpieczne wymienianie wpisów tajnych w ramach zaświadczanego protokołu TLS, podpisywanie modułu HSM w hierarchii własności, a następnie uszczelnianie danych usługi do nowego procesora CPU. Usługa jest teraz uzdrowiona, w pełni automatycznie i w pełni poufne.
Odzyskiwanie po awarii przy użyciu domeny zabezpieczeń
Domena zabezpieczeń to zabezpieczony obiekt blob zawierający wszystkie poświadczenia potrzebne do ponownego skompilowania partycji HSM od podstaw: klucz właściciela partycji, poświadczenia partycji, klucz opakowujący dane oraz początkową kopię zapasową modułu HSM. Zanim usługa stanie się aktywna, klient musi pobrać domenę zabezpieczeń, podając zestaw kluczy szyfrowania RSA, aby je zabezpieczyć. Dane domeny zabezpieczeń pochodzą z TEEs i są chronione przez wygenerowany klucz symetryczny i implementację algorytmu udostępniania wpisów tajnych Shamiru, który dzieli udziały kluczy między klucze publiczne RSA dostarczone przez klienta zgodnie z parametrami kworum wybranego przez klienta. W trakcie tego procesu żaden z kluczy usługi lub poświadczeń nie jest nigdy uwidaczniony w postaci zwykłego tekstu poza kodem usługi uruchomionym w środowiskach TEE. Tylko klient, przedstawiając kworum kluczy RSA do teE, może odszyfrować domenę zabezpieczeń podczas scenariusza odzyskiwania.
Domena zabezpieczeń jest wymagana tylko wtedy, gdy z powodu awarii cały region świadczenia usługi Azure zostanie utracony i firma Microsoft utraci wszystkie trzy wystąpienia puli jednocześnie. Jeśli tylko jedno wystąpienie, a nawet dwa wystąpienia, zostaną utracone, poufne naprawy usługi po cichu zostaną odzyskane do trzech wystąpień w dobrej kondycji bez interwencji klienta. Jeśli cały region zostanie utracony, ponieważ klucze uszczelniające Intel SGX są unikatowe dla każdego procesora CPU, firma Microsoft nie ma możliwości odzyskania poświadczeń modułu HSM i kluczy właściciela partycji. Istnieją one tylko w kontekście wystąpień.
W bardzo mało prawdopodobnym przypadku wystąpienia tej katastrofy klient może odzyskać poprzedni stan puli i dane, tworząc nową pustą pulę, wstrzykiwając ją do domeny zabezpieczeń, a następnie przedstawiając kworum klucza RSA, aby udowodnić własność domeny zabezpieczeń. Jeśli klient włączył replikację w wielu regionach, jeszcze bardziej mało prawdopodobna katastrofa obu regionów, w których wystąpiła równoczesna awaria, musiałaby wystąpić, zanim konieczna będzie interwencja klienta w celu odzyskania puli z domeny zabezpieczeń.
Kontrolowanie dostępu do usługi
Zgodnie z opisem nasz kod usługi w TEE jest jedyną jednostką, która ma dostęp do samego modułu HSM, ponieważ wymagane poświadczenia nie są przekazywane klientowi ani nikomu innemu. Zamiast tego pula klienta jest powiązana z wystąpieniem firmy Microsoft Entra i jest używana do uwierzytelniania i autoryzacji. Podczas początkowej aprowizacji klient może wybrać początkowy zestaw pracowników, aby przypisać rolę Administratora dla puli. Te osoby i pracownicy w roli administratora globalnego dzierżawy firmy Microsoft Entra klienta mogą ustawić zasady kontroli dostępu w puli. Wszystkie zasady kontroli dostępu są przechowywane przez usługę w tej samej bazie danych co zamaskowane klucze, które są również szyfrowane. Tylko kod usługi w teE ma dostęp do tych zasad kontroli dostępu.
Podsumowanie
Zarządzany moduł HSM eliminuje konieczność dokonywania kompromisów między dostępnością i kontrolą kluczy kryptograficznych przy użyciu najnowocześniejszej, opartej na sprzęcie technologii enklawy poufnej. Zgodnie z opisem w tym artykule, w tej implementacji żaden personel lub przedstawiciel firmy Microsoft nie może uzyskać dostępu do materiałów kluczy zarządzanych przez klienta lub powiązanych wpisów tajnych, nawet z fizycznym dostępem do zarządzanych maszyn hosta HSM i modułów HSM. To bezpieczeństwo pozwoliło naszym klientom na usługi finansowe, produkcję, sektor publiczny, obronę i inne piony w celu przyspieszenia migracji do chmury z pełnym zaufaniem.