Správa důvěryhodných hardwarových identit

  • Článek

Služba Trusted Hardware Identity Management zpracovává správu certifikátů mezipaměti pro všechna důvěryhodná spouštěcí prostředí (TEE), která se nacházejí v Azure. Poskytuje také informace o důvěryhodných výpočetních základech (TCB), které vynucují minimální směrný plán pro řešení ověření identity.

Interakce s důvěryhodnou správou identit hardwaru a ověřením identity

Důvěryhodná správa identit hardwaru definuje standardní hodnoty zabezpečení Azure pro uzly důvěrného výpočetního prostředí (ACC) Azure a ukládá do mezipaměti zajištění od poskytovatelů TEE. Služby ověření identity a uzly ACC můžou k ověření TEE používat informace uložené v mezipaměti. Následující diagram znázorňuje interakce mezi službou ověření identity nebo uzlem, důvěryhodnou správou identit hardwaru a hostitelem enklávy.

Diagram znázorňující interakce mezi službou ověření identity nebo uzlem, důvěryhodnou správou identit hardwaru a hostitelem enklávy

Nejčastější dotazy

Návody používat správu důvěryhodných hardwarových identit s procesory Intel?

K vygenerování uvozovek Intel SGX a Intel TDX potřebuje knihovna QGL (Intel Quote Generation Library) přístup ke generování a ověřování nabídek. Všechny nebo části tohoto zajištění musí být načteny ze správy identit důvěryhodného hardwaru. Můžete ho načíst pomocí knihovny Zprostředkovatele nabídky Intel (QPL) nebo klientské knihovny DCAP (Data Center Attestation Primitives).

Datum "příští aktualizace" rozhraní API služby pro interní ukládání do mezipaměti Azure, které používá ověřování Azure, se zdá být zastaralé. Je stále v provozu a můžu ho použít?

Pole tcbinfo obsahuje informace TCB. Služba Trusted Hardware Identity Management poskytuje ve výchozím nastavení starší tcbinfo informace. Aktualizace na nejnovější tcbinfo informace od Společnosti Intel by způsobila selhání ověření identity pro zákazníky, kteří se nemigrovali na nejnovější sadu Intel SDK, a mohlo by dojít k výpadkům.

Open Enclave SDK a Azure Attestation se ale nedívají na nextUpdate datum a projdou ověřením identity.

Co je knihovna Azure DCAP?

Knihovna DCAP (Attestation Primitives) v Azure Data Center, která nahrazuje knihovnu intel quote provider Library (QPL), načte zajištění generování nabídek a zajištění ověření nabídek přímo ze služby Trusted Hardware Identity Management. Načtení zajištění přímo ze služby Trusted Hardware Identity Management zajišťuje, aby všichni hostitelé Azure měli k dispozici zajištění v rámci cloudu Azure, aby se snížily externí závislosti. Aktuální doporučená verze knihovny DCAP je 1.11.2.

Kde si můžu stáhnout nejnovější knihovnu Azure DCAP?

Ke stažení balíčků použijte následující odkazy:

Pro novější verze Ubuntu (například Ubuntu 22.04) musíte použít Intel QPL.

Proč mají důvěryhodná správa hardwarových identit a Intel různé směrné plány?

Trusted Hardware Identity Management a Intel poskytují různé základní úrovně důvěryhodné výpočetní základny. Pokud zákazníci předpokládají, že Intel má nejnovější směrné plány, musí zajistit splnění všech požadavků. Tento přístup může vést k přerušení, pokud se zákazníci neaktualizovali na zadané požadavky.

Správa důvěryhodných hardwarových identit má pomalejší přístup k aktualizaci směrného plánu TCB, aby zákazníci mohli provést potřebné změny vlastním tempem. I když tento přístup poskytuje starší směrný plán TCB, zákazníci se nedostanou k přerušení, pokud nesplní požadavky nového směrného plánu TCB. Proto je směrný plán TCB ze služby Trusted Hardware Identity Management jinou verzí než standardní hodnoty od společnosti Intel. Chceme zákazníkům umožnit, aby splnili požadavky nového směrného plánu TCB svým tempem, místo aby je vynutili aktualizaci a způsobili přerušení, které by vyžadovalo přeiritování pracovníchstreamů.

S procesory Intel Xeon E bych mohl získat certifikáty přímo z Intel PCS. Proč s procesory Intel Xeon Scalable od 4. generace potřebuji získat certifikáty ze správy důvěryhodných hardwarových identit? A jak můžu tyto certifikáty načíst?

