Data Encryption at rest in قاعدة بيانات Azure لـ PostgreSQL flexible server

يقوم قاعدة بيانات Azure لـ PostgreSQL الخادم المرن دائما بتشفير جميع البيانات الثابتة. تتضمن هذه البيانات جميع قواعد بيانات النظام والمستخدم وسجلات الخادم وشرائح سجل الكتابة المسبقة والنسخ الاحتياطية. التخزين الأساسي يتعامل مع التشفير من خلال تشفير الخادم في Azure Disk Storage.

التشفير الثابت باستخدام المفاتيح المدارة بواسطة الخدمة (SMK) أو المفاتيح التي يديرها العميل (CMK)

يدعم قاعدة بيانات Azure لـ PostgreSQL وضعين من تشفير البيانات الثابتة: المفاتيح المدارة بواسطة الخدمة (SMK)والمفاتيح التي يديرها العميل (CMK). تشفير البيانات باستخدام المفاتيح المدارة بواسطة الخدمة هو الوضع الافتراضي لخادم مرن قاعدة بيانات Azure لـ PostgreSQL. في هذا الوضع، تدير الخدمة تلقائيا مفاتيح التشفير المستخدمة لتشفير بياناتك. لا تحتاج إلى اتخاذ أي إجراء لتمكين التشفير أو إدارته في هذا الوضع.

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

يمكنك تحديد الوضع فقط في وقت إنشاء الخادم. لا يمكنك تغيير الوضع من واحد إلى آخر طوال مدة بقاء الخادم.

لتحقيق تشفير بياناتك، يستخدم قاعدة بيانات Azure لـ PostgreSQL تشفير تخزين Azure للبيانات الثابتة. عند استخدام CMK، تكون مسؤولا عن توفير مفاتيح لتشفير البيانات وفك تشفيرها في خدمات مخزن البيانات الثنائية الكبيرة ملفات Azure. يجب تخزين هذه المفاتيح في Azure Key Vault أو Azure Key Vault وحدة أمان الأجهزة المدارة (HSM). لمزيد من المعلومات، راجع المفاتيح التي يديرها العميل لتشفير تخزين Azure.

المزايا التي يوفرها كل وضع (SMK أو CMK)

يوفر تشفير البيانات باستخدام المفاتيح المدارة للخدمة لقاعدة بيانات Azure ل PostgreSQL المزايا التالية:

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

يوفر تشفير البيانات باستخدام المفاتيح المدارة من قبل العميل لقاعدة بيانات Azure ل PostgreSQL المزايا التالية:

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

متطلبات CMK

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

عند تكوين المفاتيح المدارة من قبل العميل لحساب تخزين، يقوم تخزين Azure بتغليف مفتاح تشفير البيانات الجذر (DEK) للحساب مع المفتاح المدار من قبل العميل في مخزن المفاتيح المقترن أو HSM المدار. تتغير حماية مفتاح تشفير الجذر، ولكن تظل البيانات الموجودة في حساب تخزين Azure مشفرة دائما. لا يوجد أي إجراء إضافي مطلوب من جانبك للتأكد من أن بياناتك تظل مشفرة. تسري الحماية بواسطة المفاتيح المدارة من قبل العميل على الفور.

Azure Key Vault هو نظام إدارة مفاتيح خارجي قائم على السحابة. إنه متوفر بشكل كبير ويوفر تخزينا آمنا وقابلا للتطوير لمفاتيح تشفير RSA ، مدعوما اختياريا بوحدات أمان الأجهزة (HSMs) التي تم التحقق من صحتها وفقا لمعيار FIPS 140 . لا يسمح بالوصول المباشر إلى مفتاح مخزن، ولكنه يوفر خدمات التشفير وفك التشفير للكيانات المعتمدة. يمكن ل Key Vault إنشاء المفتاح أو استيراده أو استلامه المنقول من جهاز HSM محلي.

توضح القائمة التالية متطلبات تكوين تشفير البيانات قاعدة بيانات Azure لـ PostgreSQL:

