dataskydd är avgörande för att säkerställa att din organisation överensstämmer med standarder för regelefterlevnad som GDPR och för att uppfylla förväntningarna hos dina kunder och affärspartners. Dataöverträdelser kan inte bara leda till stora böter, men rykteskadorna kan vara lika stora. För att hjälpa till stöder Microsoft SQL Server 5 olika typer av kryptering för att skydda data. Denna artikel förklarar var och en av dem och var de ska användas.

SSL transport Encryption

liksom webbplatser som säkerställer trafik mellan webbläsare och server kan SQL Server konfigureras för att använda Secure Sockets Layer (SSL) för att kryptera trafik när den färdas mellan serverinstansen och klientapplikationen. Dessutom kan klienten validera serverns identitet med serverns certifikat. SSL skyddar bara data när den färdas över nätverket, men till skillnad från de flesta andra former av SQL Server-kryptering är SSL tillgängligt i alla versioner av SQL Server som stöds och i alla utgåvor.

innan du aktiverar SSL måste du installera ett certifikat på SQL Server. Det bästa sättet att göra detta är genom att begära ett certifikat från din egen Enterprise certification authority (CA). Windows Server kan konfigureras som en CA och du kan ställa in klienter så att de litar på de certifikat som det utfärdar. Alternativt är det möjligt att använda självsignerade certifikat, även om detta passar bäst för testmiljöer.

SQL Server Transparent Data Encryption (TDE)

Transparent Data Encryption (TDE) i SQL Server skyddar data i vila genom att kryptera databasdata och loggfiler på disken. Det fungerar transparent för befintliga klientprogram, så de behöver inte ändras när TDE är aktiverat. TDE använder kryptering i realtid på sidnivå. Sidor krypteras innan de skrivs till disken, utan att öka storleken på dina data och loggfiler, och sidor dekrypteras när de läses in i minnet. TDE är endast tillgängligt i Enterprise-utgåvor av SQL Server. Det fungerar också för Azure SQL Database, Azure SQL Data Warehouse och Parallel Data Warehouse.

TDE-kryptering har en hierarkisk struktur, med Windows Data Protection API (DPAPI) som sitter ovanpå hierarkin och används för att kryptera tjänstens huvudnyckel (SMK). Du kan använda SMK för att kryptera referenser, länkade serverlösenord och databasens huvudnycklar (DMK) som finns i olika databaser. En SQL DMK är en symmetrisk nyckel som skyddar de privata nycklarna till certifikat och asymmetriska nycklar lagrade i databaser.

SQL Server kan generera självsignerade certifikat för användning med TDE eller så kan du begära ett certifikat från en CA (vilket är den vanligaste metoden). Om du väljer att aktivera TDE måste du säkerhetskopiera certifikatet och den privata nyckeln som är kopplad till certifikatet. Du måste återställa eller bifoga databasen på en annan SQL-Server. Om du aktiverar TDE på någon annan SQL Server-databas är tempdb-systemdatabasen också krypterad. Om du inaktiverar TDE bör du behålla certifikatet och den privata nyckeln eftersom delar av transaktionsloggen kan förbli krypterade tills du utför en fullständig säkerhetskopia.

TDE kräver också en databaskrypteringsnyckel (dek), som antingen är en symmetrisk nyckel som skyddas med ett certifikat lagrat i huvuddatabasen eller en asymmetrisk nyckel som skyddas av en tjänst som använder Extensible Key Management (EKM), till exempel Microsoft Azure Key Vault. Säkerhetskopieringsfiler av TDE-aktiverade databaser krypteras med DEK, så under återställningsoperationer måste certifikatet som skyddar DEK vara tillgängligt.

symmetriska nycklar använder samma lösenord för att kryptera och dekryptera data. Asymmetriska nycklar använder ett lösenord för att kryptera data (offentlig nyckel) och ett annat lösenord för att dekryptera data (privat nyckel). Du kan använda kommandot Skapa certifikat för att skapa certifikat och skapa symmetrisk nyckel och skapa asymmetrisk Nyckel Transact-SQL-kommandon för att skapa databaskrypteringsnycklar.

