SQL Server 2016 مشفر دائمًا: سهل التنفيذ وصعب الاختراق

البيانات هي أحد الأصول الرئيسية لأي شركة ، وخاصة بيانات المعاملات التي تحتوي على أسرار تجارية مثل السجلات المالية أو الصحية. تكون البيانات أكثر عرضة للخطر أثناء النقل بين الخادم الذي يخزنها والعميل الذي يطلبها.

يتمثل النهج القياسي لضمان الأمان في تشفير البيانات على الخادم واستخدام بروتوكول HTTPS الذي يدعم بروتوكول SSL لتأمين البيانات أثناء النقل. ومع ذلك ، ماذا لو تمكنا من زيادة مستوى الأمان إلى أبعد من ذلك ، باستخدام HTTPS وإرسال البيانات بتنسيق مشفر عبر خط الاتصال ، فقط لفك تشفير البيانات على العملاء الذين لديهم شهادات صالحة؟ هذا النهج من شأنه أن يجعل هجوم الرجل في الوسط (MITM) التقليدي أكثر صعوبة.

حل Microsoft لهذه المشكلة هو Always Encrypted ، وهي طريقة لإرسال البيانات المشفرة عبر خط الأنابيب وفك تشفيرها فقط من قبل المستخدمين الذين لديهم حق الوصول إلى الشهادات الصالحة. لذلك ، حتى إذا حصل المهاجم على البيانات ، بدون شهادة مناسبة مخزنة على جهاز العميل ، ستكون البيانات عديمة الفائدة.

توضح هذه المقالة كيفية إعداد واستخدام ميزة التشفير دائمًا ، ويوصى بقراءتها لأي شخص يرسل بيانات مهمة عبر خطوط الاتصال العامة ، حتى لو كانت مؤمنة باستخدام بروتوكول SSL.

المفهوم الكامن وراء التشفير دائمًا

Always Encrypted هي تقنية تشفير من جانب العميل قدمتها Microsoft مع SQL Server 2016. تحافظ ميزة التشفير دائمًا على تشفير البيانات تلقائيًا ، ليس فقط عند كتابتها ، ولكن أيضًا عند قراءتها بواسطة تطبيق معتمد. بخلاف تشفير البيانات الشفافة ، الذي يقوم بتشفير البيانات وملفات السجل على القرص في الوقت الفعلي ولكنه يسمح بقراءة البيانات من قبل أي تطبيق يستفسر عن البيانات ، يتطلب تطبيق Always Encrypted من تطبيق العميل الخاص بك استخدام برنامج تشغيل ممكّن دائمًا للتشفير للتواصل مع قاعدة البيانات. باستخدام برنامج التشغيل هذا ، ينقل التطبيق بأمان البيانات المشفرة إلى قاعدة البيانات التي يمكن فك تشفيرها لاحقًا فقط بواسطة تطبيق لديه حق الوصول إلى مفتاح التشفير. يمكن لأي تطبيق آخر يستعلم عن البيانات أيضًا استرداد القيم المشفرة ، ولكن لا يمكن لهذا التطبيق استخدام البيانات بدون مفتاح التشفير ، مما يجعل البيانات عديمة الفائدة. بسبب بنية التشفير هذه ، لا يرى مثيل SQL Server مطلقًا الإصدار غير المشفر من البيانات.

في هذا الوقت ، برامج التشغيل الوحيدة الممكّنة دائمًا هي .NET Framework Data Provider لـ SQL Server ، الأمر الذي يتطلب تثبيت .NET Framework الإصدار 4.6 على جهاز الكمبيوتر العميل ، وبرنامج تشغيل JDBC 6.0. من المحتمل أن يتغير ذلك بمرور الوقت ، ولكن هذه هي المتطلبات الرسمية للتشفير دائمًا اعتبارًا من أبريل 2017.

لكن لماذا نحتاج هذه التكنولوجيا؟ هناك عدة أسباب وجيهة لاستخدام ميزة التشفير دائمًا:

