سؤال: كيف يمكن للمؤسسات التأكد من أن واجهات برمجة التطبيقات الخاصة بها مقاومة للتنازل ، في مواجهة الهجمات المتزايدة القائمة على واجهة برمجة التطبيقات؟
روري بلونديل ، المؤسس والرئيس التنفيذي لشركة Gravitee: تعتمد الشركات من جميع الأحجام وعبر جميع الصناعات بشكل روتيني على واجهات برمجة التطبيقات الداخلية لتوحيد تطبيقات خط الأعمال الخاصة بها ، وعلى واجهات برمجة التطبيقات الخارجية لمشاركة البيانات أو الخدمات مع البائعين أو العملاء أو الشركاء. نظرًا لأن واجهة برمجة التطبيقات (API) الواحدة قد تتمكن من الوصول إلى تطبيقات أو خدمات متعددة ، فإن اختراق واجهة برمجة التطبيقات يعد طريقة سهلة للتغلب على مجموعة واسعة من أصول الأعمال بأقل جهد ممكن.
أصبحت واجهات برمجة التطبيقات (API) ناقلًا شائعًا للهجوم ، وزاد تواتر هجمات API بشكل مذهل 681%، وفقًا لآخر البحث من مختبرات الملح. الخطوة الأولى في تأمين واجهات برمجة التطبيقات الخاصة بك هي اتباع أفضل الممارسات ، مثل تلك التي OWASP توصي بالحماية من المخاطر الأمنية الشائعة لواجهة برمجة التطبيقات.
ومع ذلك ، فإن ممارسات أمان API الأساسية ليست كافية للحفاظ على أمان موارد تكنولوجيا المعلومات. يجب أن تتخذ الشركات الخطوات الإضافية التالية لحماية واجهات برمجة التطبيقات الخاصة بها.
1. اعتماد المصادقة القائمة على المخاطر
يجب أن تتبنى الشركات سياسات مصادقة قائمة على المخاطر ، والتي تسمح بفرض الحماية الأمنية في حالات المخاطر المتزايدة. على سبيل المثال ، قد لا يحتاج عميل واجهة برمجة التطبيقات الذي لديه سجل طويل من إصدار الطلبات الشرعية التي تتبع نمطًا يمكن التنبؤ به إلى المرور بنفس مستوى المصادقة لكل طلب كعميل جديد لم يتصل من قبل. ولكن إذا تغير نمط وصول عميل API منذ فترة طويلة - على سبيل المثال ، إذا بدأ العميل فجأة في إصدار طلبات من عنوان IP مختلف - فإن طلب مصادقة أكثر صرامة سيكون طريقة ذكية لضمان أن الطلبات لا تأتي من عميل مخترق.
2. إضافة المصادقة البيومترية
على الرغم من أن الرموز المميزة تظل مهمة كوسيلة أساسية لمصادقة العملاء والطلبات ، إلا أنها يمكن أن يسرق. لهذا السبب ، فإن اقتران المصادقة القائمة على الرمز المميز بالمصادقة البيومترية هي طريقة ذكية لتحسين أمان واجهة برمجة التطبيقات. بدلاً من افتراض أن أي شخص يمتلك رمزًا مميزًا لواجهة برمجة التطبيقات هو مستخدم صالح ، يجب على المطورين تصميم التطبيقات بحيث يتعين على المستخدمين أيضًا المصادقة باستخدام بصمات الأصابع أو مسح الوجه أو طريقة مماثلة ، على الأقل في السياقات عالية الخطورة.
3. فرض المصادقة خارجيًا
كلما أصبحت أنظمة مصادقة واجهة برمجة التطبيقات أكثر تعقيدًا ، زاد صعوبة فرض متطلبات الأمان داخل تطبيقك نفسه. لهذا السبب ، يجب على المطورين السعي لفصل قواعد أمان واجهة برمجة التطبيقات عن منطق التطبيق وبدلاً من ذلك استخدام أدوات خارجية ، مثل بوابات API ، لفرض متطلبات الأمان. يجعل هذا النهج سياسات أمان API أكثر قابلية للتوسع ومرونة لأنه يمكن تنفيذها بسهولة وتحديثها داخل بوابات API ، بدلاً من التعليمات البرمجية المصدر للتطبيق. والأهم من ذلك ، أنه يتيح لك تطبيق قواعد مختلفة على مستخدمين أو طلبات مختلفة بناءً على ملفات تعريف المخاطر المختلفة.
4. موازنة أمان API مع سهولة الاستخدام
من المهم عدم السماح للأمن بأن يصبح عدوًا لقابلية الاستخدام. إذا جعلت إجراءات مصادقة واجهة برمجة التطبيقات متطرفة أو مرهقة للغاية ، فقد يتخلى المستخدمون عن واجهات برمجة التطبيقات ، وهو عكس ما تريد حدوثه. تجنب ذلك من خلال التأكد من أن قواعد أمان API صارمة عندما يكون هناك سبب لذلك ، ولكن دون فرض متطلبات غير ضرورية.
الهجمات التي تستهدف واجهات برمجة التطبيقات لا تظهر أي علامة على التباطؤ. عند تصميم واجهات برمجة التطبيقات وتأمينها ، يجب على المطورين تجاوز توصيات OWASP لجعل استغلال واجهة برمجة التطبيقات أكثر صعوبة.
