مشاركة عبر

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

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

إشعار

تم تحديث هذه المقالة لتعكس أحدث قائمة أمان OWASP API Top 10 ل 2023.

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

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

على الرغم من أن إدارة واجهة برمجة التطبيقات توفر عناصر تحكم شاملة لأمان واجهة برمجة التطبيقات، فإن خدمات Microsoft الأخرى توفر وظائف تكميلية للكشف عن تهديدات واجهة برمجة تطبيقات OWASP أو حمايتها:

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

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

مزيد من المعلومات حول هذا التهديد: API1:2023 التخويل على مستوى الكائن المقطوع

التوصيات

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

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

  • بالنسبة لسيناريوهات GraphQL، قم بفرض التخويل على مستوى الكائن من خلال نهج التحقق من صحة-graphql-request ، باستخدام authorize العنصر .

مصادقة مقطوعة

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

مزيد من المعلومات حول هذا التهديد: API2:2023 مصادقة مقطوعة

التوصيات

  • استخدم Microsoft Entra لتنفيذ مصادقة واجهة برمجة التطبيقات. يوفر Microsoft Entra نقاط نهاية تسجيل الدخول المحمية والمرنة والموزعة جغرافيا تلقائيا. استخدم نهج validate-azure-ad-token للتحقق من صحة رموز Microsoft Entra المميزة في طلبات واجهة برمجة التطبيقات الواردة.
  • حيثما تكون المصادقة مطلوبة، تدعم APIM التحقق من صحة رموز OAuth 2 المميزة والمصادقة الأساسية وشهادات العميل ومفاتيح واجهة برمجة التطبيقات.
    • تأكد من التكوين الصحيح لأساليب المصادقة. على سبيل المثال، قم بتعيين و عند التحقق من صحة رموز OAuth2 المميزة require-expiration-time.require-signed-tokenstrue
  • يمكن استخدام تحديد المعدل لتقليل فعالية هجمات القوة الغاشمة.
  • يمكن استخدام تصفية IP للعميل لتقليل مساحة سطح الهجوم. يمكن تطبيق مجموعات أمان الشبكة على الشبكات الظاهرية المتكاملة مع APIM.
  • إذا كان ذلك ممكنا، قم بالمصادقة على الخلفيات من APIM من خلال البروتوكولات الآمنة والهوية المدارة أو مدير بيانات الاعتماد للمصادقة على الخلفيات.
  • تأكد من تمرير الرموز المميزة أو المفاتيح في العناوين وليس عناوين URL للطلبات الواردة إلى API Management والطلبات الصادرة إلى الواجهات الخلفية.
  • استخدم Microsoft Entra لتأمين الوصول إلى مدخل مطور APIM.

تخويل مستوى خاصية الكائن المقطوع

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

مزيد من المعلومات حول هذا التهديد: API3:2023 التخويل على مستوى خاصية الكائن المقطوع

