توصيات للتخفيف من تهديدات أهم 10 تهديدات لمشروع أمان تطبيق الويب المفتوح OWASP باستخدام APIM

  • مقالة

ينطبق على: جميع مستويات إدارة واجهة برمجة التطبيقات

تعمل مؤسسة مشروع أمان تطبيق الويب المفتوح (OWASP) على تحسين أمان البرامج من خلال مشاريع البرمجيات مفتوحة المصدر الخاصة بها التي يقودها المجتمع، ومئات الفصول في جميع أنحاء العالم، وعشرات الآلاف من الأعضاء، ومن خلال استضافة المؤتمرات المحلية والعالمية.

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

إشعار

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

تفويض مستوى الهدف المعطل

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

مزيد من المعلومات حول هذا التهديد: التفويض غير الساري لمستوى الهدف API1:2019

التوصيات

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

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

    • استخدم نهج مخصص لتنفيذ التفويض لمستوى الهدف، إذا لم يتم تنفيذه في الخلفية.

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

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

  • بالنسبة لسيناريوهات لغة الاستفسار GraphQL، قم بفرض التفويض على مستوى العنصر من خلال نهج طلب التحقق من صحة لغة الاستفسار GraphQL، باستخدام العنصر authorize.

مصادقة المستخدم المعطل

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

مزيد من المعلومات حول هذا التهديد: API2:2019تفويض المستخدم المعطل

التوصيات

استخدام APIM لمصادقة المستخدم وتخويله:

  • المصادقة - تدعم APIM أساليب المصادقة التالية:

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

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

    • نهج شهادة العميل - يعد استخدام شهادات العميل أكثر أماناً من بيانات الاعتماد الأساسية أو مفتاح الاشتراك، ولكنه لا يسمح بالمرونة التي توفرها بروتوكولات التفويض المستندة إلى الرمز المميز مثل التفويض المفتوح 2.0.

  • التخويل - تدعم APIM نهج validate JWT للتحقق من صحة الرمز المميز للوصول OAuth 2.0 JWT الوارد القائم على المعلومات التي تم الحصول عليها من نقطة نهاية بيانات التعريف لموفر هوية التفويض OAuth. تكوين النهج للتحقق من مطالبات الرمز المميز ذات الصلة والجمهور ووقت انتهاء الصلاحية. تعرف على المزيد حول حماية واجهة برمجة التطبيقات باستخدام تخويل OAuth 2.0 ومعرف Microsoft Entra.

توصيات أخرى:

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

  • يجب أن تستخدم واجهات برمجة التطبيقات TLS/SSL (أمان النقل) لحماية بيانات الاعتماد أو الرموز المميزة. يجب إرسال بيانات الاعتماد والرموز المميزة في رؤوس الطلبات وليس كمعايير استعلام.

  • في مدخل مطور APIM، قم بتكوين معرف Microsoft Entra أو Azure Active Directory B2C كموفر هوية لزيادة أمان الحساب. يستخدم مدخل المطور CAPTCHA للتخفيف من هجمات القوة الغاشمة.

التعرض المفرط للبيانات

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

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

مزيد من المعلومات حول هذا التهديد: API3:2019 التعرض المفرط للبيانات

التوصيات

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

    في APIM، استخدم:

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

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

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

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

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

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

  • بالنسبة لسيناريوهات لغة الاستفسار GraphQL، استخدم نهج طلب GraphQL للتحقق من صحة طلبات GraphQL، وتفويض الوصول إلى مسارات استعلام معينة، والحد من حجم الاستجابة.

نقص الموارد والحد من المعدل

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

مزيد من المعلومات حول هذا التهديد: API4:2019 نقص الموارد والحد من المعدل

التوصيات

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

  • عرّف تعريفات هدف الطلب الصارمة وخصائصها في تعريف واجهة برمجة التطبيقات المفتوح. على سبيل المثال، حدد الحد الأقصى لقيمة الأعداد الصحيحة للصفحات وأقصى طول والتعبير العادي (regex) للسلاسل. افرض هذه المخططات مع التحقق من صحة المحتوى والتحقق من صحة نهج المعلمات في APIM.

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

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

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

  • تطبيق نهج CORS للتحكم في مواقع الويب المسموح لها بتحميل الموارد التي يتم تقديمها من خلال واجهة برمجة التطبيقات. لتجنب التكوينات المتساهلة بشكل مفرط، لا تستخدم قيم محرف البدل (*) في نهج CORS.

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

  • بينما يمكن لـ APIM حماية خدمات الواجهة الخلفية من هجمات DDoS، فقد تكون عرضة لتلك الهجمات نفسها. نشر خدمة حماية الروبوت أمام APIM (على سبيل المثال، بوابة تطبيق Azure أو Azure Front Door أو حماية Azure DDoS) للحماية بشكل أفضل من هجمات DDoS. عند استخدام خدمة الحماية WAF مع بوابة تطبيق Azure أو خاصية Azure Front Door، ضع في اعتبارك استخدام Microsoft_BotManagerRuleSet_1.0.

