اگر امروز کلیدهای دسترسی (Access Keys) ابری خود را در تنظیمات پلتفرم‌های مختلف کپی می‌کنید، در واقع دارید یک بمب ساعتی را در زیرساخت خود می‌کارید. باید بدانید که هر کلیدی که در یک سیستم شخص ثالث ذخیره می‌شود، یک نقطه شکست تک‌نقطه است که تا ابد اعتبار دارد و فقط منتظر یک نفوذ امنیتی است تا فعال شود. در حالی که اکثر پلتفرم‌ها با ذخیره اعتبارنامه‌های ابری به عنوان یک ضرورت استاندارد برخورد می‌کنند، این رازها در واقع بدهی‌های خاموشی هستند که به مرور زمان انباشته شده و ریسک سازمان را افزایش می‌دهند.
پلتفرم Zero — ابزاری برای مدیریت حقیقت مهندسی توسط b0gy — با رویکردی جسورانه این الگو را می‌شکند. به نقل از مستندات فنی این پلتفرم، آن‌ها ذخیره کلیدهای حساب‌های خدماتی (Service Account Keys)، کلیدهای دسترسی، رازها یا فایل‌های JSON برای دسترسی به گوگل کلود (GCP) و آمازون وب سرویسز (AWS) را به‌طور کامل متوقف کرده‌اند. به‌جای آن، از توکن‌های هویت فدراسیون (Federated Identity Tokens) استفاده می‌کنند؛ توکن‌هایی که در لحظه صادر شده و پس از چند دقیقه منقضی می‌شوند. این استراتژی تضمین می‌کند که حتی در صورت رخ دادن یک نفوذ امنیتی در پلتفرم، هیچ داده‌ای برای نشت وجود نداشته باشد.
اکثر فرآیندهای اتصال به ابر امروزه بر مدل «کپی کن و دعا کن» استوار است. شما یک فایل JSON را از کنسول دانلود می‌کنید — کاری که قطعاً نباید آن را از طریق ایمیل به خودتان ارسال کنید — و سپس آن را در محیط کاربری یک سرویس شخص ثالث می‌چسبانید. در این لحظه، شما فقط امیدوارید که ارائه‌دهنده سرویس آن را رمزنگاری کرده باشد، امیدوارید که آن‌ها عملیات چرخش کلید (Rotation) را انجام دهند و امیدوارید که هیچ‌یک از کارکنانشان نتواند آن را بخواند. این روند باعث ایجاد یک اعتبارنامه می‌شود که به‌طور نامحدود معتبر است، بر اساس هر دسترسی که شما اعطا کرده‌اید محدوده یافته و در سیستمی ذخیره شده است که شما هیچ کنترلی روی آن ندارید. اگر پلتفرمی مورد نفوذ قرار گیرد یا کارمندی با دسترسی به پایگاه داده کنجکاو شود، آن کلید تا زمانی که کسی آن را ابطال کند، کار می‌کند. اغلب، هیچ‌کس آن را ابطال نمی‌کند زیرا هیچ‌کس به یاد نمی‌آورد که چنین کلیدی وجود دارد.
این شکنندگی در مقیاس جهانی کاملاً مشهود است. طبق گزارش GitGuardian ۲۰۲۶، در سال ۲۰۲۵ میلادی حدود ۲۸.۶۵ میلیون رمز سخت‌افزاری (Hardcoded Secret) به گیت‌هاب ارسال شده که نسبت به سال قبل ۳۴٪ افزایش یافته است. نکته تکان‌دهنده این است که اکثر این رازها در لحظه شناسایی، معتبر بودند. مشکل لزوماً بی‌دقتی تیم‌ها نیست، بلکه این است که اعتبارنامه‌های طولانی‌مدت ذاتاً ناپایدارند. آن‌ها بی‌صدا کار می‌کنند تا زمانی که ناگهان متوقف شوند و تنها حالت شکست آن‌ها، یک نفوذ امنیتی گسترده است. این چالش در مدیریت اعتبارنامه‌ها شباهت زیادی به دشواری‌های پذیرش متدهای احراقی جدید دارد؛ همان‌طور که بسیاری از سازمان‌ها در مقیاس‌پذیری پس‌وردهای بیومتریک با موانعی روبرو شدند، تغییر پارادایم از رمزهای ثابت به هویت‌های پویا نیز با مقاومت‌های سیستمی همراه است.
سازوکار فدراسیون بدون کلید
Zero این سطح از امنیت را از طریق هویت فدراسیون پیاده می‌کند. در گوگل کلود پلتفرم (GCP)، آن‌ها از فدراسیون هویت ورک‌لود (Workload Identity Federation) استفاده می‌کنند و در آمازون وب سرویسز (AWS) از AssumeRoleWithWebIdentity مبتنی بر OIDC بهره می‌گیرند. پیش‌فرض اصلی در هر دو مورد یکسان است: به‌جای دادن یک کلید به Zero، شما به ابر خود دستور می‌دهید که هویت Zero را به‌عنوان یک منبع معتبر بشناسد و به آن اعتماد کند.
جریان پیاده‌سازی در GCP
- صدور OIDC: پلتفرم Zero صادرکننده OIDC خود را اجرا کرده و یک نقطه انتهایی JWKS (مجموعه کلید وب JSON) را منتشر می‌کند. این یک URL استاندارد اکتشاف است که کلیدهای عمومی مورد نیاز برای تأیید توکن‌های امضا شده توسط Zero را فراهم می‌کند.
- برقراری اعتماد: کاربران یک Pool هویت ورک‌لود در پروژه GCP خود می‌سازند که صراحتاً به صادرکننده OIDC پلتفرم Zero اعتماد می‌کند.
- دسترسی محدود: دسترسی‌ها از طریق یک شرط ویژگی (Attribute Condition) محدود می‌شوند تا دسترسی فقط به یک سازمان خاص محدود شود. این کار با منطقی شبیه به
attribute.workspace == "org:YOUR_ORG_ID"انجام می‌شود. - صدور در لحظه: هرگاه Zero نیاز به خواندن منابع داشته باشد، یک توکن JWT کوتاه‌مدت که با کلید خصوصی خودش امضا شده و حاوی شناسه سازمان (Org ID) به عنوان یک ادعا (Claim) است، صادر می‌کند.
- تبادل توکن: این توکن به سرویس توکن امنیتی (STS) گوگل ارسال می‌شود. STS امضای توکن را با JWKS بررسی کرده و شرط ویژگی را چک می‌کند. اگر تطابق وجود داشته باشد، یک توکن دسترسی کوتاه‌مدت GCP صادر می‌کند که دقیقاً مطابق با نقش‌های اعطایی است.
جریان پیاده‌سازی در AWS
- ایجاد نقش IAM: در AWS، به‌جای استفاده از Pool هویت ورک‌لود، کاربران یک نقش (Role) در IAM ایجاد می‌کنند.
- سیاست اعتماد: این نقش شامل یک سیاست اعتماد (Trust Policy) است که به‌طور مشخص به صادرکننده OIDC پلتفرم Zero و شناسه سازمان خاص کاربر اشاره می‌کند.
- پذیرش نقش: به‌جای تبادل توکن STS، آمازون از
AssumeRoleWithWebIdentityاستفاده می‌کند تا همان نتیجه را بگیرد: یک اعتبارنامه کوتاه‌مدت که محدود به آن حساب است و هیچ رمز ذخیره شده‌ای در سمت ارائه‌دهنده وجود ندارد.
این معماری تضمین می‌کند که ارائه‌دهنده ابر (و نه اپلیکیشن) مرز امنیتی را اعمال کند. به دلیل محدودسازی بر اساس هر سازمان (Per-org scoping)، یک مستأجر (Tenant) هرگز نمی‌تواند پروژه‌های مستأجر دیگر را بخواند. این موضوع توسط فیلترهای پرس‌وجوی سطح اپلیکیشن مدیریت نمی‌شود، بلکه توسط مکانیسم‌های اجباری خودِ ابر اعمال می‌گردد. در این مدل، رابطه اعتماد مستقیماً در پیکربندی IAM کاربر قابل مشاهده است و برای ابطال دسترسی، تنها کافی است یک منبع واحد را حذف کنید.
موازنه‌های مهندسی و هزینه‌ها
گذار به مدل بدون کلید، هزینه‌های مشخصی در پیچیدگی مهندسی و اصطکاک هنگام راه‌اندازی ایجاد می‌کند. مدل بدون کلید رایگان نیست؛ این روش از نظر امنیتی ارزان‌تر اما از نظر پیاده‌سازی گران‌تر است.
اصطکاک در شروع کار
راه‌اندازی این سیستم سخت‌تر از فرآیند سنتی «دانلود و چسباندن» در یک مرحله است. فدراسیون بدون کلید نیازمند ایجاد Poolهای هویت ورک‌لود یا نقش‌های IAM از طریق کنسول ابر یا اجرای کدهای Terraform است. برای کاهش این مانع و تسهیل تجربه کاربر، Zero ابزارهای زیر را توسعه داده است:
- جادوگرهای (Wizards) راهنمای گام‌به‌گام با دستورات آماده و قابل کپی.
- قطعات کد (Snippets) آماده Terraform برای استقرار سریع.
- پرامپت‌های LLM تک‌مرحله‌ای (One-shot) که پیکربندی صحیح را برای محیط‌های خاص تولید می‌کنند.
تأخیر در عملکرد
یک جریمه عملکردی قابل اندازه‌گیری در این روش وجود دارد. هر عملیات ابری با یک رفت‌وبرگشت (Round-trip) برای تبادل توکن شروع می‌شود. اگرچه برای یک همگام‌سازی که هزاران منبع را می‌خواند این تأخیر ناچیز است (زیرا تبادل توکن فقط یک‌بار در شروع اتفاق می‌افتد)، اما همچنان چند صد میلی‌ثانیه به هر چرخه همگام‌سازی اضافه می‌کند که در رویکرد کلید ذخیره شده وجود نداشت.
گسترش سطح خطا
وقتی یک کلید ذخیره شده شکست می‌خورد، خطا ساده است: «اعتبارنامه نامعتبر». اما در مدل فدراسیون، سطوح خطا گسترده‌تر است. شکست‌ها می‌توانند ناشی از موارد زیر باشند:
- انقضای توکن‌های OIDC.
- پیکربندی غلط شرایط ویژگی (Attribute Conditions).
- ارجاع Poolهای هویت ورک‌لود به صادرکننده اشتباه.
- نقش‌های IAM با سیاست‌های اعتماد نادرست.
برای مقابله با این پیچیدگی، Zero سرمایه‌گذاری سنگینی روی پیام‌های خطای تشخیصی دقیق انجام داده است تا بتواند دقیقاً مشخص کند کدام بخش از زنجیره اتصال قطع شده است.
مسئله «رمزهای نامرئی»
این تغییر، یک شکست سیستماتیک در حاکمیت امنیتی ابر (Cloud Security Governance) را هدف قرار داده است. این تصمیم بر اساس مشاهده اتفاقاتی شکل گرفت که وقتی پلتفرم‌ها رازها را ذخیره می‌کنند، رخ می‌دهد. اغلب، یک تیم در طول فرآیند شروع کار، یک حساب ابری را متصل می‌کند و به کلید حساب خدماتی گسترده‌ترین دسترسی‌های ممکن را می‌دهد تا «فقط مطمئن شود که سیستم کار می‌کند».
شش ماه بعد، هیچ‌کس به یاد نمی‌آورد چه دسترسی‌هایی اختصاص یافته است. دوازده ماه بعد، شخصی که تنظیمات را انجام داده از شرکت رفته است، اما کلید همچنان معتبر است و هر شب برای عملیات استفاده می‌شود. این وضعیت یک خلأ خطرناک در دیده‌پذیری ایجاد می‌کند. در بسیاری از تعاملات مشاوره‌ای، وقتی این پرسش مطرح می‌شود که «کدام سرویس‌های شخص ثالث به ابر شما دسترسی دارند و با چه مجوزهایی؟»، اغلب سکوتی طولانی برقرار می‌شود. پاسخ رایج «ما نمی‌دانیم» است؛ نه به دلیل سهل‌انگاری، بلکه چون رازهای ذخیره شده ذاتاً به‌گونه‌ای طراحی شده‌اند که نامرئی باشند.
برای ادغام‌هایی که فدراسیون بدون کلید هنوز در آن‌ها یک گزینه نیست — مانند GitHub Apps، Slack و Jira — پلتفرم Zero از جریان‌های استاندارد OAuth با ذخیره‌سازی رمزنگاری شده توکن‌ها استفاده می‌کند. اگرچه این مدل سطح حمله کوچک‌تری دارد (استفاده از توکن‌های محدود OAuth به‌جای کلیدهای کامل ادمین ابر)، اما هدف بلندمدت، رسیدن به یک معماری کاملاً بدون کلید است. این معماری آماده است و انتقال نهایی با پذیرش گسترده‌تر فدراسیون OIDC توسط سایر پلتفرم‌ها اتفاق خواهد افتاد.
گام بعدی شما و تحلیل نهایی
این رویکرد اساساً مدل اعتماد را معکوس می‌کند. به‌جای اعتماد به یک شخص ثالث برای محافظت از یک راز دائمی که هرگز خودش را حسابرسی نمی‌کند، کاربر به هویت ارائه‌دهنده برای بازه‌های زمانی کوتاه اعتماد می‌کند. اصطکاک در راه‌اندازی یک هزینه یک‌باره است، اما مزیت امنیتی آن به مرور زمان افزایش می‌یابد.
قاعده کلی (Heuristic): اگر پلتفرم شما اعتبارنامه‌های ابری را ذخیره می‌کند، شما در واقع به یک شخص ثالث اعتماد کرده‌اید تا رازی را محافظت کند که هرگز منقضی نمی‌شود و تا زمان سوءاستفاده، به‌طور بی‌صدا کار می‌کند. هویت فدراسیون، راز را به‌طور کامل حذف می‌کند؛ ابر شما در هر درخواست، فراخواننده را تأیید می‌کند و شما می‌توانید دسترسی را تنها از یک نقطه واحد قطع کنید.
خلاصه نهایی (tl;dr):
- الگو: اکثر پلتفرم‌ها اعتبارنامه‌های طولانی‌مدت ابری را ذخیره می‌کنند که باعث انباشت ریسک و مقاومت در برابر حسابرسی می‌شود.
- راهکار: استفاده از هویت فدراسیون (Workload Identity Federation در GCP و پذیرش نقش مبتنی بر OIDC در AWS) تا پلتفرم هرگز رازی برای اتصالات پرریسک نگه ندارد.
- نتیجه: هیچ چیزی برای نشت وجود ندارد، نیازی به چرخش کلید نیست و رابطه اعتماد در پیکربندی IAM شما قابل مشاهده است؛ برای ابطال دسترسی، تنها حذف یک منبع کافی است.
این مطلب بخش اول از یک سری سه قسمتی درباره ساخت Zero است. در بخش بعدی بررسی خواهیم کرد که این پلتفرم چگونه با ابزاری به نام Landed شروع شد تا به یک پرسش حیاتی پاسخ دهد: آیا کامیتی که مستقر کرده‌اید، واقعاً همان کامیتی است که در حال اجراست؟
گفتگو