أهم 10 تهديدات لواجهة برمجة التطبيقات في OWASP

أنت تطّلع على مستندات Apigee Edge.
انتقِل إلى مستندات Apigee X. info

يوضّح هذا المستند الأساليب المختلفة التي يمكنك استخدامها في Apigee لمعالجة نقاط ضعف الأمان التي حدّدها OWASP. للاطّلاع على طرق إضافية تم توثيقها في Apigee، يُرجى الاطّلاع على خيارات التخفيف من المخاطر في قائمة OWASP Top 10 لعام 2021 على Google Cloud.

مقدمة

OWASP هو منتدى مفتوح مخصّص لمساعدة المؤسسات في تطوير التطبيقات وواجهات برمجة التطبيقات الموثوق بها وشرائها وصيانتها. من خلال مشروع أمان واجهات برمجة التطبيقات في OWASP، ينشر OWASP أهم المخاطر الأمنية التي تواجه تطبيقات الويب وواجهات برمجة التطبيقات REST، ويقدّم اقتراحات للتعامل مع هذه المخاطر.

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

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

يجب اعتبار "تطبيقات المستهلك" غير موثوق بها أو "عامة"، لأنّك لا تتحكم في منصّة التشغيل التي يعمل عليها التطبيق. افترض أنّه يمكن اختراق أي تطبيق متاح للجميع وسيحدث ذلك، وبالتالي لا يمكن الوثوق به لفرض التحكّم في الوصول (API1 أو API5) أو فلترة بيانات الاستجابة (API6) أو تخزين أسرار العميل بأمان (API2) مثل مفاتيح واجهة برمجة التطبيقات أو الرموز المميّزة للوصول. في ما يلي بعض الاقتراحات التي تم استنتاجها من خلال فحص أهم 10 نقاط في OWASP لعام 2019:

  • حدِّد نوع تطبيقات العملاء التي ستستخدم واجهات برمجة التطبيقات (SPA أو التطبيقات المتوافقة مع الأجهزة الجوّالة أو التطبيقات المستندة إلى المتصفّح)، وصِمّم أنماط المصادقة والتفويض والأمان المناسبة.
  • استخدِم دائمًا مسارات OAuth أو OpenID Connect الخاصة بـ "العميل العام" (ننصح بشدة باستخدام PKCE).
  • فكِّر في منطق النشاط التجاري لتطبيقك وحدِّد مواصفات OpenAPI أولاً، ثمّ صِمّ أدوات وكيل واجهة برمجة التطبيقات لفلترة جميع بيانات الاستجابة من الخلفية في Apigee. لا تعتمد أبدًا على رمز التطبيقات المُنزَّلة لإجراء ذلك.
  • فلترة جميع طلبات البيانات التي تحتوي على معلومات تحديد الهوية الشخصية الخاصة بالمستخدم للسماح فقط بالبيانات من الخلفية التي تخصّ المستخدم الذي يطلب البيانات

API1:2019 إذن على مستوى العنصر لا يعمل

وصف التهديد

إنّ عدم التحقّق بشكل كافٍ من التفويض لطلب الوصول إلى عنصر يسمح للمهاجم بتنفيذ إجراء غير مصرّح به عن طريق إعادة استخدام رمز مميّز للوصول. يحدث هذا التهديد بسبب إعداد غير سليم لعمليات التحقّق من الأذونات. توفّر Apigee سياسات VerifyApiKey وOAuth و"رمز JSON المميّز للويب" (JWT)، والتي تساعد في الحماية من هذه الثغرة الأمنية، ولكن من المهم ضبط هذه السياسات بشكل صحيح لمنع هذا التهديد.

لمنع هذا التهديد، من المهم أن تتعاون فِرق تطوير التطبيقات والأمان بشكل وثيق. إنّ التفويض هو موضوع معقّد بطبيعته، ويتطلّب التفويض الدقيق والفعّال فهمًا عميقًا لمنطق النشاط التجاري للتطبيق.

هناك جانبان رئيسيان يجب مراعاتهما من منظور تنفيذ Apigee:

  • سلامة رمز الوصول
  • فرض التحكّم في الوصول

سلامة رمز الدخول

من المهم التأكّد من عدم التلاعب بالرمز المميّز الذي يوفّره العميل المُقدّم للطلب، وذلك باستخدام عملية OAuth أو OpenID Connect الصحيحة مع آلية التوقيع أو التحقّق من بيانات الاعتماد المناسبة. تتوافق Apigee مع جميع مسارات OAuth الشائعة الاستخدام.

تشمل سياسات التحقّق من رمز مميّز للوصول في Apigee ما يلي:

تنفيذ عناصر التحكّم في الوصول

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

توفّر Apigee آليتين رئيسيتين للتحقّق من سياسات التفويض وفرضها:

  • الطلبات الداخلية: استخدام المخططات المشروطة لتقييم طلبات الوصول استنادًا إلى المطالبات المستخرَجة كمتغيّرات للمخطط من رمز مميّز لمنح الأذونات
  • مفوَّض: باستخدام خدمة callout لحلّ إدارة الوصول التابع لجهة خارجية

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

استخدِم متغيّرات المسار المتاحة لسياسات OAuth أو JWT لتقييم طلبات الوصول باستخدام عبارات المسار الشَرطية.

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

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

API2:2019 Broken user authentication

وصف التهديد

