Глава 10 — Проектирование безопасных архитектур LLM

Десятый пост поглавного разбора LLM Primer VII: AI Security. Глава, обращающаяся с архитектурой как с первичной дисциплиной безопасности — потому что самая безопасная конфигурация вероятностного компонента та, чей радиус поражения ограничен структурой, а не собственной сдержанностью компонента.

Зачем существует эта глава

Главы частей I–III назвали угрозы и защиты со стороны модели. Глава 10 проходит архитектуру вокруг модели — границы изоляции, уровни валидации, политические движки, API-контракты и zero-trust-принципы, придающие системе её структурные свойства. Предпосылка неизменна с более ранней инженерии безопасности: предположить компрометацию, ограничить ущерб, сделать компрометацию читаемой. Новое в том, что компонент, который надо ограничить, — оркестратор, движимый естественным языком, чьи инструкции могут приходить через любой канал ввода. Архитектурные паттерны переносятся из ранних эпох; специфика того, как они применяются к LLM, — то, где эта глава делает свою работу.

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

10.1 Изоляция ограничивает радиус поражения

Граница изоляции — намеренный шов, поперёк которого компонент по одну сторону не может напрямую повлиять на компонент по другую, не пройдя через контролируемый интерфейс. Причина безопасности для изоляции в том, что ущерб компрометации ограничен тем, что скомпрометированный компонент мог достичь через свои легитимные интерфейсы. Для систем LLM самый важный вопрос изоляции — между моделью и всем остальным, к чему система имеет доступ. Модель, работающая в процессе с неограниченным доступом к файловой системе, неограниченным сетевым доступом и tool'ом исполнения shell без allow-list, имеет большой радиус поражения. Модель, чей процесс работает в песочнице с определённым набором сисколлов, чей сетевой доступ идёт через egress-прокси с domain-level allow-list'ом, чьи инструменты вызываются через capability-токены, выдаваемые окружающим кодом на запрос, — имеет намного меньший. Паттерн распространяется на исполнение кода — sandbox-инструменты вроде тех, что OpenAI и Anthropic используют для сред code-interpreter, запускают сгенерированный код в эфемерных gVisor или Firecracker VM — и на браузинг, где headless-браузеры работают в изолированных сетевых namespace без доступа к внутренним endpoint'ам. Изоляция — дизайн-решение, принятое до любой конкретной атаки, и это самая дешёвая инвестиция в безопасность на единицу сокращения радиуса поражения, которую предлагает поле.

10.2 Валидация многослойна, а политика декларативна

Единая точка валидации — единая точка отказа. Продакшн-LLM-endpoint'ы обычно составляют пять слоёв между клиентским запросом и ответом. Аутентификация верифицирует учётные данные сущности. Валидация запроса проверяет запрос по схеме API — типы, диапазоны, длины, наборы символов. Оценка политики спрашивает, разрешает ли аутентифицированная сущность, валидированный запрос и текущее состояние системы это действие. Вызов модели работает с системным промптом, валидированным пользовательским вводом, списком инструментов, ограниченным тем, что политика разрешает, и ограничениями вывода. Фильтрация вывода проверяет ответ на контент, который не следует возвращать, — утёкшие секреты, запрещённый контент, небезопасные tool-вызовы, — до отправки. Логика политики растёт со временем и, если разбросана по коду приложения, становится объединением многих условий, которое сложно инспектировать, тестировать или эволюционировать. Поле сошлось на отделении политики от кода. Open Policy Agent (OPA), проект CNCF, оценивает политики, написанные на Rego. AWS Cedar, выпущенный в 2023, — более сфокусированный язык авторизации со свойствами формальной верификации. Оба готовы к продакшену; выбор обычно — организационное выравнивание. Политики становятся версионированными, обозреваемыми артефактами, и эффективная политика безопасности системы всегда читаема в одном месте.

10.3 Zero-trust, применённый к вызовам модели

API — контракт между LLM-системой и её вызывающими. Безопасный дизайн API — дисциплина формирования контракта, чтобы его инварианты пережили встречу с adversarial-вызывающими. Явные схемы ввода — строгие типы, диапазоны, allow-list'ы перечислений — стоят мало и ограничивают неявное доверие, которое API возлагает на вызывающего. Структурные ответы об ошибках, не выпускающие внутреннее состояние, избегают сбора разведданных, который вкратце сформулированные ошибки делают возможным. Ключи идемпотентности, ID запросов и версионирование дают системе наблюдаемость поведения вызывающего без требования дополнительного состояния. Модель zero-trust, сформулированная в BeyondCorp Google 2014 и формализованная в NIST SP 800-207 в 2020, расширяет принцип: ни один вызывающий не доверен в силу сетевого местоположения. Каждый запрос аутентифицируется, авторизуется против явной политики, оценивается по устройству и контексту и логируется. Применительно к LLM-системам сам вызов модели становится сущностью — запрос от модели к нижестоящему инструменту аутентифицируется как модель, несёт идентичность человека, от имени которого модель работает, и авторизуется против политики, знающей обе идентичности. Capability-токены с узкой областью действия и коротким TTL — то, что делает это композиционным. Результат в том, что скомпрометированный промпт не может эскалировать до полной компрометации системы, потому что собственные возможности модели ограничены токенами, которые окружающий код выдал на конкретный запрос.

Стоит запомнить: не просите модель контролировать саму себя. Каждая возможность, которую модель может вызвать, должна быть закрыта кодом вне модели, проверяющим вызов по политике, и политика должна выражаться декларативно, чтобы её эволюция была обозреваема. Кооперация модели — не часть периметра безопасности.

Что подготавливает глава 10

Структура без видимости отказывает невидимо. Глава 11 рассматривает слой наблюдаемости, превращающий архитектурные защиты в систему, которую можно эксплуатировать, — что логировать, когда LLM в цикле, как структурировать телеметрию для обслуживания оповещения в реальном времени, расследования постфактум, планирования ёмкости, комплаенса и непрерывной оценки из тех же записей. Семантические конвенции OpenTelemetry GenAI, начавшие стандартизировать LLM-специфичные span'ы и атрибуты в 2024, дают вендор-нейтральный фундамент. Конкретные реализации — Langfuse, Helicone, Arize Phoenix, Datadog LLM Observability — сидят сверху с разными компромиссами. Глава 12 затем обрабатывает измерение идентичности и доступа — OAuth, mTLS, RBAC против ABAC, мультитенантная изоляция, лимиты скорости и корпоративные контроли governance, делающие систему пригодной в регулируемых средах.

Дальше — Глава 11: Наблюдаемость, логирование и реагирование на инциденты. Что логировать по конвенциям OpenTelemetry GenAI, как обнаружить паттерны злоупотребления и как проводить NIST-образное реагирование на инциденты для системы, чьи отказы вероятностны.

Хочется всю картину? В книжной главе — разобранные политики OPA для авторизации инструментов, паттерны выдачи capability-токенов, полная адаптация от BeyondCorp к NIST-800-207 zero-trust для вызовов LLM и врезки In Plain English, которые эта статья только резюмирует. LLM Primer VII на Amazon →