افصل نشر HTTP عن تنفيذ التطبيق والبيانات الدائمة. الـ reverse proxy يقدر ينظم التوجيه والحدود، لكن الوصول للـ origin وتصريح التطبيق وسعة الـ upstream والاسترجاع كل واحد منهم محتاج ضوابطه الخاصة.
طلب الويب بيمر على مسؤوليات متعددة
سيرفر الويب بيستقبل طلبات HTTP ويقدر يقدم ملفات ثابتة. عملية التطبيق بتنفذ السلوك الديناميكي للمشروع، زي التحقق من حساب أو الاستعلام من قاعدة بيانات. الـ reverse proxy بيستقبل الطلبات بالنيابة عن العملية دي ويوجّهها لـ upstream. برنامج واحد ممكن يؤدي أكتر من دور، لكن فصل المسؤوليات بيسهّل التفكير في الإعداد والاسترجاع.
تتبّع طلب واحد من تحليل الـ hostname لحد الرد. سجّل فين بيخلص TLS، وأنهي عملية بتختار المسار، وأنهي مكوّن يقدر يقرأ بيانات التطبيق. اعمل نفس الحاجة لطلب إداري. التمرين ده غالبًا بيكشف listener أو hostname اتعمل للاختبار وفضل بالغلط متاح. الرسم البياني المفروض يوصف المسار المنشور مش المعمارية اللي كنت بتتمنى تبنيها.
استخدم الحافة لتنظيم سلوك HTTP
NGINX بتوثّق تقديم المحتوى الثابت وتحويل الطلبات لـ upstream. معمارية الـ worker ووحدات HTTP بتوفر آليات إعداد، لكن الإعداد المحدد هو اللي بيحدد السلوك. حدّد الـ hostnames والـ upstreams وجذور نظام الملفات بشكل مقصود. قيّد الملفات اللي ممكن تتقدم عشان الإعداد والبيانات السرية وبيانات المستودع ما تبقاش قابلة للتنزيل لمجرد إنها موجودة جنب التطبيق.
حدّد حدود مناسبة لجسم الطلب والمهلات والاتصالات حسب التطبيق. تعامل مع الـ caches كقرار بيانات: المحتوى المرتبط بمستخدم أو صلاحية ما ينفعش يورث قاعدة تخزين مؤقت مشتركة من غير مراجعة. اختبر المصادقة وسلوك الـ cache مع بعض. حافظ على إعداد قابل للتكرار وتحقق من التغييرات قبل إعادة تحميل الخدمة، مع مسار معروف للرجوع للنسخة الشغالة السابقة.
| الطبقة | المسؤولية المفيدة | تحقق قبل الإطلاق |
|---|---|---|
| حافة الويب العامة | TLS وتوجيه الـ hostname وحدود HTTP | الشهادات والجذور والـ hostnames المقصودة |
| عملية التطبيق | منطق العمل والتصريح | المصادقة وفحوصات المدخلات وفشل التبعيات |
| خدمة البيانات الداخلية | حالة التطبيق الدائمة | وصول مقيّد واسترجاع مختبر |
| شبكة مزود الـ upstream | خدمة الشبكة المتعاقد عليها | نطاق الحماية ومسار التصعيد |
الـ reverse proxy مش بيشيل تعرض الـ origin
لو الـ origin فضل متاح للعامة، العميل ممكن يوصله من غير ما يستخدم مسار الـ proxy المقصود. قيّد الوصول للـ origin من خلال تصميم الشبكة وإعداد التطبيق لما النشر يتطلب الحد ده. على جهاز واحد، الـ backend غالبًا يقدر يسمع على loopback أو socket محلي. عبر الأجهزة، استخدم مسارات مقيّدة صريحة وحماية مناسبة لاتصال الـ upstream.
الـ forwarded headers محتاجة قاعدة ثقة كمان. اقبل المعلومات عن العميل الأصلي بس من وسطاء موثوقين، وامنع المتصلين العشوائيين من تقديم قيم التطبيق بيعتبرها موثوقة. حدّد إيه اللي يظهر في سجلات الوصول وتقارير الأخطاء. الـ proxy يقدر يغيّر المعلومات المتاحة في كل طبقة؛ لكنه مش بيمسح معرفات الحساب ولا بيخلي التطبيق مجهول بالنسبة لمشغّله.
طبّق قرارات الوصول جوه التطبيق
معمارية Zero Trust بتاعة NIST بتركز على قرارات الوصول للموارد بدل الثقة الضمنية المبنية على موقع الشبكة بس. طبّق المبدأ ده بشكل ملموس: صادق المتصل، وصرّح العملية المطلوبة، وادي حسابات الخدمة النطاق المطلوب بس. الطلب اللي جاي من subnet داخلي ما ينفعش يتحول تلقائيًا لطلب مسؤول.
افصل الوظائف العامة والإدارية لما يكون عملي. أعد التحقق من الصلاحية لما المستخدم يوصل لسجل بدل الاعتماد على تسجيل الدخول الأولي بس. خلي بيانات اعتماد الـ proxy والتطبيق وقاعدة البيانات منفصلة. قدّم التغييرات على مراحل قابلة للاختبار، بداية من مسار حساس ضيق. تسمية النشر Zero Trust أقل فايدة من إثبات إن الفعل الممنوع فعلًا مرفوض في المكوّن المسؤول عنه.
خطّط لرفض الخدمة على أكتر من طبقة
رابط شبكة مشبع وطلب تطبيق مكلف بيفشلوا في أماكن مختلفة. تحديد المعدل على حافة الويب ممكن يساعد في تقييد أنماط الطلبات، بينما حدود التطبيق تقدر تحدد شغل زي البحث أو الرفع أو التصدير. وحدة تحديد الطلبات في NGINX بتوفر آلية واحدة؛ المفتاح والحدود لازم تناسب المستخدمين الحقيقيين وتتختبر عشان ما ترفضش حركة شرعية.
إرشادات رفض الخدمة بتاعة OWASP بتتناول كمان استنزاف الموارد في سلوك التطبيق. حط حدود وقت وحجم حول الشغل المكلف، استخدم طوابير محدودة، وراقب إشارات الفشل. الضوابط المحلية ما تقدرش تخلق سعة في رابط upstream مشبع أصلًا. اتأكد من حماية الشبكة المحددة المضمنة في العرض المختار وجهّز مسار تصعيد. ما تفترضش أبدًا إن حماية Layer 3–4 في الكتالوج بتثبت كمان حماية كل workload HTTP.
خلي الاسترجاع جزء من النشر
افحص الموقع من عميل خارجي باستخدام الـ hostname المقصود. تحقق من HTTPS والتحويلات والموارد الثابتة وتسجيلات الدخول ومعاملة تطبيق تمثيلية. اتأكد إن الـ listeners الإدارية والملفات الخاصة فضلت غير متاحة. حاكي توقف الـ upstream وتحقق إن الحافة بترجع فشل متحكم فيه بدل ما تكشف تفاصيل داخلية أو تستنى من غير حد.
بالنسبة لـ Canvas، اقرأ الضوابط المتاحة جوه حساب الاستضافة. بالنسبة لـ VPS، حافظ على حافة الويب والتطبيق كجزء من خطة التشغيل بتاعتك. منفذ الشبكة الكبير هو مواصفة سعة، مش إثبات إن التطبيق يقدر يستحمل معدل النقل ده. خلي المراقبة والاسترجاع وجهات اتصال المزود في الـ runbook. انشر بس بعد ما يتم التحقق من مسار الطلب الفعلي ومسار استرجاع عملي.
قائمتك العملية.
- تتبّع طلب عام وطلب إداري.
- حدّد الجذور المقدمة وlisteners الـ upstream.
- اثق في الـ forwarded headers بس من وسطاء معتمدين.
- اختبر التصريح وحدود الـ cache.
- جهّز حدود وتصعيد لفشل الشبكة والتطبيق.
التفاصيل اللي تفرق.
سيرفر الويب يقدر يعمل كـ reverse proxy كمان؟+
أيوه. NGINX مثال موثق واحد. أدوارها بتعتمد على الإعداد، والتطبيق لسه محتاج تصريحه وصيانته الخاصة.
الـ reverse proxy بيخفي الـ origin تلقائيًا؟+
لأ. الـ origin ممكن يفضل متاح إلا لو إعدادات التوجيه والفايروول والـ listener فرضت الحد المقصود.
تحديد الطلبات هيوقف كل هجوم DDoS؟+
لأ. هو بيتناول أنماط طلبات HTTP مختارة. إشباع الشبكة وفشل الموارد التانية محتاجين ضوابط upstream وتطبيق مناسبة.
اذهب إلى المصدر.
تدعم هذه المراجع المفاهيم التقنية في هذا الدليل. اتبع الوثائق الحالية قبل تغيير نظام إنتاجي.
- NGINX: دليل المبتدئين nginx.org
- NGINX: تحديد طلبات HTTP nginx.org
- NIST SP 800-207: معمارية Zero Trust nvlpubs.nist.gov
- OWASP: منع رفض الخدمة cheatsheetseries.owasp.org
إرشاد تحريري من SwissOctet. الأمثلة توضيحية. يجب التحقق من مواصفات الخدمة والخيارات المتاحة والشروط التعاقدية بشكل منفصل.