تسمح سياسات مصادقة المستخدمين التي تم تنفيذها بشكلٍ سيئ للمهاجمين بانتحال هوية مستخدمين شرعيين من خلال الاستفادة من عيوب التنفيذ في عمليات المصادقة. في ما يلي بعض مبادئ مصادقة التي يجب أخذها في الاعتبار عند تنفيذ طرق المصادقة:

  • مصادقة وكيل المستخدم (التطبيق) والمستخدم المُقدّم للطلب دائمًا
  • استخدِم أنماط المصادقة والتفويض المفوَّضة وتجنَّب تمرير كلمات المرور مباشرةً ضمن طلب واجهة برمجة التطبيقات.
  • التحقّق دائمًا من صحة توقيع بيانات اعتماد الوصول، والتأكّد من أنّ جميع بيانات اعتماد الوصول المستخدَمة لها وقت انتهاء صلاحية محدّد
  • منع هجمات القوة الغاشمة من خلال ضبط الحصص واستخدام Apigee Sense لرصد هجمات القوة الغاشمة التي ينفذها برامج التتبُّع والاستجابة لها

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

هناك بعض العناصر الرئيسية التي يجب أخذها في الاعتبار هنا، وسيتم تناول كليهما في الأقسام التالية:

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

تصميم الأمان

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

توفّر ملفات RFC الخاصة بكل من OpenID Connect وOAuth عددًا كبيرًا من عمليات المصادقة وتفويض الأذونات، بالإضافة إلى الجهات المعنيّة بهذه العمليات. هذا موضوع معقّد، وليس من المستغرب أنّ المصادقة غير الصالحة هي أحد أهم تهديدات واجهة برمجة التطبيقات في OWASP. لا يتناول هذا المستند تقديم دليل شامل حول التنفيذ الصحيح لمعايير هوية العميل، ومع ذلك، تتوفّر لدى Apigee العديد من المراجع الإضافية لفهم مسارات OAuth بشكل أفضل، مثل هذا الكتاب الإلكتروني والبثّ على الويب ومثال على تنفيذ عملية OAuth.

سياسات المصادقة

في ما يلي سياسات Apigee التي تساعد في معالجة المخاوف المتعلّقة بالهوية والمصادقة:

إدارة الزيارات

تساعد ميزات إدارة الزيارات التالية في Apigee في الحماية من هجمات القوة الغاشمة:

  • سياسة إيقاف الزيادات المفاجئة لضبط حدّ أقصى لمعدّل إجمالي متوسّط متغيّر على خادم وكيل لواجهة برمجة التطبيقات
  • سياسات الحصص، لضبط حدود معدّلات دقيقة للوكلاء لـ واجهة برمجة التطبيقات استنادًا إلى الحصص التي تحدّدها مفاتيح تطبيقات المطوّرين أو حصص منتجات واجهة برمجة التطبيقات
  • سياسات التخزين المؤقت، من أجل تخزين الرموز المميّزة المخزّنة للوصول استنادًا إلى أوقات انتهاء الصلاحية المحدّدة لها، بالإضافة إلى إمكانية invalidate بيانات الاعتماد المخزّنة (على سبيل المثال، في حال اختراق رمز مميّز صالح للوصول)

ميزة الإدارة

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

توفّر Apigee عددًا من الميزات والأدوات لضمان سلامة التنفيذ و منع أخطاء الضبط الخاطئ.

التحكم في الوصول المستنِد إلى الدور (RBAC)

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

توفّر لك Apigee الميزات اللازمة لإدارة الوصول المستنِد إلى الأدوار من خلال توفير الإمكانات اللازمة لتعيين المستخدمين إلى أدوار pre-defined أو إنشاء أدوار مخصّصة لتلائم فِرق واجهة برمجة التطبيقات. إنّ تحديد الأدوار وتعيينها بشكل صحيح وإدارة ذلك أمران مهمان لمساعدتك في توسيع نطاق برنامج واجهة برمجة التطبيقات بأمان. يمكنك أيضًا استخدام الاتحاد للدمج مع دليل المؤسسة الحالي، والحدّ من الحاجة إلى إدارة مجموعة ملفّات اعتماد مشرف ثانية في Apigee.

مسارات الإحالات الناجحة المشتركة

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

الشكل: مسارات المستخدمين المشترَكة هي حِزم قابلة لإعادة الاستخدام من السياسات والمنطق الشَرطي التي تسمح لك بالحفاظ على نمط مركب.

إعداد تقارير الأمان

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

تتضمّن ميزة Advanced API Ops الجديدة من Apigee إعداد تقارير أمان متقدّمة، ما يتيح لفِرق العمليات والأمان عرض التقارير بسهولة عن جميع أدوات وكيل برمجة التطبيقات ، كما تركّز على الالتزام بسياسات الأمان، مثل استخدام عمليات الربط المشتركة. إنّ إعداد التقارير، وتسجيل البيانات، وإصدار التنبيهات هي عناصر رئيسية لأمان واجهة برمجة التطبيقات، وسيتمّ مناقشتها بالتفصيل ضمن API10: عدم كفاية التسجيل، ولكن من منظور منع المخاطر المتعلّقة بتعطُّل المصادقة، فإنّ هذه العناصر مفيدة للغاية في ضمان الالتزام بمعايير المصادقة المحدّدة التي يتم تنفيذها كعمليات مشترَكة.

الأمان التشغيلي

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

Apigee Sense

