Często zadawane pytania dotyczące zaświadczania platformy Microsoft Azure

Usługa Trusted Hardware Identity Management (THIM) pobiera punkt odniesienia zabezpieczeń platformy Azure dla węzłów azure Confidential computing (ACC) z firmy Intel i buforuje dane. Zaświadczanie platformy Azure używa również buforowanych informacji w weryfikowaniu zaufanych środowisk wykonywania (TEE).

ThiM jest zalecany z następujących powodów:

• Oferuje wysoką dostępność
• Zmniejsza zależności od usług hostowanych zewnętrznie i łączności z Internetem.
• Okresowo pobiera nowsze wersje certyfikatów firmy Intel, list CRL, informacji o zaufanej bazie obliczeniowej (TCB) i cytuje tożsamość enklawy węzłów ACC firmy Intel. Usługa potwierdza, że punkt odniesienia zabezpieczeń platformy Azure ma być odwoływalny przez zaświadczanie platformy Azure podczas weryfikowania tees, co znacznie zmniejsza liczbę niepowodzeń zaświadczania z powodu unieważnienia lub odwołania certyfikatów Intel.

L.p. Zaświadczenie platformy Azure zależy od punktu odniesienia zabezpieczeń określonego przez usługę Trusted Hardware Identity Management (THIM) w celu zweryfikowania tee. Funkcja THIM jest obecnie przeznaczona do obsługi tylko węzłów obliczeniowych poufnych platformy Azure.

Podczas procesu zaświadczania SGX zaświadczenie platformy Azure wykonuje następujące weryfikacje:

• Sprawdza, czy zaufany katalog główny podpisanego cudzysłowu enklawy należy do firmy Intel
• Sprawdza, czy cudzysłów TEE spełnia punkt odniesienia zabezpieczeń platformy Azure zdefiniowany przez usługę Trusted Hardware Identity Management (THIM)
• Jeśli klient utworzył dostawcę zaświadczania i skonfigurował zasady niestandardowe, oprócz powyższych weryfikacji, zaświadczenie platformy Azure ocenia ofertę TEE względem zasad zaświadczania. Klienci mogą używać zasad zaświadczania do definiowania reguł autoryzacji dla tee, a także dyktować reguły wystawiania na potrzeby generowania tokenu zaświadczania.

Ogólnie rzecz biorąc, w przypadku modeli zaświadczania z firmą Intel jako głównym elementem zaufania klient zaświadczania komunikuje się z interfejsami API enklawy w celu pobrania dowodów enklawy. Interfejsy API enklawy wewnętrznie nazywają usługę buforowania Intel PCK, aby pobrać certyfikaty Intel węzła do przetestowania. Certyfikaty są używane do podpisywania dowodów enklawy, co powoduje wygenerowanie zdalnie możliwego zabezpieczenia.

Ten sam proces można zaimplementować na potrzeby zaświadczania platformy Azure. Jednak aby czerpać korzyści oferowane przez zaufane zarządzanie tożsamościami sprzętowymi (THIM), po zainstalowaniu maszyny wirtualnej ACC zaleca się zainstalowanie biblioteki Azure DCAP. W oparciu o umowę z firmą Intel po zainstalowaniu biblioteki Azure DCAP żądania generowania dowodów enklawy są przekierowywane z usługi buforowania Intel PCK do thiM. Biblioteka Azure DCAP jest obsługiwana w środowiskach opartych na systemach Windows i Linux.

• Po zainstalowaniu maszyny wirtualnej Azure Confidential computing zainstaluj bibliotekę Azure DCAP (Windows/Linux), aby czerpać korzyści oferowane przez usługę Trusted Hardware Identity Management (THIM).
• Należy utworzyć klienta zaświadczania zdalnego, który może pobierać dowody enklawy i wysyłać żądania do zaświadczania platformy Azure. Zobacz przykłady kodu, aby uzyskać informacje.
• Żądania zaświadczania można wysyłać do punktu końcowego interfejsu API REST domyślnych dostawców lub niestandardowych dostawców zaświadczania.
• W wersji interfejsu API 2018-09-01-preview klient musi wysłać token dostępu Firmy Microsoft Entra wraz z dowodami do punktu końcowego interfejsu API zaświadczającego SGX. Token dostępu Firmy Microsoft Entra nie jest wymaganym parametrem do wykonania zaświadczania SGX w wersji interfejsu API 2020-10-01 .

Token zaświadczania generowany przez zaświadczenie platformy Azure jest podpisany przy użyciu certyfikatu z podpisem własnym. Certyfikaty podpisywania są ujawniane za pośrednictwem punktu końcowego metadanych OpenID. Jednostka uzależniona może pobrać certyfikaty podpisywania z tego punktu końcowego i przeprowadzić weryfikację podpisu tokenu zaświadczania. Certyfikat podpisywania zawiera również cytat SGX TEE, w którym działa zaświadczenie platformy Azure. Jeśli jednostka uzależniona woli również sprawdzić, czy zaświadczanie platformy Azure działa wewnątrz prawidłowej enklawy SGX, cudzysłów SGX można pobrać z certyfikatu podpisywania i lokalnie zweryfikowane. Aby uzyskać więcej informacji, zobacz przykłady kodu.

Czas ważności tokenu zaświadczania wynosi 8 godzin. Obecnie nie ma żadnej aprowizacji w celu dostosowania wartości.

Wiele certyfikatów uwidocznionych w punkcie końcowym metadanych OpenID odpowiada różnym przypadkom użycia (na przykład zaświadczeniu SGX) obsługiwanym przez zaświadczenie platformy Azure. Zgodnie ze standardami określonymi przez RFC 7515 certyfikat z identyfikatorem klucza (kid) zgodnym z parametrem kid w nagłówku tokenu zaświadczania ma być używany do weryfikacji podpisu. Jeśli nie znaleziono pasującego dziecka , należy wypróbować wszystkie certyfikaty uwidocznione przez punkt końcowy metadanych OpenID.

W momencie tworzenia dowodów TEE kod działający wewnątrz tee może zawierać dowolne informacje w dowodach. Na przykład teE może utworzyć jedną lub więcej par kluczy asymetrycznych, serializować składniki klucza publicznego tych par kluczy jako ciąg JWKS JSON i dołączyć ciąg JWKS JSON do dowodów TEE jako RunTimeData { cytat, ciąg JWKS JSON }. Zaświadczenie platformy Azure sprawdza, czy skrót SHA256 elementu RuntimeData jest zgodny z niższymi 32 bajtami atrybutu "dane raportu" oferty. Po ocenie dowodów TEE zaświadczenie platformy Azure generuje zestaw JWT z zestawem JWKS dostępnym jako oświadczenie o nazwie "keys" w ramach oświadczenia "x-ms-runtime". Funkcja RunTimeData może być dalej używana przez jednostkę uzależnioną w celu ustanowienia bezpiecznego kanału i bezpiecznego przesyłania danych do środowiska TEE.

Zaświadczenie platformy Azure przechowuje dane klienta magazynowane podczas przetwarzania i replikacji na potrzeby BCDR w lokalizacji geograficznej, w której klient wdraża wystąpienie usługi.