Dela via

Always Encrypted med säkra enklaver

  • Artikel

gäller för: SQL Server 2019 (15.x) och senare – Windows endast Azure SQL Database

Always Encrypted med säkra enklaver utökar de konfidentiella databehandlingsfunktionerna i Always Encrypted genom att möjliggöra kryptering på plats och rikare konfidentiella sökfrågor. Always Encrypted med säkra enklaver finns i SQL Server 2019 (15.x) och senare, samt i Azure SQL Database.

Always Encrypted introducerades i Azure SQL Database 2015 och i SQL Server 2016 (13.x) och skyddar sekretessen för känsliga data från skadlig kod och högprivilegierade obehöriga användare: Databasadministratörer (DBA), datoradministratörer, molnadministratörer eller någon annan som har legitima åtkomst till serverinstanser, maskinvara osv., men som inte bör ha åtkomst till vissa eller alla faktiska data.

Utan de förbättringar som beskrivs i den här artikeln skyddar Always Encrypted data genom att kryptera dem på klientsidan och aldrig att tillåta att data eller motsvarande kryptografiska nycklar visas i klartext i databasmotorn. Därför är funktionerna i krypterade kolumner i databasen kraftigt begränsade. De enda åtgärder som databasmotorn kan utföra på krypterade data är likhetsjämförelser (endast tillgängliga med deterministisk kryptering). Alla andra åtgärder, inklusive kryptografiska åtgärder (inledande datakryptering eller nyckelrotation) och mer omfattande frågor (till exempel mönstermatchning) stöds inte i databasen. Användarna måste flytta sina data utanför databasen för att utföra dessa åtgärder på klientsidan.

Always Encrypted med säkra enklaver åtgärdar dessa begränsningar genom att tillåta vissa beräkningar på klartextdata inom en säker enklav på serversidan. En säker enklav är en skyddad minnesregion i databasmotorprocessen. Den säkra enklaven visas som en ogenomskinlig ruta för resten av databasmotorn och andra processer på värddatorn. Det finns inget sätt att visa data eller kod i enklaven utifrån, inte ens med ett felsökningsprogram. Dessa egenskaper gör den säkra enklaven till en betrodd körningsmiljö som på ett säkert sätt kan komma åt kryptografiska nycklar och känsliga data i klartext, utan att äventyra datasekretessen.

Always Encrypted använder säkra enklaver enligt följande diagram:

Ett diagram över dataflödet för Always Encrypted.

När du parsar en Transact-SQL-instruktion som skickas av ett program avgör databasmotorn om -instruktionen innehåller några åtgärder på krypterade data som kräver användning av den säkra enklaven. För sådana påståenden:

  • Klientdrivrutinen skickar de kolumnkrypteringsnycklar som krävs för åtgärderna till den säkra enklaven (via en säker kanal) och skickar instruktionen för körning.

  • Vid bearbetning av instruktionen delegerar databasmotorn kryptografiska åtgärder eller beräkningar på krypterade kolumner till den säkra enklaven. Om det behövs dekrypterar enklaven data och utför beräkningar i klartext.

Under instruktionsbearbetningen exponeras inte både data och kolumnkrypteringsnycklarna i klartext i databasmotorn utanför den säkra enklaven.

Klientdrivrutiner som stöds

Om du vill använda Always Encrypted med säkra enklaver måste ett program använda en klientdrivrutin som stöder funktionen. Konfigurera programmet och klientdrivrutinen för att aktivera enklaverberäkningar och enklavattestering (se avsnittet Secure enclave attestation nedan). Mer information, inklusive listan över klientdrivrutiner som stöds, finns i Utveckla program med Always Encrypted.

Stödda enclave-teknologier

Always Encrypted stöder följande enklavteknologier (eller typer av enklaver):

Vilken typ av enklaver som är tillgänglig för databasen beror på vilken SQL-produkt som är värd för den (Azure SQL Database vs. SQL Server) och (när det gäller Azure SQL Database) konfigurationen av databasen.

  • I SQL Server 2019 (15.x) och senare stöder Always Encrypted VBS-enklaver. (Intel SGX-enklaver stöds inte.)

  • I Azure SQL Database kan en databas använda antingen en Intel SGX-enklav eller en VBS-enklav, beroende på vilken maskinvara databasen är konfigurerad för att köras på:

    • Databaser som använder DC-serien maskinvarukonfiguration (tillgänglig med köpmodellen vCore) använder Intel SGX-enklaver.
    • Databaser som använder en annan konfiguration än DC-serien med köpmodellen för virtuella kärnor och databaser med hjälp av DTU-inköpsmodell kan konfigureras för att använda VBS-enklaver.

    Not

    VBS-enklaver är för närvarande tillgängliga i alla Azure SQL Database-regioner förutom: Jio India Central.

