Authentication in Azure Key Vault

تعمل المصادقة باستخدام Key Vault بالتزامن مع Microsoft Entra ID، المسؤولة عن التحقق من هوية أي principal security.

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

• يحدد المدير الأمني user شخصا لديه ملف في Microsoft Entra ID.

• يحدد مبدأ الأمان group مجموعة من المستخدمين الذين تم إنشاؤهم في Microsoft Entra ID. يتم منح أي أدوار أو أذون تم تعيينها للمجموعة لجميع المستخدمين داخل المجموعة.

• يعد كيان الخدمة نوعًا من مبادئ الأمان التي تحدد تطبيقًا أو خدمة، أي أنها جزء من التعليمة البرمجية، بدلًا من مستخدم أو مجموعة. يعمل معرف كائن كيان الخدمة مثل اسم المستخدم الخاص به؛ يعمل سر عميل كيان الخدمة مثل كلمة المرور الخاصة به.

بالنسبة للتطبيقات، هناك طريقتان للحصول على كيان الخدمة:

• مستحسن: تمكين هوية مدارة معينة من قبل النظام للتطبيق.

  مع الهوية المدارة، يدير Azure داخليا مبدأ الخدمة الخاص بالتطبيق ويصادق تلقائيا على التطبيق مع خدمات Azure الأخرى. تتوفر الهوية المُدارة للتطبيقات التي وُزِعت في مجموعة متنوعة من الخدمات.

  لمزيد من المعلومات، راجع نظرة عامة على الهوية المدارة. انظر أيضا Azure الخدمات التي تدعم إدارة الهوية ، والتي تربط بمقالات تشرح كيفية تفعيل الهوية المدارة لخدمات محددة (مثل خدمة التطبيقات، دالات Azure، Virtual Machines، إلخ).

• إذا لم تتمكن من استخدام الهوية المدارة، فإنك بدلا من ذلك register التطبيق مع المستأجر Microsoft Entra الخاص بك، كما هو موضح في Quickstart: تسجيل تطبيق في منصة الهوية Azure. ينشئ التسجيل أيضاً كائن تطبيق ثانٍ يحدد التطبيق عبر جميع المستأجرين.

سيناريوهات المصادقة في Key Vault

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

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

• المستخدم فقط: يصل المستخدم إلى خزنة المفاتيح من أي تطبيق مسجل في المستأجر. أمثلة على هذا النوع من الوصول تشمل Azure PowerShell وبوابة Azure. لكي يعمل هذا السيناريو عند استخدام سياسات الوصول (القديمة)، يجب تحديد المستخدم objectId في سياسة الوصول، applicationId يتم تحديد أو يجب أن يكون null. عند استخدام Azure RBAC، قم بتعيين الأدوار المناسبة للمستخدم.

• التطبيق زائد المستخدم (يشار إليه أحيانا بالهوية المركبة): يطلب من المستخدم الوصول إلى خزنة المفاتيح من تطبيق محدد ويجب على التطبيق استخدام تدفق المصادقة نيابة عن المستخدم (OBO) لانتحال شخصية المستخدم. لكي يعمل هذا السيناريو مع سياسات الوصول (القديمة)، يجب تحديد كلاهما applicationId في objectId سياسة الوصول. applicationId يحدد التطبيق المطلوب ويحدد objectId المستخدم. حاليا، هذا الخيار غير متوفر لمستوى البيانات Azure RBAC.

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

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

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

تكوين جدار الحماية الخاص ب Key Vault

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

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

تدفق عملية طلب Key Vault مع المصادقة

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

1. يطلب رمز للمصادقة باستخدام Microsoft Entra ID، على سبيل المثال:

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

2. إذا نجح التحقق باستخدام معرف Microsoft Entra ID، يمنح المعلم الأمني رمز OAuth.

3. استدعاء إلى واجهة برمجة تطبيقات Key Vault REST عبر نقطة النهاية (URI) الخاصة ب Key Vault.

4. يتحقق Key Vault Firewall من المعايير التالية. في حالة استيفاء أي معيار، يُسمح بالمكالمة. وإلا فسيتم حظر المكالمة وإعادة الرد المحظور.

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

5. إذا سمح جدار الحماية بالمكالمة، يستدعي Key Vault Microsoft Entra ID للتحقق من رمز وصول مدير الأمان.

6. يتحقق Key Vault مما إذا كان مدير الأمان لديه الإذن اللازم للتشغيل المطلوب. إذا لم يكن كذلك، يعيد Key Vault ردا ممنوعا.

7. يقوم Key Vault بتنفيذ العملية المطلوبة ويعيد النتيجة.

يوضح المخطط التالي العملية لتطبيق يستدعي واجهة برمجة تطبيقات "Get Secret" في Key Vault:

إشعار

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

المصادقة إلى Key Vault في كود التطبيق

يستخدم Key Vault SDK مكتبة عملاء Azure Identity، التي تسمح بالمصادقة السلسة على Key Vault عبر بيئات بنفس الكود

Azure مكتبات عملاء الهوية

.NET	Python	Java	JavaScript
Azure Identity SDK .NET	Azure Identity SDK Python	Azure Identity SDK Java	Azure Identity SDK JavaScript

لمزيد من المعلومات حول أفضل الممارسات وأمثلة المطورين، راجع Authenticate to Key Vault in code

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

• Key Vault دليل المطورين

• تعيين سياسة وصول Key Vault

• تعيين دور Azure RBAC إلى Key Vault

• Key Vault استكشاف أخطاء سياسة الوصول

• Key Vault رموز أخطاء واجهة برمجة التطبيقات REST

• ما هو Azure التحكم في الوصول القائم على الأدوار (Azure RBAC)؟