تشفير بيانات خارجية في Azure SQL باستخدام مفتاح يديره العميل

ينطبق على: قاعدة بيانات Azure SQL مثيل Azure SQL المُدار Azure Synapse Analytics

يتيح Azure SQL تشفير البيانات الخارجية (TDE) باستخدام المفتاح المُدار بواسطة العميل، سيناريو إحضار المفتاح الخاص بك (BYOK) لحماية البيانات في حالة السكون، ويسمح للمؤسسات بتنفيذ فصل المهام في إدارة المفاتيح والبيانات. مع TDE المُدار بواسطة العميل، يكون العميل مسؤولاً عن إدارة دورة حياة المفتاح والتحكم الكامل فيها (إنشاء المفتاح، وتحميله، وتناوبه، وحذفه)، وأذونات استخدام المفاتيح، وتدقيق العمليات على المفاتيح.

في هذا السيناريو، يكون المفتاح المستخدم لتشفير مفتاح تشفير قاعدة البيانات (DEK)، هو أداة حماية TDE، هو مفتاح غير متماثل مدار من قبل العملاء مخزن في Azure Key Vault (AKV) المملوك للعميل والمدار من قبل العملاء، وهو نظام إدارة مفاتيح خارجي قائم على السحابة. يعد Key Vault تخزيناً آمناً ومتاحاً بدرجة كبيرة وقابل للتطوير لمفاتيح تشفير RSA، وهو مدعوم اختيارياً بوحدات أمان الأجهزة (HSM) التي تم التحقق من صحتها FIPS 140-2 المستوى 2. فهو لا يسمح بالوصول المباشر إلى مفتاح مخزن، ولكنه يوفر خدمات التشفير/فك التشفير باستخدام المفتاح إلى الكيانات المعتمدة. يمكن إنشاء المفتاح بواسطة مخزن المفاتيح أو استيرادها أو نقلها إلى المخزن الرئيسي من جهاز HSM محلي.

بالنسبة إلى قاعدة بيانات Azure SQL وAzure Synapse Analytics، يتم تعيين أداة حماية TDE على مستوى الخادم ويتم توريثه بواسطة جميع قواعد البيانات المشفرة المرتبطة بهذا الخادم. بالنسبة لمثيل Azure SQL المُدار، يتم تعيين أداة حماية TDE على مستوى المثيل ويتم توريثه بواسطة جميع قواعد البيانات المشفرة على هذا المثيل. يشير المصطلح خادم إلى خادم في SQL Database وAzure Synapse وإلى مثيل مُدار في SQL Managed Instance بهذا المستند، ما لم يذكر بشكل مختلف.

ملاحظة

تنطبق هذه المقالة على قاعدة بيانات Azure SQL ومثيل SQL Azure المدار وAzure Synapse Analytics (تجمعات SQL المخصصة ( المعروفة سابقًا بـ SQL DW)). للحصول على وثائق حول تشفير البيانات الخارجية لتجمعات SQL المخصصة داخل مساحات عمل Synapse، راجع تشفير Azure Synapse Analytics.

هام

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

ملاحظة

لتزويد عملاء Azure SQL بطبقتين من تشفير البيانات في حالة عدم التشغيل، يتم تقديم تشفير البنية الأساسية (باستخدام خوارزمية تشفير AES-256) باستخدام المفاتيح المُدارة بواسطة النظام الأساسي. ويوفر هذا طبقة إضافية من التشفير في وضع التشغيل جنباً إلى جنب مع TDE باستخدام المفاتيح المدارة من قبل العملاء والمتوفرة بالفعل. بالنسبة إلى Azure SQL Database وManaged Instance، سيتم تشفير جميع قواعد البيانات، بما في ذلك قاعدة البيانات الرئيسية وقواعد بيانات النظام الأخرى، عند تشغيل تشفير البنية الأساسية. في هذا الوقت، يجب على العملاء طلب الوصول إلى هذه الإمكانية. إذا كنت مهتماً بهذه الإمكانية، فاتصل AzureSQLDoubleEncryptionAtRest@service.microsoft.com.

مزايا TDE المدار من قبل العملاء

يوفر TDE المدار من قبل العميل المزايا التالية للعميل:

• السيطرة الكاملة ومتعددة المستويات على استخدام وإدارة أداة حماية TDE؛

• مدى شفافية استخدام أداة حماية TDE؛

• القدرة على تنفيذ الفصل بين الواجبات في إدارة المفاتيح والبيانات داخل المنظمة؛

