عامل‌های خفته کلیدهایشان را نگه می‌دارند: بازپس‌گیری اعتبارنامه به‌عنوان یک مرحله از چرخه حیات

یافته و مسئله چارچوب‌بندی

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

این واگرایی ساختاری است نه تصادفی. خفتگی یک وضعیت استفاده است که هر چیزی که تماس‌ها را ثبت می‌کند مشاهده می‌کند — یک API gateway، یک مخزن trace، داشبورد استفاده یک ارائه‌دهنده. مجوزدهی وضعیتی جداگانه است که در اختیار یک ارائه‌دهنده هویت، یک secrets manager، جدول grant یک پایگاه داده، یا سوابق OAuth یک فروشنده SaaS است. هیچ چیز این دو را مجبور به توافق نمی‌کند. یک عامل می‌تواند از تله‌متری ناپدید شود در حالی که توکنش ماه‌ها معتبر می‌ماند، و هیچ سیستم واحدی در موقعیتی نیست که این ناهماهنگی را متوجه شود.

بازبینی امنیتی این شکاف را به ارث می‌برد. پرسش معمول — آیا این عامل فعال است؟ — توسط پشته observability پاسخ داده می‌شود که شاهد اشتباهی است. پرسش باربر این است که عامل هنوز به چه چیزی می‌تواند دسترسی داشته باشد، و این را گراف مجوزدهی پاسخ می‌دهد. عاملی بدون ترافیک و با توکنی با دامنه نوشتن به یک CRM تولیدی، بازنشسته نیست. این یک principal بدون مراقبت است: مجموعه‌ای از مجوزهای دائمی بدون اپراتوری که آن را تماشا کند، بدون فرایندی که وصله شود، و بدون مالکی که اگر از آن استفاده می‌شد متوجه شود.

چرا عامل‌ها بدون از دست دادن دسترسی خفته می‌شوند

سه سازوکار بیشترین سهم را در این انحراف دارند، و هر سه مهندسی معمولی هستند نه سهل‌انگاری.

اولی تأمین یک‌باره است. bootstrap عامل غالباً اسکریپتی است که یک بار در طول نمونه اولیه نوشته می‌شود: توکنی می‌سازد، آن را در یک فایل محیطی یا یک secret store می‌نویسد، و خارج می‌شود. اسکریپت هیچ مفهومی از مالک ثبت‌شده و هیچ مفهومی از انقضا ندارد، چون در زمان نوشتنش انتظار می‌رفت عامل موقت باشد. توکن‌های طولانی‌عمر مسیر کمترین مقاومت هستند وقتی جایگزین، سیم‌کشی یک جریان تمدید در سیستمی است که ممکن است به هر حال به‌طور پیوسته اجرا نشود.

دومی توقف به‌جای حذف است. حذف یک عامل مستلزم دانستن این است که چه چیزی به آن وابسته است، و این دانش به‌ندرت مکتوب می‌شود. یک تعریف ابزار که عامل دیگری به آن ارجاع می‌دهد، یک هدف webhook، یک job زمان‌بندی‌شده، یک fixture تست — هر یک از این‌ها می‌تواند هنگام حذف یک principal بی‌صدا بشکند. توقف برگشت‌پذیر و ارزان است؛ حذف برگشت‌ناپذیر است و مستلزم فهرستی است که هیچ‌کس ندارد. اپراتورهای عقلانی توقف می‌کنند، و توقف بدون اینکه هرگز تصمیمی درباره‌اش گرفته شود دائمی می‌شود.

سومی اینرسی طرف مقابل است. یک اتصال باقی می‌ماند چون سیستم آن سر هیچ سیگنالی ندارد که عامل متوقف شده است. یک یکپارچه‌سازی SaaS یک refresh token را تا زمان لغو نگه می‌دارد. یک سرویس داخلی یک grant حساب سرویس را تا زمانی که کسی ACL را ویرایش کند نگه می‌دارد. سکوت خود عامل پیامی نیست که هیچ‌یک از این سیستم‌ها دریافت کند. بنابراین خفتگی از دیدگاه هر طرفی به‌جز طرفی که تماس را متوقف کرده نامرئی است.

یک زمان‌بندی بازپس‌گیری

راه اصلاح این است که انقضای اعتبارنامه را به‌عنوان یک رویداد زمان‌بندی‌شده چرخه حیات با همان جایگاه صدور بدانیم، و زمان‌بندی را قابل اجرا کنیم نه توصیه‌ای.

حداکثر عمر و مالک ثبت‌شده در زمان صدور. هر اعتبارنامه‌ای که برای یک عامل ساخته می‌شود دو ویژگی اجباری دارد: یک حداکثر عمر سخت، و یک مالک نام‌دار (یک تیم، یک rotation، یک نام مستعار on-call — نه حساب یک فرد). تمدید یک عمل صریح است که آن مالک انجام می‌دهد، نه یک refresh خودکار که بی‌صدا اعتبارنامه را تا ابد تمدید کند. عمرهای حداکثری کوتاه با تمدید ارزان پیش‌فرض را وارونه می‌کنند: اعتبارنامه منقضی می‌شود مگر اینکه کسی به‌طور ایجابی آن را زنده نگه دارد، که غفلت را به انقضا تبدیل می‌کند نه به دسترسی دائمی.

