توفير مصادقة مخصصة لخدمة Azure OpenAI من خلال بوابة

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

توضح هذه المقالة السيناريوهات الرئيسية التي توفر المصادقة ل Azure OpenAI:

• مصادقة تطبيقات العميل عبر موفر هوية خارجي

• مصادقة تطبيقات العميل عبر الشهادات

• مصادقة تطبيقات عميل متعددة عبر المفاتيح للوصول إلى مثيل Azure OpenAI مشترك

• مصادقة تطبيقات العميل التي تصل إلى مثيلات Azure OpenAI المتعددة

يصف كل سيناريو التحديات التي يقدمونها وفوائد دمج بوابة.

مصادقة تطبيقات العميل عبر موفر هوية خارجي

قم بتنزيل ملف Visio لهذه البنية.

قيود السيناريو

يحتوي هذا السيناريو على القيود التالية:

• تستخدم تطبيقات العميل موفر هوية خارجي ممكن ل OpenID Connect (OIDC) مثل Okta أو Auth0 أو موفري الهوية الاجتماعية.

• تتم مصادقة تطبيقات العميل مقابل مستأجر Microsoft Entra يختلف عن مستأجر مستوى بيانات Azure OpenAI.

يمكن تطبيق هذه القيود على الأمثلة التالية:

• تطبيقات العميل الحالية التي تصادق بالفعل على موفر OIDC خارجي أو معرف Microsoft Entra والتي تتكامل مع مثيلات Azure OpenAI.

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

الاتصال مباشرة ب Azure OpenAI

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

تقديم بوابة

قم بتنزيل ملف Visio لهذه البنية.

تحل البوابة تحديات هذا السيناريو بالطرق التالية:

• تستخدم البوابة التخويل المفتوح (OAuth) لمصادقة المستخدمين عبر موفري الهوية الخارجيين الحاليين. تتحقق البوابة من صحة رموز وصول المستخدم المصادق عليها، مثل رمز ويب JSON المميز (JWT)، الذي ينشئه موفر الهوية. ثم تمنح البوابة التخويل لمثيل Azure OpenAI المدعوم.

• لا تحتاج إلى إدارة مفاتيح العميل. يلغي هذا النهج المخاطر الأمنية للمصادقة المستندة إلى المفتاح.

• تتصل البوابة ب Azure OpenAI باستخدام هوية مدارة، ما يحسن الأمان عبر Azure RBAC الأقل امتيازا.

توصيات لهذا السيناريو

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

• تكوين هذا السيناريو لإدارة واجهة برمجة التطبيقات باستخدام النهج الواردة. استخدم النهج validate-jwt لفرض قيم وجود JWT المدعومة وصحتها وسمتها.

أسباب لتجنب بوابة لهذا السيناريو

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

مصادقة تطبيقات العميل عبر الشهادات

قم بتنزيل ملف Visio لهذه البنية.

قيود السيناريو

يحتوي هذا السيناريو على القيود التالية:

• تريد استخدام الشهادات لمصادقة تطبيقات العميل.

• لا يمكن لتطبيقات العميل استخدام معرف Microsoft Entra أو موفري OIDC الآخرين للمصادقة أو لا تريد استخدامها.

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

يمكن تطبيق هذه القيود على الأمثلة التالية:

• العميل الذي يصادق على Azure OpenAI هو جهاز أو جهاز ولا يحدث أي تفاعل للمستخدم.

• تتطلب مؤسستك استخدام الشهادات للمصادقة بسبب معايير الأمان ولوائح التوافق.

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

الاتصال مباشرة ب Azure OpenAI

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

تقديم بوابة

قم بتنزيل ملف Visio لهذه البنية.

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

توفر البوابة العديد من المزايا في هذا السيناريو:

• يمكنك استخدام الهوية المدارة للبوابة بدلا من مفاتيح الوصول، ما يلغي المخاطر المسروقة المفاتيح ويقلل من عبء صيانة تدوير المفتاح.

• يمكنك مركزية التحقق من صحة الشهادة، ما يضمن استخدام نهج أمان متسقة لتقييم شهادات العميل الرقمية لجميع التطبيقات الذكية.

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

توصيات لهذا السيناريو

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

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

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

• استخدم النهج في validate-client-certificate APIM للتحقق من صحة شهادات العميل التي يشير إليها Azure key vault. يتحقق هذا النهج من صحة شهادة العميل التي يقدمها تطبيق العميل ويتحقق من المصدر وتاريخ انتهاء الصلاحية وبصمة الإبهام وقوائم الإبطال.

أسباب لتجنب بوابة لهذا السيناريو

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

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

مصادقة تطبيقات عميل متعددة عبر المفاتيح للوصول إلى مثيل Azure OpenAI مشترك

قم بتنزيل ملف Visio لهذه البنية.

قيود السيناريو

يحتوي هذا السيناريو على القيود التالية:

• تصل تطبيقات العميل المتعددة إلى مثيل Azure OpenAI مشترك.
• لا يمكن للعملاء استخدام معرف Microsoft Entra للمصادقة أو لا تريد استخدامه.
• لا يمكن للعملاء استخدام الهوية الموحدة للمصادقة أو لا تريد استخدامها.
• تريد استخدام المصادقة المستندة إلى المفتاح لتطبيقات العميل.

يمكن تطبيق هذه القيود على الأمثلة التالية:

• يمكنك نشر تطبيقات العميل عبر بيئات متعددة، بما في ذلك Azure أو محليا أو موفري السحابة الآخرين.

• تحتاج المؤسسة إلى توفير Azure OpenAI لفرق مختلفة وتعيين حدود وصول واستخدام فريدة لكل فريق.

الاتصال مباشرة ب Azure OpenAI

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

• لا يمكنك إبطال الأذونات لعملاء معينين لأن كل عميل يشارك نفس المفتاح.

• لا يمكنك منح عملاء مختلفين حقوق وصول مختلفة لنماذج مختلفة في نفس نشر مثيل Azure OpenAI.

• لا يمكنك تمييز عميل واحد عن آخر من منظور التسجيل.

تقديم بوابة

قم بتنزيل ملف Visio لهذه البنية.

يمكنك إدخال بوابة في هذه البنية التي تصدر مفتاحا مخصصا لكل تطبيق عميل. تستخدم API Management مفهوم الاشتراكات لتوفير مفاتيح عميل مخصصة. يجب أن تستخدم البوابة هوية مدارة لمصادقة نفسها باستخدام Azure OpenAI.

توفر البوابة العديد من المزايا في هذا السيناريو:

• يمكنك إبطال الوصول إلى تطبيق عميل واحد دون التأثير على العملاء الآخرين.

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

• يمكنك تحديد كل عميل بشكل فريد من منظور التسجيل.

• تفرض البوابة حدود المعدل والحصص النسبية لكل عميل بشكل مستقل.

توصيات لهذا السيناريو

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

• تأكد من أن البوابة تتخذ قرارات التوجيه إلى عمليات نشر النموذج المناسبة استنادا إلى هوية العميل عند توجيه طلبات تطبيق عميل متعددة من خلال بوابة إلى مثيل Azure OpenAI مشترك. لمزيد من المعلومات، راجع استخدام بوابة أمام عمليات نشر Azure OpenAI المتعددة.

مصادقة تطبيقات العميل التي تصل إلى مثيلات Azure OpenAI المتعددة

قم بتنزيل ملف Visio لهذه البنية.

قيود السيناريو

يحتوي هذا السيناريو على القيود التالية:

• تتصل تطبيقات العميل بمثيلات Azure OpenAI متعددة في منطقة واحدة أو أكثر.
• لا يمكن للعملاء استخدام معرف Microsoft Entra أو موفري OIDC الآخرين للمصادقة أو لا تريد استخدامها.
• تريد استخدام المصادقة المستندة إلى المفتاح لتطبيقات العميل.

