Искусственный интеллект в облаке редко представляет собой автономную службу — он является продуктом сложной цифровой цепочки поставок базовых облачных компонентов. Организации активно внедряют облачные ИИ-платформы из-за их эффективности и масштабируемости, однако эта спешка сопряжена со скрытыми рисками. Облачные рабочие нагрузки ИИ зависят от уровней сторонних служб (виртуальных машин, контейнеров, систем хранения, служб идентификации и т. д.), и уязвимости или неверные настройки на любом из уровней могут вызвать каскадный сбой, подвергая опасности ИИ-приложение.
Недавнее исследование Tenable подчеркивает, что облачные среды ИI изобилуют подобными унаследованными рисками.
Цифровая цепочка поставок ИИ: уровни риска под поверхностью службы
Когда вы запускaете ИИ-службу в облаке — будь то управляемый блокнот для машинного обучения или API искусственного интеллекта — за кулисами работает множество служб. Например, управляемый ИИ-блокнот фактически может работать на базе службы контейнеров, которая, в свою очередь, работает на виртуальной машине в инфраструктуре облачного провайдера. Каждый из этих базовых компонентов является частью цифровой цепочки поставок вашего ИИ, предоставляемой облачным вендором.
Подвох заключается в следующем: если у какой-либо базовой службы есть уязвимость, ваша рабочая нагрузка ИИ наследует этот риск.
Облачные провайдеры часто выстраивают службы по принципу башни «Дженга», надстраивая новые ИИ-службы поверх существующих платформ. Это означает, что неверная конфигурация глубоко в стеке — например, небезопасная настройка по умолчанию в виртуальной машине или службе хранения — может незаметно распространиться на расположенный выше уровень ИИ.
Неверные настройки облака по принципу «Дженги», когда облачные провайдеры строят одну службу поверх другой, теперь дают о себе знать в управляемых ИИ-службах. Всего одна неправильно настроенная служба нижнего уровня может поставить под угрозу все зависящие от нее ИИ-службы, подчеркивая характер цепочки поставок облачного ИИ.
Неверные настройки облака по принципу «Дженги», когда облачные провайдеры строят одну службу поверх другой, теперь дают о себе знать в управляемых ИИ-службах. Всего одна неправильно настроенная служба нижнего уровня может поставить под угрозу все зависящие от нее ИИ-службы, подчеркивая характер цепочки поставок облачного ИИ.
Сложность этой многоуровневой цепочки поставок носит не просто теоретический характер. Согласно модели общей ответственности в облаке, провайдеры обеспечивают безопасность базовой инфраструктуры, однако клиенты несут ответственность за безопасную настройку того, что они создают поверх нее. Реальность такова, что настройки по умолчанию у облачных провайдеров ставят удобство использования выше безопасности: зачастую чрезмерно разрешающие параметры по умолчанию, оставляемые пользователями без изменений, могут создавать серьезные уязвимости. Таким образом, каждая рабочая нагрузка ИИ, построенная на облачных службах, наследует не только возможности этих служб, но и любые скрытые в них уязвимости безопасности.
Унаследованные уязвимости в рабочих нагрузках ИИ
Один из поразительных выводов заключается в том, что облачные рабочие нагрузки, на которых работает ИИ-по, значительно уязвимее остальных. Почти проанализированных облачных рабочих нагрузок с установленным пакетом ИИ содержали хотя бы одну неисправленную критическую уязвимость — этот показатель заметно выше 50% для облачных рабочих нагрузок без ИИ. Иными словами, в рабочей нагрузке ИИ с большей долей вероятности кроется критическая уязвимость.
Почему так происходит? Одна из причин заключается в самой программной цепочке поставок ИИ: многие рабочие нагрузки ИИ работают на платформах на базе Linux с многочисленными библиотеками и фреймворками с открытым исходным кодом, в которых часто обнаруживаются уязвимости. Если эти библиотеки (например, широко используемый пакет для ИИ или даже такой инструмент, как cURL) не обновляются, они могут стать источником критических сбоев.
Влияние этих унаследованных уязвимостей усиливается спецификой рабочих нагрузок ИИ. Если злоумышленник использует критическую уязвимость в системе ИИ, последствия могут выйти за рамки простого доступа к серверу — злоумышленник может манипулировать моделями ИИ или фальсифицировать конфиденциальные обучающие данные, что приведет к искажению результатов работы ИИ или утечке конфиденциальной информации.
И если эта уязвимая рабочая нагрузка ИИ вдобавок остается открытой для интернета, это создает опасную комбинацию, которая значительно повышает вероятность взлома. В отчете Tenable Cloud AI Risk Report прямо отмечается, что искусственный интеллект, при всей своей интеллектуальности, не лишен рисков и требует к себе внимания.
Команды безопасности должны проявлять особую бдительность при управлении уязвимостями для ИИ. Высокая частота критических сбоев в таких рабочих нагрузках в сочетании с конфиденциальным характером данных и моделей ИИ делают исправление уязвимостей и повышение защищенности первоочередной задачей.
Почти 70% облачных рабочих нагрузок с поддержкой ИИ содержат хотя бы одну критическую неисправленную уязвимость — это значительно выше, чем ~50% облачных рабочих нагрузок без ИИ. Этот разрыв подчеркивает, как сложный программный стек ИИ может порождать скрытые уязвимости, требующие оперативного устранения.
Почти 70% облачных рабочих нагрузок с поддержкой ИИ содержат хотя бы одну критическую неисправленную уязвимость — это значительно выше, чем ~50% облачных рабочих нагрузок без ИИ. Этот разрыв подчеркивает, как сложный программный стек ИИ может порождать скрытые уязвимости, требующие оперативного устранения.
Рискованные настройки по умолчанию и ошибки конфигурации в облачных ИИ-службах
Помимо программных уязвимостей, ошибки конфигурации в облачных службах представляют собой серьезный риск для цепочки поставок ИИ. Облачные службы ИИ часто поставляются с конфигурациями по умолчанию, которые при сохранении в исходном виде могут предоставлять опасные избыточные привилегии. Например, управляемый сервис ИИ-блокнотов от ведущего облачного провайдера по умолчанию предоставляет пользователям права root внутри экземпляра блокнота, что означает полный контроль администратора. Что тревожит больше всего, подавляющее большинство (около 91%) организаций, использующих эту службу, имеют хотя бы один блокнот с включенными по умолчанию правами root.
По данным Tenable, 90,5% организаций, использующих управляемые среды разработки ИИ, сохраняют настройки с избыточными правами доступа уровня root хотя бы в одном экземпляре блокнота. Эта ошибка конфигурации, часто унаследованная от параметров по умолчанию, демонстрирует, как один недосмотр может подвергнуть рабочие нагрузки ИИ серьезному риску.
По данным Tenable, 90,5% организаций, использующих управляемые среды разработки ИИ, сохраняют настройки с избыточными правами доступа уровня root хотя бы в одном экземпляре блокнота. Эта ошибка конфигурации, часто унаследованная от параметров по умолчанию, демонстрирует, как один недосмотр может подвергнуть рабочие нагрузки ИИ серьезному риску.
В довершение всего, облачные среды ИИ часто работают с крайне конфиденциальными данными, и ошибки конфигурации здесь могут привести к серьезной утечке. Рассмотрим службу ведущего облачного провайдера для хостинга и обучения моделей ИИ. Она опирается на облачные хранилища (бакеты) для обучающих данных. Исследование Tenable показало, что у 14% организаций, использующих эту службу, хотя бы один бакет с обучающими данными имел незаблокированный публичный доступ, а примерно у 5% — хотя бы один избыточно разрешающий бакет был открыт для любого аутентифицированного пользователя. На практике это означает, что значительное число наборов данных ИИ, которые могут включать проприетарные данные для обучения или информацию о клиентах, находились всего в одном шаге от того, чтобы стать достоянием общественности. Подобное открытие данных влечет за собой множество рисков: злоумышленник может похитить обучающие данные (раскрыв интеллектуальную собственность или конфиденциальную информацию) или даже отравить данные, внедрив вредоносные образцы и исказив результаты работы модели.
Непрерывное управление воздействием угроз для цепочек поставок ИИ
Учитывая масштаб этих рисков — от неисправленных уязвимостей в библиотеках с открытым исходным кодом до унаследованных ошибок конфигурации облака и открытых наборов данных, — очевидно, что обеспечение безопасности ИИ в облаке требует непрерывного и упреждающего управления рисками. Традиционных контрольных списков безопасности недостаточно; организациям необходим подход к управлению воздействием угроз, адаптированный к уникальной поверхности атаки ИИ. На практике это означает регулярную оценку каждого слоя цепочки поставок ИИ на предмет уязвимостей, а также непрерывную оценку рисков цепочки поставок для ваших облачных сервисов.
Как это может выглядеть?
Во-первых, расширьте свою программу управления уязвимостями так, чтобы она охватывала ИИ-фреймворки и базовую инфраструктуру, на которой они запущены. Если 70% рабочих нагрузок ИИ содержат критические CVE, то сканирование и устранение уязвимостей в этих системах (включая такие ИИ-библиотеки, как TensorFlow, PyTorch, а также базовые образы ОС и слои контейнеров) должно быть главным приоритетом. Не менее важен аудит конфигураций: не доверяйте настройкам по умолчанию в управляемых ИИ-сервисах. При развертывании облачных предложений ИИ — будь то Amazon SageMaker, Google Vertex AI, Azure Cognitive Services или другие — тщательно проверяйте и ужесточайте конфигурации на каждом уровне. Убедитесь, что хранилища данных моделей не являются общедоступными по умолчанию и что служебные учетные записи или ключи API следуют принципу наименьших привилегий. Облачные провайдеры часто публикуют рекомендации по безопасности для своих ИИ-сервисов; используйте их, но сохраняйте бдительность, помня, что «по умолчанию» часто не означает «безопасно».
Управление идентификацией и доступом — еще один ключевой элемент. Применяйте строгий контроль идентификации и доступа к ИИ-ресурсам и данным. Ограничьте круг лиц и сервисов, имеющих доступ к вашим моделям, блокнотам и хранилищам данных. Сюда относится использование уникальных служебных учетных записей с минимальными областями видимости для ИИ-сервисов вместо широкого повторного использования учетных записей уровня администратора. Там, где это возможно, внедряйте многоуровневый контроль доступа (например, сетевые ограничения в дополнение к разрешениям идентификации) для защиты конфиденциальных обучающих данных. Принцип наименьших привилегий должен строго соблюдаться в средах ИИ — как для человеческих пользователей, так и для машинных идентификаторов. Как отмечают аналитики Tenable, сокращение избыточных прав и ужесточение облачных идентификационных данных имеют ключевое значение для предотвращения несанкционированного доступа, особенно к ценным хранилищам данных ИИ.
Но обеспечение безопасности ИИ начинается не с развертывания — оно начинается с разработки. Уязвимости могут быть заложены на ранних этапах в конвейере CI/CD, еще до того, как модель попадет в производство. Вот почему так важно применять подход сдвига влево (shift-left): выявление и устранение рисков безопасности на этапах разработки, интеграции и тестирования кода. Облачные платформы защиты приложений (CNAPP), в том числе от компании Tenable, помогают командам внедрять безопасность на более ранних этапах жизненного цикла, обеспечивая видимость и контроль в средах разработки и выполнения. Чем раньше вы примете меры, тем более устойчивыми станут ваши ИИ-системы.
Наконец, учитывая взаимосвязанный характер облачных рисков, организациям следует рассмотреть платформы управления воздействием угроз с надежными возможностями облачной безопасности, которые могут обеспечить целостное представление о рисках во всем облачном стеке. Эффективная платформа, готовая справиться с рисками ИИ, может сопоставлять результаты обнаружения уязвимостей в рабочих нагрузках, неверных конфигураций в облачных ресурсах, идентификационных данных и даже утечки данных, чтобы составить богатую контекстом картину ваших реальных рисков. Это помогает расставлять приоритеты при устранении уязвимостей в зависимости от их воздействия и сосредотачиваться на опасных комбинациях, которые могут привести к взлому.
Более глубокий анализ
ИИ стимулирует инновации и конкурентные преимущества, но он также создает сложную задачу в области безопасности с высокими ставками. Скрытая цепочка поставок, лежащая в основе каждого облачного сервиса ИИ, означает, что команды безопасности должны смотреть за пределы самого ИИ-приложения и защищать каждую зависимость, которая обеспечивает его работу. Это требует бдительности, правильных инструментов и проактивной стратегии. Обнадеживает то, что, внедряя непрерывное управление воздействием угроз и рассматривая рабочие нагрузки ИИ как часть более широкой облачной экосистемы, организации могут безопасно развивать инновации в области ИИ.
Обеспечение безопасности революции ИИ заключается в защите лежащих в ее основе уровней — от библиотек кода до конфигураций облака и конвейеров данных.
Чтобы узнать больше, прочтите последнее исследование Tenable, и Tenable Cloud Security Risk Report 2025.