تفويض مستوى الخاصية المعطل

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

لمزيد من المعلومات حول هذا التهديد: تفويض مستوى الخاصية المعطل API5:2019

التوصيات

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

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

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

  • لا تحدد عمليات واجهة برمجة تطبيقات محرف البدل (أي واجهات برمجة التطبيقات "catch-all" معها * كمسار). تأكد من أن APIM تخدم فقط طلبات نقاط النهاية المحددة بشكل صريح، ويتم رفض الطلبات إلى نقاط النهاية غير المعرفة.

  • لا تنشر واجهات برمجة التطبيقات مع منتجات مفتوحة لا تتطلب اشتراكاً.

التعيين الجماعي

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

مزيد من المعلومات حول هذا التهديد: API6:2019 التعيين الجماعي

التوصيات

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

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

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

التكوين الخاطئ للأمان

قد يحاول المهاجمون استغلال نقاط الضعف في التكوين الخاطئ للأمان مثل:

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

مزيد من المعلومات حول هذا التهديد: التكوين الخاطئ للأمان API7:2019

التوصيات

  • تكوين بروتوكول أمان طبقة النقل للبوابة بشكل صحيح. لا تستخدم البروتوكولات الضعيفة (على سبيل المثال، بروتوكول أمان طبقة النقل 1.0، 1.1) أو الشفرات.

  • تكوين واجهات برمجة التطبيقات لقبول نسبة استخدام الشبكة المشفرة فقط، على سبيل المثال من خلال بروتوكولات HTTPS أو WSS.

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

  • استخدام نُهج APIM:

    • دائماً ما ترث النُهج الأصل من خلال العلامة <base>.

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

    • قم بتكوين نهج CORS ولا تستخدم محرف البدل * لأي خيار تكوين. بدلاً من ذلك، قم بإدراج القيم المسموح بها بشكل صريح.

    • قم بتعيين نهج التحقق من الصحة إلى prevent بيئات الإنتاج للتحقق من صحة مخططات صيغتي JSON وXML والعناوين، ومعايير الاستعلام، ورموز الحالة، وفرض الحد الأقصى لحجم الطلب أو الاستجابة.

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

    • إذا تم استخدام شهادات العميل بين المتصل وإدارة واجهة برمجة التطبيقات، فاستخدم النهج التحقق من شهادة العميل. تأكد من أن السمات validate-revocation، وvalidate-trust، وvalidate-not-before، وvalidate-not-after تم تعيينها جميعاً إلى true.

      • يمكن أيضاً تطبيق شهادات العميل (بروتوكول أمان طبقة النقل المتبادل) بين APIM والواجهة الخلفية. يجب أن تكون الواجهة الخلفية:

        • تمتلك تكوين بيانات اعتماد التخويل

        • تتحقق من صحة سلسلة الشهادات حيثما ينطبق ذلك

        • تتحقق من صحة اسم الشهادة عند الاقتضاء

  • بالنسبة لسيناريوهات لغة الاستفسار GraphQL، استخدم نهج طلب لغة الاستفسار GraphQL للتحقق من الصحة. تأكد من تعيين العنصر authorization والسمات max-size وmax-depth.

  • لا تخزن الأسرار في ملفات النهج أو في التحكم بالمصادر. استخدم دائماً القيم المسماة في APIM أو أحضر الأسرار في وقت التشغيل باستخدام تعبيرات النهج المخصصة.

  • نشر واجهات برمجة التطبيقات من خلال المنتجات، والتي تتطلب اشتراكات. لا تستخدم المنتجات المفتوحة التي لا تتطلب اشتراكاً.

  • استخدم تكامل خاصية Key Vault لإدارة جميع الشهادات - وهذا يؤدي إلى مركزية إدارة الشهادات ويمكن أن يساعد في تسهيل مهام إدارة العمليات مثل تجديد الشهادة أو إبطالها.

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

  • تمثيل خدمات الواجهة الخلفية كـ كيانات خلفية. تكوين بيانات اعتماد التخويل، والتحقق من صحة سلسلة الشهادات، والتحقق من صحة اسم الشهادة عند الاقتضاء.

  • عند استخدام مدخل المطور:

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

    • استخدم معرف Microsoft Entra أو Azure Active Directory B2C لتسجيل المستخدم وتسجيل الدخول. قم بتعطيل مصادقة اسم المستخدم وكلمة المرور الافتراضية، وهي أقل أماناً.

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

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

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

  • لا تستخدم أي ميزات مهملة.

