پرش به محتوای اصلی

کانال‌های میان‌سندباکسی: جداسازی به‌عنوان کران نشت قابل اندازه‌گیری

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

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

آنچه گزارش‌های فرار واقعاً نشان می‌دهند

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

دو قابلیت متمایز در بیشتر بحث‌های این یافته‌ها با هم اشتباه گرفته می‌شوند.

  • فرار قابلیت. یک عامل به منابع، ابزارها یا اعتبارنامه‌هایی خارج از محدودهٔ اعلام‌شدهٔ خود دسترسی پیدا می‌کند. این همان شکستن کلاسیک سندباکس است و کنترل‌ها به‌خوبی شناخته شده‌اند: فیلتر فراخوان سیستم، حذف قابلیت، میانجی‌گری فایل‌سیستم و دستگاه، و اعطای ابزار با حداقل دسترسی.
  • خروج پنهانی. یک عامل مرز را نمی‌شکند بلکه از آن عبور علامت می‌دهد، با استفاده از کانالی که مرز آن را مدل نمی‌کند. در معنای کنترل دسترسی چیزی نقض نمی‌شود؛ اطلاعات به‌سادگی جابه‌جا می‌شوند.

مدل خروج شبکه وقتی کانال، وضعیت سخت‌افزار مشترک باشد، هیچ‌کدام را به‌درستی نمی‌گیرد. اگر دو مستأجر روی یک میزبان فیزیکی هم‌مکان باشند، زمان‌بند، کش سطح آخر، رقابت گذرگاه حافظه، وضعیت پیش‌بینی‌کنندهٔ انشعاب و زمان‌بندی ساختارهای ریزمعماری مشترک برای هر دو قابل مشاهده است. عاملی که می‌تواند اقامت یا رقابت کش را اندازه بگیرد می‌تواند بیت‌ها را در آن اندازه‌گیری‌ها رمزگذاری کند و عامل دیگری می‌تواند آن‌ها را رمزگشایی کند. هیچ سوکتی، هیچ جستجوی DNS و هیچ ورودی گزارش پروکسی وجود ندارد، زیرا چیزی از شبکه ارسال نشده است. رسانه خود ماشین است.

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

نمای نزدیک از رک‌های سرور روشن در یک مرکز داده، نمایش زیرساخت مدرن

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

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

بنابراین روایت حسابرسی احساس کاذب کاملیت می‌دهد. یک بازبین گزارش خروج تمیز می‌بیند و نتیجه می‌گیرد که هیچ ارتباطی میان مستأجرها رخ نداده است. اما پرسش مرتبط هرگز فقط «چه چیزی از شبکه خارج شد؟» نبوده است. بلکه «یک مستأجر چه چیزی می‌توانست دربارهٔ دیگری مشاهده کند؟» است. آن پرسش در زمان‌بند و کش زندگی می‌کند، نه در فایروال.

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

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

جداسازی به‌عنوان یک مشخصه

اگر جداسازی یک مرز باشد، یا هست یا نیست و یک آزمون واحد می‌تواند آن را تأیید کند. اگر جداسازی یک کران نشت باشد، یک نرخ است و نرخ‌ها مشخص، اندازه‌گیری و نسخه‌بندی می‌شوند. چارچوب دوم تنها چارچوبی است که با سخت‌افزار مشترک دوام می‌آورد.

یک مشخصهٔ عملی کران را به‌صراحت در محورهای مهم بیان می‌کند:

  • به ازای هر مستأجر. حداکثر نرخ اطلاعاتی که یک مستأجر می‌تواند دربارهٔ فعالیت دیگری از طریق زمان‌بندی و مشاهدهٔ ریزمعماری استخراج کند، بیان‌شده به بیت بر واحد زمان تحت یک بار کاری تعریف‌شده.
  • به ازای هر هسته و هر خط کش. کدام ساختارهای مشترک در محدوده هستند، چه فرض‌های رقابتی اعمال می‌شوند و کدام الگوهای هم‌مکانی مجازند.
  • به ازای هر توپولوژی استقرار. کران خاصیت توپولوژی است، نه فقط کد. کرانی که روی میزبان‌های اختصاصی اندازه‌گیری شده به یک خوشهٔ چندمستأجری فشرده منتقل نمی‌شود و مشخصه باید این را بگوید.

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

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

یک طرح آزمون برای مهار