• يمكن لمسؤول Key Vault إبطال أذونات الوصول إلى المفتاح لمنع الوصول إلى قاعدة البيانات المشفرة؛

• الإدارة المركزية للمفاتيح في AKV؛

• ثقة أكبر من عملائك النهائيين، نظراً لأن AKV مصمم بحيث لا تستطيع Microsoft رؤية مفاتيح التشفير أو استخراجها؛

كيفية عمل TDE المدار من قبل العملاء

لكي يستخدم خادم Azure SQL واقي TDE المخزن في AKV لتشفير DEK، يحتاج مسؤول مخزن المفاتيح إلى منح حقوق الوصول التالية للخادم باستخدام هوية Azure Active Directory (Microsoft Azure Active Directory) الفريدة:

• get - لاسترداد الجزء العام وخصائص المفتاح في المخزن الرئيسي

• wrapKey - لتتمكن من حماية (تشفير) DEK

• wrapKey - لتتمكن من إلغاء حماية (تشفير) DEK

يمكن لمسؤول الخزنة الرئيسية كذلك تمكين تسجيل أحداث تدقيق الخزنة الرئيسية، بحيث يمكن مراجعتها لاحقاً.

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

عند الحاجة، يرسل الخادم DEK المحمي إلى خزنة المفاتيح لفك التشفير.

يمكن للمدققين استخدام Azure Monitor لمراجعة سجلات AuditEvent الخاصة بخزنة المفاتيح، في حالة تمكين التسجيل.

ملاحظة

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

متطلبات تكوين TDE المدار من قبل العملاء

متطلبات تكوين AKV

• يجب أن تنتمي Key vault وSQL Database/managed instance إلى نفس مستأجر Azure Active Directory. لا يتم دعم مخزن المفاتيح والتفاعلات مع الخادم. لنقل الموارد بعد ذلك، يجب إعادة تكوين TDE مع AKV. تعرف على المزيد حول نقل الموارد.

• يجب تمكين ميزتي الحذف المؤقت والحماية من المسح في مخزن المفاتيح للحماية من فقدان البيانات بسبب حذف المفتاح العرضي (أو مخزن المفاتيح).

• امنح الخادم أو المثيل المُدار حق الوصول إلى خزنة المفاتيح (الحصول على، وwrapKey، وunsrapKey) باستخدام هوية Azure Active Directory. يمكن أن تكون هوية الخادم عبارة عن هوية مُدارة مُعيَّنة من قِبل النظام أو هوية مُدارة مُعيَّنة من قِبل المستخدم تم تعيينها للخادم. عند استخدام مدخل Azure، يتم إنشاء هوية Azure AD تلقائياً عند إنشاء الخادم. عند استخدام PowerShell أو Azure CLI، يجب إنشاء هوية Azure AD بشكل صريح والتحقق منها. راجع تكوين TDE مع BYOK وتكوين TDE مع BYOK لـ SQL Managed Instance للحصول على إرشادات تفصيلية خطوة بخطوة عند استخدام PowerShell.

  • اعتماداً على نموذج الإذن للخزنة الرئيسية (سياسة الوصول أو Azure RBAC)، يمكن منح الوصول إلى الخزنة الرئيسية إما عن طريق إنشاء سياسة وصول على الخزنة الرئيسية أو عن طريق إنشاء تعيين مهمة جديدة لـ Azure RBAC مع دور مستخدم تشفير خدمة تشفير الخزنة الرئيسية.

• عند استخدام جدار الحماية مع AKV، يجب تمكين الخيار السماح خدمات Microsoft الموثوق بها بتجاوز جدار الحماية.

تمكين الحماية من الحذف المؤقت والمسح لـ AKV

هام

يجب تمكين كل من الحذف المؤقت والحماية من التطهير في مخزن المفاتيح عند تكوين TDE المُدار بواسطة العميل على خادم جديد أو موجود أو مثيل مُدار.

الحذف المبدئي والحماية من المسح هما ميزتان هامتان في Azure Key Vault تسمحان باستعادة المخازن المحذوفة وعناصر مخزن المفاتيح المحذوفة، مما يقلل من مخاطر قيام المستخدم بحذف مفتاح أو عن طريق الخطأ أو بشكل ضار مخزن رئيسي.

• يتم الاحتفاظ بالموارد المحذوفة مبدئياً لمدة 90 يوماً، ما لم يتم استردادها أو مسحها من قبل العميل. الإجراءان الاسترداد والمسح لهما أذونات خاصة بهما مقترنة بسياسة الوصول إلى الخزنة الرئيسية. يتم تشغيل ميزة الحذف المبدئي افتراضياً لمخازن المفاتيح الجديدة ويمكن أيضاً تمكينها باستخدام مدخل Microsoft Azure أو PowerShell أو Azure CLI.

