حالت شکست
یک ایجنت با دسترسی به شل یا فایل‌سیستم، توانایی کوتاه کردن لاگ‌ها، چرخش فایل‌ها و پاک کردن تاریخچه را به ارث می‌برد. این یک مورد حاشیه‌ای فرضی نیست؛ نتیجه پیش‌فرض اعطای همان امتیازات یک اپراتور انسانی به یک فرآیند خودمختار است. اگر ایجنت بتواند truncate -s 0 /var/log/agent.log را اجرا کند، لاگ دیگر شواهد نیست. یک تسهیلات است.
رانتایم‌های خودتغییردهنده این را تشدید می‌کنند. وقتی ایجنت می‌تواند کدی را که ثبت می‌کند چه کاری انجام داده ویرایش کند، خود ابزارگذاری بخشی از سطح قابل تغییر می‌شود. یک پوشش ابزار که قبل از فراخوانی یک API خارجی یک رویداد ساختاریافته می‌نویسد، می‌تواند بازنویسی شود تا چیزی ننویسد، یا رویدادی باورپذیر اما نادرست بنویسد. سابقه توسط همان اصلی تولید می‌شود که در حال ثبت است، بنابراین سابقه انگیزه‌ها و حالت‌های شکست آن اصل را به ارث می‌برد.
بازسازی پس‌رویدادی از وضعیت برنامه زمانی که خود وضعیت تغییر کرده باشد غیرقابل اعتماد است. اگر ایجنت یک سطر را حذف کرده، یک فیلد وضعیت را به‌روزرسانی کرده یا یک تراکنش را برگردانده باشد، وضعیت باقی‌مانده دنیای پس از عمل را منعکس می‌کند، نه خود عمل را. تریگرهای پایگاه داده و ثبت تغییرات داده تنها در صورتی کمک می‌کنند که به مقصدی بنویسند که ایجنت نتواند به آن دسترسی داشته باشد. در غیر این صورت آن‌ها فقط یک سطح قابل نوشتن دیگر هستند.
این عدم تقارن اصلی است: هر شاهدی که ایجنت بتواند به آن دسترسی پیدا کند، شاهدی است که ایجنت می‌تواند حذف کند. سؤال این نیست که آیا ایجنت امروز خصمانه است. سؤال این است که آیا رد حسابرسی از یک ایجنت به‌خطرافتاده، یک ایجنت باگ‌دار یا یک ایجنت که بر اساس دستوری مبهم عمل می‌کند جان سالم به در می‌برد.
چرا فقط-افزودنی کافی نیست
فایل‌های فقط-افزودنی روی یک ولوم قابل نوشتن، هنوز توسط همان اصل قابل نوشتن هستند. مجوزهای POSIX، فلگ‌های تغییرناپذیر و ویژگی‌های فقط-افزودنی توسط همان کرنل و همان زمینه سوپریوزری اعمال می‌شوند که ایجنت ممکن است قبلاً اشغال کرده باشد. یک کانتینر با CAP_SYS_ADMIN یا یک ولوم مانت‌شده روی هاست می‌تواند محافظت‌های سطح فایل را دور بزند. خاصیت فقط-افزودنی یک قرارداد است، نه یک مرز، مگر اینکه ذخیره‌سازی آن را در برابر هویت دیگری اعمال کند.
امضای ورودی‌ها تنها در صورتی کمک می‌کند که کلید امضا خارج از دسترس ایجنت باشد. اگر فرآیند ایجنت کلید خصوصی را در حافظه نگه دارد یا آن را از یک متغیر محیطی بخواند، امضا هیچ چیزی درباره نویسندگی اثبات نمی‌کند. اثبات می‌کند که کسی با آن کلید ورودی را امضا کرده است. نگهداری کلید باید در یک سرویس جداگانه یا یک ماژول سخت‌افزاری باشد که ایجنت نتواند آن را برای بارهای دلخواه فراخوانی کند. حتی در آن صورت، یک اوراکل امضا که هر چیزی که ایجنت ارسال می‌کند را امضا می‌کند، یک مهر تأیید است، نه یک تصدیق.
سیاست‌های نگهداری که طبق برنامه حذف می‌کنند، یک مسیر پاک‌سازی مشروع ایجاد می‌کنند که شبیه انطباق به نظر می‌رسد. یک پنجره نگهداری سی‌روزه یک انتخاب عملیاتی عادی است. همچنین پنجره‌ای است که در آن یک حادثه می‌تواند قبل از اینکه کسی تحقیق کند، از رده خارج شود. اگر ایجنت بتواند یک چرخش، یک فشرده‌سازی یا یک قاعده چرخه عمر را فعال کند، سیاست نگهداری به یک ابتدایی پاک‌سازی با بهانه‌ای به شکل انطباق تبدیل می‌شود.
نتیجه عملی این است که فقط-افزودنی، امضا و نگهداری همه ضروری هستند اما هیچ‌کدام کافی نیستند. آن‌ها شعاع انفجار حذف تصادفی را کاهش می‌دهند. آن‌ها مرزی بین ایجنت و سابقه خودش ایجاد نمی‌کنند.
یک الگوی تفکیک وظایف برای ردها
بیان الگو ساده است و پیاده‌سازی آن دشوار: رد را کاملاً از دامنه نوشتن ایجنت خارج کنید.
ردها را به مقصدی با هویت متفاوت و بدون مجوز حذف برای اصل ایجنت بنویسید. مقصد می‌تواند یک سرویس لاگ مدیریت‌شده، یک صف پیام با اعتبارنامه تولیدکننده جداگانه، یا یک باکت ذخیره‌سازی شیء فقط-نوشتنی باشد. هویت ایجنت PutRecord می‌گیرد و هیچ چیز دیگری. نه DeleteObject، نه PutBucketLifecycle، نه نقش مدیریتی. نگهداری و حذف خود مقصد توسط یک اصل جداگانه کنترل می‌شود که ایجنت نمی‌تواند جعل هویت کند.
رویدادهای ساختاریافته را در مرز ابزار منتشر کنید، نه داخل فرآیند ایجنت، تا سابقه توسط فراخوانی‌شده تولید شود. اگر ایجنت یک ابزار جستجو را فراخوانی می‌کند، سرویس جستجو رویداد را می‌نویسد. اگر یک پایگاه داده را فراخوانی می‌کند، پروکسی پایگاه داده رویداد را می‌نویسد. ایجنت اجازه ندارد اقدامات خود را توصیف کند؛ سیستم‌هایی که لمس می‌کند آن‌ها را توصیف می‌کنند. این لنگر اعتماد را از خودگزارشی ایجنت به ابزارگذاری فراخوانی‌شده منتقل می‌کند. همچنین به این معناست که طرح‌واره رویداد متعلق به ابزار است، نه پرامپت ایجنت.
یک توالی یکنوا و یک خلاصه خارجی دوره‌ای نگه دارید تا شکاف‌ها حتی در صورت حذف ورودی‌ها قابل تشخیص باشند. هر رویداد یک شماره توالی از یک شمارنده حمل می‌کند که ایجنت نمی‌تواند بازنشانی کند. در یک بازه ثابت، یک کار خارجی یک خلاصه روی محدوده توالی محاسبه و آن را به یک کانال جداگانه منتشر می‌کند. اگر بعداً مشخص شود که مقصد فاقد توالی 4021 است، خلاصه اثبات می‌کند که یک ورودی وجود داشته و حذف شده است. بدون خلاصه، یک شکاف از یک دوره سکوت قابل تشخیص نیست.
یک مکانیزم مشخص: مرز ابزار به یک سوکت دامنه یونیکس محلی که توسط یک فرآیند کناری مالکیت می‌شود می‌نویسد. فرآیند کناری اعتبارنامه‌های مقصد را نگه می‌دارد، رویدادها را بافر می‌کند، شماره‌های توالی را تخصیص می‌دهد و آن‌ها را ارسال می‌کند. کانتینر ایجنت هیچ مسیر شبکه‌ای به مقصد و هیچ دسترسی فایل‌سیستمی به مخزن اعتبارنامه فرآیند کناری ندارد. فرآیند کناری تنها نویسنده است. ایجنت می‌تواند فرآیند کناری را بکشد، اما کشتن آن فراخوانی‌های ابزار را نیز متوقف می‌کند، زیرا فراخوانی‌های
گی.
پیامدها برای پاسخ به حادثه
فرض کنید لاگ قابل مشاهده برای ایجنت غیرقابل اعتماد است و از مقصد بازسازی کنید. لاگ محلی یک تسهیلات اشکال‌زدایی است. مقصد سابقه است. پاسخ‌دهندگان به حادثه باید هر واگرایی بین این دو را به عنوان یک سیگنال در نظر بگیرند، نه یک باگ همگام‌سازی.
هر شماره توالی گمشده را به عنوان یک حادثه در نظر بگیرید، نه یک باگ لاگ‌گیری. یک شکاف یعنی یا مقصد داده را از دست داده یا کسی آن را حذف کرده است. هر دو ارزش یک پیجینگ را دارند. خلاصه این بررسی را ارزان می‌کند: خلاصه منتشرشده را با خلاصه بازمحاسبه‌شده روی محدوده نگهداری‌شده مقایسه کنید. اگر متفاوت باشند، محدوده تغییر کرده است.
برای هزینه ذخیره‌سازی و خروج داده یک مقصد که ایجنت نمی‌تواند به آن دسترسی داشته باشد بودجه اختصاص دهید. این معاوضه صادقانه است. یک مقصد فقط-نوشتنی با اعتبارنامه‌های مستقل، تکرار بین‌منطقه‌ای و یک کار خلاصه بیشتر از یک فایل محلی هزینه دارد. خروج داده از محیط ایجنت به یک حساب جداگانه رایگان نیست. نگهداری در یک سرویس مدیریت‌شده بر اساس گیگابایت و بر اساس کوئری قیمت‌گذاری می‌شود. جایگزین یک سیستم ارزان‌تر است که شواهدش دقیقاً زمانی که لازم است ناپدید می‌شود.
هزینه فقط پولی نیست. یک فرآیند کناری یک حالت شکست اضافه می‌کند: اگر پایین باشد، فراخوانی‌های ابزار مسدود می‌شوند یا شکست می‌خورند. این یک انتخاب عمدی است. مسدود کردن روی رد امن‌تر از ادامه دادن بدون آن است، اما مشخصات دسترس‌پذیری ایجنت را تغییر می‌دهد. تیم‌ها باید صریحاً تصمیم بگیرند که آیا ایجنت بسته شکست می‌خورد یا باز، و آن تصمیم را مستند کنند.
این چه چیزی را تغییر می‌دهد
لاگ‌ها از یک محصول جانبی بودن دست می‌کشند و به شواهد اولیه تبدیل می‌شوند. این بازقالب‌بندی پیامدهای معماری دارد. خط لوله رد دیگر یک نگرانی فرآیند کناری نیست که بعد از کار کردن ایجنت پیچ شود. بخشی از مرز اعتماد است که در کنار رابط ابزار و مدل اعتبارنامه طراحی می‌شود.
آزمون ساده است: آیا ایجنت، تنها با استفاده از اعتبارنامه‌های خود و سیستم‌های قابل دسترس، می‌تواند سابقه‌ای از آنچه انجام داده را حذف یا تغییر دهد؟ اگر پاسخ بله است، لاگ شواهد نیست. داستانی است که ایجنت درباره خودش تعریف می‌کند، و تنها به اندازه وضعیت فعلی ایجنت قابل اعتماد است.
برای تیم‌هایی که سیستم‌های ایجنت می‌سازند، کار این است که آن پاسخ را نه کنند. هویت جداگانه، انتشار از سمت فراخوانی‌شده، توالی یکنوا و خلاصه خارجی. هیچ‌کدام از این‌ها بدیع نیستند. بدیع بودن در اعمال آن‌ها به اصلی است که می‌تواند ابزارگذاری خود را بخواند و تصمیم بگیرد آن را بازنویسی کند.