I avsnittet Säkerhetsöverväganden finns viktig information om det nivåskydd som varje enklavtyp tillhandahåller.

Säkerhetsenklavsattestering

Enklaverattestering är en djupskyddsmekanism som kan hjälpa till att identifiera attacker som inbegriper manipulering av enklavens kod eller dess miljö av skadliga administratörer.

Enklaverattestering gör det möjligt för ett klientprogram att upprätta förtroende med den säkra enklaven för databasen, programmet är anslutet till innan appen använder enklaven för bearbetning av känsliga data. Attesteringsarbetsflödet verifierar att enklaven är en äkta VBS- eller Intel SGX-enklav och koden som körs inuti den är det äkta Microsoft-signerade enklavens bibliotek för Always Encrypted. Under attesteringen kommunicerar både klientdrivrutinen i programmet och databasmotorn med en extern attesteringstjänst med hjälp av en klient angiven slutpunkt.

Always Encrypted kan använda någon av de två attesteringstjänsterna:

Om du vill aktivera Always Encrypted med säkra enklaver för ditt program måste du ange ett attesteringsprotokoll i konfigurationen av klientdrivrutinen i ditt program. Ett attesteringsprotokollvärde avgör om 1) klientappen ska använda attestering, och i så fall 2) anger den typ av attesteringstjänst som ska användas. Tabellen nedan innehåller de attesteringsprotokoll som stöds för de giltiga kombinationerna av SQL-produkter och enklaver:

Hostingprodukt Typ av enklav Attesteringsprotokoll som stöds
SQL Server 2019 (15.x) och senare VBS-enklaver HGS, ingen attestering
Azure SQL Database SGX-enklaver (databaser i DC-serien) Microsoft Azure attestering
Azure SQL Database VBS-enklaver Ingen attestering

Några viktiga punkter att ta upp:

  • Attestering av VBS-enklaver i SQL Server 2019 (15.x) och senare kräver HGS. Du kan också använda VBS-enklaver utan attestering (de senaste klientdrivrutinerna krävs).
  • Med Intel SGX-enklaver (i DC-seriens databaser) i Azure SQL Database är attestering obligatoriskt och kräver Microsoft Azure-attestering.
  • VBS-enklaver i Azure SQL Database stöder inte attestering.

Mer information finns i:

Terminologi

Enklaveraktiverade nycklar

Always Encrypted med säkra enklaver introducerar begreppet enklaveraktiverade nycklar:

  • Enklavaktiverad kolumnhuvudnyckel – en kolumn master nyckel som har egenskapen ENCLAVE_COMPUTATIONS som anges i kolumnen master nyckelmetadataobjekt i databasen. Kolumnen master nyckelmetadataobjekt måste också innehålla en giltig signatur för metadataegenskaperna. Mer information finns i CREATE COLUMN MASTER KEY (Transact-SQL)
  • Enklavaktiverad kolumnkrypteringsnyckel – en kolumnkrypteringsnyckel som krypteras med en enklavaktiverad kolumn master nyckel. Endast enklaveraktiverade kolumnkrypteringsnycklar kan användas för beräkningar i den säkra enklaven.

För mer information, se Hantera nycklar för Always Encrypted med säkra enklaver.

Enklaveraktiverade kolumner

En enklavaktiverad kolumn är en databaskolumn krypterad med en enklavaktiverad kolumnkrypteringsnyckel.

Funktioner för konfidentiell databehandling för enklaveraktiverade kolumner

De två viktigaste fördelarna med Always Encrypted med säkra enklaver är kryptering på plats och omfattande konfidentiella frågor.

Kryptering på plats

Kryptering på plats tillåter kryptografiska åtgärder på databaskolumner i den säkra enklaven, utan att flytta data utanför databasen. Kryptering på plats förbättrar prestanda och tillförlitlighet för kryptografiska åtgärder. Du kan utföra kryptering på plats med hjälp av instruktionen ALTER TABLE (Transact-SQL).

De kryptografiska åtgärder som stöds på plats är:

  • Kryptera en klartextkolumn med en enklavaktiverad kolumnkrypteringsnyckel.
  • Kryptera om en krypterad enklavaktiverad kolumn för att:
    • Rotera en kolumnkrypteringsnyckel – kryptera om kolumnen med en ny enklavaktiverad kolumnkrypteringsnyckel.
    • Ändra krypteringstypen för en enklavaktiverad kolumn, till exempel från deterministisk till randomiserad.
  • Dekryptera data som lagras i en kolumn med aktiverad enklav (konvertera kolumnen till en klartextkolumn).