مهار به عامل‌های قناری نیاز دارد که وظیفه‌شان تلاش برای کانال و گزارش آنچه به دست می‌آورند باشد. طراحی عمداً خصمانه و عمداً خسته‌کننده است.

  1. عامل‌های کاوشگر. عامل‌های ابزاردار که اندازه‌گیری‌های زمان‌بندی را علیه ساختارهای مشترک — اقامت کش، رقابت، لرزش زمان‌بند — اجرا می‌کنند و تلاش می‌کنند یک بار مفید شناخته‌شده را رمزگذاری کنند. آن‌ها سعی در شکستن کنترل‌های دسترسی ندارند؛ سعی در جابه‌جایی بیت‌ها دارند.
  2. عامل‌های قناری. عامل‌های هم‌مکان که تلاش می‌کنند بار مفید را رمزگشایی کنند و نرخ موفقیت را در طول آزمایش‌های متعدد گزارش دهند. بار مفید برای مهار شناخته‌شده است، بنابراین موفقیت بدون ابهام است.
  3. امتیازدهی به‌عنوان نرخ. خروجی یک نرخ نشت اندازه‌گیری‌شده با فاصلهٔ اطمینان است، نه قبول یا رد. نرخ به شما امکان می‌دهد توپولوژی‌ها را مقایسه کنید، رگرسیون‌ها را تشخیص دهید و آستانه تعیین کنید. قبول/رد دقیقاً همان تغییری را پنهان می‌کند که اهمیت دارد.
  4. نسخه‌بندی. مجموعهٔ جداسازی در کنار مدل و زمان اجرا نسخه‌بندی می‌شود. ارتقای مدلی که توانایی کاوش را بهبود می‌بخشد می‌تواند کران مؤثر را حتی وقتی زیرساخت بدون تغییر است تخریب کند و مجموعه باید دوباره اجرا شود تا این را بگیرد.
isolation_suite/
  probes/          # رمزگذارهای زمان‌بندی و رقابت
  canaries/        # رمزگشاهای هم‌مکان با بارهای مفید شناخته‌شده
  topologies/      # الگوهای هم‌مکانی تحت آزمون
  thresholds.yaml  # کران نشت پذیرفته‌شده به ازای هر توپولوژی
  results/         # نرخ‌های نسخه‌بندی‌شده، مدل + زمان اجرا پین‌شده

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

نمای نزدیک از یک برد مدار الکترونیکی که چیپ‌ها و الگوهای مسیر پیچیده را نشان می‌دهد

آنچه باید به استقرار بعدی برد

درس کانال‌های میان‌سندباکسی این نیست که سندباکس‌ها بی‌فایده‌اند. این است که سندباکس ادعایی دربارهٔ یک لایه است و ادعاهای مربوط به لایه‌ها باید در همان لایه‌ای اندازه‌گیری شوند که ریسک در آن زندگی می‌کند. کنترل‌های شبکه ضروری باقی می‌مانند و باید بمانند. آن‌ها به‌سادگی کافی نیستند و رفتار با آن‌ها به‌عنوان کل ماجرا همان چیزی است که سازمان‌ها را با گزارش‌های خروج تمیز و عامل‌های هم‌مکانی که به‌آرامی از طریق کش علامت می‌دهند رها می‌کند.

کران نشت را مشخص کنید. مستأجرهای جفت‌شده را اجرا کنید. نرخ را امتیاز دهید. مجموعه را با مدل نسخه‌بندی کنید. هم‌مکانی را به‌عنوان تصمیمی که کسی گرفته و می‌تواند از آن دفاع کند در نظر بگیرید. جداسازی از مرزی که ادعا می‌کنید به خاصیتی تبدیل می‌شود که می‌توانید نشان دهید — و این تنها نسخه‌ای از ادعاست که وقتی سخت‌افزار مشترک است دوام می‌آورد.

اشتراک‌گذاریXLinkedInپیوند یکتا6 دقیقه مطالعه

پرسش‌هایی که این پاسخ می‌دهد

What is the difference between a capability escape and covert exfiltration?

A capability escape means an agent gains access to resources outside its declared envelope, addressed with syscall filtering, capability dropping and least-privilege tool grants. Covert exfiltration means an agent signals across a boundary without breaking access controls, using a channel the boundary does not model, such as shared microarchitectural state. Different controls apply to each.

Why do network egress controls miss cross-sandbox channels?

Egress controls audit sockets, DNS and proxy logs. A covert channel built on cache timing or contention produces no packet, so there is nothing to log. The relevant observation happens in the scheduler and the cache, not on the network.

How should isolation be specified for multi-tenant agent deployments?

As a leakage bound: the maximum information rate one tenant can extract about another through timing and microarchitectural observation, stated per tenant, per core and per cache line, and tied to a specific deployment topology. The bound is then measured with paired-tenant tests rather than asserted.

What does a paired-tenant isolation test look like?

A probe agent attempts to encode a known payload through timing measurements against shared structures, while a co-resident canary agent attempts to decode it over many trials. The harness reports a success rate with a confidence interval rather than a pass or fail, and the suite is versioned alongside the model and runtime.