Loading...

الأمان · قراءة 8 دقائق

تحديد معدل الطلبات: أوقِف الإساءة دون حجب عملائك

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

Updated

تحديد معدل الطلبات: أوقِف الإساءة دون حجب عملائك

ما الذي يفعله فعلًا

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

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

اختيار رقم لا يؤذي

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

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

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

ليس كل مسار يستحق الحدّ نفسه

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

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

على cdn.com.tr يمكن ضبط حدّ معدل الطلبات على مستوى الحساب كله وكذلك لكل قاعدة توصيل، وهذا ما يجعل الأمر عمليًا: قاعدة صارمة تطابق مسار تسجيل الدخول لديك، وأخرى أكثر تساهلًا لبقية الموقع.

لماذا الحافة هي المكان الصحيح لذلك

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

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

تحديد المعدل مقابل WAF مقابل حماية DDoS

تُستخدم هذه المصطلحات الثلاثة كأنها مترادفة، وهي تؤدي أعمالًا مختلفة فعلًا.

تحديد المعدل يعدّ. فهو يعرف كم مرة يسأل العميل، ولا يعرف شيئًا عمّا يسأل عنه. وهو يوقف التخمين والكشط والقصف غير المقصود.

وWAF يفحص. فهو يقرأ الطلب ويحجب ما يبدو كحقن SQL أو برمجة عابرة للمواقع (XSS) أو ثغرة معروفة — فالطلب الخبيث الواحد يُلتقط من محاولته الأولى، مهما وصل ببطء.

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

أنت بحاجة إلى الثلاثة لأن كلًّا منها يغطي النقطة العمياء لدى الآخرين: طلب واحد ذكي يمرّره العدّاد، وألف طلب بريء المظهر لا يجد فيها WAF عيبًا، ومليون طلب لا تستطيع آلة واحدة حتى تقييمها. وعلى cdn.com.tr تنتمي كلها إلى الحافة نفسها، وتُضبَط من لوحة واحدة.

التطبيق التدريجي دون كسر أي شيء

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

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

الأسئلة الشائعة

ما هو الحدّ الابتدائي الجيد لمعدل الطلبات؟

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

هل سيحجب تحديد المعدل عملاء حقيقيين؟

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

هل يكفي تحديد المعدل لإيقاف هجوم DDoS؟

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

هل الأفضل أن أطبّق تحديد المعدل داخل تطبيقي؟

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