• الأمان - البيانات مطلوبة دائمًا لتكون آمنة. الآن بعد أن تم اختراق SSL ، تملأ ميزة "التشفير الدائم" الفجوة بطبقة أخرى من حماية خط أنابيب النقل.
• الدعم التنظيمي - يجب تشفير البيانات والحفاظ عليها من أعين DBA المتطفلين من خلال المزيد والمزيد من لوائح الصناعة ، في المقام الأول في صناعات التمويل والاتصالات. هذا موصوف في معيار PII ("معلومات التعريف الشخصية") الذي ينص على وجوب حماية أشياء مثل أرقام بطاقات الائتمان وأرقام الضمان الاجتماعي والأسماء والعناوين ، وإلا يمكن معاقبة مالك البيانات بشدة.

كيفية استخدام ميزة التشفير دائمًا

يتطلب استخدام ميزة التشفير دائمًا قدرًا صغيرًا من التحضير داخل خادم قاعدة البيانات الذي يخزن الجداول المشفرة. التحضير هو عملية من خطوتين:

• قم بإنشاء تعريف المفتاح الرئيسي للعمود
• قم بإنشاء مفتاح تشفير العمود

مفتاح العمود الرئيسي

إذن ما هو مفتاح العمود الرئيسي؟

المفتاح الرئيسي للعمود هو شهادة يتم تخزينها في مخزن شهادات Windows (والذي يستخدم العرض التوضيحي كخيار تخزين شهادة) ، ووحدة أمان أجهزة تابعة لجهة خارجية (اسم عام لحلول الجهات الخارجية للتثبيت والإدارة والاستخدام الشهادات) ، أو Azure Key Vault (حل Microsoft المستند إلى السحابة لإدارة الشهادات).

يستخدم التطبيق الذي يقوم بتشفير البيانات المفتاح الرئيسي للعمود لحماية مفاتيح تشفير الأعمدة المختلفة التي تتعامل مع تشفير البيانات داخل أعمدة جدول قاعدة البيانات. يتطلب استخدام مخازن الشهادات من SQL Server ، والتي يشار إليها أحيانًا باسم Enterprise Key Manager ، استخدام SQL Server Enterprise Edition.

في هذه المقالة ، نصف استخدام شهادة موقعة ذاتيًا تقوم بتخزينها في Microsoft Certificate Store لنظام التشغيل Windows. على الرغم من أن هذا النهج ليس التكوين الأمثل ، إلا أنه يوضح مفهوم التشفير دائمًا - ولكن يجب أيضًا الإشارة إلى أن هذا النهج غير مقبول لبيئات الإنتاج ، حيث يجب أن تتم إدارة الشهادات من خلال حسابات مستخدمين منفصلة وآمنة ويفضل ، على خوادم منفصلة.

يمكنك إنشاء تعريف مفتاح رئيسي للعمود باستخدام الواجهة الرسومية داخل SQL Server Management Studio (SSMS) أو باستخدام T-SQL. في SSMS ، اتصل بمثيل قاعدة بيانات SQL Server 2016 حيث تريد استخدام ميزة التشفير دائمًا لحماية جدول قاعدة البيانات.

إنشاء واستخدام مفاتيح العمود الرئيسية

في Object Explorer ، انتقل أولاً إلى قاعدة البيانات ، ثم إلى الأمان ، ثم قم بتوسيع مجلد Always Encrypted Keys لعرض مجلديه الفرعيين ، كما هو موضح في الأشكال التالية:

لإنشاء المفتاح الرئيسي للعمود ، انقر بزر الماوس الأيمن فوق المجلد Column Master Keys وحدد New Column Master Key . في مربع الحوار New Column Master Key ، اكتب اسمًا للمفتاح الرئيسي للعمود ، وحدد ما إذا كنت تريد تخزين المفتاح في مخزن شهادات المستخدم الحالي أو الجهاز المحلي أو Azure Key Vault ، ثم حدد شهادة في القائمة. إذا لم تكن هناك شهادات ، أو إذا كنت تريد استخدام شهادة موقعة ذاتيًا جديدة ، فانقر فوق الزر Generate Certificate ، ثم انقر فوق OK . تنشئ هذه الخطوة شهادة موقعة ذاتيًا وتحميلها في مخزن الشهادات لحساب المستخدم الحالي الذي يقوم بتشغيل SSMS.

