Microsoft Azure Attestation

  • Artikel

Microsoft Azure Attestation är en enhetlig lösning för fjärrkontroll av tillförlitligheten hos en plattform och integritet för binärfiler som körs i den. Tjänsten stöder attestering av plattformar som backas upp av TPM:er (Trusted Platform Modules) tillsammans med möjligheten att intyga tillståndet för betrodda körningsmiljöer (TEE) som Intel® Software Guard Extensions (SGX)-enklaver, virtualiseringsbaserade säkerhets enklaver (VBS), betrodda plattformsmoduler (TPM), betrodd start för virtuella Azure-datorer och konfidentiella virtuella Azure-datorer.

Attestering är en process för att visa att binärfiler för programvara instansierades korrekt på en betrodd plattform. Fjärranslutna förlitande parter kan sedan få förtroende för att endast sådan avsedd programvara körs på betrodd maskinvara. Azure Attestation är en enhetlig kundinriktad tjänst och ramverk för attestering.

Azure Attestation möjliggör banbrytande säkerhetsparadigm som Azure Confidential Computing och Intelligent Edge-skydd. Kunder har begärt möjligheten att oberoende verifiera platsen för en dator, statusen för en virtuell dator (VM) på den datorn och miljön där enklaver körs på den virtuella datorn. Azure Attestation ger dessa och många ytterligare kundförfrågningar.

Azure Attestation tar emot bevis från beräkningsentiteter, omvandlar dem till en uppsättning anspråk, validerar dem mot konfigurerbara principer och genererar kryptografiska bevis för anspråksbaserade program (till exempel förlitande parter och granskningsmyndigheter).

Azure Attestation stöder både plattforms- och gästattestering av AMD SEV-SNP-baserade konfidentiella virtuella datorer (CVM). Azure Attestation-baserad plattformsattestering sker automatiskt under kritisk startsökväg för CVM:er, utan att någon kundåtgärd behövs. Mer information om gästattestering finns i Meddelande om allmän tillgänglighet för gästattestering för konfidentiella virtuella datorer.

Användningsfall

Azure Attestation tillhandahåller omfattande attesteringstjänster för flera miljöer och distinkta användningsfall.

SGX-enklaverattestering

Intel® Software Guard-tillägg (SGX) avser isolering i maskinvaruklass, som stöds på vissa Intel CPU-modeller. SGX gör att kod kan köras i sanerade fack som kallas SGX-enklaver. Åtkomst- och minnesbehörigheter hanteras sedan av maskinvara för att säkerställa en minimal attackyta med korrekt isolering.

Klientprogram kan utformas för att dra nytta av SGX-enklaver genom att delegera säkerhetskänsliga uppgifter som ska utföras i dessa enklaver. Sådana program kan sedan använda Azure Attestation för att rutinmässigt upprätta förtroende för enklaven och dess möjlighet att komma åt känsliga data.

Intel® Xeon® Scalable-processorer stöder endast ECDSA-baserade attesteringslösningar för fjärrattestering av SGX-enklaver. Med hjälp av ECDSA-baserad attesteringsmodell stöder Azure Attestation validering av Intel® Xeon® E3-processorer och Intel® Xeon-skalbara® processorbaserade serverplattformar.

Kommentar

För att utföra attestering av Intel® Xeon® Skalbara processorbaserade serverplattformar med Azure Attestation förväntas användarna installera Azure DCAP version 1.10.0 eller senare.

Öppna enklavattestering

Open Enclave (OE) är en samling bibliotek som syftar till att skapa en enda enhetlig abstraktion som utvecklare kan använda för att skapa TEE-baserade program. Den erbjuder en universell säker appmodell som minimerar plattformsspecifika egenskaper. Microsoft ser det som ett viktigt steg i riktning mot demokratisering av maskinvarubaserade enklavtekniker som SGX och ökad användning i Azure.

OE standardiserar specifika krav för verifiering av enklaver. Detta kvalificerar OE som en mycket passande attesteringskonsument av Azure Attestation.

TPM-attestering

TPM-baserad attestering (Trusted Platform Modules) är avgörande för att tillhandahålla bevis på en plattforms tillstånd. En TPM fungerar som roten för förtroende och säkerhetsprocessorn för att tillhandahålla kryptografisk giltighet för mätningarna (bevis). Enheter med en TPM kan förlita sig på attestering för att bevisa att startintegriteten inte komprometteras och använda anspråken för att identifiera aktivering av funktionstillstånd under start.

Klientprogram kan utformas för att dra nytta av TPM-attestering genom att delegera säkerhetskänsliga uppgifter till att endast ske efter att en plattform har verifierats vara säker. Sådana program kan sedan använda Azure Attestation för att rutinmässigt upprätta förtroende för plattformen och dess möjlighet att komma åt känsliga data.

AMD SEV-SNP-attestering

Azure Confidential VM (CVM) baseras på AMD-processorer med SEV-SNP-teknik. CVM erbjuder diskkrypteringsalternativ för virtuella datorer med plattformshanterade nycklar eller kundhanterade nycklar och binder diskkrypteringsnycklarna till den virtuella datorns TPM. När en CVM startar skickas SNP-rapporten som innehåller måtten för den inbyggda programvaran för den virtuella gästdatorn till Azure Attestation. Tjänsten validerar måtten och utfärdar en attesteringstoken som används för att frigöra nycklar från Managed-HSM eller Azure Key Vault. Dessa nycklar används för att dekryptera vTPM-tillståndet för den virtuella gästdatorn, låsa upp OS-disken och starta CVM. Attesterings- och nyckelfrisättningsprocessen utförs automatiskt på varje CVM-start, och processen säkerställer att CVM endast startar vid lyckad attestering av maskinvaran.

