Microsoft рассказала, как защищает генеративные ИИ-модели в Azure AI Foundry

В Microsoft Security Blog 4 марта 2025 года вышел пост с описанием мер безопасности Microsoft для генеративных моделей в Azure AI Foundry

Главная мысль Microsoft: модель ИИ в облаке нужно рассматривать не как «магическую сущность», а как обычное программное обеспечение, которое надо проверять, изолировать и контролировать так же строго, как любой сторонний код.

По словам Microsoft, модели в Azure AI Foundry работают внутри виртуальных машин Azure и доступны через API. Компания отдельно подчёркивает, что такие модели не обладают каким-то особым способом «вырваться» из среды исполнения только потому, что это ИИ. Поэтому к ним применяются те же базовые облачные меры защиты, что и к другим рабочим нагрузкам в Azure.

Для наиболее заметных и востребованных моделей Microsoft проводит проверку до публикации в каталоге Azure AI Foundry Model Catalog. В официальном посте перечислены четыре основных направления такой проверки:

1. Анализ на вредоносный код. Модели сканируют на предмет встроенного вредоносного кода, который мог бы использоваться как вектор заражения.

2. Поиск уязвимостей. Проверяются известные уязвимости и сценарии атак, включая CVE и уязвимости нулевого дня, которые могут затрагивать модели или их окружение.

3. Выявление бэкдоров. Microsoft пишет о поиске признаков атак на цепочку поставок, произвольного выполнения кода и несанкционированных сетевых вызовов. По сути, речь идёт о попытке найти скрытые механизмы, которые могут изменить поведение модели или использовать её как точку входа.

4. Контроль целостности модели. Компания анализирует слои, компоненты и тензоры модели, чтобы заметить следы подмены, повреждения или несанкционированных изменений.

Microsoft отдельно уточняет, что модели, прошедшие такую проверку, можно определить по отметке в карточке модели. Это важная практическая деталь для команд, которые выбирают модель для продакшена: проверять нужно не только название модели, но и её статус в каталоге.

Microsoft приводит в пример DeepSeek R1. Для особенно заметных моделей компания заявляет более глубокую проверку: изучение исходного кода, работу экспертных команд и red teaming, то есть имитацию атак с точки зрения атакующего.

Это согласуется и с другим официальным материалом Microsoft от 29 января 2025 года, где говорилось, что DeepSeek R1 появился в Azure AI Foundry и вошёл в каталог из более чем 1 800 моделей. Там же Microsoft отдельно заявляла о red teaming, автоматизированных оценках поведения модели и дополнительных ревью безопасности.

Один из самых важных пунктов — работа с пользовательскими данными. В официальном посте Microsoft Security Blog сказано, что компания не использует данные клиентов для обучения общих моделей и не передаёт журналы или контент поставщикам моделей. Также Azure AI Foundry и Azure OpenAI Service, по словам Microsoft, работают на серверах Microsoft без runtime-подключений к исходным разработчикам моделей. А если клиент дообучает модель на своих данных, такая модель остаётся в его собственном пространстве.

Эти формулировки подтверждаются документацией Microsoft Learn. В документации по Azure Direct Models в Microsoft Foundry указано, что prompts, completions, embeddings и training data:

• не доступны другим клиентам;

• не доступны OpenAI или другим провайдерам моделей;

• не используются для улучшения моделей или сервисов провайдеров без явного разрешения;

• не используются для обучения foundation-моделей без явного разрешения или указания клиента.

В документации по моделям из каталога Foundry также сказано, что Microsoft не передаёт промпты и outputs поставщику модели и не использует их для обучения или улучшения моделей Microsoft, моделей провайдера или любых сторонних моделей. Там же уточняется, что файн-тюнинг модели доступны исключительно клиенту, который их создал.

Microsoft отдельно описывает подход Zero Trust, то есть архитектуру, в которой по умолчанию не доверяют ни одному компоненту только потому, что он уже находится внутри инфраструктуры. Для ИИ-моделей это означает, что даже размещённая в Azure модель не должна считаться безопасной автоматически. Её нужно проверять, мониторить и ограничивать в правах так же, как любой другой подозрительный или сторонний компонент. То есть модель рассматривается как сторонняя зависимость. Её происхождение и репутация важны. Также нужно смотреть на карточку модели и статус проверок и модель нельзя выпускать в прод без собственной оценки рисков. А ещё вокруг модели должны быть сетевые и инфраструктурные ограничения.

В том же мартовском посте Microsoft пишет не только о проверках перед размещением, но и о продолжающемся мониторинге доверия к ключевым моделям. А в Microsoft Defender for Cloud уже есть отдельные рекомендации для ИИ-ресурсов: например, система непрерывно сканирует модели в Azure Machine Learning Registries и Workspaces на риски безопасности, включая вредоносное содержимое и уязвимости, связанные с сериализацией.

Разработчикам важно помнить, что использование модели из крупного облачного каталога не отменяет внутреннюю проверку. Microsoft сама пишет, что никакое сканирование не способно обнаружить вообще все злонамеренные действия, поэтому организация должна опираться и на собственную оценку доверия к поставщику модели. Также модель стоит воспринимать как часть цепочки поставок ПО. Если в компании уже есть процессы проверки зависимостей, контейнеров, образов и библиотек, то генеративные модели логично встроить в ту же схему контроля. Это не отдельный «магический» класс объектов, а ещё один тип исполняемого и потенциально рискованного артефакта. Такой вывод прямо следует из архитектурного описания Microsoft и её сравнения модели с обычным ПО, работающим в VM.

Microsoft фактически предлагает относиться к генеративной ИИ-модели как к обычной сторонней зависимости: проверять её на вредоносное поведение, не доверять ей по умолчанию, изолировать, контролировать доступ к данным и не выпускать в продакшен без собственной оценки рисков.