Kryptering på plats tillåts med både deterministisk och randomiserad kryptering, så länge kolumnkrypteringsnycklarna som ingår i en kryptografisk åtgärd är enklaveraktiverade.

Konfidentiella frågor

Not

SQL Server 2022 (16.x) lägger till ytterligare stöd för konfidentiella frågor med ÅTGÄRDERNA JOIN, GROUP BY och ORDER BY på krypterade kolumner.

Konfidentiella sökfrågor är DML-sökfrågor som omfattar åtgärder på kolumner med enklavstöd som utförs i den säkra enklaven.

De åtgärder som stöds i de säkra enklaver är:

Verksamhet Azure SQL Database SQL Server 2022 (16.x) SQL Server 2019 (15.x)
jämförelseoperatorer Stödd Understödd Stödd
BETWEEN (Transact-SQL) Understödd Stödd Stödd
IN (Transact-SQL) Stödd Stöttad Stödd
LIKE (Transact-SQL) Stödd Stödd Understödd
DISTINKT Understödd Supporterad Stödd
ansluter Understödd Stödd Endast kapslade loopkopplingar stöds
SELECT – ORDER BY Clause (Transact-SQL) Stödd Stödd Stöds inte
SELECT – GRUPPERA EFTER – Transact-SQL- Stödd Stödd Stöds inte

Anteckning

Ovanstående åtgärder i säkra enklaver kräver randomiserad kryptering. Deterministisk kryptering stöds inte. Likhetsjämförelse förblir den åtgärd som är tillgänglig för kolumner med deterministisk kryptering.

Den kompatibilitetsnivån för databasen ska anges till SQL Server 2022 (160) eller senare.

I Azure SQL Database och i SQL Server 2022 (16.x) kräver konfidentiella frågor med enklaver i en teckensträngskolumn (char, nchar) att kolumnen använder en binärkodpunktssortering (_BIN2) eller en UTF-8-sortering. I SQL Server 2019 (15.x) krävs a_BIN2 sortering.

Mer information finns i Kör instruktioner Transact-SQL med säkra enklaver.

Index för enklaveraktiverade kolumner

Du kan skapa icke-klustrade index på enklaveraktiverade kolumner med hjälp av randomiserad kryptering för att snabba upp konfidentiella DML-frågor med hjälp av den säkra enklaven.

För att säkerställa att ett index i en kolumn som krypteras med randomiserad kryptering inte läcker känsliga data krypteras och sorteras nyckelvärdena i indexdatastrukturen (B-träd) baserat på deras oformaterade värden. Sortering efter klartextvärde är också användbart för bearbetning av frågor i enklaven. När frågeexekutor i databasmotorn använder ett index i en krypterad kolumn för beräkningar i enklaven, söker den igenom indexet för att söka efter specifika värden som lagras i kolumnen. Varje sökning kan omfatta flera jämförelser. Frågeexekutor delegerar varje jämförelse till enklaven, som dekrypterar ett värde som lagras i kolumnen och det krypterade indexnyckelvärdet som ska jämföras, den utför jämförelsen i klartext och returnerar resultatet av jämförelsen med utföraren.

Det går inte att skapa index för kolumner som använder randomiserad kryptering och inte är enklaveraktiverade.

Ett index i en kolumn med deterministisk kryptering sorteras baserat på chiffertext (inte klartext), oavsett om kolumnen är enklavaktiverad eller inte.

Mer information finns i Skapa och använda index för kolumner med Always Encrypted med säkra enklaver. Allmän information om hur indexering i databasmotorn fungerar finns i artikeln Beskrivning av klustrade och icke-klustrade index.

Databasåterställning

Om en instans av SQL Server misslyckas kan dess databaser lämnas i ett tillstånd där datafilerna kan innehålla vissa ändringar från ofullständiga transaktioner. När instansen startas körs en process som kallas databasåterställning, vilket innebär att alla ofullständiga transaktioner som hittas i transaktionsloggen återställs för att säkerställa att databasens integritet bevaras. Om en ofullständig transaktion har gjort några ändringar i ett index måste dessa ändringar också ångras. Vissa nyckelvärden i indexet kan till exempel behöva tas bort eller sättas i igen.

Viktig