التوصيات

  • أفضل نهج للتخفيف من هذه الثغرة الأمنية هو التأكد من أن الواجهات الخارجية المحددة في واجهة برمجة التطبيقات الخلفية مصممة بعناية وبشكل مثالي، بشكل مستقل عن استمرار البيانات. يجب أن تحتوي فقط على الحقول المطلوبة من قِبل مستهلكي واجهة برمجة التطبيقات. تجب مراجعة واجهات برمجة التطبيقات بشكل متكرر، وإيقاف الحقول القديمة، ثم إزالتها.
  • في APIM، استخدم المراجعات للتحكم بأمان في التغييرات غير المقسمة، على سبيل المثال، إضافة حقل إلى واجهة، وإصدارات لتنفيذ التغييرات العاجلة. يجب عليك أيضا إصدار واجهات الواجهة الخلفية، والتي عادة ما يكون لها دورة حياة مختلفة عن واجهات برمجة التطبيقات التي تواجه المستهلك.
  • فصل واجهات API الخارجية عن تنفيذ البيانات الداخلية. تجنب ربط عقود واجهة برمجة التطبيقات مباشرة بعقود البيانات في خدمات الواجهة الخلفية.
  • إذا لم يكن من الممكن تغيير تصميم واجهة الخلفية وكانت البيانات الزائدة مصدر قلق، فاستخدم نهج تحويل APIM لإعادة كتابة حمولات الاستجابة وإخفاء البيانات أو تصفيتها. يمكن استخدام التحقق من صحة المحتوى في APIM مع مخطط XML أو JSON لحظر الاستجابات ذات الخصائص غير الموثقة أو القيم غير الصحيحة. على سبيل المثال، قم بإزالة خصائص صيغة JSON غير الضرورية من نص الاستجابة. يؤدي حظر الطلبات ذات الخصائص غير الموثقة إلى التخفيف من الهجمات، بينما يؤدي حظر الاستجابات ذات الخصائص غير الموثقة إلى صعوبة إجراء هندسة عكسية لنواقل الهجوم المحتملة. يدعم نهج التحقق من صحة المحتوى أيضا حظر الاستجابات التي تتجاوز حجما محددا.
  • استخدم نهج validate-status-code لحظر الاستجابات مع أخطاء غير محددة في مخطط API.
  • استخدم نهج التحقق من صحة الرؤوس لحظر الاستجابات بالعناوين التي لم يتم تعريفها في المخطط أو التي لا تتوافق مع تعريفها في المخطط. إزالة الرؤوس غير المرغوب فيها باستخدام نهج رأس المجموعة.
  • بالنسبة لسيناريوهات GraphQL، استخدم نهج التحقق من صحة-graphql-request للتحقق من صحة طلبات GraphQL، وتخويل الوصول إلى مسارات استعلام معينة، والحد من حجم الاستجابة.

استهلاك الموارد غير المقيد

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

مزيد من المعلومات حول هذا التهديد: API4:2023 استهلاك الموارد غير المقيد

التوصيات

  • استخدم نهج تحديد المعدل حسب المفتاح أو الحد من المعدل لتطبيق التقييد على نوافذ زمنية أقصر. تطبيق نهج أكثر صرامة للحد من المعدل على نقاط النهاية الحساسة، مثل إعادة تعيين كلمة المرور أو تسجيل الدخول أو عمليات التسجيل أو نقاط النهاية التي تستهلك موارد كبيرة.
  • استخدم نهج الحصة النسبية حسب المفتاح أو حد الحصة النسبية للتحكم في العدد المسموح به من استدعاءات واجهة برمجة التطبيقات أو النطاق الترددي للإطارات الزمنية الأطول.
  • تحسين الأداء باستخدام التخزين المؤقت المضمن، وبالتالي تقليل استهلاك وحدة المعالجة المركزية، والذاكرة، وموارد الشبكات لعمليات معينة.
  • تطبيق نهج التحقق من الصحة.
  • لواجهات برمجة التطبيقات الذكاء الاصطناعي التوليدية:
    • استخدم التخزين المؤقت الدلالي لتقليل الحمل على الخلفيات.
    • استخدم الحد من الرمز المميز للتحكم في الاستهلاك والتكاليف.
    • إرسال مقاييس استهلاك الرمز المميز لمراقبة استخدام الرمز المميز وتكوين التنبيهات.
  • تقليل الوقت الذي تستغرقه خدمة الواجهة الخلفية للاستجابة. كلما طالت مدة استجابة الخدمة الخلفية، طال شغل الاتصال في APIM، وبالتالي تقليل عدد الطلبات التي يمكن تقديمها في إطار زمني معين.
  • تطبيق نهج CORS للتحكم في مواقع الويب المسموح لها بتحميل الموارد التي يتم تقديمها من خلال واجهة برمجة التطبيقات. لتجنب التكوينات المتساهلة بشكل مفرط، لا تستخدم قيم أحرف البدل (*) في نهج CORS.
  • بينما يتمتع Azure بحماية على مستوى النظام الأساسي وحماية محسنة ضد هجمات رفض الخدمة الموزعة (DDoS)، يمكن تحسين حماية التطبيق (الطبقة 7) لواجهات برمجة التطبيقات عن طريق نشر خدمة حماية الروبوت أمام APIM - على سبيل المثال، Azure Application Gateway أو Azure Front Door أو Azure DDoS Protection. عند استخدام نهج جدار حماية تطبيق ويب (WAF) مع Azure Application Gateway أو Azure Front Door، فكر في استخدام Microsoft_BotManagerRuleSet_1.0.

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

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

