افصل نشر HTTP عن تنفيذ التطبيق والبيانات الدائمة. يمكن للوكيل العكسي تنظيم التوجيه والحدود، لكن الوصول إلى الأصل وتفويض التطبيق وسعة المصدر الأعلى والاستعادة يتطلب كل منها ضوابطه الخاصة.
طلب الويب يعبر عدة مسؤوليات
يستقبل خادم الويب طلبات HTTP ويمكنه تقديم الملفات الثابتة. تنفذ عملية التطبيق السلوك الديناميكي للمشروع، مثل التحقق من حساب أو الاستعلام من قاعدة بيانات. يستقبل الوكيل العكسي الطلبات نيابة عن تلك العملية ويعيد توجيهها إلى مصدر أعلى. قد يؤدي برنامج واحد عدة أدوار، لكن فصل المسؤوليات يسهّل فهم التهيئة والاستعادة.
تتبّع طلباً واحداً من تحليل اسم المضيف إلى الاستجابة. سجّل أين ينتهي TLS، وأي عملية تختار المسار وأي مكوّن يمكنه قراءة بيانات التطبيق. افعل الشيء نفسه لطلب إداري. غالباً ما يكشف هذا التمرين عن مستمع أو اسم مضيف أُنشئ للاختبار وبقي عن طريق الخطأ قابلاً للوصول. ينبغي أن يصف المخطط المسار المنشور بدلاً من البنية التي كنت تأمل بنائها.
استخدم الحافة لتنظيم سلوك HTTP
توثّق NGINX كلاً من تقديم المحتوى الثابت وإعادة توجيه الطلبات إلى مصدر أعلى. توفر بنية العامل ووحدات HTTP آليات تهيئة، لكن تهيئة معينة لا تزال تحدد السلوك. حدّد أسماء المضيفين والمصادر الأعلى وجذور نظام الملفات عن قصد. قيّد الملفات التي يمكن تقديمها بحيث لا تصبح التهيئة وبيانات الاعتماد وبيانات المستودع الوصفية قابلة للتنزيل لمجرد وجودها بالقرب من التطبيق.
ضع حدوداً مناسبة لنصوص الطلبات والمهلات والاتصالات وفقاً للتطبيق. تعامل مع ذاكرات التخزين المؤقت كقرار بيانات: لا يمكن للمحتوى المرتبط بمستخدم أو إذن أن يرث قاعدة تخزين مؤقت مشتركة بأمان دون مراجعة. اختبر المصادقة وسلوك التخزين المؤقت معاً. احتفظ بتهيئة قابلة لإعادة الإنتاج وتحقق من التغييرات قبل إعادة تحميل الخدمة، مع مسار معروف للعودة إلى النسخة العاملة السابقة.
| الطبقة | المسؤولية المفيدة | تحقق قبل الإطلاق |
|---|---|---|
| حافة الويب العامة | TLS وتوجيه اسم المضيف وحدود HTTP | الشهادات والجذور وأسماء المضيفين المقصودة |
| عملية التطبيق | منطق الأعمال والتفويض | المصادقة وفحوص الإدخال وفشل التبعيات |
| خدمة البيانات الداخلية | حالة التطبيق الدائمة | وصول مقيّد واستعادة مختبرة |
| شبكة المزود الأعلى | خدمة الشبكة المتعاقد عليها | نطاق الحماية ومسار التصعيد |
الوكيل العكسي لا يزيل تعرض الأصل
إذا بقي الأصل قابلاً للوصول علناً، فقد يصل إليه العميل دون استخدام مسار الوكيل المقصود. قيّد الوصول إلى الأصل عبر تصميم الشبكة وتهيئة التطبيق عندما يتطلب النشر ذلك الحد. على جهاز واحد، يمكن للخادم الخلفي غالباً الاستماع على loopback أو مقبس محلي. عبر الأجهزة، استخدم مسارات مقيّدة صريحة وحماية مناسبة لاتصال المصدر الأعلى.
تحتاج الرؤوس المعاد توجيهها إلى قاعدة ثقة أيضاً. اقبل المعلومات المتعلقة بالعميل الأصلي فقط من وسطاء موثوقين، وامنع المتصلين العشوائيين من تقديم قيم يعتبرها التطبيق موثوقة. حدّد ما يظهر في سجلات الوصول وتقارير الأخطاء. يمكن للوكيل تغيير المعلومات المتاحة في كل طبقة؛ لكنه لا يمحو معرّفات الحسابات ولا يجعل التطبيق مجهولاً لدى مشغله.
طبّق قرارات الوصول داخل التطبيق
تركز بنية Zero Trust من NIST على قرارات الوصول إلى الموارد بدلاً من الثقة الضمنية القائمة على الموقع الشبكي فقط. طبّق هذا المبدأ بشكل ملموس: صادق على المتصل، وفوّض العملية المطلوبة وامنح حسابات الخدمة نطاقها المطلوب فقط. لا ينبغي أن يصبح الطلب القادم من شبكة فرعية داخلية طلب مسؤول تلقائياً.
افصل الوظائف العامة والإدارية حيثما كان ذلك عملياً. أعد التحقق من الإذن عندما يصل مستخدم إلى سجل بدلاً من الاعتماد فقط على تسجيل الدخول الأولي. أبقِ بيانات اعتماد الوكيل والتطبيق وقاعدة البيانات منفصلة. أدخل التغييرات على مراحل قابلة للاختبار، بدءاً بمسار حساس ضيق. إن تسمية نشر ما بـ Zero Trust أقل فائدة من إثبات أن إجراءً محظوراً يُرفض فعلاً في المكوّن المسؤول عنه.
خطط لرفض الخدمة على أكثر من طبقة
يفشل رابط شبكة مشبع وطلب تطبيق مكلف في موضعين مختلفين. قد يساعد تحديد المعدل عند حافة الويب في تقييد أنماط الطلبات، بينما يمكن لحدود التطبيق أن تحدد عملاً مثل عمليات البحث أو الرفع أو التصدير. توفر وحدة تحديد الطلبات في NGINX آلية واحدة؛ ويجب أن يناسب المفتاح والحدود المستخدمين الحقيقيين وأن يُختبرا لتجنب رفض حركة مرور مشروعة.
تتناول إرشادات رفض الخدمة من OWASP أيضاً استنفاد الموارد في سلوك التطبيق. ضع حدوداً زمنية وحجمية حول العمل المكلف، واستخدم طوابير محدودة وراقب إشارات الفشل. لا يمكن للضوابط المحلية إنشاء سعة في رابط مصدر أعلى مشبع بالفعل. تأكد من حماية الشبكة المحددة المضمنة في العرض المختار وجهّز مسار تصعيد. لا تفترض أبداً أن حماية الطبقة 3–4 في كتالوج تثبت أيضاً الحماية لكل حمل عمل HTTP.
اجعل الاستعادة جزءاً من النشر
تحقق من الموقع من عميل خارجي باستخدام اسم المضيف المقصود. تحقق من HTTPS وإعادات التوجيه والموارد الثابتة وعمليات تسجيل الدخول ومعاملة تطبيق تمثيلية. تأكد من بقاء المستمعين الإداريين والملفات الخاصة غير قابلة للوصول. حاكِ توقف المصدر الأعلى وتحقق من أن الحافة تعيد فشلاً مضبوطاً بدلاً من كشف تفاصيل داخلية أو الانتظار دون حد.
بالنسبة إلى Canvas، اقرأ الضوابط المتاحة داخل حساب الاستضافة. بالنسبة إلى VPS، حافظ على حافة الويب والتطبيق كجزء من خطة التشغيل الخاصة بك. منفذ الشبكة الكبير هو مواصفة سعة، وليس دليلاً على أن التطبيق يمكنه تحمل تلك الإنتاجية. أبقِ المراقبة والاستعادة وجهات اتصال المزود في دليل التشغيل. انشر فقط بعد التحقق من مسار الطلب الفعلي ومسار استعادة عملي.
قائمة التحقق العملية.
- تتبّع طلباً عاماً وطلباً إدارياً.
- حدّد الجذور المقدمة ومستمعي المصدر الأعلى.
- ثق بالرؤوس المعاد توجيهها فقط من وسطاء معتمدين.
- اختبر التفويض وحدود التخزين المؤقت.
- جهّز الحدود والتصعيد لأعطال الشبكة والتطبيق.
التفاصيل المهمة.
هل يمكن لخادم الويب أن يعمل أيضاً كوكيل عكسي؟+
نعم. NGINX مثال موثق. تعتمد أدواره على التهيئة، ولا يزال التطبيق بحاجة إلى تفويضه وصيانته الخاصة.
هل يخفي الوكيل العكسي الأصل تلقائياً؟+
لا. قد يبقى الأصل قابلاً للوصول ما لم تفرض إعدادات التوجيه وجدار الحماية والمستمع الحد المقصود.
هل سيوقف تحديد الطلبات كل هجوم DDoS؟+
لا. إنه يعالج أنماط طلبات HTTP المحددة. يتطلب تشبع الشبكة وأعطال الموارد الأخرى ضوابط مناسبة للمصدر الأعلى والتطبيق.
اذهب إلى المصدر.
تدعم هذه المراجع المفاهيم التقنية في هذا الدليل. اتبع الوثائق الحالية قبل تغيير نظام إنتاجي.
- NGINX: دليل المبتدئين nginx.org
- NGINX: تحديد طلبات HTTP nginx.org
- NIST SP 800-207: بنية Zero Trust nvlpubs.nist.gov
- OWASP: منع رفض الخدمة cheatsheetseries.owasp.org
إرشاد تحريري من SwissOctet. الأمثلة توضيحية. يجب التحقق من مواصفات الخدمة والخيارات المتاحة والشروط التعاقدية بشكل منفصل.