Cloudflare توسع حماية تطبيقات الويب إلى المنشآت الخاصة

أعلنت Cloudflare اليوم عن الإتاحة العامة لخدماتها للمنشآت الخاصة (private origins)، وهي خطوة مهمة تتيح للمطورين والشركات حماية تطبيقاتهم وخدماتهم الداخلية بنفس مستوى الأمان والأداء الذي توفره Cloudflare لأصولهم الموجهة للجمهور. لم تعد هناك حاجة لتعريض عنوان IP الخاص بالمنشأ للإنترنت، حيث يمكن الآن توجيه سجل DNS الوكيل (proxied DNS record) إلى عنوان IP خاص، وستصل Cloudflare إلى هذا المنشأ عبر اتصال Cloudflare One الحالي الخاص بك.

لماذا هذا التوسع مهم؟

كنا نسمع دائمًا من العملاء عن مشكلة تواجههم: تطبيقاتهم الداخلية، واجهات برمجة التطبيقات (APIs)، الخلفيات الخاصة بوكلاء الذكاء الاصطناعي (AI agent backends)، وخوادم MCP، وأدوات التشغيل، لم تُبنَ لتواجه الإنترنت مباشرةً. ومع ذلك، تحتاج هذه الخدمات إلى قبول الطلبات من الشركاء أو العملاء أو الوكلاء عبر الإنترنت. قبل هذه الميزة، كان وضع Cloudflare أمام هذه الخدمات يتطلب إما كشف عنوان IP عام، أو فتح منفذ جدار حماية، أو تشغيل cloudflared بجانب المنشأ. هذه المتطلبات كانت غالبًا ما تترك التطبيقات الخاصة دون نفس الحماية والتحكم المستخدمة للتطبيقات العامة.

• WAF (جدار حماية تطبيقات الويب) والقواعد المُدارة
• إدارة الروبوتات (Bot management)
• تحديد المعدل (Rate limiting)
• التخزين المؤقت (Caching)
• قواعد التحويل وإعادة الكتابة (Transform and rewrite rules)
• Workers

كيف تعمل هذه الميزة؟

الأمر بسيط للغاية. ما عليك سوى إنشاء سجل A أو AAAA وكيل (proxied A or AAAA record) يشير إلى عنوان IP الخاص بمنشأك. بالنسبة لنطاقات IP الخاصة المدعومة، يتم تمكين خيار «استخدام توجيه الشبكة الخاصة» (Use private network routing) تلقائيًا. هذا ينطبق على عناوين IPv4 الخاصة بـ RFC 1918، وعناوين CGNAT بـ RFC 6598 (100.64.0.0/10)، وعناوين IPv6 المحلية الفريدة بـ RFC 4193 (fc00::/7).

تظل بقية دورة الطلب كما هي: إنهاء TLS، وWAF، والقواعد، والتخزين المؤقت تستمر في العمل على شبكة Cloudflare. بالنسبة للعملاء الذين يقومون بأتمتة عمليات النشر عبر الـAPI، فإن التوجيه الخاص هو مجرد خاصية إضافية في سجل DNS القياسي، مع إضافة «private_routing»: true. عندما يرى وكيل Cloudflare هذه الإشارة، فإنه بدلاً من محاولة الاتصال مباشرة بعنوان IP الخاص عبر الإنترنت العام، يسلم الطلب إلى طبقة الشبكة الخاصة التي تقوم بتوجيه الاتصال عبر اتصال الشبكة الخاص الحالي للعميل.

ما الذي يعنيه هذا للمطورين؟

بالنسبة للمطورين ومصممي المنتجات، هذا يعني تبسيطًا كبيرًا لكيفية تأمين ونشر تطبيقات وخدمات المؤسسة الداخلية. لم تعد هناك مقايضات بين الأمان والأداء لأصولك الخاصة. يمكنك الآن تطبيق نفس سياسات الحماية من WAF، وإدارة الروبوتات، والتخزين المؤقت على الأنظمة الخلفية لوكلاء AI، أو واجهات API الداخلية، أو أدوات التشغيل دون الحاجة إلى إعادة تصميمها لتواجه الإنترنت العام، أو القلق بشأن تعريض عناوين IP الخاصة. هذا يوفر وقتًا وجهدًا كبيرين في إدارة البنية التحتية ويسمح بالتركيز على تطوير الميزات الأساسية.

نرى أن هذه الخطوة تعزز من مرونة البنية التحتية الهجينة وتجعل Cloudflare حلاً أكثر شمولية. وتعمل Cloudflare بالفعل على الخطوة التالية، وهي دعم حركة المرور من الشبكات الخاصة إلى الشبكات الخاصة (private-to-private traffic)، مع خطة لإطلاق نسخة تجريبية مغلقة في أوائل عام 2027. هذا يعني أن المستخدمين والخدمات ووكلاء الذكاء الاصطناعي على الشبكات الخاصة سيتمكنون من الوصول إلى التطبيقات على شبكات خاصة أخرى عبر خدمات تطبيقات Cloudflare.

المصدر: blog.cloudflare.com