Bagikan melalui

Manajemen Identitas Perangkat Keras Tepercaya

  • Artikel

Layanan Manajemen Identitas Perangkat Keras Tepercaya menangani manajemen cache sertifikat untuk semua lingkungan eksekusi tepercaya (TEEs) yang berada di Azure. Ini juga menyediakan informasi basis komputasi tepercaya (TCB) untuk memberlakukan garis besar minimum untuk solusi pengesahan.

Manajemen Identitas Perangkat Keras Tepercaya dan interaksi pengesahan

Manajemen Identitas Perangkat Keras Tepercaya menentukan garis besar keamanan Azure untuk simpul komputasi rahasia Azure (ACC) dan jaminan cache dari penyedia TEE. Layanan pengesahan dan simpul ACC dapat menggunakan informasi cache untuk memvalidasi TEE. Diagram berikut menunjukkan interaksi antara layanan pengesahan atau simpul, Manajemen Identitas Perangkat Keras Tepercaya, dan host enklave.

Diagram yang menggambarkan interaksi antara layanan pengesahan atau simpul, Manajemen Identitas Perangkat Keras Tepercaya, dan host enklave.

Tanya jawab umum

Bagaimana cara menggunakan Manajemen Identitas Perangkat Keras Tepercaya dengan prosesor Intel?

Untuk menghasilkan kutipan Intel SGX dan Intel TDX, Intel Quote Generation Library (QGL) memerlukan akses ke pembuatan kutipan/jaminan validasi. Semua atau bagian dari jaminan ini harus diambil dari Manajemen Identitas Perangkat Keras Tepercaya. Anda dapat mengambilnya dengan menggunakan pustaka klien Intel Quote Provider Library (QPL) atau Azure Data Center Attestation Primitives (DCAP).

Tanggal "pembaruan berikutnya" dari API layanan penembolokan internal Azure yang digunakan Azure Attestation tampaknya sudah kedaluarsa. Apakah masih beroperasi dan dapatkah saya menggunakannya?

Bidang tcbinfo berisi informasi TCB. Layanan Manajemen Identitas Perangkat Keras Tepercaya menyediakan informasi yang lebih tcbinfo lama secara default. Memperbarui ke informasi terbaru tcbinfo dari Intel akan menyebabkan kegagalan pengesahan bagi pelanggan yang belum bermigrasi ke Intel SDK terbaru, dan dapat mengakibatkan pemadaman.

Open Enclave SDK dan Azure Attestation tidak melihat nextUpdate tanggal, namun, dan akan melewati pengesahan.

Apa itu pustaka Azure DCAP?

Pustaka Azure Data Center Attestation Primitives (DCAP), pengganti Intel Quote Provider Library (QPL), mengambil jaminan pembuatan kutipan dan jaminan validasi kutipan langsung dari layanan Manajemen Identitas Perangkat Keras Tepercaya. Mengambil jaminan langsung dari layanan Manajemen Identitas Perangkat Keras Tepercaya memastikan bahwa semua host Azure memiliki jaminan yang tersedia di cloud Azure untuk mengurangi dependensi eksternal. Versi pustaka DCAP yang direkomendasikan saat ini adalah 1.11.2.

Di mana saya dapat mengunduh pustaka Azure DCAP terbaru?

Gunakan tautan berikut untuk mengunduh paket:

Untuk versi Ubuntu yang lebih baru (misalnya, Ubuntu 22.04), Anda harus menggunakan Intel QPL.

Mengapa Manajemen Identitas Perangkat Keras Tepercaya dan Intel memiliki garis besar yang berbeda?

Manajemen Identitas Perangkat Keras Tepercaya dan Intel menyediakan tingkat dasar yang berbeda dari basis komputasi tepercaya. Ketika pelanggan berasumsi bahwa Intel memiliki garis besar terbaru, mereka harus memastikan bahwa semua persyaratan terpenuhi. Pendekatan ini dapat menyebabkan kerusakan jika pelanggan belum memperbarui ke persyaratan yang ditentukan.

