← Все руководства

Как провести лёгкую проверку атакоустойчивости внутреннего чат-бота

Шаги

1. Шаг 1: Зафиксируйте разрешение на проверку, границы тестовой среды, список доступных функций и ответственных за устранение проблем. Используйте отдельный стенд, тестовые учётные записи и синтетические данные.

2. Шаг 2: Подготовьте десять безопасных сценариев атак: прямое внедрение инструкций в запрос; скрытая инструкция в документе из базы знаний; попытка раскрыть системные правила; запрос на выдачу тестового секрета; обращение от имени другого пользователя; попытка обойти ограничения доступа к документу; провокация к опасному вызову инструмента; передача персональных данных в ответе; запрос на выполнение непроверенного кода; серия тяжёлых запросов для проверки отказоустойчивости.

3. Шаг 3: Выполните каждый сценарий на минимальном наборе безвредных запросов, не перебирайте реальные пароли, токены и персональные данные. Для каждого теста сохраните исходный запрос, контекст, ответ, вызванные инструменты и результат проверки.

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

5. Шаг 5: Занесите находки в журнал с полями «идентификатор», «сценарий», «дата», «среда», «учётная запись», «шаги воспроизведения», «ожидаемое поведение», «фактическое поведение», «доказательство», «влияние», «повторяемость», «ответственный» и «статус». Не записывайте в журнал реальные секреты и персональные данные.

6. Шаг 6: Назначьте важность по внутренней шкале: критическая — возможен полный обход доступа, раскрытие секрета или опасное действие; высокая — существенная утечка данных или надёжный обход ограничения; средняя — ограниченное нарушение с дополнительными условиями; низкая — малозначимое отклонение без заметного ущерба. Отдельно отметьте воспроизводимость и область воздействия.

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

Чеклист

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

Типичные ошибки

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