Закономерность в отчётах об инцидентах этого цикла
Это стоит сформулировать аккуратно, потому что это меняет суть инцидента. Взлом подразумевает противника и уязвимость. Неавторизованный пункт назначения подразумевает разрыв между тем, какой оператор считал власть агента, и тем, что фактически допускала среда исполнения. Это разные классы отказов, и они требуют разных мер устранения.
Отчёты описывают обнаруженное поведение, а не предотвращённое
Каждое описание в этом цикле ретроспективно. Кто-то заметил поведение, затем восстановил его. Это свойство логирования, а не свойство модели. Система, которая предотвращает неавторизованный исходящий трафик, и система, которая допускает его и позже сообщает о нём, могут использовать один и тот же движок политик; они различаются лишь тем, была ли граница применена до или после факта, и был ли попытка записана вообще.
Неудобное следствие в том, что отрасль в настоящее время не может по запросу предъявить доказательства, которые разрешили бы спорный инцидент. Когда регулятор спрашивает, пытался ли агент достичь конкретного пункта назначения в конкретном запуске, честный ответ для большинства развёртываний таков: транскрипт существует, а полномочия — нет. Транскрипт показывает, что сказала модель. Он не показывает, какие учётные данные были предъявлены на границе, по чьему предоставлению, и была ли ветвь политики оценена и отклонена.
Это контекст текущего регуляторного нажима: запросы FTC, добровольные обещания, циркулирующие среди лабораторий, и законопроекты на уровне штатов в процессе разработки — всё это пишется против корпуса доказательств, который в значительной степени анекдотичен. Правила, составленные по анекдотам, тяготеют к широким и неисполнимым, потому что составители не могут указать на конкретный запуск и сказать: вот форма отказа. Альтернатива — не дерегуляция. Это создание записи.
Три артефакта, которые делают инцидент реконструируемым
Реконструируемый инцидент нуждается в трёх записях, и у каждой есть естественное место, которое не находится внутри собственного фреймворка агента.
Запись намерения
Цель, как она была заявлена агенту, зафиксированная до выбора инструмента, а не выведенная впоследствии из транскрипта. Вывод — это и есть проблема: транскрипт — это нарратив, который модель написала о себе, и он сформирован тем же контекстом, который породил поведение. Запись намерения — это вход, а не отчёт модели о входе. Она должна нести идентификатор задачи, запрашивающего принципала, заявленную цель и объём полномочий, предоставленных для этой цели.
Запись исходящего трафика
Каждый пункт назначения, каждые использованные учётные данные и класс полезной нагрузки, записанные на границе, а не внутри фреймворка агента. Граница — единственное место, где записи можно доверять, потому что это единственное место, которое наблюдает попытку независимо от того, что намеревался сделать фреймворк. Если фреймворк агента пишет собственный журнал исходящего трафика, скомпрометированный или неправильно настроенный фреймворк пишет вводящий в заблуждение журнал.
Конкретный механизм: прямой прокси, который завершает весь исходящий трафик из среды исполнения агента, разрешает пункт назначения, проверяет его против предоставленного объёма задачи и выдаёт структурированную запись перед пересылкой или отказом. Запись пишется прокси, а не агентом. Агент не может её подавить, потому что агент не находится на пути записи.
Запись решения
Какая политика была оценена, какая ветвь была выбрана и каким был бы запасной вариант. Последнее предложение важнее всего и чаще всего опускается. Знать, что запрос был отклонён, полезно; знать, что отказ провалился в разрешение по умолчанию, — это разница между политикой и украшением. Запись решения должна называть версию политики, входы оценки, результат и состояние запасного варианта.
Почему дашборды не удовлетворяют этому
Агрегированные метрики отвечают на вопрос как часто. Они не отвечают на вопрос что именно произошло в запуске 41 208. Когда инцидент находится на рассмотрении, вопрос всегда конкретен: этот запуск, этот пункт назначения, эти учётные данные, это прmedia/server-rack-circuit-board-1958b2-bf296a.jpg)
Выборочные трассировки имеют тот же дефект в более резкой форме. Выборка предназначена для сохранения репрезентативного и отбрасывания хвоста. Аномальные запуски, которые имеют значение, — это именно хвост. Система, которая сохраняет один процент трассировок, по построению отбросит запуски, нужные следователю, и сделает это невидимо, потому что отсутствие записи неотличимо от отсутствия события.
Политика хранения поэтому становится параметром безопасности, а не параметром стоимости хранения. Это честный компромисс во всём дизайне. Записи полной точности каждого намерения и каждой попытки исходящего трафика объёмны и чувствительны, потому что они описывают, что организация пыталась сделать. Прагматичная позиция — многоуровневое хранение: полная точность в течение окна, достаточно долгого, чтобы охватить обнаружение инцидента, агрегированные и отредактированные за его пределами, с сохранённой схемой, чтобы конкретный запуск всё ещё можно было идентифицировать, даже когда детали его полезной нагрузки устарели. Это выбор политики, и его следует делать явно, а не по умолчанию отдавать на откуп тому, что поставляет поставщик observability.
Минимально жизнеспособная реализация
Трёх свойств достаточно, чтобы создать разницу между реконструируемым инцидентом и анекдотом.
Пишите вне области записи агента. Записи намерения и исходящего трафика идут в хранилище только для добавления, к которому среда исполнения агента не имеет учётных данных для изменения или удаления. Только для добавления — это не предпочтение хранилища; это свойство, которое делает запись доказательством, а не показанием.
Привязывайте записи к идентификаторам, на которые может нацелиться отзыв. Каждая запись несёт идентификатор задачи и идентификатор учётных данных. Без привязки отзыв — тупой инструмент: вы можете остановить агента, но не можете отозвать конкретное предоставление, которое позволило конкретный исходящий трафик. С ней ответ на инцидент — это ограниченный отзыв, а не выключение.
Относитесь к схеме журнала как к версионированному интерфейсу. Инструменты ответственности и аудита ниже по потоку будут зависеть от имён полей и семантики. Схема, которая меняется без версионирования, ломает инструменты молча, а сломанный аудиторский след хуже отсутствующего, потому что он выглядит полным.
{
"schema_version": "1.2",
"task_id": "...",
"credential_id": "...",
"intent": {"principal": "...", "objective": "...", "granted_scope": ["..."]},
"egress": {"destination": "...", "payload_class": "...", "outcome": "allowed|denied"},
"decision": {"policy_version": "...", "branch": "...", "fallback": "..."}
}
Компромисс реален и должен быть назван. Эта инструментация стоит задержки на границе, хранения записей и инженерного внимания к схеме. Она не делает агента безопасным. Она делает поведение агента разборчивым, что является предпосылкой для любого заявления о безопасности, которое следует. Политика без телеметрии — это заявление о намерении; телеметрия без политики — это запись дрейфа. Текущий цикл инцидентов предполагает, что у отрасли больше первого, чем она может обосновать, и что первая инвестиция — это запись.