Ochrona własności intelektualnej na maszynach wirtualnych Azure za pomocą bezpiecznego wydania klucza zabezpieczonego za pomocą zaświadczania

W tym artykule opisano wzorzec wielokrotnego użytku do ochrony poufnego zasobu — na przykład własnościowych wag modelu uczenia maszynowego, licencjonowanego zestawu danych lub tajnej konfiguracji — który musi działać na maszynie wirtualnej (VM) w subskrypcji platformy Azure należącej do kogoś innego. Strona będąca właścicielem zasobu ( wydawcy) różni się od strony będącej właścicielem subskrypcji, w której działa maszyna wirtualna ( konsument). Użytkownik ma pełny dostęp do płaszczyzny sterowania Azure dla tej maszyny wirtualnej, ale nie może mieć możliwości wyodrębnienia tego zasobu.

Wzorzec łączy kilka udokumentowanych funkcji platformy Azure w wiele warstw ochrony. Jego kryptograficznym rdzeniem jest funkcja Secure Key Release (SKR) warunkowana poświadczeniem z usługi Azure Key Vault, warunkowana poświadczeniem vTPM funkcji Trusted Launch. Nie wymaga poufnego przetwarzania, chociaż poufne przetwarzanie można dodać jako opcjonalną warstwę, gdy model zagrożeń go wymaga.

Scenariusz i model zagrożeń

Wydawca wdraża obciążenie oparte na maszynach wirtualnych w subskrypcji klienta (na przykład za pośrednictwem Azure Marketplace jako szablon rozwiązania lub w postaci obrazu udostępnionego). Obciążenie robocze wymaga klucza deszyfrującego, aby uzyskać dostęp do zasobu wydawcy w czasie wykonywania. Klucz musi być wydany tylko do autentycznego, niezmodyfikowanego obrazu wydawcy — nigdy bezpośrednio konsumentowi ani nigdy do obrazu, przy którym dokonano manipulacji lub który został podmieniony.

Wzorzec broni przed dwoma odrębnymi kierunkami zagrożenia. Jawne nazywanie ich jest tym, co sprawia, że decyzje dotyczące warstw są jasne.

Kierunek zagrożenia A jest podstawowym zagrożeniem i tym, który kształtuje architekturę. W podstawowym modelu kierunek zagrożenia B jest ryzykiem świadomie akceptowanym: platforma jest zaufana, zgodnie z powszechnym podejściem polegającym na zaufaniu hiperwizorowi dostawcy chmury. Dodaj Layer 4 tylko wtedy, gdy samemu hipernadzorcy nie można ufać (na przykład w przypadku obciążenia podlegającego regulacjom, które wymaga szyfrowania pamięci).

Kiedy dodać poufne przetwarzanie (warstwa 4)

Przetwarzanie poufne nie jest alternatywą dla tego wzorca — to opcjonalna warstwa 4, którą dodajesz na wierzchu. Wzorzec podstawowy (warstwy 1–3) już uzależnia wydanie klucza od poświadczenia, chroni zasób przed użytkownikiem i działa na dowolnym wariancie Gen2 Trusted Launch SKU w standardowej cenie. Dodanie przetwarzania poufnego nie zmienia sposobu działania wzorca: SKR, utwardzony obraz i izolacja sieci pozostają takie same, a proces wydawania jest identyczny. Jedyne różnice polegają na tym, że zasady wydania opierają się na deklaracjach hardware-TEE zamiast na deklaracjach mierzonego rozruchu vTPM, a obciążenie działa w wariancie SKU poufnej maszyny wirtualnej. Zyskujesz ochronę przed wektorem zagrożenia B (hostem/hipernadzorcą), ale odbywa się to kosztem mniejszej dostępności jednostek SKU, procesorów GPU i regionów oraz wyższej ceny.

Poniższa tabela pokazuje, co dodaje warstwa 4 i z jakimi kosztami się to wiąże — a nie wybór między dwoma wzorcami:

Zacznij od wzorca podstawowego. Dodaj warstwę 4 tylko wtedy, gdy musisz nie ufać hiperwizorowi — na przykład w przypadku obciążenia podlegającego regulacjom, które wymaga szyfrowania pamięci — akceptując bardziej ograniczoną dostępność SKU, GPU i regionów oraz wyższy koszt.

