عمال وصفحات كلاودفلير ليس لديها أي تحكم في الوصول لكل مورد — ولا يوجد حل بديل حقيقي | Evolving Cyber Blog

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

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

هذه ليست حالة حافة متخصصة. أي فريق يدير أكثر من مشروع واحد لـ Worker أو Pages — مع أكثر من مطور واحد أو خط أنابيب CI/CD واحد — يتأثر بهذه الفجوة.

المشكلة: كل شيء على مستوى الحساب

في نموذج الأذونات الخاص بـ Cloudflare، يُعد كل من Workers وPages موارد على مستوى الحساب. عندما تمنح أي دور أو رمز وصول إلى Workers أو Pages، ينطبق هذا الوصول على كل Worker وكل مشروع Pages في الحساب — لا يوجد فلتر للموارد على مستوى Worker الفردي أو المشروع.

أدوار الأعضاء

عندما تضيف عضوًا إلى الفريق وتعيّنه دور "مشرف عمال Cloudflare"، يمكنه قراءة وكتابة وحذف كل عامل في حسابك. ينطبق نفس الشيء على الصفحات — فالعضو الذي لديه حق الوصول إلى الصفحات يمكنه الوصول إلى جميع مشاريع الصفحات، دون وجود طريقة لتقييده بمشروع واحد فقط. لا توجد آلية تقول "يمكن لهذا المطور الوصول فقط إلى worker-payments" أو "يمكن لهذا المطور النشر فقط في مشروع الصفحات الخاص بالتسويق." كلا الدورين ينطبقا على مستوى الحساب بأكمله، وهذه هي الخيار الوحيد المتاح.

لدى كلاودفلير ميزة تُسمى الأدوار محددة النطاق، والتي تتيح لك تقييد وصول عضو إلى مناطق محددة. هذا يبدو ذا صلة — لكنه ليس كذلك. تنطبق الأدوار محددة النطاق حصريًا على موارد مستوى المنطقة: DNS، SSL، قواعد الجدار الناري، قواعد الصفحات. العمال والصفحات هي موارد على مستوى الحساب وتقع بالكامل خارج نظام تحديد نطاق المجال. إعطاء دور محدد النطاق لا يعطي أي تقييد على العمال أو الصفحات. عضو لديه دور مدير العمال مخصص فقط لمنطقة الإنتاج الخاصة بك لا يزال يمتلك صلاحية مدير العمال — بالإضافة إلى الوصول للصفحات — عبر كامل حسابك.

الأدوار المقتصرة على النطاق لا تنطبق على العمال أو الصفحات. إنها لا تقدم أي حل لهذه المشكلة — لا شيء.

رموز ### API

رموز واجهة برمجة التطبيقات (API) هي الطريقة التي تستخدمها خطوط CI/CD للمصادقة لنشر العمال عبر Wrangler ومشاريع Pages عبر واجهة برمجة تطبيقات Cloudflare أو wrangler pages deploy. عندما تقوم بإنشاء رمز بصلاحية "تحرير نصوص العمال"، يمكنه قراءة وكتابة وحذف أي عامل في حسابك. عندما تقوم بإنشاء رمز بصلاحية "تحرير صفحات Cloudflare"، يمكنه قراءة وكتابة وحذف أي مشروع صفحات في حسابك. كلا الصلاحيتين لا تقبلان تصفية الموارد على مستوى العامل الفردي أو المشروع.

تعترف وثائق كلودفلير الخاصة بنشر CI/CD بهذا مباشرة، وتنصح المطورين بـ "تحديد نطاق الرمز المميز الخاص بك" وتقيده بحساب محدد — لكن أفضل مستوى من التحديد المتاح هو على مستوى الحساب. يمكنك تقييد الرمز المميز ليقتصر على حساب واحد من بين عدة حسابات تمتلكها، لكن لا يمكنك تقييده لعامل واحد أو مشروع صفحات واحد داخل ذلك الحساب.

مدونة أذونات Cloudflare (سبتمبر 2023) تؤكد هذا مباشرة: اعتبارًا من تاريخ الكتابة، نطاق الموارد خارج المناطق محدود — يمكن تحديد نطاق رموز R2 لحاويات معينة، ولكن Workers وPages ليس لديهم ما يعادل ذلك. ويتم تأكيد هذا مرة أخرى في وثائق Builds الخاصة بـ Workers، التي تولّد تلقائيًا رمز نشر يغطي برامج Workers (تحرير)، تخزين Workers KV (تحرير)، تخزين Workers R2 (تحرير)، ومسارات Workers (تحرير) — على مستوى الحساب بالكامل، دون خيار لتضييق النطاق ليشمل اسم برنامج واحد فقط. تواجه عمليات نشر Pages عبر CI/CD نفس المشكلة: إذ أن إذن Cloudflare Pages: تحرير يغطي كل مشروع Pages على الحساب.

