أعلنت Cloudflare دمج Cloudflare Gateway وData Loss Prevention مع منصة الحوسبة الطرفية Cloudflare Workers، في خطوة تنقل بوابة الويب الآمنة من نموذج القرارات الثابتة مثل السماح والحظر والعزل إلى تنفيذ كود مخصص داخل مسار تقييم السياسة الأمنية نفسه.
يتوفر هذا التكامل لخطط Zero Trust، ويقدم مسارين رئيسيين لاستدعاء Worker من سياسات Gateway: إجراء جديد باسم Forward متاح حالياً في مرحلة تجريبية عامة، وCustom Functions متوقع طرحها قبل نهاية عام 2026.
تحويل الطلبات أو تنفيذ منطق مخصص
يعمل إجراء Forward كوسيط inline للطلبات المتطابقة مع السياسة. يستقبل Worker ترويسات طلب HTTP وجسمه، ويمكنه تعديلهما قبل إرسالهما إلى الخدمة الأصلية، ثم تعديل الاستجابة قبل إعادتها إلى المستخدم. أما Gateway فتتولى اتصالات TCP وإنهاء TLS وإعادة التشفير وإدارة الشهادات والتفاوض على إصدار HTTP، ما يترك للـWorker مهمة منطق التحويل فقط.
يمكن أيضاً استخدام Forward لتنفيذ إجراءات جانبية دون تعطيل مسار الطلب، مثل إرسال تنبيه إلى Slack أو PagerDuty، تسجيل البيانات في R2، استدعاء webhook، أو تحديث مخزن KV. وتقول Cloudflare إن استدعاء Worker يتم على البنية نفسها التي تشغّل Gateway، ومن خلال استدعاء محلي لا يتطلب تمرير الحركة عبر شبكة منفصلة.
أما Custom Functions فتستدعي Worker أثناء تقييم السياسة وتعيد قيمة من نوع نص أو رقم أو قيمة منطقية. ويمكن استخدام هذه القيمة كselector في سياسات HTTP أو الشبكة. ويستطيع Worker تلقي سياق يتضمن عنوان IP المصدر، هوية المستخدم، وضع الجهاز، ترويسات HTTP وبيانات الاتصال، وفق مرحلة السياسة.
أمثلة على الاستخدام
توضح Cloudflare أن دالة مخصصة يمكنها قراءة مطالبة JWT واستخراج دور المستخدم أو مجموعته، ثم استخدام النتيجة للسماح بالوصول أو لإضافة ترويسة مثل X-App-Role إلى الطلب المتجه للخدمة الأصلية. كما يمكن بناء صفحات اعتراض تطلب من المستخدم تبرير الوصول إلى وجهة حساسة، مع حفظ الجلسة في KV وسجل التدقيق في D1 أو قاعدة بيانات داخلية عبر Hyperdrive.
تشمل الاستخدامات الأخرى فحص الملفات عبر خدمة sandbox خارجية، إرسال تنبيهات فورية عند مطابقة قاعدة DLP، وتنفيذ حسابات مخاطر تعتمد على مصادر داخلية متعددة. وتفرق Cloudflare بين المسارين بوضوح: Custom Functions مناسبة لتقييمات سريعة ومحددة وعديمة الحالة، بينما يستهدف Forward تحويل الطلبات الحية ومعالجة الطلب والاستجابة.
توسيع قدرات DLP
أعلنت Cloudflare أيضاً إتاحة دوال تحقق مخصصة لـDLP. تسمح هذه الدوال للعملاء باستخدام مصدر الحقيقة الخاص بهم للتحقق من نتيجة الكشف قبل اتخاذ قرار الإنفاذ. ومن الأمثلة التحقق مما إذا كان مفتاح GitHub المكتشف نشطاً فعلاً، بدلاً من الاكتفاء بمطابقة نمط يشبه الأسرار أو الرموز.
تستقبل دالة التحقق مقتطفاً من البيانات وموقع الجزء المطابق، ثم يمكنها استدعاء واجهة خارجية وإعادة نتيجة تتضمن درجة مطابقة أو قرار veto. وبهذا يصبح بالإمكان التمييز بين وجود نمط حساس وبين كون الحالة المحددة تمثل تسريباً فعلياً أو استخداماً غير مشروع.
ما الذي يتغير عملياً؟
تسعى Cloudflare إلى تقليل الحاجة إلى بنية وسيطة تديرها فرق الأمن، مثل مجموعات NGINX التي تُستخدم فقط لقراءة مطالبات JWT أو تعديل الترويسات. لكن المرونة الجديدة تنقل جزءاً من المسؤولية إلى كود العميل: فالتطبيقات التي تستخدم Forward يجب تصميمها بعناية حتى لا تؤثر سلباً في تجربة المستخدم، كما أن فشل Custom Function أو انتهاء مهلة تنفيذها يتطلب تحديد سلوك احتياطي مسبقاً.
تُحتسب الحركة المحالة إلى Workers كطلبات Workers عادية. وتعمل الوظائف مع Workers Free وWorkers Paid وWorkers for Enterprise، لكن الخطة المجانية تفرض حدوداً على زمن التنفيذ وعدد الطلبات اليومية. وتقول Cloudflare إن الإتاحة العامة لكلا المسارين ستكون لجميع العملاء وعلى كل أنواع الخطط، فيما تخطط لتوسيع نقاط التكامل داخل مجموعة Cloudflare One، مع Email Security كخطوة تالية.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.