Прозрачно криптиране на данни и винаги криптирани

Ако трябва да съхранявате поверителни данни във вашата база данни, можете да използвате криптиране на данни . SQL Server поддържа криптиране със симетрични ключове, асиметрични ключове, сертификати и фрази за пароли. Предполагам, че вие, читателят, вече сте запознати с тези термини. В тази статия ще се съсредоточа върху две от многото опции за криптиране, предоставени от SQL Server:

Прозрачно криптиране на данни (TDE)
Винаги шифровани (AE)

Прозрачно криптиране на данни

Прозрачното криптиране на данни (TDE) защитава данните в покой, когато не се използват. Когато данните се използват, SQL Server ги декриптира автоматично. Можете да използвате TDE за криптиране и декриптиране в реално време на данните и регистрационните файлове. Вие криптирате данните с ключа за криптиране на базата данни (DEK) , което е симетричен ключ. Той се съхранява в записа за зареждане на базата данни и следователно е достъпен още по време на процеса на възстановяване на базата данни. Вие защитавате DEK със сертификат в основната база данни. Можете също да използвате асиметричен ключ вместо сертификата; обаче асиметричният ключ трябва да се съхранява в EKM модул. TDE използва само криптирането AES и Triple DES. TDE беше внедрен за първи път в SQL Server с версия 2012.

Можете да използвате TDE само в потребителски бази данни. Не можете да експортирате ключа за криптиране на базата данни. Този ключ се използва само от SQL Server Database Engine. Крайните потребители никога не го използват. Дори ако промените собственика на базата данни, не е необходимо да регенерирате DEK.

TDE криптира данни на ниво страница. В допълнение, той криптира и регистъра на транзакциите. Трябва да архивирате сертификата, използван за защита на DEK, и частния ключ, използван за защита на сертификата, веднага след като активирате TDE. Ако трябва да възстановите или прикачите криптираната база данни към друг екземпляр на SQL Server, трябва да възстановите и сертификата, и частния ключ, или не можете да отворите базата данни. Отбележете отново, че не експортирате DEK, тъй като той е част от самата база данни. Трябва да запазите и поддържате сертификата, използван за защита на DEK, дори след като деактивирате TDE в базата данни. Това е така, защото части от регистъра на транзакциите все още може да са криптирани. Сертификатът е необходим, докато не извършите пълното архивиране на базата данни.

Винаги шифровани

SQL Server 2016 Enterprise Edition въвежда ново ниво на криптиране, а именно Винаги криптирано (AE) отличителен белег. Тази функция позволява същото ниво на защита на данните като криптирането на данните в клиентското приложение. Всъщност, въпреки че това е функция на SQL Server, данните се криптират и декриптират от страна на клиента. Ключовете за криптиране никога не се разкриват на SQL Server Database Engine. По този начин DBA също не може да види чувствителни данни без ключовете за криптиране, само като има разрешения на системния администратор на екземпляра на SQL Server с криптираните данни. По този начин AE прави разделение между администраторите, които управляват данните, и потребителите, които притежават данните.

Клавиши AE

Имате нужда от два ключа за Always Encrypted. Първо създавате главния ключ на колоната (CMK) . След това създавате ключ за криптиране на колона (CEK) и го защитете с CMK. Едно приложение използва CEK за криптиране на данните. SQL Server съхранява само криптирани данни и не може да ги декриптира. Това е възможно, защото главните ключове на колоната не се съхраняват в база данни на SQL Server. В базата данни SQL Server съхранява само връзката към тези ключове. Главните ключове на колоните се съхраняват извън SQL Server на едно от следните възможни места:

Съхранение на сертификати на Windows за текущия потребител
Съхранение на сертификати на Windows за локалната машина
Услуга Azure Key Vault
Хардуерен модул за сигурност (HSM) , който поддържа Microsoft CryptoAPI или Cryptography API:следващо поколение

Ключовете за криптиране на колоните се съхраняват в базата данни. В базата данни на SQL Server се съхранява само криптираната част от стойностите на ключовете за криптиране на колони, заедно с информацията за местоположението на главните ключове на колоните. CEK никога не се съхраняват като обикновен текст в база данни. CMK, както беше споменато, всъщност се съхраняват във външни доверени хранилища за ключове.