• لتكوينات CMK للمستأجر الفردي، يجب أن ينتمي Key Vault والخادم المرن قاعدة بيانات Azure لـ PostgreSQL إلى نفس المستأجر Microsoft Entra. للسيناريوهات بين المستأجرين، انظر مفاتيح إدارة العميل عبر المستأجرين. يتطلب نقل مورد Key Vault بعد ذلك إعادة تكوين تشفير البيانات.
• قم بتعيين Days للاحتفاظ بتكوين الخزائن المحذوفة Key Vault إلى 90 يوما. إذا قمت بتكوين مثيل Key Vault موجود برقم أقل، فإنه يظل صالحا. ومع ذلك، إذا كنت ترغب في تعديل هذا الإعداد وزيادة القيمة، يجب إنشاء مثيل Key Vault جديد. بمجرد إنشاء مثيل، لا يمكنك تعديل هذا الإعداد.
• تمكين الميزة المحذوفة مبدئيا في Key Vault للمساعدة في الحماية من فقدان البيانات إذا تم حذف مفتاح أو مثيل Key Vault عن طريق الخطأ. يحتفظ Key Vault بالموارد المحذوفة مبدئيا لمدة 90 يوما ما لم يستعيدها المستخدم أو يزيلها في هذه الأثناء. تحتوي إجراءات الاسترداد والإزالة على أذونات خاصة بها مقترنة بمخزن مفاتيح أو دور RBAC أو إذن نهج وصول. تكون الميزة المحذوفة مبدئيا قيد التشغيل بشكل افتراضي. إذا كان لديك Key Vault تم نشره منذ زمن بعيد، فقد يكون الحذف الناعم معطلا أيضا. في هذه الحالة، يمكنك تشغيله باستخدام Azure CLI.
• قم بتمكين الحماية من الإزالة لفرض فترة احتفاظ إلزامية بالمخازن وكائنات المخزن المحذوفة.
• امنح قاعدة بيانات Azure ل PostgreSQL الوصول المرن للهوية المدارة المعينة للمستخدم إلى المفتاح من خلال:
• المفضل: تكوين Azure Key Vault باستخدام نموذج إذن RBAC وتعيين الهوية المدارة دور مستخدم تشفير خدمة التشفير Key Vault.
• القديمة: إذا تم تكوين Azure Key Vault باستخدام نموذج إذن نهج الوصول، فامنح الأذونات التالية للهوية المدارة:
• get: لاسترداد الخصائص والجزء العام من المفتاح في Key Vault.
• list: لإدراج المفاتيح المخزنة في Key Vault والتكرار من خلالها.
• wrapKey: لتشفير مفتاح تشفير البيانات.
• unwrapKey: لفك تشفير مفتاح تشفير البيانات.
• يمكن أن يكون المفتاح المستخدم لتشفير مفتاح تشفير البيانات غير متماثل أو RSA أو RSA-HSM فقط. يتم دعم الأحجام الرئيسية من 2048 و3072 و4096. استخدم مفتاح 4096 بت للحصول على أمان أفضل.
• يجب أن يكون تاريخ ووقت تنشيط المفتاح (إذا تم تعيينه) في الماضي. يجب أن يكون تاريخ ووقت انتهاء الصلاحية (إذا تم تعيينه) في المستقبل.
• يجب أن يكون المفتاح في حالة التمكين .
• إذا كنت تقوم باستيراد مفتاح موجود إلى Key Vault، فقم بتوفيره بتنسيقات الملفات المدعومة (.pfx، .byokأو .backup).

تحديثات إصدار مفتاح CMK

يمكنك تكوين CMK لتدوير المفتاح يدويا وتحديثاته، أو لتحديثات إصدار المفتاح التلقائي بعد تدوير المفتاح يدويا أو تلقائيا في Key Vault.

لمزيد من المعلومات، راجع تكوين تشفير البيانات في خادم مرن قاعدة بيانات Azure لـ PostgreSQL.

Important

عند تدوير المفتاح إلى إصدار جديد، احتفظ بالمفتاح القديم متوفرا لإعادة التشفير للنجاح. بينما تحدث معظم عمليات إعادة التشفير في غضون 30 دقيقة، انتظر ساعتين على الأقل قبل تعطيل الوصول إلى إصدار المفتاح القديم.

تدوير المفاتيح يدويا والتحديثات

عند تكوين CMK مع تحديثات المفاتيح اليدوية، يجب تحديث إصدار المفتاح يدويا في خادم مرن قاعدة بيانات Azure لـ PostgreSQL بعد تدوير المفتاح يدويا أو تلقائيا في Key Vault. يستمر الخادم في استخدام النسخة القديمة حتى تقوم بتحديثها. يمكنك توفير هذا الوضع عن طريق تحديد مفتاح URI يتضمن الإصدار GUID في URI. على سبيل المثال، https://<keyvault-name>.vault.azure.net/keys/<key-name>/<key-version> حتى وقت قريب، كان هذا الخيار هو الخيار الوحيد المتاح.

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

تحديثات تلقائية لإصدار المفتاح

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

لتنفيذ هذا الأسلوب باستخدام Azure Resource Manager أو Bicep أو Terraform أو Azure PowerShell أو Azure CLI، قم بحذف الإصدار GUID من URI الرئيسي.

في المدخل، حدد خانة الاختيار لتوجيه واجهة المستخدم لمنع معرفات المستخدم الرسومية للإصدار أثناء التحديد التفاعلي وعند التحقق من صحة URI.

التوصيات

عند استخدام مفتاح مدار من قبل العميل لتشفير البيانات، اتبع هذه التوصيات لتكوين Key Vault:

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

ملاحظة

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

• احتفظ بنسخة من المفتاح الذي يديره العميل في مكان آمن، أو احفظه في خدمة الضمان.
• إذا قام Key Vault بإنشاء المفتاح، فقم بإنشاء نسخة احتياطية للمفتاح قبل استخدام المفتاح لأول مرة. يمكنك فقط استعادة النسخ الاحتياطي إلى Key Vault.

اعتبارات خاصة

إبطال الوصول إلى المفتاح العرضي من Azure Key Vault

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

• إلغاء تعيين دور RBAC لمستخدم تشفير خدمة تشفير Key Vault أو إبطال الأذونات من الهوية المستخدمة لاسترداد المفتاح في Key Vault.
• حذف المفتاح.
• حذف مثيل Key Vault.
• تغيير قواعد جدار حماية Key Vault.
• حذف الهوية المدارة للخادم في معرف Microsoft Entra.

مراقبة المفاتيح المحفوظة في Azure Key Vault

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

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

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

بعد تشفير الخادم المرن قاعدة بيانات Azure لـ PostgreSQL باستخدام مفتاح مدار من قبل العميل مخزن في Key Vault، يتم أيضا تشفير أي نسخة خادم تم إنشاؤها حديثا. يمكنك إنشاء هذه النسخة الجديدة من خلال عملية استعادة نقطة زمنية (PITR) أو قراءة النسخ المتماثلة.

عند إعداد تشفير البيانات باستخدام المفتاح المدار من قبل العميل، أثناء العملية مثل استعادة نسخة احتياطية أو إنشاء نسخة متماثلة للقراءة، يمكنك تجنب المشكلات باتباع الخطوات التالية على الخوادم الأساسية والمستعادة أو النسخة المتماثلة:

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

HSMs المدارة

وحدات أمان الأجهزة (HSMs) هي أجهزة مقاومة للعبث تساعد في تأمين عمليات التشفير من خلال إنشاء المفاتيح المستخدمة لتشفير البيانات وفك تشفير البيانات وإنشاء التوقيعات الرقمية وإنشاء الشهادات الرقمية. يتم اختبار HSMs والتحقق من صحتها واعتمادها وفقا لأعلى معايير الأمان ، بما في ذلك FIPS 140 والمعايير المشتركة.

Azure Key Vault Managed HSM هي خدمة سحابية مدارة بالكامل ومتوفرة بدرجة عالية ومستأجر واحد ومتوافقة مع المعايير. يمكنك استخدامه لحماية مفاتيح التشفير لتطبيقاتك السحابية من خلال HSMs التي تم التحقق من صحتها وفقا لمعيار FIPS 140-3.

عند إنشاء خادم مرن قاعدة بيانات Azure لـ PostgreSQL جديد في مدخل Azure باستخدام المفتاح المدار من قبل العميل، يمكنك اختيار Azure Key Vault HSM المدار كمخزن مفاتيح، كبديل Azure Key Vault. المتطلبات الأساسية، من حيث الهوية والأذونات المعرفة من قبل المستخدم، هي نفسها كما هو الحال مع Azure Key Vault (كما هو موضح سابقا في هذه المقالة). لمزيد من المعلومات حول كيفية إنشاء مثيل HSM مدار، ومزاياه واختلافاته عن مخزن شهادات مشترك يستند إلى Key Vault، وكيفية استيراد المفاتيح إلى HSM المدار، راجع ما هو Azure Key Vault Managed HSM؟.

حالة المفتاح المدار من قبل العميل يتعذر الوصول إليه

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

تتضمن بعض الأسباب المحتملة لحالة الخادم لتصبح غير قابلة للوصول ما يلي:

السبب	نوع الحل
يحتوي أي من مفاتيح التشفير التي يشير إليها الخادم على تاريخ ووقت انتهاء الصلاحية تم تكوينهما، ويتم الوصول إلى هذا التاريخ والوقت.	تمديد تاريخ انتهاء صلاحية المفتاح. ثم انتظر حتى تقوم الخدمة بإعادة التحقق من المفتاح ونقل حالة الخادم تلقائيا إلى جاهز. فقط عندما يكون الخادم في حالة جاهز يمكنك تدوير المفتاح إلى إصدار أحدث أو إنشاء مفتاح جديد، وتحديث الخادم بحيث يشير إلى هذا الإصدار الجديد من نفس المفتاح أو إلى المفتاح الجديد.
تقوم بتدوير المفتاح ونسيان تحديث مثيل قاعدة بيانات Azure لخادم PostgreSQL المرن بحيث يشير إلى الإصدار الجديد من المفتاح. تنتهي صلاحية المفتاح القديم ، الذي يشير إليه الخادم ، ويحول حالة الخادم إلى يتعذر الوصول إليها.	لتجنب هذا الموقف ، في كل مرة تقوم فيها بتدوير المفتاح ، تأكد أيضا من تحديث مثيل الخادم الخاص بك للإشارة إلى الإصدار الجديد. للقيام بذلك، استخدم az postgres flexible-server update، باتباع المثال الذي يصف "تغيير المفتاح/الهوية لتشفير البيانات. لا يمكن تفعيل تشفير البيانات بعد إنشاء الخادم، فهذا يحدث فقط المفتاح/الهوية.". إذا كنت تفضل تحديثه باستخدام واجهة برمجة التطبيقات، فيمكنك استدعاء نقطة نهاية الخوادم - تحديث الخدمة.
يمكنك حذف مثيل Key Vault، لا يمكن للخادم المرن قاعدة بيانات Azure لـ PostgreSQL الوصول إلى المفتاح والانتقال إلى حالة يتعذر الوصول إليها.	استرجع مثيل Key Vault وانتظر حتى تقوم الخدمة بتشغيل إعادة التحقق الدورية من المفتاح، وقم بنقل حالة الخادم تلقائيا إلى جاهز.
يمكنك حذف، من معرف Microsoft Entra، هوية مدارة تستخدم لاسترداد أي من مفاتيح التشفير المخزنة في Key Vault.	استرجع الهوية وانتظر حتى تقوم الخدمة بتشغيل إعادة التحقق الدورية من المفتاح، ونقل حالة الخادم تلقائيا إلى جاهز.
تم تكوين نموذج إذن Key Vault الخاص بك لاستخدام التحكم في الوصول المستند إلى الدور. يمكنك إزالة تعيين دور التحكم في الوصول استنادا إلى الدور لمستخدم تشفير خدمة تشفير Key Vault من الهويات المدارة التي تم تكوينها لاسترداد أي من المفاتيح.	امنح دور RBAC مرة أخرى للهوية المدارة وانتظر حتى تقوم الخدمة بتشغيل إعادة التحقق الدورية من المفتاح، ونقل حالة الخادم تلقائيا إلى جاهز. يتكون النهج البديل من منح الدور على Key Vault إلى هوية مدارة مختلفة، وتحديث الخادم بحيث يستخدم هذه الهوية المدارة الأخرى للوصول إلى المفتاح.
تم تكوين نموذج أذونات Key Vault لاستخدام نهج الوصول. يمكنك إبطال سياسات الوصول إلى القائمة أو الحصول عليها أو wrapKey أو إلغاء التفاف المفتاح من الهويات المدارة التي تم تكوينها لاسترداد أي من المفاتيح.	امنح دور RBAC مرة أخرى للهوية المدارة وانتظر حتى تقوم الخدمة بتشغيل إعادة التحقق الدورية من المفتاح، ونقل حالة الخادم تلقائيا إلى جاهز. يتكون النهج البديل من منح نهج الوصول المطلوبة على Key Vault إلى هوية مدارة مختلفة، وتحديث الخادم بحيث يستخدم هذه الهوية المدارة الأخرى للوصول إلى المفتاح.
يمكنك إعداد قواعد جدار حماية Key Vault المقيدة بشكل مفرط، بحيث لا يمكن لقاعدة بيانات Azure للخادم المرن PostgreSQL الاتصال ب Key Vault لاسترداد مفاتيحك.	عند تكوين جدار حماية Key Vault، تأكد من تحديد الخيار للسماح بخدمات Microsoft الموثوقة بحيث يمكن لقاعدة بيانات Azure لخادم PostgreSQL المرن تجاوز جدار الحماية.