Elementy wzorca

Ten wzorzec stanowi wielowarstwowy model obrony. Każda warstwa broni określonego kierunku zagrożenia: Warstwy 1–3 bronią przed konsumentem (kierunek zagrożenia A), a opcjonalna warstwa 4 broni przed hostem (kierunek zagrożenia B). Chroniony zasób znajduje się w rdzeniu, osiągalny tylko przez każdą otaczającą warstwę.

flowchart TB
    threatA["Threat direction A<br/>Consumer / VM and subscription owner<br/>run-command, disk snapshot and swap,<br/>serial console, managed-identity theft"]
    threatB["Threat direction B<br/>Host / hypervisor<br/>reads guest memory"]

    subgraph L4 ["Layer 4 (optional) — Confidential Computing: host memory encryption"]
        subgraph L3 ["Layer 3 — Network isolation: private endpoints, no public egress, deny assignments"]
            subgraph L2 ["Layer 2 — Hardened image: dm-verity, read-only root, no SSH or agent"]
                subgraph L1 ["Layer 1 — Attestation-gated SKR: vTPM measured-boot claims gate key release"]
                    asset["Protected asset<br/>released key, then decrypted weights"]
                end
            end
        end
    end

    threatA -. "defended by Layers 1–3" .-> asset
    threatB -. "defended only by Layer 4" .-> asset
    style L4 stroke-dasharray: 5 5

Warstwy chronią zasób zarówno w spoczynku, jak i podczas użycia. Podczas działania maszyna wirtualna odbiorcy i kotwice zaufania wydawcy oddziałują ze sobą w następujący sposób:

flowchart TB
    subgraph consumer ["Consumer tenant (untrusted operator)"]
        vm["Trusted Launch VM<br/>Secure Boot + vTPM<br/>Hardened image"]
    end
    subgraph publisher ["Publisher tenant (holds the trust anchors)"]
        maa["Microsoft Azure Attestation"]
        akv["Key Vault Premium / Managed HSM<br/>exportable key + release policy"]
    end
    vm -->|"1. Attestation request (vTPM evidence)"| maa
    maa -->|"2. Signed MAA token (secureboot, PCR claims)"| vm
    vm -->|"3. POST /keys/{key}/release (MAA token)"| akv
    akv -->|"4. Key wrapped to vTPM ephemeral key, or AccessDenied"| vm
    linkStyle default stroke-width:2px

Warstwa 1: Bezpieczne udostępnianie klucza uwarunkowane atestacją (brama kryptograficzna)

Ta warstwa jest podstawą. Maszyna wirtualna z funkcją Zaufane uruchamianie uruchamia się z Bezpiecznym rozruchem i wirtualnym modułem TPM (vTPM). vTPM zapisuje pomiary łańcucha rozruchowego w rejestrach konfiguracji platformy (PCR), tworząc kryptograficzny odcisk palca dokładnie tego, co zostało uruchomione. Gość żąda tokenu MAA, który zawiera te pomiary, takie jak oświadczenie secureboot oraz od x-ms-azurevm-attested-pcr-values.pcr0 do pcr7. Następnie wywołuje punkt końcowy /release usługi Key Vault i przekazuje token. Key Vault weryfikuje podpis tokenu i ocenia go względem zasad wydania klucza. Jeśli oświadczenia określone w zasadach są zgodne, usługa Key Vault udostępnia klucz opakowany przy użyciu efemerycznego klucza vTPM, tak aby tylko ta poświadczona maszyna wirtualna mogła go odszyfrować. Jeśli nie są zgodne, zwracana jest wartość AccessDenied.

Przed czym chroni (zagrożenie A): Zmodyfikowana, ponownie utworzona z obrazu lub z podmienionym dyskiem maszyna wirtualna ma inne wartości PCR i nie może uzyskać klucza. Migawka dysku systemu operacyjnego zainstalowanego na innej maszynie wirtualnej również kończy się niepowodzeniem.

Przykładowe zasady wydawania dla maszyny wirtualnej Trusted Launch:

{
  "version": "1.0.0",
  "anyOf": [
    {
      "authority": "https://<MAA_PROVIDER>.<region>.attest.azure.net",
      "allOf": [
        { "claim": "secureboot", "equals": true },
        { "claim": "x-ms-azurevm-attested-pcr-values.pcr4", "equals": "<BASE64_PCR4>" },
        { "claim": "x-ms-azurevm-attested-pcr-values.pcr7", "equals": "<BASE64_PCR7>" }
      ]
    }
  ]
}