ملاحظة: يجب تنفيذ هذه الخطوات على جهاز موثوق به ، ولكن ليس على جهاز الكمبيوتر الذي يستضيف مثيل SQL Server. بهذه الطريقة ، تظل البيانات محمية في SQL Server حتى إذا تم اختراق الكمبيوتر المضيف.

لذلك ، بعد إنشاء الشهادة وتكوينها كمفتاح رئيسي للعمود ، يجب عليك تصديرها وتوزيعها على جميع أجهزة الكمبيوتر التي تستضيف العملاء الذين يتطلبون الوصول إلى البيانات. إذا كان تطبيق العميل مستندًا إلى الويب ، فيجب عليك تحميل الشهادة على خادم الويب. إذا كان تطبيقًا مثبتًا على أجهزة كمبيوتر المستخدمين ، فيجب عليك نشر الشهادة على كمبيوتر كل مستخدم على حدة.

يمكنك العثور على الإرشادات القابلة للتطبيق لتصدير واستيراد الشهادات لنظام التشغيل الخاص بك على عناوين URL التالية:

• تصدير الشهادات
  • Windows 7 و Windows Server 2008 R2
  • Windows 8 و Windows Server 2012
  • Windows 8.1 و Windows Server 2012 R2
  • Windows 10 و Windows Server 2016
• استيراد الشهادات
  • Windows 7 و Windows Server 2008 R2
  • Windows 8 و Windows Server 2012
  • Windows 8.1 و Windows Server 2012 R2
  • Windows 10 و Windows Server 2016

عند استيراد الشهادات إلى مخزن الشهادات على أجهزة الكمبيوتر مع تطبيق يقوم بتشفير البيانات وفك تشفيرها ، يجب عليك استيراد الشهادات إما إلى مخزن شهادات الجهاز أو مخزن الشهادات لحساب المجال الذي يقوم بتشغيل التطبيق.

مفتاح تشفير العمود

بعد إنشاء مفتاح عمود رئيسي ، تكون جاهزًا لإنشاء مفاتيح تشفير لأعمدة معينة. يستخدم برنامج تشغيل SQL Server 2016 ADO.NET مفاتيح تشفير الأعمدة لتشفير البيانات قبل إرسالها إلى SQL Server ، وفك تشفير البيانات بعد استردادها من مثيل SQL Server 2016. كما هو الحال مع المفتاح الرئيسي للعمود ، يمكنك إنشاء مفاتيح تشفير الأعمدة باستخدام T-SQL أو SSMS. بينما يسهل إنشاء مفاتيح العمود الرئيسية باستخدام T-SQL ، فإن إنشاء مفاتيح تشفير العمود أسهل باستخدام SSMS.

لإنشاء مفتاح تشفير عمود ، استخدم Object Explorer للاتصال بطبعة قاعدة البيانات ، وانتقل إلى قاعدة البيانات ، ثم إلى Security ، وقم بتوسيع مجلد Always Encrypted Keys . انقر بزر الماوس الأيمن فوق Column Encryption Keys ، ثم حدد New Column Encryption Key . في مربع الحوار New Column Encryption Key ، اكتب اسمًا لمفتاح التشفير الجديد ، وحدد Column Master Key Definition في القائمة المنسدلة ، ثم انقر فوق OK . يمكنك الآن استخدام مفتاح تشفير العمود في تعريف جدول جديد.

تكوين جدول بقيم مشفرة

بعد إنشاء تعريف المفتاح الرئيسي للعمود ومفاتيح تشفير العمود ، يمكنك إنشاء جدول للاحتفاظ بالقيم المشفرة.

