Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
              gäller för:SQL Server
Azure SQL Database
Azure SQL Managed Instance
Azure Synapse Analytics
Analytics Platform System (PDW)
Transparent datakryptering (TDE) krypterar SQL Server-, Azure SQL Database- och Azure Synapse Analytics-datafiler. Den här krypteringen kallas kryptering av vilande data.
För att skydda en användardatabas kan du vidta försiktighetsåtgärder som:
- Utforma ett säkert system.
- Kryptera konfidentiella tillgångar.
- Skapa en brandvägg runt databasservrarna.
En illasinnad part som stjäl fysiska medier som enheter eller säkerhetskopieringsband kan dock återställa eller bifoga databasen och bläddra bland dess data.
En lösning är att kryptera känsliga data i en databas och använda ett certifikat för att skydda de nycklar som krypterar data. Den här lösningen hindrar alla utan nycklar från att använda data. Men du måste planera den här typen av skydd i förväg.
TDE utför I/O-kryptering i realtid och dekryptering av data och loggfiler. Krypteringen använder en databaskrypteringsnyckel (DEK). Databasens startpost lagrar nyckeln för tillgänglighet under återställningen. DEK är en symmetrisk nyckel och skyddas av ett certifikat som serverns master databas lagrar eller av en asymmetrisk nyckel som en EKM-modul skyddar.
TDE skyddar vilande data, vilket är data och loggfiler. Det gör att du kan följa många lagar, förordningar och riktlinjer som fastställts i olika branscher. Med den här möjligheten kan programutvecklare kryptera data med hjälp av AES- och 3DES-krypteringsalgoritmer utan att ändra befintliga program.
Anmärkning
TDE är inte tillgängligt för systemdatabaser. Det kan inte användas för att kryptera master, modeleller msdb. 
              tempdb krypteras automatiskt när en användardatabas aktiverat TDE, men kan inte krypteras direkt.
TDE tillhandahåller inte kryptering i kommunikationskanaler. Mer information om hur du krypterar data mellan kommunikationskanaler finns i Kryptera anslutningar till SQL Server genom att importera ett certifikat.
Relaterade ämnen:
- Transparent datakryptering för SQL Database, SQL Managed Instance och Azure Synapse Analytics
- Kom igång med transparent datakryptering (TDE) i Azure Synapse Analytics
- Flytta en TDE-skyddad databas till en annan SQL Server
- Aktivera TDE på SQL Server med HJÄLP av EKM
- Använda SQL Server Connector med SQL-krypteringsfunktioner
- SQL Server-säkerhetsbloggen på TDE med vanliga frågor och svar
Om TDE
Kryptering av en databasfil görs på sidnivå. Sidorna i en krypterad databas krypteras innan de skrivs till disken och dekrypteras när de läse in i minnet. TDE ökar inte storleken på den krypterade databasen.
Information som gäller för SQL Database
När du använder TDE med Azure SQL Database skapar SQL Database automatiskt certifikatet på servernivå som lagras i master databasen. Om du vill flytta en TDE-databas i SQL Database behöver du inte dekryptera databasen för flyttåtgärden. Mer information om hur du använder TDE med SQL Database finns i transparent datakryptering med Azure SQL Database.
Information som gäller för SQL Server
När du har skyddat en databas kan du återställa den med rätt certifikat. Mer information om certifikat finns i SQL Server-certifikat och asymmetriska nycklar.
När du har aktiverat TDE säkerhetskopierar du omedelbart certifikatet och dess associerade privata nyckel. Om certifikatet blir otillgängligt, eller om du återställer eller kopplar databasen på en annan server, behöver du säkerhetskopior av certifikatet och den privata nyckeln. Annars kan du inte öppna databasen. Certifikat som lagras i en innesluten systemdatabas bör också säkerhetskopieras.
Behåll krypteringscertifikatet även om du har inaktiverat TDE i databasen. Även om databasen inte är krypterad kan delar av transaktionsloggen förbli skyddade. Du kan också behöva certifikatet för vissa åtgärder tills du gör en fullständig säkerhetskopia av databasen.
Du kan fortfarande använda ett certifikat som överskrider utgångsdatumet för att kryptera och dekryptera data med TDE.
Krypteringshierarki
Windows Data Protection API (DPAPI) finns i roten av krypteringsträdet, skyddar nyckelhierarkin på datornivå och används för att skydda tjänstens huvudnyckel (SMK) för databasserverinstansen. SMK skyddar databashuvudnyckeln (DMK), som lagras på användardatabasnivå och skyddar certifikat och asymmetriska nycklar. Dessa nycklar skyddar i sin tur symmetriska nycklar som skyddar data. TDE använder en liknande hierarki ned till certifikatet. När du använder TDE måste DMK och certifikat lagras i master databasen. En ny nyckel, som endast används för TDE och kallas för databaskrypteringsnyckeln (DEK), skapas och lagras i användardatabasen.
Följande bild visar arkitekturen för TDE-kryptering. Endast objekt på databasnivå (databaskrypteringsnyckeln och ALTER DATABASE -delarna) kan konfigureras av användaren när du använder TDE i SQL Database.
Aktivera TDE
Följ dessa steg om du vill använda TDE.
Gäller för: SQL Server.
- Skapa en huvudnyckel.
- Skapa eller hämta ett certifikat som skyddas av huvudnyckeln.
- Skapa en databaskrypteringsnyckel och skydda den med hjälp av certifikatet.
- Ange att databasen ska använda kryptering.
I följande exempel visas kryptering och dekryptering av databasen med hjälp av AdventureWorks2022 ett certifikat med namnet MyServerCert som är installerat på servern.
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD= '<password>';
GO
CREATE CERTIFICATE MyServerCert
    WITH SUBJECT = 'My DEK Certificate';
