خبر خوب برای تیمهای DevOps و SRE: حالا میتوانید با یک کلیک دسترسی به اپلیکیشنهای داخلی ساختهشده روی Cloudflare Workers را امن کنید 🔐
سرعت ساخت اپلیکیشنها با کمک AI خیلی زیاد شده و همین سرعت باعث شده تا هر کارمندی بتواند یک سرویس بسازد، آن را روی اینترنت منتشر کند و احتمالاً بهصورت ناخواسته اطلاعات داخلی را در معرض دید قرار بدهد. این ریسک، دغدغه اصلی هر CISO و تیم عملیات است.
برای حل این مشکل، ابزار جدیدی عرضه شده که امکان اعمال Cloudflare Access را مستقیم روی یک Worker یا روی همه Workers در یک حساب فراهم میکند. با این روش، اپلیکیشنها بهصورت پیشفرض پشت ورود شرکتی قرار میگیرند و دیگر نیازی نیست هر توسعهدهنده بهصورت دستی این تنظیمات را بسازد.
امکانات کلیدی که دریافت میکنید:
🔒 تعیین یک policy در سطح حساب تا تمامی preview و production deployments بهصورت پیشفرض پشت ورود شرکت باشند.
🧩 اعمال policy روی یک اپلیکیشن خاص تا احراز هویت روی هر دامنه مرتبط با آن اجباری شود، فارغ از نحوه استقرار.
👥 مشاهده دقیق کاربران: ایمیل، نام و گروههای هر کاربر احرازشده را مستقیماً در کد دریافت کنید — بدون نیاز به اعتبارسنجی دستی JWT (JSON Web Token).
⚙️ ساخت یک internal platform که هر دیپلوی آن بهصورت پیشفرض خصوصی باشد؛ یک نمونه open-sourced از یک internal static site platform هم آماده شده است.
Access on Workers — چگونه کار میکند 🧭
وقتی Access برای یک Worker فعال شود، Cloudflare احراز هویت را در لبه (edge) اعمال میکند؛ یعنی قبل از اینکه Worker کدی اجرا کند، کاربر باید احراز هویت شده باشد. بعد از احراز هویت، اطلاعات هویتی لازم (مثل email، name و groups) بهصورت قابلدسترسی برای Worker ارسال میشود تا نیازی به پیادهسازی و اعتبارسنجی دستی JWT در هر سرویس نباشد. این کار هم تجربه توسعهدهنده را سادهتر میکند و هم حملات ناشی از آشکارسازی ناخواسته را کاهش میدهد.
چند نکته عملیاتی برای تیمهای SRE/DevOps:
• به CI/CD فکر کنید: برای محیطهای preview و automation باید مکانیزمی برای دسترسی سرویسها (مثل service accounts یا API tokens) تنظیم کنید تا pipelineها بدون دخالت انسان بتوانند دیپلوی کنند.
• مدیریت سرویسهای بدونکاربر (service-to-service): برای APIها و jobهای خودکار، از روشهای معتبر سازی مخصوص سرویسها استفاده کنید و آنها را در policyها لحاظ کنید.
• لاگ و Audit: وقتی دسترسیها مرکزی میشود، لاگها و گزارشهای audit را فعال و مانیتور کنید تا تغییرات policy یا تلاشهای ناموفق فوراً دیده شوند.
• تست در staging: قبل از فعالسازی در سطح حساب، policyها را در محیط staging و preview تست کنید تا ریسک قطع سرویس کاهش یابد.
مزیت اصلی برای شما بهعنوان مهندس عملیات این است که میتوانید از نشت ناخواسته داده جلوگیری کنید، کنترل مرکزی روی دیپلویها داشته باشید و در عین حال توسعهدهندگان آزادی عمل لازم برای ساخت سریع اپلیکیشنها را حفظ کنند. این کار بهویژه وقتی تیمها متعدد و سریع در حال ساخت ابزارهای داخلی هستند، بسیار ارزشمند است 😊
اگر میخواهید سریع شروع کنید: policy سطح حساب را امتحان کنید، سپس برای اپلیکیشنهای حساس policyهای خاص تنظیم کنید و از مثال open-sourced برای راهاندازی یک internal platform خصوصی بهعنوان الگو استفاده کنید. موفق باشید!
