Customer-managed TDE for Azure Synapse Analytics

ينطبق على: Azure Synapse Analytics SQL pools المخصص (سابقا SQL DW)

نصيحة

Microsoft Fabric Data Warehouse هو مستودع علائقي على نطاق مؤسسي قائم على أساس بحيرة البيانات، مع بنية جاهزة للمستقبل، وذكاء اصطناعي مدمج، وميزات جديدة. إذا كنت جديدا في مستودع البيانات، ابدأ ب Fabric Data Warehouse. يمكن لأحمال عمل تجمع SQL المخصصة الحالية الترقية إلى Fabric للوصول إلى قدرات جديدة في علوم البيانات، والتحليلات اللحظية، والتقارير.

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

في هذا السيناريو، يعد Transparent Data Encryption (TDE) مفتاحا يديره العميل ويؤمن مفتاح تشفير قاعدة البيانات (DEK). تقوم بتخزين حامي TDE إما في Azure Key Vault أو Azure Key Vault Managed HSM، وهما خدمات إدارة مفاتيح آمنة قائمة على السحابة مصممة لتوافر عالي وقابلية التوسع. تدعم كلتا الخدمتين مفاتيح التشفير المحمية بأجهزة FIPS 140-2 المعتمدة: Azure Key Vault يدعم FIPS 140-2 المستوى 2، ويدعم Azure Key Vault Managed HSM المستوى 3 من FIPS 140-2. تدعم كلتا الخدمتين أيضا أنواع المفاتيح غير المتماثلة والمتماثلة، وتعتمد الخوارزميات المدعومة والاستخدام على نموذج نشر TDE. يمكنك توليد المفتاح في الخدمة، استيراده، أو نقله بأمان من HSMs المحلي. الوصول المباشر إلى المفاتيح مقيد بذلك، لذا تقوم الخدمات المصرح لها بعمليات تشفير دون كشف محتوى المفتاح.

ملحوظة

تغطي هذه المقالة مجموعات SQL المخصصة المستقلة (سابقا SQL DW).

  • ل Azure Synapse Analytics dedicated SQL pools (سابقا SQL DW)، قم بتعيين الحامي TDE على مستوى الخادم. جميع قواعد البيانات المشفرة المرتبطة بذلك الخادم ترث حامي TDE.
  • تشفير البيانات في مجموعات SQL مخصصة ومجموعات SQL بدون خوادم في مساحة عمل Synapse باستخدام المفتاح المدار من قبل العميل المحدد على مستوى مساحة العمل. لمزيد من المعلومات حول التشفير الشفاف للبيانات المخصصة لمجموعات SQL المخصصة داخل مساحات Synapse، راجع Azure Synapse Analytics crypto.

مفتاح إدارة العميل (CMK) وإحضار مفتاحك الخاص (BYOK)

في هذا المقال، تستخدم مصطلحات مفتاح إدارة العميل (CMK) و"أحضر مفتاحك الخاص" (BYOK) بالتبادل، لكنهما يمثلان بعض الاختلافات.

  • مفتاح العميل المدار (CMK) - تدير دورة حياة المفتاح، بما في ذلك إنشاء المفاتيح، التدوير، والحذف. تخزين المفتاح في Azure Key Vault أو Azure Managed HSM واستخدامه لتشفير مفتاح تشفير قاعدة البيانات (DEK).

  • Bring Your Own Key Key (BYOK) - تقوم بجلب أو استيراد مفتاحك الخاص بأمان من وحدة أمان الأجهزة المحلية (HSM) إلى Azure Key Vault. قد تستخدم هذه المفاتيح المستوردة كأي مفتاح آخر في Azure Key Vault، بما في ذلك كمفتاح إدارة من قبل العميل لتشفير DEK. لمزيد من المعلومات، راجع استيراد المفاتيح المحمية ب HSM إلى HSM المدار (BYOK).

