Implementera transparent datakryptering
Transparent datakryptering (TDE) hjälper till att skydda Azure SQL Database, Azure SQL Managed Instance och Synapse SQL i Azure Synapse Analytics mot hot om skadlig offlineaktivitet genom att kryptera vilande data. TDE utför realtidskryptering och realtidsdekryptering av databasen, tillhörande säkerhetskopior och transaktionsloggfiler i vila, utan att några ändringar krävs i programmet. Som standard är TDE aktiverat för alla nyligen distribuerade Azure SQL-databaser och måste aktiveras manuellt för äldre databaser i Azure SQL Database, Azure SQL Managed Instance eller Azure Synapse.
TDE utför I/O-kryptering i realtid och dekryptering av data på sidnivå. Varje sida dekrypteras när de läses in i minnet och krypteras sedan innan de skrivs tillbaka till disken. TDE krypterar lagringen av en hel databas med hjälp av en symmetrisk nyckel som kallas databaskrypteringsnyckel (DEK). Vid databasstart dekrypteras den krypterade DEK:en och används sedan för dekryptering och omkryptering av databasfilerna i SQL Server Database Engine-processen. DEK skyddas av TDE-skyddet. TDE-skydd är antingen ett tjänsthanterat certifikat (tjänsthanterad transparent datakryptering) eller en asymmetrisk nyckel som lagras i Azure Key Vault (kundhanterad transparent datakryptering).
För Azure SQL Database och Azure Synapse anges TDE-skyddet på den logiska SQL-servernivån och ärvs av alla databaser som är associerade med den servern. För Azure SQL Managed Instance (BYOK-funktion i förhandsversion) anges TDE-skyddet på instansnivå och ärvs av alla krypterade databaser på den instansen. Termservern refererar både till server och instans i det här dokumentet, om inte annat anges.
Alla nyligen skapade SQL-databaser krypteras som standard med hjälp av tjänsthanterad transparent datakryptering. När databaskällan krypteras krypteras måldatabaserna som skapas via återställning, geo-replikering och databaskopiering som standard. Men när databaskällan inte är krypterad krypteras inte måldatabaserna som skapas via återställning, geo-replikering och databaskopiering som standard. Befintliga SQL-databaser som skapats före maj 2017 och befintliga SQL Managed Instance-databaser som skapats före februari 2019 krypteras inte som standard. SQL Managed Instance-databaser som skapats genom återställning ärver krypteringsstatus från källan. Om du vill återställa en befintlig TDE-krypterad databas måste du först importera det nödvändiga TDE-certifikatet till SQL Managed Instance. Om du vill ta reda på krypteringsstatusen för en databas kör du en select-fråga från sys.dm_database_encryption_keys DMV och kontrollerar kolumnens encryption_state_desc status.
TDE kan inte användas för att kryptera systemdatabaser, till exempel master databasen, i SQL Database och SQL Managed Instance. Huvuddatabasen innehåller objekt som behövs för att utföra TDE-åtgärder på användardatabaser. Vi rekommenderar att du inte lagrar känsliga data i systemdatabaser. Undantaget är tempdb, som alltid krypteras med TDE för att skydda data som lagras där.
Tjänsthanterad transparent datakryptering
I Azure är standardinställningen för TDE att DEK skyddas av ett inbyggt servercertifikat. Det inbyggda servercertifikatet är unikt för varje server. Den krypteringsalgoritm som används är AES 256. Om en databas finns i en geo-replikeringsrelation skyddas både den primära och den geo-sekundära databasen av den primära databasens överordnade servernyckel. Om två databaser är anslutna till samma server delar de även samma inbyggda certifikat. Microsoft roterar automatiskt dessa certifikat i enlighet med den interna säkerhetsprincipen. Rotnyckeln skyddas av ett internt Microsoft-hemlighetsarkiv. Kunder kan kontrollera SQL Database-efterlevnaden med interna säkerhetsprinciper i oberoende granskningsrapporter från tredje part som är tillgängliga i Microsoft Trust Center.
Microsoft flyttar och hanterar också nycklarna sömlöst efter behov för geo-replikering och återställning.
Kundhanterad transparent datakryptering – Bring Your Own Key
Kundhanterad TDE kallas även BYOK-stöd (Bring Your Own Key) för TDE. I det här scenariot är TDE-skyddet som krypterar DEK en kundhanterad asymmetrisk nyckel som lagras i ett kundägt och hanterat Azure Key Vault (Azures molnbaserade externa nyckelhanteringssystem) och aldrig lämnar nyckelvalvet. TDE-skyddet kan genereras av nyckelvalvet eller överföras till nyckelvalvet från en lokal maskinvarusäkerhetsmodul (HSM). SQL Database måste beviljas behörighet till det kundägda nyckelvalvet för att dekryptera och kryptera DEK. Om behörigheterna för den logiska SQL-servern till nyckelvalvet återkallas är en databas otillgänglig och alla data krypteras
Med TDE med Azure Key Vault-integrering kan användarna styra viktiga hanteringsuppgifter, inklusive nyckelrotationer, behörigheter för nyckelvalv, nyckelsäkerhetskopior och aktivera granskning/rapportering av alla TDE-skydd med hjälp av Azure Key Vault-funktioner. Key Vault tillhandahåller central nyckelhantering, utnyttjar noggrant övervakade HSM:er och möjliggör uppdelning av uppgifter mellan hantering av nycklar och data för att uppfylla efterlevnaden av säkerhetsprinciper.
Flytta en transparent datakrypteringsskyddad databas
Du behöver inte dekryptera databaser för åtgärder i Azure. TDE-inställningarna för källdatabasen eller den primära databasen ärvs transparent på målet. Åtgärder som ingår omfattar:
- Geo-återställning
- Återställning till tidpunkt för självbetjäning
- Återställning av en borttagen databas
- Aktiv geo-replikering
- Skapa en databaskopia
- Återställning av säkerhetskopieringsfil till Azure SQL Managed Instance
Manuell kopiering av en databas som krypterats av tjänsthanterad TDE stöds inte i Azure SQL Managed Instance, eftersom det certifikat som används för kryptering inte är tillgängligt. Använd funktionen för återställning till tidpunkt för att flytta den här typen av databas till en annan SQL Managed Instance eller växla till kundhanterad nyckel.
När du exporterar en TDE-skyddad databas krypteras inte det exporterade innehållet i databasen. Det exporterade innehållet lagras i okrypterade BACPAC-filer. Se till att skydda BACPAC-filerna på rätt sätt och aktivera TDE när importen av den nya databasen är klar.
Om BACPAC-filen till exempel exporteras från en SQL Server-instans krypteras inte det importerade innehållet i den nya databasen automatiskt. På samma sätt krypteras inte heller den nya databasen automatiskt om BACPAC-filen importeras till en SQL Server-instans.
Det enda undantaget är när du exporterar en databas till och från SQL Database. TDE är aktiverat på den nya databasen, men själva BACPAC-filen är fortfarande inte krypterad.
Hantera transparent datakryptering
Hantera TDE i Azure-portalen.
Om du vill konfigurera TDE via Azure-portalen måste du vara ansluten som Azure-ägare, deltagare eller SQL Security Manager.
Aktivera och inaktivera TDE på databasnivå. För Azure SQL Managed Instance använder du Transact-SQL (T-SQL) för att aktivera och inaktivera TDE på en databas. För Azure SQL Database och Azure Synapse kan du hantera TDE för databasen i Azure-portalen när du har loggat in med Azure-administratörs- eller deltagarkontot. Leta upp TDE-inställningarna under din användardatabas. Som standard används krypteringsnyckel på servernivå. Ett TDE-certifikat genereras automatiskt för servern som innehåller databasen.
Du anger TDE-huvudnyckeln, TDE-skyddet, på server- eller instansnivå. Om du vill använda TDE med BYOK-stöd och skydda dina databaser med en nyckel från Azure Key Vault öppnar du TDE-inställningarna under servern eller den hanterade instansen.
Du kan också använda en kundhanterad nyckel för TDE på databasnivå för Azure SQL Database.