مشاركة عبر

تأمين Azure Functions

  • مقالة

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

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

  • يتم تأمين موارد التطبيق من موارد Azure للعملاء الآخرين.
  • يتم تحديث مثيلات الجهاز الظاهري وبرامج وقت التشغيل بانتظام لمعالجة الثغرات الأمنية المكتشفة حديثًا.
  • يظل اتصال البيانات السرية (مثل سلاسل الاتصال) بين تطبيقك وموارد Azure الأخرى (مثل قاعدة بيانات SQL) داخل Azure ولا يتجاوز أي حدود للشبكة. دائمًا ما يتم تشفير البيانات السرية عند تخزينها.
  • يتم تشفير جميع الاتصالات عبر ميزات اتصال App Service، مثل الاتصال المختلط.
  • يتم تشفير الاتصالات بأدوات الإدارة عن بعد مثل Azure PowerShell وAzure CLI وAzure SDKs وواجهات برمجة تطبيقات REST.
  • تحمي إدارة التهديدات على مدار 24 ساعة البنية التحتية والنظام الأساسي من البرامج الضارة وحجب الخدمة الموزع (DDoS) والاختراق الوسيط (MITM) وغيرها من التهديدات.

لمزيد من المعلومات حول أمان البنية الأساسية والنظام الأساسي في Azure، راجع Azure Trust Center.

للحصول على مجموعة من توصيات الأمان التي تتبع معيار أمان سحابة Microsoft، راجع أساس أمان Azure لوظائف Azure.

عملية آمنة

يرشدك هذا القسم إلى تكوين تطبيق وظيفة وتشغيله بشكل آمن قدر الإمكان.

Defender للسحابة

يتكامل Defender for Cloud مع تطبيق الوظائف في المدخل. ويوفر تقييماً سريعاً للثغرات الأمنية المحتملة المتعلقة بالتكوين مجاناً. يمكن لتطبيقات الوظائف التي تعمل في خطة مخصصة أيضا استخدام ميزات الأمان المحسنة ل Defender for Cloud مقابل تكلفة إضافية. لتتعرف على المزيد، اطلع على حماية تطبيقات الويب وواجهات برمجة تطبيقات Azure App Service.

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

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

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

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

لمزيد من توصيات الأمان الخاصة بإمكانية الملاحظة، اطلع على أساس أمان Azure لـ Azure Functions.

نقاط نهاية HTTP الآمنة

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

طلب HTTPS

بشكل افتراضي، يمكن للعملاء الاتصال بنقاط النهاية للوظيفة باستخدام كل من بروتوكول HTTP أو بروتوكول HTTPS. يجب إعادة توجيه HTTP إلى HTTPs لأن HTTPS يستخدم بروتوكول طبقة مآخذ توصيل آمنة أو بروتوكول أمان طبقة النقل (SSL/TLS) لتوفير اتصال آمن، ويكون مشفراً ومصادقاً. لتتعرف على كيفية القيام بذلك، اطلع على فرض HTTPS.

عند طلب HTTPS، يجب عليك أيضا طلب أحدث إصدار TLS. لتتعرف على كيفية القيام بذلك، اطلع على فرض إصدارات بروتوكول أمان طبقة النقل.

لمزيد من المعلومات، اطلع على الاتصالات الآمنة (بروتوكول أمان طبقة النقل).

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

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

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

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

تعطيل نقاط النهاية الإدارية

يمكن لتطبيقات الوظائف خدمة نقاط النهاية الإدارية /admin ضمن المسار التي يمكن استخدامها لعمليات مثل الحصول على معلومات حالة المضيف وإجراء استدعاءات الاختبار. عند الكشف، يجب أن تتضمن الطلبات مقابل نقاط النهاية هذه المفتاح الرئيسي للتطبيق. تتوفر العمليات الإدارية أيضا من خلال Azure Resource Manager Microsoft.Web/sites API، والتي تقدم Azure RBAC. يمكنك تعطيل /admin نقاط النهاية عن طريق تعيين functionsRuntimeAdminIsolationEnabled خاصية الموقع إلى true.

تفعيل مصادقة/تخويل خدمة التطبيق

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

استخدم إدارة Azure API (APIM) لمصادقة الطلبات

يوفر APIM خيارات أمان واجهة برمجة التطبيقات المختلفة للطلبات الواردة. لمعرفة المزيد، راجع نُهج مصادقة إدارة واجهة برمجة التطبيقات. باستخدام APIM في مكانه، يمكنك تكوين تطبيق الوظائف الخاص بك لقبول الطلبات فقط من عنوان IP لمثيل APIM الخاص بك. لمعرفة المزيد، راجع قيود عنوان IP.

الأذونات

كما هو الحال مع أي تطبيق أو خدمة، فإن الهدف هو تشغيل تطبيق الوظيفة بأقل أذونات ممكنة.

أذونات إدارة المستخدم

تدعم الوظائف التحكم في الوصول استناداً إلى الدور في Azure (Azure RBAC). أدوار Azure التي تدعمها الوظائف هي المساهم والمالك والقارئ.

