# افصل حافة الويب العامة عن التطبيق | SwissOctet Insights

https://swissoctet.com/arz/insights/separate-the-web-edge-from-the-app/

SwissOctet / رؤى / الويب و onion الويب و onion تطبيقي · قراءة 4 دقيقة

افصل حافة الويب العامة عن التطبيق

امنح سيرفر الويب والوكيل العكسي والتطبيق مسؤوليات متمايزة، مع وصول متعمد إلى الأصل وTLS وحدود للطلبات ومسار للحوادث.

بقلم SwissOctet Editorial احفظ الدليل انسخ الرابط

في هذه الصفحة 01 طلب الويب بيمر على مسؤوليات متعددة 02 استخدم الحافة لتنظيم سلوك HTTP 03 الـ reverse proxy مش بيشيل تعرض الـ origin 04 طبّق قرارات الوصول جوه التطبيق 05 خطّط لرفض الخدمة على أكتر من طبقة 06 خلي الاسترجاع جزء من النشر قائمتك العملية المصادر وقراءات إضافية العودة إلى المكتبة الإجابة المباشرة افصل نشر HTTP عن تنفيذ التطبيق والبيانات الدائمة. الـ reverse proxy يقدر ينظم التوجيه والحدود، لكن الوصول للـ origin وتصريح التطبيق وسعة الـ upstream والاسترجاع كل واحد منهم محتاج ضوابطه الخاصة.

01 طلب الويب بيمر على مسؤوليات متعددة

سيرفر الويب بيستقبل طلبات HTTP ويقدر يقدم ملفات ثابتة. عملية التطبيق بتنفذ السلوك الديناميكي للمشروع، زي التحقق من حساب أو الاستعلام من قاعدة بيانات. الـ reverse proxy بيستقبل الطلبات بالنيابة عن العملية دي ويوجّهها لـ upstream. برنامج واحد ممكن يؤدي أكتر من دور، لكن فصل المسؤوليات بيسهّل التفكير في الإعداد والاسترجاع.

تتبّع طلب واحد من تحليل الـ hostname لحد الرد. سجّل فين بيخلص TLS، وأنهي عملية بتختار المسار، وأنهي مكوّن يقدر يقرأ بيانات التطبيق. اعمل نفس الحاجة لطلب إداري. التمرين ده غالبًا بيكشف listener أو hostname اتعمل للاختبار وفضل بالغلط متاح. الرسم البياني المفروض يوصف المسار المنشور مش المعمارية اللي كنت بتتمنى تبنيها.

02 استخدم الحافة لتنظيم سلوك HTTP

NGINX بتوثّق تقديم المحتوى الثابت وتحويل الطلبات لـ upstream. معمارية الـ worker ووحدات HTTP بتوفر آليات إعداد، لكن الإعداد المحدد هو اللي بيحدد السلوك. حدّد الـ hostnames والـ upstreams وجذور نظام الملفات بشكل مقصود. قيّد الملفات اللي ممكن تتقدم عشان الإعداد والبيانات السرية وبيانات المستودع ما تبقاش قابلة للتنزيل لمجرد إنها موجودة جنب التطبيق.

حدّد حدود مناسبة لجسم الطلب والمهلات والاتصالات حسب التطبيق. تعامل مع الـ caches كقرار بيانات: المحتوى المرتبط بمستخدم أو صلاحية ما ينفعش يورث قاعدة تخزين مؤقت مشتركة من غير مراجعة. اختبر المصادقة وسلوك الـ cache مع بعض. حافظ على إعداد قابل للتكرار وتحقق من التغييرات قبل إعادة تحميل الخدمة، مع مسار معروف للرجوع للنسخة الشغالة السابقة.

الطبقة المسؤولية المفيدة تحقق قبل الإطلاق

حافة الويب العامة TLS وتوجيه الـ hostname وحدود HTTP الشهادات والجذور والـ hostnames المقصودة

عملية التطبيق منطق العمل والتصريح المصادقة وفحوصات المدخلات وفشل التبعيات

خدمة البيانات الداخلية حالة التطبيق الدائمة وصول مقيّد واسترجاع مختبر

شبكة مزود الـ upstream خدمة الشبكة المتعاقد عليها نطاق الحماية ومسار التصعيد

03 الـ reverse proxy مش بيشيل تعرض الـ origin

