Kanıtlama korumalı Güvenli Anahtar Sürümü ile Azure VM'lerde fikri mülkiyeti koruma

Bu makalede, başka birinin Azure aboneliğindeki bir sanal makinede (VM) çalışması gereken özel makine öğrenmesi modeli ağırlıkları, lisanslı veri kümesi veya gizli dizi yapılandırması gibi hassas bir varlığı korumaya yönelik yeniden kullanılabilir bir düzen açıklanmaktadır. Varlığa ( yayımcı) sahip olan taraf, VM'nin çalıştığı aboneliğin sahibi olan taraftan ( tüketici) farklıdır. Müşteri, söz konusu VM'ye Azure denetim düzleminde tam erişime sahiptir, ancak varlığı dışarı aktarabilmemelidir.

Desen, belgelenmiş birkaç Azure özelliğini savunma katmanları halinde birleştirir. Şifreleme çekirdeği, Trusted Launch vTPM kanıtlamasına bağlı Azure Key Vault Güvenli Anahtar Yayımıdır (SKR). Gizli Hesaplama gerektirmez ancak tehdit modeli bunu gerektirdiğinde, Gizli Hesaplama isteğe bağlı bir katman olarak eklenebilir.

Note

Güvenli Anahtar Yayımı, Azure Key Vault Premium ve Yönetilen HSM’nin veri düzlemi özelliğidir. İmzalı bir Microsoft Azure Doğrulama (MAA) belirtecini işlem türünden bağımsız olarak anahtarın yayın ilkesine göre doğrular. Gizli VM'ler bu belirteçlerin ortak bir kaynağıdır, ancak bunlar gerekli değildir; Güvenilen Başlatma VM'leri de MAA belirteçleri üretir. Belirteç gereksinimleri için bkz. Azure Key Vault güvenli anahtar yayımlama ilkesi dil bilgisi.

Senaryo ve tehdit modeli

Bir yayıncı, VM tabanlı bir iş yükünü bir tüketicinin aboneliğine dağıtır (örneğin, Azure Market üzerinden bir çözüm şablonu olarak veya paylaşılan bir imaj olarak). İş yükünün çalışma zamanında yayımcının varlığının kilidini açmak için bir şifre çözme anahtarına ihtiyacı vardır. Anahtar yalnızca yayımcının orijinal, değiştirilmemiş görüntüsünde yayınlanmalıdır; hiçbir zaman doğrudan tüketiciye sunulmamalı ve hiçbir zaman üzerinde oynanmış veya değiştirilen bir görüntüye sunulmamalıdır.

Desen iki ayrı tehdit yönüne karşı savunma sağlar. Katmanlama kararlarını net hale getiren, bunları açıkça adlandırmaktır.

Tehdit yönü Saldırgan Yetenekler Tarafından korunuyor
A — tüketici (VM/abonelik sahibi) Dağıtılan kaynaklar üzerinde tam Azure RBAC yetkilerine sahip abonelik sahibi az vm run-command, özel betik uzantıları, işletim sistemi diskinin anlık görüntüsünü alma ve değiştirme, seri konsol, IMDS aracılığıyla yönetilen kimlik belirtecinin çalınması—hepsi SSH olmadan Katmanlar 1-3
B — bulut hizmet sağlayıcısı (ana makine / hipervizör) VM belleğine ana bilgisayar düzeyinde erişimi olan bir operatör Vm dışından konuk belleği okuma Katman 4 (isteğe bağlı)

Tehdit yönü A, birincil tehdit ve mimariyi şekillendiren tehdittir. Temel düzende, tehdit yönü B açıkça kabul edilen bir risktir: platform güvenilirdir ve bulut sağlayıcısının hiper yöneticisine güvenmenin ortak duruşuyla eşleşir. Katman 4'ü yalnızca hipervizörün kendisine güvenilmemesi gerektiğinde ekleyin (örneğin, bellek şifrelemesini zorunlu kılan mevzuata tabi bir iş yükü).

Gizli Bilgi İşlem (Katman 4) ne zaman eklenir?

