Cloudflare Zero Trust: دليل لأمان الوصول في المؤسسات

تعد الهجرة إلى Cloudflare Zero Trust خطوة تحديث بالغة الأهمية للمؤسسات التي تتطلع إلى استبدال شبكات VPN القديمة للشركات في عام 2026. وتمنح شبكات VPN التقليدية المستخدمين وصولاً واسعًا إلى الشبكة الفرعية الكاملة للشركة بمجرد تجاوزهم شاشة تسجيل الدخول الأولية؛ مما يعني أن سرقة بيانات اعتماد موظف واحد تمكن المهاجمين من التسلل مباشرة إلى خوادم قواعد البيانات الحساسة. وعلى النقيض من ذلك، يقوم نموذج أمان Zero Trust بتقييم عمليات التحقق من التفويض لكل طلب وصول إلى التطبيق، مما يحظر حركة المرور غير المؤكدة بشكل افتراضي. يستعرض هذا الدليل مراحل التهيئة، وإعداد الأنفاق الآمنة، وتحديد السياسات المستخدمة لبناء بيئة Zero Trust.

[!WARNING] تحذير بشأن قيود شبكات VPN: تعرض إعدادات VPN التقليدية شبكاتك الداخلية لهجمات الحركة الجانبية (lateral movement). ويضمن الترقية إلى مسارات وصول يتم التحقق منها عند الحافة (edge-verified) بقاء قاعدة بياناتك معزولة حتى لو تم اختراق الجهاز المحمول الخاص بالموظف محليًا.

النقاط الرئيسية:

• يستخدم Cloudflare Zero Trust سياسات الوصول عند الحافة لتقييم هويات المستخدمين وفحوصات سلامة الأجهزة.
• تؤمن أنفاق Cloudflare Tunnels الخفيفة منافذ الخادم دون فتح تكوينات جدار الحماية الواردة.
• تدعم السياسات القياسية عمليات الدمج مع موفري الهوية (مثل Google Workspace أو Okta).
• يتحقق فحص الأجهزة من تشفير القرص وحالة برنامج مكافحة الفيروسات قبل السماح بالوصول إلى قاعدة البيانات.

الركائز الأساسية لإعداد Cloudflare Zero Trust

تعتمد بنية الأمان الاحترافية على التحقق المستمر من المستخدمين وأجهزتهم. وكما تصف وثائق Cloudflare One، تُقيَّم سياسات الوصول عند الحافة في كل طلب — قريبًا من المستخدم بدلاً من مُركِّز VPN مركزي. ويعتمد الإعداد على ثلاث ركائز أمنية متميزة لتأمين الوصول إلى قاعدة البيانات:

1. Cloudflare Access (التحقق من الهوية)

يعمل Cloudflare Access كوسيط هوية أصلي عند الحافة. وبناءً على ذلك، يجب عليك تكوين ثلاث قواعد أساسية:

• مزامنة موفر الهوية: اربط دليل شركتك (مثل Okta أو Microsoft Entra ID أو Google Workspace) مباشرة بالحافة.
• سياسات الوصول: قم ببناء قواعد دقيقة بناءً على نطاقات البريد الإلكتروني، والمواقع الجغرافية، وحالات المصادقة متعددة العوامل (MFA)؛ مما يساهم في تصفية الطلبات الضارة.
• الإلغاء الفوري: يؤدي إلغاء تنشيط ملف تعريف المستخدم في دليلك المركزي إلى إنهاء جلسات الحافة الخاصة به على الفور في جميع أنحاء العالم، مما يؤمن نقاط دخول النظام.

2. Cloudflare Tunnel (موصل cloudflared)

تتطلب البنية التحتية التقليدية فتح منفذ الخادم 80 أو 443 للإنترنت العام، مما يعرض الخدمات لشبكات البوتات التي تقوم بمسح المنافذ.

• اتصالات صادرة فقط: يعمل برنامج خادم خفيف (cloudflared) على خادمك الأصلي، لإنشاء اتصالات صادرة فقط إلى حافة Cloudflare.
• لا توجد منافذ واردة مفتوحة: وبالتالي، يمكنك إغلاق جميع المنافذ الواردة على جدار الحماية المحلي لديك، مما يجعل خادمك غير مرئي لعمليات المسح عبر الإنترنت العام.

3. فحص حالة الأجهزة (عميل WARP)

لحماية قواعد البيانات الحساسة من الإصابة بالبرامج الضارة، يجب على الحافة التحقق من سلامة الأجهزة. لذلك، يقوم عميل WARP بإجراء ثلاث عمليات تحقق من حالة الجهاز:

• التحقق من مكافحة الفيروسات: التأكد من أن الجهاز المحمول الخاص بالمستخدم يقوم بتشغيل برنامج أمان نشط قبل منح الوصول، مما يمنع تشغيل البرامج الضارة.
• التحقق من تحديثات نظام التشغيل: تقييد الوصول إذا كان جهاز الموظف يقوم بتشغيل أنظمة تشغيل قديمة تفتقر إلى تحديثات الأمان الهامة، مما يقلل من مخاطر استغلال البرامج الثابتة.
• التحقق من تشفير القرص: التحقق من أن تشفير FileVault أو BitLocker نشط على جهاز العميل، مما يمنع تسرب البيانات من الأجهزة المفقودة.

خطوات النشر للشركات

تتبع عملية الانتقال السلسة التي تتجنب تعطيل سير العمل اليومي تسلسل التنفيذ التالي:

1. تأسيس تكامل الهوية: قم بمزامنة دليل البريد الإلكتروني لشركتك مع لوحة تحكم Cloudflare.
2. نشر أنفاق Cloudflare Tunnels: قم بتثبيت موصل cloudflared على خوادم التطوير والإنتاج المستهدفة.
3. صياغة سياسات وصول دقيقة: قم بتهيئة قواعد الوصول التي تقيد لوحات تحكم الإدارة لرسائل بريد إلكتروني محددة للمطورين.
4. توزيع عميل WARP: استخدم أدوات إدارة الأجهزة لتثبيت عميل الحافة على جميع الأجهزة المحمولة للشركة، مما يتيح فحوصات حالة الأجهزة.

مقارنة تقنية: VPN التقليدي مقابل Zero Trust

يوضح تقييم مقاييس التشغيل سبب انتقال المؤسسات إلى بنيات الأمان الأصلية عند الحافة:

المتطلبات الأساسية قبل البدء

قبل تهيئة أي إعداد، تأكد من توفر العناصر أدناه؛ حيث يمثل غياب أحد المتطلبات السبب الأكثر شيوعًا لتوقف عملية النشر في منتصف الطريق.

• حساب Cloudflare مع تمكين Zero Trust. تغطي الخطة المجانية ما يصل إلى 50 مستخدمًا، وهو أمر كافٍ تمامًا للمشروع التجريبي. قم بتدوين نطاق فريقك (مثلاً، your-org.cloudflareaccess.com).
• نطاق تم إعداده بالفعل على Cloudflare. يجب أن يقع كل اسم مضيف عام تنوي حمايته (مثل app.example.com) على منطقة تستخدم خوادم أسماء Cloudflare، بحيث يمكن إنشاء سجلات DNS تلقائيًا.
• وصول مسؤول إلى موفر الهوية (IdP). ستقوم بتسجيل Cloudflare كتطبيق SAML أو OIDC في Okta أو Microsoft Entra ID أو Google Workspace.
• وصول مسؤول (root أو sudo) على كل خادم أصلي يقوم بتشغيل موصل cloudflared.
• جرد سريع للتطبيقات. ضع قائمة بكل خدمة داخلية، وعنوانها ومنفذها المحلي، ومن يجب أن يصل إليها؛ حيث تصبح هذه القائمة خريطة السياسات الخاصة بك.

خطوة بخطوة: تهيئة Cloudflare Access ونفق آمن

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

1. تثبيت cloudflared والمصادقة عليه

قم بتثبيت الموصل على خادمك الأصلي، ثم قم بالمصادقة عليه باستخدام حسابك. يفتح أمر تسجيل الدخول نافذة متصفح حيث يمكنك تفويض المنطقة.

1# Debian / Ubuntu
2curl -L https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb -o cloudflared.deb
3sudo dpkg -i cloudflared.deb
4
5# Authenticate — writes a cert.pem to ~/.cloudflared/
6cloudflared tunnel login

2. إنشاء النفق وبيانات اعتماده

ينتج عن إنشاء النفق معرف UUID ويقوم بكتابة ملف بيانات اعتماد مطابق في ~/.cloudflared/. حافظ على سرية هذا الملف؛ فهو يمثل هوية الموصل.

1cloudflared tunnel create enterprise-apps
2# Created tunnel enterprise-apps with id 6ff42ae2-765d-4adf-8112-31c55c1551ef

3. تحديد قواعد ingress في ملف config.yml