قبل القيام بذلك ، يجب أن تقرر نوع التشفير المراد استخدامه وأي الأعمدة تريد تشفيرها وما إذا كان يمكنك فهرسة هذه الأعمدة. باستخدام ميزة التشفير دائمًا ، يمكنك تحديد أحجام الأعمدة بشكل طبيعي ، ويقوم SQL Server بضبط حجم تخزين العمود بناءً على إعدادات التشفير. بعد إنشاء الجدول الخاص بك ، قد تحتاج إلى تغيير التطبيق الخاص بك لتنفيذ الأوامر الموجودة في هذا الجدول باستخدام ميزة التشفير دائمًا .

أنواع تشفير SQL Server 2016

قبل إنشاء جدول يحتوي على قيم مشفرة ، يجب أن تقرر ما إذا كان يجب تشفير كل عمود أم لا.

أولاً ، هل سيتم استخدام هذا العمود للبحث عن القيم أو إرجاع تلك القيم فقط؟

إذا كان سيتم استخدام العمود لعمليات البحث ، فيجب أن يستخدم العمود نوع تشفير محدد ، مما يسمح بعمليات المساواة. ومع ذلك ، هناك قيود على البحث عن البيانات التي تم تشفيرها باستخدام ميزة "التشفير دائمًا ". يدعم SQL Server 2016 عمليات المساواة فقط ، والتي تتضمن joins equal to ، not equal to (التي تستخدم المساواة) ، واستخدام القيمة في عبارة GROUP BY . لا يتم دعم أي بحث باستخدام LIKE . بالإضافة إلى ذلك ، يجب أن يتم فرز البيانات المشفرة باستخدام ميزة التشفير دائمًا على مستوى التطبيق ، حيث سيتم فرز SQL Server بناءً على القيمة المشفرة بدلاً من القيمة التي تم فك تشفيرها.

إذا لم يتم استخدام العمود لتحديد موقع السجلات ، فيجب أن يستخدم العمود نوع التشفير العشوائي. يعتبر هذا النوع من التشفير أكثر أمانًا ، لكنه لا يدعم عمليات البحث أو عمليات الانضمام أو التجميع.

تكوين جدول بأعمدة مشفرة

عند إنشاء الجداول ، يمكنك استخدام بناء الجملة العادي CREATE TABLE مع بعض المعلمات الإضافية داخل تعريف العمود. يتم استخدام ثلاث معلمات داخل بناء جملة ENCRYPTED WITH CREATE TABLE .

أولها هو المعلمة ENCRYPTION_TYPE ، والتي تقبل قيمة RANDOMIZED أو DETERMINISTIC . الثانية هي المعلمة ALGORITHM ، والتي تقبل فقط قيمة RAEAD_AES_256_CBC_HMAC_SHA_256 . المعلمة الثالثة هي COLUMN_ENCRYPTION_KEY ، وهي مفتاح التشفير الذي تستخدمه لتشفير القيمة.

 CREATE TABLE [dbo].[Customers] ( [CustomerId] [int] IDENTITY(1,1), [TaxId] [varchar](11) COLLATE Latin1_General_BIN2 ENCRYPTED WITH (ENCRYPTION_TYPE = DETERMINISTIC, ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256', COLUMN_ENCRYPTION_KEY = YOUR_COLUMN_ENCRYPTION_KEY) NOT NULL, [FirstName] [nvarchar](50) NULL, [LastName] [nvarchar](50) NULL, [MiddleName] [nvarchar](50) NULL, [Address1] [nvarchar](50) NULL, [Address2] [nvarchar](50) NULL, [Address3] [nvarchar](50) NULL, [City] [nvarchar](50) NULL, [PostalCode] [nvarchar](10) NULL, [State] [char](2) NULL, [BirthDate] [date] ENCRYPTED WITH (ENCRYPTION_TYPE = RANDOMIZED, ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256', COLUMN_ENCRYPTION_KEY = YOUR_COLUMN_ENCRYPTION_KEY) NOT NULL PRIMARY KEY CLUSTERED ([CustomerId] ASC) ON [PRIMARY] ); GO

