پیوست

انواع Encryption در SQL Server

sql encryption img

انواع Encryption در SQL Server

زمان مطالعه: ۶ دقیقه

مقدمه

محافظت از داده ها برای اطمینان از انطباق سازمان شما با استانداردهای انطباق نظارتی مانند GDPR و تأمین انتظارات مشتریان و شرکای تجاری حیاتی است. نقض داده ها نه تنها می تواند جریمه های زیادی در پی داشته باشد، بلکه صدمه به اعتبار نیز می تواند به همان اندازه بزرگ باشد. برای کمک، Microsoft SQL Server از ۵ نوع رمزگذاری مختلف برای محافظت از داده ها پشتیبانی می کند. در این مقاله هریک از آنها و مکان استفاده از آنها توضیح داده شده است.

 

 

SSL Transport Encryption (رمزگذاری لایه انتقال سوکت های امن)

 

مانند وب سایت هایی که ترافیک بین مرورگر و سرور را ایمن می کنند، می توان SQL Server را طوری تنظیم کرد که از Secure Sockets Layer (SSL) برای رمزگذاری ترافیک هنگام عبور از بین سرور و برنامه سرویس گیرنده استفاده کند. علاوه بر این ، مشتری می تواند با استفاده از گواهی سرور، هویت سرور را تأیید کند. SSL فقط هنگام عبور از شبکه از داده ها محافظت می کند ، اما برخلاف بسیاری از اشکال دیگر رمزگذاری SQL Server ،SSL در همه نسخه های پشتیبانی شده SQL Server و در همه نسخه ها در دسترس است.

قبل از فعال کردن SSL، باید گواهی را در SQL Server نصب کنید. بهترین راه برای انجام این کار درخواست مجوز از سازمان صدور گواهینامه سازمانی خود (Certification Authority) است. ویندوز سرور می تواند به عنوان CA پیکربندی شود و می توانید مشتری ها را طوری تنظیم کنید که به گواهینامه هایی که صادر می کند اعتماد کنند. متناوباّ، می توان از گواهینامه های خود امضا شده استفاده کرد، اگرچه این برای آزمایشی در محیط مناسب است.

 

sql encryption

 

 

SQL Server Transparent Data Encryption (رمزگذاری داده های شفاف)

 

Transparent Data Encryption (TDE) در SQL Server با رمزگذاری داده های پایگاه داده و ثبت پرونده ها بر روی دیسک، از داده ها در حالت استراحت محافظت می کند. برای برنامه های موجود مشتری به طور شفاف کار می کند، بنابراین با فعال کردن TDE نیازی به تغییر نیست. TDE از رمزنگاری در زمان واقعی در سطح صفحه استفاده می کند. صفحات قبل از نوشتن بر روی دیسک ، بدون افزایش اندازه داده ها و پرونده های پرونده رمزگذاری می شوند، و صفحات هنگام خواندن در حافظه رمزگشایی می شوند. TDE فقط در نسخه های Enterprise SQL Server در دسترس است. همچنین برای پایگاه داده Azure SQL ،Azure SQL Data Warehouse و Parallel Data Warehouse کار می کند.

رمزگذاری TDE دارای ساختار سلسله مراتبی است ، با Windows Data Protection API (DPAPI) در بالای سلسله مراتب نشسته و برای رمزگذاری کلید اصلی سرویس (Service Master Key) استفاده می شود. شما می توانید از SMK برای رمزگذاری اطلاعات کاربری، رمزهای عبور سرور پیوند داده شده و کلیدهای اصلی پایگاه داده (Database Master Keys) مستقر در پایگاه های مختلف استفاده کنید. SQL DMK یک کلید متقارن است که از کلیدهای خصوصی گواهینامه ها و کلیدهای نامتقارن ذخیره شده در پایگاه داده محافظت می کند.

SQL Server می تواند برای استفاده با TDE گواهینامه هایی با امضای خود تولید کند یا می توانید از CA یک گواهینامه درخواست کنید (این روش معمول تر است). اگر تصمیم دارید TDE را فعال کنید ، باید از گواهی و کلید خصوصی مرتبط با گواهی پشتیبان تهیه کنید. شما باید پایگاه داده را در SQL Server دیگری بازیابی یا ضمیمه کنید. اگر TDE را روی هر پایگاه داده SQL Server دیگری فعال کنید، پایگاه داده سیستم tempdb نیز رمزگذاری شده است. اگر TDE را غیرفعال کنید، باید گواهینامه و کلید خصوصی را نگه دارید زیرا قسمت هایی از گزارش تراکنش می تواند رمزگذاری شود تا زمانی که نسخه پشتیبان تهیه کنید.

TDE همچنین به یک کلید رمزگذاری پایگاه داده (Database Encryption Key) نیاز دارد، که یا یک کلید متقارن است که با استفاده از یک گواهی ذخیره شده در پایگاه داده اصلی محافظت می شود، یا یک کلید نامتقارن است که توسط یک سرویس با استفاده از مدیریت کلید توسعه پذیر (Extensible Key Management) محافظت می شود ، مانند Microsoft Azure Key Vault. پرونده های پشتیبان از پایگاه داده های فعال شده با TDE با استفاده از DEK رمزگذاری می شوند ، بنابراین در حین عملیات بازیابی ، گواهی محافظت از DEK باید در دسترس باشد.

کلیدهای متقارن از رمز عبور مشابه برای رمزگذاری و رمزگشایی داده ها استفاده می کنند. کلیدهای نامتقارن از یک رمز عبور برای رمزگذاری داده ها (کلید عمومی) و رمز عبور دیگری برای رمزگشایی داده ها (کلید خصوصی) استفاده می کنند. برای ایجاد گواهینامه ها می توانید از دستور CREATE CERTIFICATE و از دستورات CREATE SYMMETRIC KEY و CREATE ASYMMETRIC KEY Transact-SQL برای ایجاد کلیدهای رمزگذاری پایگاه داده استفاده کنید.

 

 

 

