تأمين 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.
طلب HTTPS
بشكل افتراضي، يمكن للعملاء الاتصال بنقاط النهاية للوظيفة باستخدام كل من بروتوكول HTTP أو بروتوكول HTTPS. يجب إعادة توجيه HTTP إلى HTTPs لأن HTTPS يستخدم بروتوكول طبقة مآخذ توصيل آمنة أو بروتوكول أمان طبقة النقل (SSL/TLS) لتوفير اتصال آمن، ويكون مشفراً ومصادقاً. لتتعرف على كيفية القيام بذلك، اطلع على فرض HTTPS.
عندما تطلب HTTPS، يجب عليك أيضاً طلب أحدث إصدار من بروتوكول أمان طبقة النقل. لتتعرف على كيفية القيام بذلك، اطلع على فرض إصدارات بروتوكول أمان طبقة النقل.
لمزيد من المعلومات، اطلع على الاتصالات الآمنة (بروتوكول أمان طبقة النقل).
مفاتيح الوصول إلى الدالة
تتيح لك الوظائف استخدام المفاتيح لزيادة صعوبة الوصول إلى نقاط نهاية وظيفة HTTP خلال التطوير. ما لم يتم تعيين مستوى وصول HTTP في وظيفة يتم تشغيلها بواسطة HTTP على anonymous، يجب أن تتضمن الطلبات مفتاح وصول API في الطلب.
بينما توفر المفاتيح آلية أمان افتراضية، قد تحتاج إلى النظر في خيارات أخرى لتأمين نقطة نهاية HTTP في الإنتاج. على سبيل المثال، ليس من الممارسات الجيدة توزيع البيانات السرية المشتركة في التطبيقات العامة. إذا تم استدعاء وظيفتك من عميل عام، فقد ترغب في التفكير في تنفيذ آلية أمان أخرى. لمعرفة المزيد، راجع تأمين نقطة نهاية HTTP في الإنتاج.
عندما تقوم بتجديد قيم مفاتيح الوظيفة، يجب عليك إعادة توزيع قيم المفاتيح المحدّثة يدوياً على جميع العملاء الذين يتصلون بوظيفتك.
نطاقات التخويل (مستوى الوظيفة)
يوجد نطاقي وصول لمفاتيح المستوى الوظيفي:
دالة: تنطبق هذه المفاتيح فقط على الوظائف المحددة التي يتم تعريفها بموجبها. عند استخدامها كمفتاح API، فإنها تسمح فقط بالوصول إلى هذه الوظيفة.
المضيف: يمكن استخدام المفاتيح ذات النطاق المضيف للوصول إلى جميع الوظائف داخل Function App. عند استخدامها كمفتاح API، فإنها تسمح بالوصول إلى أي وظيفة داخل Function App.
تتم تسمية كل مفتاح كمرجع، وهناك مفتاح افتراضي (يسمى "افتراضي") على مستوى الدالة والمضيف. مفاتيح الوظائف لها الأسبقية على مفاتيح المضيف. عندما يتم تعريف مفتاحين بنفس الاسم، يتم استخدام مفتاح الوظيفة دائماً.
المفتاح الرئيسي (على مستوى المسؤول)
يحتوي كل تطبيق وظيفي أيضاً على مفتاح مضيف على مستوى المسؤول يسمى _master. بالإضافة إلى توفير وصول على مستوى المضيف إلى جميع الوظائف في التطبيق، يوفر المفتاح الرئيسي أيضاً وصولاً إدارياً إلى وقت التشغيل REST APIs. لا يمكن إبطال هذا المفتاح. عند تعيين مستوى وصول لـ admin، يجب أن تستخدم الطلبات المفتاح الرئيسي؛ يؤدي أي مفتاح آخر إلى فشل الوصول.
تنبيه
نظرا للأذونات المرتفعة في تطبيق الوظائف الذي تم منحه بواسطة المفتاح الرئيسي، يجب عدم مشاركة هذا المفتاح مع جهات خارجية أو توزيعه في تطبيقات العميل الأصلية. توخ الحذر عند اختيار مستوى وصول المسؤول.
مفتاح النظام
قد تتطلب ملحقات معينة مفتاحاً مُداراً من قبل النظام للوصول إلى نقاط نهاية خطاف الويب. تم تصميم مفاتيح النظام لنقاط نهاية الوظائف الخاصة بالامتداد التي يتم استدعاؤها بواسطة المكونات الداخلية. على سبيل المثال، يتطلب مشغل شبكة الحدث أن يستخدم الاشتراك مفتاح نظام عند استدعاء نقطة نهاية المشغل. وتستخدم الوظائف الدائمة أيضاً مفاتيح النظام لاستدعاء واجهات برمجة التطبيقات لملحقات المهام الدائمة.
يتم تحديد نطاق مفاتيح النظام من خلال الملحق، ولكنه ينطبق بشكل عام على تطبيق الوظيفة بأكمله. لا يمكن إنشاء مفاتيح النظام إلا من خلال ملحقات محددة، ولا يمكنك تعيين قيمها بشكل صريح. مثل المفاتيح الأخرى، يمكنك إنشاء قيمة جديدة للمفتاح من المدخل أو باستخدام واجهات برمجة تطبيقات المفاتيح.
مقارنة المفاتيح
يعرض الجدول التالي مقارنة لاستخدامات أنواع مختلفة من مفاتيح الوصول:
| الإجراء | النطاق | المفاتيح الصالحة |
|---|---|---|
| تنفيذ وظيفة | وظيفة محددة | الدالة |
| تنفيذ وظيفة | أي دالة | وظيفة أو مضيف |
| استدعاء نقطة نهاية المسؤول | تطبيق الوظيفة | مضيف (رئيسي فقط) |
| استدعاء واجهات برمجة تطبيقات ملحقات المهام الدائمة | تطبيق الوظيفة1 | النظام2 |
| استدعاء خطاف الويب الخاص بالملحق (داخلي) | تطبيق الوظيفة1 | النظام2 |
1 النطاق الذي يحدده الملحق.
2 أسماء محددة تم تعيينها بواسطة الملحق.
لتتعرف على المزيد حول مفاتيح الوصول، اطلع على مقالة ربط مشغل HTTP.
مستودعات البيانات السرية
بشكل افتراضي، يتم تخزين المفاتيح في حاوية تخزين Blob بالحساب الذي يوفره الإعداد AzureWebJobsStorage. يمكنك استخدام إعداد AzureWebJobsSecretStorageType لتجاوز هذا السلوك وتخزين المفاتيح في موقع مختلف.
| الموقع | قيمة | الوصف |
|---|---|---|
| حساب التخزين الثاني | blob |
يخزن المفاتيح في تخزين Blob لحساب تخزين مختلف، استنادًا إلى عنوان URL الخاص بـ SAS في AzureWebJobsSecretStorageSas. |
| نظام الملفات | files |
يتم الاحتفاظ بالمفاتيح على نظام الملفات، وهو الافتراضي في Functions v1.x. |
| Azure Key Vault | keyvault |
يتم استخدام مخزن المفاتيح الذي تم تعيينه في AzureWebJobsSecretStorageKeyVaultUri لتخزين المفاتيح. |
| Kubernetes Secrets | kubernetes |
يتم استخدام مجموعة الموارد في AzureWebJobsKubernetesSecretName لتخزين المفاتيح. مدعوم فقط عند تشغيل وقت تشغيل الوظائف في Kubernetes. تُنشئ أدوات Azure Functions الأساسية القيم تلقائياً عند التوزيع إلى Kubernetes. |
عند استخدام Key Vault لتخزين المفاتيح، تعتمد إعدادات التطبيق التي تحتاجها على نوع الهوية المدارة. يدعم الإصدار 3.x من وقت تشغيل الوظائف الهويات المدارة المعينة من قبل النظام فقط.
| اسم الإعداد | المعين من نظام | المستخدم المعين | تسجيل التطبيق |
|---|---|---|---|
| AzureWebJobsSecretStorageKeyVaultUri | √ | √ | √ |
| AzureWebJobsSecretStorageKeyVaultClientId | س | √ | √ |
| AzureWebJobsSecretStorageKeyVaultClientSecret | X | X | √ |
| AzureWebJobsSecretStorageKeyVaultTenantId | X | X | √ |
المصادقة/التخويل
بينما يمكن أن توفر المفاتيح الوظيفية بعض التخفيف للوصول غير المرغوب فيه، فإن الطريقة الوحيدة لتأمين نقاط النهاية الوظيفية حقاً هي من خلال تطبيق مصادقة إيجابية للعملاء الذين يصلون إلى وظائفك. ومن ثَم يمكنك اتخاذ قرارات التخويل بناءً على الهوية.
تفعيل مصادقة/تخويل خدمة التطبيق
يتيح لك النظام الأساسي ل App Service استخدام معرف Microsoft Entra والعديد من موفري الهوية التابعين لجهة خارجية لمصادقة العملاء. يمكنك استخدام هذه الإستراتيجية لتنفيذ قواعد التخويل المخصصة لوظائفك، ويمكنك العمل مع معلومات المستخدم من التعليمة البرمجية لوظيفتك. لمعرفة المزيد، راجع المصادقة والتخويل في خدمات تطبيق Azure والعمل باستخدام هويات العميل.
استخدم إدارة Azure API (APIM) لمصادقة الطلبات
يوفر APIM مجموعة متنوعة من خيارات أمان واجهة برمجة التطبيقات (API) للطلبات الواردة. لمعرفة المزيد، راجع نُهج مصادقة إدارة واجهة برمجة التطبيقات. باستخدام APIM في مكانه، يمكنك تكوين تطبيق الوظائف الخاص بك لقبول الطلبات فقط من عنوان IP لمثيل APIM الخاص بك. لمعرفة المزيد، راجع قيود عنوان IP.
الأذونات
كما هو الحال مع أي تطبيق أو خدمة، فإن الهدف هو تشغيل تطبيق الوظيفة بأقل أذونات ممكنة.
أذونات إدارة المستخدم
تدعم الوظائف التحكم في الوصول استناداً إلى الدور في Azure (Azure RBAC). أدوار Azure التي تدعمها الوظائف هي المساهم والمالك والقارئ.
تعد الأذونات فعالة على مستوى تطبيق الوظيفة. مطلوب دور المساهم لأداء معظم المهام الوظيفية على مستوى التطبيق. تحتاج أيضا إلى دور المساهم مع إذن قارئ المراقبة لتتمكن من عرض بيانات السجل في Application Insights. يمكن لدور المالك فقط حذف تطبيق الوظيفة.
تنظيم الوظائف حسب الامتياز
تمنح سلاسل الاتصال وبيانات الاعتماد الأخرى المخزنة في إعدادات التطبيق جميع الوظائف في تطبيق الوظائف نفس مجموعة الأذونات في المورد ذي الصلة. يمكنك التفكير في تقليل عدد الوظائف التي لها حق الوصول إلى بيانات الاعتماد المحددة عن طريق نقل الوظائف التي لا تستخدم بيانات الاعتماد هذه إلى تطبيق وظائف منفصل. يمكنك دائماً استخدام تقنيات مثل تسلسل الوظائف لتمرير البيانات بين الوظائف في تطبيقات الوظائف المختلفة.
الهويات المُدارة
تسمح الهوية المدارة من معرف Microsoft Entra لتطبيقك بالوصول بسهولة إلى موارد Microsoft Entra المحمية الأخرى مثل Azure Key Vault. تتم إدارة الهوية بواسطة النظام الأساسي Azure ولا يتطلب منك توفير أي أسرار أو تدويرها. لمزيد من الاطلاع على الهويات المدارة في معرف Microsoft Entra، راجع الهويات المدارة لموارد Azure.
يمكن منح طلبك نوعين من الهويات:
- ترتبط الهوية التي يعيّنها النظام بالتطبيق الخاص بك ويتم حذفها إذا تم حذف التطبيق الخاص بك. يمكن أن يكون للتطبيق هوية واحدة معينة من قبل النظام.
- الهوية التي يعيّنها المستخدم هي مورد Azure مستقل يمكن تعيينه لتطبيقك. يمكن أن يكون للتطبيق هويات متعددة مخصصة للمستخدم.
يمكن استخدام الهويات المدارة بدلاً من البيانات السرية للاتصالات من بعض المشغلات والروابط. اطلع على الاتصالات المستندة إلى الهوية.
لمزيد من المعلومات، اطلع على كيفية استخدام الهويات المدارة لـ 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 Blob وAzure Queue. للحصول على معلومات حول كيفية تكوين هذه الملحقات لاستخدام هوية، اطلع على كيفية استخدام الاتصالات المستندة إلى الهوية في 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 (ASE) بيئة استضافة مخصصة لتشغيل وظائفك فيها. يتيح لك ASE تكوين بوابة أمامية واحدة يمكنك استخدامها لمصادقة جميع الطلبات الواردة. للمزيد من المعلومات، راجع تكوين جدار حماية تطبيق الويب (WAF) لبيئة خدمة التطبيقات.
استخدام خدمة البوابة
تتيح لك خدمات البوابة، مثل Azure Application Gateway وAzure Front Door إعداد Web Application Firewall (WAF). تُستخدم قواعد WAF لمراقبة الهجمات المكتشفة أو منعها، مما يوفر طبقة إضافية من الحماية لوظائفك. لإعداد WAF، يجب تشغيل تطبيق الوظيفة في ASE أو باستخدام نقاط النهاية الخاصة (معاينة). لتتعرف على المزيد، اطلع على استخدام نقاط النهاية الخاصة.