Manajemen Identitas Perangkat Keras Tepercaya mengambil pendekatan yang lebih lambat untuk memperbarui garis besar TCB, sehingga pelanggan dapat membuat perubahan yang diperlukan dengan kecepatan mereka sendiri. Meskipun pendekatan ini menyediakan garis besar TCB yang lebih lama, pelanggan tidak akan mengalami kerusakan jika mereka belum memenuhi persyaratan garis besar TCB baru. Inilah sebabnya mengapa garis besar TCB dari Trusted Hardware Identity Management adalah versi yang berbeda dari garis besar Intel. Kami ingin memberdayakan pelanggan untuk memenuhi persyaratan garis besar TCB baru dengan kecepatan mereka, alih-alih memaksa mereka untuk memperbarui dan menyebabkan gangguan yang akan memerlukan reprioritasisasi aliran kerja.

Dengan Intel Xeon E Processors, saya bisa mendapatkan sertifikat saya langsung dari Intel PCS. Mengapa, dengan prosesor Intel Xeon Scalable mulai dari generasi ke-4, apakah saya perlu mendapatkan sertifikat dari Trusted Hardware Identity Management? Dan bagaimana cara mengambil sertifikat tersebut?

Dimulai dengan Prosesor Intel® Xeon® yang Dapat Diskalakan Generasi ke-4, Azure melakukan pendaftaran tidak langsung di Layanan Pendaftaran Intel menggunakan Manifes Platform dan menyimpan sertifikat PCK yang dihasilkan dalam layanan Manajemen Identitas Perangkat Keras Tepercaya (THIM) Azure menggunakan pendaftaran tidak langsung, karena layanan pendaftaran Intel tidak akan menyimpan kunci akar untuk platform dalam kasus ini dan ini tercermin dalam false CachedKeys bendera dalam Sertifikat PCK. Saat pendaftaran tidak langsung digunakan, semua komunikasi berikut ke Intel PCS akan memerlukan Manifes Platform, yang tidak disediakan Azure ke komputer virtual (VM). Sebagai gantinya, VM harus menjangkau THIM untuk menerima sertifikat PCK. Untuk mengambil sertifikat PCK, Anda dapat menggunakan Intel QPL atau pustaka Azure DCAP.

Bagaimana cara menggunakan Intel QPL dengan Trusted Hardware Identity Management?

Pelanggan mungkin ingin fleksibilitas menggunakan Intel QPL untuk berinteraksi dengan Manajemen Identitas Perangkat Keras Tepercaya tanpa harus mengunduh dependensi lain dari Microsoft (yaitu, pustaka klien Azure DCAP). Pelanggan yang ingin menggunakan Intel QPL dengan layanan Manajemen Identitas Perangkat Keras Tepercaya harus menyesuaikan file konfigurasi Intel QPL, sgx_default_qcnl.conf.

Pembuatan kuotasi/jaminan verifikasi yang digunakan untuk menghasilkan kutipan Intel SGX atau Intel TDX dapat dibagi menjadi:

  • Sertifikat PCK. Untuk mengambilnya, pelanggan harus menggunakan titik akhir Manajemen Identitas Perangkat Keras Tepercaya.
  • Semua pembuatan kuotasi/jaminan verifikasi lainnya. Untuk mengambilnya, pelanggan dapat menggunakan titik akhir Manajemen Identitas Perangkat Keras Tepercaya atau titik akhir Intel Provisioning Certification Service (PCS).

File konfigurasi Intel QPL (sgx_default_qcnl.conf) berisi tiga kunci untuk menentukan titik akhir kolateral. Kunci pccs_url menentukan titik akhir yang digunakan untuk mengambil sertifikat PCK. Kunci collateral_service dapat menentukan titik akhir yang digunakan untuk mengambil semua pembuatan kuotasi/jaminan verifikasi lainnya. Jika kunci collateral_service tidak ditentukan, semua jaminan verifikasi kuotasi diambil dari titik akhir yang ditentukan dengan pccs_url kunci.

Tabel berikut ini memperlihatkan bagaimana kunci ini dapat diatur.

Nama Kemungkinan titik akhir
pccs_url Titik akhir Manajemen Identitas Perangkat Keras Tepercaya: https://global.acccache.azure.net/sgx/certification/v3.
collateral_service Titik akhir Manajemen Identitas Perangkat Keras Tepercaya (https://global.acccache.azure.net/sgx/certification/v3) atau titik akhir Intel PCS. File sgx_default_qcnl.conf selalu mencantumkan titik akhir terbaru di kunci collateral_service .

Cuplikan kode berikut berasal dari contoh file konfigurasi 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" 
                } 
            } 
        } 
    }

