Глава 12 — Контроль доступа и идентичность

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

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

Все традиционные дисциплины контроля доступа применимы к LLM-системам: аутентифицировать сущность, авторизовать её запросы против политики, изолировать арендаторов, ограничить потребление на сущность, выставить корпоративные governance-оверлеи. Механизмы — те, что поле использует десятилетиями: OAuth 2.0, mTLS, RBAC, ABAC, token buckets, SAML, SCIM. Новое в том, что сам вызов модели может стать сущностью — агент, действующий от имени пользователя, несёт свою идентичность и свои разрешения, — и что per-tenant-конфигурация поведения модели — first-class-фича продукта для мультитенантных LLM-платформ.

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

12.1 Аутентификация и авторизация переносятся с дополнениями

Аутентификация верифицирует учётные данные. API-ключи — простейший механизм: высокоэнтропийная строка, выданная сущности при провижининге, хэшированная в базе учётных данных, предъявляемая в заголовке при каждом запросе. Их легко реализовать и использовать, и легко утечь через логи, вывод CI и закоммиченные репозитории. OAuth 2.0 bearer-токены улучшают ситуацию короткоживущими токенами и ограничением scope; черновик OAuth 2.1 консолидирует лучшие практики безопасности последнего десятилетия. mTLS добавляет взаимную аутентификацию для machine-to-machine-вызовов, особенно полезен для внутренних LLM-сервисов. Авторизация спрашивает, что аутентифицированной сущности разрешено делать. RBAC — роли, разрешения, назначения — работает, когда популяция делится на устойчивые группы. ABAC — контроль доступа на основе атрибутов — оценивает предикаты по атрибутам сущности, ресурса и контекста и обрабатывает случаи, которые RBAC не может: разрешения, зависящие от владельца ресурса, времени или местоположения запроса или отношений в системе. Эти два не взаимоисключающие; продакшн-системы часто их слоят с RBAC для крупнозернистого доступа и ABAC для конкретных условий. Политические движки из главы 10 — OPA, Cedar — то, как ABAC становится поддерживаемым в масштабе.

12.2 Мультитенантная изоляция — вопрос defence-in-depth

Мультитенантная система обслуживает несколько клиентов из одного развёртывания. Требование изоляции в том, что никакой арендатор не может видеть данные, запросы или взаимодействия с моделью другого арендатора ни при каком режиме отказа. Три архитектурных подхода сидят на спектре. Изоляция уровня базы данных — отдельная база данных на арендатора — сильнейшая, но самая дорогая в эксплуатации. Изоляция уровня схемы — отдельная схема PostgreSQL или база MySQL на арендатора на общей инфраструктуре — средний путь. Изоляция уровня строк — общая схема, ID арендатора на каждой строке, row-level security на уровне базы данных — дешевейшая, но требует дисциплинированного кода приложения. Для LLM-систем изоляция распространяется на retrieval-корпус (per-tenant vector-database namespaces), логику построения промпта (без межарендаторной конкатенации), log-store (без межарендаторных чтений) и саму модель, когда она файн-тюнится на данных, специфичных для арендатора. Лимиты скорости и квоты добавляют ось потребления ресурсов. Token bucket разрешает короткие всплески до определённой ёмкости; sliding window принуждает более равномерную скорость при более высокой вычислительной стоимости; leaky bucket сглаживает нижестоящую скорость. Для LLM-систем измерение лимитов скорости расширяется: запросы в секунду, токены в минуту, стоимость в день, tool-вызовы в час, эмбеддинги в секунду. У каждого измерения своё экономическое и security-обоснование, и корпоративные тарифы обычно дискриминируют по нескольким.

12.3 Корпоративный governance — оверлей, делающий систему пригодной

У корпоративных клиентов требования governance за пределами аутентификации и лимитов скорости. Им нужно знать, какие сотрудники используют систему, на каких данных, для каких целей. Им нужны аудит-логи, достаточные для внутреннего комплаенса и внешнего аудита. Им нужны контроли того, какие модели разрешены, какие инструменты доступны, какие категории контента допущены. Им нужны обязательства по обработке данных — использование в обучении, шифрование, резиденция, удержание, удаление. Ставшие стандартом фичи отражают эти требования. Single sign-on через SAML или OpenID Connect делает корпоративного identity provider'а источником истины о том, кто может использовать систему. SCIM-провижининг распространяет изменения пользователей автоматически. Экспорт аудит-логов посылает телеметрию LLM-системы в корпоративный SIEM. Обязательства по резиденции данных гарантируют, что данные арендатора не покидают указанную юрисдикцию. Customer-managed encryption keys позволяют предприятию ротировать или отзывать независимо от провайдера. Опции приватного развёртывания перемещают LLM-сервис в собственный облачный аккаунт предприятия. Каждая из этих фич — governance-поверхность, которую надо эксплуатировать, а не только имплементировать; корпоративный governance-оверлей — то, что превращает мультитенантную LLM-платформу в нечто, что может принять регулируемая индустрия.

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

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

Часть IV развила системные измерения безопасности LLM: архитектурные границы (глава 10), наблюдаемость и реагирование на инциденты (глава 11) и контроли идентичности и доступа (глава 12). Трактовка была mechanism-first и даёт защитимую техническую позицию. Глава 13 открывает часть V, двигаясь наружу от технического ядра к регуляторному периметру. EU AI Act, вступающий в полное действие с августа 2026 для большинства категорий высокого риска, — самый значимый единичный инструмент, но федеральная позиция США (эволюционирующая после перехода EO 14110 к EO 14179), законы уровня штатов (Колорадо, Калифорния, Нью-Йорк и другие), GDPR применительно к ИИ и возникающие фреймворки в Сингапуре, Японии, Корее, Индии и других местах коллективно делают поверхность комплаенса плюральной, а не единой. Глава рассматривает, что эти регуляции требуют в практических терминах и как контроли из глав 3, 10, 11 и 12 отображаются на эти требования.

Дальше — Глава 13: Регуляторный ландшафт. Поэтапное применение EU AI Act, GDPR против систем ИИ, аудируемость, карты моделей и фреймворки классификации риска, структурирующие регуляторную архитектуру.

Хочется всю картину? В книжной главе — разобранные настройки OAuth и mTLS, полная матрица решения RBAC-против-ABAC с продакшн-примерами, паттерны изоляции арендаторов по слоям хранилища и врезки In Plain English, которые эта статья только резюмирует. LLM Primer VII на Amazon →