الحقن

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

  • حقن التبعية للأمر، حيث يحاول ممثل سيئ تغيير طلب واجهة برمجة التطبيقات لتنفيذ الأوامر على نظام التشغيل الذي يستضيف واجهة برمجة التطبيقات

  • حقن أدوات إدارة قواعد البيانات SQL، حيث يحاول ممثل سيئ تغيير طلب واجهة برمجة التطبيقات لتنفيذ الأوامر والاستعلامات مقابل قاعدة البيانات التي تعتمد عليها واجهة برمجة التطبيقات

مزيد من المعلومات حول هذا التهديد: حقن API8:2019

التوصيات

  • تغطي نهج جدار حماية تطبيق الويب الحديث (WAF) العديد من نقاط الضعف الشائعة في الحقن. بينما لا تحتوي APIM على مكون جدار الحماية WAF مضمن، يوصى بشدة بنشر جدار حماية WAF المصدر (أمام) مثيل إدارة واجهة برمجة التطبيقات. على سبيل المثال، استخدم بوابة تطبيق Azure أو Azure Front Door.

    هام

    تأكد من أن الممثل السيئ لا يمكنه تجاوز البوابة التي تستضيف جدار الحماية WAF والاتصال مباشرة ببوابة APIM أو واجهة برمجة التطبيقات الخلفية نفسها. تتضمن عوامل التخفيف المحتملة: قوائم التحكم في الوصول للشبكة، واستخدام نهج APIM لتقييد نسبة استخدام الشبكة الواردة بواسطة عنوان IP للعميل، وإزالة الوصول العام حيثما لم يكن مطلوباً، ومصادقة شهادة العميل (المعروفة أيضاً باسم TLS المتبادلة أو mTLS).

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

    يجب أن يكون للمخطط المزود بتعريف واجهة برمجة التطبيقات قيد نمط تعبير نمطي regex مطبق على الحقول المعرضة للخطر. يجب اختبار كل تعبير نمطي regex للتأكد من أنه يقيد الحقل بشكل كافٍ للتخفيف من محاولات الحقن الشائعة.

إدارة الأصول غير السليمة

تتضمن الثغرات الأمنية المتعلقة بإدارة الأصول غير السليمة ما يلي:

  • عدم وجود وثائق واجهة برمجة التطبيقات المناسبة أو معلومات الملكية

  • أعداد مفرطة من إصدارات واجهة برمجة التطبيقات القديمة، والتي قد تفقد إصلاحات الأمان

مزيد من المعلومات حول هذا التهديد: API9:2019 إدارة الأصول غير السليمة

التوصيات

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

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

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

  • استخدم المراجعات والإصدارات في APIM للتحكم في نقاط نهاية واجهة برمجة التطبيقات والتحكم فيها. لديك إستراتيجية إصدار خلفية قوية والالتزام بحد أقصى لعدد إصدارات واجهة برمجة التطبيقات المدعومة (على سبيل المثال، إصداران أو 3 إصدارات سابقة). التخطيط لإهمال إصدارات واجهة برمجة التطبيقات القديمة، وغالباً ما تكون أقل أماناً، وإزالتها بسرعة.

  • استخدم مثيل APIM لكل بيئة (مثل التطوير، والاختبار، والإنتاج). تأكد من أن كل مثيل APIM يتصل بتبعياته في نفس البيئة. على سبيل المثال، في بيئة الاختبار، يجب أن يتصل مورد APIM الاختبار بمورد اختبار Azure Key Vault وإصدارات الاختبار لخدمات الواجهة الخلفية. استخدم ممارسات أتمتة عملية تطوير البرمجيات DevOps والبنية الأساسية كتعلم برمجي للمساعدة في الحفاظ على الاتساق والدقة بين البيئات وتقليل الأخطاء البشرية.

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

  • قم بنشر واجهات برمجة التطبيقات للاستهلاك من خلال مدخل المطور المضمن. تأكد من أن وثائق واجهة برمجة التطبيقات محدثة.

  • اكتشف واجهات برمجة التطبيقات غير الموثقة أو غير المدارة وكشفها من خلال APIM للحصول على تحكم أفضل.

التسجيل والمراقبة غير الكافيين

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

مزيد من المعلومات حول هذا التهديد: API10:2019 تسجيل ومراقبة غير كافيين

التوصيات

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

تعلم المزيد عن: