Transparent Data Encryption | بخش اول

مقدمه

SQL Server راهکار ممانعت از چنین سوء استفاده ای را اینگونه دیده است

 اما DMK و Server Certificate چیست ؟و چگونه SQL Server مدعی میشود با حفاظت DEK به کمک DMK و Server Certificate میتوان امنیت را تضمین نمود؟

DMK یک کلید در سطح دیتابیس Master میباشد

(دقت شود که این کلید در User Database ذخیره نمیگردد! در Master Database ذخیره میشود) زمانیکه شما DEK خود را توسط DMK رمزنگاری میکنید، یا به عبارتی بین DEK و DMK وابستگی (Dependency) ایجاد میکنید، میتوانید مطمئن باشید که اگر کسی دیتافایل دیتابیس شما را سرقت نمود یا Backup های شما را سرقت نمود، نمیتواند آنها را بازیابی/Restore نماید زیرا جهت بازکردن آنها علاوه بر DEK که در درون User Database قراردارد به DMK نیز که در دیتابیس Master قرار گرفته نیاز دارد، پس به واسطه وجود این Dependency بین کلیدها سارق نمیتواند کلید DEK را از حالت Encrypt خارج کند، و در نتیجه کلید DEK را بدست نیاوره و دیتافایل را نیز نمیتواند Decrypt نماید.

 سوال دومی که بوجود می آید این است که خود DMK چگونه محافظت میگردد ؟ DMK به کمک کلید دیگری به نام SMK محافظت (Encrypt) میشود، SMK نیز خود یک کلید است که در سطح Instance سرور و طی پروسه نصب SQL Server به طور خودکار ساخته میشود. فکر میکنید، ماجرای کلید بازی تمام شده است ؟ خیر! خود کلید SMK نیز توسط DPAPI در سطح Windows رمزنگاری شده و محافظت میگردد، حالا میتوانید نفس راحتی بکشید، کلید بازی تمام شد. حال اگر یک نگاه مجدد به کل پروسه Encryption کلیدها بیاندازید متوجه میشوید که منظور از سلسله مراتب کلیدها چیست : Windows از SMK محافظت میکند، SMK از DMK محافظت میکند، DMK از DEK محافظت میکند و نهایتا DEK از دیتافایل ها محافظت میکند.

 اما این Server Certificate چیست؟

ماجرا از اینجا شروع میشود که ما دو نوع کلید برای مقاصد رمز نگاری داریم : یکی Symmetric Key و دیگری Asymmetric Key یا معادل فارسی آنها کلید متقارن و کلید نا متقارن، Symmetric Key به طور ساده میشود “اسم شب” یا همان رمز ثابت (Shared Secret) که دو طرف مذاکره باید آن را بدانند و به کمک آن پیام های خود را رمزنگاری و رمزگشایی کنند، اما Asymmetric Key که دومین نوع کلید میباشد، امنیت بالاتری را فراهم ساخته و علاوه بر رمز نگاری این امکان را میدهد که طرفین مذاکره را نیز شناسایی کنیم (از آن به عنوان Public Key و Private Key نیز یاد میشود).

 این چه ربطی به TDE دارد؟

خوب جریان اینه:  DMK یک Symmetric Key است و شما اگر بخواهید از TDE استفاده کنید باید DEK را با استفاده از یک Asymmetric Key رمز نگاری و محافظت کنید، بنابراین نیاز به یک کلید Asymmetric است، این کلید Asymmetric را میتوان به واسطه Server Certificate ها ایجاد کرد. شما با ساخت یک Server Certificate به کمک Master Key اقدام به تولید یک Asymmetric Key میکنید که DEK با استفاده از این Server Certificate محافظت میشود. 

 --جهت ساختن DMK کد زیر را اجرا کنید
USE master
GO
IF NOT EXISTS(SELECT 1 FROM sys.symmetric_keys where name =
'##MS_DatabaseMasterKey##')
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'myDMKp@ssw0rd'
GO
--Check for master_key_encrypted_by_server
Use master
IF NOT EXISTS (select 1 from sys.databases where
[is_master_key_encrypted_by_server] = 1)
ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY
GO

قدم دوم: ساخت Server Certificate

--جهت ساخت سرتیفیکیتی با اسم مثالی Cert4TDE کد زیر را اجرا کنید
Use master
IF NOT EXISTS (SELECT 1 FROM sys.certificates WHERE name = 'Cert4TDE')
CREATE CERTIFICATE Cert4TDE
WITH SUBJECT = 'Certificate for TDE',
START_DATE = '01/01/2013',
EXPIRY_DATE = '01/01/2025';
GO
--جهت بررسی ساخته شدن سرتیفیکیت کد زیر را اجرا کنید
select * from sys.certificates

قدم سوم: ساخت Database Encryption Key-DEK

--جهت ساخت کلید DEK کد زیر را اجرا کنید
Use AdventureWorks2014
Go
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256 --Supported encryption algorithms are AES with 128-bit, 192‑bit, or 256‑bit keys or 3 Key Triple DES
ENCRYPTION BY SERVER CERTIFICATE Cert4TDE

  قدم چهارم: فعال سازی TDE

Use master
GO
ALTER DATABASE AdventureWorks2014 SET ENCRYPTION ON

 با توجه به آنکه پس از راه اندازی TDE اس کیو ال سرور در پس زیمنه شروع به Encrypt کردن فایل های شما میکند، ممکن است کمی کندی در سرور خود احساس کنید که البته خیلی نیست ولی چون SQL میخواهد کل اطلاعات را برای اولین بار Encrypt کند ممکن است برای بار اول این پروسه کمی طول بکشد و لی پس از اتمام آن دیگر شاهد این بار کاری نخواهید بود زیرا از این پس SQL Server بلافاصله به محض Check Point زدن و Write دیتا بر روی دیسک اقدام به Encrypt کردن دیتا میکند و این عمل بسیار کم بار است و حداکثر چیزی بین ۲ تا ۵ درصد بار کاری به CPU اضافه میکند، ولی در عوض شما با یک هزینه بسیار کم و بدن آنکه نیاز باشد حتی یک خط از کدهای نرم افزار یا SQL خود را تغییر دهید صاحب File Encryption شده اید.
 جهت مونیتورینگ میزان پیشرفت عملیات Encryption در بدو راه اندازی TDE میتوانید از اسکریپت زیر استفاده کنید:

 --To monitor encryption progress you can use this query
select DB_NAME(database_id), * from sys.dm_database_encryption_keys