Počínaje 4. generaci procesorů Intel® Xeon® Scalable provádí Azure nepřímou registraci ve službě Intel Registration Service pomocí manifestu platformy a uloží výsledný certifikát PCK ve službě Trusted Hardware Identity Management (THIM), protože registrační služba Intel v tomto případě neukládá kořenové klíče pro platformu a to se projeví příznakem false v CachedKeys certifikátech PCK. Při použití nepřímé registrace by veškerá následující komunikace s Intel PCS vyžadovala manifest platformy, který Azure neposkytuje virtuálním počítačům. Místo toho musí virtuální počítače kontaktovat THIM, aby přijímaly certifikáty PCK. Pokud chcete načíst certifikát PCK, můžete použít knihovnu Intel QPL nebo Azure DCAP.

Návody používat Intel QPL se správou důvěryhodných hardwarových identit?

Zákazníci můžou chtít flexibilitu používat Intel QPL k interakci se správou důvěryhodných hardwarových identit, aniž by museli stahovat jinou závislost od Microsoftu (to znamená klientskou knihovnu Azure DCAP). Zákazníci, kteří chtějí používat Intel QPL se službou Trusted Hardware Identity Management, musí upravit konfigurační soubor Intel QPL sgx_default_qcnl.conf.

Uvozovky generování/ověření, které se používají k vygenerování uvozovek Intel SGX nebo Intel TDX, je možné rozdělit na:

  • Certifikát PCK. K jeho načtení musí zákazníci použít koncový bod důvěryhodné správy identit hardwaru.
  • Všechny ostatní záruky generování/ověření nabídky. Zákazníci ho můžou načíst buď pomocí koncového bodu Důvěryhodné správy identit hardwaru, nebo koncového bodu Intel Provisioning Certification Service (PCS).

Konfigurační soubor Intel QPL (sgx_default_qcnl.conf) obsahuje tři klíče pro definování koncových bodů zajištění. Klíč pccs_url definuje koncový bod, který se používá k načtení certifikátů PCK. Klíč collateral_service může definovat koncový bod, který se používá k načtení všech ostatních záruk generování nabídek nebo ověření. collateral_service Pokud klíč není definovaný, veškeré zajištění ověření nabídky se načte z koncového bodu definovaného pccs_url klíčem.

Následující tabulka ukazuje, jak lze tyto klíče nastavit.

