В чём суть риска
Атакующий многократно обращается к API модели, чтобы воспроизвести её поведение или построить модель-заменитель. Компания теряет интеллектуальную собственность и доход от неё, а последующие атаки на модель упрощаются.
Внешний клиент с обычным легальным доступом систематически отправляет запросы, покрывающие пространство решений модели, и собирает ответы. Каждый отдельный запрос выглядит допустимым, поэтому классические средства защиты API его не останавливают. По накопленным парам «запрос — ответ» строится копия, близкая по поведению к оригиналу. Граница доверия нарушается не взломом, а использованием сервиса не по назначению: платный или партнёрский доступ превращается в канал вывода самой модели. Копию затем можно изучать без ограничений.
Чем риск оборачивается для компании
Вложения в разработку модели обесцениваются, монетизация сервиса снижается.
Утрачивается конфиденциальность модели как объекта интеллектуальной собственности.
Имея копию, атакующему проще готовить следующие атаки на оригинал.
Где риск наиболее вероятен
Кому и что решать
Определить, какие модели составляют коммерческую ценность, и выдавать к ним доступ только через управляемый шлюз.
Обеспечить аутентификацию, квоты и анализ характера запросов по каждому клиенту API.
Включить в договоры запрет на воспроизведение модели и учитывать этот риск в тарифах и лимитах.
Что стоит наблюдать
Признаки сами по себе не доказывают инцидент. Их полезно сопоставлять с учётной записью, версией модели, решением политики, источником контекста и результатом вызова инструмента.
Какие меры создают границу
Меры работают в связке и не перекладывают ответственность на модель: важны границы полномочий, владелец, телеметрия и процедура безопасного отказа.
Договорные ограничения использования
Закрепить в условиях доступа запрет на копирование модели и право приостановить обслуживание.
Лимиты и квоты запросов
Ограничить число и частоту обращений на клиента в соответствии с заявленным сценарием.
Замедление подозрительных клиентов
Снижать скорость ответов при признаках систематического сбора, не отключая добросовестных пользователей.
Маркировка модели
Применять водяные знаки и отпечатки модели, чтобы доказать происхождение копии.
Анализ характера запросов
Отслеживать объём, разнообразие и связанность обращений по учётным записям.
Вопросы, показатели и первые шаги
Вопросы команде и поставщику
- Какие наши модели доступны извне и сколько стоит их утрата?
- Можем ли мы отличить обычного клиента от того, кто собирает ответы?
- Сможем ли мы доказать, что чужая модель скопирована с нашей?
- Что записано в договорах с клиентами API о воспроизведении модели?
Показатели контроля
- Доля внешних API моделей с настроенными квотами на клиента
- Число выявленных случаев аномального сбора ответов за период
- Время от обнаружения аномалии до ограничения доступа
Первые 30 дней
- Перечислить модели, доступные внешним клиентам, и оценить их ценность
- Настроить квоты и учёт запросов по каждому клиенту
- Проверить условия договоров на запрет воспроизведения модели
Как проверить в пилотном проекте
Проверить сегментацию, учётные записи и ограничение расхода ресурсов на вывод модели и выполнение агентов.
Сервисная учётная запись имеет минимальные полномочия для согласованной нагрузки.
Политика сети и квот ограничивает неразрешённый маршрут или нештатный расход.
Телеметрия исполнения поступает в согласованный мониторинг или процесс SOC.
Какие классы решений рассматривать
Ниже — редакционные профили поставщиков, связанные с доменом угрозы. Это не рейтинг и не подтверждение применимости: заявленные функции следует проверить в вашем пилоте по указанным критериям.
INFERA AI Security portfolio
InfEra Security · AI Security / DevSecOps
INFERA AI.SafeCode · INFERA AI.Firewall
AIGATE / DevScore / AIPitch
Aitalon · AI Gateway
AIGATE · DevScoreAqua CNAPP
Aqua Security · CNAPP / Container Security
Aqua CNAPP capabilitiesИсточники и проверка
Сначала — объяснение для русскоязычной команды. Затем — первоисточники, по которым можно проверить границы, методологию и применимость в конкретной архитектуре.