Hvis du har brug for at gemme fortrolige data i din database, kan du bruge datakryptering . SQL Server understøtter kryptering med symmetriske nøgler, asymmetriske nøgler, certifikater og adgangskodesætninger. Jeg går ud fra, at du, læseren, allerede er bekendt med disse udtryk. I denne artikel vil jeg fokusere på to ud af mange krypteringsmuligheder leveret af SQL Server:
- Transparent Data Encryption (TDE)
- Altid krypteret (AE)
Transparent datakryptering
Transparent Data Encryption (TDE) beskytter data i hvile, når de ikke bruges. Når dataene bruges, dekrypterer SQL Server dem automatisk. Du kan bruge TDE til realtidskryptering og dekryptering af data og logfiler. Du krypterer dataene med databasekrypteringsnøglen (DEK) , som er en symmetrisk nøgle. Den er gemt i databasens boot record og er derfor tilgængelig allerede under databasegendannelsesprocessen. Du beskytter DEK'en med et certifikat i masterdatabasen. Du kan også bruge en asymmetrisk nøgle i stedet for certifikatet; dog skal den asymmetriske nøgle gemmes i et EKM-modul. TDE bruger kun AES- og Triple DES-krypteringerne. TDE blev først implementeret i SQL Server med version 2012.
Du kan kun bruge TDE på brugerdatabaser. Du kan ikke eksportere databasekrypteringsnøglen. Denne nøgle bruges kun af SQL Server Database Engine. Slutbrugere bruger det aldrig. Selvom du ændrer databaseejeren, behøver du ikke at regenerere DEK.
TDE krypterer data på sideniveau. Derudover krypterer den også transaktionsloggen. Du bør sikkerhedskopiere det certifikat, der bruges til at beskytte DEK, og den private nøgle, der bruges til at beskytte certifikatet, umiddelbart efter du har aktiveret TDE. Hvis du har brug for at gendanne eller vedhæfte den krypterede database til en anden SQL Server-instans, skal du gendanne både certifikatet og den private nøgle, ellers kan du ikke åbne databasen. Bemærk igen, at du ikke eksporterer DEK, da det er en del af selve databasen. Du skal beholde og vedligeholde det certifikat, der bruges til at beskytte DEK, selv efter du har deaktiveret TDE i databasen. Dette skyldes, at dele af transaktionsloggen muligvis stadig er krypteret. Certifikatet er nødvendigt, indtil du udfører den fulde databasesikkerhedskopiering.
Altid krypteret
SQL Server 2016 Enterprise Edition introducerer et nyt krypteringsniveau, nemlig Always Encrypted (AE) funktion. Denne funktion muliggør det samme niveau af databeskyttelse som at kryptere dataene i klientapplikationen. Faktisk, selvom dette er en SQL Server-funktion, er dataene krypteret og dekrypteret på klientsiden. Krypteringsnøglerne afsløres aldrig for SQL Server Database Engine. På denne måde kan en DBA heller ikke se følsomme data uden krypteringsnøglerne, blot ved at have sysadmin-tilladelser på SQL Server-instansen med de krypterede data. På denne måde laver AE en adskillelse mellem de administratorer, der administrerer dataene, og de brugere, der ejer dataene.
AE-taster
Du skal bruge to nøgler til Always Encrypted. Først opretter du kolonnehovednøglen (CMK) . Derefter opretter du kolonnekrypteringsnøglen (CEK) og beskyt det med CMK. En applikation bruger CEK til at kryptere dataene. SQL Server gemmer kun krypterede data og kan ikke dekryptere dem. Dette er muligt, fordi kolonnens hovednøgler ikke rigtig er gemt i en SQL Server-database. I databasen gemmer SQL Server kun linket til disse nøgler. Kolonnehovednøglerne gemmes uden for SQL Server på et af følgende mulige steder:
- Windows Certificate Store for den aktuelle bruger
- Windows Certificate Store til den lokale maskine
- Azure Key Vault-tjeneste
- Et hardwaresikkerhedsmodul (HSM) , der understøtter Microsoft CryptoAPI eller Cryptography API:Next Generation
Kolonnekrypteringsnøglerne er gemt i databasen. Inde i en SQL Server-database er kun den krypterede del af værdierne af kolonnekrypteringsnøgler gemt sammen med informationen om placeringen af kolonnehovednøgler. CEK'er gemmes aldrig som almindelig tekst i en database. CMK'er er som nævnt faktisk gemt i eksterne betroede nøglelagre.
Brug af AE-tasterne
Et program kan bruge AE-nøglerne og kryptering ved at bruge en AE-aktiveret driver, såsom .NET Framework Data Provider til SQL Server version 4.6 eller nyere, Microsoft JDBC Driver til SQL Server 6.0 eller nyere eller Windows ODBC driver til SQL Server version 13.1 eller højere. Applikationen skal sende parametriserede forespørgsler til SQL Server. Den AE-aktiverede driver arbejder sammen med SQL Server Database Engine for at bestemme, hvilke parametre der skal krypteres eller dekrypteres. For hver parameter, der skal krypteres eller dekrypteres, henter driveren de nødvendige metadata til krypteringen fra Database Engine, inklusive krypteringsalgoritmen, placeringen af den tilsvarende CMK og den krypterede værdi for den tilsvarende CEK. Derefter kontakter driveren CMK-butikken, henter CMK'en, dekrypterer CEK'en og bruger CEK'en til at kryptere eller dekryptere parameteren. Derefter cacher chaufføren CEK'en for at fremskynde den næste brug af den samme CEK. Følgende figur viser processen grafisk.
Figuren repræsenterer hele processen i trin:
- Klientapplikation opretter en parametriseret forespørgsel
- Klientapplikation sender den parametrerede forespørgsel til den AE-aktiverede driver
- Den AE-aktiverede driver kontakter SQL Server for at bestemme, hvilke parametre der skal kryptering eller dekryptering, placeringen af CMK'en og den krypterede værdi af CEK'en
- Den AE-aktiverede driver henter CMK'en og dekrypterer CEK'en
- Den AE-aktiverede driver krypterer parameteren/parametrene
- Driveren sender forespørgslen til databasemotoren
- Databasemotoren henter dataene og sender resultatsættet til driveren
- Driveren udfører dekryptering, hvis det er nødvendigt, og sender resultatsættet til klientapplikationen
AE-krypteringstyper
Databasemotoren fungerer aldrig på de almindelige tekstdata, der er gemt i de krypterede kolonner. Nogle forespørgsler på de krypterede data er dog mulige, afhængigt af krypteringstypen. Der er to typer af kryptering:
- Deterministisk kryptering , som altid genererer den samme krypterede værdi for den samme inputværdi. Med denne kryptering kan du indeksere den krypterede kolonne og bruge punktopslag, lighedssammenføjninger og grupperingsudtryk på den krypterede kolonne. En ondsindet bruger kan dog prøve at gætte værdierne ved at analysere mønstrene for de krypterede værdier. Dette er især farligt, når sættet af mulige værdier for en kolonne er diskret med et lille antal forskellige værdier.
- Randomiseret kryptering , som krypterer data på en uforudsigelig måde.
AE Demo:Oprettelse af objekterne
Det er tid til at vise, hvordan AE fungerer gennem nogle demo-kode. Lad os først oprette og bruge en demodatabase.
USE master; IF DB_ID(N'AEDemo') IS NULL CREATE DATABASE AEDemo; GO USE AEDemo; GO
Opret derefter CMK i SSMS GUI. Opdater mappen Databaser i Object Explorer for at se AEDemo-databasen. Udvid denne databasemappe, udvid undermappen Sikkerhed og derefter undermappen Altid krypterede nøgler, og højreklik på undermappen Kolonnehovednøgle og vælg indstillingen Ny kolonnehovednøgle fra pop op-menuen. Skriv AE_ColumnMasterKey i tekstfeltet Navn, og sørg for at vælge indstillingen Windows Certificate Store – Local Machine i rullelisten Key Store, som den følgende figur viser.
Du kan kontrollere, om CMK'en blev oprettet korrekt med følgende forespørgsel.
SELECT * FROM sys.column_master_keys;
Dernæst opretter du CEK. I SSMS, i Object Explorer, højreklik på undermappen Column Encryption Keys lige under Column Master Key-undermappen og vælg indstillingen New Column Encryption Key fra pop op-menuen. Navngiv CEK AE_ColumnEncryptionKey og brug AE_ColumnMasterKey CMK til at kryptere den. Du kan kontrollere, om CEK-oprettelsen lykkedes med følgende forespørgsel.
SELECT * FROM sys.column_encryption_keys;
I øjeblikket er det kun de nye binære sorteringer, kollationerne med BIN2 suffiks, understøttes for AE. Lad os derfor oprette en tabel med passende sammenstillinger for tegnkolonnerne.
CREATE TABLE dbo.Table1 (id INT, SecretDeterministic NVARCHAR(10) COLLATE Latin1_General_BIN2 ENCRYPTED WITH (COLUMN_ENCRYPTION_KEY = AE_ColumnEncryptionKey, ENCRYPTION_TYPE = DETERMINISTIC, ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256') NULL, SecretRandomized NVARCHAR(10) COLLATE Latin1_General_BIN2 ENCRYPTED WITH (COLUMN_ENCRYPTION_KEY = AE_ColumnEncryptionKey, ENCRYPTION_TYPE = RANDOMIZED, ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256') NULL );
AE Demo:Indsættelse af data
Nu kan du prøve at indsætte en række data med følgende sætning.
INSERT INTO dbo.Table1 (id, SecretDeterministic, SecretRandomized) VALUES (1, N'DeterSec01', N'RandomSec1');
Du får fejl 206, fejltekst:"Operand type sammenstød:nvarchar er inkompatibel med nvarchar(4000) krypteret med (encryption_type ='DETERMINISTIC', encryption_algorithm_name ='AEAD_AES_256_CBC_HMAC_SHA_256_CBC_HMAC_SHA_256'encryption_encryption_AE_Eencryption_AE_Eencryption_AE_Eencryption_256', column_keynkeyn_AE_AE . SQL Server kan ikke kryptere eller dekryptere dataene. Du skal ændre dataene fra en klientapplikation. Du kan udføre et begrænset sæt operationer på bordet fra SQL Server. For eksempel kan du bruge TRUNCATE TABLE-sætningen på en tabel med AE-kolonner.
Jeg oprettede en meget enkel klient Windows Console-applikation i Visual C#. Applikationen henter faktisk bare nøglerne og indsætter en enkelt række i tabellen oprettet med koden ovenfor. Her er C#-koden.
using System;
using System.Collections.Generic;
using System.Data;
using System.Data.SqlClient;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace AEDemo
{
class Program
{
static void Main(string[] args)
{
string connectionString = "Data Source=localhost; “ +
“Initial Catalog=AEDemo; Integrated Security=true; ” +
“Column Encryption Setting=enabled";
SqlConnection connection = new SqlConnection(connectionString);
connection.Open();
if (args.Length != 3)
{
Console.WriteLine("Please enter a numeric “ +
“and two string arguments.");
return;
}
int id = Int32.Parse(args[0]);
{
using (SqlCommand cmd = connection.CreateCommand())
{
cmd.CommandText = @"INSERT INTO dbo.Table1 “ +
“(id, SecretDeterministic, SecretRandomized)" +
" VALUES (@id, @SecretDeterministic, @SecretRandomized);";
SqlParameter paramid= cmd.CreateParameter();
paramid.ParameterName = @"@id";
paramid.DbType = DbType.Int32;
paramid.Direction = ParameterDirection.Input;
paramid.Value = id;
cmd.Parameters.Add(paramid);
SqlParameter paramSecretDeterministic = cmd.CreateParameter();
paramSecretDeterministic.ParameterName =
@"@SecretDeterministic";
paramSecretDeterministic.DbType = DbType.String;
paramSecretDeterministic.Direction = ParameterDirection.Input;
paramSecretDeterministic.Value = "DeterSec1";
paramSecretDeterministic.Size = 10;
cmd.Parameters.Add(paramSecretDeterministic);
SqlParameter paramSecretRandomized = cmd.CreateParameter();
paramSecretRandomized.ParameterName =
@"@SecretRandomized";
paramSecretRandomized.DbType = DbType.String;
paramSecretRandomized.Direction = ParameterDirection.Input;
paramSecretRandomized.Value = "RandomSec1";
paramSecretRandomized.Size = 10;
cmd.Parameters.Add(paramSecretRandomized);
cmd.ExecuteNonQuery();
}
}
connection.Close();
Console.WriteLine("Row inserted successfully");
}
}
}
Du kan køre C#-koden fra Visual Studio i fejlfindingstilstanden eller bygge applikationen. Derefter kan du køre AEDemo.exe-applikationen fra kommandoprompten eller fra SSMS i SQMCMD-tilstand.
AE Demo:Læsning af data
Når du har kørt programmet, bør du prøve at læse dataene fra den samme session i SSMS, som du brugte til at oprette tabellen.
SELECT * FROM dbo.Table1;
Du kan kun se krypterede data. Åbn nu et andet forespørgselsvindue i SSMS. Højreklik i dette vindue og vælg Forbindelse og derefter Skift forbindelse. Klik på knappen Indstillinger nederst i dialogboksen Forbindelse. Skriv AEDemo for databasenavnet, og klik derefter på fanen Yderligere forbindelsesparametre. Indtast "Søjlekrypteringsindstilling=aktiveret" i tekstboksen (uden dobbelte anførselstegn). Klik derefter på Opret forbindelse.
Prøv igen at indsætte en række fra SSMS. Brug følgende forespørgsel.
INSERT INTO dbo.Table1 (id, SecretDeterministic, SecretRandomized) VALUES (2, N'DeterSec2', N'RandomSec2');
Jeg fik en fejl igen. Denne SSMS-version, jeg bruger, kan stadig ikke parametrisere ad-hoc-indsatser. Lad os dog prøve at læse dataene med følgende forespørgsel.
SELECT * FROM dbo.Table1;
Denne gang virker forespørgslen, og du får følgende resultat:
Id SecretDeterministic SecretRandomized
— ——————— —————-
1 DeterSec1 RandomSec1
2 DeterSec2 RandomSec2
AE-begrænsninger
Du har allerede set nogle begrænsninger af Always Encrypted, herunder:
- Kun BIN2-sortering understøttes for strenge
- Du kan kun indeksere kolonner med deterministisk kryptering og bruge et begrænset sæt T-SQL-operationer på disse kolonner
- Du kan ikke indeksere kolonner med randomiseret kryptering
- AE er kun begrænset til Enterprise- og Developer-udgaverne
- At arbejde med AE i SSMS kan være smertefuldt
Se Books Online for en mere detaljeret liste over AE-begrænsninger. Bemærk dog også styrkerne ved AE. Det er nemt at implementere, fordi det ikke behøver ændringer i en applikation, undtagen modifikation af forbindelsesstrenge. Data er krypteret ende-til-ende, fra klienthukommelsen gennem netværket til databaselageret. Selv DBA'er kan ikke kun se dataene i SQL Server; selv DBA'er har brug for adgang til nøglelageret uden for SQL Server for at læse CMK. AE og andre krypteringsmuligheder i SQL Server giver et komplet sæt af muligheder, og det er op til dig og det forretningsproblem, du løser, at vælge den passende metode.
Konklusion
Transparent datakryptering er ekstremt enkel at bruge. Databeskyttelsen er dog meget begrænset. TDE beskytter kun data i hvile. Altid krypteret er dog virkelig en kraftfuld funktion. Det er stadig ikke for komplekst at implementere, og dataene er fuldstændig beskyttet. Ikke engang en DBA kan se det uden at have adgang til krypteringsnøglerne. Forhåbentlig vil begrænsningerne for AE, især samlingsbegrænsningen, blive fjernet i fremtidige versioner af SQL Server.