Gizli Bilgi İşlem bu desene alternatif değildir; üzerine eklediğiniz isteğe bağlı Katman 4'tür . Temel örüntü (Katmanlar 1–3) zaten anahtarın serbest bırakılmasını kanıtlamaya bağlar, varlığı tüketiciden korur ve standart maliyetle herhangi bir Gen2 Trusted Launch SKU’sunda çalışır. Gizli Bilgi İşlem eklemek düzenin çalışma şeklini değiştirmez: SKR, sağlamlaştırılmış görüntü ve ağ yalıtımı aynı kalır ve yayın akışı aynıdır. Tek farklar, sürüm ilkesinin vTPM ölçülen önyükleme talepleri yerine donanım-TEE taleplerine kapı açması ve iş yükünün gizli bir VM SKU'su üzerinde çalışmasıdır. Tehdit yönü B'ye (konak/hiper yönetici) karşı koruma elde eder ve premium maliyetle SKU, GPU ve bölge genişliğiyle işlem yapabilirsiniz.

Aşağıdaki tabloda Katman 4'in eklediği ve maliyeti gösterilmektedir; iki desen arasında seçim yapılmaz:

Consideration Temel desen (Katmanlar 1-3, Güvenilen Başlatma) Katman 4 eklendi (Gizli Bilgi İşlem)
Varlığı tüketiciden korur (tehdit A) Evet Evet (değişmedi)
Varlığı konaktan/hiper yöneticiden korur (tehdit B) Hayır (kabul edilen risk) Evet (bellek şifrelemesi)
Doğrulamaya koşullu anahtarın serbest bırakılması vTPM ölçümlü önyükleme beyanları Hardware-TEE iddiaları
GPU SKU kullanılabilirliği Tüm 2. Nesil SKU'lar Yalnızca gizli GPU SKU'ları ve kotaları ile sınırlıdır
Bölge ve SKU genişliği Geniş Daha Dar
Göreli maliyet Standart VM fiyatlandırması Premium

Temel desenle başlayın. Katman 4’ü yalnızca hipervizöre güvenmemeniz gerektiğinde ekleyin; örneğin, bellek şifrelemesini zorunlu kılan düzenlemelere tabi bir iş yükünde, daha sınırlı SKU, GPU ve bölge kullanılabilirliğini ve ek maliyeti kabul ederek.

Desenin öğeleri

Bu örüntü, bir derinlemesine savunma katmanıdır. Her katman belirli bir tehdit yönünü savunur: Katmanlar 1-3 tüketiciye karşı savunma (tehdit yönü A) ve isteğe bağlı Katman 4 konağa karşı savunma (tehdit yönü B). Korunan varlık çekirdekte yer alır ve yalnızca her kapalı katmandan erişilebilir.

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

Katmanlar, varlığı hem depolama durumundayken hem de kullanımdayken korur. Çalışma zamanında, tüketicinin sanal makinesi ile yayıncının güven çıpaları aşağıdaki şekilde etkileşime girer:

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

Katman 1: Kanıtlamaya Bağlı Güvenli Anahtar Serbest Bırakma (kriptografik geçit)

Bu katman temeldir. Güvenilen Başlatma sanal makinesi, Güvenli Önyükleme ve sanal TPM (vTPM) ile önyüklenir. vTPM önyükleme zincirini Platform Yapılandırma Kayıtlarında (PCR) ölçer ve tam olarak önyüklenenlerin şifreleme parmak izini oluşturur. Konuk, x-ms-azurevm-attested-pcr-values.pcr0 claim'i ve pcr7 ile secureboot arasındakiler gibi bu ölçümleri içeren bir MAA belirteci talep eder. Ardından Key Vault /release uç noktasını çağırır ve belirteci sunar. Key Vault belirtecin imzasını doğrular ve anahtarın yayın ilkesine göre değerlendirir. İlkenin talepleri eşleşiyorsa, Key Vault anahtarı vTPM'nin kısa ömürlü anahtarına sarmalanmış olarak serbest bırakır, böylece yalnızca bu doğrulanmış VM'nin anahtarı açabilmesini sağlar. Eşleşmiyorlarsa, yayınlama AccessDenied döndürür.

Neyi engeller (tehdit A): Kurcalanmış, yeniden görüntülenen veya diski değiştirilmiş bir VM, farklı PCR’leri ölçer ve anahtarı alamaz. Farklı bir VM'ye bağlanan işletim sistemi diskinin anlık görüntüsü de başarısız olur.

Güvenilen Başlatma VM'sine yönelik bir temsili sürüm ilkesi:

{
  "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>" }
      ]
    }
  ]
}

Katman 2: Sağlamlaştırılmış görüntü (şifresi çözülen varlığı koruyun)