يمكن تطبيق هذه القيود على الأمثلة التالية:

• يجب أن توزع تطبيقات العميل أحمال العمل الخاصة بها جغرافيا لتقليل زمن الانتقال وتحسين الأداء.

• تحاول تطبيقات العميل تحسين الرموز المميزة الخاصة بها في الحصص النسبية الدقيقة عن طريق نشر المثيلات عبر مناطق متعددة.

• تتطلب المؤسسة إمكانات سلسة لتجاوز الفشل والتعافي من الكوارث لضمان التشغيل المستمر. لذلك يديرون استراتيجية التوزيع المزدوج، مثل الاستراتيجية التي تتكون من توزيع معدل النقل المقدم ونشر الدفع أولا بأول.

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

الاتصال مباشرة بمثيلات Azure OpenAI المتعددة

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

تقديم بوابة

قم بتنزيل ملف Visio لهذه البنية.

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

توصيات لهذا السيناريو

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

• ربط استخدام الرمز المميز لكل مستأجر في البوابة عند تنفيذ سيناريوهات متعددة المستأجرين مع مثيلات Azure OpenAI المتعددة. يضمن هذا الأسلوب تعقب إجمالي استخدام الرمز المميز، بغض النظر عن مثيل Azure OpenAI الخلفي الذي تتم إعادة توجيه الطلب إليه.

التوصيات العامة

عند دمج Azure OpenAI من خلال بوابة، هناك العديد من التوصيات الشاملة التي يجب مراعاتها والتي تنطبق في جميع السيناريوهات.

استخدم APIM بدلا من إنشاء الحل الخاص بك لتنسيق واجهة برمجة التطبيقات الفعال والتكامل السلس مع خدمات Azure الأخرى وتوفير التكاليف عن طريق تقليل جهود التطوير والصيانة. تضمن APIM إدارة واجهة برمجة التطبيقات الآمنة من خلال دعم المصادقة والتخويل مباشرة. وهو يتكامل مع موفري الهوية، مثل معرف Microsoft Entra، الذي يمكن OAuth 2.0 ويوفر تخويلا يستند إلى النهج. بالإضافة إلى ذلك، تستخدم APIM الهويات المدارة للوصول الآمن والمنخفض الصيانة إلى Azure OpenAI.

الجمع بين سيناريوهات حل بوابة شامل

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

قم بتنزيل ملف Visio لهذه البنية.

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

فرض نهج البوابة

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

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

للتحقق من صحة الرمز المميز للوصول، تأكد من التحقق من صحة جميع المطالبات المسجلة الرئيسية مثل issو expaudو وأي nbf مطالبات ذات صلة بحمل العمل مثل عضوية المجموعة أو أدوار التطبيق.

استخدام هويات Azure المُدارة

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

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

تنفيذ إمكانية المراقبة الشاملة

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

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

تطبيقات البوابة

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

المساهمون

كتب المساهمون التاليون هذه المقالة في الأصل.

الكتاب الرئيسيون:

• Lizet Pena De Sola | مهندس عملاء أول، FastTrack ل Azure
• Bappaditya Banerjee | مهندس عملاء أول، FastTrack ل Azure
• جيمس كروفت | مهندس عملاء، ISV ومركز التميز الأصلي الرقمي

لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.

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

• RBAC ل Azure OpenAI
• استخدام الهويات المدارة في APIM
• النُهج في API Management
• المصادقة والتخويل لواجهات برمجة التطبيقات في APIM
• حماية واجهة برمجة تطبيقات في APIM باستخدام OAuth 2.0 ومعرف Microsoft Entra
• تأمين الخدمات الخلفية باستخدام مصادقة شهادة العميل في APIM

الموارد ذات الصلة

• الوصول إلى Azure OpenAI ونماذج اللغات الأخرى من خلال بوابة