Използване на клавишите AE

Едно приложение може да използва AE ключовете и криптирането, като използва драйвер с активиран AE, като .NET Framework Data Provider за SQL Server версия 4.6 или по-нова, Microsoft JDBC драйвер за SQL Server 6.0 или по-нова или Windows ODBC драйвер за SQL Server версия 13.1 или по-висок. Приложението трябва да изпраща параметризирани заявки към SQL Server. Драйверът с активиран AE работи заедно с SQL Server Database Engine, за да определи кои параметри трябва да бъдат криптирани или декриптирани. За всеки параметър, който трябва да бъде криптиран или декриптиран, драйверът получава метаданните, необходими за криптирането от Database Engine, включително алгоритъма за криптиране, местоположението на съответния CMK и криптираната стойност за съответния CEK. След това драйверът се свързва с CMK магазина, извлича CMK, декриптира CEK и използва CEK за криптиране или декриптиране на параметъра. След това драйверът кешира CEK, за да ускори следващото използване на същия CEK. Следващата фигура показва графично процеса.

Фигурата представя целия процес на стъпки:

Клиентското приложение създава параметризирана заявка
Клиентското приложение изпраща параметризираната заявка към драйвера с активиран AE
Драйверът с активиран AE се свързва със SQL Server, за да определи кои параметри се нуждаят от криптиране или декриптиране, местоположението на CMK и криптираната стойност на CEK
Драйверът с активиран AE извлича CMK и декриптира CEK
Драйверът с активиран AE криптира параметъра(ите)
Драйверът изпраща заявката към Database Engine
The Database Engine извлича данните и изпраща набора от резултати на драйвера
Драйверът извършва декриптиране, ако е необходимо, и изпраща набора от резултати на клиентското приложение

Типове AE криптиране

Database Engine никога не работи с обикновените текстови данни, съхранявани в криптираните колони. Въпреки това са възможни някои заявки за криптирани данни, в зависимост от типа криптиране. Има два вида криптиране:

Детерминистично криптиране , който винаги генерира една и съща криптирана стойност за една и съща входна стойност. С това криптиране можете да индексирате криптираната колона и да използвате търсене на точки, присъединяване на равенство и групиращи изрази в криптираната колона. Въпреки това, злонамерен потребител може да се опита да отгатне стойностите, като анализира моделите на криптираните стойности. Това е особено опасно, когато наборът от възможни стойности за колона е дискретен, с малък брой различни стойности.
Произволно криптиране , който криптира данните по непредсказуем начин.

AE Демо:Създаване на обекти

Време е да покажем как работи AE чрез някакъв демо код. Първо, нека създадем и използваме демонстрационна база данни.

USE master;
IF DB_ID(N'AEDemo') IS NULL
   CREATE DATABASE AEDemo;
GO
USE AEDemo;
GO

След това създайте CMK в SSMS GUI. В Object Explorer опреснете папката Databases, за да видите базата данни AEDemo. Разгънете тази папка на базата данни, разгънете подпапката Защита, след това подпапката Винаги шифровани ключове и щракнете с десния бутон върху подпапката Главен ключ на колона и изберете опцията Нов главен ключ на колона от изскачащото меню. В текстовото поле Име напишете AE_ColumnMasterKey и се уверете, че сте избрали опцията Windows Certificate Store – Local Machine в падащия списък Key Store, както е показано на следващата фигура.

Можете да проверите дали CMK е създаден успешно със следната заявка.

SELECT * 
FROM sys.column_master_keys;

След това създавате CEK. В SSMS, в Object Explorer, щракнете с десния бутон върху подпапката Column Encryption Keys точно под подпапката Column Master Key и изберете опцията New Column Encryption Key от изскачащото меню. Наименувайте CEK AE_ColumnEncryptionKey и използвайте AE_ColumnMasterKey CMK, за да го криптирате. Можете да проверите дали създаването на CEK е било успешно със следната заявка.

SELECT * 
FROM sys.column_encryption_keys;

Понастоящем само новите двоични съпоставяния, съпоставянията с BIN2 суфикс, се поддържат за AE. Затова нека създадем таблица с подходящи съпоставяния за колоните със знаци.

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 Демо:Вмъкване на данните