تشخیص خفتگی بر اساس تله‌متری آخرین تماس موفق. زنده‌بودن فرایند سیگنال اشتباهی است. کانتینری که در حال اجراست اما خطا می‌دهد، یا زمان‌بندگری که به مجوزی لغوشده شلیک می‌کند، زنده به نظر می‌رسد و از نظر عملکردی مرده است. سیگنالی که اهمیت دارد زمان آخرین تماس احراز هویت‌شده موفق است، تجمیع‌شده بر اساس اعتبارنامه نه بر اساس فرایند. آن زمان است که job بازپس‌گیری می‌خواند.

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

1. لغو دامنه‌های نوشتن. principal دسترسی خواندن را حفظ می‌کند، بنابراین هر مصرف‌کننده‌ای که فقط می‌خواند به کار خود ادامه می‌دهد، و هر مصرف‌کننده‌ای که می‌نویسد به‌طور بلند و قابل مشاهده در پنجره‌ای که کسی می‌تواند پاسخ دهد شکست می‌خورد.
2. لغو دامنه‌های خواندن. پس از یک دوره سکوت تعریف‌شده بدون حادثه، principal دسترسی به داده را کاملاً از دست می‌دهد. وابسته‌هایی که از مرحله یک جان سالم به در بردند اکنون آشکار می‌شوند.
3. حذف principal. هویت، عضویت‌های گروهی، ورودی‌های secret و grantهای طرف مقابل حذف می‌شوند، و حذف در همان audit log مراحل قبلی نوشته می‌شود.

طرحی از شیء policy که control plane ارزیابی می‌کند:

principal: agent.reporting.summariser
owner: team-data-platform
issued: 2025-02-11
max_lifetime: 90d
renewal: explicit
last_successful_call: 2025-03-04
stages:
  - revoke_write:  on_dormant(30d)
  - revoke_read:   on_dormant(60d)
  - delete:        on_dormant(90d)
log: audit.credentials

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

این چه چیزی را برای ناوگان تغییر می‌دهد

فهرست از یک لیست فرایند به یک گراف مجوزدهی تبدیل می‌شود. پرسش مفید درباره هر عامل این نیست که آیا در حال اجراست، بلکه این است که می‌تواند به‌عنوان کدام principalها عمل کند، آن principalها به کدام منابع دسترسی دارند، و هر یال متعلق به چه کسی است. با این شمارش، عامل‌های خفته اما متصل ارزان‌ترین سطح حمله در دارایی برای حذف هستند — بدون مهاجرت، بدون هماهنگی با یک مصرف‌کننده زنده، بدون پنجره تغییر — و همزمان کم‌ترین احتمال را برای جلب توجه دارند، چون هیچ چیز در عملیات عادی به آن‌ها دست نمی‌زند.

سیاست بازپس‌گیری نیز باید در همان control plane صدور باشد، نه در یک ممیزی فصلی. ممیزی نمونه‌برداری می‌کند؛ control plane اجرا می‌کند. اگر سیستمی که اعتبارنامه صادر می‌کند همان سیستمی باشد که آن را منقضی می‌کند، خفتگی به وضعیتی تبدیل می‌شود که پلتفرم با یک تایمر حل می‌کند نه یافته‌ای که بازبین مطرح می‌کند و تیم به تعویق می‌اندازد. نقش ممیزی به بررسی این تغییر می‌کند که زمان‌بندی اجرا شده و استثناها توجیه دارند، که کاری بسیار کوچک‌تر و قابل‌مدیریت‌تر از بازسازی این است که یک دارایی از عامل‌ها به چه چیزی می‌تواند دسترسی داشته باشد.

مرحله چرخه حیاتی که غایب بود

مدل‌های چرخه حیات عامل معمولاً از طراحی تا استقرار تا از رده خارج کردن را در بر می‌گیرند، با از رده خارج کردن به‌عنوان یک مرحله پاکسازی در پایان. یافته Arrakis نشان می‌دهد که مدل یک مرحله کم دارد: بازپس‌گیری، که از لحظه‌ای آغاز می‌شود که آخرین تماس موفق عامل عقب می‌نشیند و زمانی پایان می‌یابد که principal آن حذف شود. آن مرحله تله‌متری خودش، مالک خودش، زمان‌بندی خودش و مسیر ممیزی خودش را دارد. عاملی که پس از توقف کار کلیدهایش را نگه می‌دارد از رده خارج نشده است — بلکه در تنها معنایی که برای یک مهاجم اهمیت دارد، در حال اجرا رها شده است. بهداشت ناوگان همان تمرین توجه کردن، با یک تایمر، پیش از هر کس دیگری است.