Prosedur berikut menjelaskan cara mengubah file konfigurasi Intel QPL dan mengaktifkan perubahan.

Di Windows

  1. Buat perubahan pada file konfigurasi.

  2. Pastikan bahwa ada izin baca ke file dari lokasi registri dan kunci/nilai berikut:

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

  3. Mulai ulang layanan AESMD. Misalnya, buka PowerShell sebagai administrator dan gunakan perintah berikut:

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

Di Linux

  1. Buat perubahan pada file konfigurasi. Misalnya, Anda dapat menggunakan Vim untuk perubahan melalui perintah berikut:

    sudo vim /etc/sgx_default_qcnl.conf

  2. Mulai ulang layanan AESMD. Buka terminal apa pun dan jalankan perintah berikut:

    sudo systemctl restart aesmd 
systemctl status aesmd

Bagaimana cara meminta jaminan di komputer virtual rahasia?

Gunakan sampel berikut dalam tamu komputer virtual rahasia (CVM) untuk meminta jaminan AMD yang mencakup sertifikat VCEK dan rantai sertifikat. Untuk detail tentang jaminan ini dan dari mana asalnya, lihat Sertifikat Kunci Dukungan Chip Versi (VCEK) dan Spesifikasi Antarmuka KDS.

Parameter URI

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

Isi permintaan

Nama Tipe Deskripsi
Metadata Boolean Pengaturan untuk True memungkinkan jaminan dikembalikan.

Permintaan sampel

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

Respons

Nama Deskripsi
200 OK Mencantumkan jaminan yang tersedia dalam isi HTTP dalam format JSON
Other Status Codes Menjelaskan mengapa operasi gagal

Definisi

Kunci Deskripsi
VcekCert Sertifikat X.509v3 seperti yang didefinisikan dalam RFC 5280
tcbm Basis komputasi tepercaya
certificateChain Sertifikat AMD SEV Key (ASK) dan AMD Root Key (ARK)

Bagaimana cara meminta jaminan AMD di Kontainer Azure Kubernetes Service pada simpul CVM?

Ikuti langkah-langkah ini untuk meminta jaminan AMD dalam kontainer rahasia:

  1. Mulailah dengan membuat kluster Azure Kubernetes Service (AKS) pada simpul CVM atau dengan menambahkan kumpulan simpul CVM ke kluster yang ada:

    • Buat kluster AKS pada simpul CVM:

      1. Buat grup sumber daya di salah satu wilayah yang didukung CVM:

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

      2. Buat kluster AKS dengan satu simpul CVM di grup sumber daya:

        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. Konfigurasikan kubectl untuk menyambungkan ke kluster:

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

    • Tambahkan kumpulan simpul CVM ke kluster AKS yang ada:

      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. Verifikasi koneksi ke kluster Anda dengan menggunakan kubectl get perintah . Perintah ini menampilkan daftar node kluster.

    kubectl get nodes

    Contoh output berikut menunjukkan simpul tunggal yang Anda buat di langkah-langkah sebelumnya. Pastikan bahwa status simpul adalah Ready.

    NAMA STATUS ROLES USIA VERSION
    aks-nodepool1-31718369-0 Siap agen 6m44s v1.12.8

  3. Buat file curl.yaml dengan konten berikut. Ini mendefinisikan pekerjaan yang menjalankan kontainer curl untuk mengambil jaminan AMD dari titik akhir Manajemen Identitas Perangkat Keras Tepercaya. Untuk informasi selengkapnya tentang Pekerjaan Kubernetes, lihat dokumentasi 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"

    File curl.yaml berisi argumen berikut.

    Nama Tipe Deskripsi
    Metadata Boolean Pengaturan untuk True memungkinkan jaminan dikembalikan.

  4. Jalankan pekerjaan dengan menerapkan file curl.yaml :

    kubectl apply -f curl.yaml

  5. Periksa dan tunggu pod menyelesaikan pekerjaannya:

    kubectl get pods

    Contoh respons adalah:

    Nama Siap Status Hidupkan ulang Usia
    Curl-w7nt8 0/1 Selesai 0 72 dtk

  6. Jalankan perintah berikut untuk mendapatkan log pekerjaan dan memvalidasi apakah berfungsi. Output yang berhasil harus mencakup vcekCert, tcbm, dan certificateChain.

    kubectl logs job/curl

Langkah berikutnya