Перейти к основному содержимому

Контейнмент на основе политик: что может и чего не может решать OS-энфорсер

Контейнмент на уровне хоста обеспечивает соблюдение границ ресурсов и файловой системы, но не может судить, была ли авторизована операция агента. Разделяйте слои принуждения и авторизации.

A close-up view of a neoclassical building facade featuring detailed arches and columns.

Два вопроса, которые контейнмент смешивает

Контейнмент отвечает на узкий, механический вопрос: к чему может получить доступ этот процесс? Авторизация отвечает на другой вопрос: была ли эта операция в рамках делегированного мандата? Это не один и тот же вопрос, и OS-энфорсер не предназначен для ответа на второй.

Примитив уровня хоста, такой как Windows Execution Containers или более старые механизмы Job Object и AppContainer, на которых он строится, работает с системными вызовами, дескрипторами, токенами и SID. Он видит процесс, запрашивающий дескриптор файла, ключ реестра, сетевой сокет, выделение памяти. Он не видит намерения, области задачи, согласия пользователя или разницы между агентом, законно редактирующим документ в своём назначенном рабочем пространстве, и тем же агентом, эксфильтрующим этот документ из-за перенаправления через инъекцию промпта. У ядра нет представления о том, что «эта операция была в рамках мандата». У него есть только представление о том, что «этот дескриптор был предоставлен или отклонён».

Это различие важно, потому что команды под давлением сроков часто его стирают. Настраивается песочница, песочница блокирует запись за пределами каталога, и команда делает вывод, что управление обеспечено. На самом деле построена граница изоляции. Журнал аудита авторизации — кто что одобрил, в рамках какой задачи, с какими классами данных — теперь живёт в конфигурации песочницы или, что хуже, ни в чьём слое вообще. Когда разбор инцидента спрашивает, почему агент прочитал запись клиента, на которую у него не было никаких прав, ответа в журнале контейнмента нет. Журнал контейнмента показывает только то, что чтение прошло успешно.

Где на самом деле проходит граница

Close-up of hands signing a contract on a desk with office supplies, symbolizing legal agreements.

У этих двух слоёв противоположные сильные стороны. Примитивы уровня ядра сильны в изоляции и слабы в семантике. Контейнер может надёжно запретить процессу запись в C:\\Windows\\System32, открытие сырого сокета или порождение дочернего процесса, наследующего его токен. Он не может сказать, должен ли был процесс это делать. Политические движки — обратная ситуация: сильны в семантике, слабы в принуждении. Политический движок может оценить «этот агент имеет грант для задачи invoice-reconcile-4417 с областью действия в классе данных финансов, истекающий через пятнадцать минут» и решить, что чтение реестра поставщиков входит в область действия. Он не может сам по себе остановить системный вызов. Если политический движок обойдён или к нему обращаются постфактум, запись уже произошла.

Таким образом, интерфейс между ними — это и есть та проектная поверхность, которая имеет значение. Статический список разрешений — фиксированный набор путей и хостов, которые песочница допускает — это неправильная форма, потому что в нём нет понятия задачи, нет срока действия и нет способа выразить, что один и тот же агент должен иметь разные права для разных работ. Правильная форма — это подписанный грант возможностей: структурированный токен, выпущенный политическим слоем, предъявленный слою принуждения и проверенный в точке использования. Грант несёт как минимум идентификатор задачи, область действия (какие классы данных, какие пути, какие сетевые назначения), срок действия и терминальное состояние. Слой принуждения проверяет подпись и область действия; он не переинтерпретирует мандат.

Это близко к модели возможностей, которую операционные системы используют десятилетиями, применённой к рабочим нагрузкам агентов. Политический слой становится эмитентом возможностей; слой ОС становится монитором ссылок. Ни один из них не достаточен в одиночку.

Правила проектирования многослойного контейнмента

