أمان Azure Key Vault

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

نظرة عامة على ميزات الأمان وأفضل الممارسات لـ Azure Key Vault.

إشعار

للحصول على قائمة شاملة بتوصيات أمان Azure Key Vault، راجع أساس الأمان لـ Azure Key Vault.

أمن الشبكة

يمكنك تقليل تعرض الخزائن الخاصة بك عن طريق تحديد عناوين IP التي يمكنها الوصول إليها. تتيح لك نقاط نهاية خدمة الشبكة الظاهرية لـ Azure Key Vault تقييد الوصول إلى شبكة افتراضية محددة. تسمح لك نقاط النهاية أيضاً بتقييد الوصول إلى قائمة نطاقات عناوين IPv4 (إصدار بروتوكول الإنترنت 4). يتم رفض وصول أي مستخدم يتصل بخزنة المفاتيح من خارج تلك المصادر. للتعرف على المزيد من المعلومات، راجع نقاط النهاية لخدمة الشبكة الظاهرية في Azure Key Vault

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

تتيح لك خدمة Azure Private Link الوصول إلى Azure Key Vault وخدمات العملاء/الشركاء المستضافة من Azure عبر "نقطة نهاية خاصة" في الشبكة الظاهرية. تُعد نقطة النهاية الخاصة في Azure هي واجهة شبكة تربطك بشكل خاص وآمن بخدمة مُشغّلة بواسطةAzure Private Link. تستخدم نقطة النهاية الخاصة عنوان IP خاصًّا من الشبكة الظاهرية الخاصة بك، مما يؤدي إلى جلب الخدمة بشكل فعال إلى الشبكة الظاهرية الخاصة بك. يمكن توجيه كافة حركة المرور إلى الخدمة من خلال نقطة النهاية الخاصة، لذلك لا توجد بوابات أو أجهزة NAT أو اتصالات ExpressRoute أو VPN أو عناوين IP عامة مطلوبة. قم بنقل البيانات بين شبكتك الظاهرية وخدمات الاجتياز عبر شبكة Microsoft الأساسية، مما يلغي التعرض للإنترنت العام. يمكنك الاتصال بمثيل مورد Azure، مما يمنحك أعلى مستوى من الدقة في التحكم في الوصول. للاطلاع على خطوات التنفيذ، راجع تكامل Key Vault مع Azure Private Link

TLS و HTTPS

  • الواجهة الأمامية لـ Key Vault (مستوى البيانات) هي خادم متعدد المستأجرين. وهذا يعني أن خزائن المفاتيح من عملاء مختلفين يمكن أن تشترك في نفس عنوان IP العام. من أجل تحقيق العزل، يتم مصادقة كل طلب HTTP وتخويله بشكل مستقل عن الطلبات الأخرى.
  • بروتوكول HTTPS يسمح للعميل بالمشاركة في التفاوض TLS. يمكن للعملاء فرض إصدار TLS، وكلما فعل العميل ذلك، سيستخدم الاتصال بأكمله حماية المستوى المقابل. يدعم Key Vault إصدارات بروتوكول TLS 1.2 و1.3.

إشعار

يمكنك مراقبة إصدار TLS المستخدم من قبل العملاء من خلال مراقبة سجلات Key Vault باستخدام نموذج استعلام Kusto هنا.

مصادقة Key Vault

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

  • التطبيق فقط: يمثل التطبيق كيان الخدمة أو هوية مُدارة. هذه الهوية هي السيناريو الأكثر شيوعًا للتطبيقات التي تحتاج بشكل دوري للوصول إلى الشهادات أو المفاتيح أو الأسرار من قبو المفاتيح. لكي يعمل هذا السيناريو، objectId يجب تحديد التطبيق في نهج الوصول ويجب applicationIdألا يتم تحديده أو يجب أن يكون null.
  • المستخدم فقط: يصل المستخدم إلى قبو المفتاح من أي تطبيق مسجل في المستأجر. تتضمن أمثلة هذا النوع من الوصول Azure PowerShell وAzure portal. لكي يعمل هذا السيناريو، objectId يجب تحديد التطبيق في نهج الوصول ويجب applicationIdألا يتم تحديده أو يجب أن يكون null.
  • التطبيق بالإضافة إلى المستخدم (يشار إليها أحيانًا باسم الهوية المركبة):يطلب من المستخدم الوصول إلى قبو المفتاح من تطبيق معين ويجب على التطبيق استخدام تدفق المصادقة (OBO) نيابة عن انتحال شخصية المستخدم. لكي يعمل هذا السيناريو، يجب تحديد كليهما applicationIdobjectId في نهج الوصول. applicationIdيعرف التطبيق المطلوب ويحدد objectId المستخدم. حاليًّا، هذا الخيار غير متوفر لطائرة البيانات Microsoft Azure RBAC.

