چرا سیاست ایستا برای عامل‌ها کافی نیست
یک سیاست خروجی ایستا فرض می‌کند مجموعه مقصدها پیش از اجرای عامل قابل دانستن است. برای جریان‌های کاری انسانی این فرض عمدتاً برقرار است: یک حساب سرویس به مجموعه‌ای ثابت از میزبان‌ها دسترسی دارد، یک توسعه‌دهنده به یک رجیستری بسته شناخته‌شده می‌رسد، یک cron job با یک پایگاه داده صحبت می‌کند. فهرست متناهی، قابل بازبینی و به‌کندی متغیر است.
عامل‌ها این فرض را می‌شکنند چون فراخوانی‌های ابزار در زمان اجرا ترکیب می‌شوند. مقصد غالباً مشتق می‌شود نه اعلام‌شده. یک مرحله بازیابی یک URL برمی‌گرداند، یک مرحله خلاصه‌سازی یک نام میزبان از آن URL استخراج می‌کند، و یک مرحله واکشی آن را فراخوانی می‌کند. هیچ مهندسی آن نام میزبان را در فایل سیاست ننوشته، چون هیچ مهندسی در زمان نگارش آن را نمی‌دانست. این فراخوانی به‌حکم ساختار مشروع است و برای فهرست پیش‌تأییدشده نامرئی است.
پاسخ معمول این است که فهرست را آن‌قدر گسترده کنیم تا از مسدود کردن دست بردارد. این شکست معکوس را تولید می‌کند: لیست مجازی که به‌قدر کافی گسترده باشد تا هر مقصد مشتق‌شده‌ای را بپذیرد، عملاً یک قاعده پذیرش همه‌چیز با چند مرحله اضافه است. سیاست هنوز شبیه یک کنترل به نظر می‌رسد، اما دیگر تمایز قائل نمی‌شود. بین این دو حالت شکست هیچ تنظیم ایستایی کار نمی‌کند، چون از سیاست خواسته شده به سؤالی پاسخ دهد که نمی‌تواند ببیند.
مشکل عمیق‌تر این است که مقصد واحد قضاوت اشتباهی است. همان نقطه پایانی می‌تواند بسته به بار داده و مرحله‌ای که آن را تولید کرده، بی‌خطر یا خصمانه باشد. فراخوانی یک سرویس فراداده داخلی وقتی پیکربندی را واکشی می‌کند روتین است و وقتی آرگومان یک مسیر اعتبارنامه باشد مشکل جدی است. درخواست به یک API شریک وقتی بدنه یک پرس‌وجوی وضعیت است اشکالی ندارد و وقتی بدنه شامل الحاق همه‌چیزی باشد که عامل در این نشست خوانده است، اشکالی دارد. فیلتر کردن فقط بر اساس میزبان، اطلاعاتی را که این موارد را از هم متمایز می‌کند دور می‌ریزد.
بازرسی قصد در زمان اجرا واقعاً چه چیزی را بررسی می‌کند
بازرسی قصد در زمان اجرا تصمیم را از کجا فراخوانی می‌رود به فراخوانی در تلاش برای انجام چه کاری منتقل می‌کند. این نیازمند نگاه کردن به چیزی بیش از مقصد است.
آرگومان‌ها، نه فقط مقصدها. پارامترها، شکل بار داده، و منشأ مقادیر. منشأ مهم‌ترین بخش است و بخشی که ابزارهای ایستا معمولاً فاقد آن هستند. اگر یک آرگومان به یک پیام کاربر ردیابی شود، یک نوع مقدار است. اگر به خروجی ابزاری ردیابی شود که محتوای نامعتبر خوانده است، نوع دیگری است. ردیابی این تبار از طریق مسیر، همان چیزی است که به یک بررسی اجازه می‌دهد پارامتری که کاربر فراهم کرده را از پارامتری که یک سند تزریق‌شده فراهم کرده تشخیص دهد.
موقعیت در توالی. یک فراخوانی نسبت به مسیری که آن را تولید کرده مشکوک است. خواندن یک مخزن اسرار بلافاصله پس از یک تلاش احراز هویت ناموفق، رویدادی متفاوت از خواندن آن به‌عنوان اولین مرحله یک اجرای تأمین است. همان فراخوانی، در موقعیتی متفاوت، معنای متفاوتی دارد. به همین دلیل بررسی‌های قصد به مسیر اخیر به‌عنوان ورودی نیاز دارند، نه فقط به یک فراخوانی ابزار واحد.
نرخ و تکرار. همان فراخوانی بی‌خطر چهل بار پشت سر هم، رویدادی متفاوت از همان فراخوانی یک بار است. تکرار غالباً همان سیگنالی است که شمارش را از یک جست‌وجوی واحد جدا می‌کند، و اندازه‌گیری آن ارزان است چون شمارنده از قبل در لایه ارکستراسیون وجود دارد.
یک مکانیزم مشخص که این‌ها را به هم می‌بندد: نگهداری یک گراف منشأ به‌ازای هر اجرا که در آن هر مقدار یک برچسب آلودگی حمل می‌کند که ثبت می‌کند کدام منابع در آن سهیم بوده‌اند. وقتی یک فراخوانی ابزار در آستانه اجراست، گارد یک بردار ویژگی از آرگومان‌های فراخوانی، برچسب‌های آلودگی روی آن آرگومان‌ها، موقعیت فراخوانی در مسیر، و نرخ فراخوانی اخیر به آن مقصد می‌سازد. یک طبقه‌بند کوچک آن بردار را امتیازدهی می‌کند. امتیاز، نه نام میزبان، چیزی است که سیاست بر آن عمل می‌کند. انتشار آلودگی بخش باربر است؛ بدون آن طبقه‌بند از نحو سطحی حدس می‌زند.
بودجه تأخیر
بررسی‌های قصد بین مدل و ابزار قرار می‌گیرند، پس هر میلی‌ثانیه به‌ازای هر مرحله پرداخت می‌شود. عاملی که ده‌ها فراخوانی ابزار در هر وظیفه انجام می‌دهد، هزینه گارد را ده‌ها بار می‌پردازد، و آن هزینه روی مسیر بحرانی است. گاردی که تأخیر محسوسی به هر فراخوانی اضافه می‌کند، محصول را تغییر می‌دهد، نه فقط وضعیت امنیتی را.
ساختار عملی لایه‌ای است. ابتدا اکتشاف‌های ارزان اجرا می‌شوند: کلاس مقصد، شکل آرگومان، وجود برچسب آلودگی، آستانه‌های نرخ فراخوانی. این‌ها جست‌وجوهای جدولی و مقایسه‌ها هستند، و اکثریت بزرگی از فراخوانی‌ها را بدون حضور مدل در حلقه حل می‌کنند. طبقه‌بندی گران فقط روی ابهام اجرا می‌شود، جایی که لایه ارزان نمی‌تواند تصمیم بگیرد. قاعده تشدید باید منتشر شود، نه ضمنی، چون تعریف می‌کند سیستم چه چیزی را می‌گیرد و چه چیزی را نمی‌گیرد. اگر قاعده این باشد که «وقتی هر آرگومانی برچسب آلودگی نامعتبر حمل می‌کند و مقصد خارج از کلاس داخلی است، تشدید کن»، این جمله‌ای است که یک اپراتور می‌تواند درباره‌اش استدلال کند و یک بازبین می‌تواند به چالش بکشد.
معاوضه صادقانه این است که لایه‌بندی تأخیر را با پوشش می‌خرد. فراخوانی‌ای که لایه ارزان تأیید می‌کند هرگز به طبقه‌بند نمی‌رسد، پس هر چیزی که اکتشاف‌ها نسبت به آن کور هستند، به‌حکم طراحی از دست می‌رود. سخت‌تر کردن قاعده تشدید برای گرفتن بیشتر یعنی پرداخت هزینه طبقه‌بند بیشتر. هیچ تنظیمی هم‌زمان حداکثر سرعت و حداکثر حساسیت نیست؛ انتخاب باید صر
هزینه اشتباه کردن نیز به شکلی نامتقارن است که تفکر مبتنی بر هشدار آن را پنهان می‌کند. مثبت‌های کاذب را در مراحل عامل اندازه بگیرید، نه در هشدارها. یک مرحله مسدودشده می‌تواند یک اجرای کامل را بی‌اعتبار کند: عامل یک نتیجه ابزار را از دست می‌دهد، مسیر از ریل خارج می‌شود، و وظیفه یا شکست می‌خورد یا با نتیجه‌ای تنزل‌یافته کامل می‌شود که کاربر نمی‌تواند آن را از یک نتیجه درست تشخیص دهد. گاردی که بیش از حد شلیک می‌کند صفی از هشدارها برای بررسی تولید نمی‌کند؛ شکست‌های خاموشی تولید می‌کند که شبیه خطاهای مدل به نظر می‌رسند. به همین دلیل بودجه مثبت کاذب برای یک گارد عامل تنگ‌تر از یک کنترل شبکه متعارف است، و به همین دلیل تصمیمات گارد باید در ردپای اجرا قابل مشاهده باشند.
عملیاتی کردن مدل
طبقه‌بند یک مصنوع یک‌باره نیست. مدل قصد را در کنار عامل نسخه‌بندی کنید. یک تغییر سیاست یک استقرار است: با نسخه عامل ارسال می‌شود، در ردپای اجرا ثبت می‌شود، و به همان شکل قابل بازگردانی است. برخورد با سیاست به‌عنوان پیکربندی‌ای که مستقل از عامل منحرف می‌شود، همان چیزی است که باعث می‌شود گاردها قواعدی را اجرا کنند که هیچ‌کس به یاد نمی‌آورد نوشته است.
یک حالت سایه نگه دارید که مسدودسازی‌های بالقوه را بدون اجرا ثبت می‌کند، و اختلاف را هفتگی بازبینی کنید. حالت سایه تنها راه یادگیری نرخ مثبت کاذب گارد پیش از آن است که شروع به هزینه‌تراشی برای اجراها کند. بازبینی هفتگی جایی است که قاعده تشدید تنظیم می‌شود، و جایی که انحراف در الگوهای استفاده از ابزار عامل پیش از تبدیل شدن به یک حادثه ظاهر می‌شود.
حوادث تأییدشده را به‌عنوان مسیرهای برچسب‌خورده بازخوران کنید. مجموعه آموزش طبقه‌بند همان گزارش حادثه است، یعنی فرایند بازبینی حادثه و فرایند آموزش مدل یک فرایند واحد هستند. هر حادثه تأییدشده به یک نمونه مثبت با مسیر ضمیمه‌اش تبدیل می‌شود؛ هر مسدودسازی حالت سایه که بازبینی آن را رد کند به یک نمونه منفی تبدیل می‌شود. این حلقه را می‌بندد و مدل را بدون تلاش جداگانه جمع‌آوری داده که کسی نگهداری‌اش نکند به‌روز نگه می‌دارد.
معاوضه اینجا بار عملیاتی است. گاردی که از حوادث یاد می‌گیرد نیازمند بازبینی حادثه به‌موقع و سازگار است، و این یک تعهد مستمر است نه یک پروژه. تیم‌هایی که نمی‌توانند آن را حفظ کنند، با یک لایه اکتشافی ساده‌تر و خوب‌فهم‌شده بهتر خدمت می‌گیرند تا با طبقه‌بندی که بی‌صدا از تاریخ خارج می‌شود.
چه چیزی از این برداشت کنیم
لیست‌های مجاز ایستا غلط نیستند؛ کم‌برازش هستند. آن‌ها به سؤالی درباره مقصدها پاسخ می‌دهند در حالی که ریسک در آرگومان‌ها، منشأ و توالی زندگی می‌کند. بازرسی قصد در زمان اجرا به سؤال درست پاسخ می‌دهد، اما تنها اگر سیگنال قصد به‌قدر کافی ارزان باشد که روی مسیر داغ ارزیابی شود. بررسی‌ها را لایه‌بندی کنید، قاعده تشدید را منتشر کنید، مثبت‌های کاذب را در اجراهای بی‌اعتبارشده اندازه بگیرید نه در هشدارها، و مدل را با عامل نسخه‌بندی کنید. ویژگی امنیتی این نیست که هر فراخوانی پیش‌تأییدشده است. این است که هر فراخوانی در بافت قضاوت می‌شود، با هزینه‌ای که عامل می‌تواند در هر مرحله بپردازد.