Warstwa 2: Utwardzony obraz (chroń odszyfrowany zasób)

Warstwa 1 decyduje o tym, czy klucz jest udostępniany; nie chroni zasobu po jego odszyfrowaniu w działającej maszynie gościnnej. Wzmocnienie zabezpieczeń obrazu w celu zmniejszenia powierzchni ataków gościa i płaszczyzny sterowania: integralność systemu plików (na przykład dm-verity), główny system plików tylko do odczytu, brak demona SSH, bez interakcyjnego logowania i bez agenta gościa, który może wykonywać polecenia dostarczane przez operator.

Co blokuje (zagrożenie A): Wykorzystanie wewnątrz gościa uruchomionej, poświadczonej maszyny wirtualnej — takie jak nieautoryzowane procesy, eskalacja uprawnień czy wyodrębnienie odszyfrowanego zasobu z pamięci procesu za pomocą luki na poziomie systemu operacyjnego.

Warstwa 3. Izolacja sieci (zmniejszanie powierzchni)

Ogranicz sposób rozmowy maszyny wirtualnej z kotwicami zaufania i danymi. Użyj prywatnych punktów końcowych dla Key Vault, usług magazynowania i dowolnego rejestru; prywatnej ścieżki dostępu do dostawcy poświadczania; prywatnego DNS; oraz bez zbędnego publicznego ruchu wychodzącego. Jeśli mechanizm wdrażania to obsługuje — na przykład aplikacja zarządzana — przypisania typu deny mogą również odebrać odbiorcy uprawnienia RBAC do zasobów obliczeniowych, całkowicie blokując ataki na płaszczyznę sterowania (run-command, operacje na dyskach, konsolę szeregową, kradzież tożsamości). W modelu dostarczania opartym na szablonie rozwiązania odbiorca zachowuje uprawnienia RBAC do wdrożonych zasobów, więc utwardzanie płaszczyzny sterowania nie jest dostępne; w takim przypadku warstwy 1 i 2 zapewniają ochronę przed zagrożeniem A — migawka lub podmieniony dysk nie przejdą poświadczenia (warstwa 1), a utwardzony obraz (warstwa 2) uniemożliwia wyodrębnienie odszyfrowanego zasobu z poziomu systemu gościa.

Co blokuje (zagrożenie A): Zmniejsza uwidocznione powierzchnie zarówno dla ataków płaszczyzny sterowania, jak i płaszczyzny danych, i zapobiega eksfiltracji ścieżek od zaświadczanego gościa.

Warstwa 4 (opcjonalnie): Poufne przetwarzanie (broni kierunku zagrożenia B)

Wszystko powyżej ufa hostowi. Jeśli nie możesz ufać hiperwizorowi, uruchom obciążenie robocze na maszynie wirtualnej z ochroną poufności (AMD SEV-SNP lub Intel TDX). Szyfrowanie pamięci uniemożliwia hostowi odczyt pamięci gościa, a mechanizm SKR podnosi poziom deklaracji w polityce wydania z deklaracji vTPM dotyczących mierzonego rozruchu do deklaracji opartych na sprzętowym TEE. Ta warstwa jest jedyną warstwą, która chroni przed zagrożeniem z kierunku B. Jest domyślnie wyłączona, ponieważ ogranicza dostępność jednostek SKU, procesorów GPU i regionów oraz zwiększa koszty.

Tożsamość między dzierżawcami

Wydawca przechowuje kotwice zaufania — Key Vault (lub zarządzany moduł HSM) oraz dostawcę poświadczania — w dzierżawie wydawcy, poza mechanizmem RBAC odbiorcy. Maszyna wirtualna z poświadczeniem działa w dzierżawie klienta i musi wywoływać usługę Key Vault przez tę granicę. Dwa ograniczenia platformy wykluczają oczywiste podejścia:

• Tożsamość zarządzana istnieje tylko w jednym dzierżawcy. Dzierżawa wydawcy nie rozpozna tożsamości zarządzanej znajdującej się w dzierżawie odbiorcy ani nie wyda jej tokenów.
• Przypisanie roli RBAC Azure może być przeznaczone tylko dla tożsamości we własnej dzierżawie zasobu, więc nie można przyznać tożsamości zarządzanej odbiorcy roli w Key Vault wydawcy.

Poświadczenie tożsamości federacyjnej (FIC) również nie może bezpośrednio zniwelować tej różnicy: Entra ID nie pozwala, aby poświadczenie FIC ufało tokenom wystawianym przez inną dzierżawę Entra, więc aplikacja należąca do wydawcy nie może sfederować zarządzanej tożsamości konsumenta ponad tą granicą.

Wzorzec, który działa, umieszcza tożsamość pomostową — aplikację wielodostępną — po stronie konsumenta:

1. Odbiorca rejestruje aplikację wielodostępną w swojej dzierżawie i konfiguruje w niej element FIC w tej samej dzierżawie, który ufa tożsamości zarządzanej maszyny wirtualnej. FIC, który ufa tożsamości w tej samej dzierżawie, jest dozwolony.
2. Publikujący wdraża tę aplikację we własnej dzierżawie, tworząc dla niej nazwę główną usługi i przypisując tej nazwie głównej rolę Key Vault Crypto Service Release User dla klucza. Ten zamierzony etap wdrożenia dla każdego odbiorcy to moment, w którym wydawca udziela podmiotowi zewnętrznemu dostępu do swojej dzierżawy.
3. W czasie wykonywania tożsamość zarządzana maszyny wirtualnej pobiera token z usługi IMDS, wymienia go za pośrednictwem FIC w celu uwierzytelnienia jako aplikacji wielodostępnej i wywołuje punkt końcowy Key Vault /release z tokenem MAA w treści żądania.

Przewodnik

1. Skonfiguruj kotwice zaufania (dzierżawa wydawcy). Utwórz Key Vault premium lub zarządzany moduł HSM. Utwórz klucz RSA-HSM z możliwością eksportowania . Dołącz politykę wydania, która przypisuje Twój autorytet MAA i deklaracje Trusted Launch (secureboot, wybrane x-ms-azurevm-attested-pcr-values.pcrN).
2. Określanie oczekiwanych wartości PCR. Zaświadczaj znane dobre wystąpienie obrazu raz i odczytaj x-ms-azurevm-attested-pcr-values z zwróconego tokenu MAA. Przypnij rejestry PCR mierzone przez łańcuch rozruchu — najczęściej pcr4 (program rozruchowy/jądro) i pcr7 (stan funkcji Secure Boot).
3. Wdróż obciążenie robocze (dzierżawa klienta). Wdróż maszynę wirtualną z funkcją Zaufane uruchamianie (Gen2) działającą na utwardzonym obrazie. Nadaj jej tożsamość zarządzaną i sfederuj ją z należącą do odbiorcy aplikacją wielodzierżawową opisaną w artykule Tożsamość między dzierżawami, której jednostce usługi wydawca przyznał rolę Key Vault Crypto Service Release User do klucza.
4. Zaświadczaj i zwalniaj w czasie wykonywania. Użytkownik-gość uzyskuje token MAA, a następnie wywołuje POST /keys/{key-name}/release. Key Vault weryfikuje i zwraca opakowany klucz; gość odpakowuje go wewnątrz maszyny wirtualnej.
5. Zweryfikuj przypadek negatywny. Zmień przypięty pcR w zasadach wydania na niezgodną wartość (lub uruchom zmodyfikowany obraz) i potwierdź, że wydanie zwraca wartość AccessDenied.

Aby uzyskać kod możliwy do uruchomienia, zobacz przykłady w sekcji Powiązana zawartość.

Treści powiązane

• Gramatyka zasad bezpiecznego wydania kluczy w usłudze Azure Key Vault
• Bezpieczne udostępnianie kluczy przy użyciu Azure Key Vault i Azure Confidential Computing
• Przykłady zasad bezpiecznego wydania klucza
• Omówienie usługi Microsoft Azure Attestation
• Zaufane uruchamianie maszyn wirtualnych platformy Azure
• Federacja tożsamości obciążeniowej
• Przykład: cvm-securekey-release-app w Azure/confidential-computing-cvm-guest-attestation
• Przykład: przykłady SKR w Azure-Samples/confidential-computing