كانت واجهاتنا البرمجية مفتوحة على مصراعيها: كيف أنقذتنا ‘بوابة الـ API’ من جحيم الهجمات العشوائية؟

السلام عليكم يا جماعة، معكم أخوكم أبو عمر.

بتذكر هداك اليوم زي كأنه مبارح. كنت قاعد في أمان الله، بشرب كاسة الشاي بالنعنع تبعت المسا، وبتصفح آخر أخبار التقنية. فجأة، رن الجوال. رقم المبرمج الجديد في الفريق، شب صغير لسا متحمس ومليان طاقة. أول ما رديت، سمعت صوت لَهَث وخوف: “يا أبو عمر الحقنا! السيرفرات كلها down! الموقع واقع والتطبيق مش شغال! شكلها ولّعت!”.

قلبي نغزني. “ولّعت كيف يعني؟” سألته وأنا بحاول أكون هادي. قال لي إنه استخدام المعالج (CPU) وصل 100% على كل الخدمات المصغرة (Microservices) تبعتنا، والطلبات على قاعدة البيانات بالملايين، وكل شيء انهار. للحظة، فكرت إنه هجوم DDoS منظم ومتطور. دخلنا على لوحة المراقبة (Dashboard) بسرعة، وهون كانت الصدمة… ما كان هجوم منظم بالمعنى الدقيق، كان “جحيم عشوائي”.

وجدنا آلاف الطلبات من عناوين IP مختلفة حول العالم، بعضها بيعمل scraping للبيانات، وبعضها بيحاول يخمن كلمات سر بشكل غبي، وبعضها مجرد bots بتلف على الإنترنت وبتطلب أي endpoint بتلاقيه. كانت واجهاتنا البرمجية (APIs)، اللي بنيناها بكل فخر بتقنية الخدمات المصغرة، مفتوحة على مصراعيها زي سوق شعبي بدون بوابات. كل خدمة عندها الـ API الخاص فيها، وكلها مكشوفة للإنترنت مباشرة. كانت فوضى، ورطة حقيقية. في هداك اليوم، أدركنا أن بنية الخدمات المصغرة الرائعة تبعتنا كانت أيضًا كعب أخيل لأنظمتنا. وهون بلش الحكي الجد عن إشي اسمه “API Gateway”.

ما هي بنية الخدمات المصغرة؟ ولماذا كانت مشكلتنا؟

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

هذا الأسلوب رائع جدًا للتطوير السريع والتوسع، لكنه خلق مشكلة جديدة: بدل ما يكون عندك واجهة برمجية (API) وحدة كبيرة، صار عندك عشرات أو حتى مئات الواجهات الصغيرة. كل خدمة الها الـ API تبعها. وهذا يعني:

• سطح هجوم واسع (Large Attack Surface): كل API هو باب محتمل للهجمات. بدل ما تحرس باب واحد، صار لازم تحرس 50 باب.
• تكرار الكود: كل خدمة بتحتاج تنفذ نفس المنطق: التحقق من المستخدم (Authentication)، تحديد صلاحياته (Authorization)، تحديد عدد الطلبات المسموحة (Rate Limiting)، تسجيل النشاط (Logging). هذا تكرار ممل ومصدر للأخطاء.
• صعوبة الإدارة: كيف بتعرف أي خدمة عليها ضغط؟ كيف بتجمع كل سجلات النشاط في مكان واحد؟ كيف بتحدّث سياسة أمان على كل الخدمات مرة وحدة؟ الموضوع بصير كابوس.

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

بوابة الـ API (API Gateway): الحارس الأمين على أبواب المدينة

بعد ليلة طويلة من إطفاء الحرائق المؤقتة، اجتمعنا وقررنا إنه “فش إشي بمشي هيك”. لازم يكون في حل جذري. الحل كان اسمه API Gateway.

ببساطة شديدة، بوابة الـ API هي عبارة عن خادم (Server) وسيط، بكون هو نقطة الدخول الوحيدة لكل الطلبات اللي جاية من برا (من تطبيقات الموبايل، مواقع الويب، إلخ). بدل ما العميل يكلم كل خدمة مصغرة مباشرة، صار يكلم البوابة، والبوابة هي اللي بتتفاهم مع الخدمات الداخلية.

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

كيف أنقذتنا بوابة الـ API عمليًا؟

خلونا نرجع لمشاكلنا ونشوف كيف البوابة حلتها وحدة وحدة:

1. التوحيد والأمان: نقطة دخول واحدة تحكم الكل

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

نصيحة أبو عمر: لا تكشف خدماتك الداخلية للإنترنت أبدًا. استخدم شبكة خاصة (VPC/VNet) واجعل الـ API Gateway هي المكون الوحيد الذي يملك IP عام. شغل نظيف ومُرتب.