Каждый грант несёт область задачи, классы данных и терминальное состояние. Грант, который говорит «этот агент может читать D:\\data», — это не грант; это постоянная дыра. Грант, который говорит «задача invoice-reconcile-4417 может читать класс данных finance-vendor-ledger до 14:32 UTC, после чего возможность отзывается и процесс завершается», поддаётся аудиту. Терминальное состояние важно так же, как и область действия: агент, завершивший свою задачу, не должен сохранять живую возможность, потому что скомпрометированный или галлюциниру

Explore the stunning architecture of Budapest's Parliament Building, a UNESCO World Heritage Site in Hungary.

Запрещать по умолчанию на уровне ОС; авторизовать по исключению на уровне политики. Контейнер должен запускаться без доступа к файловой системе, сети или устройствам и получать возможности только через интерфейс грантов. Политический слой также должен исходить из позиции запрета и выдавать гранты только тогда, когда определение задачи, метка классификации данных и запись согласия пользователя или сервиса совпадают. Это инвертирует распространённый шаблон, где песочница разрешающая, а политический слой — запоздалая мысль для логирования.

Логируйте грант и решение о принуждении отдельно. Это два разных события с двумя разными владельцами. Журнал грантов фиксирует, что политический слой выдал возможность для задачи X, области Y, срока Z, на основании записи согласия W. Журнал принуждения фиксирует, что слой ОС разрешил или отклонил конкретный запрос дескриптора в рамках этой возможности. Когда происходит инцидент, журнал грантов отвечает на вопрос «было ли это авторизовано?», а журнал принуждения отвечает на вопрос «выдержала ли граница?». Их слияние в один поток лишает возможности отнести сбой к политическому слою или слою принуждения, а именно эта атрибуция и нужна во время разбора.

Честный компромисс

Многослойный контейнмент стоит задержки и сложности. Каждая проверка возможности — это обращение к политическому слою или валидация подписанного токена, и каждой задаче нужен жизненный цикл гранта с выдачей, обновлением и отзывом. Команды, которые это пропускают и полагаются на одну разрешающую песочницу, выпускают быстрее и какое-то время выглядят работающими. Режим отказа — не драматичное нарушение; это медленное накопление постоянных разрешений, которые никто не может перечислить, за которым следует инцидент, где журнал контейнмента полон, а запись авторизации пуста.

Неудобная часть в том, что OS-энфорсер никогда не сможет решать авторизацию, потому что авторизация — это утверждение о человеческом намерении и организационном мандате, а у ядра нет доступа ни к тому, ни к другому. Лучшее, что он может сделать, — это исполнять решение, принятое в другом месте, добросовестно и быстро. Проектирование интерфейса между двумя слоями — формат гранта, точка валидации, путь отзыва, раздельные журналы — и есть настоящая инженерная работа. Отношение к песочнице как к средству управления — это короткий путь, который переносит журнал аудита из политического слоя в конфигурационный файл, который никто не проверяет.

Полезный тест: возьмите любое действие агента, которое ваша система допускает сегодня, и задайте два вопроса. Какой слой решил, что оно разрешено, и какой слой сделал его возможным? Если на оба вопроса отвечает один и тот же слой, граница не многослойна, и следующему разбору инцидента придётся реконструировать авторизацию из журналов принуждения, которые никогда не предназначались для этого.

ПоделитьсяXLinkedInПостоянная ссылка5 мин чтения

Связанное чтение

На какие вопросы это отвечает

Can a sandbox alone govern what an LLM agent is allowed to do?

No. A sandbox enforces what a process can touch at the syscall and handle level. It cannot determine whether an action was within a delegated mandate, because it has no representation of task scope, data classes or user consent. Governance requires a separate policy layer that issues and revokes capabilities.

What should a capability grant contain?

At minimum a task identifier, a scope covering data classes and reachable paths or destinations, an expiry, and a terminal state that revokes the capability when the task ends. The enforcement layer validates the signature and scope; it does not reinterpret the mandate.

Why log grants and enforcement decisions separately?

The grant log answers whether an action was authorised and by which consent record. The enforcement log answers whether the boundary held. Keeping them separate preserves attribution during an incident review; merging them loses the ability to tell a policy failure from an enforcement failure.