Microsoft rekommenderar starkt att du aktiverar accelererad databasåterställning (ADR) för din databas, innan du skapar det första indexet på en enklavaktiverad kolumn krypterad med randomiserad kryptering. ADR är aktiverat som standard i Azure SQL Database och Azure SQL Managed Instance. ADR är tillgängligt men inte aktiverat som standard i SQL Server 2019 (15.x) och senare.

Med den traditionella databasåterställningsprocessen (som följer ARIES- återställningsmodell) måste databasmotorn vänta tills ett program tillhandahåller kolumnkrypteringsnyckeln för kolumnen till enklaven, vilket kan ta lång tid. Accelererad databasåterställning (ADR) minskar dramatiskt antalet ångrade åtgärder som måste skjutas upp eftersom en kolumnkrypteringsnyckel inte är tillgänglig i cachen i enklaven. Därför ökar databasens tillgänglighet avsevärt genom att minimera risken för att en ny transaktion blockeras. Med ADR aktiverat kan databasmotorn fortfarande behöva en kolumnkrypteringsnyckel för att slutföra rensningen av gamla dataversioner, men det gör den som en bakgrundsaktivitet som inte påverkar tillgängligheten för databasen eller användartransaktionerna. Du kan se felmeddelanden i felloggen som anger misslyckade rensningsåtgärder på grund av att en kolumnkrypteringsnyckel saknas.

Säkerhetshänsyn

Följande säkerhetsaspekter gäller Always Encrypted med säkra enklaver.

  • VBS-enklaver hjälper till att skydda dina data från attacker i den virtuella datorn. De ger dock inget skydd mot attacker med privilegierade systemkonton som kommer från värden. Intel SGX-enklaver skyddar data från attacker från både gästoperativsystemet och värdoperativsystemet.
  • Användning av enklaverattestering rekommenderas om det är tillgängligt för din miljö och om du är orolig för att skydda dina data från attacker från användare med administratörsåtkomst på operativsystemnivå till den dator som är värd för din databas. Om du använder attestering måste du se till att attesteringstjänsten och dess konfiguration hanteras av en betrodd administratör. Dessutom erbjuder både stödda attesteringstjänster olika principer och attesteringslägen, varav vissa utför minimal verifiering av enklaven och dess miljö, och är utformade för testning och utveckling. Följ noga riktlinjerna som är specifika för din attesteringstjänst för att säkerställa att du använder de rekommenderade konfigurationerna och principerna för dina produktionsdistributioner.
  • Kryptering av en kolumn med randomiserad kryptering med en enklavaktiverad kolumnkrypteringsnyckel kan leda till att dataordningen som lagras i kolumnen läcker, eftersom sådana kolumner stöder intervalljämförelser. Om till exempel en krypterad kolumn, som innehåller anställdas löner, har ett index, kan en skadlig DBA skanna indexet för att hitta det maximala krypterade lönevärdet och identifiera en person med den maximala lönen (förutsatt att namnet på personen inte är krypterat).
  • Om du använder Always Encrypted för att skydda känsliga data från obehörig åtkomst från databasadministratörer ska du inte dela kolumnen master nycklar eller kolumnkrypteringsnycklar med databasadministratörerna. En DBA kan hantera index på krypterade kolumner utan direkt åtkomst till nycklarna med hjälp av cachen för kolumnkrypteringsnycklar i enklaven.

Överväganden för affärskontinuitet, haveriberedskap och datamigrering

När du konfigurerar en lösning för hög tillgänglighet eller haveriberedskap för en databas med Always Encrypted med säkra enklaver kontrollerar du att alla databasrepliker kan använda en säker enklav. Om en enklav är tillgänglig för den primära repliken, men inte för den sekundära repliken, kommer alla instruktioner som försöker använda funktionen Always Encrypted med säkra enklaver att misslyckas efter övergången.

När du kopierar eller migrerar en databas med Always Encrypted med säkra enklaver kontrollerar du att målmiljön alltid stöder enklaver. Annars fungerar inte instruktioner som använder enklaver på kopian eller den migrerade databasen.

