کنترل دسترسی Cloudflare Workers در پروژه‌های ابری معمولاً از یک سؤال ساده شروع می‌شود: چه کسی اجازهٔ انجام چه کاری را دارد؟ اما وقتی تعداد اعضای تیم، سرویس‌ها و Agentهای هوش مصنوعی بیشتر می‌شود، یک پاسخ کلی مثل «دسترسی ادمین» دیگر قابل‌قبول نیست. Cloudflare در ۱۵ سپتامبر ۲۰۲۶ از کنترل‌های دسترسی سطح Worker برای تیم‌ها و Agentها خبر داد؛ قابلیتی که هدفش اجرای عملی اصل کمترین دسترسی در محیط Developer Platform است.
مسئلهٔ دسترسی گسترده چیست؟
اگر یک کاربر، ابزار CI/CD یا Agent برای انتشار تغییرات فقط به یک Worker نیاز داشته باشد، دسترسی سراسری به همهٔ Workerها، تنظیمات حساب، دامنه‌ها و منابع جانبی ریسک غیرضروری ایجاد می‌کند. یک خطای پیکربندی یا افشای توکن می‌تواند دامنهٔ اثر حادثه را از یک اپلیکیشن به کل حساب گسترش دهد. راهکار Cloudflare، یعنی کنترل دسترسی Cloudflare Workers، دسترسی را هم بر اساس منبع و هم بر اساس نوع عملیات محدود می‌کند.
چهار سطح مجوز برای یک Worker
Cloudflare چهار نقش جدید را معرفی کرده است. نقش Metadata Read-Only برای مشاهدهٔ فهرست منابع، تنظیمات و داده‌های مشاهده‌پذیری مانند معیارها، لاگ‌ها و traceهاست، بدون اینکه کد Worker یا محتوای محصول در اختیار کاربر قرار گیرد. این نقش برای عیب‌یابی اولیه مناسب است.
نقش Content Read-Only اجازهٔ خواندن کد Worker یا محتوای D1 را می‌دهد، اما تغییر یا استقرار را مجاز نمی‌کند. این سطح برای بازبینی کد، تحلیل خطا و Agentهای بررسی‌کننده کاربرد دارد.
در مدل کنترل دسترسی Cloudflare Workers، نقش Editor برای تیم توسعه یا CI/CD طراحی شده است. این نقش می‌تواند محتوای محصول و تنظیمات Worker را تغییر دهد و نسخهٔ جدید را مستقر کند، اما امکان ایجاد یا حذف منبع را ندارد. در نتیجه، حتی اگر توکن استقرار لو برود، مهاجم نمی‌تواند Worker را حذف کند یا به منابع دیگر حساب دست بزند.
بالاترین سطح، Admin، کنترل کامل همان Worker را فراهم می‌کند؛ از جمله ایجاد، تغییر نام، حذف و اعطای دسترسی. نکتهٔ مهم این است که Admin هم می‌تواند در محدودهٔ یک Worker مشخص تعریف شود و الزاماً به معنی دسترسی به تمام حساب نیست.
این قابلیت برای Agentهای هوش مصنوعی چه معنایی دارد؟
کنترل دسترسی Cloudflare Workers برای Agentها یعنی هر عامل دقیقاً همان سطحی را بگیرد که برای وظیفه‌اش لازم است. Agentی که فقط باید لاگ‌ها را بخواند، به Editor نیاز ندارد. Agentی که کد را بررسی می‌کند نباید بتواند مستقر کند. Agentی که در خط انتشار فعالیت می‌کند باید به Worker مشخص و نقش Editor محدود شود، نه اینکه کل حساب Cloudflare را در اختیار داشته باشد. این تفکیک هم خطای انسانی را کاهش می‌دهد و هم ممیزی رفتار Agent را ساده‌تر می‌کند.
نکتهٔ مهم دربارهٔ Route و دامنهٔ سفارشی
دسترسی به خود Worker به‌تنهایی برای تغییر Route یا Custom Domain کافی نیست. Cloudflare برای این تغییرها مجوز جداگانهٔ Workers Routes را لازم می‌داند، چون تغییر مسیر ترافیک می‌تواند سرویس تولید را از دسترس خارج کند. بنابراین مسیر انتشار باید بین «تغییر کد»، «تغییر تنظیمات Worker» و «تغییر مسیر ورودی» مرز مشخص داشته باشد.
چک‌لیست پیشنهادی برای تیم‌های فنی
۱. برای پایش و عیب‌یابی، ابتدا Metadata Read-Only را امتحان کنید. ۲. برای بازبینی کد، Content Read-Only بدهید. ۳. توکن CI/CD را در سطح یک Worker و با نقش Editor بسازید. ۴. در کنترل دسترسی Cloudflare Workers، Admin را فقط برای مسئول مشخص و سناریوی واقعاً مدیریتی نگه دارید. ۵. تغییر Route و دامنه را جداگانه تأیید و ممیزی کنید. ۶. توکن‌ها را دوره‌ای چرخانده و لاگ استفاده از آن‌ها را بررسی کنید.
جمع‌بندی
امنیت دسترسی زمانی قابل‌کنترل می‌شود که مجوزها با کار واقعی هر فرد یا Agent هماهنگ باشند. کنترل دسترسی Cloudflare Workers در مدل چهارسطحی خود یک الگوی عملی ارائه می‌دهد: مشاهده برای عیب‌یابی، خواندن برای بازبینی، ویرایش برای استقرار و مدیریت برای مسئولیت کامل. حتی اگر از Cloudflare استفاده نمی‌کنید، همین تفکیک می‌تواند برای APIها، پنل‌ها، سرورها و سرویس‌های داخلی تکتاز هم به‌عنوان یک الگوی طراحی دسترسی استفاده شود.
برای تکمیل این نگاه فنی، مطلب قبلی تکتاز مگ دربارهٔ قابلیت‌های جدید DevTools در Chrome ۱۵۳ و ۱۵۴ نیز راهنمای مناسبی برای بررسی عملکرد و رفتار اپلیکیشن است.
منبع رسمی: گزارش Cloudflare دربارهٔ کنترل دسترسی Workers