تحمي خدمة Apigee Sense واجهات برمجة التطبيقات من الزيارات الناتجة عن طلبات غير مرغوب فيها، بما في ذلك الهجمات من العملاء الضارّين. يحلِّل Apigee Sense عدد زيارات طلبات البيانات من واجهة برمجة التطبيقات، ويحدِّد الأنماط التي قد تمثّل طلبات غير مرغوب فيها. باستخدام هذا التحليل، يمكنك تحديد العملاء الذين يقدّمون طلبات غير مرغوب فيها، ثم اتّخاذ إجراء للسماح بهذه الطلبات أو حظرها أو الإبلاغ عنها. ستتضمّن الميزات المستقبلية لميزة Sense إمكانية تفعيل ميزة التحقّق من ReCAPTCHA تلقائيًا في الزيارات المريبة.

باستخدام Apigee Sense، يمكنك حماية واجهات برمجة التطبيقات من أنماط الطلبات التي تشمل ما يلي:

  • السلوك المبرمَج الذي يمتزج مع السلوك البشري
  • محاولات متكرّرة من عنوان IP نفسه
  • معدّلات الأخطاء غير المعتادة
  • طلبات العملاء المريبة
  • الزحف إلى البيانات
  • هجمات جمع المفاتيح وهجمات القوة الغاشمة للمصادقة
  • فترات النشاط
  • الأنماط الجغرافية

Advanced API Ops

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

تعمل ميزة رصد القيم الشاذة من خلال تطبيق نماذج الذكاء الاصطناعي (AI) وتعلُّم الآلة (ML) على بيانات واجهة برمجة التطبيقات السابقة. يمكن أن يؤدي رصد الحالات الشاذة بعد ذلك إلى إرسال تنبيهات في الوقت الفعلي لسيناريوهات لم تكن تتوقعها لتحسين إنتاجيتك وخفض متوسط وقت حلّ مشاكل واجهة برمجة التطبيقات (MTTR).

تستند عمليات مراقبة واجهة برمجة التطبيقات المتقدّمة إلى آلية التنبيه الحالية لمراقبة واجهة برمجة التطبيقات لإضافة الأنواع التالية من التنبيهات المتقدّمة:

  • إجمالي تنبيهات حركة المرور: يُرسِل تنبيهًا عند تغيُّر عدد الزيارات بنسبة مئوية محدّدة على مدار نطاق زمني. على سبيل المثال، يمكنك إرسال تنبيه عند زيادة عدد الزيارات بنسبة ‎5% أو أكثر لمدة ساعة واحدة، أو انخفاضه بنسبة ‎10% أو أكثر لمدة أسبوع واحد.
  • تنبيهات القيم الشاذة يرصد Edge مشاكل الأداء والزيارات بدلاً من أن تحتاج إلى تحديدها مسبقًا بنفسك. يمكنك بعد ذلك إرسال تنبيه بشأن هذه القيم الشاذة.
  • تنبيهات انتهاء صلاحية بروتوكول أمان طبقة النقل (TLS) عرض إشعار عند اقتراب انتهاء صلاحية شهادة بروتوكول طبقة المقابس الآمنة (TLS)

API3:2019 تعرّض البيانات للخطر بشكل مفرط

وصف التهديد

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

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

من مبادئ التصميم الأخرى في Apigee هي قابلية إعادة الاستخدام. بغض النظر عن المخاوف المتعلّقة بالأمان، يؤدي الاعتماد على تطبيق لفلترة البيانات المقدَّمة من واجهة برمجة التطبيقات إلى ضرورة نقل منطق الفلترة هذا على جميع الأنظمة الأساسية التي تُطوّر تطبيقات لها.

من منظور الأمان، ينتج هذا التهديد عن تفويض فرض التفويض على أحد التطبيقات، ولكن غالبًا ما يكون ذلك على نظام أساسي أو نظام تشغيل لا يمكنك التحكّم فيه. لقد سبق أن راجعنا في API1 وAPI2 أهمية تنفيذ المصادقة والتفويض بشكلٍ صحيح لتجنُّب الوصول غير المصرّح به إلى البيانات.

تتناول الأقسام التالية كيفية إجراء ما يلي:

  • إعادة كتابة الطلبات والردود إلى خدمات الخلفية لتقليل إمكانية الوصول إلى البيانات
  • تنفيذ معالجة الأخطاء لمنع رسائل الخطأ المفصّلة من الكشف عن معلومات حساسة متعلقة بالبيئة للمهاجمين حول خدماتك الخلفية

إعادة كتابة الردود والطلبات

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

ولإجراء ذلك، تستخدم Apigee ثلاث سياسات رئيسية:

  • تعيين رسالة
  • وسائل شرح الرموز
  • معالجة الأخطاء

تحديد سياسة الرسائل

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

  • إضافة معلَمات نماذج أو عناوين أو مَعلمات طلب بحث جديدة إلى رسالة
  • نسخ المواقع الحالية من رسالة إلى أخرى
  • إزالة عناوين الرسائل ومَعلمات طلبات البحث ومَعلمات النماذج و/أو حِزم بيانات الرسائل من رسالة
  • ضبط قيمة السمات الحالية في رسالة

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

إعادة كتابة معقّدة باستخدام رمز مخصّص

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

باستخدام الرموز البرمجية الإجرائية، يمكنك إجراء ما يلي:

  • إنشاء قيم محتوى معقّدة أو التلاعب بها، مثل قيم الطلب والاستجابة
  • إعادة كتابة عناوين URL، مثلاً لإخفاء عنوان URL لنقطة نهاية مستهدفة

تتضمّن Apigee Edge سياسة منفصلة للغات المتوافقة: سياسة JavaScript وسياسة التعليقات التوضيحية في Java وسياسة النصوص البرمجية في Python.

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