Här är de specifika överväganden som du bör tänka på:

  • SQL Server

    • När du konfigurerar en AlwaysOn-tillgänglighetsgruppkontrollerar du att varje SQL Server-instans som är värd för en databas i tillgänglighetsgruppen stöder Always Encrypted med säkra enklaver och har en enklav och attestering konfigurerad.
    • När du återställer från en säkerhetskopia av en databas som använder funktionen Always Encrypted med säkra enklaver på en SQL Server-instans som inte har enklaven konfigurerad, kommer återställningsåtgärden att lyckas och alla funktioner som inte förlitar sig på enklaven kommer att vara tillgängliga. Dock misslyckas alla efterföljande instruktioner som använder enklaverfunktionen och index på enklaveraktiverade kolumner med randomiserad kryptering blir ogiltiga. Detsamma gäller när du kopplar en databas med Always Encrypted med säkra enklaver på den instans som inte har enklaven konfigurerad.
    • Om databasen innehåller index för enklaveraktiverade kolumner med randomiserad kryptering måste du aktivera accelererad databasåterställning (ADR) i databasen innan du skapar en databassäkerhetskopia. ADR ser till att databasen, inklusive indexen, är tillgänglig omedelbart efter att du har återställt databasen. Mer information finns i Database Recovery.

  • Azure SQL Database

    • När du konfigurerar aktiv geo-replikeringkontrollerar du att en sekundär databas stöder säkra enklaver, om den primära databasen gör det.

När du migrerar databasen med en bacpac-fil i både SQL Server och Azure SQL Database måste du se till att du släpper alla index för enklaveraktiverade kolumner med randomiserad kryptering innan du skapar bacpac-filen.

Kända begränsningar

Always Encrypted med säkra enklaver hanterar vissa begränsningar i Always Encrypted genom att stödja kryptering på plats och mer avancerade konfidentiella sökningar med index, enligt beskrivningen i Funktioner för konfidentiell databehandling för enklaveraktiverade kolumner.

Alla andra begränsningar för Always Encrypted som anges i Begränsningar gäller även för Always Encrypted med säkra enklaver.

Följande begränsningar är specifika för Always Encrypted med säkra enklaver:

  • Klustrade index kan inte skapas på enklaveraktiverade kolumner med hjälp av randomiserad kryptering.
  • Enklaveraktiverade kolumner med randomiserad kryptering kan inte vara primärnyckelkolumner och kan inte refereras till av begränsningar för sekundärnyckel eller unika nyckelbegränsningar.
  • I SQL Server 2019 (15.x) (den här begränsningen gäller inte för Azure SQL Database eller SQL Server 2022 (16.x)) stöds endast kapslade loopkopplingar (med hjälp av index, om tillgängligt) på enklaveraktiverade kolumner med randomiserad kryptering. Information om andra skillnader mellan olika produkter finns i Konfidentiella frågor.
  • Kryptografiska operationer på plats kan inte kombineras med andra ändringar av kolumnmetadata, förutom att ändra en sortering inom samma kodsida och nullbarhet. Du kan till exempel inte kryptera, kryptera om eller dekryptera en kolumn OCH ändra en datatyp för kolumnen i en enda ALTER TABLE/ALTER COLUMN Transact-SQL-instruktion. Använd två separata uttalanden.
  • Det går inte att använda enklaveraktiverade nycklar för kolumner i minnesinterna tabeller.
  • Uttryck som definierar beräknade kolumner kan inte utföra några beräkningar på enklaveraktiverade kolumner med hjälp av randomiserad kryptering (även om beräkningarna är bland de åtgärder som stöds i Konfidentiella frågor).
  • Escape-tecken stöds inte i parametrarna för LIKE-operatorn på kolumner som är aktiverade för enklaver och använder randomiserad kryptering.
  • Frågor med LIKE-operatorn eller en jämförelseoperator som har en frågeparameter med någon av följande datatyper (som blir stora objekt efter kryptering) ignorerar index och utför tabellgenomsökningar.
    • nchar[n] och nvarchar[n], om n är större än 3967.
    • char[n], varchar[n], binary[n], varbinary[n], om n är större än 7935.
  • Verktygsbegränsningar:
    • De enda nyckellager som stöds för lagring av kolumnnycklar master med enklav-stöd är Windows Certificate Store och Azure Key Vault.
    • Om du vill utlösa en kryptografisk åtgärd på plats via ALTER TABLE/ALTER COLUMNmåste du utfärda -instruktionen med hjälp av ett frågefönster i SSMS eller Azure Data Studio, eller så kan du skriva ett eget program som utfärdar -instruktionen. För närvarande stöder inte Set-SqlColumnEncryption-cmdleten i SqlServer PowerShell-modulen och guiden Always Encrypted i SQL Server Management Studio kryptering på plats. Flytta data från databasen för kryptografiska åtgärder, även om kolumnkrypteringsnycklarna som används för åtgärderna är enklaveraktiverade.
  • När du återställer en VBS-enklavaktiverad databas är det viktigt att konfigurera om inställningen för VBS-enklaver igen.

Relaterat innehåll