https://thedotnetblog.com/ru/tags/agentic-ai/Articles, tutorials and insights from the .NET community.Hugoru@thedotnetblog (The .NET Blog)@thedotnetblogThu, 04 Jun 2026 00:00:00 +0000https://thedotnetblog.com/ru/news/emiliano-montesdeoca/sql-server-maestro-agentic-ai-security-defense-in-depth/Thu, 04 Jun 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/ru/news/emiliano-montesdeoca/sql-server-maestro-agentic-ai-security-defense-in-depth/Агентный ИИ вводит угрозы, для которых традиционные модели STRIDE не были предназначены. Вот как Microsoft SQL соотносится с фреймворком MAESTRO для предоставления управляемой границы выполнения.<p>Модели угроз безопасности строятся на предположениях о том, кто или что делает запросы. STRIDE предполагает человеческих субъектов, взаимодействующих с системами через определённые интерфейсы. Агенты ИИ работают не так.</p> <h2 id="stride-не-был-разработан-для-агентов-ии">STRIDE Не Был Разработан для Агентов ИИ</h2> <p>Агентные системы работают автономно, объединяют инструменты в цепочки через вызовы API, принимают решения о том, какие данные извлекать и какие действия выполнять, и могут получать инструкции из нескольких источников — пользовательских промптов, результатов инструментов, полученных данных. Модель угроз STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) неадекватно захватывает специфические для агентов векторы атак, такие как инъекция промптов, отравление контекста или злоупотребление инструментами.</p> <p>Альянс Cloud Security Alliance опубликовал фреймворк MAESTRO специально для рисков агентов ИИ.</p> <h2 id="фреймворк-maestro">Фреймворк MAESTRO</h2> <p>MAESTRO организует риски агентного ИИ в семь уровней:</p> <ol> <li><strong>Foundation Models</strong> — базовые LLM и их уязвимости обучения</li> <li><strong>Data Operations</strong> — получение, хранение и манипулирование данными</li> <li><strong>Agent Frameworks</strong> — промежуточное программное обеспечение оркестрации и координации агентов</li> <li><strong>Deployment &amp; Infrastructure</strong> — где выполняются агенты и как они настроены</li> <li><strong>Evaluation &amp; Observability</strong> — мониторинг поведения агентов во времени</li> <li><strong>Security &amp; Compliance</strong> — управление доступом, аудит и нормативное соответствие</li> <li><strong>Agent Ecosystem</strong> — как агенты взаимодействуют друг с другом и с внешними инструментами</li> </ol> <p>Каждый уровень имеет специфические векторы атак, которые традиционные средства контроля безопасности не адресуют напрямую.</p> <h2 id="microsoft-sql-как-управляемая-граница-выполнения">Microsoft SQL как Управляемая Граница Выполнения</h2> <p>SQL Server 2025 соотносится с уровнями MAESTRO конкретными способами:</p> <p><strong>Уровень Data Operations</strong>: <code>AI_GENERATE_EMBEDDINGS</code>, встроенный в T-SQL, удерживает векторные операции в пределах управляемой границы базы данных. Данные не нужно отправлять в сервис модели для обработки эмбеддингов.</p> <p><strong>Уровни Security &amp; Compliance</strong>: Безопасность на уровне строк (RLS) и динамическое маскирование данных (DDM) применяются независимо от того, как пришёл запрос — от пользователя-человека или агента ИИ. Агент не может обойти элементы управления, которые применяются самой базой данных.</p> <p><strong>Уровень Agent Frameworks</strong>: Хранимые процедуры служат границами инструментов. Вместо предоставления агентам произвольного SQL-доступа вы определяете разрешённые операции как процедуры и предоставляете их как инструменты агента. Параметризованные запросы предотвращают инъекцию на уровне выполнения.</p> <p><strong>Уровень Evaluation &amp; Observability</strong>: Журналирование аудита и Query Store фиксируют, что каждый агент фактически выполнил — не только то, что ему было предложено сделать. Эта прослеживаемость критически важна для расследований инцидентов в агентных системах, где атрибуция сложна.</p> <h2 id="глубокоэшелонированная-защита-для-агентного-ии">Глубокоэшелонированная Защита для Агентного ИИ</h2> <p>Принцип остаётся таким же, как и в традиционной безопасности: ни одного отдельного элемента управления недостаточно. Что меняется — так это то, какие элементы управления наиболее важны для агентов:</p> <p><strong>Уменьшение радиуса поражения</strong>: границы инструментов через хранимые процедуры означают, что скомпрометированный агент может выполнять только предопределённые операции. Он не может переключиться на произвольные запросы.</p> <p><strong>Наблюдаемость</strong>: после инцидента вы должны быть в состоянии ответить &ldquo;что именно делал этот агент?&rdquo;. Агентные системы ИИ без прослеживаемости на уровне базы данных имеют слепые пятна, которые журналирование приложений не покрывает.</p> <p><strong>Ограниченное выполнение</strong>: параметризация, RLS и DDM являются активами безопасности независимо от того, является ли вызывающий человеком. Не ослабляйте их для адаптации агентов.</p> <p><strong>Подотчётность</strong>: журналирование аудита SQL Server создаёт запись о том, кто (какой агент, с какими учётными данными) выполнил что и когда. Это важно, когда агентные системы совершают действия с реальными последствиями в мире.</p> <p>SQL Server 2025 был создан не для абстрактного решения агентных рисков — он был создан как реляционная база данных. Но управление, которое делает корпоративную базу данных надёжной, оказывается именно тем, что делает границу выполнения агентов безопасной.</p> <p>Оригинальный пост: <a href="https://devblogs.microsoft.com/azure-sql/microsoft-sql-security-across-the-maestro-stack-building-secure-agentic-ai-with-defense-in-depth/">Microsoft SQL Security Across the MAESTRO Stack</a></p>