مزيد من المعلومات حول هذا التهديد: تخويل مستوى الدالة المقطوعة API5:2023

التوصيات

  • بشكل افتراضي، قم بحماية جميع نقاط نهاية واجهة برمجة التطبيقات في APIM باستخدام مفاتيح الاشتراك أو نهج التخويل على مستوى واجهات برمجة التطبيقات. إذا كان ذلك ممكنا، فحدد نهج التخويل الأخرى لواجهات برمجة التطبيقات أو عمليات واجهة برمجة التطبيقات المحددة.
  • التحقق من صحة رموز OAuth المميزة باستخدام النهج.
    • استخدم نهج validate-azure-ad-token للتحقق من صحة الرموز المميزة ل Microsoft Entra. حدد جميع المطالبات المطلوبة، وإذا كان ذلك ممكنا، حدد التطبيقات المعتمدة.
    • للتحقق من صحة الرموز المميزة التي لم تصدرها Microsoft Entra، حدد نهج validate-jwt وفرض مطالبات الرمز المميز المطلوبة. إذا كان ذلك ممكنا، فاطلب وقت انتهاء الصلاحية.
    • إذا كان ذلك ممكنا، استخدم الرموز المميزة المشفرة أو سرد تطبيقات محددة للوصول.
    • مراقبة الطلبات المرفوضة ومراجعتها بسبب عدم وجود تخويل.
  • استخدم شبكة Azure الظاهرية أو الارتباط الخاص لإخفاء نقاط نهاية واجهة برمجة التطبيقات من الإنترنت. تعرف على المزيد حول استخدام خيارات شبكة ظاهرية باستخدام APIM.
  • لا تحدد عمليات واجهة برمجة تطبيقات محرف البدل (أي واجهات برمجة التطبيقات "catch-all" معها *  كمسار). تأكد من أن APIM تخدم فقط طلبات نقاط النهاية المحددة بشكل صريح، ويتم رفض الطلبات إلى نقاط النهاية غير المعرفة.
  • لا تنشر واجهات برمجة التطبيقات مع منتجات مفتوحة لا تتطلب اشتراكاً.
  • إذا كانت عناوين IP للعميل معروفة، فاستخدم نهج تصفية ip للسماح بنسبة استخدام الشبكة فقط من عناوين IP المعتمدة.
  • استخدم نهج validate-client-certificate لفرض أن الشهادة المقدمة من قبل العميل إلى مثيل APIM تطابق قواعد ومطالبات التحقق المحددة.

الوصول غير المقيد إلى تدفقات الأعمال الحساسة

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

مزيد من المعلومات حول هذا التهديد: API6:2023 وصول غير مقيد إلى تدفقات الأعمال الحساسة

التوصيات

  • تقليل الوصول أو حظره استنادا إلى بصمات العميل. على سبيل المثال، استخدم نهج الإرجاع والاستجابة مع نهج الاختيار لحظر نسبة استخدام الشبكة من المستعرضات بدون رأس استنادا إلى عنوان عامل المستخدم أو تناسق الرؤوس الأخرى.
  • استخدم نهج التحقق من صحة المعلمات لفرض أن عناوين الطلب تتطابق مع مواصفات واجهة برمجة التطبيقات.
  • استخدم نهج تصفية ip للسماح بالطلبات فقط من عناوين IP المعروفة أو رفض الوصول من عناوين IP معينة.
  • استخدم ميزات الشبكات الخاصة للحد من الاتصال الخارجي بواجهات برمجة التطبيقات الداخلية.
  • استخدم نهج الحد من المعدل حسب المفتاح للحد من الارتفاعات الحادة في استهلاك واجهة برمجة التطبيقات استنادا إلى هوية المستخدم أو عنوان IP أو قيمة أخرى.
  • إدارة واجهة برمجة التطبيقات الأمامية مع Azure Application Gateway أو خدمة Azure DDoS Protection للكشف عن حركة مرور الروبوت وحظرها.

تزييف الطلب من جانب الخادم

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