تعد الأذونات فعالة على مستوى تطبيق الوظيفة. مطلوب دور المساهم لأداء معظم المهام الوظيفية على مستوى التطبيق. تحتاج أيضا إلى دور المساهم مع إذن قارئ المراقبة لتتمكن من عرض بيانات السجل في Application Insights. يمكن لدور المالك فقط حذف تطبيق الوظيفة.

تنظيم الوظائف حسب الامتياز

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

الهويات المُدارة

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

يمكن منح طلبك نوعين من الهويات:

  • ترتبط الهوية المعينة من قبل النظام للتطبيق ويتم حذفها إذا تم حذف التطبيق. يمكن أن يكون للتطبيق هوية واحدة معينة من قبل النظام.
  • الهوية التي يعيّنها المستخدم هي مورد Azure مستقل يمكن تعيينه لتطبيقك. يمكن أن يكون للتطبيق هويات متعددة يعينها المستخدم، ويمكن تعيين هوية واحدة يعينها المستخدم لموارد Azure متعددة، مثل تطبيقي App Service.

يمكن استخدام الهويات المدارة بدلاً من البيانات السرية للاتصالات من بعض المشغلات والروابط. اطلع على الاتصالات المستندة إلى الهوية.

لمزيد من المعلومات، اطلع على كيفية استخدام الهويات المدارة لـ App Service وAzure Functions.

تقييد الوصول إلى مشاركة الموارد عبر المصادر (CORS)

تعد مشاركة الموارد عبر المصادر (CORS) طريقة للسماح لتطبيقات الويب التي تعمل في مجال آخر بتقديم طلبات لنقاط نهاية مشغل HTTP. توفر App Service دعماً مدمجاً لتسليم عناوين مشاركة الموارد عبر المصادر المطلوبة في طلبات HTTP. يتم تحديد قواعد مشاركة الموارد عبر المصادر على مستوى تطبيق الوظيفة.

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

إدارة البيانات السرية

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

لا تقم بتخزين البيانات السرية في تعليمات وظيفتك البرمجية.

إعدادات التطبيق

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

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

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

ويمكنك أيضاً تشفير الإعدادات بشكل افتراضي في ملف local.settings.json عند تطوير الوظائف على جهاز الكمبيوتر المحلي. لمزيد من المعلومات، راجع تشفير ملف الإعدادات المحلية.

مراجع Key Vault

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

يعد Azure Key Vault عبارة عن خدمة توفر إدارة مركزية للبيانات السرية، مع تحكم كامل في نُهج الوصول ومحفوظات التدقيق. يمكنك استخدام مرجع Key Vault بدلاً من سلسلة الاتصال أو المفتاح في إعدادات التطبيق. لتتعرف على المزيد، اطلع على استخدام مراجع Key Vault لـ App Service وAzure Functions.

الاتصالات القائمة على الهوية

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

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

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

تحديد حصص الاستخدام

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

التحقق من صحة البيانات

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

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

معالجة الأخطاء

بينما يبدو الأمر أساسياً، من المهم أن تكتب بيانات برمجية جيدة لمعالجة للأخطاء في وظائفك. تظهر الأخطاء التي لم تتم معالجتها على المضيف وتتم معالجتها في وقت التشغيل. تتعامل الروابط المختلفة مع معالجة الأخطاء بشكل مختلف. لتتعرف على المزيد، اطلع على معالجة أخطاء Azure Functions .

تعطيل تصحيح الأخطاء عن بعد

تأكد من تعطيل تصحيح الأخطاء عن بعد، إلا عندما تعمل على تصحيح وظائفك بشكل نشط. يمكنك تعطيل تصحيح الأخطاء عن بُعد في علامة التبويب إعدادات عامة لتطبيق الوظيفة التكوين في المدخل.

تقييد الوصول إلى مشاركة الموارد عبر المصادر (CORS)

تدعم Azure Functions مشاركة الموارد عبر المنشأ (CORS). يتم تكوين CORS في المدخل ومن خلال Azure CLI. تنطبق قائمة الأصول المسموح بها لـ CORS على مستوى تطبيق الدالات. مع تمكين CORS، تتضمن Access-Control-Allow-Origin الاستجابات العنوان. لمزيد من المعلومات، راجع مشاركة الموارد عبر المنشأ.

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

تشفير البيانات المخزنة

يقوم Azure Storage بتشفير كافة البيانات الثابتة في حساب تخزين. لمزيد من المعلومات، راجع تشفير خدمة تخزين Azure للبيانات الثابتة.

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

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

هام

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

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

توزيع آمن

تعمل أدوات Azure Functions على تسهيل نشر التعليمات البرمجية لمشروع الوظيفة المحلي إلى Azure. من المهم فهم كيفية عمل النشر عند التفكير في الأمان لطبولوجيا Azure Functions.

بيانات اعتماد النشر

تتطلب عمليات نشر App Service مجموعة من بيانات اعتماد النشر. تُستخدم بيانات اعتماد النشر هذه لتأمين عمليات نشر تطبيق الوظيفة. تتم إدارة بيانات اعتماد النشر بواسطة نظام App Service الأساسي ويتم تشفيرها في حالة الثبات.