الفهرسة مع التشفير دائمًا

يمكن استخدام الأعمدة التي تحتوي على بيانات مشفرة كأعمدة رئيسية داخل الفهارس ، بشرط أن يتم تشفير هذه الأعمدة باستخدام نوع DETERMINISTIC المحدد. تقوم الأعمدة المشفرة باستخدام نوع التشفير RANDOMIZED بإرجاع رسالة خطأ عند محاولة إنشاء فهرس على هذه الأعمدة. يمكن استخدام الأعمدة المشفرة باستخدام أي نوع من أنواع التشفير كأعمدة INCLUDE داخل فهارس غير مجمعة.

نظرًا لأن القيم المشفرة يمكن أن تكون فهارس ، فلا يلزم إجراء أية إجراءات ضبط أداء إضافية للقيم المشفرة باستخدام ميزة "التشفير دائمًا" بخلاف الفهرسة والضبط اللذين تقوم بهما عادةً. النطاق الترددي الإضافي للشبكة والإدخال / الإخراج الأكبر هما الآثار الجانبية الوحيدة التي تنتج عن زيادة حجم القيم التي يتم إرجاعها.

أداء مشفر دائمًا

يعد الأداء دائمًا عاملاً رئيسيًا ، خاصة في هذه الحالة ، عندما نضيف مقدارًا إضافيًا من التشفير إلى حركة مرور قاعدة البيانات المعتادة. أفضل موقع لاختبار الأداء هو SQL Performance ، والذي اختبر تنفيذ الاستعلام واستخدام القرص في سيناريوهات مختلفة:

نظرًا لوجود عمل وحدة المعالجة المركزية والقرص الصلب الذي يجب إجراؤه باستخدام عمليات التشفير وفك التشفير ، فهناك تأثير واضح على مقدار مساحة التخزين المستخدمة ومدة الاستعلامات. نظرًا لأن هذا يتأثر ببيئتك - وحدة المعالجة المركزية وذاكرة الوصول العشوائي وميزات القرص - يجب عليك اختبار ما إذا كان هذا سيشكل مشكلة في الإنتاج.

ملاحظة: في حالة رغبتك في معرفة المزيد حول تحسين أداء Microsoft SQL Sever ، يرجى مراجعة إحدى مقالاتنا السابقة ، كيفية ضبط Microsoft SQL Server للأداء.

تغييرات التطبيق

ما الذي يتعين عليك القيام به لتنفيذ ميزة التشفير دائمًا بشكل صحيح في التعليمات البرمجية القديمة؟

أحد الأشياء الرائعة حول ميزة Always Encrypted لـ SQL Server 2016 هو أن التطبيقات التي تستخدم بالفعل الإجراءات المخزنة ، أو ORMs ، أو أوامر T-SQL ذات المعلمات يجب ألا تتطلب أي تغييرات في التطبيق لاستخدام Always Encrypted ، ما لم تكن عمليات عدم المساواة قيد الاستخدام بالفعل. تحتاج التطبيقات التي تنشئ جمل SQL كجمل SQL ديناميكي داخل التطبيق وتنفذ تلك الأوامر على قاعدة البيانات مباشرةً إلى تعديل لاستخدام معلمات استعلاماتها ، وهي أفضل ممارسة أمان موصى بها لجميع التطبيقات ، قبل أن تتمكن من الاستفادة من ميزة Always Encrypted.

هناك تغيير آخر مطلوب لإجراء عمل "التشفير دائمًا" وهو إضافة سمة سلسلة الاتصال إلى سلسلة الاتصال الخاصة بالتطبيق المتصل بقاعدة البيانات: Column Encryption Setting=enabled .

مع إضافة هذا الإعداد إلى سلسلة الاتصال ، يسأل برنامج تشغيل ADO.NET SQL Server إذا كان الأمر التنفيذي يتضمن أي أعمدة مشفرة ، وإذا كان الأمر كذلك ، فما هي الأعمدة المشفرة. بالنسبة للتطبيقات عالية التحميل ، قد لا يكون استخدام هذا الإعداد هو أفضل ممارسة ، خاصة إذا كانت نسبة كبيرة من أوامر التنفيذ لا تتضمن قيمًا مشفرة.

