Есть болезненная правда в корпоративных AI-проектах: многие команды одержимы качеством модели и игнорируют подотчетность. Когда агент пишет или читает производственные данные, первый вопрос при разборе инцидента — не «был ли ответ хорошим?» Он — «кто это на самом деле сделал?»
Оригинальный источник: https://devblogs.microsoft.com/azure-sql/sql-mcp-server-obo-auth/
Вот почему поддержка OBO в Data API builder 2.0 с SQL MCP Server — более важное событие, чем кажется на первый взгляд. Подходы с именем пользователя/паролем и managed identity все еще работают операционно, но оба схлопывают идентичность до границы сервиса. Логи показывают приложение или промежуточный слой, а не источник человеческого запроса. Это приемлемо для простой автоматизации. Это неприемлемо для регулируемых агентных воркфлоу.
С OBO SQL аутентифицирует делегированный контекст пользователя, а не идентичность хоста инструмента. Это дает принципиально лучшую модель аудита: принципал пользователя, действие, контекст оператора и идентификатор приложения среднего уровня вместе. Вы получаете прослеживаемость без потери контрольной поверхности MCP-инструментов и разрешений сущностей DAB.
Моя позиция тверда: если ваш агент может касаться чувствительных SQL-данных, OBO должна быть вашей архитектурой по умолчанию, а не опциональной задачей по усилению. Настройка более вовлеченная, но долг по идентификации всегда оплачивается позже, обычно во время инцидентов безопасности, комплаенс-аудитов или эскалаций руководства.
Практическое руководство по внедрению
- Начните с валидации потока идентификации с минимальным представлением «WhoAmI» и автоматизированными проверками в интеграционных тестах. Если принципал SQL не соответствует вошедшему пользователю, остановитесь и исправьте перед поставкой.
- Подключите запросы Log Analytics для SQLSecurityAuditEvents к вашим дашбордам SOC и настройте оповещения о высокорисковых действиях, инициированных через OBO-пути.
- Согласуйте RBAC и разрешения DAB, чтобы пользовательская идентичность и авторизация на уровне действий оставались согласованными от начала до конца.
Один тонкий, но важный момент дизайна в анонсе — поведение кеша. DAB явно блокирует кеширование ответов, когда включена делегированная аутентификация пользователя. Этот компромисс корректен. Ухищрения производительности, которые могут раскрыть результаты, ограниченные пользователем, не стоят того в мультитенантных или регулируемых средах.
SQL MCP Server плюс OBO — это начало зрелого паттерна: агенты как контролируемые операторы, пользователи как ответственные принципалы, плоскости данных как аудируемые системы. Если ваша архитектура не может уверенно ответить на вопрос «кто это сделал», это не готовый к производству AI, независимо от того, насколько отполировано выглядит демо.