تتيح لك Apigee تنفيذ معالجة مخصّصة للاستثناءات باستخدام سياسة من النوع Raise Fault. تتيح لك سياسة "تصعيد الخطأ"، وهي نوع من سياسة "تعيين الرسالة"، توليد استجابة خطأ مخصّصة استجابةً لحالة خطأ.

مسارات الإحالات الناجحة المشتركة

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

API4:2019 Lack of resources & rate limiting

وصف التهديد

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

يمكن معالجة هذا التهديد بسهولة باستخدام ميزات Apigee التالية:

  • الاستقطاعات والسياسات المتعلقة بمنع الطلبات المرتفعة بصفتها عناصر تحكّم وقائية لفرض حدود على عدد الزيارات في طلبات واجهة برمجة التطبيقات الواردة
  • Apigee Sense لرصد الهجمات المستندة إلى برامج التتبُّع والاستجابة لها بشكل ديناميكي
  • مراقبة وإصدار تنبيهات متقدّمة لواجهات برمجة التطبيقات كعناصر تحكّم تحليلية للتنبيه إلى هجمات الحرمان من الخدمات الموزّعة الجارية

الحدّ من معدّل الزحف باستخدام الحصص وسياسات المنع عند تسجيل قفزات مفاجئة في عدد الزيارات

توفّر Apigee سياستَين لتقييد معدّل الإرسال:

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

Spike Arrest

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

الحصص

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

  • المنتج الذي يحتوي على خادم وكيل واجهة برمجة التطبيقات
  • التطبيق الذي يطلب واجهة برمجة التطبيقات
  • مطوّر التطبيق
  • العديد من المعايير الأخرى

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

رصد برامج التتبُّع باستخدام Apigee Sense

باستخدام Apigee Sense، يمكنك اتّخاذ إجراء للسماح صراحةً بالطلبات الواردة من عملاء أو نطاقات IP أو أنظمة مستقلة معيّنة أو حظرها أو الإبلاغ عنها، استنادًا إلى العملاء أو المواقع الجغرافية التي تُظهر سلوكًا ضارًا أو مريبًا. تطبِّق Apigee Edge هذه الإجراءات على الطلبات قبل أن تعالجها الوكلاء لـ API. على سبيل المثال، يمكن رصد نطاق عنوان IP أو عميل معيّن يعرض سلوك "مخطّط تخمين عشوائي"، ثم يتم حظره أو وضع علامة عليه.

رصد التهديدات باستخدام مراقبة العمليات المتقدّمة لواجهات برمجة التطبيقات

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

‫API5:2019 مستوى الوظيفة المعطّلة التفويض

وصف التهديد

هذا التهديد هو نوع من API1، وهو يشكّل أيضًا ثغرة في التفويض. من خلال هذا التهديد، يتمكّن المهاجم من تنفيذ إجراءات عن طريق إرسال طلبات إلى وظائف لا يملك إذنًا بالوصول إليها. على سبيل المثال، قد يتمكّن المهاجم من تعديل البيانات التي يُسمح له بقراءتها فقط أو حذفها إذا لم تُجري نقطة نهاية واجهة برمجة التطبيقات عملية التحقّق من فعل طلب HTTP، وذلك من خلال استبدال GET بـ PUT أو DELETE. أو من خلال عدم تنفيذ عناصر تحكّم بالوصول بشكلٍ حصري بما يكفي في مسار عنوان URL لمصدر واجهة برمجة التطبيقات، قد تسمح نقطة نهاية واجهة برمجة التطبيقات لمهاجم بعرض بيانات مستخدم آخر من خلال تغيير المسار في طلب.

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

يتم عادةً تقسيم العناصر المفاهيمية لتقليل احتمالية حدوث هذا التهديد إلى ما يلي:

  • ما الذي يتم حمايته؟ فكِّر في استراتيجية منتجات واجهات برمجة التطبيقات، ونفِّذ تقسيمًا منطقيًا للوظائف عند استخدام أفضل الممارسات المتعلقة بواجهة برمجة التطبيقات RESTful لمحاولة تصميم المسارات والموارد التي تعرضها ميزات منتجات وتطبيقات Apigee API والخوادم الوكيلة لها.
  • مَن يمكنه الوصول إلى موارد واجهة برمجة التطبيقات؟ حدِّد الشخصيات العالية المستوى ونفِّذ أذونات الوصول التلقائية "لأقل امتياز" باستخدام بعض ميزات المصادقة والتفويض في Apigee كما هو موضّح في API1 وAPI2.
  • كيف يتم فرض سياسات الوصول؟ استخدِم مسارات المعالجة والشذوذات الشَرطية للتحقّق من صحة مسار عنوان URL والفعل لجميع طلبات البيانات من واجهة برمجة التطبيقات.

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

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

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

ومع ذلك، لتنفيذ التفويض الوظيفي والتقسيم الفعّالَين، من الضروري تحديد استراتيجية منتجات واجهات برمجة التطبيقات. يشكّل تحديد "المستخدِم" و"المنتج" لمنتجات واجهة برمجة التطبيقات جزءًا من هذه العملية المستمرة والأساسية، ويُجرى ذلك من خلال الاطّلاع على موارد واجهة برمجة التطبيقات من وجهة نظر العميل والمطوّر، ثم تحديد أنواع الطلبات التي سيتم السماح بها بالضبط، وذلك وصولاً إلى مستوى مورد المسار وفعل HTTP.

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

التحكّم في الوصول على مستوى الوظيفة باستخدام نطاقات OAuth وبيانات JWT

على الرغم من أنّ طرق التفويض التي تم النظر فيها أعلاه في ما يتعلّق بمتطلبات واجهة برمجة التطبيقات 1:2019 بشأن التفويض المعطّل للعناصر تتناول التحكّم الدقيق في الوصول على مستوى العنصر، من المهمّ أيضًا تناول التحكّم الإجمالي في الوصول على مستوى الوظيفة. هل يُسمح للمستخدم الذي يقدّم الطلب بطلب مسار عنوان URL هذا على الإطلاق؟ غالبًا ما يتم تحديد هذا النوع من السياسات حسب شخصية المستخدم (عميل أو موظف أو مشرف أو مطوّر داخلي أو تابع لجهة خارجية).

للحد من خطر الضبط غير الصحيح، ننصحك هنا بالتعاون مع فريق الأمان لضمان احتواء العبارة حول المستخدم المُقدّم للطلب في رمز هجمة الوصول، إما باستخدام نطاقات OAuth أو مطالبات JWT.

طلب التحقّق من خلال مسارات مشروطة

على مستوى أساسي، يتألف طلب بيانات من واجهة برمجة تطبيقات REST مما يلي:

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

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

بعد فهم منطق النشاط التجاري لمنتج واجهة برمجة التطبيقات وتحديد الوظائف التي تسمح بها واجهات برمجة التطبيقات بوضوح، تكون الخطوة التالية هي حظر أي طلبات لا تندرج ضمن هذا النطاق من خلال ميزات منتج Apigee التالية:

  • المنطق الشَرطي وسياسات "رفع الخطأ" لتقييد مسارات الموارد أو الأفعال في أي خطوة من عملية ضبط تدفق الخادم الوكيل
  • JSON وXML سياسات حماية من التهديدات لحماية المواقع الإلكترونية من الهجمات المستندة إلى المحتوى باستخدام حِزم طلب JSON أو XML غير الصالحة

API6:2019 Mass assignment

وصف التهديد

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

يحدث هذا التهديد عند إرسال بيانات غير مفلتَرة (عادةً بتنسيق JSON أو XML) إلى عميل، مما يسمح للمهاجم بتخمين تفاصيل التنفيذ الأساسية لأنظمة الخلفية، بالإضافة إلى أسماء عناصر البيانات السرية. يمكن أن تؤدي نتيجة هذا النوع من الهجمات إلى منح المهاجم إمكانية قراءة البيانات غير الملائمة أو التلاعب بها، أو في أسوأ سيناريوهات الحالة، يمكن أن تؤدي إلى تفعيل الثغرات الأمنية لتشغيل الرموز البرمجية عن بُعد.

هناك جانبان عادةً ما يتسبّبان في السماح بهذا النوع من التهديدات:

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

من منظور منتجات Apigee، نقدّم العديد من الميزات المفيدة لضمان تنفيذ عمليات فلترة قوية للبيانات في واجهات برمجة التطبيقات.

سياسة فلترة مواصفات OpenAPI

تتيح لك سياسة OASValidation (التحقّق من مواصفات OpenAPI) التحقّق من طلب أو استجابة واردَين وفقًا لمواصفات OpenAPI 3.0 (JSON أو YAML). تتيح لك هذه السياسة ما يلي:

  1. تصميم واجهة برمجة التطبيقات من خلال إنشاء مواصفات OpenAPI (OAS)
  2. تنفيذ منطق التوسّط والأمان والتخزين المؤقت اللازمَين لعرض منتج واجهة برمجة التطبيقات بشكل آمن من الخلفية باستخدام Apigee
  3. التحقّق من صحة الطلبات الواردة وفقًا لمخطّط البيانات المحدّد في مواصفات OAS، بما في ذلك المسار الأساسي والفعل وسياسة رسالة الطلب و المَعلمات

سياسة التحقّق من رسائل SOAP

تسمح لك سياسة التحقّق من رسائل SOAP بالتحقّق من الطلبات المستندة إلى XML، إما من خلال التحقّق من صحة رسالة XML وفقًا لمخطّط XSD، أو التحقّق من صحة رسالة SOAP وفقًا لتعريف WSDL. بالإضافة إلى ذلك، يمكنك استخدام سياسة التحقّق من الرسائل للتأكّد من أنّ حمولة رسالة JSON أو XML منسقة بشكل سليم، بما في ذلك التحقّق مما يلي في رسالة XML أو JSON:

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

API7:2019 Security misconfiguration

وصف التهديد

غالبًا ما يكون ضبط الإعدادات الأمنية بشكلٍ غير صحيح نتيجةً لإعدادات تلقائية غير آمنة أو إعدادات مخصّصة غير مكتملة أو مساحة تخزين سحابي مفتوحة أو عناوين HTTP تم ضبطها بشكلٍ غير صحيح أو طرق HTTP غير ضرورية أو مشاركة موارد متعددة المصادر (CORS) مسموح بها أو رسائل خطأ مفصّلة تحتوي على معلومات حساسة. غالبًا ما يحاول المهاجمون العثور على عيوب لم يتم تصحيحها أو نقاط نهاية شائعة أو ملفات وأدلة غير محمية للحصول على إذن وصول غير مصرّح به أو معرفة بالنظام الذي يريدون مهاجمته. يمكن أن تؤدي الأخطاء في إعدادات الأمان إلى تعريض بيانات المستخدمين الحسّاسة للخطر، بالإضافة إلى تفاصيل النظام التي قد تؤدي إلى اختراق الخادم بالكامل. بالإضافة إلى ذلك، قد تشمل بعض حالات الاستخدام الأخرى للثغرات الأمنية المتعلّقة بأخطاء الضبط في ملف التكوين المتعلّق بالحماية ما يلي:

  • إعدادات بروتوكول أمان طبقة النقل (TLS) غير صحيحة
  • رسائل الخطأ التي تتضمّن تتبعات تسلسل استدعاء الدوال البرمجية
  • الأنظمة التي لم يتم ترقيتها
  • لوحات إدارة الخوادم أو مساحة التخزين الظاهرة