• يمكن تشغيل الحماية من المسح باستخدام Azure CLI أو PowerShell. عند تمكين الحماية من المسح، لا يمكن إزالة مخزن أو عنصر في الحالة المحذوفة حتى انقضاء فترة الاحتفاظ. فترة الاحتفاظ الافتراضية هي 90 يوماً، ولكنها قابلة للتكوين من 7 إلى 90 يوماً من خلال مدخل Azure.

• يتطلب Azure SQL تمكين الحماية من الحذف والإزالة في مخزن المفاتيح التي تحتوي على مفتاح التشفير المستخدم كحامي TDE للخادم أو مثيل مُدار. يساعد هذا في منع سيناريو حذف المفاتيح العرضي أو الضار أو حذف المفتاح الذي يمكن أن يؤدي إلى دخول قاعدة البيانات إلى حالة يتعذر الوصول إليها.

• عند تكوين حامي TDE على خادم موجود أو أثناء إنشاء الخادم، يتحقق Azure SQL من أن مخزن المفاتيح المستخدم به ميزة الحماية من الحذف والإزالة قيد التشغيل. إذا لم يتم تمكين الحماية من الحذف المؤقت والمسح في مخزن المفاتيح، فإن إعداد TDE Protector يفشل مع حدوث خطأ. في هذه الحالة، يجب أولاً تمكين الحماية من الحذف المبدئي والتطهير في مخزن المفاتيح ثم يجب إجراء إعداد TDE Protector.

متطلبات تكوين أداة حماية TDE

• يمكن أن يكون واقي TDE مفتاحاً غير متماثل أو RSA أو RSA HSM فقط. أطوال المفاتيح المدعومة هي 2048 بايت و3072 بايت.

• يجب أن يكون تاريخ تنشيط المفتاح (إذا تم تعيينه) تاريخاً ووقتاً في الماضي. يجب أن يكون تاريخ انتهاء الصلاحية (إذا تم تعيينه) تاريخاً ووقتاً في المستقبل.

• يجب أن يكون المفتاح في الحالة ممكّن.

• إذا كنت تستورد مفتاحاً موجوداً في مخزن المفاتيح، فتأكد من توفيره بتنسيقات الملفات المدعومة (.pfxأو .byokأو .backup).

ملاحظة

يدعم Azure SQL الآن استخدام مفتاح RSA مخزن في HSM مُدار كحامي TDE. Azure Key Vault Managed HSM عبارة عن خدمة سحابية مُدارة بالكامل، ومتاحة للغاية، ومستأجر فردي، ومتوافقة مع المعايير التي تمكّنك من حماية مفاتيح التشفير لتطبيقات السحابة الخاصة بك، باستخدام FIPS 140-2 Level 3 HSMs المصادق عليها. تعرف على المزيد حول HSMs المُدارة.

ملاحظة

تمنع مشكلة في إصدارات Thales CipherTrust Manager السابقة لإصدار 2.8.0 المفاتيح المستوردة حديثاً إلى Azure Key Vault من الاستخدام مع Azure SQL Database أو Azure SQL Managed Instance لسيناريوهات TDE التي يديرها العميل. يمكن العثور على مزيد من التفاصيل عن هذه المشكلة هنا. بالنسبة لمثل هذه الحالات، يُرجى الانتظار 24 ساعة بعد استيراد المفتاح إلى key vault لبدء استخدامه كأداة حماية TDE للخادم أو المثيل المُدار. تم حل هذه المشكلة في Thales CipherTrust Manager v2.8.0.

توصيات عند تكوين TDE المدارة من قبل العملاء

توصيات عند تكوين AKV

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

• قم بتعيين تأمين مورد على الخزنة الرئيسية للتحكم في من يمكنه حذف هذا المورد الهام ومنع الحذف المبدئي أو غير المصرح به. تعرف على المزيد حول تأمين الموارد.

• تمكين التدقيق والإبلاغ عن جميع مفاتيح التشفير: توفر الخزنة الرئيسية سجلات يسهل إدخالها في معلومات الأمان وأدوات إدارة الأحداث الأخرى. تعد حزمة إدارة العمليات Log Analytics أحد الأمثلة على الخدمة المدمجة بالفعل.

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

ملاحظة