مزيد من المعلومات حول هذا التهديد: API7:2023 Server Side Request Forgery

التوصيات

  • إذا كان ذلك ممكنا، فلا تستخدم عناوين URL المتوفرة في حمولات العميل، على سبيل المثال، كمعلمات لعناوين URL الخلفية أو نهج إرسال الطلب أو نهج إعادة كتابة عنوان url .
  • إذا كانت API Management أو خدمات الواجهة الخلفية تستخدم عناوين URL المتوفرة في حمولة الطلب لمنطق العمل، فحدد قائمة محدودة من أسماء المضيفين أو المنافذ أو أنواع الوسائط أو السمات الأخرى مع النهج في APIM، مثل اختيار تعبيرات النهج والنهج.
  • حدد السمة timeout في نهج طلب إعادة التوجيه وطلب الإرسال.
  • التحقق من صحة بيانات الطلب والاستجابة وتعقيمها باستخدام نهج التحقق من الصحة. إذا لزم الأمر، استخدم نهج set-body لمعالجة الاستجابة وتجنب إرجاع البيانات الأولية.
  • استخدم الشبكات الخاصة لتقييد الاتصال. على سبيل المثال، إذا لم تكن واجهة برمجة التطبيقات بحاجة إلى أن تكون عامة، فقيد الاتصال من الإنترنت لتقليل سطح الهجوم.

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

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

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

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