في جميع أنواع الوصول، يصادق التطبيق مع معرف Microsoft Entra. يمكن للتطبيق استخدام أي طريقة مصادقة مدعومة استنادًا إلى نوع التطبيق. التطبيق يكتسب رمز مميز للمورد في الوحدتين لمنح حق الوصول. المورد هو نقطة نهاية في وحدة الإدارة أو البيانات، استناداً إلى بيئة Azure. يستخدم التطبيق الرمز المميز ويرسل طلب "REST API" إلى Key Vault. لمعرفة المزيد، راجع تدفق المصادقة بالكامل.

نموذج آلية واحدة للمصادقة لكلتا الوحدتين له العديد من الفوائد:

  • يمكن للمؤسسات التحكم في الوصول مركزيًّا إلى جميع الخزائن الرئيسية في مؤسستها.
  • إذا غادر المستخدم، يفقد على الفور حق الوصول إلى جميع key vaults في المؤسسة.
  • يمكن للمؤسسات تخصيص المصادقة باستخدام الخيارات في معرف Microsoft Entra، مثل تمكين المصادقة متعددة العوامل للأمان المضاف.

لمزيد من المعلومات حول أساسيات الأمان، راجع مصادقة Key Vault.

نظرة عامة على طراز الوصول

يتم التحكم بالوصول إلى وحدة HSM المدارة من خلال واجهتين: وحدة الإدارةووحدة البيانات. وحدة الإدارة هو المكان الذي تدير فيه Key Vault نفسه. تتضمن العمليات في هذا المستوى إنشاء وحذف key vaults واسترداد خصائص "key vaults" وتحديث سياسات الوصول. وحدة البيانات هو المكان الذي تعمل فيه مع البيانات المخزنة في key vaults. يمكنك إضافة المفاتيح والأسرار والشهادات وحذفها وتعديلها.

تستخدم كلتا الوحدتين معرف Microsoft Entra للمصادقة. للتخويل، يستخدم مستوى الإدارة عنصر تحكم الوصول المستند إلى دور Azure (Azure RBAC) ويستخدم مستوى البيانات نهج الوصول إلى مفتاح Vault و Azure RBAC لعمليات مستوى بيانات Key Vault.

للوصول إلى key vault في أي من الوحدتين (المستويين) يجب أن يكون لدى جميع المتصلين (المستخدمين أو التطبيقات) المصادقة والتخويل المناسبين. المصادقة تأسيس هوية المتصل (المستخدم). يحدد التخويل العمليات التي يمكن للمتصل تنفيذها. تعمل المصادقة مع Key Vault جنبا إلى جنب مع معرف Microsoft Entra، المسؤول عن مصادقة هوية أي أساس أمان معين.

أساس الأمان هو كائن يمثّل مستخدمًا أو مجموعة أو خدمة أو تطبيقًا يطلب الوصول إلى موارد Azure. يقوم Azure بتعيين معرف كائن فريد لكل أساس أمان.

  • يحدد أساس أمان المستخدم فردا لديه ملف تعريف في معرف Microsoft Entra.
  • يحدد أساس أمان المجموعة مجموعة من المستخدمين الذين تم إنشاؤهم في Microsoft Entra ID. يتم منح أي أدوار أو أذون تم تعيينها للمجموعة لجميع المستخدمين داخل المجموعة.
  • يعد كيان الخدمة نوعًا من مبادئ الأمان التي تحدد تطبيقًا أو خدمة، أي أنها جزء من التعليمة البرمجية، بدلًا من مستخدم أو مجموعة. يُعرَف معرِّف عنصر كيان الخدمة باسم معرِّف العميل، ويعمل مثل اسم المستخدم الخاص به. كيان الخدمة الرئيسي السري أو الشهادة يعمل مثل كلمة المرور الخاصة به. تدعم العديد من خدمات Azure تعيين الهوية المدارة مع الإدارة التلقائية لمعرف العميلوالشهادة. الهوية المدارة هي الخيار الأكثر أمانًا والموصى به للمصادقة داخل Azure.

لمزيد من المعلومات حول المصادقة على مفتاح Vault، راجع المصادقة على Azure Key Vault.

نظام الوصول المشروط

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

لمزيد من المعلومات، راجع واجهات برمجة تطبيقات الوصول المشروط

الوصول المتميز

يحدد التخويل العمليات التي يمكن للمتصل تنفيذها. يستخدم التخويل في Key Vault التحكم في الوصول المستند إلى دور Azure (Azure RBAC) على مستوى الإدارة ونُهج الوصول إما Azure RBAC أو Azure Key Vault على مستوى البيانات.

يتم الوصول إلى الخزائن من خلال واجهتين أو طائرتين. هاتان الطائرتان هما طائرة الإدارة وطائرة البيانات.

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

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

يعرض الجدول التالي نقاط النهاية الخاصة بوحدتي الإدارة والبيانات.

الوصول إلى الوحدة الوصول إلى نقاط النهاية العمليات آليات التحكم بالوصول
وحدة تحكم الإدارة عمومي:
management.azure.com:443

Microsoft Azure المشغل بواسطة 21Vianet:
management.chinacloudapi.cn:443

حكومة Azure الأمريكية:
management.usgovcloudapi.net:443

Azure ألمانيا:
management.microsoftazure.de:443
إنشاء خزائن المفاتيح وقراءتها وتحديثها وحذفها

قم بتعيين نهج الوصول إلى Key Vault

تعيين علامات Vault للمفاتيح
Azure RBAC
خطة البيانات عمومي:
<vault-name>.vault.azure.net:443

Microsoft Azure المشغل بواسطة 21Vianet:
<vault-name>.vault.azure.cn:443

حكومة Azure الأمريكية:
<vault-name>.vault.usgovcloudapi.net:443

Azure ألمانيا:
<vault-name>.vault.microsoftazure.de:443
المفاتيح: تشفير، فك التشفير، wrapKey، unwrapKey، التوقيع، التحقق، الحصول على، قائمة، إنشاء، تحديث، استيراد، حذف، استرداد، النسخ الاحتياطي، استعادة، إزالة، تدوير (معاينة)، getrotationpolicy (معاينة)، setrotationpolicy (معاينة)، الإصدار(معاينة)

شهادات: managecontacts، getissuers، listissuers، setissuers، حذف، manageissuers، الحصول على، قائمة، إنشاء، استيراد، تحديث، حذف، استرداد، النسخ الاحتياطي، استعادة، تطهير

أسرار: الحصول على، قائمة، تعيين، حذف، استرداد، النسخ الاحتياطي، استعادة، تطهير
سياسة الوصول إلى Vault الرئيسية أو Azure RBAC

إدارة الوصول الإداري إلى مفتاح Vault

عند إنشاء مخزن مفاتيح في مجموعة موارد، يمكنك إدارة الوصول باستخدام معرف Microsoft Entra. يمكنك منح المستخدمين أو المجموعات القدرة على إدارة مخازن المفاتيح في مجموعة موارد. يمكنك منح حق الوصول على مستوى نطاق معين عن طريق تعيين أدوار Azure المناسبة. لمنح حق الوصول إلى مستخدم لإدارة مخازن المفاتيح، يمكنك تعيين دور key vault Contributor محدد مسبقًا للمستخدم في نطاق معين. يمكن تعيين مستويات النطاقات التالية إلى دور Azure:

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

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

هام

عند استخدام نموذج إذن نهج الوصول، إذا كان لدى المستخدم Contributor، Key Vault Contributor أو دور آخر لديه Microsoft.KeyVault/vaults/write أذونات لمستوى إدارة خزنة المفاتيح، يمكن للمستخدم منح نفسه حق الوصول إلى مستوى البيانات عن طريق تعيين نهج الوصول إلى Key Vault. يجب أن تتحكم بشدة في من لديه حق الوصول إلى دور Contributor مخازن المفاتيح الخاصة بك من خلال نموذج إذن نهج الوصول للتأكد من أن الأشخاص المخولين فقط يمكنهم الوصول إلى مخازن المفاتيح والمفاتيح والبيانات السرية والشهادات وإدارتها. يوصى باستخدام نموذج إذن التحكم في الوصول استنادًا إلى الدور (RBAC) الجديد لتجنب هذه المشكلة. باستخدام نموذج إذن التحكم في الوصول استنادا إلى الدور، تقتصر إدارة الأذونات على أدوار "المالك" و"المستخدم مسؤول istrator"، ما يسمح بفصل المهام بين أدوار عمليات الأمان والعمليات الإدارية العامة.

التحكم في الوصول إلى بيانات "مفتاح Vault"

يمكنك التحكم في الوصول إلى مفاتيح Key Vault والشهادات والبيانات السرية باستخدام نهج وصول Azure RBAC أو Key Vault.

لمزيد من المعلومات، راجع

التسجيل والمراقبة

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

يمكنك دمج "Key Vault" مع "شبكة الأحداث" ليتم إعلامك عند تغيير حالة مفتاح أو شهادة أو سر مخزن في خزنة المفاتيح. نظرة عامة: مراقبة Key Vault من خلال Azure Event Grid

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

النسخ الاحتياطي والاسترداد.

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

تأكد من إجراء نسخ احتياطية منتظمة من المخزن الخاص بك عند تحديث / حذف / إنشاء عناصر داخل Vault.

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