پایه و اساس چنین عملکردی در 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 از دیتافایل ها محافظت میکند.
به ظاهر ما درخصوص کلیه کلیدها صحبت کردیم، ولی مطمئن هستم راجع به Server Certificate و مصرف آن برای شما سوالاتی بوجود آمده است. بگذارید کمی دیگر مبحث را بشکافیم، DMK و 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 محافظت میشود.
بد نیست یکبار دیگر به تصویر بالا نگاهی بیاندازید.
حال که کمی با سلسله مراتب کلیدها آشنا شدیم، میتوانیم نحوه پیاده سازی 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 اطمینان حاصل کرد:
|
[sql] –جهت ساختن DMK کد زیر را اجرا کنید –Check for master_key_encrypted_by_server |
قدم دوم: ساخت Server Certificate
|
[sql] –جهت ساخت سرتیفیکیتی با اسم مثالی Cert4TDE کد زیر را اجرا کنید –جهت بررسی ساخته شدن سرتیفیکیت کد زیر را اجرا کنید |
قدم سوم: ساخت Database Encryption Key-DEK
|
[sql] –جهت ساخت کلید DEK کد زیر را اجرا کنید |
قدم چهارم: فعال سازی TDE
|
[sql] Use master ALTER DATABASE AdventureWorks2014 SET ENCRYPTION ON [/sql] |
با توجه به آنکه پس از راه اندازی TDE اس کیو ال سرور در پس زیمنه شروع به Encrypt کردن فایل های شما میکند، ممکن است کمی کندی در سرور خود احساس کنید که البته خیلی نیست ولی چون SQL میخواهد کل اطلاعات را برای اولین بار Encrypt کند ممکن است برای بار اول این پروسه کمی طول بکشد و لی پس از اتمام آن دیگر شاهد این بار کاری نخواهید بود زیرا از این پس SQL Server بلافاصله به محض Check Point زدن و Write دیتا بر روی دیسک اقدام به Encrypt کردن دیتا میکند و این عمل بسیار کم بار است و حداکثر چیزی بین 2 تا 5 درصد بار کاری به CPU اضافه میکند، ولی در عوض شما با یک هزینه بسیار کم و بدن آنکه نیاز باشد حتی یک خط از کدهای نرم افزار یا SQL خود را تغییر دهید صاحب File Encryption شده اید.
جهت مونیتورینگ میزان پیشرفت عملیات Encryption در بدو راه اندازی TDE میتوانید از اسکریپت زیر استفاده کنید:
|
[sql] –To monitor encryption progress you can use this query |
توجه: شما میبایست از کلیدها و سرتیفیکیت های خود حتما Backup تهیه کنید، در غیر اینصورت ممکن است در شرایط خرابی تنوانید دیتابیس خود را Restore کنید!
درخصوص مزایا و معایب TDE و همچنین مبحث Backup گیری از کلیدها و نحوه Restore کردن دیتابیس های Encrypt شده بر روی دیگر سرورها، طی مقاله بعدی صحبت خواهم نمود.
منبع: آموزش برنامه نویسی نیک آموز
23 دیدگاه
مسعود طاهری
سلام مهندس
سید سیاوش گلچوبیان
تشکر از حسن نظر شما
فرشید علی اکبری
سلام
سید سیاوش گلچوبیان
سلام
روز شما بخیر، متاسفانه تو SQL Server 2014 تا جایی که میدونم نمیشه به هیچ وجه روی اطلاعاتی که داخل فایل گروپ MEMORY_OPTIMIZED_DATA ذخیره میشوند، TDE پیاده سازی کرد (البته باید ذکر کنم که شما میتونید روی دیتابیستون TDE رو فعال کنید، ولی فایل گروپ مذکور مشمول حال مزایای TDE نمیشه)، ولی میتونید به عنوان جایگزین برای حفاظت از اطلاعات داخل جداول In-Memory از متدهای Encryption دیتا های داخل جدول استفاده کنید. البته این با TDE متفاوته ولی امنیت اطلاعات رو با ناخوانا کردنشون برای افراد غیر مجاز تضمین میکنه.
باتشکر
فرشید علی اکبری
سلام
سید سیاوش گلچوبیان
متاسفانه تو نسخه SQL Server 2016 CTP2 هنوز همچین امکانی گنجانده نشده و نمیشه داده های درون فایل گروپ MEMORY_OPTIMIZED_DATA رو به کمک TDE، Encrypt کرد.
همونطور که اشاره فرمودید، استفاده از متدهای Encryption ذاتا بحث های Performance ای رو همیشه با خودش به همراه داشته، حتی تو TDE (البته به لطف Async بودن این فرآیند تو TDE و اعمال اون در حین CheckPoint این اثر منفی از دید ما خیلی کمرنگتر شده) ولی متاسفانه در خصوص In_Memory آبجکت ها فعلا راه دیگه ای به جز Encryption دیتاهای داخل جدول به ذهن من نمیرسه، البته میشه جهت بهبود Performance در روش رمز نگاری اطلاعات جداول، به جای استفاده مستقیم از Asymmetric Key ها از Symmetric Key های Encrypt شده توسط Asymmetric Key استفاده کرد که هم Performance رو تا حدود قابل توجهی بهبود میده و هم امنیت رو خدشه دار نمیکنه.
ولی نهایتا هزینه ای که پرداخت میکنیم بابت Encryption زیاده، حتی در روش TDE (متاسفانه یکی از مهمترین ابزارهای ما جهت افزایش Performance که همون Compress کردن جداول و ایندکس ها هستش چه در TDE و چه در روش های دیگه Encryption بی ارزش میشه و کارآییش رو از دست میده)
امین ثریا
سلام ودرود
تو SQL Server 2014 و In memory oltp همون طور ک میدونید دیتا فایلها و دلتافایلها ب صورت کدهای محلی توسط کامپایلر سی به وجود میان واگه به مسیر root فایلها برید و یکی از فایلها رو ب عنوان نمونه نگاه کنید مشاهده میکنید ک ماهیت اونها و محتواشون ب صورت کدهای سی اند ب طوری ک نامفهومند و handle کردنشون هم تنها توسط خود SQL قابل انجامه .
حالا دقیقا نمیدونم آیا با این وجود هنوز باید نگران امنیتشون باشیم یا این که منظور شما فایلهای با معماری Disk Base هست؟!
سید علی سیدنژاد جوپاری
سلام
تشکر از مقاله مفیدتون لطفا این بحث رو ادامه و بیشتر گسترش بدید
m
عالی بود با تشکر از زحماتتون
جواد
سلام
خیلی ممنون خیلی مقالتون مفیده
قسمت بعدیش رو کی میذارید؟
مجتبی شهریور
سلام
مهندس متشکرم
خیلی عالی بود منتظر قسمتهای بعدی هستیم
ساناز احمدی
سلام
خیلی عالی بود احسنت….
tiyara9090@hotmail.com
salam
mr30
ghsmat bad ki up mi konid???????????????????????
سید سیاوش گلچوبیان
باسلام و تشکر از نظرات دوستان، انشا الله تا 7 مرداد قسمت دوم این مقاله را منتشر خواهم کرد.
فرشید علی اکبری
سلام
جواد
با سلام و خسته نباشید
ببخشید قسمت دوم مقاله رو کی می گذارید؟
باتشکر
حسن ضرابی
با سلام و خسته نباشید خدمت آقای سید سیاوش گلچوبیان
از مقاله بسیار عالیتون خیلی ممنونم واقعا زحمت کشیدید
من یک سئوال داشتم
اگر ما بخواهیم از روش tde برای رمز گذاری استفاده کنیم که کسی به بکاپ های ما دسترسی نداشته باشد من یک روشی به ذهنم خورد که خواستم از شما سئوال کرده باشم که ببینم این روش درست هست یا خیر.
برای بکاپ گرفتن یک دیتابیس با پسوند bak در روز و زمان خواستی که این بکاپ که بخواهد گرفته شود شاید هم در روز چند بار گرفته شود ما بیاییم کل عملیات را انجام بدهیم که من دیگر واردش نمی شم مثلا در sp کل کدها را می نویسیم و دیتابیس رمزگذاری می شود یعنی کل کارها برای گرفتن بکاپ به صورت tde انجام می شود بعد بکاپ را می گیریم بعد که بکاپ را گرفتیم بیاییم کل دیتابیس را به حالت اولیه برگردانیم یعنی تمام رمزگذاری را drop کنیم و انگار حالت tde در دیتابیس وجود ندارد باز در زمان خواص که بخواهد بکاپ از دیتابیس بگیرد باز اول tde را انجام بدهد بعد بکاپ بگیرد و بعد حالت tde غیر فعال شود
آیا این روش اصولی هست
با تشکر از شما
خیلی مچکرم
مسعود طاهری
سلام دوست عزیز
حسن ضرابی
با سلام و خسته نباشید خدمت آقای مسعود طاهری عزیز و آقای سید سیاوش گلچوبیان
بابت مقاله بسیار عالیشون
در view سیستمیsys.dm_database_encryption_keys
که در مقاله بالا توضیح داده شد من در مورد چند فیلد این view سیستمی سئوال
داشتم
یکی در مورد فیلد
create_date هست فکر می کنم وقتی ما
encrypt را
on می کنیم و وقتی
encrypt کردن دیتابیس به پایان رسید این فیلد تاریخ مورد نظر را می گیرد
یکی در مورد فیلد
modify_date هست که اگر یک توضیحی بدهید که چه موقع تاریخ به روز می شود و تفاوت آن با
فیلد
regenereate_date در چیست
در مورد فیلد
set_date فکر می کنم که و تستی که کردم وقتی
encrypt را
off می کنیم و بعد
on می کنیم تاریخ آن تغییر می کند خواستم بدونم تستم درست هست یا خیر
و هم در مورد فیلد
opened_date هست که اگر یک توضیحی بدهید بسیار سپاسگزار می شوم و خیلی محبت می کنید
و
آخر هم در مورد فیلد encryption_state هست که خیلی بر روی این فیلد تست کردم فقط
مورد 4 و 6 را متوجه نشدم چون 1 یعنی encrypt نشده است و 2 یعنی در حالی encrypt
کردن هست و در حال انجام کار هست که تمام شود و وقتی که حالت encrypt
کردن به درستی تمام شد عدد 3 را در فیلد encryption_state ذخیره می کند و عدد 5 هم یعنی encrypt
کردن دیتابیس دارد غیر فعال می شود و در فیلد precent_complte
درصد تمام شدن را انجام می دهد که وقتی تمام شد به جای عدد 5 عدد 1 به را ذخیره می
کند عدد 1 یعنی encrypt
نشده است
حالا
اگر محبت کنید و توضیح دهید که عدد 4 و 6 چه کاری انجام می دهند ممنون می شوم
با
سپاس از شما و سایت خیلی عالیتون
ممنونم
که پاسخ می دهید
با
تشکر از شما
مسعود طاهری
سلام در حال حاضر امکان تست دقیق برای فراهم نیست تا همه حالت ها را بتوانم براتون جواب بدهم اما می توانید از لینک زیر به خوبی کمک بگیرید
فرزام نوذری
عالی بود <3
فاطمه
سلام.
در یک دیتابیس که انکریپشن on شده است
دیگه نمیخوام دیتابیسم انکریپت باشه و میخوام این tde رو از دیتابیسم حذف کنم. چیکار باید بکنم؟؟؟
فاطمه
سلام.
چطور میتوانم انکریپت کردن دیتابیس را غیرفعال کنم؟؟؟
فاطمه
اگر نخوام دیگه دیتابیسم انکریپت شده باشه
چیکار کنم؟؟؟
فاطمه
سلام
چطور میتونم انکریپت کردن دیتابیس رو غیرفعال کنم؟|؟
اگر نخوام دیگه دیتابیسم انکریپت شده باشه
چیکار باید کنم؟؟؟
آرزو محمدزاده
درود وقت بخیر
اگه منظورتون آپدیت ssms هست که پیغام میده اپدیت موجود هست و شما باید دستی اپدیت کنید اما اگه منظورتون مورد دیگه ای هست در تنظیمات ویندوز از بخش Product Microsoft تیک آپدیت را بردارید.
سپاس از همراهی شما