فوائد TDE المدار من قبل العميل

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

  • تحكم كامل ودقيق في استخدام وإدارة واقي TDE.

  • شفافية استخدام واقي TDE.

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

  • يمكن لمسؤول Azure Key Vault إلغاء صلاحيات الوصول إلى المفاتيح لجعل قاعدة البيانات المشفرة غير قابلة للوصول.

  • Central Management of keys in Azure Key Vault.

  • ثقة أكبر من عملائك النهائيين، لأن Azure Key Vault مصمم بحيث لا تستطيع Microsoft رؤية أو استخراج مفاتيح التشفير.

Important

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

Permissions to configure client managed TDE في Azure Key Vault

اختر نوع Azure Key Vault الذي تريد استخدامه.

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

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

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

    • get - لاسترجاع الجزء العام وخصائص المفتاح في Azure Key Vault
    • wrapKey - لتتمكن من حماية (تشفير) DEK
    • unwrapKey - لتتمكن من فك الحماية (فك التشفير) DEK

في قائمة إعدادات الوصول في بوابة Azure في خزنة المفاتيح، لديك خيار اختيار التحكم في الوصول القائم على الأدوار في Azure أو سياسة الوصول إلى الخزنة. للحصول على تعليمات خطوة بخطوة حول إعداد تكوين الوصول إلى Azure Key Vault ل TDE، انظر Set up SQL Server TDE Extensible Key Management باستخدام Azure Key Vault. لمزيد من المعلومات حول نماذج الوصول، انظر Azure Key Vault security.

يمكن لمسؤول Key Vault أيضا تمكين تسجيل أحداث تدقيق key vault، بحيث يمكن تدقيقها لاحقا.

عندما تقوم بتكوين خادم لاستخدام حامي TDE من Azure Key Vault، يرسل الخادم DEK لكل قاعدة بيانات مفعلة بتقنية TDE إلى خزنة المفاتيح للتشفير. يعيد خزنة المفاتيح DEK المشفرة، والتي يخزنها الخادم في قاعدة بيانات المستخدم.

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

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

ملحوظة

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

Requirements to configure client managed TDE في Azure Key Vault

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

  • عند استخدام جدار حماية مع Azure Key Vault، يجب عليك تفعيل خيار السماح ل-خدمات Microsoft الموثوقة بتجاوز الجدار الناري، إلا إذا كنت تستخدم نقاط نهاية خاصة ل Azure Key Vault. لمزيد من المعلومات، راجع Configure Azure Key Vault Firewall and Virtual Networks.

المتطلبات الرئيسية لتكوين واقي TDE

يستخدم Transparent Data Encryption باستخدام مفاتيح يديرها العميل مفتاحا خارجيا يعرف ب TDE protector، ويخزن في Azure Key Vault لحماية مفتاح تشفير قاعدة البيانات (DEK).

تنطبق المتطلبات التالية.

أنواع وأحجام المفاتيح المدعومة

يمكن دعم حامي TDE بواسطة مفاتيح غير متماثلة مخزنة في Azure Key Vault. أحجام المفاتيح المدعومة هي 2,048 بت و3,072 بت.

متطلبات الحالة الرئيسية والصلاحية

  • إذا حددت تاريخ تفعيل مفتاح، قم بتعيينه على تاريخ ووقت في الماضي.
  • إذا حددت تاريخ انتهاء صلاحية المفتاح، قم بإعداده على تاريخ ووقت في المستقبل.
  • يجب أن يكون المفتاح في الحالة ممكّن.

متطلبات الاستيراد الرئيسية

إذا قمت باستيراد مفتاح موجود إلى Azure Key Vault، قدم المفتاح بأحد الصيغ المدعومة التالية:

  • .pfx
  • .byok
  • .backup

Recommendations for configuring client-managed TDE in Azure Key Vault