ملاحظة

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

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

استعادة من حذف الهوية المدارة

إذا حذفت الهوية المدارة المعينة من قبل المستخدم والتي تصل إلى مفتاح التشفير المخزن في Key Vault في Microsoft Entra ID، فاتبع الخطوات التالية للاسترداد:

1. استرجع الهوية أو أنشئ هوية Entra ID مدارة جديدة.
2. إذا قمت بإنشاء هوية جديدة، حتى إذا كان لها نفس اسم الهوية المحذوفة بالضبط، فقم بتحديث قاعدة بيانات Azure لخصائص الخادم المرنة بحيث تعرف أنه يجب عليها استخدام هذه الهوية الجديدة للوصول إلى مفتاح التشفير.
3. تأكد من أن هذه الهوية لديها أذونات مناسبة للعمليات على المفتاح في Azure Key Vault (AKV).
4. انتظر لمدة ساعة تقريبا حتى يعيد الخادم التحقق من صحة المفتاح.

Important

ببساطة لا يسترد إنشاء هوية معرف إنترا جديدة بنفس اسم الهوية المحذوفة من حذف الهوية المدارة.

استخدم تشفير البيانات مع المفاتيح المدارة من العملاء وميزات استمرارية الأعمال المتكررة جغرافيا

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

• تحتاج إلى إنشاء مفتاح تشفير النسخ الاحتياطي المتكرر جغرافيا في مثيل Key Vault يجب أن يكون موجودا في المنطقة حيث يتم تخزين النسخ الاحتياطي الجغرافي المكرر.
• إصدار واجهة برمجة تطبيقات REST ل Azure Resource Manager لدعم خوادم CMK الممكنة للنسخ الاحتياطي المكررة جغرافيا هو معاينة 2022-11-01. إذا كنت ترغب في استخدام قوالب Azure Resource Manager لأتمتة إنشاء الخوادم التي تستخدم كلا من التشفير مع CMKs وميزات النسخ الاحتياطي المتكررة جغرافيا، فاستخدم إصدار واجهة برمجة التطبيقات هذا.
• لا يمكنك استخدام نفس الهوية المدارة من قبل المستخدم للمصادقة لمثيل Key Vault لقاعدة البيانات الأساسية ومثيل Key Vault الذي يحتوي على مفتاح التشفير للنسخ الاحتياطي المتكرر جغرافيا. للحفاظ على المرونة الإقليمية، قم بإنشاء الهوية المدارة من قبل المستخدم في نفس المنطقة مثل النسخ الاحتياطية المتكررة جغرافيا.
• إذا قمت بإعداد قاعدة بيانات النسخ المتماثلة للقراءة ليتم تشفيرها باستخدام CMKs أثناء الإنشاء، فيجب أن يكون مفتاح التشفير الخاص بها في مثيل Key Vault في المنطقة التي توجد بها قاعدة بيانات النسخة المتماثلة للقراءة. تحتاج إلى إنشاء الهوية المعينة من قبل المستخدم للمصادقة مقابل هذا المثيل Key Vault في نفس المنطقة.

