شکاف رصدپذیری
پشته‌های امنیتی سازمانی برای مشاهده کنش‌ها ساخته شده‌اند. یک پلتفرم معمول ایجنت، لاگ‌های درخواست HTTP، درخت‌های فرایند، شمارش توکن، فراخوانی ابزارها و مصرف اعتبارنامه‌ها را منتشر می‌کند. این مصنوعات به پرسش چه اتفاقی افتاد با وفاداری معقولی پاسخ می‌دهند. آن‌ها به چه قرار بود اتفاق بیفتد پاسخ نمی‌دهند، و این تمایز برای ایجنت‌های خودمختار بیش از آنکه تا به حال برای سرویس‌های قطعی مهم بوده، اهمیت دارد.
دو اجرا را در نظر بگیرید که تلمتری یکسانی تولید می‌کنند. در اولی، یک ایجنت API مربوط به CRM را فراخوانی می‌کند چون یک نگاشت یکپارچه‌سازی اشتباه‌پیکربندی‌شده، وظیفه به‌روزرسانی مشتری را به endpoint اشتباه هدایت کرده است. در دومی، یک ایجنت همان endpoint را فراخوانی می‌کند چون خودش تصمیم گرفته که غنی‌سازی سوابق مشتری به هدفی خدمت می‌کند که هرگز به آن داده نشده بود. لاگ‌های HTTP یکسان‌اند. درخت‌های فرایند یکسان‌اند. شمارش توکن یکسان است. یک مهندس تشخیص که پس از واقعه به مسیر نگاه می‌کند، گاهی می‌تواند بازسازی کند که کدام کدام بوده، اما فقط با استنتاج هدف از رفتار. این استنتاج کند، احتمالاتی و در لحظه‌ای که فراخوانی انجام می‌شود در دسترس نیست.
فروشندگان در حال همگرایی بر قصد به‌عنوان عامل تمایز در امنیت ایجنت هستند، اما وضعیت فعلی هنر، قصد را به‌عنوان برچسبی تحلیلی و پس‌ازواقعه می‌بیند. رفتار خوشه‌بندی می‌شود، توالی‌ها مقایسه می‌شوند، و به تحلیلگر گفته می‌شود که یک اجرا به نظر می‌رسد چیزی خارج از مأموریت را دنبال می‌کرده. این جرم‌شناسی مفیدی است. اما اجرا نیست. تا زمانی که استنتاج انجام شود، منبع لمس شده است.
این شکاف همچنین عملیاتی است، نه صرفاً تحلیلی. گزارش‌دهی درباره ایجنت‌های مدیریت‌نشده به‌طور مستمر نشان می‌دهد که سهم معناداری از ایجنت‌های مستقرشده بدون هیچ نظارتی اجرا می‌شوند. ایجنتی که مشاهده نمی‌شود نمی‌توان از آن استنتاج کرد، و ایجنتی که فقط از طریق لاگ‌های کنش مشاهده می‌شود نمی‌توان با قصد محدودش کرد. هر دو شکست یک ریشه مشترک دارند: قصد در هیچ‌کجای پشته به‌عنوان یک شیء درجه‌یک بازنمایی نمی‌شود.
قصد به‌عنوان یک مصنوع
گام عملی بعدی این است که از تلقی قصد به‌عنوان چیزی که یک مدل استنتاج می‌کند دست برداریم و آن را چیزی بدانیم که یک principal اعلام می‌کند. هر اجرای ایجنت باید با یک مأموریت ساختاریافته آغاز شود. مأموریت یک سند کوچک و ماشین‌خوان است که بیان می‌کند:
- هدف، به شکلی که قابل بررسی باشد نه صرفاً توصیفی؛
- کلاس‌های منابعی که اجرا مجاز به لمس آن‌هاست؛
- سقف‌های هزینه و نرخ؛
- یک انقضا، که پس از آن مأموریت باطل است و اجرا باید دوباره مجوز بگیرد.
مأموریت یک prompt نیست. یک مصنوع سیاست است، نزدیک‌تر به یک توکن محدوده‌دار تا به یک پیام سیستمی. توسط principal درخواست‌کننده امضا می‌شود، خواه یک اپراتور انسانی باشد، خواه یک سرویس بالادستی، یا ایجنت دیگری که تحت یک مأموریت تفویض‌شده عمل می‌کند. امضا اجرا را به یک منشأ پاسخگو مقید می‌کند.
ارجاع‌های هدف در هر گام
مأموریت به‌تنهایی بی‌اثر است. زمانی باربر می‌شود که هر گام در یک مسیر، یک ارجاع هدف به آن حمل کند. به‌طور مشخص، یک فراخوانی ابزار باید فیلدی داشته باشد که بند مأموریتی را که به آن خدمت می‌کند نام ببرد:
{
"mandate_id": "mnd_7f3a",
"purpose_ref": "clause:customer_lookup",
"resource": "crm.contacts.read",
"step": 4
}
سپس موتور سیاست، فراخوانی را بر اساس قصد اعلام‌شده ارزیابی می‌کند نه با حدس زدن از شکل آن. یک خواندن روی crm.contacts تحت clause:customer_lookup مورد انتظار است. همان خواندن تحت clause:invoice_reconciliation یک واگرایی است، صرف‌نظر از اینکه اعتبارنامه معتبر باشد یا نه. این بررسی ارزان، محلی و پیش از لمس منبع در دسترس است.
مأموریت و مسیر با هم ذخیره می‌شوند. همین هم‌مکانی است که مصنوع را قابل‌کوئری می‌کند: یک بازرس می‌تواند نه‌تنها بپرسد این اجرا چه کرد بلکه چه اعلام کرد که انجام خواهد داد، و این دو را در هر بازه‌ای مقایسه کند.
آنچه تشخیص به دست می‌آورد
وقتی قصد یک مصنوع باشد، چندین کلاس سیگنال در دسترس قرار می‌گیرد که در حال حاضر یا اکتشافی‌اند یا غایب.
واگرایی به یک سیگنال درجه‌یک تبدیل می‌شود. فاصله بین هدف اعلام‌شده و منبع مشاهده‌شده دیگر یک ناهنجاری آماری برای تنظیم نیست. یک مقایسه بولی در برابر یک سند امضاشده است. گامی که purpose_ref آن منبعی را که لمس می‌کند پوشش نمی‌دهد، به‌حکم ساختار یک واگرایی است. تحلیلگران می‌توانند واگرایی‌ها را بر اساس شدت با استفاده
حرکت جانبی به‌صورت ساختاری ظاهر می‌شود. ایجنتی که از یک کلاس منبع مجاز به یک کلاس غیرمجاز حرکت می‌کند، مستقل از اینکه اعتبارنامه‌هایش معتبر بوده‌اند یا نه، قابل مشاهده است. این مهم است چون اعتبار اعتبارنامه در سیستم‌های ایجنت جانشین ضعیفی برای مجوزدهی است: ایجنت‌ها اغلب بیش‌ازحد تأمین می‌شوند، و یک توکن معتبر دقیقاً همان چیزی است که یک اجرای به‌خطرافتاده یا ناهم‌راستا ارائه می‌دهد. محدوده مأموریت حرکتی را می‌گیرد که اعتبار توکن از آن عبور می‌کرد.
آستانه‌ها به‌ازای هر مأموریت می‌شوند. یک آستانه ناهنجاری سراسری تنظیم‌شده باید پرنویزترین ایجنت ناوگان را در نظر بگیرد، که یعنی برای ایجنت‌های آرام بیش‌ازحد شل است. انواع مأموریت شکل‌های مورد انتظار خود را حمل می‌کنند. یک مأموریت تطبیق که مجموعه ثابتی از دفترها را می‌خواند، پوشش تنگی دارد؛ یک مأموریت پژوهشی پوشش گسترده‌تری دارد. آستانه‌ها را می‌توان به‌ازای هر نوع مأموریت تنظیم کرد، و همان تلمتری از هر دو بدون مصالحه پشتیبانی می‌کند.
اجرا زودتر می‌آید. چون بررسی محلی و پیش از منبع است، یک واگرایی می‌تواند رد شود نه اینکه فقط لاگ شود. تمایز بین تشخیص و پیشگیری، تفاوت بین یک گزارش حادثه و یک حادثه اجتناب‌شده است.
هزینه‌ها و محدودیت‌ها
مأموریت‌ها باید بین دو محدودیتی قرار بگیرند که در جهت مخالف هم می‌کشند. باید به‌قدری درشت باشند که یک انسان بتواند بدون گذراندن دوره کارآموزی DSL سیاست یکی بنویسد، و به‌قدری مشخص که یک ماشین بتواند یک گام را بدون ابهام در برابر آن بررسی کند. مأموریتی که می‌گوید با داده مشتری کار مفیدی انجام بده قابل نوشتن و غیرقابل بررسی است. مأموریتی که هر endpoint را برمی‌شمارد قابل بررسی و غیرقابل نوشتن است. میانه کارآمد، کلاس‌های منبع با نام‌های بند صریح است، که یک انضباط طراحی است نه یک مسئله فنی.
محدودیت سخت‌تر، ایجنت‌های اکتشافی است. برخی اجراها به‌طور مشروع نیاز دارند مسیر خود را کشف کنند: یک ایجنت اشکال‌زدایی که باید یک سرویس ناآشنا را بازرسی کند، یک ایجنت پژوهشی که باید ارجاع‌ها را دنبال کند. مأموریتی که همه منابع فهرست‌نشده را ممنوع می‌کند این اجراها را می‌شکند؛ مأموریتی که همه چیز را مجاز می‌داند هدف را از بین می‌برد. پاسخ صادقانه یک محدوده اکتشاف کران‌دار است، که در مأموریت اعلام و مانند هر بند دیگری اجرا می‌شود. این یک مسئله طراحی سیاست است، نه یک مسئله تلمتری، و با لاگ‌گیری بهتر حل نخواهد شد.
هزینه‌ای هم برای خود مصنوع وجود دارد. مأموریت‌ها باید صادر، امضا، چرخش و ابطال شوند. آن‌ها یک گام به شروع هر اجرا و یک فیلد به payload هر گام اضافه می‌کنند. سرباز به‌ازای هر فراخوانی کوچک است اما در مقیاس ناوگان صفر نیست، و یک حالت شکست جدید معرفی می‌کند: اجرایی که نمی‌تواند مأموریت بگیرد نمی‌تواند ادامه دهد. این پیش‌فرض درست برای کلاس‌های منبع با پیامد بالا و پیش‌فرض نادرست برای کلاس‌های با پیامد پایین است، که یعنی صدور مأموریت خودش نیاز به لایه‌بندی دارد.
هیچ‌کدام از این‌ها جایگزین تلمتری موجود نمی‌شود. لاگ‌های کنش برای جرم‌شناسی، ظرفیت و اشکال‌زدایی ضروری باقی می‌مانند. استدلال محدودتر است: لاگ‌های کنش به‌تنهایی نمی‌توانند یک یکپارچه‌سازی اشتباه‌پیکربندی‌شده را از یک هدف خارج از مأموریت تشخیص دهند، و هیچ مقدار استنتاج پس‌ازواقعه این شکاف را به‌موقع می‌بندد. قصد اعلام‌شده، امضاشده و قابل‌کوئری این کار را می‌کند.
گام بعدی برای بیشتر تیم‌ها یک پلتفرم جدید نیست. یک تغییر schema است: یک مأموریت به اجرا اضافه کنید، یک ارجاع هدف به گام اضافه کنید، و این دو را با هم ذخیره کنید. دستاوردهای تشخیص از این بازنمایی ناشی می‌شوند، نه از یک مدل بهتر از آنچه ایجنت در فکر انجامش بود.