Dela via

Konfigurera attestering för Always Encrypted med azure-attestering

  • Artikel

Gäller för:Azure SQL Database

Microsoft Azure Attestation är en lösning för attestera betrodda körningsmiljöer (TEE), inklusive Intel Software Guard-tillägg (Intel SGX) enklaver.

Om du vill använda Azure Attestation för attestera Intel SGX-enklaver som används för Always Encrypted med säkra enklaver i Azure SQL Database måste du:

  1. Skapa en attesteringsprovider och konfigurera den med den rekommenderade attesteringsprincipen.

  2. Fastställa attesterings-URL:en och dela den med programadministratörer.

Viktigt!

Med Intel SGX-enklaver i Azure SQL Database är attestering obligatoriskt och kräver Microsoft Azure Attestation. VBS-enklaver i Azure SQL Database stöder inte attestering. Den här artikeln gäller endast Intel SGX-enklaver.

Kommentar

Att konfigurera attestering är attesteringsadministratörens ansvar. Se Roller och ansvarsområden när du konfigurerar Intel SGX-enklaver och attestering.

Skapa och konfigurera en attesteringsprovider

En attesteringsprovider är en resurs i Azure Attestation som utvärderar attesteringsbegäranden mot attesteringsprinciper och utfärdar attesteringstoken.

Attesteringsprinciper anges med hjälp av grammatiken för anspråksregeln.

Viktigt!

En attesteringsprovider skapas med standardprincipen för Intel SGX-enklaver, som inte verifierar koden som körs i enklaven. Microsoft rekommenderar starkt att du anger den rekommenderade principen som används i följande utdata och inte använder standardprincipen för Always Encrypted med säkra enklaver.

Microsoft rekommenderar följande princip för attestera Intel SGX-enklaver som används för Always Encrypted i Azure SQL Database:

version= 1.0;
authorizationrules 
{
       [ type=="x-ms-sgx-is-debuggable", value==false ]
        && [ type=="x-ms-sgx-product-id", value==4639 ]
        && [ type=="x-ms-sgx-svn", value>= 2 ]
        && [ type=="x-ms-sgx-mrsigner", value=="e31c9e505f37a58de09335075fc8591254313eb20bb1a27e5443cc450b6e33e5"] 
    => permit();
};

Principen verifierar:

  • Enklaven i Azure SQL Database stöder inte felsökning.

    Enklaver kan läsas in med felsökning inaktiverad eller aktiverad. Felsökningsstöd är utformat för att göra det möjligt för utvecklare att felsöka koden som körs i en enklav. I ett produktionssystem kan felsökning göra det möjligt för en administratör att undersöka innehållet i enklaven, vilket skulle minska den skyddsnivå som enklaven tillhandahåller. Den rekommenderade principen inaktiverar felsökning för att säkerställa att om en skadlig administratör försöker aktivera felsökningsstöd genom att ta över enklaverdatorn misslyckas attesteringen.

  • Produkt-ID:t för enklaven matchar produkt-ID:t som tilldelats Always Encrypted med säkra enklaver.

    Varje enklaver har ett unikt produkt-ID som skiljer enklaven från andra enklaver. Produkt-ID:t som tilldelats always encrypted-enklaven är 4639.

  • Bibliotekets säkerhetsversionsnummer (SVN) är större än eller lika med 2.

    Med SVN kan Microsoft svara på potentiella säkerhetsbuggar som identifieras i enklavens kod. Om ett säkerhetsproblem upptäcks och åtgärdas distribuerar Microsoft en ny version av enklaven med ett nytt (inkrementerat) SVN. Den rekommenderade principen uppdateras för att återspegla det nya SVN:t. Genom att uppdatera din princip så att den matchar den rekommenderade principen kan du se till att om en obehörig administratör försöker läsa in en äldre och osäker enklav misslyckas attesteringen.

  • Biblioteket i enklaven har signerats med hjälp av Microsoft-signeringsnyckeln (värdet för anspråket x-ms-sgx-mrsigner är hashen för signeringsnyckeln).

    Ett av huvudmålen med attestering är att övertyga klienter om att binärfilen som körs i enklaven är binärfilen som ska köras. Attesteringsprinciper tillhandahåller två mekanismer för detta ändamål. Den ena är mrenclave-anspråket , som är hashen för binärfilen som ska köras i en enklav. Problemet med mrenclave är att binär hash ändras även med triviala ändringar i koden, vilket gör det svårt att återkalla koden som körs i enklaven. Därför rekommenderar vi användning av mrsigner, som är en hash av en nyckel som används för att signera enklaven binär. När Microsoft återkallar enklaven förblir mrsigner densamma så länge signeringsnyckeln inte ändras. På så sätt blir det möjligt att distribuera uppdaterade binärfiler utan att bryta kundernas program.

Viktigt!

Microsoft kan behöva rotera nyckeln som används för att signera always encrypted-enklavens binärfil, vilket förväntas vara en sällsynt händelse. Innan en ny version av enklaverbinärfilen, signerad med en ny nyckel, distribueras till Azure SQL Database uppdateras den här artikeln för att tillhandahålla en ny rekommenderad attesteringsprincip och instruktioner om hur du ska uppdatera principen i dina attesteringsprovidrar för att säkerställa att dina program fortsätter att fungera oavbrutet.

Anvisningar för hur du skapar en attesteringsprovider och konfigurerar med en attesteringsprincip med hjälp av:

Fastställa attesterings-URL:en för din attesteringsprincip

När du har konfigurerat en attesteringsprincip måste du dela attesterings-URL:en med administratörer av program som använder Always Encrypted med säkra enklaver i Azure SQL Database. Attesterings-URL:en är för Attest URI attesteringsprovidern som innehåller attesteringsprincipen, som ser ut så här: https://MyAttestationProvider.wus.attest.azure.net.

Använda Azure-portalen för att fastställa attesterings-URL:en

I fönstret Översikt för attesteringsprovidern kopierar du värdet för Attest URI egenskapen till Urklipp.

Använda PowerShell för att fastställa attesterings-URL:en

Använd cmdleten Get-AzAttestation för att hämta egenskaperna för attesteringsprovidern, inklusive AttestURI.

Get-AzAttestation -Name $attestationProviderName -ResourceGroupName $attestationResourceGroupName

Mer information finns i Skapa och hantera en attesteringsprovider.

Nästa steg

Se även