رموز محددة بالوقت لا تساعد

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

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

ماذا يكسر هذا

هاتان الفجوتان معًا تكسران أهم مبدأين للتحكم في الوصول في أنظمة الإنتاج:

أدنى امتياز: يجب ألا يمتلك رمز CI/CD المخصص لمدفوعات العمال إذنًا دائمًا لتعديل عامل المصادقة، أو إجراء الدفع، أو أي مشروع من Pages. يجب ألا يكون خط النشر لموقع التسويق الخاص بك قادرًا على الوصول إلى عامل المدفوعات. اليوم، هم قادرون على ذلك — ولا توجد آلية منصاتية لمنع ذلك.
فصل الواجبات: يجب ألا يكون المطور الذي يعمل على عامل أو مشروع Pages واحد قادرًا على الوصول إلى موارد فريق آخر في بيئة الإنتاج. اليوم، إذا كان لديهم حق الوصول إلى Workers أو Pages على الإطلاق، فهم قادرون على ذلك.

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

ما الذي يفعله المطورون فعليًا: الحلول البديلة

لأن المنصة لا توفر ضوابط وصول لكل عامل أو لكل مشروع صفحات، فقد توصلت الفرق إلى مجموعة من الأنماط التعويضية. إليك ما يُستخدم فعليًا في الواقع — وحساب صريح للقيود الخاصة بكل نمط.

نمط الحساب المنفصل — أكثر الحلول البديلة شيوعًا

الحل البديل الأكثر توصية في مجتمع كلودفلير هو عزل مشاريع العمال (Workers) والصفحات (Pages) في حسابات كلودفلير منفصلة — حساب واحد لكل مشروع أو فريق. يحصل كل حساب على أعضائه ورموزه الخاصة، ونظرًا لأن كل حساب هو حد صارم، فإن الوصول يكون معزولًا بشكل طبيعي.

سلسلة نقاش في مجتمع Cloudflare من أبريل 2025 — تسأل بشكل مباشر "هل يمكن للأعضاء الوصول فقط إلى العمال الخاصين بي بدلاً من الحساب الكامل للنطاق؟" — توضح مدى شيوع هذا السؤال. الإجابة من المجتمع، المتسقة عبر عدة سلاسل نقاش تعود لسنوات، هي نفسها: تحتاج إلى حسابات منفصلة. سلسلة نقاش أخرى من أبريل 2025 سألت عن كيفية عزل إدارة مختلف تطبيقات Worker وD1 وPages بين الفرق في شركة صغيرة — السؤال يشير إلى Pages صراحة — ومرة أخرى، كانت الإجابة تشير إلى فصل الحسابات كالخيار الحقيقي الوحيد.

هذا النمط يحقق هدف العزل. لكن وصفه بأنه حيلة يقلل من مدى الصعوبة التشغيلية التي يسببها بالفعل:

انتشار الحسابات وتجزئة الفوترة. كل حساب يُعد كيانًا منفصلاً للفوترة، ولوحة تحكم منفصلة، ومجموعة منفصلة من بيانات الاعتماد لتأمينها وتغييرها. إدارة الأعضاء وتسجيل الدخول الموحد وسجلات التدقيق عبر N حسابات يتوسع بشكل سيئ.
لا يمكن للموارد عبور حدود الحسابات. العاملون الذين يحتاجون لمشاركة مساحات أسماء KV أو قواعد بيانات D1 أو دلاء R2 أو الكائنات الدائمة لا يمكنهم القيام بذلك عبر الحسابات. مشاريع Pages التي تستخدم العاملين كوظائف خلفية تواجه نفس القيد — الارتباطات بالخدمة محددة لكل حساب.
لا توجد طريقة لنقل عامل أو مشروع Pages بين الحسابات. إذا قمت بالتطوير في حساب معزول ورغبت في نقله إلى حساب الإنتاج الرئيسي، يجب عليك إعادة إنشاء النص البرمجي أو المشروع يدويًا، وجميع الارتباطات والمتغيرات البيئية والأسرار والمسارات من الصفر. لا يوجد واجهة برمجة تطبيقات للنقل ولا مسار ترحيل لأي من العاملين أو Pages.
تجزئة الرصد. السجلات والتحليلات والقياسات لكل حساب على حدة. ستفقد الرؤية الموحدة عبر أسطولك من العاملين وPages وتحتاج إلى أدوات خارجية لتجميعها.

إنشاء حسابات منفصلة لعزل مشاريع العمال والصفحات هو إجراء تعويضي — وليس بنية أمنية مصممة. أنت تعمل حول حد التفويض المفقود، وليس تبني واحدًا.

رموز قصيرة العمر مع تدوير عدواني