التوصيات

  • تكوين بروتوكول أمان طبقة النقل للبوابة بشكل صحيح. لا تستخدم البروتوكولات الضعيفة (على سبيل المثال، بروتوكول أمان طبقة النقل 1.0، 1.1) أو الشفرات.
  • تكوين واجهات برمجة التطبيقات لقبول نسبة استخدام الشبكة المشفرة فقط، على سبيل المثال من خلال بروتوكولات HTTPS أو WSS. يمكنك تدقيق هذا الإعداد وفرضه باستخدام نهج Azure.
  • ضع في اعتبارك نشر APIM خلف نقطة نهاية خاصة أو مرفقة بشبكة ظاهرية تم نشرها في الوضع الداخلي. في الشبكات الداخلية، يمكن التحكم في الوصول من داخل الشبكة الخاصة (عبر جدار الحماية أو مجموعات أمان الشبكة) ومن الإنترنت (عبر وكيل عكسي).
  • استخدام نهج إدارة واجهة برمجة تطبيقات Azure:
    • دائماً ما ترث النُهج الأصل من خلال العلامة <base>.
    • عند استخدام OAuth 2.0، قم بتكوين واختبار نهج validate-jwt للتحقق من وجود الرمز المميز وصحته قبل أن يصل إلى الخلفية. تحقق تلقائياً من وقت انتهاء صلاحية الرمز المميز وتوقيع الرمز المميز والمصدر. افرض المطالبات، والجماهير، وانتهاء صلاحية الرمز المميز، وتوقيع الرمز المميز من خلال إعدادات النهج. إذا كنت تستخدم Microsoft Entra، يوفر نهج validate-azure-ad-token طريقة أكثر شمولا وأسهل للتحقق من صحة رموز الأمان المميزة.
    • قم بتكوين نهج CORS ولا تستخدم محرف البدل * لأي خيار تكوين. بدلاً من ذلك، قم بإدراج القيم المسموح بها بشكل صريح.
    • تعيين نهج التحقق من الصحة في بيئات الإنتاج للتحقق من صحة مخططات JSON وXML والعناوين ومعلمات الاستعلام ورموز الحالة، وفرض الحد الأقصى لحجم الطلب أو الاستجابة.
    • إذا كانت إدارة واجهة برمجة التطبيقات خارج حدود الشبكة، فلا يزال التحقق من صحة بروتوكول الإنترنت للعميل ممكناً باستخدام نهج تقييد عناوين IP للمتصل. تأكد من أنه يستخدم قائمة السماح، وليس قائمة حظر.
    • إذا تم استخدام شهادات العميل بين المتصل وإدارة واجهة برمجة التطبيقات، فاستخدم نهج التحقق من صحة شهادة العميل. تأكد من أن السمات validate-revocation، وvalidate-trust، وvalidate-not-before، وvalidate-not-after تم تعيينها جميعاً إلى true.
  • يمكن أيضاً تطبيق شهادات العميل (بروتوكول أمان طبقة النقل المتبادل) بين APIM والواجهة الخلفية. يجب أن تكون الواجهة الخلفية:
    • تمتلك تكوين بيانات اعتماد التخويل
    • تتحقق من صحة سلسلة الشهادات حيثما ينطبق ذلك
    • تتحقق من صحة اسم الشهادة عند الاقتضاء
    • بالنسبة لسيناريوهات GraphQL، استخدم نهج التحقق من صحة-graphQL-request . تأكد من تعيين العنصر authorization والسمات max-size وmax-depth.
  • لا تخزن الأسرار في ملفات النهج أو في التحكم بالمصادر. استخدم دائماً القيم المسماة في APIM أو أحضر الأسرار في وقت التشغيل باستخدام تعبيرات النهج المخصصة. يجب دمج القيم المسماة مع Azure Key Vault أو تشفيرها داخل APIM عن طريق وضع علامة عليها "سرية". لا تخزن الأسرار أبداً في قيم مسماة بالنص العادي.
  • نشر واجهات برمجة التطبيقات من خلال المنتجات، والتي تتطلب اشتراكات. لا تستخدم المنتجات المفتوحة التي لا تتطلب اشتراكاً.
  • تأكد من أن واجهات برمجة التطبيقات تتطلب مفاتيح اشتراك، حتى إذا تم تكوين جميع المنتجات لطلب مفاتيح الاشتراك. معرفة المزيد
  • طلب الموافقة على الاشتراك لجميع المنتجات ومراجعة جميع طلبات الاشتراك بعناية.
  • استخدم تكامل Key Vault لإدارة جميع الشهادات. هذا مركزية إدارة الشهادات ويمكن أن يساعد على تسهيل مهام إدارة العمليات مثل تجديد الشهادة أو إبطالها. استخدم الهوية المدارة للمصادقة على خزائن المفاتيح.
  • عند استخدام البوابة المستضافة ذاتياً، تأكد من وجود عملية لتحديث الصورة إلى أحدث إصدار بشكل دوري.
  • تمثيل خدمات الواجهة الخلفية كـ كيانات خلفية. تكوين بيانات اعتماد التخويل، والتحقق من صحة سلسلة الشهادات، والتحقق من صحة اسم الشهادة عند الاقتضاء.
  • حيثما أمكن، استخدم إدارة بيانات الاعتماد أو الهوية المدارة للمصادقة مقابل خدمات الواجهة الخلفية.
  • عند استخدام مدخل المطور:
    • إذا اخترت استضافة مدخل المطور ذاتياً، فتأكد من وجود عملية لتحديث المدخل المستضاف ذاتياً بشكل دوري إلى أحدث إصدار. التحديثات للإصدار المدار الافتراضي تلقائياً.
    • استخدم معرف Microsoft Entra أو معرف Microsoft Entra الخارجي لتسجيل دخول المستخدم وتسجيل الدخول. قم بتعطيل مصادقة اسم المستخدم وكلمة المرور الافتراضية، وهي أقل أماناً.
    • تعيين مجموعات المستخدمين إلى المنتجات، للتحكم في رؤية واجهات برمجة التطبيقات في المدخل.
  • استخدم نهج Azure لفرض تكوين مستوى موارد APIM وأذونات التحكم في الوصول المستندة على الأدوار (RBAC) للتحكم في الوصول إلى الموارد. منح الحد الأدنى من الامتيازات المطلوبة لكل مستخدم.
  • استخدم عملية DevOps ونهج البنية الأساسية كتعلم برمجي خارج بيئة التطوير لضمان تناسق محتوى إدارة واجهة برمجة التطبيقات وتغييرات التكوين وتقليل الأخطاء البشرية.
  • لا تستخدم أي ميزات مهملة.

إدارة المخزون غير السليمة

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

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

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

التوصيات

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

الاستهلاك غير الآمن لواجهات برمجة التطبيقات

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

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

التوصيات

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

المحتوى ذو الصلة

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