للسماح بمزيد من المرونة في تكوين TDE المدار من قبل العملاء، يمكن الآن ربط Azure SQL Database server وManaged Instance في منطقة واحدة بالخزنة الرئيسية في أي منطقة أخرى. لا يلزم أن يكون الخادم والخزنة الرئيسية في نفس المنطقة.

التوصيات عند تكوين أداة حماية TDE

• احتفظ بنسخة من أداة حماية TDE في مكان آمن أو احفظها في خدمة الضمان.

• إذا تم إنشاء المفتاح في الخزنة الرئيسية، فقم بإنشاء نسخة احتياطية للمفتاح قبل استخدام المفتاح في AKV للمرة الأولى. يمكن استعادة النسخة الاحتياطية إلى Azure Key Vault فقط. تعرف على المزيد حول الأمر Backup-AzKeyVaultKey.

• قم بإنشاء نسخة احتياطية جديدة متى تم إجراء أي تغييرات على المفتاح (على سبيل المثال، السمات الرئيسية والعلامات وACL).

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

• احتفظ بجميع المفاتيح المستخدمة مسبقاً في AKV حتى بعد التبديل إلى المفاتيح المدارة بواسطة الخدمة. تضمن إمكانية استعادة النسخ الاحتياطية لقاعدة البيانات باستخدام أداة حماية TDE المخزنة في AKV. يجب الحفاظ على أداة حماية TDE التي تم إنشاؤها باستخدام Azure Key Vault حتى يتم إنشاء جميع النسخ الاحتياطية المخزنة المتبقية باستخدام المفاتيح المدارة بواسطة الخدمة. قم بعمل نسخ احتياطية قابلة للاسترداد من هذه المفاتيح باستخدام Backup-AzKeyVaultKey.

• لإزالة مفتاح يُحتمل اختراقه أثناء حادث أمني دون المخاطرة بفقدان البيانات، اتبع الخطوات الواردة في إزالة مفتاح يُحتمل اختراقه.

أداة حماية TDE لا يمكن الوصول إليها

عندما يتم تكوين TDE لاستخدام مفتاح يديره العميل، يلزم الوصول المستمر إلى واقي TDE حتى تظل قاعدة البيانات متصلة بالإنترنت. إذا فقد الخادم الوصول إلى أداة حماية TDE المدارة من قبل العملاء في AKV، فستبدأ قاعدة البيانات خلال 10 دقائق في رفض جميع الاتصالات مع رسالة الخطأ المقابلة وتغيير حالتها إلى غير قابل للوصول. إن الإجراء الوحيد المسموح به على قاعدة بيانات في حالة "تعذر الوصول" هو حذفه.

ملاحظة

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

بعد استعادة الوصول إلى المفتاح، تتطلب إعادة تشغيل قاعدة البيانات عبر الإنترنت وقتاً وخطوات إضافية، والتي قد تختلف بناءً على الوقت المنقضي دون الوصول إلى المفتاح وحجم البيانات في قاعدة البيانات:

• إذا تمت استعادة الوصول إلى المفتاح في غضون 30 دقيقة، فسيتم معالجة قاعدة البيانات تلقائياً في غضون الساعة التالية.

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

وفيما يلي عرض للخطوات الإضافية المطلوبة على المدخل لإعادة تشغيل قاعدة بيانات يتعذر الوصول إليها عبر الإنترنت.

إلغاء الوصول إلى أداة الحماية العرضية لـ TDE

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

• إبطال حصول الخزنة الرئيسية على أذوناتwrapKey وunsrapKey من الخادم

• حذف المفتاح

• حذف الخزنة الرئيسية

• تغيير قواعد جدار حماية الخزنة الرئيسية

• حذف الهوية المدارة من الخادم في Azure Active Directory

تعرف على المزيد حول الأسباب الشائعة لعدم إمكانية الوصول إلى قاعدة البيانات.

مراقبة TDE المدارة من قبل العملاء

لمراقبة حالة قاعدة البيانات وتمكين التنبيه لفقدان الوصول إلى أداة حماية TDE، قم بتكوين ميزات Azure التالية:

• Azure Resource Health. سيتم عرض قاعدة البيانات التي يتعذر الوصول إليها والتي فقدت الوصول إلى أداة حماية TDE على أنها "غير متوفر" بعد رفض الاتصال الأول بقاعدة البيانات.
• سجل النشاط عند فشل الوصول إلى أداة حماية TDE في الخزنة الرئيسية المدارة من قبل العميل، تتم إضافة الإدخالات إلى سجل النشاط. يمكنك إنشاء تنبيهات لهذه الأحداث من إعادة الوصول في أسرع وقت ممكن.
• يمكن تعريف مجموعات الإجراءات لإرسال إعلامات وتنبيهات إليك بناءً على تفضيلاتك، على سبيل المثال، البريد الإلكتروني/الرسائل القصيرة/الدفع/الصوت أو تطبيق Logic أو Webhook أو ITSM أو Automation Runbook.

النسخ الاحتياطي لقاعدة البيانات واستعادتها باستخدام TDE المُدار من قبل العملاء

بمجرد تشفير قاعدة البيانات باستخدام TDE التي تستخدم مفتاح من Key Vault، يتم أيضاً تشفير أي نسخ احتياطية تم إنشاؤها حديثاً باستخدام أداة حماية TDE نفسها. عند تغيير أداة حماية TDE، فإن النسخ الاحتياطية القديمة لقاعدة البياناتلا يتم تحديثها لاستخدام أحدث أداة حماية TDE.

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

هام

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

إذا لم يعد المفتاح المطلوب لاستعادة نسخة احتياطية متاحاً للخادم المستهدف، فسيتم إرجاع رسالة الخطأ التالية عند محاولة الاستعادة: "لا يمتلك الخادم المستهدف <Servername>حق الوصول إلى جميع عناوين URI الخاصة بـ AKV التي تم إنشاؤها بين <الطابع الزمني # 1> و<الطابع الزمني رقم 2>. أعد محاولة التشغيل بعد استعادة جميع معرفات الموارد المنتظمة لـ AKV."

للتخفيف من ذلك، قم بتشغيل الأمر cmdlet Get-AzSqlServerKeyVaultKey للخادم الهدف أو Get-AzSqlInstanceKeyVaultKey للمثيل المُدار الهدف من إرجاع قائمة المفاتيح المتاحة وتحديد المفاتيح المفقودة. لضمان إمكانية استعادة جميع النسخ الاحتياطية، تأكد من أن الخادم الهدف الخاص بالاستعادة لديه حق الوصول إلى جميع المفاتيح المطلوبة. لا يتعين تمييز هذه المفاتيح على أنها أداة حماية TDE.

لمعرفة المزيد حول استرداد النسخ الاحتياطي لـ SQL Database، راجع استرداد قاعدة بيانات في SQL Database. لمعرفة المزيد حول استرداد النسخ الاحتياطي لتجمع SQL المخصص في Azure Synapse Analytics، راجع استرداد مجموعة SQL المخصصة. للنسخ الاحتياطي/الاستعادة الأصلية لـ SQL Server باستخدام SQL Managed Instance، راجع التشغيل السريع: استعادة قاعدة بيانات إلى SQL Managed Instance

اعتبار آخر لملفات السجل: تظل ملفات السجل التي تم نسخها احتياطياً مشفرة باستخدام واقي TDE الأصلي، حتى إذا تم تدويرها وتستخدم قاعدة البيانات الآن واقي TDE جديداً. أثناء الاستعادة، ستكون هناك حاجة إلى كلا المفتاحين لاستعادة قاعدة البيانات. إذا كان ملف السجل يستخدم أداة حماية TDE المخزن في Azure Key Vault، فستكون هناك حاجة إلى هذا المفتاح في وقت الاستعادة، حتى إذا تم تغيير قاعدة البيانات لاستخدام TDE المُدار بواسطة الخدمة في هذه الأثناء.

توفر عالٍ مع TDE المدار من قبل العملاء

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

بدلاً من ذلك، يمكن تحقيق ذلك عن طريق إنشاء مفتاح باستخدام مخزن المفاتيح الأساسية في منطقة واحدة ونسخ المفتاح في مخزن مفاتيح في منطقة Azure مختلفة. استخدم الأمر cmdlet Backup-AzKeyVaultKey لاسترداد المفتاح بتنسيق مشفر من خزنة المفاتيح الرئيسية ثم استخدم الأمر cmdlet Restore-AzKeyVaultKey وتحديد خزنة المفاتيح في المنطقة الثانية لاستنساخ مفتاح. بدلاً من ذلك، استخدم مدخل Azure لإجراء نسخ احتياطي للمفتاح واستعادته. لا يُسمح بعملية النسخ الاحتياطي/الاستعادة إلا بين خزانات المفاتيح ضمن نفس اشتراك Azure وجغرافية Azure.

Geo-DR وTDE المُدار بواسطة العميل

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

