حماية البيانات بالتشفير
يشكل تشفير البيانات أساس أمن قواعد البيانات. حتى إذا تمكن المهاجمون من الوصول إلى التخزين الأساسي لديك، فإن التشفير يحافظ على معلوماتك الحساسة غير قابلة للقراءة. توفر منصات SQL من مايكروسوفت خيارات تشفير متعددة، من حماية البيانات في حالة سكونية إلى تأمين البيانات أثناء معالجتها.
فهم متى تستخدم كل طريقة يساعدك على تحقيق التوازن بين الحماية والأداء. دعونا نستكشف تقنيات التشفير المتوفرة في SQL Server وAzure SQL وقواعد بيانات SQL في Microsoft Fabric.
فهم طبقات التشفير
يعمل تشفير قواعد البيانات في طبقات مختلفة، كل منها يحل مشكلة محددة. تشفير البيانات الشفاف (TDE) يشفر البيانات في حالة السكون—فكر فيه كأنه حماية لملفات قاعدة البيانات على القرص. يستهدف تشفير على مستوى العمود أعمدة حساسة محددة، بينما يذهب التشفير على مستوى العمود إلى أبعد من ذلك من خلال حماية البيانات طوال دورة حياته، حتى أثناء معالجة الاستعلامات.
عند تفعيل TDE، يقوم SQL Server تلقائيا بتشفير ملفات قاعدة البيانات، وسجلات المعاملات، والنسخ الاحتياطية. تطبيقاتك لا تحتاج إلى تغييرات في الكود — التشفير يحدث بشفافية خلف الكواليس. يستخدم TDE مفتاح تشفير قاعدة بيانات محمي بشهادة مخزنة master في قاعدة البيانات.
التشفير على مستوى العمود يعمل بطريقة مختلفة. تقوم بتشفير وفك تشفير البيانات بشكل صريح في كود T-SQL أو تطبيقك، مما يمنحك تحكما دقيقا في الأعمدة التي تحتوي على بيانات حساسة ومن يمكنه فك تشفيرها.
يتبع Always Encrypted نهجا مختلفا من خلال إبقاء مفاتيح التشفير خارج محرك قاعدة البيانات تماما. قاعدة البيانات لا ترى بياناتك النصية الصريحة أبدا، مما يعني أن حتى مسؤولي قواعد البيانات الذين لديهم وصول عالي المستوى لا يمكنهم عرض المعلومات المحمية.
تكوين Always Encrypted
يضمن برنامج Always Encrypted أن محرك قاعدة البيانات لا يعالج قيم النص العادي أبدا. تطبيقات العميل الخاصة بك تحتفظ بمفاتيح التشفير وتتولى جميع عمليات التشفير وفك التشفير. هذا الفصل يعني أن حتى من لديه وصول إداري إلى قاعدة البيانات لا يمكنه رؤية البيانات المحمية.
للبدء مع Always Encrypted، تقوم أولا بإنشاء مفتاح رئيسي للعمود (CMK) يحمي مفاتيح تشفير الأعمدة. تخزين CMK في مخزن مفاتيح آمن مثل Azure Key Vault، أو Windows Certificate Store، أو وحدة أمان الأجهزة.
عبارة T-SQL التالية تنشئ إدخال بيانات وصفية يشير إلى مفتاحك في Azure Key Vault. المواد المفتاحية الفعلية تبقى في الخزنة، ولا تخزن أبدا في قاعدة البيانات.
CREATE COLUMN MASTER KEY MyCMK
WITH (
KEY_STORE_PROVIDER_NAME = 'AZURE_KEY_VAULT',
KEY_PATH = 'https://mykeyvault.vault.azure.net/keys/MyCMK/abc123'
);
بعد ذلك، أنشئ مفتاح تشفير العمود (CEK) محمي بمفتاح العمود الرئيسي:
CREATE COLUMN ENCRYPTION KEY MyCEK
WITH VALUES (
COLUMN_MASTER_KEY = MyCMK,
ALGORITHM = 'RSA_OAEP',
ENCRYPTED_VALUE = 0x01700000016C006F00...
);
لاحظ أن CEK نفسه مخزن بشكل مشفر. عندما يحتاج تطبيقك للعمل مع بيانات مشفرة، يسترجع هذه القيمة ويستخدم CMK لفك تشفيرها محليا.
عند إنشاء أو تعديل الجداول، تحدد نوع التشفير للأعمدة الحساسة:
CREATE TABLE Employees (
EmployeeID int PRIMARY KEY,
SSN char(11) COLLATE Latin1_General_BIN2
ENCRYPTED WITH (
ENCRYPTION_TYPE = DETERMINISTIC,
ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256',
COLUMN_ENCRYPTION_KEY = MyCEK
),
Salary money
ENCRYPTED WITH (
ENCRYPTION_TYPE = RANDOMIZED,
ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256',
COLUMN_ENCRYPTION_KEY = MyCEK
)
);
لديك نوعان من التشفير للاختيار من بينهما. استخدم النص الحتمي عندما تحتاج إلى إجراء مقارنات مساواة، أو انضمام، أو تصفية باستخدام WHERE الجمل — نفس النص الأصلي ينتج دائما نفس النص المشفر. استخدم العشوائي للحصول على أمان أقوى عندما لا تحتاج إلى عمليات الاستعلام هذه.
تنفيذ تشفير على مستوى العمود
التشفير على مستوى العمود باستخدام دوال T-SQL يمنحك بديلا عندما تحتاج إلى تحكم أكبر في عملية التشفير، أو عندما لا يكون Always Encrypted مناسبا. بهذا النهج، تدير المفاتيح المتماثلة أو غير المتماثلة المخزنة داخل قاعدة البيانات.
ابدأ بإنشاء مفتاح رئيسي لقاعدة البيانات وشهادة:
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'StrongPassword123!';
CREATE CERTIFICATE SensitiveDataCert
WITH SUBJECT = 'Certificate for sensitive data encryption';
أنشئ مفتاحا متماثلا محميا بالشهادة:
CREATE SYMMETRIC KEY SensitiveDataKey
WITH ALGORITHM = AES_256
ENCRYPTION BY CERTIFICATE SensitiveDataCert;
لتشفير البيانات، افتح المفتاح المتماثل واستخدم الدالة ENCRYPTBYKEY :
OPEN SYMMETRIC KEY SensitiveDataKey
DECRYPTION BY CERTIFICATE SensitiveDataCert;
INSERT INTO CustomerData (CustomerID, CreditCardNumber)
VALUES (1, ENCRYPTBYKEY(KEY_GUID('SensitiveDataKey'), '4111-1111-1111-1111'));
CLOSE SYMMETRIC KEY SensitiveDataKey;
يتبع فك التشفير نمطا مشابها باستخدام DECRYPTBYKEY:
OPEN SYMMETRIC KEY SensitiveDataKey
DECRYPTION BY CERTIFICATE SensitiveDataCert;
SELECT CustomerID,
CONVERT(varchar(20), DECRYPTBYKEY(CreditCardNumber)) AS CardNumber
FROM CustomerData;
CLOSE SYMMETRIC KEY SensitiveDataKey;
نعم، هذا النهج يتطلب المزيد من العمل—أنت تدير المفاتيح بشكل صريح في كودك. لكن هذا التعقيد يأتي مع المرونة. يمكنك منح أو رفض صلاحيات المفتاح المتماثل، مما يمنحك تحكما دقيقا في من يمكنه فك تشفير بياناتك.
اختر النهج الصحيح للتشفير
أي طريقة تشفير يجب أن تستخدمها؟ يعتمد ذلك على متطلبات الأمان وقيود التطبيق.
TDE هو أفضل خيار لك عندما تحتاج إلى حماية البيانات الساكنة دون المساس بكود التطبيق. إنه ممتاز لمتطلبات الامتثال التي تتطلب تشفير ملفات قواعد البيانات والنسخ الاحتياطية. لكن ضع في اعتبارك أن TDE لا يحمي البيانات من المستخدمين الذين يمكنهم الاتصال بقاعدة البيانات بالأذونات الصحيحة.
يتألق Always Encrypted عندما تحتاج إلى حماية البيانات من مسؤولي قواعد البيانات، أو عندما يجب أن تبقى البيانات الحساسة مشفرة حتى أثناء معالجة الاستعلامات. ما هو المقابل؟ تحتاج إلى دعم برامج تشغيل العميل، وأنت محدود في العمليات التي يمكنك تنفيذها على الأعمدة المشفرة.
يعمل التشفير على مستوى العمود بشكل جيد عندما تحتاج إلى تحكم دقيق في التشفير وفك التشفير، أو عندما تريد تشفير أعمدة محددة دون عبء البنية التحتية في Always Encrypted. يتطلب الأمر جهدا تطويريا أكبر، لكنك تحصل على أقصى مرونة في إدارة المفاتيح.
نصيحة
يمكنك دمج طرق التشفير. على سبيل المثال، فعل TDE لحماية البيانات الأساسية في حالة السكون، ثم أضف Always Encrypted لأعمدتك الأكثر حساسية.
بالنسبة لقواعد بيانات SQL في Microsoft Fabric، يتم تفعيل TDE بشكل افتراضي ويدار تلقائيا. ركز قرارات تصميم التشفير الخاصة بك على حماية على مستوى العمود باستخدام تشفير المفتاح المشفر دائما أو التشفير المتماثل بناء على متطلبات تطبيقك.