https://thedotnetblog.com/ru/tags/microsoft-entra-id/Articles, tutorials and insights from the .NET community.Hugoru@thedotnetblog (The .NET Blog)@thedotnetblogWed, 22 Jul 2026 00:00:00 +0000https://thedotnetblog.com/ru/news/emiliano-montesdeoca/sql-mcp-obo-audit-frontier/Wed, 22 Jul 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/ru/news/emiliano-montesdeoca/sql-mcp-obo-audit-frontier/Аутентификация On-Behalf-Of в Data API builder и SQL MCP Server — важная веха в управлении, потому что Azure SQL наконец может аудировать человека, стоящего за действием агента.<p>Есть болезненная правда в корпоративных AI-проектах: многие команды одержимы качеством модели и игнорируют подотчетность. Когда агент пишет или читает производственные данные, первый вопрос при разборе инцидента — не «был ли ответ хорошим?» Он — «кто это на самом деле сделал?»</p> <p>Оригинальный источник: <a href="https://devblogs.microsoft.com/azure-sql/sql-mcp-server-obo-auth/">https://devblogs.microsoft.com/azure-sql/sql-mcp-server-obo-auth/</a></p> <p>Вот почему поддержка OBO в Data API builder 2.0 с SQL MCP Server — более важное событие, чем кажется на первый взгляд. Подходы с именем пользователя/паролем и managed identity все еще работают операционно, но оба схлопывают идентичность до границы сервиса. Логи показывают приложение или промежуточный слой, а не источник человеческого запроса. Это приемлемо для простой автоматизации. Это неприемлемо для регулируемых агентных воркфлоу.</p> <p>С OBO SQL аутентифицирует <strong>делегированный контекст пользователя</strong>, а не идентичность хоста инструмента. Это дает принципиально лучшую модель аудита: принципал пользователя, действие, контекст оператора и идентификатор приложения среднего уровня вместе. Вы получаете прослеживаемость без потери контрольной поверхности MCP-инструментов и разрешений сущностей DAB.</p> <p>Моя позиция тверда: если ваш агент может касаться чувствительных SQL-данных, OBO должна быть вашей архитектурой по умолчанию, а не опциональной задачей по усилению. Настройка более вовлеченная, но долг по идентификации всегда оплачивается позже, обычно во время инцидентов безопасности, комплаенс-аудитов или эскалаций руководства.</p> <h3 id="практическое-руководство-по-внедрению">Практическое руководство по внедрению</h3> <ul> <li><strong>Начните с валидации потока идентификации</strong> с минимальным представлением «WhoAmI» и автоматизированными проверками в интеграционных тестах. Если принципал SQL не соответствует вошедшему пользователю, остановитесь и исправьте перед поставкой.</li> <li><strong>Подключите запросы Log Analytics</strong> для SQLSecurityAuditEvents к вашим дашбордам SOC и настройте оповещения о высокорисковых действиях, инициированных через OBO-пути.</li> <li><strong>Согласуйте RBAC и разрешения DAB</strong>, чтобы пользовательская идентичность и авторизация на уровне действий оставались согласованными от начала до конца.</li> </ul> <p>Один тонкий, но важный момент дизайна в анонсе — поведение кеша. DAB явно блокирует кеширование ответов, когда включена делегированная аутентификация пользователя. Этот компромисс корректен. Ухищрения производительности, которые могут раскрыть результаты, ограниченные пользователем, не стоят того в мультитенантных или регулируемых средах.</p> <p><strong>SQL MCP Server плюс OBO</strong> — это начало зрелого паттерна: агенты как контролируемые операторы, пользователи как ответственные принципалы, плоскости данных как аудируемые системы. Если ваша архитектура не может уверенно ответить на вопрос «кто это сделал», это не готовый к производству AI, независимо от того, насколько отполировано выглядит демо.</p>