مفاتيح مدارة من قبل العملاء عبر المستأجرين (CMK)

تسمح لك المفاتيح المدارة للعملاء عبر المستأجرين باستخدام مفاتيح التشفير المخزنة في مثيل HSM Key Vault أو المدار الذي ينتمي إلى Microsoft Entra ID مختلف عن الخادم المرن قاعدة بيانات Azure لـ PostgreSQL. يتطلب إعداد CMK عبر المستأجرين تكوين وتنسيق إضافي بين المستأجرين. في سيناريو التبديل بين المستأجرين، توجد مورد قاعدة بيانات Azure لقاعدة بيانات PostgreSQL في مستأجر يديره بائع برمجيات مستقل (ISV) يشار إليه بمزود الخدمة. المفتاح المستخدم لتشفير مورد قاعدة بيانات Azure لـ PostgreSQL موجود في خزنة مفاتيح في مستأجر مختلف يديرها العميل.

الإعداد

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

إعداد مستأجر موفر الخدمة (ISV)

• إنشاء تطبيق متعدد المستأجرين.
  • تكوين الهوية المدارة المعينة من قبل المستخدم كبيانات اعتماد موحدة على التطبيق.

إعداد مستأجر العميل

1. تثبيت التطبيق متعدد المستأجرين.
2. إنشاء أو استخدام مخزن مفاتيح موجود أو HSM مدار ومنح أذونات المفتاح للتطبيق متعدد المستأجرين.
   1. إنشاء مفتاح جديد أو استخدام مفتاح موجود.
   2. استرداد المفتاح من Azure Key Vault أو Azure HSM المدار وتسجيل معرف المفتاح.

على مستأجر موفر الخدمة (ISV)

حتى هذه النقطة، قمت بتكوين التطبيق متعدد المستأجرين على مستأجر موفر الخدمة. كما قمت بتثبيت التطبيق على مستأجر العميل وتكوين key vault والمفتاح على مستأجر العميل. بعد ذلك، يمكنك إنشاء خادم قاعدة بيانات Azure لـ PostgreSQL على مستأجر موفر الخدمة وتكوين المفاتيح المدارة من قبل العميل باستخدام المفتاح من مستأجر العميل.

عند إنشاء خادم قاعدة بيانات Azure لـ PostgreSQL باستخدام مفاتيح يديرها العميل، يجب التأكد من أنه لديه حق الوصول إلى المفاتيح التي استخدمها العميل. في سيناريوهات المستأجر الفردي، يمكنك منح مفتاح الوصول المباشر إلى الهوية التي يديرها المستخدم للخادم قاعدة بيانات Azure لـ PostgreSQL. في سيناريو بين المستأجرين المشتركين، لم يعد بإمكانك الاعتماد على الوصول المباشر إلى خزنة المفاتيح لأنها في مستأجر آخر يديره العميل. هذا القيد هو السبب في إنشاء تطبيق عبر المستأجرين وتسجيل هوية مدارة داخل التطبيق لمنحه الوصول إلى خزنة مفاتيح العميل في الأقسام السابقة. هذه الهوية المدارة، إلى جانب معرف التطبيق عبر المستأجرين، هي ما تستخدمه عند إنشاء CMK عبر المستأجرين لخادم قاعدة بيانات Azure لـ PostgreSQL.

