کلیدهای JSON بلندمدت سریع‌ترین راه برای به‌خطر افتادن دسترسی به پروژه‌های GCP هستند. فدرسیون هویت بارکاری (Workload Identity Federation یا WIF) این مخاطره را با تبدیلِ کلیدهای همیشه‌قابل‌استفاده به سازوکارهای اعتمادی کوتاه‌مدت حل می‌کند: به‌جای مدیریت رازها، روابط اعتماد پیکربندی می‌شوند و دسترسی‌ها از طریق توکن‌های کوتاه‌مدت صادر و کنترل می‌شوند.

ریسک‌ها و هزینه‌های نگهداری کلیدهای بلندمدت

تولید، توزیع و گردش کلیدهای حساب‌های سرویس برای ابزارهای CI/CD، ارائه‌دهندگان ثالث یا توابع سرویس همواره مشکل‌زا بوده است. اگر تاریخ‌انقضا قرار ندهید، ریسک نشت افزایش می‌یابد؛ اگر مرتباً کلیدها را بازتولید کنید، هماهنگی با تیم‌ها دشوار و پرخطا می‌شود. حتی با لاگینگ پیشرفته، تعیین شعاع اثر یک کلید نشت‌شده زمان‌بر و ناپایدار باقی می‌ماند.

فدرسیون هویت بارکاری چطور مدل را تغییر می‌دهد

مکانیزم WIF ساده و ساختارمند است: به‌جای صادرکردن یک راز به سرویس خارجی، به GCP اعلام می‌کنید کدام ارائه‌دهندگان هویت پذیرفته می‌شوند و تحت چه شرط‌هایی. سرویس خارجی توکن خود را به Security Token Service گوگل می‌فرستد و پس از اعتبارسنجی، GCP یک توکن دسترسی کوتاه‌مدت صادر می‌کند که پس از مدت کوتاهی منقضی می‌شود؛ بنابراین نیاز به گردش کلیدهای بلندمدت از بین می‌رود.

سه مؤلفه اصلی WIF

  • Workload Identity Pool — مخزن نام‌گذاری‌شده برای گروه‌بندی پیکربندی‌های اعتماد در پروژه (پولِ هویت بارکاری).
  • Provider — کانکتوری درون پول که مشخص می‌کند توکن‌ها از کجا می‌آیند و چگونه ادعاها (claims) به صفات قابل‌فهم برای GCP نگاشت شوند. هر سیستم هویت خارجی یک ارائه‌دهنده جداگانه دریافت می‌کند.
  • Service Account Binding — بایندینگی که مشخص می‌کند وقتی هویتی اعتبارسنجی شد، چه دسترسی‌های موقتی به حساب سرویس اعطا می‌شود.

نقطه حساس: شرط‌های صفتی (attribute conditions)

اگر شرط‌های صفتی تعریف نشوند، هر هویتی که از یک ارائه‌دهنده مورد اعتماد بیاید می‌تواند دسترسی کسب کند؛ این سطح دسترسی برای محیط تولید بسیار باز خواهد بود. شرط‌های صفتی مانند فیلترهای دقیق عمل می‌کنند: نام سرویس، نام رول، شناسه استیج یا هر ادعای (claim) دیگری را بررسی و دسترسی را محدود می‌کنند. همیشه شرط‌های حداقلی، خاص و قابل‌تصدیق بنویسید تا فقط بارکاری‌های مشخص اجازه دسترسی داشته باشند.

معماری فدرسیون هویت بارکاری در GCP—پول، ارائه‌دهنده و بایندینگ

تصمیم عملی: تفویض هویت (Impersonation) یا دسترسی مستقیم؟

گوگل دسترسی مستقیم به حساب سرویس را به‌عنوان گزینه پیش‌فرض فراهم می‌کند، اما بسیاری از تیم‌ها تفویض هویت (impersonation) را ترجیح می‌دهند. مزیت تفویض این است که می‌توان سلسله‌مراتب، محدوده و محدودیت‌های دقیق‌تری تعریف کرد و ریسک به‌اشتراک‌گذاری مستقیم کلید یا شناسه حساب سرویس را کاهش داد. در پیاده‌سازی ما، استفاده از impersonation کنترل لاگ‌ها را بهبود داد و بازگردانی را در رخدادها تسهیل کرد.