GO
USE AdventureWorks2022;
GO
CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256
    ENCRYPTION BY SERVER CERTIFICATE MyServerCert;
GO
ALTER DATABASE AdventureWorks2022
    SET ENCRYPTION ON;
GO
Krypterings- och dekrypteringsåtgärderna schemaläggs i bakgrundstrådar av SQL Server. Om du vill visa status för dessa åtgärder använder du katalogvyerna och dynamiska hanteringsvyer i tabellen som visas senare i den här artikeln.
Försiktighet
Säkerhetskopieringsfiler för databaser som har TDE aktiverat krypteras också med DEK. När du återställer dessa säkerhetskopior måste därför certifikatet som skyddar DEK vara tillgängligt. Förutom att säkerhetskopiera databasen bör du därför underhålla säkerhetskopior av servercertifikaten. Dataförlustresultat om certifikaten inte längre är tillgängliga.
Mer information finns i SQL Server-certifikat och asymmetriska nycklar.
Kommandon och funktioner
Om du vill att följande instruktioner ska acceptera TDE-certifikat använder du en databashuvudnyckel för att kryptera dem. Om du bara krypterar dem med lösenord avvisar uttrycken dem som krypteringskrypterare.
Viktigt!
Om du gör certifikaten lösenordsskyddade när TDE använder dem blir databasen otillgänglig efter en omstart.
Följande tabell innehåller länkar och förklaringar av TDE-kommandon och funktioner:
| Kommando eller funktion | Avsikt | 
|---|---|
| SKAPA DATABASKRYPTERINGSNYCKEL | Skapar en nyckel som krypterar en databas | 
| ÄNDRA DATABASKRYPTERINGSNYCKEL | Ändrar nyckeln som krypterar en databas | 
| TA BORT DATABASKRYPTERINGSNYCKEL | Tar bort nyckeln som krypterar en databas | 
| ÄNDRA ALTERNATIV FÖR DATABASUPPSÄTTNING | Förklarar alternativet ALTER DATABASEsom används för att aktivera TDE | 
Katalogvyer och dynamiska hanteringsvyer
I följande tabell visas TDE-katalogvyer och dynamiska hanteringsvyer (DMV).
| Katalogvy eller dynamisk hanteringsvy | Avsikt | 
|---|---|
| sys.databases | Katalogvy som visar databasinformation | 
| sys.certificates | Katalogvy som visar certifikaten i en databas | 
| sys.dm_database_encryption_keys | Dynamisk hanteringsvy som innehåller information om en databas krypteringsnycklar och krypteringstillstånd | 
Permissions
Varje TDE-funktion och kommando har individuella behörighetskrav enligt beskrivningen i tabellerna som visades tidigare.
För att kunna visa de metadata som ingår i TDE krävs behörigheten VIEW DEFINITION för ett certifikat.
Överväganden
Medan en omkrypteringssökning för en databaskryptering pågår inaktiveras underhållsåtgärder till databasen. Du kan använda inställningen för enanvändarläge för databasen för att utföra underhållsåtgärder. Mer information finns i Ange en databas till enanvändarläge.
              sys.dm_database_encryption_keys Använd vyn dynamisk hantering för att hitta tillståndet för databaskryptering. Mer information finns i avsnittet Katalogvyer och dynamiska hanteringsvyer tidigare i den här artikeln.