Betrott startattestering

Azure-kunder kan förhindra bootkit- och rootkit-infektioner genom att aktivera betrodd start för sina virtuella datorer . När den virtuella datorn är Säker start och vTPM aktiverat med gästattesteringstillägget installerat skickas vTPM-mått regelbundet till Azure Attestation för övervakning av startintegriteten. Ett attesteringsfel indikerar potentiell skadlig kod, som visas för kunder via Microsoft Defender för molnet, via aviseringar och Rekommendationer.

Azure Attestation körs i en TEE

Azure Attestation är avgörande för scenarier med konfidentiell databehandling eftersom det utför följande åtgärder:

  • Verifierar om enklavens bevis är giltiga.
  • Utvärderar enklavens bevis mot en kunddefinierad princip.
  • Hanterar och lagrar klientspecifika principer.
  • Genererar och signerar en token som används av förlitande parter för att interagera med enklaven.

För att hålla Microsoft borta från den betrodda databehandlingsbasen (TCB) flyttas viktiga åtgärder för Azure Attestation som citatverifiering, tokengenerering, principutvärdering och tokensignering till en SGX-enklav.

Varför använda Azure Attestation

Azure-attestering är det bästa valet för attestera TEE eftersom det ger följande fördelar:

  • Enhetligt ramverk för attestera flera miljöer, till exempel TPMs, SGX-enklaver och VBS-enklaver.
  • Gör det möjligt att skapa anpassade attesteringsprovidrar och konfiguration av principer för att begränsa tokengenerering.
  • Skyddar sina data vid användning med implementering i en SGX-enklav eller konfidentiell virtuell dator baserat på AMD SEV-SNP.
  • Tjänst med hög tillgänglighet

Så här upprättar du förtroende med Azure Attestation

  1. Kontrollera om attesteringstoken genereras av Azure Attestation – Attesteringstoken som genereras av Azure Attestation är signerad med ett självsignerat certifikat. URL:en för signeringscertifikat exponeras via en OpenID-metadataslutpunkt. Förlitande part kan hämta signeringscertifikatet och utföra signaturverifiering av attesteringstoken. Mer information finns i kodexempel
  2. Kontrollera om Azure Attestation körs i en SGX-enklav – Tokensigneringscertifikaten innehåller SGX-offert för tee där Azure Attestation körs. Om den förlitande parten föredrar att kontrollera om Azure Attestation körs i en giltig SGX-enklav kan SGX-offerten hämtas från signeringscertifikatet och verifieras lokalt. Mer information finns i kodexempel
  3. Verifiera bindningen av Azure Attestation SGX-citattecken med nyckeln som signerade attesteringstoken – förlitande part kan kontrollera om hash för den offentliga nyckeln som signerade attesteringstoken matchar rapportdatafältet i Azure Attestation SGX-offerten. Mer information finns i kodexempel
  4. Kontrollera om kodmätningar i Azure Attestation matchar de Publicerade Azure-värdena – SGX-offerten som är inbäddad i signeringscertifikat för attesteringstoken innehåller kodmätningar av Azure Attestation, till exempel MRSIGNER. Om den förlitande parten är intresserad av att verifiera om SGX-offerten tillhör Azure Attestation som körs i Azure kan MRSIGNER-värdet hämtas från SGX-offerten i signeringscertifikatet för attesteringstoken och jämföras med värdet som tillhandahålls av Azure Attestation-teamet. Om du är intresserad av att utföra den här valideringen skickar du en begäran på Azure-supportsidan. Azure Attestation-teamet kontaktar dig när vi planerar att rotera MRSIGNER.

Mrsigner för Azure Attestation förväntas ändras när kodsigneringscertifikat roteras. Azure Attestation-teamet följer distributionsschemat nedan för varje mrsigner-rotation:

i. Azure Attestation-teamet meddelar det kommande MRSIGNER-värdet med en respitperiod på två månader för att göra relevanta kodändringar

ii. Efter respitperioden på två månader börjar Azure Attestation använda det nya MRSIGNER-värdet

iii. Tre månader efter aviseringsdatumet slutar Azure Attestation använda det gamla MRSIGNER-värdet

Stöd för affärskontinuitet och haveriberedskap (BCDR)

Med BCDR (Business Continuity and Disaster Recovery ) för Azure Attestation kan du minimera tjänststörningar till följd av betydande tillgänglighetsproblem eller katastrofhändelser i en region.

Kluster som distribueras i två regioner fungerar oberoende av varandra under normala omständigheter. Vid fel eller avbrott i en region sker följande:

  • Azure Attestation BCDR ger sömlös redundans där kunderna inte behöver ta några extra steg för att återställa.
  • Azure Traffic Manager för regionen identifierar att hälsoavsökningen är degraderad och växlar slutpunkten till en länkad region.
  • Befintliga anslutningar fungerar inte och får interna serverfel eller tidsgränsproblem.
  • Alla kontrollplansåtgärder kommer att blockeras. Kunder kommer inte att kunna skapa attesteringsproviders i den primära regionen.
  • Alla dataplansåtgärder, inklusive attesteringsanrop och principkonfiguration, hanteras av en sekundär region. Kunder kan fortsätta att arbeta med dataplansåtgärder med den ursprungliga URI:n som motsvarar den primära regionen.

Nästa steg