يوجد نوعان من بيانات اعتماد النشر:

  • بيانات الاعتماد على مستوى المستخدم: مجموعة واحدة من بيانات الاعتماد لحساب Azure بأكمله. يمكن استخدامه للتوزيع في App Service لأي تطبيق، في أي اشتراك، لديه إذن الوصول إلى حساب Azure. إنها المجموعة الافتراضية التي تظهر في واجهة المستخدم الرسومية للمدخل (مثل نظرة عامةوخصائصصفحة موارد التطبيق). عند منح المستخدم حق الوصول إلى التطبيق عبر التحكم في الوصول استناداً إلى الدور (RBAC) أو أذونات coadmin، يمكن لهذا المستخدم استخدام بيانات الاعتماد الخاصة به على مستوى المستخدم حتى يتم إبطال الوصول. لا تشارك بيانات الاعتماد هذه مع مستخدمي Azure الآخرين.

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

في الوقت الحالي، لا يتم دعم Key Vault لنشر بيانات الاعتماد. لتتعرف على المزيد حول إدارة بيانات اعتماد النشر، اطلع على تكوين بيانات اعتماد النشر لـ Azure App Service.

تعطيل بروتوكول نقل الملفات

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

لا يُنصح باستخدام بروتوكول نقل الملفات لنشر تعليمات وظيفتك البرمجية. تعد عمليات نشر بروتوكول نقل الملفات عمليات يدوية، وتتطلب منك مزامنة المشغلات. لتتعرف على المزيد، اطلع على نشر بروتوكول نقل الملفات.

عندما لا تخطط لاستخدام بروتوكول نقل الملفات، يجب عليك تعطيله في المدخل. إذا اخترت استخدام بروتوكول نقل الملفات، فيجب عليك فرض بروتوكولات نقل الملفات.

تأمين نقطة نهاية إدارة سلسلة التوريد

يحتوي كل تطبيق وظيفة على نقطة نهاية خدمة مقابلة scm تستخدمها خدمة الأدوات المتقدمة (Kudu) لعمليات النشر وملحقات مواقع App Service الأخرى. دائماً ما تكون نقطة نهاية إدارة سلسلة التوريد لتطبيق الوظيفة عبارة عن عنوان URL بالشكل https://<FUNCTION_APP_NAME.scm.azurewebsites.net>. عند استخدام عزل الشبكة لتأمين وظائفك، يجب عليك أيضاً حساب نقطة النهاية هذه.

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

التحقق المستمر من صحة الأمان

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

أمن الشبكة

يتيح لك تقييد الوصول إلى الشبكة لتطبيق الوظائف التحكم في من يمكنه الوصول إلى نقاط النهاية الخاصة بوظائفك. تستفيد الوظائف من البنية الأساسية لـ App Service لتمكين وظائفك من الوصول إلى الموارد دون استخدام عناوين قابلة للتوجيه عبر الإنترنت أو لتقييد الوصول إلى الإنترنت إلى نقطة نهاية الوظيفة. لتتعرف على المزيد حول خيارات الشبكة هذه، اطلع على خيارات شبكة Azure Functions.

تعيين قيود الوصول

تتيح لك قيود الوصول تحديد قوائم قواعد السماح/الرفض للتحكم في نقل البيانات إلى تطبيقك. يتم تقييم القواعد بترتيب الأولوية. إذا لم توجد قواعد محددة، فسيقبل تطبيقك نقل البيانات من أي عنوان. لتتعرف على المزيد، اطلع على قيود وصول Azure App Service.

تأمين حساب التخزين

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

نشر تطبيق الوظائف الخاص بك إلى شبكة ظاهرية

تُعد Azure Private Endpoint واجهة شبكة تربطك بشكل خاص وآمن بخدمة مدعومة من Azure Private Link. تستخدم نقطة النهاية الخاصة عنوان بروتوكول إنترنت خاصًا من شبكتك الظاهرية، ما يجعل الخدمة في شبكتك الافتراضية تعمل بشكل فعال.

يمكنك استخدام نقطة النهاية الخاصة للوظائف المستضافة في خطط PremiumوApp Service.

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

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

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

نشر تطبيق وظيفتك بمعزل عن غيره

توفر Azure App Service Environment بيئة استضافة مخصصة لتشغيل وظائفك. تتيح لك هذه البيئات تكوين بوابة أمامية واحدة يمكنك استخدامها لمصادقة جميع الطلبات الواردة. للمزيد من المعلومات، راجع تكوين جدار حماية تطبيق الويب (WAF) لبيئة خدمة التطبيقات.

استخدام خدمة البوابة

تتيح لك خدمات البوابة، مثل Azure Application Gateway وAzure Front Door إعداد Web Application Firewall (WAF). تُستخدم قواعد WAF لمراقبة الهجمات المكتشفة أو منعها، مما يوفر طبقة إضافية من الحماية لوظائفك. لإعداد WAF، يجب تشغيل تطبيق الوظيفة في ASE أو باستخدام نقاط النهاية الخاصة (معاينة). لتتعرف على المزيد، اطلع على استخدام نقاط النهاية الخاصة.

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