لتجنب المشكلات أثناء إنشاء أو أثناء النسخ المتماثل الجغرافي بسبب عدم اكتمال المواد الأساسية، من المهم اتباع هذه القواعد عند تكوين TDE المُدار بواسطة العميل (إذا تم استخدام مخازن مفاتيح منفصلة للخادم الأساسي والثانوي):

• يجب أن تحتوي جميع خزائن المفاتيح المعنية على نفس الخصائص ونفس حقوق الوصول للخوادم ذي الصلة.

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

• يجب أن يتم الإعداد الأولي والتناوب من حامي TDE على الثانوي أولاً، ثم على الابتدائي.

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

يمكن الآن ربط خادم Azure SQL Database وManaged Instance في منطقة واحدة بمخزن المفاتيح في أي منطقة أخرى. لا يلزم أن يكون الخادم والخزنة الرئيسية في نفس المنطقة. مع هذا، من أجل التبسيط، يمكن توصيل الخوادم الأساسية والثانوية بنفس خزنة المفاتيح (في أي منطقة). سيساعد هذا في تجنب السيناريوهات التي قد تكون فيها المواد الرئيسية غير متزامنة إذا تم استخدام خزائن مفاتيح منفصلة لكلا الخادمين. يحتوي Azure Key Vault على طبقات متعددة من التكرار للتأكد من أن المفاتيح وخزائن المفاتيح الخاصة بك تظل متاحة في حالة فشل الخدمة أو المنطقة. توفر Azure Key Vault والتكرار

نهج Azure لـ TDE المُدار بواسطة العميل

يمكن استخدام Azure Policy لفرض TDE المُدار بواسطة العميل أثناء إنشاء أو تحديث خادم Azure SQL Database أو مثيل Azure SQL المُدار. مع تطبيق هذا النهج، ستفشل أي محاولات لإنشاء أو تحديث خادم منطقي في Azure أو مثيل مُدار إذا لم يتم تكوينه باستخدام مفتاح يديره العميل. يمكن تطبيق نهج Azure على اشتراك Azure بالكامل، أو داخل مجموعة موارد فقط.

لمزيد من المعلومات حول نهج Azure، راجع ما المقصود بنهج Azure؟ وهيكل تعريف نهج Azure.

يتم دعم السياستين المضمنتين التاليتين لـ TDE المُدار بواسطة العميل في Azure Policy:

• يجب أن تستخدم خوادم SQL المفاتيح التي يديرها العملاء لتشفير البيانات الثابتة
• يجب أن تستخدم خدمة SQL managed instances المفاتيح التي يديرها العملاء لتشفير البيانات الثابتة

يمكن إدارة نهج TDE المُدار بواسطة العميل بالانتقال إلى مدخل Microsoft Azureوالبحث عن خدمة النهج. ضمن التعريفات، ابحث عن المفتاح المُدار بواسطة العميل.

هناك ثلاثة تأثيرات لهذه النُهج:

• Audit - الإعداد الافتراضي، وسيسجل تقرير تدقيق فقط في سجلات نشاط نهج Azure
• رفض - منع إنشاء أو تحديث الخادم المنطقي أو المثيل المُدار بدون تكوين مفتاح يديره العميل
• معطل - سيعطل النهج ولن يقيد المستخدمين من إنشاء أو تحديث خادم منطقي أو مثيل مُدار بدون تمكين TDE الذي يديره العميل

إذا تم تعيين نهج Azure لـ TDE المُدار بواسطة العميل على رفض، فسيفشل إنشاء خادم منطقي Azure SQL أو إنشاء مثيل مُدار. سيتم تسجيل تفاصيل هذا الفشل في سجل النشاط لمجموعة الموارد.

هام

تم إهمال الإصدارات السابقة من النُهج المضمنة لـ TDE المُدار بواسطة العميل والتي تحتوي على التأثير AuditIfNotExist. لا تتأثر تعيينات النهج الحالية التي تستخدم النُهج المتوقفة وستستمر في العمل كما كان من قِبل.

الخطوات التالية

قد ترغب أيضاً في التحقق من نماذج برامج PowerShell النصية التالية للعمليات الشائعة باستخدام TDE المُدار بواسطة العميل:

• تدوير حامي التشفير الخارجي للبيانات لقاعدة بيانات SQL

• إزالة حامي تشفير البيانات الخارجية (TDE) لقاعدة بيانات SQL

• إدارة تشفير البيانات الخارجية في SQL Managed Instance باستخدام مفتاحك الخاص باستخدام PowerShell

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