Когда ИИ-агент использует учётные данные человека для доступа к базам данных, система не получает скрытую за учётной записью «идентичность агента» — она видит самого пользователя. Таков главный вывод измерения, проведённого Naseeb Ahmed Mian в производственной среде с использованием Azure, Azure CLI и sqlcmd.
В исследуемой конфигурации навыки программного агента подключались к базам данных через команду sqlcmd, используя аутентификацию через Azure CLI. Команда извлекает кэшированный токен доступа после входа пользователя, а затем передаёт его базе данных. В результате подключения отображались под именем пользователя, с именем его устройства и инструментом sqlcmd — независимо от того, написал ли запрос сам пользователь или выполнил его агент.
Журнал аудита видит учётные данные, но не видит намерение
Журнал сеанса показывал имя учётной записи пользователя, имя рабочей станции и клиентский интерфейс, но не содержал поля, отличающего действия, выполненные агентом. Поэтому человеческие и автоматизированные запросы в журнале выглядели одинаково, а последующие средства контроля не могли применять разные ограничения частоты запросов, этапы одобрения или политики хранения в зависимости от источника выполнения.
Проблема не ограничивается расследованиями безопасности. Если позднее, через несколько месяцев, будет оспорен выполненный запрос, журнал не докажет, написал ли его пользователь или запустил автоматизированный инструмент. Он точно связывает действие с учётными данными, но ничего не говорит о намерении и фактическом исполнителе.
Что раскрывает токен доступа?
Переданный Azure CLI токен содержал область user_impersonation, а также утверждение о том, что аутентификация включала многофакторный фактор. На практике каждое действие агента сопровождалось доказательством того, что пользователь прошёл многофакторную аутентификацию, даже если это произошло несколько часов назад и в рамках другой задачи.
Кроме того, срок действия токена, составляющий 84 минуты, не обязательно означает завершение работы агента. CLI автоматически обновляет токен с помощью токена обновления, поэтому автономное выполнение может продолжаться до истечения срока действия токена обновления или отключения учётной записи пользователя.
Членство в группах расширяет картину
Проверка назначений ролей показала лишь одну строку: роль Reader в непродуктивной подписке. Однако токен доступа содержал 37 групп, тогда как запрос прямого членства показал 34 группы с наличием вложенных групп. Среди связанных с доступом групп были такие роли, как средство просмотра баз данных SQL, пользователь с повышенными привилегиями, участник ресурсов и администратор базы данных.
Опасность заключается в том, что эти членства могут предоставлять фактические разрешения на уровне данных и не обязательно отображаться при проверке ролей на уровне плоскости управления. Поэтому при традиционном анализе область доступа агента может выглядеть ограниченной, хотя членство в группах предоставляет ему более широкие возможности.
Что меняется на практике?
При проверке той же идентичности в двух производственных хранилищах с разницей в один час были получены резко различающиеся результаты. В одном из них идентичность имела только разрешения CONNECT и SELECT и не могла подключиться к защищённому уровню. Другая производственная аналитическая точка показала 430 таблиц и 107 разрешений, включавших чтение, запись, определение схемы и администрирование базы данных.
Сравнение показывает, что область разрешений определяется не только идентичностью: путь доступа, движок и средства контроля, связанные с конечной точкой, также имеют решающее значение. Конечная точка может быть предназначена только для чтения согласно своей документации, однако её правила безопасности не обязательно применяются, когда данные вызываются через другой движок.
Редакционный вывод certi.news: проблема не в том, что у агента «нет идентичности», а в том, что идентичность человека была использована как быстрый заменитель отдельной автоматизированной идентичности. Это даёт сбой в трёх аспектах: атрибуции, расширении разрешений и отзыве доступа. Измерение также показало, что среда, в которой учётные данные имели возможность удаления из защищённой базы данных, была единственной средой без включённого журнала аудита. Открытыми остаются важные вопросы о согласованности членства в группах, сохранении временных разрешений внутри выданных токенов и способности организаций регистрировать намерение выполнения, а не только владельца учётных данных.