Backup Encryption

Backup Encryption fungerar som TDE men krypterar SQL-säkerhetskopior istället för aktiva data och loggfiler. Backup kryptering finns i SQL Server 2014 och senare. Du kan ange AES 128, AES 192, AES 256 eller Triple DES kryptering, och använda antingen ett certifikat eller asymmetrisk nyckel lagras i EKM. Dessutom är det möjligt att aktivera TDE och Backup kryptering samtidigt, även om du bör använda olika certifikat eller nycklar.

precis som med TDE, om du aktiverar Säkerhetskopieringskryptering måste du också säkerhetskopiera certifikatet eller nyckeln. Utan nyckeln eller certifikatet kan säkerhetskopieringsfilen inte användas för att återställa data. Säkerhetskopior kan också krypteras när du använder SQL Server Managed Backup till Microsoft Azure.

det är värt att notera att om du använder ett certifikat för att kryptera säkerhetskopior måste du ha det ursprungliga certifikatet när du återställer data. Det betyder att certifikatet måste ha samma tumavtryck som när säkerhetskopian skapades. Att förnya certifikat eller ändra dem på något sätt kan göra att tumavtrycket ändras.

kolumn/cellnivå kryptering

Finns i alla versioner av SQL Server, kan cellnivå kryptering aktiveras på kolumner som innehåller känsliga data. Data krypteras på disken och förblir krypterad i minnet tills DECRYPTBYKEY-funktionen används för att dekryptera den. Därför, även om SQL-data är krypterad, är det inte säkert utöver att bara använda en funktion i användarkontexten för att dekryptera den. Dessutom, eftersom en funktion behövs för att dekryptera data, måste klientapplikationer ändras för att fungera med kryptering på cellnivå.

Krypteringsnyckelhantering

som med TDE måste du skapa en huvudnyckel (DMK) innan du använder kryptering på cellnivå. Det finns fyra alternativ för kryptering av information med cellnivåkryptering:

• Du kan använda en lösenfras för att kryptera och dekryptera data, men du måste kryptera lagrade procedurer och funktioner; annars kan lösenfrasen nås i metadata.
• asymmetriska nycklar ger stark säkerhet men kan påverka prestanda.symmetriska tangenter är vanligtvis tillräckligt starka och ger en bra balans mellan säkerhet och prestanda.
• certifikat ger också en bra balans mellan säkerhet och prestanda, och de kan associeras med en databasanvändare.

alltid krypterad

alltid krypterad krypterar känslig data i klientapplikationer utan att avslöja krypteringsnycklarna till databasmotorn, vilket ger separation mellan dataägare och datahanterare. Med Always Encrypted enabled kan du till exempel vara säker på att databasadministratörerna inte kan läsa känslig data. Som namnet antyder krypteras data i vila och om de används i ett tredjepartssystem, till exempel Azure.

alltid krypterad kan konfigureras för enskilda databaskolumner. Två typer av nycklar används: kolumn krypteringsnycklar och kolumn huvudnycklar. Kolumnkrypteringsnycklar skydda data i en kolumn och kolumnhuvudnycklar är nyckelskyddande nycklar som krypterar en eller flera kolumnkrypteringsnycklar. Kolumnhuvudnycklar lagras i externa betrodda nyckelbutiker, som Azure Key Vault.

krypteringsprocessen är transparent för klientapplikationer men kräver en speciell drivrutin på klientdatorer. Alltid krypterad är tillgänglig i SQL Server 2016 och senare, men endast i Enterprise-utgåvor. På grund av de extra kraven på klientsidan är Always Encrypted bäst lämpad för situationer där separation av dataägare och chefer är ett primärt krav.

IT-konsult och författare som specialiserat sig på förvaltning och säkerhetsteknik. Russell har mer än 15 års erfarenhet av det, han har skrivit en bok om Windows-säkerhet och han medförfattare till en text för Microsofts officiella akademiska kurs (MOAC) – serie.