db پیوست

 

Backup Encryption (رمزگذاری پشتیبان)

 

رمزگذاری پشتیبان مانند TDE کار می کند اما پشتیبان گیری SQL را به جای داده فعال و پرونده های پرونده رمزگذاری می کند. رمزگذاری پشتیبان در SQL Server 2014 به بعد در دسترس است. می توانید رمزگذاریAES 128 ، AES 192 ، AES 256 یا Triple DES را مشخص کنید و از کلید گواهی یا نامتقارن ذخیره شده در EKM استفاده کنید. علاوه بر این، امکان فعال کردن رمزگذاری پشتیبان TDE و پشتیبان گیری وجود دارد، اگرچه باید از گواهینامه ها یا کلیدهای مختلف استفاده کنید.

درست مانند TDE، اگر Backup Encryption را فعال کنید ، باید از گواهی یا کلید نیز نسخه پشتیبان تهیه کنید. بدون کلید یا گواهی ، از پرونده پشتیبان برای بازیابی داده ها نمی توان استفاده کرد. هنگام استفاده از پشتیبان SQL Server Managed Backup در Microsoft Azure ، پشتیبان گیری نیز می تواند رمزگذاری شود.

شایان ذکر است اگر از گواهی رمزگذاری پشتیبان استفاده می کنید ، هنگام بازیابی داده ها باید گواهینامه اصلی را داشته باشید. این بدان معنی است که گواهی باید همان انگشت نگاری را داشته باشد که هنگام ایجاد نسخه پشتیبان تهیه شده است. تمدید گواهینامه ها یا تغییر آنها به هر طریقی می تواند باعث تغییر اثر انگشت شود.

 

 

Column/Cell-Level Encryption (رمزگذاری در سطح ستون / سلول)

 

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

 

 

cryptographic key

 

Encryption Key Management(مدیریت کلید رمزگذاری)

 

همانند TDE ، قبل از استفاده از رمزگذاری در سطح سلول ، باید یک کلید اصلی (DMK) ایجاد کنید. چهار رمز برای رمزگذاری اطلاعات با استفاده از رمزگذاری در سطح سلول وجود دارد:

 

  • برای رمزگذاری و رمزگشایی داده ها می توانید از عبارت عبور استفاده کنید ، اما باید رویه ها و عملکردهای (Procedures & Functions) ذخیره شده را رمزگذاری کنید. در غیر این صورت ، می توان به عبارت عبور (Passphrase) در فراداده (Meta Data) دسترسی داشت.
  • کلیدهای نامتقارن (Asymmetric Keys) امنیت بالایی را ایجاد می کنند اما می توانند در عملکرد تأثیر داشته باشند.
  • کلیدهای متقارن (Symmetric Keys) معمولاً به اندازه کافی قوی هستند و تعادل خوبی بین امنیت و عملکرد ایجاد می کنند.
  • گواهینامه ها تعادل خوبی بین امنیت و عملکرد را نیز ایجاد می کنند و می توانند با کاربر پایگاه داده مرتبط شوند.

 

 

 

Always Encrypted (همیشه رمزگذاری شده)

 

همیشه رمزگذاری شده بدون اینکه کلیدهای رمزگذاری موتور پایگاه داده را فاش کند ، داده های حساس را در برنامه های مشتری رمزگذاری می کند ، و این امر جدایی بین دارندگان داده و مدیران داده را فراهم می کند. به عنوان مثال ، با فعال بودن همیشه رمزگذاری شده ، می توانید مطمئن باشید که مدیران پایگاه داده شما قادر به خواندن اطلاعات حساس نیستند. همانطور که از نام آن مشخص است ، داده ها در حالت استراحت رمزگذاری می شوند و اگر در سیستم شخص ثالث مانند Azure استفاده شوند ، رمزگذاری می شوند.

همیشه رمزگذاری شده می تواند برای ستون های پایگاه داده جداگانه پیکربندی شود. از دو نوع کلید استفاده می شود: کلیدهای رمزگذاری ستون و کلیدهای اصلی ستون. کلیدهای رمزگذاری ستون از داده ها در یک ستون محافظت می کنند و کلیدهای اصلی ستون “کلیدهای محافظ کلید” هستند که یک یا چند کلید رمزگذاری ستون را رمزگذاری می کنند. کلیدهای اصلی ستون در فروشگاه های کلید قابل اعتماد خارجی مانند Azure Key Vault ذخیره می شوند.

روند رمزگذاری برای برنامه های مشتری شفاف است اما به یک درایور ویژه در رایانه های مشتری نیاز دارد. Always Encrypted در SQL Server 2016 به بعد در دسترس است ، اما فقط در نسخه های Enterprise وجود دارد. به دلیل نیازهای جانبی اضافی مشتری ، Always Encrypted به بهترین وجهی مناسب شرایطی است که جدایی صاحبان داده و مدیران یک نیاز اصلی است.

 

 

 

 

sheybani
ترجمه: علی شیبانی

منبع: سایت نت ریکس (netwrix.com)

 

 

امنیت پیوست

 

[کل: ۳ میانگین: ۳.۷]
اشتراک در
اطلاع از
1 دیدگاه
قدیمی‌ترین
تازه‌ترین بیشترین رأی
بازخورد (Feedback) های اینلاین
مشاهده همه دیدگاه ها
نیک آیین
1 سال قبل

ممنون بابت تهیه این مقاله
خسته نباشید