Сега можете да опитате да вмъкнете ред данни със следното изявление.

INSERT INTO dbo.Table1
 (id, SecretDeterministic, SecretRandomized)
VALUES (1, N'DeterSec01', N'RandomSec1');

You get the error 206, error text:“Operand type clash:nvarchar is incompatible with nvarchar(4000) encrypted with (encryption_type ='DETERMINISTIC', encryption_algorithm_name ='AEAD_AES_256_CBC_HMAC_SHA_256', column_encryption_key_name ='AE_ColumnEncryptionKey', column_encryption_key_database_name ='AEDemo')” . SQL Server не може да криптира или декриптира данните. Трябва да промените данните от клиентско приложение. Можете да извършвате ограничен набор от операции върху таблицата от SQL Server. Например, можете да използвате израза TRUNCATE TABLE върху таблица с колони AE.

Създадох много просто клиентско приложение за Windows Console във Visual C#. Приложението всъщност просто извлича ключовете и вмъква един ред в таблицата, създадена с кода по-горе. Ето кода на C#.

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");            
        }
    }
}

Можете да стартирате C# кода от Visual Studio в режим на отстраняване на грешки или да изградите приложението. След това можете да стартирате приложението AEDemo.exe от командния ред или от SSMS в режим SQMCMD.

AE Демо:Четене на данните

След като стартирате приложението, трябва да опитате да прочетете данните от същата сесия в SSMS, която сте използвали за създаване на таблицата.

SELECT *
FROM dbo.Table1;

Можете да видите само криптирани данни. Сега отворете втори прозорец за заявка в SSMS. Щракнете с десния бутон върху този прозорец и изберете Connection, след което Change Connection. В диалоговия прозорец за връзка щракнете върху бутона Опции в долната част. Въведете AEDemo за името на базата данни и след това щракнете върху раздела Допълнителни параметри на връзката. В текстовото поле въведете „Настройка за шифроване на колона=разрешена“ (без двойни кавички). След това щракнете върху Свързване.

Опитайте отново да вмъкнете ред от SSMS. Използвайте следната заявка.

INSERT INTO dbo.Table1
 (id, SecretDeterministic, SecretRandomized)
VALUES (2, N'DeterSec2', N'RandomSec2');

Отново получих грешка. Тази версия на SSMS, която използвам, все още не може да параметризира ad-hoc вмъквания. Нека обаче се опитаме да прочетем данните със следната заявка.

SELECT * 
FROM dbo.Table1;

Този път заявката работи и получавате следния резултат:

Id SecretDeterministic SecretRandomized

— —————————————-

1 DeterSec1 RandomSec1

2 DeterSec2 RandomSec2

Ограничения на AE

Вече видяхте някои ограничения на Always Encrypted, включително:

Само BIN2 съпоставяния се поддържат за низове
Можете да индексирате само колони с детерминирано криптиране и да използвате ограничен набор от T-SQL операции за тези колони
Не можете да индексирате колони с произволно криптиране
AE е ограничен само до изданията Enterprise и Developer
Работата с AE в SSMS може да бъде болезнена

Моля, направете справка с Books Online за по-подробен списък с ограничения на AE. Въпреки това, моля, обърнете внимание и на силните страни на AE. Той е лесен за изпълнение, защото не се нуждае от модификации в приложение, с изключение на модификацията на низовете за връзка. Данните са криптирани от край до край, от паметта на клиента през мрежата до съхранението на база данни. Дори DBA не могат да преглеждат данните само в SQL Server; дори DBA се нуждаят от достъп до ключовото хранилище извън SQL Server, за да прочетат CMK. AE и други опции за криптиране в SQL Server предоставят пълен набор от възможности и от вас и бизнес проблема, който решавате, зависи да изберете подходящия метод.

Заключение

Прозрачното криптиране на данни е изключително лесно за използване. Въпреки това, защитата на данните е много ограничена. TDE защитава данните само в покой. Въпреки това, Always Encrypted е наистина мощна функция. Все още не е твърде сложен за изпълнение и данните са напълно защитени. Дори DBA не може да го види, без да има достъп до ключовете за криптиране. Надяваме се, че ограниченията за AE, особено ограничението за съпоставяне, ще бъдат премахнати в бъдещите версии на SQL Server.