Název Možné koncové body
pccs_url Koncový bod důvěryhodné správy identit hardwaru: https://global.acccache.azure.net/sgx/certification/v3.
collateral_service Koncový bod důvěryhodné správy identit hardwaru (https://global.acccache.azure.net/sgx/certification/v3) nebo koncový bod Intel PCS. Soubor sgx_default_qcnl.conf vždy uvádí nejaktuálnější koncový bod v klíči collateral_service .

Následující fragment kódu pochází z příkladu konfiguračního souboru Intel QPL:

    { 
        "pccs_url": "https://global.acccache.azure.net/sgx/certification/v3/", 
        "use_secure_cert": true, 
        "collateral_service": "https://global.acccache.azure.net/sgx/certification/v3/",  
        "pccs_api_version": "3.1", 
        "retry_times": 6, 
        "retry_delay": 5, 
        "local_pck_url": "http://169.254.169.254/metadata/THIM/sgx/certification/v3/",
        "pck_cache_expire_hours": 24, 
        "verify_collateral_cache_expire_hours": 24, 
        "custom_request_options": { 
            "get_cert": { 
                "headers": { 
                    "metadata": "true" 
                }, 
                "params": { 
                    "api-version": "2021-07-22-preview" 
                } 
            } 
        } 
    }

Následující postupy vysvětlují, jak změnit konfigurační soubor Intel QPL a aktivovat změny.

V systému Windows

  1. Proveďte změny konfiguračního souboru.

  2. Ujistěte se, že soubor má oprávnění ke čtení z následujícího umístění registru a klíče/hodnoty:

    [HKEY_LOCAL_MACHINE\SOFTWARE\Intel\SGX\QCNL]
"CONFIG_FILE"="<Full File Path>"

  3. Restartujte službu AESMD. Otevřete například PowerShell jako správce a použijte následující příkazy:

    Restart-Service -Name "AESMService" -ErrorAction Stop
Get-Service -Name "AESMService"

V Linuxu

  1. Proveďte změny konfiguračního souboru. Například pro změny můžete použít Vim pomocí následujícího příkazu:

    sudo vim /etc/sgx_default_qcnl.conf

  2. Restartujte službu AESMD. Otevřete libovolný terminál a spusťte následující příkazy:

    sudo systemctl restart aesmd 
systemctl status aesmd

Návody požádat o zajištění v důvěrném virtuálním počítači?

V důvěrném hostu virtuálního počítače (CVM) použijte následující ukázku pro vyžádání zajištění AMD, které zahrnuje certifikát VCEK a řetěz certifikátů. Podrobnosti o tomto doprovodu a o tom, odkud pochází, najdete v tématu Certifikát VCEK (Versioned Chip Endorsement Key) a specifikace rozhraní KDS.

Parametry identifikátoru URI

GET "http://169.254.169.254/metadata/THIM/amd/certification"

Text požadavku

Name Typ Popis
Metadata Logické Nastavení umožňující True vrácení zajištění.

Ukázkový požadavek

curl GET "http://169.254.169.254/metadata/THIM/amd/certification" -H "Metadata: true"

Odpovědi

Název Popis
200 OK Seznam dostupných zajištění v textu HTTP ve formátu JSON
Other Status Codes Popisuje, proč operace selhala.

Definice

Key Popis
VcekCert Certifikát X.509v3 definovaný v dokumentu RFC 5280
tcbm Důvěryhodná výpočetní základna
certificateChain Certifikáty AMD SEV Key (ASK) a AMD Root Key (ARK)

Návody požádat o zajištění AMD v kontejneru služby Azure Kubernetes Service na uzlu CVM?

Pokud chcete požádat o zajištění AMD v důvěrném kontejneru, postupujte takto:

  1. Začněte vytvořením clusteru Azure Kubernetes Service (AKS) na uzlu CVM nebo přidáním fondu uzlů CVM do existujícího clusteru:

    • Vytvořte cluster AKS na uzlu CVM:

      1. Vytvořte skupinu prostředků v jedné z podporovaných oblastí CVM:

        az group create --resource-group <RG_NAME> --location <LOCATION>

      2. Vytvořte cluster AKS s jedním uzlem CVM ve skupině prostředků:

        az aks create --name <CLUSTER_NAME> --resource-group <RG_NAME> -l <LOCATION> --node-vm-size Standard_DC4as_v5 --nodepool-name <POOL_NAME> --node-count 1

      3. Nakonfigurujte kubectl pro připojení ke clusteru:

        az aks get-credentials --resource-group <RG_NAME> --name <CLUSTER_NAME>

    • Přidejte fond uzlů CVM do existujícího clusteru AKS:

      az aks nodepool add --cluster-name <CLUSTER_NAME> --resource-group <RG_NAME> --name <POOL_NAME > --node-vm-size Standard_DC4as_v5 --node-count 1

  2. Pomocí příkazu ověřte připojení ke clusteru kubectl get . Tento příkaz vrátí seznam uzlů clusteru.

    kubectl get nodes

    Následující příklad výstupu ukazuje jeden uzel, který jste vytvořili v předchozích krocích. Ujistěte se, že je Readystav uzlu .

    NAME STAV ROLE AGE (VĚK) VERZE
    aks-nodepool1-31718369-0 Připraven agent 6m44s v1.12.8

  3. Vytvořte soubor curl.yaml s následujícím obsahem. Definuje úlohu, která spouští kontejner curl pro načtení zajištění AMD z koncového bodu Trusted Hardware Identity Management. Další informace o úlohách Kubernetes najdete v dokumentaci k Kubernetes.

    apiVersion: batch/v1 
kind: Job 
metadata: 
  name: curl 
spec: 
  template: 
    metadata: 
      labels: 
        app: curl 
    spec: 
      nodeSelector: 
        kubernetes.azure.com/security-type: ConfidentialVM 
      containers: 
        - name: curlcontainer 
          image: alpine/curl:3.14 
          imagePullPolicy: IfNotPresent 
          args: ["-H", "Metadata:true", "http://169.254.169.254/metadata/THIM/amd/certification"] 
      restartPolicy: "Never"

    Soubor curl.yaml obsahuje následující argumenty.

    Name Typ Popis
    Metadata Logické Nastavení umožňující True vrácení zajištění.

  4. Spusťte úlohu použitím souboru curl.yaml :

    kubectl apply -f curl.yaml

  5. Zkontrolujte a počkejte, až pod dokončí svou úlohu:

    kubectl get pods

    Zde je příklad odpovědi:

    Název Připraven Stav Restartuje Věk
    Curl-w7nt8 0/1 Dokončeno 0 72 s

  6. Spuštěním následujícího příkazu získejte protokoly úloh a ověřte, jestli funguje. Úspěšný výstup by měl zahrnovat vcekCert, tcbma certificateChain.

    kubectl logs job/curl

Další kroky