هناك خطوات مختلفة يمكن للمؤسسات اتّخاذها لمواجهة التحديات المتعلّقة بإعدادات الأمان الخاطئة والحدّ منها، بما في ذلك:

  1. وضع عمليات التشديد والإصلاح ووضع معايير لها
  2. تطوير منظومة متكاملة لإدارة واجهات برمجة التطبيقات
  3. تقييد الوصول الإداري وتفعيل التدقيق والتنبيهات

مسارات المستخدمين المشترَكة وعناصر ربط المسارات

تتيح Apigee مفهوم المسار المشترَك الذي يتيح لمطوّري واجهات برمجة التطبيقات دمج السياسات والموارد في مجموعة قابلة لإعادة الاستخدام. من خلال تسجيل الوظائف القابلة لإعادة الاستخدام في مكان واحد، يساعدك المسار المشترَك في ضمان الاتساق وتقليل وقت التطوير وإدارة الرموز البرمجية بسهولة أكبر. يمكنك تضمين مسار مشترَك داخل خوادم وكيل واجهة برمجة تطبيقات فردية، أو يمكنك اتخاذ خطوة إضافية ووضع مسارات مشترَكة في مخطّطات ربط المسارات ل ejecutang منطق المسار المشترَك تلقائيًا لكل خادم وكيل لواجهة برمجة التطبيقات يتم نشره في البيئة نفسها التي يتم فيها تنفيذ المسار المشترَك.

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

بينما تسعى المؤسسات جاهدة إلى تطوير إطار عمل لإدارة أمان واجهات برمجة التطبيقات، يوفّر Apigee إمكانات تتعلّق بإعداد تقارير أمان واجهات برمجة التطبيقات، ما يساعد فِرق العمليات في الحصول على مستوى الشفافية الذي يحتاجونه بشأن سمات أمان واجهات برمجة التطبيقات من أجل:

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

تقدّم تقارير أمان Apigee إحصاءات مفصّلة لفِرق العمليات لضمان الالتزام بالسياسات ومتطلبات الضبط وحماية واجهات برمجة التطبيقات من إساءة الاستخدام الداخلية والخارجية وتحديد الحوادث الأمنية وحلّها بسرعة.

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

مراقبة واجهة برمجة التطبيقات

توفّر Apigee منصّة شاملة لمراقبة واجهات برمجة التطبيقات تكمل إمكانات إعداد تقارير الأمان. تتيح ميزة "مراقبة واجهة برمجة التطبيقات" للمؤسسات رصد مشاكل الأداء وحركة مرور واجهة برمجة التطبيقات بشكل استباقي. تعمل ميزة Apigee API monitoring مع Apigee Edge for Public Cloud لتوفير إحصاءات سياقية في الوقت الفعلي حول أداء واجهة برمجة التطبيقات، ما يساعد في تشخيص المشاكل بسرعة وتسهيل الإجراءات التصحيحية للحفاظ على استمرارية النشاط التجاري.

الشكل: توفّر ميزة "مراقبة واجهة برمجة التطبيقات" في Apigee مجموعة كبيرة من الأدوات لمراقبة المشاكل والتحقّق منها واتّخاذ إجراءات بشأنها. وتستفيد من أفضل ميزات الذكاء على مستوى العالم من Google Cloud Platform.

Apigee Sense

يساعد Apigee Sense في حماية واجهات برمجة التطبيقات من عدد الطلبات غير المرغوب فيه، بما في ذلك الهجمات من العملاء الضارّين. يحلِّل Apigee Sense عدد زيارات طلبات البيانات من واجهة برمجة التطبيقات، ويحدِّد الأنماط التي قد تمثّل طلبات غير مرغوب فيها.

باستخدام هذا التحليل، يمكن للمؤسسات تحديد العملاء الذين يقدّمون طلبات غير مرغوب فيها، ثم اتّخاذ إجراء للسماح بهذه الطلبات أو حظرها أو الإبلاغ عنها. باستخدام Apigee Sense، من الممكن حماية واجهات برمجة التطبيقات من أنماط طلبات data التي تشمل ما يلي:

  • السلوك المبرمَج الذي يمتزج مع السلوك البشري
  • محاولات متكرّرة من عنوان IP نفسه
  • معدّلات الأخطاء غير المعتادة
  • طلبات العملاء المريبة
  • الزحف إلى البيانات
  • جمع مفاتيح التشفير
  • فترات النشاط
  • الأنماط الجغرافية

هجوم API8:2019 Injection

وصف التهديد