Katman 1, anahtarın serbest bırakılıp bırakılmayacağını denetler; çalışan konukta şifresi çözüldükten sonra varlığı korumaz. Konuk içi ve denetim düzlemi saldırı yüzeyini azaltmak için imajı sağlamlaştırın: dosya sistemi bütünlüğü (örneğin dm-verity), salt okunur bir kök dosya sistemi, SSH daemon’unun bulunmaması, etkileşimli oturum açmanın devre dışı olması ve operatörün sağladığı komutları yürütebilecek konuk içi bir aracının bulunmaması.

Neyi engeller (tehdit A): Çalışmakta olan, tasdik edilmiş bir VM’nin konuk içinden istismar edilmesi — kötü amaçlı süreçler, ayrıcalık yükseltme ve şifresi çözülmüş varlığın işletim sistemi düzeyindeki bir güvenlik açığı aracılığıyla süreç belleğinden çıkarılması.

Katman 3: Ağ yalıtımı (yüzeyi küçültme)

VM'nin güven kökleri ve veriyle nasıl iletişim kuracağını kısıtlayın. Key Vault, depolama ve herhangi bir kayıt defteri için özel uç noktaları; kanıtlama sağlayıcısının özel yolu; özel DNS'yi kullanın ve gereksiz genel çıkışlar kullanmayın. Teslim mekanizmasının bunu desteklediği durumlarda - örneğin, yönetilen bir uygulamada - reddetme atamaları, müşterinin işlem kaynakları üzerindeki RBAC yetkilerini de kaldırarak denetim düzlemi saldırılarını (run-command, disk işlemleri, seri konsol, kimlik hırsızlığı) tamamen engelleyebilir. Çözüm şablonu teslim modelinde tüketici, dağıtılan kaynaklar üzerinde RBAC’yi elinde tutar; bu nedenle kontrol düzlemi sağlamlaştırması kullanılamaz. Bu durumda, Tehdit A’ya karşı savunmayı Katman 1 ve 2 sağlar: bir anlık görüntü ya da değiştirilmiş bir disk doğrulamayı geçemez (Katman 1) ve sağlamlaştırılmış görüntü (Katman 2), konuk işletim sistemi içinde şifresi çözülmüş varlığın çıkarılmasını engeller.

Neyi engeller (tehdit A): Hem kontrol düzlemi hem de veri düzlemi saldırılarına yönelik saldırı yüzeyini azaltır ve doğrulanan konuktan veri sızdırma yollarını engeller.

Katman 4 (isteğe bağlı): Gizli Bilgi İşlem (tehdit yönünü B'ye karşı korur)

Yukarıdaki her şey konağa güvenir. Hiper yöneticiye güvenemiyorsanız iş yükünü Gizli VM'de (AMD SEV-SNP veya Intel TDX) çalıştırın. Bellek şifrelemesi, ana sistemin konuk belleğini okumasını engeller ve SKR, sürüm ilkesinde vTPM ölçülü önyükleme taleplerinden donanım tabanlı TEE taleplerine geçer. Bu katman, tehdit yönü B'yi savunan tek katmandır. Varsayılan olarak kapalıdır çünkü SKU, GPU ve bölge kullanılabilirliğini daraltıp maliyet ekler.

Kiracılar arası kimlik

Yayımcı, güven köklerini — Key Vault'u (veya Managed HSM'yi) ve tasdik sağlayıcısını — tüketicinin RBAC kapsamı dışında, yayımcının tenant'ında barındırır. Doğrulanmış VM, tüketicinin kiracısında çalışır ve bu sınırı aşarak Key Vault’a çağrı yapması gerekir. İki platform kısıtlaması, belirgin yaklaşımları dışlar:

  • Yönetilen kimlik tam olarak bir kiracıda bulunur. Yayımcının kiracısı, tüketicinin kiracısında yer alan yönetilen kimliği tanımaz ve bu kimlik için belirteç düzenlemez.
  • Bir Azure RBAC rol ataması yalnızca kaynağın kendi kiracısındaki bir kimliğe atanabilir; bu nedenle tüketicinin yönetilen kimliğine yayımcının Key Vault’unda bir rol atayamazsınız.

Bir federe kimlik bilgisi (FIC) de aradaki boşluğu doğrudan kapatamaz: Entra ID, bir FIC’nin başka bir Entra kiracısı tarafından verilen belirteçlere güvenmesine izin vermez; bu nedenle yayımcıya ait bir uygulama, tüketicinin yönetilen kimliğini bu sınırın ötesine federe edemez.

