Облачная безопасность ИИ должна подтвердить наличие контроля, прежде чем агенты попадут в промышленную эксплуатацию

VB Intelligence | Анализ партнёра

Конфиденциальные вычисления на GPU позволяют защитить чувствительные рабочие нагрузки, но предприятиям также нужны доказательства того, что они могут идентифицировать агентов, изолировать арендаторов и отзывать доступ, не нарушая работу.

Если ИИ-агент скомпрометирован, сможет ли ваше предприятие остановить его и продолжить работу? Этот вопрос связывает безопасность ИИ с операционным требованием: контролировать доступ на уровне отдельной рабочей нагрузки.

Недавно я побеседовал с Ниром Червони, руководителем направления продуктов безопасности в Nebius — облачном провайдере, специализирующемся на ИИ. Он помог очертить универсальный подход, в основе которого лежит инфраструктура: отдельные идентификаторы агентов, ограниченные полномочия учётных данных, ключи шифрования под контролем клиента и возможность аудита действий. Мы также обсудили конфиденциальные вычисления на GPU как дополнительную защиту данных и моделей во время обработки, отметив при этом их чётко определённые ограничения.

На мой взгляд, главный вывод для корпоративных заказчиков заключается в том, что оценка инфраструктуры ИИ должна выходить за рамки вычислительных мощностей и сертификатов безопасности. Заказчикам нужны доказательства того, что средства контроля работают в нештатных ситуациях: при компрометации идентификатора, сбое проверки целостности или попытке пересечь границы между арендаторами.

Конфиденциальные вычисления могут укрепить эту основу. Однако они не гарантируют, что действия агента авторизованы, приложение безопасно, а результаты его работы приемлемы.

Главное

Отдельные идентификаторы агентов помогают локализовать угрозу. Совместное использование учётных данных затрудняет установление того, кто совершил те или иные действия, и выборочный отзыв доступа. Предприятиям следует проверить, приведёт ли остановка одного агента к сбою в работе других, не связанных с ним нагрузок.

Политики доступа и защитные ограничения моделей решают разные задачи. Разрешения должны ограничивать доступ агента независимо от того, как модель реагирует на запрос.

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

Для изоляции арендаторов в облаке, специализирующемся на ИИ, необходимы практические доказательства. При проверке провайдера следует оценить строгость процедур обновления оборудования, сети управления, общие плоскости управления и межсоединения GPU.

Требования к суверенитету выходят за рамки местоположения. Клиентам необходимо изучить, кто получает доступ к данным, как они обрабатываются и хранятся, а также кто контролирует средства их защиты на всех этапах развёртывания.

Что произошло

В августовском опросе VB Pulse Survey половина респондентов сообщила, что в их организациях агенты уже используются в промышленной эксплуатации. Среди них 61% отметили, что агенты хотя бы в некоторых случаях совместно используют учётные данные. В исследовании VB Pulse Survey за сентябрь лишь 14% участников, ответивших на вопрос об отзыве доступа, сообщили, что назначенный ответственный может отозвать доступ агента в течение нескольких минут.

Это вызывает практический вопрос: не опережает ли внедрение агентов развитие системы управления доступом?

Червони подчеркнул важность привычных основ безопасности: отдельного идентификатора для каждого агента, краткосрочных учётных данных с правами, ограниченными его задачами, управления секретами, ключей под контролем клиента и журналов аудита, передающих данные в систему мониторинга безопасности предприятия.

«Не полагайтесь на защитное ограничение, чтобы обеспечить то, что политика доступа может детерминированно обеспечить сама», — сказал он.

По словам Червони, Nebius инвестировала в управление идентификацией и доступом, управление ключами и секретами, а также журналирование аудита; кроме того, компания работает с клиентами, которые хотят использовать собственную систему управления ключами (KMS) или другие компоненты безопасности. На мой взгляд, эти заявления — хорошая отправная точка для определения того, как должна выглядеть проверка.

Почему это важно

Локализация агента должна быть частью требований к непрерывности бизнеса

Совместное использование учётных данных создаёт зависимость между рабочими нагрузками. Отзыв таких данных может остановить скомпрометированного агента, но вместе с ним может прерваться работа других агентов, использующих тот же доступ.

На мой взгляд, предприятиям следует оценивать контроль доступа и устойчивость к сбоям в комплексе. Назначенный ответственный, отдельный идентификатор и ограниченные полномочия создают условия для выборочной локализации угрозы. Затем необходимо провести учения и выяснить, работает ли такая локализация на практике, в том числе что происходит с активными сеансами и уже выполняемыми задачами.

Защитные ограничения модели по-прежнему полезны, но отвечают на другой вопрос. Если направить агента от нежелательного действия, это не лишит его базового разрешения на выполнение такого действия. Инфраструктура и приложение должны независимо обеспечивать соблюдение границ доступа.

Конфиденциальные вычисления делают границы доверия более явными

Червони описал конфиденциальные вычисления на GPU как расширение защиты на этап обработки данных GPU, включая защиту от действий некоторых привилегированных участников инфраструктуры в поддерживаемых конфигурациях. Аттестация предоставляет сведения о среде, которые клиент может проверить до предоставления ключей.