إنّ إدخال البيانات غير الموثوق بها، مثل لغة الاستعلامات البنيوية (SQL) وNoSQL وأدوات تحليل لغة XML وORM وLDAP وأوامر نظام التشغيل و JavaScript، في طلبات واجهة برمجة التطبيقات يمكن أن يؤدي إلى تنفيذ أوامر غير مقصودة أو الوصول غير المصرّح به إلى البيانات. سيغذّي المهاجمون واجهة برمجة التطبيقات ببيانات ضارة من خلال أيّ من ناقلات الحقن المتاحة مثل الإدخال المباشر والمَعلمات والخدمات المدمجة وما إلى ذلك، متوقّعين أن يتم إرسالها إلى مترجم. يمكن للمهاجمين اكتشاف هذه العيوب بسهولة عند مراجعة رمز المصدر باستخدام برامج فحص الثغرات وبرامج البحث عن الأخطاء. يمكن أن تؤدي عملية الحقن الناجحة إلى الإفصاح عن المعلومات ما يؤثر في السرية وفقدان البيانات، أو قد تؤدي في بعض الحالات أيضًا إلى حجب الخدمة.

تشمل أفضل الممارسات للحدّ من أخطاء/هجمات الحقن تحديد بيانات الإدخال بدقة، مثل المخططات والأنواع وأنماط السلاسل، وإجراء عمليات التحقّق من صحة الإدخال، وعمليات التحقّق من الحدود وفرضها أثناء التشغيل. تسمح منصة Apigee بالتحقق من صحة البيانات الواردة باستخدام الفلاتر للسماح فقط بالقيم الصالحة لكل مَعلمة إدخال.

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

سياسة حماية التعبير العادي

تُستخرج سياسة RegularExpressionProtection معلومات من رسالة (مثل مسار عنوان URL أو مَعلمة طلب البحث أو العنوان أو مَعلمة النموذج أو المتغيّر أو الحمولة بتنسيق XML أو الحمولة بتنسيق JSON) وتقيّم هذا المحتوى وفقًا للتعبيرات العادية المحدّدة مسبقًا. إذا تم تقييم أي تعبيرات منتظمة محدّدة على أنّها صحيحة، يتم اعتبار الرسالة تهديدًا ويتم رفضها. التعبير العادي هو مجموعة من السلاسل التي تحدّد نمطًا في سلسلة. تتيح التعبيرات العادية تقييم المحتوى بشكل آلي بحثًا عن الأنماط. يمكن استخدام التعبيرات العادية، على سبيل المثال، لتقييم عنوان بريد إلكتروني للتأكّد من أنّه منظَّم بشكلٍ صحيح.

إنّ الاستخدام الأكثر شيوعًا RegularExpressionProtection هو تقييم حِزم JSON وXML بحثًا عن المحتوى الضار.

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

هناك عدة طرق أخرى للتحقّق من صحة الإدخال متاحة من خلال منصة Apigee:

التحقّق من أنواع المحتوى

يشير نوع المحتوى إلى محتوى الملف الذي يتم نقله عبر بروتوكول HTTP ويتم تصنيفه وفقًا لبنية من جزأين. تنصح Apigee بالتحقق من أنواع المحتوى للطلب والاستجابة باستخدام المنطق الشَرطي كما هو موضّح أدناه.

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

بينما تسعى المؤسسات جاهدة إلى تطوير إطار عمل لإدارة الخدمات، تقدّم Apigee إمكانات متعلّقة بإعداد تقارير أمان واجهات برمجة التطبيقات، ما يساعد فِرق العمليات ويمنحها مستوى الشفافية الذي تحتاجه لتأمين واجهات برمجة التطبيقات من خلال منحهم مستوى الشفافية الذي يحتاجونه لتأمين سمات أمان واجهات برمجة التطبيقات من أجل:

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

‏API9:2019 إدارة مواد العرض بشكل غير سليم

وصف التهديد

تسمح إدارة البيئة وتقسيمها غير المُجديين للمهاجمين بالوصول إلى نقاط نهاية واجهة برمجة التطبيقات التي لم يتم تأمينها بشكل كافٍ. ويؤدي أيضًا عدم توفّر إجراءات وقائية لإدارة الموارد إلى عرض غير ضروري للموارد التي تم إيقافها نهائيًا.

يمكن معالجة هذا التهديد من خلال الاستفادة من إمكانات Apigee المتقدّمة لإدارة دورة حياة واجهة برمجة التطبيقات بالكامل، ما يتيح لك إنشاء نموذج إدارة شامل يتيح التعاون بين الفِرق، وفي الوقت نفسه، تطبيق الفصل بين المسؤوليات بين الجهات المعنيّة بالسلامة ومطوّري واجهة برمجة التطبيقات. يمكن ضبط الحدود وعناصر التحكّم والحفاظ عليها باستخدام:

المؤسسات والبيئات والنُسخ: قيود افتراضية وحقيقية تضمن العزل وعملية ترقية آمنة من خلال السياقات أثناء التشغيل

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

إدارة الجمهور لمستندات واجهة برمجة التطبيقات: بعد نشر واجهة برمجة تطبيقات فيبوابة المطوّرين، يمكنك الحد من مستوى ظهور المستندات من خلال إدارة شرائح الجمهور المستهدَفة.

Flow Hooks: يمكنك فرض سياسات وأنماط عامة يمكن إدارتها بصفتها قيودًا احترازية مميّزة لا يمكن لمطوّري واجهات برمجة التطبيقات تعديلها.

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

المؤسسات والبيئات

يمكن ضبط نطاق عناصر الضبط والمستخدمين والميزات في Apigee على مؤسسات و/أو بيئات معيّنة. ويعني ذلك أنّ المنصة تتضمّن قيودًا مُعدّة مسبقًا يمكن وضعها حول واجهات برمجة التطبيقات وإعداداتها الداعمة.

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

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

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