İşe yarayan düzen, köprü kimliğini—bir çok kiracılı uygulamayı—tüketici tarafına yerleştirir:

  1. Tüketici, kendi kiracısında çok kiracılı bir uygulama kaydeder ve VM'nin yönetilen kimliğine güvenen aynı kiracıya ait bir FIC yapılandırır. Aynı kiracıdaki bir kimliğe güvenen bir FIC'ye izin verilir.
  2. Yayıncı, onun için bir hizmet sorumlusu oluşturarak ve bu sorumluya anahtar üzerinde Key Vault Crypto Service Release User rolünü atayarak bu uygulamayı kendi kiracısına dahil eder. Bu kasıtlı, her bir tüketici için gerçekleştirilen onboarding adımı, yayıncının harici bir aktöre kendi kiracı ortamına erişim izni verdiği noktadır.
  3. Çalışma zamanında VM'nin yönetilen kimliği IMDS'den bir belirteç alır, bunu çok kiracılı uygulama olarak kimlik doğrulamak için FIC aracılığıyla değiş tokuş eder ve istek gövdesinde MAA belirteciyle Key Vault'un /release uç noktasını çağırır.

Important

Kimlik değişimi güvenlik sınırı değildir. Tüketici, çok kiracılı uygulamanın kaydına sahip olduğundan, tüketici tarafı yöneticisi buna başka bir kimlik bilgisi (istemci gizli dizisi gibi) ekleyebilir ve bu akışı el ile yönlendirebilir; böylece kimlik katmanı yayımcıya saldırgan bir tüketiciye karşı güvence sağlamaz. Gerçek sınır SKR + kanıtlamadır (Katman 1): geçerli bir yayımcı-kiracı belirteci olsa bile, geçerli bir MAA belirteci sürüm ilkesini karşılamadığı ve yalnızca yayımcının orijinal, doğrulanmış görüntüsünün bir tane üretebildiği sürece Key Vault anahtarı yayınlamayı reddeder. Kimlik katmanı yalnızca isteği doğru kasaya yönlendirir.

Walkthrough

  1. Güven tutturucularını (yayımcı kiracısı) sağlayın. Key Vault Premium veya Yönetilen HSM oluşturun. Dışarı aktarılabilir bir RSA-HSM anahtarı oluşturun. MAA yetkilinizi ve Güvenilen Başlatma taleplerini (secureboot, seçilix-ms-azurevm-attested-pcr-values.pcrN) sabitleyen bir yayın ilkesi ekleyin.
  2. Beklenen PCR değerlerini belirleyin. İmajınızın iyi olduğu bilinen bir örneğini bir kez doğrulayın ve döndürülen MAA belirtecinden x-ms-azurevm-attested-pcr-values okuyun. Önyükleme zincirinizin ölçtüğü PCR’leri sabitleyin—genellikle pcr4 (önyükleme yükleyicisi/çekirdek) ve pcr7 (Güvenli Önyükleme durumu).
  3. İş yükünü (tüketici kiracısı) dağıtın. Sağlamlaştırılmış görüntüyü çalıştıran bir Güvenilen Başlatma (2. Nesil) VM'sini dağıtın. Ona bir yönetilen kimlik atayın ve bu kimliği, Kiracılar arası kimlik bölümünde açıklanan, yayımcının hizmet sorumlusuna anahtar üzerinde Key Vault Crypto Service Release User rolünü atadığı tüketiciye ait çok kiracılı uygulama ile federasyonlu hâle getirin.
  4. Çalışma zamanında doğrulama ve yayımlama. Konuk kullanıcı bir MAA belirteci alır, ardından POST /keys/{key-name}/release çağrısını yapar. Key Vault, sarmalanmış anahtarı doğrular ve döndürür; konuk, anahtarın sarmalını sanal makinenin içinde açar.
  5. Negatif durumu doğrulayın. Sürüm ilkesinde sabitlenmiş bir PCR değerini eşleşmeyen bir değerle değiştirin (veya değiştirilmiş bir imajla önyükleme yapın) ve serbest bırakma işleminin AccessDenied döndürdüğünü doğrulayın.

Çalıştırılabilir kod için İlgili içerikteki örneklere bakın.

İlgili içerik

  • Last updated on