لو الـ origin فضل متاح للعامة، العميل ممكن يوصله من غير ما يستخدم مسار الـ proxy المقصود. قيّد الوصول للـ origin من خلال تصميم الشبكة وإعداد التطبيق لما النشر يتطلب الحد ده. على جهاز واحد، الـ backend غالبًا يقدر يسمع على loopback أو socket محلي. عبر الأجهزة، استخدم مسارات مقيّدة صريحة وحماية مناسبة لاتصال الـ upstream.

الـ forwarded headers محتاجة قاعدة ثقة كمان. اقبل المعلومات عن العميل الأصلي بس من وسطاء موثوقين، وامنع المتصلين العشوائيين من تقديم قيم التطبيق بيعتبرها موثوقة. حدّد إيه اللي يظهر في سجلات الوصول وتقارير الأخطاء. الـ proxy يقدر يغيّر المعلومات المتاحة في كل طبقة؛ لكنه مش بيمسح معرفات الحساب ولا بيخلي التطبيق مجهول بالنسبة لمشغّله.

04 طبّق قرارات الوصول جوه التطبيق

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

افصل الوظائف العامة والإدارية لما يكون عملي. أعد التحقق من الصلاحية لما المستخدم يوصل لسجل بدل الاعتماد على تسجيل الدخول الأولي بس. خلي بيانات اعتماد الـ proxy والتطبيق وقاعدة البيانات منفصلة. قدّم التغييرات على مراحل قابلة للاختبار، بداية من مسار حساس ضيق. تسمية النشر Zero Trust أقل فايدة من إثبات إن الفعل الممنوع فعلًا مرفوض في المكوّن المسؤول عنه.

05 خطّط لرفض الخدمة على أكتر من طبقة

رابط شبكة مشبع وطلب تطبيق مكلف بيفشلوا في أماكن مختلفة. تحديد المعدل على حافة الويب ممكن يساعد في تقييد أنماط الطلبات، بينما حدود التطبيق تقدر تحدد شغل زي البحث أو الرفع أو التصدير. وحدة تحديد الطلبات في NGINX بتوفر آلية واحدة؛ المفتاح والحدود لازم تناسب المستخدمين الحقيقيين وتتختبر عشان ما ترفضش حركة شرعية.

إرشادات رفض الخدمة بتاعة OWASP بتتناول كمان استنزاف الموارد في سلوك التطبيق. حط حدود وقت وحجم حول الشغل المكلف، استخدم طوابير محدودة، وراقب إشارات الفشل. الضوابط المحلية ما تقدرش تخلق سعة في رابط upstream مشبع أصلًا. اتأكد من حماية الشبكة المحددة المضمنة في العرض المختار وجهّز مسار تصعيد. ما تفترضش أبدًا إن حماية Layer 3–4 في الكتالوج بتثبت كمان حماية كل workload HTTP.

06 خلي الاسترجاع جزء من النشر

افحص الموقع من عميل خارجي باستخدام الـ 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. الأمثلة توضيحية. يجب التحقق من مواصفات الخدمة والخيارات المتاحة والشروط التعاقدية بشكل منفصل.

اربط المعرفة بنية تحتية ذات صلة.

Canvas Web سويسرا Vector VPS سويسرا Pulse NVMe سويسرا Transit 40 سويسرا

احتفظ بالخيط ملاحظاتك الميدانية التالية.

استكشف كل الأدلة

ملاحظة ميدانية / 01

+

عمليات اليوم الثاني تطبيقي

خط أساس لتقوية Linux VPS يمكنك الحفاظ عليه

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

6 دقيقة قراءة اقرأ الدليل

ملاحظة ميدانية / 02

+

الويب و onion الأساس

استضافة الويب أو VPS: اختر العمل الذي تريد توليه

قارن متطلبات التطبيق والتحكم ومسؤوليات الصيانة بدلًا من اعتبار VPS الخطوة التالية التلقائية لكل موقع.

6 دقيقة قراءة اقرأ الدليل

ملاحظة ميدانية / 03

+

الويب و onion تطبيقي

دليل تحويل دومين وDNS وTLS لسيرفر جديد

جهّز توجيه اسم المضيف والشهادات والرجوع مع بعض عشان الترحيل يغيّر السيرفر من غير ما يكسر هوية الموقع أو الاتصالات الآمنة.

قراءة 4 دقيقة اقرأ الدليل