وبالتالي ، يوفر .NET Framework طريقة جديدة على كائن SqlConnection تسمى SqlCommandColumnEncryptionSetting ، والتي تحتوي على ثلاث قيم محتملة:

• Disabled - لا توجد أعمدة أو معلمات مشفرة دائمًا للاستعلامات التي يتم تنفيذها باستخدام كائن الاتصال هذا.
• Enabled - هناك أعمدة و / أو معلمات مشفرة دائمًا قيد الاستخدام للاستعلامات التي يتم تنفيذها باستخدام كائن الاتصال هذا.
• ResultSet - لا توجد معلمات مشفرة دائمًا. ومع ذلك ، يؤدي تنفيذ الاستعلامات باستخدام كائن الاتصال هذا إلى إرجاع الأعمدة المشفرة باستخدام "التشفير دائمًا".

ملاحظة: اعلم أن استخدام هذه الطريقة قد يتطلب قدرًا كبيرًا من التغيير في رمز التطبيق الخاص بك. هناك طريقة بديلة تتمثل في إعادة تشكيل التطبيق الخاص بك لاستخدام اتصالات مختلفة.

للحصول على أفضل أداء لـ SQL Server ، من الحكمة أن تطلب فقط بيانات التعريف الخاصة بـ Always Encrypted لتلك الاستعلامات التي تستخدم Always Encrypted. هذا يعني أنه في التطبيقات التي تستخدم فيها نسبة كبيرة من الاستعلامات ميزة "التشفير دائمًا" ، يجب تمكين سلسلة الاتصال ويجب أن تحدد الاستعلامات المحددة داخل التطبيق SqlCommandColumnEncryptionSetting على أنه Disabled . بالنسبة للتطبيقات التي لا تستخدم معظم الاستعلامات فيها قيم "التشفير دائمًا" ، يجب عدم تمكين سلسلة الاتصال ، ويجب تعيين SqlCommandColumnEncryptionSetting على Enabled أو ResultSet حسب الحاجة لتلك الاستعلامات التي تستخدم الأعمدة المشفرة دائمًا. في معظم الحالات ، تستطيع التطبيقات ببساطة تمكين سمة سلسلة الاتصال ، وسيظل أداء التطبيق دون تغيير أثناء استخدام البيانات المشفرة.

هل التشفير دائمًا يستحق العناء؟

اجابة قصيرة؟ نعم بالتأكيد!

فهو لا يساعد فقط في منع الكثير من المخاوف الأمنية المحتملة ويزود مطوري SQL بميزات أمان إضافية ، ولكنه أيضًا يجعل نظامك أكثر توافقًا ، وهو أمر حيوي في العديد من الصناعات ، من الاتصالات إلى الخدمات المصرفية والتأمين. من المهم أيضًا ملاحظة أنه نظرًا للمتطلبات التقنية المذكورة في المقالة ، يمكن تنفيذ ميزة التشفير الدائم مع الحد الأدنى من تغييرات التطبيق على الأنظمة الحالية .

على الرغم من أنك قد تستخدم حلولًا مخصصة للحصول على نفس التأثير ، إلا أن هذه التقنية مرفقة بإصدار جديد من SQL Server ، ويمكن استخدامها خارج الصندوق. من المهم أيضًا ملاحظة ، نظرًا لأن هذه تقنية جديدة ، لا تزال هناك بعض القيود على استخدامها ، وتضيف بعض الأجهزة الإضافية.

ومع ذلك ، ما لم تكن بمثابة كسر للصفقة لبيئتك ، وكان لديك تطبيق يتم توزيعه خارج شبكة الإنترانت الخاصة بشركتك ، فلا يوجد سبب فعليًا لعدم استخدام ميزة التشفير دائمًا.