تربط قائمة ingress كل اسم مضيف عام بخدمة خاصة خلف جدار الحماية.

 1tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef
 2credentials-file: /root/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json
 3
 4ingress:
 5  # Internal admin console
 6  - hostname: db-admin.example.com
 7    service: http://localhost:9000
 8  # Internal web app
 9  - hostname: app.example.com
10    service: http://localhost:8080
11  # Catch-all — required as the final rule
12  - service: http_status:404

تعد قاعدة catch-all العامة في النهاية إلزامية؛ حيث يرفض برنامج cloudflared البدء بدونها.

4. توجيه DNS وتشغيل النفق كخدمة نظام

1# Create a proxied CNAME for each hostname
2cloudflared tunnel route dns enterprise-apps db-admin.example.com
3cloudflared tunnel route dns enterprise-apps app.example.com
4
5# Install as a persistent system service so it survives reboots
6sudo cloudflared service install
7sudo systemctl enable --now cloudflared

لا يحتوي خادمك الأصلي الآن على منافذ واردة مفتوحة، ومع ذلك يتم توجيه كلا الاسمين عبر الحافة.

5. إنشاء تطبيق وصول ذاتي واستضافة سياسة أمنية

مع تنشيط النفق، ضع سياسة وصول (Access Policy) أمام كل اسم مضيف. يوضح كود Terraform أدناه كيفية تقييد لوحة الإشراف لمجموعة محددة ويتطلب التحقق من سلامة الأجهزة.

 1resource "cloudflare_zero_trust_access_application" "db_admin" {
 2  zone_id          = var.zone_id
 3  name             = "Database Admin Console"
 4  domain           = "db-admin.example.com"
 5  session_duration = "30m"
 6}
 7
 8resource "cloudflare_zero_trust_access_policy" "db_admin_engineers" {
 9  application_id = cloudflare_zero_trust_access_application.db_admin.id
10  zone_id        = var.zone_id
11  name           = "Engineers with healthy devices"
12  precedence     = 1
13  decision       = "allow"
14
15  include {
16    group = [var.engineering_group_id]
17  }
18
19  require {
20    device_posture = [cloudflare_zero_trust_device_posture_rule.disk_encryption.id]
21  }
22}

تحدد كتلة include من يحق له محاولة الوصول؛ وتضيف كتلة require الشروط الواجب توفرها في الجميع، وبالتالي يتم رفض مهندس مصرح له إذا كان يستخدم جهازًا غير مشفر.

6. تسجيل الأجهزة في WARP وإضافة قواعد فحص حالة الأجهزة

لا يعمل فحص الأجهزة إلا بعد تسجيل عميل WARP لصالح فريقك؛ حيث تتحقق القاعدة المذكورة أعلاه من نشاط تشفير القرص قبل منح الوصول.

 1resource "cloudflare_zero_trust_device_posture_rule" "disk_encryption" {
 2  account_id = var.account_id
 3  name       = "Disk encryption required"
 4  type       = "disk_encryption"
 5
 6  match {
 7    platform = "windows"
 8  }
 9
10  input {
11    require_all = true
12  }
13}

قم بنشر عميل WARP عبر نظام إدارة الأجهزة الخاص بك (مثل Intune أو Jamf أو Kandji) مع تعبئة اسم المؤسسة مسبقًا، ليتلقى الموظفون الترخيص تلقائيًا في الخلفية.

قائمة مرجعية للهجرة من VPN إلى Zero Trust

تحافظ الهجرة المتوازية على إتاحة شبكة VPN القديمة بينما تقوم بنقل التطبيقات واحدًا تلو الآخر؛ مما يقلل من احتمالية حدوث أعطال ويوفر لك مسار تراجع آمن في كل خطوة.

أخطاء شائعة واستكشاف الأخطاء وإصلاحها

• الخطأ 1033 (Tunnel error): يتم توجيه اسم المضيف ولكن لا يوجد موصل قيد التشغيل، أو أن سجل DNS يشير إلى نفق خاطئ. تحقق من حالة systemctl status cloudflared وتأكد من مطابقة سجل CNAME لمعرف نفقك.
• الموصل لا يبدأ: يجب أن تنتهي كل قائمة ingress بقاعدة service: افتراضية مثل http_status:404؛ وبدونها تفشل عملية التحقق من التهيئة قبل بدء تشغيل الخدمة.
• المستخدمون يصلون إلى الخادم الأصلي مباشرة متجاوزين Access: تحمي خدمة Access اسم المضيف وليس عنوان IP العام مباشرة. يحافظ النفق على إغلاق المنافذ الواردة، لذا تأكد من عدم وجود سجلات DNS عامة أو منافذ مفتوحة تعرض الخادم مباشرة.
• حظر الوصول إلى تطبيق الإشراف الخاص بك: قم دائمًا بإنشاء سياسة تسمح بالوصول لحساب طوارئ بديل قبل تحويل أي سياسة من وضع التقرير فقط إلى وضع الفرض الصارم.
• فحوصات حالة الأجهزة تفشل باستمرار: يتطلب فحص حالة الأجهزة تشغيل عميل WARP في وضع Zero Trust وليس وضع DNS فقط. تأكد من تسجيل كل جهاز تحت اسم الفريق الصحيح.

