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

يتم الآن عرض مستندات Apigee Edge.
انتقِل إلى مستندات Apigee X. المعلومات

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

مقدمة

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

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

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

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

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

API1:2019 التفويض على مستوى العنصر غير صالح

وصف التهديد

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

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

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

  • سلامة رمز الدخول
  • فرض مراقبة الوصول

سلامة الرمز المميّز للوصول

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

تتضمن سياسات التحقُّق من رمز الدخول إلى Apigee ما يلي:

فرض مراقبة الوصول

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

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

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

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

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

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

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

API2:2019 مصادقة المستخدم غير مكتملة

وصف التهديد

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

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

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

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

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

تصميم الأمان

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

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

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

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

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

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

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

ميزة الإدارة

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

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

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

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

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

التدفقات المشتركة

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

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

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

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

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

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

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

Apigee Sense

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

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

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

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

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

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

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

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

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

وصف التهديد

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

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

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

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

تتناول الأقسام التالية كيفية:

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

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

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

ولتنفيذ ذلك، تستخدم Apigee ثلاث سياسات رئيسية:

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

تعيين سياسة الرسالة

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

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

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

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

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

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

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

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

التعامل مع الأخطاء

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

التدفقات المشتركة

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

API4:2019 نقص الموارد والحدّ من المعدّل

وصف التهديد

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

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

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

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

توفّر Apigee سياستين للحدّ من المعدّل:

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

اعتقال ارتفاع

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

الحصص

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

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

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

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

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

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

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

API5:2019 تفويض مستوى الدالة غير مفعّل

وصف التهديد

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

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

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

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

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

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

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

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

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

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

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

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

طلب التحقق من الصحة باستخدام التدفقات الشرطية

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

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

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

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

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

API6:2019 التعيين الجماعي

وصف التهديد

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

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

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

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

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

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

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

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

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

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

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

الإعداد الخاطئ للأمان في API7:2019

وصف التهديد

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

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

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

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

مسارات مشترَكة وخطّافات تدفق

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

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

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

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

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

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

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

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

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

Apigee Sense

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

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

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

الحقن في واجهة برمجة التطبيقات API8:2019

وصف التهديد

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

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

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

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

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

يُعدّ تقييم حمولات JSON وXML الأكثر شيوعًا للمحتوى الضارّ من أوجه الاستخدام الأكثر شيوعًا لـ RegularExpressionProtection.

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

هناك العديد من المناهج الأخرى للتحقق من صحة المدخلات المتوفرة مع منصة Apigee:

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

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

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

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

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

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

وصف التهديد

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

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

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

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

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

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

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

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

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

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

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

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

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

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

إدارة الجمهور لوثائق واجهة برمجة التطبيقات

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

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

خطافات تدفق

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

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

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

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

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

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

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

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

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

API10:2019 التسجيل والمراقبة غير كافٍ

وصف التهديد

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

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

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

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

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

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

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

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

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