Справочная архитектура NVIDIA подтверждает, что для этого требуется системный подход. К обязательным возможностям относятся измеренный образ конфиденциальной виртуальной машины, конфиденциальные вычисления как на CPU, так и на GPU, средство проверки аттестации, управление ключами с поддержкой их безопасного предоставления, а также журналирование, не раскрывающее обрабатываемое содержимое.

Для заказчиков главный вопрос состоит в том, какие компоненты и пути доступа защищены в предлагаемой конфигурации. Одной лишь отметки о поддержке конфиденциальных вычислений для ответа недостаточно.

Червони также признал ограничения этой технологии: она не устраняет уязвимости приложений, не предотвращает внедрение промптов и не регулирует результаты работы моделей. Скомпрометированный идентификатор всё ещё может использовать предоставленные ему законные разрешения. Поэтому предприятиям необходимо оценивать защиту конфиденциальности вместе с авторизацией и безопасностью приложений.

Изоляция и суверенитет требуют доказательств, доступных для проверки клиентом

Червони предложил конкретный набор универсальных вопросов об изоляции арендаторов:

Оборудование: Как подготавливается оборудование при переходе от одного клиента к другому?

Очистка: Как обеспечиваются целостность прошивки и очистка памяти GPU?

Изоляция машин: Могут ли рабочие нагрузки арендаторов обращаться к интерфейсам управления?

Общие компоненты: Какие компоненты плоскости управления являются общими?

Сетевая изоляция: Как разделены высокоскоростные сети и проверялась ли изоляция независимыми специалистами?

Эти вопросы превращают общее заверение в утверждение, которое можно оценить. Мне нравится такой подход, потому что в качестве подтверждения можно изучить процедуру, конфигурацию и результаты тестирования, относящиеся именно к услуге, которой будет пользоваться клиент.

Для многих организаций это может быть самым важным моментом: различия между локализацией данных и суверенитетом часто вызывают серьёзную путаницу. Червони разграничил понятия локализации данных и суверенитета. Согласно его подходу, помимо географического расположения клиентам следует выяснить, кто может получить доступ к информации, как она обрабатывается и кто контролирует средства её защиты. Иными словами, речь идёт о гораздо большем, чем просто местоположение, — о самой сути суверенитета.

В качестве примера регулируемого развёртывания в Европе он привёл выделенные мощности, ключи под контролем клиента, предоставление ключей на основе аттестации, доступ сотрудников с соответствующими разрешениями и обязательным журналированием, а также обработку запросов без сохранения данных. Это пример архитектуры, а не доказательство того, что все сервисы Nebius обладают такими характеристиками.

На что обратить внимание

Следующие подтверждения должны касаться практической работы:

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

Соблюдение требований аттестации: Что происходит при сбое проверки и можно ли обойти политику предоставления ключей?

Производительность в конкретной конфигурации: Как изменятся задержка, пропускная способность и стоимость при включении необходимых средств защиты для рабочей нагрузки клиента?

Охват тестирования изоляции: Проверяют ли независимые испытания переназначение оборудования, интерфейсы управления, общие сервисы и конфигурацию межсоединений, которую собирается приобрести клиент?

Наблюдаемость доступа и хранения данных: Могут ли клиенты убедиться, что доступ сотрудников, журналы, резервные копии и сроки хранения данных, полученных при обработке запросов, соответствуют согласованным требованиям?

Итог

На мой взгляд, критерием выбора инфраструктуры ИИ должна быть возможность продемонстрировать контроль над выполняющейся рабочей нагрузкой. Конфиденциальные вычисления на GPU расширяют набор средств защиты, доступных предприятиям, однако операционная безопасность по-прежнему зависит от идентификации, авторизации, изоляции и восстановления.

Директорам по информационной безопасности и руководителям платформ ИИ следует начать с типового рабочего процесса агента.

Определите идентификатор: присвойте агенту отдельный идентификатор

Назначьте ответственного: назначьте сотрудника, несущего ответственность за агента

Проанализируйте разрешения: задокументируйте разрешения агента и проверьте отзыв доступа

Проверьте и оцените: измерьте время, необходимое для ограничения доступа, и влияние на зависимые сервисы.

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

На основе этих результатов отдел закупок должен определить критерии приёмки. Способность провайдера продемонстрировать выборочную локализацию угроз, защищённую обработку данных и проверяемую изоляцию должна влиять на выбор места размещения рабочей нагрузки наравне с мощностью и ценой. По мере того как агенты получают всё больше полномочий, возможность предприятия отозвать эти полномочия становится одним из главных показателей готовности к промышленной эксплуатации.

Роб Стречей — ведущий аналитик VB Intelligence.

VentureBeat — платный медиапартнёр Nebius, спонсора освещения мероприятий VentureBeat. Ни Nebius, ни другие спонсоры не контролируют редакционные материалы VentureBeat, VentureBeat Intelligence или VentureBeat Research. Мнения и оценки принадлежат VB Intelligence.