الاختبار والنشر التدريجي

تأكد من صحة كل سياسة أمنية قبل فرضها على حركة المرور الفعلية.

• استخدم أداة اختبار السياسات: يحاكي برنامج اختبار سياسات Access طلب مستخدم معين ويعرض أسباب السماح أو الرفض دون الانتظار لطلب فعلي.
• ابدأ بوضع التقرير فقط (report-only): يمكن للسياسات الجديدة وقواعد فحص الأجهزة تسجيل نتائجها دون فرضها فعليًا، مما يتيح لك اكتشاف الحظر الخاطئ قبل استبعاد أي مستخدم بشكل حقيقي.
• قراءة سجلات القرارات: تسجل لوحة تحكم Zero Trust كل قرار وصول مع الهوية والجهاز والسياسة المطبقة؛ وهو ما يمثل أسرع طريقة لمعرفة أسباب الحظر.
• حافظ على خيار التراجع متاحًا: اترك شبكة VPN متاحة للمجموعة التجريبية حتى يمر أسبوع عمل كامل دون أي مشاكل وصول، ثم قم بإيقاف تشغيلها وفقًا للقائمة المرجعية أعلاه.

شراكة مع استشارات أمنية معتمدة

يضمن النشر المدروس حماية الأصول الرقمية لشركتك. تقدم شركة Mecanik خدمات تدقيق أمان الخادم الاحترافية وحماية متقدمة للشبكات من خلال صفحة خدمات اختبار الاختراق . نحن متخصصون في إعداد أنفاق Cloudflare وسياسات الوصول إلى Zero Trust وتكامل SSO للمؤسسات. اتصل بنا اليوم لتحديد موعد ورشة عمل تقنية.

الأسئلة الشائعة (FAQ)

ما هو Cloudflare Zero Trust؟ برنامج Cloudflare Zero Trust هو منصة أمنية للمؤسسات تحل محل شبكات VPN التقليدية للشركات. ويتحقق باستمرار من هوية وسلامة جهاز كل مستخدم يطلب الوصول إلى التطبيقات الداخلية، مع فرض مبدأ عدم الثقة الافتراضية بأي مستخدم أو جهاز.

كيف تحمي أنفاق Cloudflare Tunnels الخوادم الخاصة؟ تنشئ أنفاق Cloudflare Tunnels اتصالاً آمنًا وصادرًا فقط بين خادمك الخاص وشبكة حافة Cloudflare. وبالتالي، يمكنك إغلاق جميع منافذ جدار الحماية الواردة، مما يجعل موارد خادمك غير مرئية لعمليات مسح المنافذ الضارة.

هل يمكنني دمج Zero Trust مع موفر الهوية الحالي لدي؟ نعم، تتكامل المنصة مع موفري الهوية القياسيين (بما في ذلك Google Workspace و Okta و Microsoft Entra ID (Azure AD سابقًا)). ويسمح لك هذا الإعداد بفرض تسجيل الدخول الموحد (SSO) وإدارة أذونات المستخدمين من لوحة تحكم مركزية.

ما هي فحوصات حالة الأجهزة في Cloudflare Access؟ فحوصات حالة الأجهزة (device posture checks) هي متطلبات أمنية يجب أن يستوفيها جهاز المستخدم قبل الوصول إلى التطبيقات؛ مثل التحقق من تشغيل برنامج مكافحة فيروسات نشط، وتفعيل تشفير القرص، واستخدام إصدارات نظام تشغيل محدثة.

ما هي تكلفة Cloudflare Zero Trust للشركات؟ تقدم Cloudflare خطة مجانية تغطي ما يصل إلى 50 مستخدمًا وتتضمن سياسات Access والأنفاق الأساسية. وبالنسبة للمؤسسات الكبيرة أو قواعد فحص الأجهزة المتقدمة، تعتمد الفواتير على اشتراك شهري لكل مستخدم.