للحفاظ على توفر عالي وتجنب مشاكل التقييد (throttling)، اتبع هذه الإرشادات لكل اشتراك:

  • لضمان الأداء الأمثل والموثوقية، استخدم Azure Key Vault مخصص ل Azure SQL. لا تشارك هذه الخزنة مع خدمات أخرى. إذا كانت خزنة المفاتيح تحت حمل كبير بسبب الاستخدام المشترك أو العمليات المفرطة للمفاتيح، فقد يؤثر ذلك سلبا على أداء قاعدة البيانات، خاصة أثناء الوصول إلى مفاتيح التشفير. Azure Key Vault enforcement throttling limits. عندما تتجاوز هذه الحدود، قد تتأخر العمليات أو تفشل. يكون هذا الخطر أعلى أثناء عمليات التحويل إلى الخادم، التي تفعل عمليات المفتاح لكل قاعدة بيانات على الخادم.

    لمزيد من المعلومات حول سلوك التقييظ، انظر Azure Key Vault throttling guidance (توجيه التقييد (throttling guidance).

    • عدد قواعد بيانات Hyperscale التي يمكنك ربطها ب Azure Key Vault واحد يعتمد على عدد خوادم الصفحات. كل خادم صفحة مرتبط بملف بيانات منطقي. للعثور على عدد خوادم الصفحات، قم بتشغيل الاستعلام التالي.

      -- # of page servers (primary copies) for this database
SELECT COUNT(*) AS page_server_count
FROM sys.database_files
WHERE type_desc = 'ROWS';

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

    • Monitor وconfigure Azure Key Vault alerts. لمزيد من المعلومات حول المراقبة والتنبيه، راجع Monitor Azure Key VaultوConfigure Azure Key Vault alerts.

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

  • تمكين التدقيق والإبلاغ عن جميع مفاتيح التشفير: يوفر Azure Key Vault سجلات يسهل ضخنها في أدوات إدارة معلومات الأمان والأحداث الأخرى. Operations Management Suite Log Analytics هو مثال على خدمة متكاملة بالفعل.

  • استخدم خزنة مفاتيح من منطقة Azure يمكنها تكرار محتواها إلى منطقة مزدوجة لتحقيق أقصى توفر. لمزيد من المعلومات، راجع أفضل الممارسات لاستخدام Azure Key Vaultو Azure Key Vault availability and releaseancy.

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

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

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

  • أنشئ نسخة احتياطية جديدة كلما أجريت أي تغييرات على المفتاح (مثل سمات المفاتيح، العلامات، ACLs).

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

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

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

تدوير واقي TDE

عندما تدير واقي TDE، فإنك تستبدل المفتاح الذي يحمي مفتاح تشفير قاعدة البيانات (DEK). تدوير المفاتيح هو عملية عبر الإنترنت ولا تستغرق سوى بضع ثوان. تقوم هذه العملية بفك تشفير وإعادة تشفير مفتاح تشفير قاعدة البيانات فقط، وليس قاعدة البيانات بأكملها.

يمكنك تدوير واقي TDE عن طريق تبديل الإعدادات لاستخدام مفتاح جديد مخزن في Azure Key Vault. اعتمادا على العرض والتكوين المدعوم، يمكن أن يكون هذا المفتاح:

  • التحول إلى نسخة مفتاح جديدة من نفس المفتاح
  • التحول إلى مفتاح مختلف

يمكن تدوير واقي TDE يدويا أو باستخدام ميزة الدوران الآلي.

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

ملحوظة

عندما تضبط TDE مع CMK باستخدام تدوير يدوي أو آلي للمفاتيح، فإنك تستخدم دائما أحدث إصدار من المفتاح الذي يدعمه النظام. الإعداد لا يسمح باستخدام نسخة سابقة أو أقل من المفاتيح. استخدام أحدث إصدار للمفتاح دائما يتوافق مع سياسة الأمان في Azure SQL التي تمنع الإصدارات السابقة من المفاتيح التي قد تكون مخترقة.

حامي TDE غير قابل للوصول

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

حالة غير قابلة للوصول

إذا كانت قاعدة البيانات غير متاحة بسبب انقطاع متقطع في الشبكة (مثل خطأ 5XX)، فلا حاجة لأي إجراء، حيث تعود قواعد البيانات تلقائيا. لتقليل تأثير أخطاء الشبكة أو الانقطاعات عند الوصول إلى حامي TDE في Azure Key Vault، تقدم الخدمة ذاكرة مؤقتة لمدة 24 ساعة قبل محاولة نقل قاعدة البيانات إلى حالة غير قابلة للوصول إليها. إذا حدث تحويل الفشل قبل الوصول إلى الحالة غير المتاحة، تصبح قاعدة البيانات غير متاحة بسبب فقدان ذاكرة التخزين المؤقت للتشفير.

إذا فقد الخادم الوصول إلى الحامي TDE الذي يديره العميل في Azure Key Vault بسبب أي خطأ في Azure Key Vault (مثل خطأ 4XX)، تنتقل قاعدة البيانات إلى حالة غير قابلة للوصول بعد 30 دقيقة.

استعادة الوصول إلى قاعدة البيانات بعد حدوث خطأ في Azure Key Vault

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

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

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

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

إلغاء الوصول العرضي إلى حامي TDE

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

  • إلغاء أذونات الحصول على المفاتيح أو إدارة HSM من الخادم

  • حذف المفتاح

  • حذف خزنة المفاتيح أو إدارة HSM

  • تغيير قواعد جدار الحماية لخزنة المفاتيح أو إدارة HSM

  • حذف الهوية المدارة للخادم في Microsoft Entra ID

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

الاتصال المحجب بين مثيل SQL المدار و Azure Key Vault

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

أكثر الأسباب شيوعا لنقص الاتصال الشبكي ب Azure Key Vault هي:

  • يتم كشف Azure Key Vault عبر نقطة نهاية خاصة وعنوان IP الخاص لخدمة Azure Key Vault غير مسموح به في القواعد الصادرة لمجموعة أمن الشبكة (NSG) المرتبطة بشبكة المثيل المدارة.

  • دقة DNS سيئة، مثل عندما لا يتم حل خزنة المفاتيح أو FQDN إدارة HSM أو تحل إلى عنوان IP غير صالح.

اختبر الاتصال من مثيل SQL المدار إلى Azure Key Vault الذي يستضيف الحامي TDE.

  • النقطة النهائية هي FQDN في الخزنة، مثل <vault_name.vault.azure.net> (بدون https://).
  • المنفذ المراد اختباره هو 443.
  • يجب أن تكون النتيجة ل RemoteAddress موجودة وتكون عنوان IP الصحيح
  • يجب أن تكون نتيجة اختبار TCP هي TcpTestSucceeded: صحيح.

في حال أعاد الاختبار TcpTestSucceeded: False، راجع إعدادات الشبكات:

  • تحقق من عنوان IP الذي تم حله، وتأكد من أنه صالح. القيمة المفقودة تعني وجود مشاكل في دقة DNS.

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

    • تحقق من تكوينات الشبكات الأخرى مثل جدول التوجيه، ووجود الجهاز الافتراضي وتكوينه، وما إلى ذلك.

مراقبة TDE الذي يديره العميل

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

  • Azure Resource Health. تظهر قاعدة البيانات غير المتاحة التي فقدت الوصول إلى حامي TDE ك "غير متوفر" بعد رفض الاتصال الأول بقاعدة البيانات.

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

  • يمكن تعريف مجموعات الإجراءات لإرسال إشعارات وتنبيهات بناء على تفضيلاتك، مثل البريد الإلكتروني، الرسائل النصية، الدفع (Push)، الصوت، تطبيق المنطق، Webhook، ITSM، أو Automation Runbook.

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

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

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

Important

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

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

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

لمعرفة المزيد حول استعادة النسخ الاحتياطي لمجموعات SQL المخصصة في Azure Synapse Analytics، راجع استعادة تجمع SQL مخصص.

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

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

باستخدام طبقات التكرار المتعددة في Azure Key Vault، يمكن لمؤشرات TDE التي تستخدم مفتاحا يديره العميل الاستفادة من توفر Azure Key Vault ومرونته. يمكنهم الاعتماد بالكامل على حل التكرار في Azure Key Vault.

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

يقدم Azure Key Vault المكونات التالية من حيث التوفر والمرونة تلقائيا دون تدخل المستخدم:

المحتوى ذو الصلة

  • تاريخ آخر تحديث في