تخفف بعض الفرق من المخاطر عن طريق إنشاء رمز API جديد لكل تشغيل نشر ثم إلغاؤه فورًا بعد ذلك. وهذا ينطبق بنفس القدر على نشرات Workers عبر Wrangler ونشرات Pages عبر wrangler pages deploy أو واجهة برمجة تطبيقات Cloudflare. هذه خطوة مشروعة للدفاع المتعدد الطبقات وتستحق التنفيذ — لكنها تحد فقط من مدة التعرض، وليس نطاقه. لا يزال للرمز حق الوصول الكامل على مستوى الحساب لجميع مشاريع Workers وPages طالما كان موجودًا.

يتطلب تنفيذ هذا بشكل صحيح أيضًا بنية تحتية لـ CI/CD تدعم إنشاء الرموز المميزة وإلغاءها ديناميكيًا عبر واجهة برمجة تطبيقات Cloudflare، والتي لا تدعمها معظم إعدادات خطوط الأنابيب القياسية بشكل افتراضي.

# Illustrative: short-lived token via Cloudflare API
# Even with expiry set, Workers Scripts: Edit still covers ALL Workers.
# Cloudflare Pages: Edit still covers ALL Pages projects.
# There is no script_name or project_name resource filter in the permissions API.

POST /client/v4/user/tokens
{
  "name": "ci-deploy-worker-payments-2026-03-11",
  "policies": [{
    "effect": "allow",
    "resources": { "com.cloudflare.api.account.ACCOUNT_ID": "*" },
    "permission_groups": [{ "id": "<workers-scripts-edit-group-id>" }]
    // ^ No per-Worker or per-Pages-project resource filter exists. Account-wide only.
  }],
  "not_before": "2026-03-11T10:00:00Z",
  "expires_on":  "2026-03-11T11:00:00Z"
}

تقييد الوصول إلى واجهة برمجة التطبيقات لكل مستخدم

نظام الأذونات في Cloudflare يسمح للمسؤولين الفائقين بتقييد أي أعضاء الحساب مسموح لهم بإنشاء رموز API على الإطلاق. يمكن أن يؤدي ذلك إلى مركزية إنشاء الرموز في حساب خدمة واحد، مما يقلل من عدد الأشخاص الذين يمكنهم إنشاء رموز بصلاحيات واسعة على كل من Workers و Pages.

هذا هو تحكم إداري مفيد — لكنه لا يحل مشكلة النطاق. الرموز التي يتم إنشاؤها بواسطة حساب الخدمة ما زالت لديها وصول شامل إلى Workers و Pages على مستوى الحساب. إنه يقلل من عدد المجالات التي يمكن من خلالها إنشاء رمز ذو نطاق زائد أو إساءة استخدامه، لكن الرموز التي يتم إنشاؤها ما زالت ذات نطاق زائد بحكم التصميم.

ما تحتاجه كلاودفلير للبناء

الإصلاح ليس معقدًا من الناحية المعمارية لوصفه. ووصفت مدونة Cloudflare لعام 2022 التي قدمت أدوار النطاقات بالوصف نظام الأذونات Bach الخاص بهم بأنه يدعم تحديد الموارد لـ "الحسابات، المناطق، بيئات العامل، أو سجلات DNS". يتم ذكر بيئات العامل صراحةً كنوع من الموارد في ذلك النظام الأساسي — ويجب التعامل مع مشاريع Pages بنفس الطريقة.

الفجوة هي أن هذه الميزة لم يتم كشفها للعمال أو الصفحات في المنتج. ما يحتاج إلى الحدوث:

رموز واجهة برمجة التطبيقات (API): تحتاج مجموعة أذونات نصوص العمال (Workers Scripts) إلى قبول مرشح الموارد لأسماء نصوص العمال الفردية. تحتاج مجموعة أذونات صفحات كلودفلير (Cloudflare Pages) إلى قبول مرشح الموارد لأسماء مشاريع الصفحات الفردية. يجب أن يكون الرمز المحدد على Workers Scripts: Edit على المورد worker-payments غير قادر على الوصول إلى worker-auth. يجب أن يكون الرمز المحدد على Cloudflare Pages: Edit على المشروع marketing-site غير قادر على الوصول إلى payments-portal.
أدوار الأعضاء: يجب أن يكون بالإمكان تحديد نطاق أذونات أدوار مديري العمال (Workers Admin) وأدوار الصفحات (Pages) -أو المتغيرات الجديدة لكل مورد- لتشمل عمال محددين ومشاريع صفحات محددة، وليس فقط للنطاقات كما تعمل الأدوار المحددة على النطاقات اليوم، وليس بطريقة تمنح وصولًا لحساب كامل.
R2 هو إثبات المفهوم: كلودفلير تدعم بالفعل تحديد النطاق على مستوى الحاوية (bucket-level) لرموز R2. نفس النمط عند تطبيقه على أسماء نصوص العمال وأسماء مشاريع الصفحات سيحل هذه المسألة. القدرة موجودة في نموذج الأذونات — ويحتاج التطبيق على العمال والصفحات.

