إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
يوفر Azure App Service البنية الأساسية للاستضافة لتطبيقات الوظائف. توفر هذه المقالة استراتيجيات أمان لتشغيل تعليمات الوظيفة البرمجية، وكيفية مساعدة App Service في تأمين وظائفك.
تؤمن Azure App Service مكونات النظام الأساسي الخاصة بها وتتصلبها، بما في ذلك أجهزة Azure الظاهرية (VMs) والتخزين واتصالات الشبكة وأطر عمل الويب وميزات الإدارة والتكامل. تخضع App Service لفحوصات امتثال مستمرة وصارمة لضمان ما يلي:
- يتم فصل كل تطبيق عن تطبيقات وموارد Azure الأخرى.
- تتناول التحديثات المنتظمة للأجهزة الظاهرية وبرنامج وقت التشغيل الثغرات الأمنية المكتشفة حديثا.
- يحدث اتصال الأسرار وسلاسل الاتصال بين التطبيقات وموارد Azure الأخرى مثل قاعدة بيانات Azure SQL فقط داخل Azure، دون عبور أي حدود للشبكة. يتم تشفير الأسرار المخزنة دائما.
- يتم تشفير جميع الاتصالات عبر ميزات اتصال خدمة التطبيقات مثل الاتصال المختلط .
- يتم تشفير جميع الاتصالات عبر أدوات الإدارة عن بعد مثل Azure PowerShell وAzure CLI وAzure SDKs وواجهات برمجة تطبيقات REST.
- تحمي إدارة التهديدات المستمرة البنية التحتية والنظام الأساسي من البرامج الضارة، وحجب الخدمة الموزع (DDoS) والهجمات التي تحدث في الوسط، وغيرها من التهديدات.
لمزيد من المعلومات حول أمان البنية الأساسية والنظام الأساسي في Azure، راجع مركز توثيق Azure.
للحصول على مجموعة من توصيات الأمان التي تتبع معيار أمان سحابة Microsoft، راجع أساس أمان Azure لوظائف Azure.
بينما التخطيط للتطوير الآمن ونشر وتشغيل الوظائف بدون خادم هو مشابه لأي تطبيق قائم على الويب أو مستضاف سحابيا، إلا أن التطبيقات بدون خادم غالبا ما تكون عرضة لأنواع مختلفة من الهجمات التقليدية. لمعرفة المزيد عن الهجمات المحتملة على البنية التحتية بدون خادم، راجع أفضل 10 في OWASP: التفسير بدون خادم.
عملية آمنة
يرشدك هذا القسم إلى تكوين تطبيق وظيفة وتشغيله بشكل آمن قدر الإمكان.
Defender للسحابة
يتكامل Defender for Cloud مع تطبيق الوظائف في المدخل. يوفر تقييما سريعا للثغرات الأمنية المحتملة المتعلقة بالتكوين. يمكن لتطبيقات الوظائف التي تعمل في خطة مخصصة أيضا استخدام ميزات الأمان المحسنة ل Defender for Cloud مقابل تكلفة إضافية. لمزيد من المعلومات، راجع Defender for App Service.
التسجيل والمراقبة
تتمثل إحدى طرق اكتشاف الهجمات في مراقبة النشاط وتحليلات التسجيل. تتكامل الوظائف مع Application Insights لجمع بيانات السجل والأداء والخطأ لتطبيق الوظائف. يكتشف Application Insights تلقائيا حالات الشذوذ في الأداء ويتضمن أدوات تحليلات قوية لمساعدتك في تشخيص المشكلات وفهم كيفية استخدام وظائفك. للمزيد من المعلومات، راجع مراقبة دوال Azure.
تتكامل الوظائف أيضاً مع سجلات Azure Monitor لتمكينك من دمج سجلات تطبيقات الوظائف مع أحداث النظام لإجراء تحليل أسهل. يمكنك استخدام إعدادات التشخيص لتكوين تصدير دفق سجلات النظام الأساسي والمقاييس لوظائفك إلى الوجهة التي تختارها، مثل مساحة عمل Logs Analytics. لمزيد من المعلومات، راجع مراقبة وظائف Azure باستخدام سجلات Azure Monitor.
لاكتشاف المخاطر وأتمتة الاستجابة على مستوى المؤسسات، قم بدفق سجلاتك وأحداثك إلى مساحة عمل Log Analytics. ومن ثَم يمكنك توصيل Azure Sentinel بمساحة العمل هذه. لمزيد من المعلومات، راجع ما هو Microsoft Sentinel.
لمزيد من توصيات الأمان الخاصة بإمكانية الملاحظة، اطلع على أساس أمان Azure لـ Azure Functions.
نقاط نهاية HTTP الآمنة
نقاط نهاية HTTP التي تكشفها علنا توفر متجه للهجوم ضد الجهات الخبيثة. عند تأمين نقاط نهاية HTTP، استخدم نهج أمان متعدد الطبقات. استخدم هذه التقنيات لتقليل نقاط النهاية المكشوفة للجمهور من نقاط HTTP، مرتبة من الأكثر أمانا وتقييدا:
- طلب HTTPS
- طلب مفاتيح الوصول
- تمكين مصادقة/تخويل خدمة التطبيقات
- استخدام إدارة واجهة برمجة تطبيقات Azure (APIM) لمصادقة الطلبات
- نشر تطبيق الوظائف الخاص بك إلى شبكة ظاهرية
- نشر تطبيق الوظائف الخاص بك في عزلة
طلب HTTPS
بشكل افتراضي، يمكن للعملاء الاتصال بنقاط نهاية الوظائف باستخدام HTTP أو HTTPS. إعادة توجيه HTTP إلى HTTPS لأن HTTPS يستخدم بروتوكول TLS لتوفير اتصال آمن، يكون مشفرا وموصنا في نفس الوقت. لتتعرف على كيفية القيام بذلك، اطلع على فرض HTTPS.
عندما تحتاج إلى HTTPS، اطلب أيضا أحدث إصدار TLS. لتتعرف على كيفية القيام بذلك، اطلع على فرض إصدارات بروتوكول أمان طبقة النقل.
لمزيد من المعلومات، اطلع على الاتصالات الآمنة (بروتوكول أمان طبقة النقل).
مفاتيح الوصول إلى الدالة
تستخدم Functions مفاتيح لجعل الوصول إلى نقاط نهاية الوظائف أصعب. ما لم تقم بتعيين مستوى وصول HTTP على دالة مفعلة بواسطة HTTP على anonymous، يجب أن تتضمن الطلبات مفتاح وصول في الطلب. لمزيد من المعلومات، راجع العمل باستخدام مفاتيح الوصول في Azure Functions.
بينما يمكن لمفاتيح الوصول أن تساعد في منع الوصول غير المرغوب فيه، فإن الطريقة الوحيدة لتأمين نقاط نهاية الوظائف الحقيقية هي تنفيذ مصادقة إيجابية للعملاء الذين يصلون إلى وظائفك. ومن ثَم يمكنك اتخاذ قرارات التخويل بناءً على الهوية.
للحصول على أعلى مستوى من الأمان، قم بتأمين بنية التطبيق بالكامل داخل شبكة افتراضية باستخدام نقاط نهاية خاصة أو بتشغيلها بشكل منفصل.
تعطيل نقاط النهاية الإدارية
يمكن لتطبيقات الوظائف تقديم نقاط نهاية إدارية ضمن المسار /admin . يمكنك استخدام هذه النقاط النهائية لعمليات مثل الحصول على معلومات حالة المضيف وإجراء استدعاءات الاختبار. عند الكشف، يجب أن تتضمن الطلبات مقابل نقاط النهاية هذه المفتاح الرئيسي للتطبيق. يمكنك أيضا الوصول إلى العمليات الإدارية من خلال واجهة Azure Resource Manager Microsoft.Web/sites التي تقدم Azure RBAC. لتعطيل /admin نقاط النهاية، قم بتعيين functionsRuntimeAdminIsolationEnabled خاصية الموقع في تطبيقك على .true لمزيد من المعلومات، راجع مرجع خاصية functionsRuntimeAdminIsolationEnabled الخاص بها.
تفعيل مصادقة/تخويل خدمة التطبيق
يتيح لك النظام الأساسي ل App Service استخدام معرف Microsoft Entra والعديد من موفري الهوية غير التابعين ل Microsoft لمصادقة العملاء. استخدم هذه الاستراتيجية لتنفيذ قواعد تفويض مخصصة لوظائفك. يمكنك العمل بمعلومات المستخدم من كود الوظيفة الخاص بك. لمزيد من المعلومات، راجع المصادقة والتخويل في Azure App Serviceوالعمل مع هويات العميل.
استخدم إدارة Azure API (APIM) لمصادقة الطلبات
يوفر 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 دعما مدمجا للتعامل مع رؤوس CORS المطلوبة في طلبات HTTP. يتم تحديد قواعد مشاركة الموارد عبر المصادر على مستوى تطبيق الوظيفة.
من المغري استخدام حرف بدل يسمح لجميع المواقع بالوصول إلى نقطة النهاية الخاصة بك. هذا النهج يهزم الغرض من CORS، وهو المساعدة في منع هجمات البرمجة النصية عبر المواقع. بدلاً من ذلك، أضف إدخال مشاركة الموارد عبر المصادر منفصل لمجال كل تطبيق ويب يجب أن يصل إلى نقطة النهاية.
إدارة البيانات السرية
للاتصال بالخدمات والموارد المختلفة اللازمة لتشغيل الكود الخاص بك، تحتاج تطبيقات الوظائف إلى الوصول إلى الأسرار، مثل سلاسل الاتصال ومفاتيح الخدمة. يصف هذا القسم كيفية تخزين البيانات السرية التي تتطلبها وظائفك.
لا تقم بتخزين البيانات السرية في تعليمات وظيفتك البرمجية.
إعدادات التطبيق
افتراضيا، تخزن سلاسل الاتصال والأسرار التي يستخدمها تطبيق الوظائف والروابط كإعدادات تطبيق. يجعل هذا الأسلوب بيانات الاعتماد هذه متاحة لكل من التعليمات البرمجية للدالة والروابط المختلفة التي تستخدمها الدالة. استخدم اسم إعداد التطبيق (المفتاح) لاسترجاع القيمة الفعلية، وهي السر.
على سبيل المثال، كل تطبيق وظيفي يتطلب حساب تخزين مرتبط، يستخدمه وقت التشغيل. افتراضيا، تخزن الاتصال بهذا الحساب التخزيني في إعداد تطبيق يسمى AzureWebJobsStorage.
يقوم Azure بتشفير إعدادات التطبيق وسلاسل الاتصال. إعدادات التطبيق وسلاسل الاتصال يتم فك تشفيرها فقط قبل حقنها في ذاكرة التطبيق عند بدء التطبيق. يتم تغيير مفاتيح التشفير بانتظام. إذا كنت تفضل إدارة التخزين الآمن لأسرارك، اجعل إعدادات التطبيق تشير إلى أسرار Azure Key Vault.
عند تطوير الوظائف على جهازك المحلي، يمكنك أيضا تشفير الإعدادات بشكل افتراضي داخل local.settings.json الملف. لمزيد من المعلومات، راجع تشفير ملف الإعدادات المحلية.
مراجع Key Vault
في حين أن إعدادات التطبيق كافية لمعظم الوظائف، قد تحتاج إلى مشاركة نفس الأسرار عبر خدمات متعددة. في هذه الحالة، يؤدي التخزين المتكرر للبيانات السرية إلى المزيد من الثغرات الأمنية المحتملة. نهج أكثر أمانا هو استخدام خدمة تخزين سرية مركزية واستخدام مراجع إلى هذه الخدمة بدلا من الأسرار نفسها.
يعد Azure Key Vault عبارة عن خدمة توفر إدارة مركزية للبيانات السرية، مع تحكم كامل في نُهج الوصول ومحفوظات التدقيق. يمكنك استخدام مرجع Key Vault بدلاً من سلسلة الاتصال أو المفتاح في إعدادات التطبيق. لمزيد من المعلومات، راجع استخدام مراجع App Service لخدمة التطبيقات وApp Service.
الاتصالات القائمة على الهوية
استخدم الهويات بدلا من الأسرار للاتصال ببعض الموارد. يتميز هذا النهج بعدم الحاجة إلى إدارة سر، كما أنه يوفر تحكما في الوصول وتدقيقا أكثر دقة.
عند كتابة التعليمات البرمجية التي تنشئ الاتصال بخدمات Azure التي تدعم مصادقة Microsoft Entra، يمكنك استخدام هوية بدلا من سلسلة بيانات سرية أو سلسلة اتصال. يتم تناول تفاصيل كلتا طريقتي الاتصال في الوثائق الخاصة بكل خدمة.
يمكنك تكوين بعض امتدادات ربط وظائف Azure للوصول إلى الخدمات باستخدام الاتصالات القائمة على الهوية. لمزيد من المعلومات، راجع تكوين اتصال يستند إلى الهوية.
تحديد حصص الاستخدام
ضع في اعتبارك تعيين حصة استخدام للوظائف التي تعمل في خطة الاستهلاك. عندما تحدد حدا يوميا لثانية الجيجابايت على إجمالي تنفيذ الوظائف في تطبيق الوظائف الخاص بك، يتوقف التنفيذ عند الوصول إلى الحد. قد يساعد هذا النهج في الحماية من تنفيذ الشيفرة الخبيثة التي تنفذ وظائفك. لتتعرف على كيفية تقدير الاستهلاك لوظائفك، اطلع على تقدير تكاليف خطة الاستهلاك.
التحقق من صحة البيانات
لا توفر المشغلات والروابط المستخدمة من قبل وظائفك أي تحقق إضافي من صحة البيانات. يجب أن تتحقق التعليمات البرمجية من صحة أي بيانات تم تلقيها من مشغل أو ربط إدخال. إذا تم اختراق خدمة المصدر، لا تريد أن تتدفق المدخلات غير المؤكدة عبر وظائفك. على سبيل المثال، إذا كانت وظيفتك تخزن البيانات من قائمة انتظار 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 ل Storage.
هام
يتم استخدام حساب التخزين لتخزين بيانات التطبيق المهمة، بما في ذلك أحيانا التعليمات البرمجية للتطبيق نفسه. يجب تقييد الوصول من التطبيقات والمستخدمين الآخرين إلى حساب التخزين.
يجب عليك أيضا الرجوع إلى الإرشادات لأي أنواع موارد يعتمد عليها منطق التطبيق الخاص بك، سواء كمشغلات أو روابط ومن التعليمات البرمجية للدالة.
توزيع آمن
يسهل تكامل أدوات Azure Functions نشر التعليمات البرمجية لمشروع الدالة المحلية إلى Azure. من المهم فهم كيفية عمل النشر عند التفكير في الأمان لطبولوجيا Azure Functions.
بيانات اعتماد النشر
تتطلب عمليات نشر App Service مجموعة من بيانات اعتماد النشر. تستخدم هذه البيانات الاعتمادية لتأمين نشر تطبيقات الوظائف الخاصة بك. تدير منصة خدمة التطبيقات بيانات اعتماد النشر وتشفيرها أثناء السكون.
يوجد نوعان من بيانات اعتماد النشر:
توفر بيانات الاعتماد على مستوى المستخدم أو نطاق المستخدم مجموعة واحدة من بيانات اعتماد النشر لحساب Azure بأكمله للمستخدم. يمكن للمستخدم الذي تم منحه حق الوصول إلى التطبيق عبر التحكم في الوصول استنادا إلى الدور (RBAC) أو أذونات المسؤول المشترك استخدام بيانات الاعتماد الخاصة به على مستوى المستخدم طالما أن لديه هذه الأذونات.
يمكنك استخدام بيانات اعتماد نطاق المستخدم لنشر أي تطبيق إلى App Service عبر Git المحلي أو FTP/S في أي اشتراك يمتلك حساب Azure الإذن للوصول إليه. لا تشارك بيانات الاعتماد هذه مع أي من مستخدمي Azure الآخرين. يمكنك إعادة تعيين بيانات اعتماد نطاق المستخدم في أي وقت.
بيانات الاعتماد على مستوى التطبيق أو نطاق التطبيق هي مجموعة واحدة من بيانات الاعتماد لكل تطبيق يمكن استخدامها لنشر هذا التطبيق فقط. يتم إنشاء بيانات الاعتماد هذه تلقائيا لكل تطبيق عند الإنشاء ولا يمكن تكوينها يدويا، ولكن يمكن إعادة تعيين كلمة المرور في أي وقت.
يجب أن يكون لدى المستخدم أذونات على الأقل على مستوى المساهم على أحد التطبيقات، بما في ذلك دور المساهم في موقع الويب المضمن، لمنحه حق الوصول إلى بيانات الاعتماد على مستوى التطبيق عبر RBAC. لا يمكن لدور القارئ النشر ولا يمكنه الوصول إلى بيانات الاعتماد هذه.
في الوقت الحالي، لا يتم دعم Key Vault لنشر بيانات الاعتماد. لتتعرف على المزيد حول إدارة بيانات اعتماد النشر، اطلع على تكوين بيانات اعتماد النشر لـ Azure App Service.
تعطيل بروتوكول نقل الملفات
بشكل افتراضي، يتم تمكين نقطة نهاية بروتوكول نقل الملفات لكل تطبيق وظيفة. يتم الوصول إلى نقطة نهاية بروتوكول نقل الملفات باستخدام بيانات اعتماد النشر.
لا يُنصح باستخدام بروتوكول نقل الملفات لنشر تعليمات وظيفتك البرمجية. تعد عمليات نشر بروتوكول نقل الملفات عمليات يدوية، وتتطلب منك مزامنة المشغلات. لمزيد من المعلومات، راجع نشر FTP.
عندما لا تستخدم FTP، احتفظ بتعطيله. يمكنك تغيير هذا الإعداد في البوابة. إذا اخترت استخدام FTP، فرض FTPS.
scm تأمين نقطة النهاية
كل تطبيق وظيفي له نقطة نهاية خدمة مقابلة scm تستخدمها خدمة الأدوات المتقدمة (Kudu) للنشر وتوسعات مواقع خدمات التطبيقات الأخرى.
scm نقطة النهاية لتطبيق الوظائف هي دائما عنوان URL في النموذج https://<FUNCTION_APP_NAME>.scm.azurewebsites.net. عند استخدام عزل الشبكة لتأمين وظائفك، يجب عليك أيضاً حساب نقطة النهاية هذه.
باستخدام نقطة نهاية منفصلة scm ، يمكنك التحكم في عمليات النشر ووظائف الأدوات المتقدمة الأخرى لتطبيقات الوظائف المعزولة أو التي تعمل في شبكة افتراضية. تدعم نقطة scm النهاية كل من المصادقة الأساسية (باستخدام بيانات اعتماد النشر) وتسجيل الدخول الفردي باستخدام بيانات اعتماد بوابة Azure الخاصة بك. لمزيد من المعلومات، راجع الوصول إلى خدمة Kudu.
التحقق المستمر من صحة الأمان
لأنك بحاجة إلى مراعاة الأمان في كل خطوة من مراحل عملية التطوير، فمن المنطقي أيضا تنفيذ التحقق الأمني في بيئة نشر مستمرة. يسمى هذا الأسلوب أحيانا DevSecOps. باستخدام Azure DevOps لخط أنابيب النشر الخاص بك، يمكنك دمج التحقق من الصحة في عملية النشر. لمزيد من المعلومات، راجع تأمين خطوط أنابيب Azure.
أمن الشبكة
من خلال تقييد الوصول إلى الشبكة على تطبيق الوظائف الخاص بك، يمكنك التحكم في من يمكنه الوصول إلى نقاط نهاية الوظائف الخاصة بك. تستخدم الوظائف البنية الأساسية لخدمة التطبيقات لتمكين وظائفك من الوصول إلى الموارد دون استخدام عناوين قابلة للتوجيه عبر الإنترنت أو لتقييد الوصول إلى الإنترنت إلى نقطة نهاية دالة. لتتعرف على المزيد حول خيارات الشبكة هذه، اطلع على خيارات شبكة Azure Functions.
تعيين قيود الوصول
قيود الوصول تتيح لك تحديد قوائم قواعد السماح والرفض للتحكم في حركة المرور إلى تطبيقك. يتم تقييم القواعد بترتيب الأولوية. إذا لم تحدد أي قواعد، فإن تطبيقك يقبل حركة المرور من أي عنوان. لمزيد من المعلومات، راجع قيود الوصول إلى Azure App Service.
تأمين حساب التخزين
عند إنشاء تطبيق الوظائف، يجب إنشاء أو ربط حساب Azure Storage للأغراض العامة الذي يدعم تخزين Blob وQueue وTable. يمكنك استبدال حساب التخزين هذا بحساب مؤمن بواسطة شبكة ظاهرية مع تمكين الوصول بواسطة نقاط نهاية الخدمة أو نقاط النهاية الخاصة. لمزيد من المعلومات، راجع تقييد حساب التخزين الخاص بك بشبكة ظاهرية.
نشر تطبيق الوظائف الخاص بك إلى شبكة ظاهرية
تُعد Azure Private Endpoint واجهة شبكة تربطك بشكل خاص وآمن بخدمة مدعومة من Azure Private Link. تستخدم نقطة النهاية الخاصة عنوان بروتوكول إنترنت خاصًا من شبكتك الظاهرية، ما يجعل الخدمة في شبكتك الافتراضية تعمل بشكل فعال.
يمكنك استخدام نقطة النهاية الخاصة للوظائف المستضافة في خطط Flex Consumption و Elastic Premium و Dedicated (App Service ).
إذا كنت ترغب في مباشرة الاستدعاءات لنقاط النهاية الخاصة، فيجب التأكد من أن عمليات بحث DNS يتم حلها لنقطة النهاية الخاصة. يمكنك فرض هذا السلوك بإحدى الطرق التالية:
- التكامل مع مناطق Azure DNS الخاصة. عندما لا تتضمن الشبكة الظاهرية خادم DNS مخصص، يتم تنفيذ ذلك تلقائيًا.
- قم بإدارة نقطة النهاية الخاصة في خادم DNS المستخدمة من قبل تطبيقك. لإدارة نقطة نهاية خاصة، يجب أن تعرف عنوان نقطة النهاية وتستخدم سجل A للإشارة إلى نقطة النهاية التي تحاول الوصول إليها.
- قم بتكوين خادم DNS الخاص بك لإعادة التوجيه إلى مناطق خاصة لنظام أسماء المجالات في Azure.
لمعرفة المزيد، راجع استخدام نقاط النهاية الخاصة لتطبيقات الويب.
نشر تطبيق وظيفتك بمعزل عن غيره
توفر Azure App Service Environment بيئة استضافة مخصصة لتشغيل وظائفك. تتيح لك هذه البيئات تكوين بوابة أمامية واحدة يمكنك استخدامها لمصادقة جميع الطلبات الواردة. لمزيد من المعلومات، راجع دمج بيئة خدمة تطبيق ILB مع بوابة تطبيق Azure.
استخدام خدمة البوابة
باستخدام خدمات البوابة مثل Azure Application GatewayوAzure Front Door، يمكنك إعداد جدار حماية لتطبيقات الويب (WAF). قواعد WAF تراقب أو تحجب الهجمات المكتشفة، مما يوفر طبقة حماية إضافية لوظائفك. لإعداد WAF، يجب أن يعمل تطبيق الوظائف في ASE أو يستخدم نقاط النهاية الخاصة (معاينة). لمزيد من المعلومات، راجع استخدام نقاط النهاية الخاصة.