التحكّم في الوصول المستنِد إلى الدور

للحدّ من API9، من الضروري أن يكون لديك تعريفات واضحة للواجبات وفصلها بين الجهات المعنية بالأمان ومطوّري واجهات برمجة التطبيقات. كما ذكرنا سابقًا في هذا المستند، توفّر Apigee إمكانات مرنة للتحكّم في الوصول بالاستناد إلى الأدوار تتيح لك منح الأذونات للأدوار المخصّصة. بالنسبة إلى هذا التهديد المحدّد، يمكن تحديد نطاق الأدوار للحصول على امتيازات محدودة لكل مؤسسة أو بيئات أو أذونات إعدادات أكثر دقة. كإجراء مفضّل، ننصحك بتقييد الأذونات لتغيير حالة النشر لواجهات برمجة التطبيقات من خلال البيئات، وكذلك للتأكّد من أنّ المطوّرين لا يمكنهم الوصول إلى مكتبات الأمان الشاملة (Flow Hooks) أو تعديلها. ستمنع هذه الأدوار المحدودة إجراء تغييرات غير مرغوب فيها على سياسات الأمان العالمية التي تتمتع بتغطية واسعة على كلّ من نقاط النهاية المنشورة القديمة والحالية.

مستندات Audience Management لواجهة برمجة التطبيقات

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

باستخدام بوابة المطوّرين المُدمَجة في Apigee، يمكنك نشر منتجات واجهات برمجة التطبيقات وتقييد مستوى رؤية المحتوى المنشور من خلال إدارة شرائح الجمهور المستهدَفة. تتوافق هذه الميزة مع استراتيجية تقسيم المحتوى التي تتوافق بدورها مع متطلبات النشاط التجاري والأمان.

عناصر الربط

يجب أن تتضمّن عمليات الترويج والإصدار لواجهات برمجة التطبيقات دائمًا عمليات الامتثال للأمان والاعتماد. لكي تكون الفِرق التي تستخدم أدوات واجهة برمجة التطبيقات المناسبة فعّالة، يجب أن تتمكّن من وضع قيود تضمن الفصل بين المسؤوليات مع الحفاظ على دورات الإصدارágil.

تتيح لك Apigee تصعيد مهام إدارة الأمان من خلال فرض سياسات عامة من خلال Flow Hooks. يمكن إدارة هذه السياسات العميقة بصفتها قيودًا امتيازية لا يمكن لمطوّري واجهات برمجة التطبيقات تعديلها، وبالتالي ضمان الفصل بين المسؤوليات وتعزيز المرونة من خلال تطبيق الأمان التلقائي، وبالتالي توفير الامتثال للأمان لجميع واجهات برمجة التطبيقات التي يتم نشرها في بيئة تنفيذ معيّنة.

الشكل: يمكن ضبط قيود الأمان المميّزة في Apigee من خلال "خطافات المسار" و"المسارات المشتركة". تتحمّل الجهات المعنية بالأمان مسؤولية الحفاظ على السياسات العالمية المتعلّقة بالأمان. تضمن هذه الميزات الفصل بين المسؤوليات وتعزّز دورات تطوير البرامج المتغيّرة باستمرار.

إعداد تقارير الأمان

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

في Apigee، يمكنك الوصول إلى تقارير أمان متخصّصة تساعد في ضمان الالتزام بالسياسات المحدّدة، و تمكّن فِرق الأمان من اتّخاذ الإجراءات استنادًا إلى إحصاءات شاملة حول ما يلي:

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

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

نشاط مستخدمي المنصة: تتبُّع العمليات الحسّاسة التي يجريها مستخدمو المنصة تحليل النشاط المريب من خلال التوغّل في تفاصيله

API10:2019 Insufficient logging & monitoring

وصف التهديد

إنّ عدم توفّر ميزة التسجيل والمراقبة والتنبيهات بشكل كافٍ يسمح بعدم رصد الهجمات الجارية، وبالتالي يجب وضع استراتيجية للحصول على إحصاءات عن الأحداث المُهمّة التي تؤثر في نشاطك التجاري.

يجب أن تراعي استراتيجيات إدارة الأحداث والتسجيل في واجهات برمجة التطبيقات أفضل الممارسات التالية:

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

توفّر Apigee الأدوات اللازمة لإنشاء استراتيجية شاملة لإدارة الأحداث والتسجيل. وتشمل هذه الأدوات ما يلي:

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

Google’s Cloud Operation Suite: يمكنك الاستفادة من عملية الدمج التلقائية في أدوات المراقبة والتسجيل من Google والتي يمكن توسيع نطاقها بشكل كبير.

سياسة طلب الدعم: تضيف هذه السياسة إمكانية استخدام مصادر السجلات التي تتطلّب نقاط نهاية HTTP لإرسال الأحداث.

إحصاءات Google: يمكنك الوصول إلى البيانات الوصفية السابقة للزيارات وتحليلها من خلال تقارير مخصّصة و/أو تقارير جاهزة. أنشئ تنبيهات وادارتها استنادًا إلى المؤشرات وفهم الحالات الشاذة للزيارات.

مراقبة واجهة برمجة التطبيقات: كما هو описан سابقًا، توفّر هذه الأداة إمكانات تنبيه يمكن تفعيلها استنادًا إلى الأحداث الحرجة. يمكن تحليل سجلّات الزيارات بشكلٍ أكبر واتّخاذ إجراء بشأنها.