مراحل پیاده‌سازی WIF در مقیاس

  1. تعریف قوانین پایه و نگهداری آنها به‌عنوان الگو در Terraform یا ابزارهای IaC.
  2. اجبار استفاده از WIF از مرحله ایجاد پروژه؛ پروژه‌های جدید بدون کلیدهای بلندمدت ساخته شوند.
  3. مدیریت تدریجی کلیدهای قدیمی و بدون تاریخ‌انقضا: حذف آنها هنگام بازسازی یا مهاجرت پروژه‌ها تا از انجام یک مهاجرت پرریسک جلوگیری شود.

اشتباه رایج در استقرارهای چندسازمانی

در تنظیمات multi-org، خطای معمول این است که ارائه‌دهنده WIF را در سطح اشتباه پول یا پروژه ایجاد کنند؛ نتیجه می‌تواند اعطای مجوزهای غیرمنتظره به برخی خطوط لوله یا بالعکس باشد. توصیه می‌شود طراحی پول‌ها و ارائه‌دهنده‌ها بر اساس مرزهای سازمانی و محیط (prod/stage/dev) ثابت شود و تست‌های دسترسی خودکار شوند.

وقتی AWS STS هویتی را به GCP ثابت می‌کند

وقتی یک تابع Lambda یا نقش IAM در AWS توکن خود را ارائه می‌دهد، AWS STS یک توکن موقتی تولید می‌کند. GCP آن توکن را مطابق پیکربندی ارائه‌دهنده در پول شما بررسی می‌کند، ادعاها را نگاشت می‌نماید و در صورت تطابق، یک توکن GCP با عمر کوتاه صادر می‌کند. برای جزئیات بیشتر به مستندات AWS STS و توضیحات OpenID Connect مراجعه کنید.

نکات اجرایی و بهترین شیوه‌ها

  • WIF را از مرحله ایجاد پروژه الزام‌آور کنید تا نیاز به بازتطبیق گسترده کلیدها کاهش یابد.
  • همیشه شرط‌های صفتی نزدیک و خاص بنویسید؛ از wildcardهای عمومی پرهیز کنید.
  • تفویض هویت را برای کنترل دقیق‌تر دسترسی و امکان بازپذیری انتخاب کنید.
  • لاگ‌های ممیزی و هشدارهای دسترسی را فعال کنید و به سیستم SIEM متصل نمایید تا در رخدادها شعاع اثر سریع تعیین شود.
  • کلیدهای باقی‌مانده و قدیمی را مرحله‌ای حذف کنید و در هر جا ممکن است جایگزینی با WIF فراهم نمایید.

چشم‌انداز عملیاتی

WIF فراتر از یک قابلیت امنیتی ساده است؛ این یک الگوی طراحی برای هویت ماشینی است که عملیات و ریسک را هم‌زمان کاهش می‌دهد. سازمان‌هایی که WIF را از ابتدا اجباری کردند، سریع‌تر توانستند دسترسی‌ها را استاندارد و قابل حسابرسی کنند و بدون موج‌های پرهزینه مهاجرتی به مدل امن‌تر منتقل شوند.

گام‌های پیشنهادی بعدی: اگر هنوز پروژه‌ای به کلیدهای بدون تاریخ‌انقضا متکی است، جدول زمانی مشخص و گام‌های کوچک تعریف کنید: ایجاد پول و ارائه‌دهنده برای آن کلاس از بارکاری‌ها، اعمال شرط‌های صفتی، اجرای تست‌های اتوماتیک و سپس غیرفعال‌سازی کلیدها. این مسیر ریسک را به‌صورت کنترل‌شده کاهش می‌دهد و زیرساخت هویتی را آینده‌نگر می‌سازد.