هذا سيسمح لأن يكون رمز CI/CD غير قادر، بفضل فرض المنصة، على الوصول إلى أي مشروع Worker أو Pages آخر غير المشروع الذي تم إصداره من أجله. سيتم تحديد نطاق الضرر في حال تم اختراق حساب المطور ليقتصر على الموارد التي تم تخصيصها له. سيتم فرض فصل الواجبات بين فرق المنتج من قبل المنصة — وليس من خلال سياسة المنظمة والثقة.

ما الذي يجب أن تفعله الفرق الآن

بينما توجد هذه الفجوة، إليك كيفية الاقتراب قدر الإمكان من أقل امتياز كما يسمح النظام الأساسي حاليًا. هذه ضوابط تعويضية — وليست حلولًا — ويجب فهمها على هذا النحو.

عزل أهم مشاريعك في Workers وPages في حساب مخصص. إذا كان لديك عدد قليل من الموارد الحيوية — مثل عمليات الدفع في Workers، تطبيقات Pages لمواجهة العملاء، خدمات المصادقة — ويمكنك تحمل العبء التشغيلي، فإن وضعها في حساب منفصل يوفر عزلة حقيقية. تقبّل أن مشاركة الموارد والمراقبة ستكون أصعب كجزء من المقايضة.
توليد رموز قصيرة العمر لكل عملية نشر وسحبها فورًا. ينطبق هذا على كل من مسارات Workers وPages. قلل فترة التعرض للمخاطر حتى إذا لم تتمكن من تحديد النطاق.
قصر إنشاء رموز API على حساب خدمة واحد فقط. استخدم التحكم في الوصول لواجهة برمجة تطبيقات Cloudflare لكل مستخدم لمنع أعضاء الفريق من إنشاء رموز واسعة بشكل مستقل.
مراقبة سجل التدقيق. استخدم واجهة برمجة تطبيقات سجل تدقيق Cloudflare لتتبع تحميلات نصوص Worker، أحداث نشر Pages، وأي تغييرات على أي منهما. أرسل تنبيهات عند وجود فاعلين غير متوقعين أو أسماء موارد غير متوقعة تم تعديلها.
رفع القضية رسميًا مع Cloudflare. إذا كنت على خطة Enterprise، ضع طلبًا رسميًا لتحديد صلاحيات الوصول لكل مورد لكل من Workers وPages مع مدير نجاح العملاء كطلب منتج مسمى. انشر الموضوع في منتدى المجتمع. كلما زادت الفرق التي توثق هذه الفجوة بشكل صريح، زاد الضغط لإغلاقها.

# Audit log query: monitor for Worker and Pages changes
GET /client/v4/accounts/{account_id}/audit_logs
  ?action.type=Script+Upload
  &since=2026-01-01T00:00:00Z
  Authorization: Bearer {your_token}

# Run a separate query for Pages deployment events:
GET /client/v4/accounts/{account_id}/audit_logs
  ?action.type=Deployment
  &since=2026-01-01T00:00:00Z
  Authorization: Bearer {your_token}

# Review both for unexpected actors or unexpected resource names.

إغلاق

Cloudflare هو منصة نستخدمها ونوصي بها. هذه التدوينة ليست إدانة — إنها حساب دقيق وموثق لفجوة محددة تهم أمن الإنتاج عبر كل من Workers وPages. البنية التحتية لإصلاحها موجودة بالفعل وفقًا للتقارير في Bach. الطلب مباشر: كشف نطاق الوصول لكل مورد للرموز والأدوار عبر Workers وPages، تمامًا كما هو موجود بالفعل لحاويات R2.

في Evolving Cyberنحن نعتقد أن الأمان الجيد هو قرار تصميمي، وليس تعديلًا لاحقًا. هذا المبدأ ينطبق على المنصات التي نبني عليها، وليس فقط على البرمجيات التي نطورها. عندما تجعل المنصة المبدأ الأدنى للامتيازات مستحيل التنفيذ عمليًا — أو يمكن تحقيقه فقط من خلال انتشار الحسابات والتعويض اليدوي — فإنها تنقل عبء الأمان بالكامل إلى الفرق التي تستخدمها. هذا ليس تصميمًا جيدًا.

الطلب: تحديد نطاق رموز واجهة برمجة التطبيقات API وأدوار الأعضاء لأسماء سكريبت Workers الفردية وأسماء مشاريع Pages. R2 بالفعل يفعل هذا للحاويات. يحتاج كل من Workers و Pages إلى الشيء نفسه.