I TDE krypteras alla filer och filgrupper i en databas. Om någon filgrupp i en databas är markerad READ ONLYmisslyckas databaskrypteringsåtgärden.
Om du använder en databas i databasspegling eller loggöverföring krypteras båda databaserna. Loggtransaktionerna krypteras när de skickas mellan dem.
Viktigt!
Fulltextindex krypteras när en databas har angetts för kryptering. Sådana index som skapats i SQL Server 2005 (9.x) och tidigare versioner importeras till databasen av SQL Server 2008 (10.0.x) och senare versioner och krypteras av TDE.
Tips/Råd
Om du vill övervaka ändringar i TDE-statusen för en databas använder du SQL Server-granskning eller Azure SQL Database-granskning. För SQL Server spåras TDE under granskningsåtgärdsgruppen DATABASE_OBJECT_CHANGE_GROUP, som du hittar i ÅTGÄRDsgrupper och åtgärder för SQL Server-granskning.
Begränsningar
Följande åtgärder tillåts inte under inledande databaskryptering, nyckeländring eller databasdekryptering:
- Ta bort en fil från en filgrupp i en databas
- Ta bort en databas
- Ta en databas offline
- Koppla från en databas
- Överföra en databas eller filgrupp till ett READ ONLYtillstånd
Följande åtgärder tillåts inte under - , ALTER DATABASE ENCRYPTION KEY- DROP DATABASE ENCRYPTION KEYoch ALTER DATABASE...SET ENCRYPTION -uttryckenCREATE DATABASE ENCRYPTION KEY:
- Ta bort en fil från en filgrupp i en databas
- Ta bort en databas
- Ta en databas offline
- Koppla från en databas
- Överföra en databas eller filgrupp till ett READ ONLYtillstånd
- Använda ett ALTER DATABASEkommando
- Starta en databas- eller databasfilsäkerhetskopia
- Starta en databas- eller databasfilåterställning
- Skapa en ögonblicksbild
Följande åtgärder eller villkor förhindrar CREATE DATABASE ENCRYPTION KEY- , ALTER DATABASE ENCRYPTION KEYDROP DATABASE ENCRYPTION KEYoch ALTER DATABASE...SET ENCRYPTION -instruktioner:
- En databas är skrivskyddad eller har skrivskyddade filgrupper.
- Ett ALTER DATABASEkommando körs.
- En datasäkerhetskopia körs.
- En databas är i ett offline- eller återställningsvillkor.
- En ögonblicksbild pågår.
- Databasunderhållsåtgärder körs.
När databasfiler skapas är omedelbar filinitiering inte tillgänglig när TDE är aktiverat.
För att kryptera en DEK med en asymmetrisk nyckel måste den asymmetriska nyckeln finnas på en utökningsbar nyckelhanteringsprovider.
TDE-genomsökning
För att aktivera TDE på en databas måste SQL Server göra en krypteringsgenomsökning. Genomsökningen läser varje sida från datafilerna till buffertpoolen och skriver sedan tillbaka de krypterade sidorna till disken.
För att ge dig mer kontroll över krypteringsgenomsökningen introducerar SQL Server 2019 (15.x) TDE-genomsökning, som har en paus- och återuppta-syntax. Du kan pausa genomsökningen medan arbetsbelastningen i systemet är tung eller under affärskritiska timmar och sedan återuppta genomsökningen senare.
Använd följande syntax för att pausa TDE-krypteringsgenomsökningen:
ALTER DATABASE <db_name> SET ENCRYPTION SUSPEND;
På samma sätt kan du använda följande syntax för att återuppta TDE-krypteringsgenomsökningen:
ALTER DATABASE <db_name> SET ENCRYPTION RESUME;
Kolumnen encryption_scan_state har lagts till i sys.dm_database_encryption_keys vyn dynamisk hantering. Den visar det aktuella tillståndet för krypteringsgenomsökningen. Det finns också en ny kolumn med namnet encryption_scan_modify_date, som innehåller datum och tid för den senaste ändringen av krypteringsgenomsökningstillståndet.
Om SQL Server-instansen startas om medan krypteringsgenomsökningen pausas loggas ett meddelande i felloggen under starten. Meddelandet anger att en befintlig genomsökning har pausats.
Viktigt!
Funktionen Pausa och återuppta TDE-genomsökning är för närvarande inte tillgänglig i Azure SQL Database, Azure SQL Managed Instance och Azure Synapse Analytics.
TDE- och transaktionsloggar
TDE skyddar datafiler och loggfiler i vila. Kryptering av hela databasen efter aktivering av TDE på en okrypterad databas är en betydande dataåtgärd och den tid det tar beror på de systemresurser som databasen körs på. Den sys.dm_database_encryption_keys DMV kan användas för att fastställa krypteringstillståndet för en databas.
När TDE är aktiverat tvingar databasmotorn fram skapandet av en ny transaktionslogg, som krypteras av databaskrypteringsnyckeln. Alla loggar som genereras av tidigare transaktioner eller aktuella långvariga transaktioner mellan TDE-tillståndsändringen krypteras inte.
Transaktionsloggarna kan övervakas med hjälp av sys.dm_db_log_info DMV, som också visar om loggfilen är krypterad eller inte använder kolumnen vlf_encryptor_thumbprint som är tillgänglig i Azure SQL och SQL Server 2019 (15.x) och senare versioner. Här är en exempelfråga för att hitta loggfilens krypteringsstatus med hjälp encryption_state av kolumnen i sys.dm_database_encryption_keys vyn:
USE AdventureWorks2022;
GO
/* The value 3 represents an encrypted state
   on the database and transaction logs. */
