Transparent Data Encryption | بخش اول

Transparent Data Encryption | بخش اول

نوشته شده توسط: سیاوش گلچوبیان
۰۶ تیر ۱۳۹۴
زمان مطالعه: 12 دقیقه
0
(0)

مقدمه

Transparent Data Encryption یا  همان TDE قابلیتی است که به واسطه آن قادر خواهید بود تا از سرقت اطلاعات دیتابیس خود به واسطه عملیاتهایی همچون دزدیدن Backup و یا کپی کردن فایل های دیتابیس، توسط اشخاص ثالث محافظت کنید، البته این به آن معنی نیست که دیگران نمیتوانند Backup ها یا دیتا فایلهای دیتابیس شما را کپی کنند، بلکه بدین معنا است است که اگر کسی فایلهای شما را سرقت کرد به واسطه وجود این قابلیت نمیتواند به اطلاعات موجود در آن فایلها دسترسی پیدا نماید. 
پایه و اساس چنین عملکردی در SQL Server بر Encrypt کردن دیتا فایل ها بنا نهاده شده است (توجه شود که Data File Encryption با Data Encryption متفاوت است، TDE از Data File Encryption استفاده مینماید) و با توجه به آنکه Data File های SQL Server شامل Data file (*.mdf|*.ndf), Log File (*.ldf), Backup file (*.bak) l ها میشود، میتوان به راحتی حدس زد که هر سه نوع این فایلها به کمک TDE امن و غیر قابل نفوذ خواهند شد.
SQL Server جهت Encrypt کردن دیتافایلها از تعدادی کلید (سلسله مراتبی از کلیدها) جهت رمز نگاری فایلهای شما استفاده میکند، این کلیدها عبارتند از :

  • Service Master Key – SMK
  • Database Master Key (DMK), Server Certificate
  • Database Encryption Key – DEK

 SQL Server به کمک کلید DEK اقدام به Encrypt یا Decrypt کردن دیتافایلهای دیتابیس شما مینماید و با اینکار دیتافایلهای شما برای اشخاصی که کلید DEK را ندارند غیرقابل دسترس میشود، ولی یک نکته مهم در اینجا وجود دارد، اینکه DEK در خود User Database ذخیره میشود ! پس اگر کسی دیتافایلهای ما را سرقت نماید این امکان وجود دارد که بتواند از درون دیتافایلهای ما کلید DEK را پیدا کند و فایل ما را Decrypt کرده و به کلیه اطلاعات موجود در آن دسترسی پیدا کند. بنابراین ما تنها به واسطه استفاده از DEK به امنیت کامل نخواهیم رسید، پس راهکار چیست؟

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

Admin های گرامی، در قدم اول دیتابیس خود را با کلید DEK رمزنگاری و محافظت کنید، سپس کلید DEK خود را نیز با استفاده از کلید DMK و Server Certificate رمزنگاری کنید، بدین شیوه (ایجاد وابستگی بین DEK و DMK) امنیت شما تضمین میگردد !

 اما 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 از دیتافایل ها محافظت میکند.

DPAPI -> SMK -> DMK -> Server Certificate -> DEK -> File Protection

 به ظاهر ما درخصوص کلیه کلیدها صحبت کردیم، ولی مطمئن هستم راجع به Server Certificate و مصرف آن برای شما سوالاتی بوجود آمده است. بگذارید کمی دیگر مبحث را بشکافیم، DMK و Server Certificate دو موجودیت مجزا هستند، هر چند که ما در طول متن، اکثر جا ها این دو را با یکدیگر استفاده می کردیم.

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

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

بیش از این وارد بحث رمز نگاری نمیشوم زیرا مفصل است، فقط همینقدر بدانید که Asymmetric Key بسیار قویتر از Symmetric Key است ولی در عوض رمز نگاری و رمز گشایی اطلاعات بوسیله Asymmetric Key بسیار CPU بر تر از Symmetric Key است و به همین دلیل معمولا از Asymmetric Key بدلیل کاهش Performance استفاده مستقیم و مداوم نمیشود.

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

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

حال که کمی با سلسله مراتب کلیدها آشنا شدیم، میتوانیم نحوه پیاده سازی TDE را نشان دهیم:

  • قدم اول : ساخت Database Master Key-DMK
  • قدم دوم: ساخت Server Certificate
  • قدم سوم: ساخت Database Encryption Key-DEK
  • قدم چهارم: فعال سازی TDE

 قدم اول: ساخت Database Master Key-DMK

از آنجا که DMK مانند SMK از همان اول توسط خود SQL ساخته نمیشود، باید خودتان آن را بسازید، البته به خاطر داشته باشید که درصورت فعال کردنی برخی Feature ها در SQL Server کلید DMK ممکن است برای شما ساخته شده باشد، به همین دلیل قبل از ساخت DMK باید از عدم وجود کلید DMK اطمینان حاصل کرد:

 --جهت ساختن 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 کردن دیتا میکند و این عمل بسیار کم بار است و حداکثر چیزی بین 2 تا 5 درصد بار کاری به 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

  
توجه: شما میبایست از کلیدها و سرتیفیکیت های خود حتما Backup تهیه کنید، در غیر اینصورت ممکن است در شرایط خرابی تنوانید دیتابیس خود را Restore کنید!
درخصوص مزایا و معایب TDE و همچنین مبحث Backup گیری از کلیدها و نحوه Restore کردن دیتابیس های Encrypt شده بر روی دیگر سرورها، طی مقاله بعدی صحبت خواهم نمود.

چه رتبه ای می‌دهید؟

میانگین 0 / 5. از مجموع 0

اولین نفر باش

title sign
معرفی نویسنده
مقالات
2 مقاله توسط این نویسنده
محصولات
7 دوره توسط این نویسنده

سیاوش گلچوبیان مدرس و مشاور ارشد SQL Server و هوش تجاری می باشد از دیگر تخصص های او به: طراحی و بهینه سازی ساختارهای OLTP و Data Warehouse ، متخصص و مشاور توسعه BI، سرویس‌های مایکروسافت SQL Server Integration Services، سرویس‌های تجزیه و تحلیل و داشبورد [SSRS , SSAS , PowerBI]، رئیس واحد دیتابیس شرکت خودروسازی سایپا، مشاوره و اجرا در حوزه‌های BI و DBA در گروه گلدیران، مشاوره و اجرا در حوزه‌های BI و DBA در گروه صنعتی گلرنگ، مشاوره و اجرا در حوزه‌های BI و DBA در شرکت خدمات فنی رنا، طراح و مجری پروژه پیاده سازی BI در شرکت پتروشیمی امیرکبیر شاره کرد.

title sign
معرفی محصول
title sign
دیدگاه کاربران

    • درود وقت بخیر

      اگه منظورتون آپدیت ssms هست که پیغام میده اپدیت موجود هست و شما باید دستی اپدیت کنید اما اگه منظورتون مورد دیگه ای هست در تنظیمات ویندوز از بخش Product Microsoft تیک آپدیت را بردارید.

      سپاس از همراهی شما

    • درود وقت بخیر
      اگه منظورتون آپدیت ssms هست که پیغام میده اپدیت موجود هست و شما باید دستی اپدیت کنید اما اگه منظورتون مورد دیگه ای هست در تنظیمات ویندوز از بخش Product Microsoft تیک آپدیت را بردارید.
      سپاس از همراهی شما