تكوين مفاتيح مدارة من قبل العملاء عبر المستأجرين

حدد الواجهة التي تريد استخدامها لتكوين المفاتيح المدارة من قبل العملاء عبر المستأجرين.

Azure

لتكوين مفاتيح مدارة من قبل العملاء عبر المستأجرين لخادم قاعدة بيانات Azure لـ PostgreSQL جديد في مدخل Azure، اتبع الخطوات التالية:

1. في قاعدة بيانات Azure لـ PostgreSQL إنشاء المورد، اختر تبويب Security في بوابة Azure، ثم اختر Customer-Managed key.

2. تعيين الهوية المدارة المعينة من قبل المستخدم التي تم إنشاؤها كهوية مدارة مخصصة للمستخدم.

3. تعيين تطبيق متعدد المستأجرين باستخدام اسم التطبيق.

4. أدخل معرف مفتاح في طريقة تحديد المفتاح باستخدام معرف المفتاح الخاص بالعميل الذي تم الحصول عليه من مستأجر العميل.

استخدم المعلمات التالية لتكوين المفاتيح المدارة من قبل العملاء عبر المستأجرين باستخدام Azure CLI:

البارامتر	الوصف
--key	معرف المورد لمفتاح Key Vault الأساسي المستخدم لتشفير البيانات.
--identity	اسم أو معرف المورد للهوية المدارة المعينة للمستخدم المستخدمة لتشفير البيانات.
--federated-client-id	معرف العميل لتطبيق Microsoft Entra متعدد المستأجرين.
--backup-federated-client-id	معرف العميل للهوية الموحدة للنسخ الاحتياطي الجغرافي. استخدم هذه المعلمة فقط عند تمكين النسخ الاحتياطي المتكرر جغرافيا.

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

# Create the multitenant application registration in the service provider's tenant
federatedClientId=$(az ad app create --display-name myMultitenantApp --query appId -o tsv)

# Get the key identifier from the key vault in the customer's tenant
keyIdentifier=$(az keyvault key show --vault-name myVault --name myKey --query key.kid -o tsv)

# Create the server with the key from the customer's tenant
az postgres flexible-server create \
  --resource-group myResourceGroup \
  --name myServer \
  --location eastus2 \
  --key $keyIdentifier \
  --identity myIdentity \
  --federated-client-id $federatedClientId

لتدوير مفتاح التشفير على خادم موجود، قم بتشغيل الأمر التالي:

az postgres flexible-server update \
  --resource-group myResourceGroup \
  --name myServer \
  --key $newKeyIdentifier \
  --identity myIdentity \
  --federated-client-id $federatedClientId

واجهة برمجة التطبيقات REST

نشر قالب ARM مع المعلمات المحددة التالية:

ملاحظة

إذا كنت تعيد إنشاء هذه العينة في أحد قوالب Azure Resource Manager الخاصة بك، استخدم apiVersion من 2026-04-01-preview أو الإصدارات الأحدث. لا تتوفر خصائص تشفير البيانات عبر المستأجرين في إصدارات واجهة برمجة التطبيقات السابقة.

البارامتر	الوصف	قيمه المثال
primaryKeyUri	معرف المفتاح المدار من قبل العميل الموجود في مخزن مفاتيح موفر الخدمة.	https://my-vault.vault.azure.com/keys/my-key
primaryUserAssignedIdentity	كائن يحدد أنه يجب تعيين الهوية المدارة إلى الخادم المرن قاعدة بيانات Azure لـ PostgreSQL.	"identity":{"type":"UserAssigned","userAssignedIdentities":{"/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity":{}}}
primaryFederatedIdentityClientId	معرف العميل لتطبيق Microsoft Entra متعدد المستأجرين.	application-client-id

إليك مثالا على واجهة برمجة تطبيقات REST مع إعدادات المعلمات الثلاثة:

PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBforPostgreSQL/flexibleServers/{serverName}?api-version=2026-04-01-preview