2. تحديد المعدل (Rate Limiting): درعنا ضد الطوفان

مشكلة الطلبات العشوائية اللي أغرقت سيرفراتنا؟ الـ API Gateway حلتها بامتياز. طبقنا سياسة “تحديد المعدل” بسيطة: كل عنوان IP مسموح له بعدد معين من الطلبات في الدقيقة (مثلاً 100 طلب). أي حدا بتجاوز هذا الحد، البوابة بتعمله “Block” تلقائيًا لفترة معينة، بدون ما يوصل طلبه أصلًا للخدمات الداخلية.

هذا منع الـ bots الغبية وهجمات القوة العمياء (Brute Force) البسيطة من إنها تستهلك مواردنا.

مثال بسيط (باستخدام Kong API Gateway – بصيغة YAML):

_format_version: "2.1"
services:
- name: user-service
  url: http://user-service-internal:8080 # عنوان الخدمة الداخلي
  routes:
  - name: user-route
    paths:
    - /users
    plugins:
    - name: rate-limiting # تفعيل إضافة تحديد المعدل
      config: 
        minute: 100 # 100 طلب في الدقيقة لكل مستهلك/IP
        policy: local

بهذا الكود البسيط، حمينا خدمة المستخدمين من أي طوفان طلبات.

3. المصادقة والترخيص المركزية (Centralized Auth): “من أنت يا هذا؟”

بدل ما كل خدمة من خدماتنا (المكتوبة بلغات مختلفة أحيانًا) تضطر تفكك وتتحقق من الـ JWT (JSON Web Tokens) أو مفاتيح الـ API، نقلنا كل هذا العبء على البوابة.

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

4. المراقبة والتسجيل (Logging & Monitoring): العين التي لا تنام

قبل البوابة، عشان نعرف شو بصير، كنا لازم ندخل على سجلات (logs) كل خدمة لحالها. كانت عملية مرهقة جدًا. مع الـ API Gateway، صارت كل الطلبات بتمر من خلالها، وبالتالي صار عنا مكان واحد مركزي بنشوف فيه كل إشي:

• كل طلب دخل للنظام.
• من أي IP أتى.
• لأي خدمة كان موجه.
• كم أخذ وقت للرد.
• هل نجح الطلب أم فشل (Status Code 200, 404, 500).

هذا أعطانا رؤية شاملة وواضحة عن صحة النظام كله، وسهل علينا اكتشاف المشاكل بسرعة البرق.

نصائح من قلب الميدان (من خبرتي كأبو عمر)

بعد ما عشنا هاي التجربة، تعلمت كم درس حابب أشارككم فيها:

1. لا تخترع العجلة: إياك ثم إياك تفكر تبني API Gateway من الصفر إلا إذا كان عندك سبب قوي جدًا وفريق ضخم. السوق مليان حلول ممتازة، مفتوحة المصدر وتجارية. من أشهرها: Kong, Tyk, NGINX Plus, Apigee (Google), AWS API Gateway, Azure API Management. اختار اللي بيناسبك وبيناسب ميزانيتك.
2. ابدأ بسيطًا: الـ API Gateway فيها ميزات كثيرة جدًا. لا تحاول تطبقها كلها من أول يوم. ابدأ بالأهم: توجيه الطلبات (Routing)، تحديد المعدل (Rate Limiting)، والمصادقة (Authentication). بعدين شوي شوي ضيف الميزات الثانية زي التخزين المؤقت (Caching) وتحويل الطلبات (Request Transformation).
3. اعتبرها كود (Gateway as Code): لا تعتمد على التعديل اليدوي من خلال واجهة رسومية. كل إعدادات البوابة تبعتك لازم تكون مكتوبة في ملفات (زي مثال الـ YAML فوق)، ومحفوظة في نظام Git. هذا بخلي التغييرات منظمة، موثقة، وسهلة المراجعة والتراجع عنها.
4. راقب البوابة نفسها: تذكر، البوابة صارت هي أهم مكون في نظامك. إذا وقعت، كل إشي بيوقع. لازم تراقب صحتها، استهلاكها للموارد، وزمن الاستجابة تبعها بشكل مستمر.

الخلاصة: البوابة ليست رفاهية، بل ضرورة 🛡️

يا جماعة، في عالم الخدمات المصغرة والأنظمة الموزعة، الـ API Gateway بطلت مجرد “إضافة حلوة” أو رفاهية. هي صارت ضرورة أساسية، زي جدار الحماية (Firewall) لشبكتك. هي خط الدفاع الأول، ومنظم المرور، والحارس اللي بيحميك من كثير وجع راس وهجمات كان ممكن تدمر شغلك كله في ليلة وضحاها.

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

ودمتم سالمين مبرمجين.