SELECT *
FROM sys.dm_database_encryption_keys
WHERE encryption_state = 3;
GO
Mer information om SQL Server-loggfilsarkitekturen finns i Transaktionsloggen.
Innan en DEK ändras krypterar den tidigare DEK alla data som skrivits till transaktionsloggen.
Om du ändrar en DEK två gånger måste du göra en loggsäkerhetskopia innan du kan ändra DEK igen.
TDE och tempdb-systemdatabasen
Systemdatabasen tempdb krypteras om någon annan databas på SQL Server-instansen krypteras med hjälp av TDE. Den här krypteringen kan ha en prestandaeffekt för okrypterade databaser på samma SQL Server-instans. Mer information om systemdatabasen finns i tempdbtempdb Database.
TDE och replikering
Replikering replikerar inte automatiskt data från en TDE-aktiverad databas i ett krypterat formulär. Aktivera TDE separat om du vill skydda distributions- och prenumerantdatabaser.
Replikering av ögonblicksbilder kan lagra data i okrypterade mellanliggande filer som BCP-filer. Den inledande datadistributionen för transaktions- och sammanslagningsreplikering kan också göra det. Under sådan replikering kan du aktivera kryptering för att skydda kommunikationskanalen.
Mer information finns i Kryptera anslutningar till SQL Server genom att importera ett certifikat.
TDE och tillgänglighetsgrupper
Du kan lägga till en krypterad databas i en AlwaysOn-tillgänglighetsgrupp.
Om du vill kryptera databaser som ingår i en tillgänglighetsgrupp skapar du huvudnyckeln och certifikaten eller den asymmetriska nyckeln (EKM) på alla sekundära repliker innan du skapar databaskrypteringsnyckeln på den primära repliken.
Om ett certifikat används för att skydda DEK säkerhetskopierar du certifikatet som skapats på den primära repliken och skapar sedan certifikatet från en fil på alla sekundära repliker innan du skapar DEK på den primära repliken.
TDE- och FILESTREAM-data
FILESTREAM-data krypteras inte, inte ens när du aktiverar TDE.
TDE och säkerhetskopior
Certifikat används ofta i transparent datakryptering för att skydda DEK. Certifikatet måste skapas i master databasen. Säkerhetskopieringsfiler för databaser som har TDE aktiverat krypteras också med hjälp av DEK. När du återställer från dessa säkerhetskopior måste därför certifikatet som skyddar DEK vara tillgängligt. Det innebär att förutom att säkerhetskopiera databasen måste du underhålla säkerhetskopior av servercertifikaten för att förhindra dataförlust. Dataförlust uppstår om certifikatet inte längre är tillgängligt.
Ta bort TDE
Ta bort kryptering från databasen med hjälp av -instruktionen ALTER DATABASE .
ALTER DATABASE <db_name> SET ENCRYPTION OFF;
Om du vill visa databasens tillstånd använder du vyn sys.dm_database_encryption_keys dynamisk hantering.
Anmärkning
Medan krypteringsprocessen pågår ALTER DATABASE tillåts inte instruktioner i databasen. Innan krypteringsprocessen är klar kan du inte börja dekryptera databasen.
Vänta tills dekrypteringen har slutförts innan du tar bort DEK:t med hjälp av DROP DATABASE ENCRYPTION KEY.
Viktigt!
Säkerhetskopiera huvudnyckeln och certifikatet som används för TDE till en säker plats. Huvudnyckeln och certifikatet krävs för att återställa säkerhetskopior som gjordes när databasen krypterades med TDE. När du har tar bort DEK:t tar du en loggsäkerhetskopia följt av en ny fullständig säkerhetskopia av den dekrypterade databasen.
TDE och buffertpooltillägget
När du krypterar en databas med hjälp av TDE krypteras inte filer som rör buffertpoolstillägget (BPE). För dessa filer använder du krypteringsverktyg som BitLocker eller EFS på filsystemsnivå.
TDE och In-Memory OLTP
Du kan aktivera TDE på en databas som har In-Memory OLTP-objekt. I SQL Server 2016 (13.x) och Azure SQL Database krypteras In-Memory OLTP-loggposter och data om du aktiverar TDE. I SQL Server 2014 (12.x) krypteras In-Memory OLTP-loggposter om du aktiverar TDE, men filer i MEMORY_OPTIMIZED_DATA filgruppen är okrypterade.
Riktlinjer för hantering av certifikat som används i TDE
Du måste säkerhetskopiera certifikatet och huvudnyckeln för databasen när databasen är aktiverad för TDE och används vid loggöverföring eller databasspegling. Certifikat som lagras i en innesluten systemdatabas bör också säkerhetskopieras.
Certifikatet som används för att skydda DEK bör aldrig tas bort från master databasen. Detta gör att den krypterade databasen blir otillgänglig.
Ett meddelande som följande (fel 33091) utlöses efter körning CREATE DATABASE ENCRYPTION KEY om certifikatet som används i kommandot inte redan har säkerhetskopierats.
Varning
Certifikatet som används för kryptering av databaskrypteringsnyckeln har inte säkerhetskopierats. Du bör omedelbart säkerhetskopiera certifikatet och den privata nyckel som är associerad med certifikatet. Om certifikatet någonsin blir otillgängligt eller om du måste återställa eller koppla databasen på en annan server måste du ha säkerhetskopior av både certifikatet och den privata nyckeln, annars kan du inte öppna databasen.
Följande fråga kan användas för att identifiera de certifikat som används i TDE som inte har säkerhetskopierats från den tidpunkt då den skapades.
SELECT pvt_key_last_backup_date,
       Db_name(dek.database_id) AS encrypteddatabase,
       c.name AS Certificate_Name
FROM sys.certificates AS c
     INNER JOIN sys.dm_database_encryption_keys AS dek
         ON c.thumbprint = dek.encryptor_thumbprint;
Om kolumnen pvt_key_last_backup_date är NULLhar databasen som motsvarar den raden aktiverats för TDE, men certifikatet som används för att skydda dess DEK har inte säkerhetskopierats. Mer information om hur du säkerhetskopierar ett certifikat finns i SÄKERHETSKOPIERingsCERTIFIKAT.