مثال على جسم الطلب:

{
"location": "eastus2",
    "identity": {
        "type": "UserAssigned",
        "userAssignedIdentities": {
        "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>": {}
        }
    },
    "sku": {
        "name": "Standard_D2s_v3",
        "tier": "GeneralPurpose"
    },
    "properties": {
        "createMode": "Create",
        "version": "16",
        "minorVersion": "5",
        "storage": {
        "storageSizeGB": 32
        },
        "network": {
        "publicNetworkAccess": "Enabled"
        },
        "backup": {
        "backupRetentionDays": 7,
        "geoRedundantBackup": "Disabled"
        },
        "dataEncryption": {
        "type": "AzureKeyVault",
        "primaryUserAssignedIdentityId": "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>",
        "primaryKeyUri": "https://<customer-keyvault>.vault.azure.net/keys/<key-name>/<key-version>",
        "primaryFederatedIdentityClientId": "<application-client-id>"
        }
    }
}

إليك مثال على واجهة برمجة تطبيقات REST لتدوير المفاتيح. مثال PATCH يقوم فقط بتحديث URI مفتاح CMK لتدوير مفتاح التشفير دون إعادة إنشاء الخادم.

PATCH https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBforPostgreSQL/flexibleServers/{serverName}?api-version=2026-04-01-preview

جسم الطلب (مثال تدوير المفتاح):

{
    "properties": {
        "dataEncryption": {
        "type": "AzureKeyVault",
        "primaryUserAssignedIdentityId": "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>",
        "primaryKeyUri": "https://<customer-keyvault>.vault.azure.net/keys/<key-name>/<new-key-version>",
        "primaryFederatedIdentityClientId": "<application-client-id>"
        }
    }
}

Important

حتى لو قمت فقط بتحديث primaryKeyUri، يجب عليك تحديد جميع خصائص تشفير البيانات في جسم الطلب. إذا لم تقدم معرف التعريف الأساسي FederatedIdentityClientId في جسم الطلب، يتم التعامل مع الطلب كتكوين CMK غير عابر للمستأجرين.

قيود المفاتيح التي يديرها العميل (CMK)

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

جميع تكوينات المفاتيح التي يديرها العميل

تنطبق هذه القيود على أي تكوين مفتاح يديره العميل في خادم مرن قاعدة بيانات Azure لـ PostgreSQL أو مستأجر واحد أو عبر المستأجر:

• يمكنك تكوين تشفير المفتاح المدار من قبل العميل فقط عند إنشاء خادم جديد. لا يمكنك إضافته كتحديث إلى خادم مرن موجود قاعدة بيانات Azure لـ PostgreSQL. بدلا من ذلك، يمكنك استعادة نسخة احتياطية من PITR إلى خادم جديد باستخدام تشفير CMK.
• بعد تكوين تشفير المفتاح المدار من قبل العميل، لا يمكنك العودة إلى المفتاح المدار من قبل النظام. إذا كنت ترغب في العودة، يجب استعادة الخادم إلى خادم جديد مع تشفير البيانات الذي تم تكوينه باستخدام مفتاح مدار بواسطة النظام.
• يجب أن يكون مثيل Azure Key Vault Managed HSM أو مثيل Azure Key Vault حيث تخطط لتخزين مفتاح التشفير موجودا في نفس المنطقة حيث تقوم بإنشاء قاعدة بيانات Azure للخادم المرن.

مفاتيح مدارة من قبل العملاء عبر المستأجرين فقط

تنطبق هذه القيود فقط عند تكوين مفاتيح مدارة من قبل العملاء عبر المستأجرين:

• النسخ الاحتياطية للاحتفاظ طويل المدى (LTR) غير مدعومة حاليا على الخوادم التي تم تكوينها باستخدام مفاتيح مدارة من قبل العملاء عبر المستأجرين (CMK).
• لا يدعم Azure PowerShell هذه الميزة حاليا.

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

• تكوين تشفير البيانات في خادم مرن قاعدة بيانات Azure لـ PostgreSQL