Шаг 6. Безопасность при работе с ИИ - это очень важно!

Это глава архиважная. Я не просто так отвожу безопасности целую главу.

Всё, что вы отправляете боту - известно уже не только вам

Всё, что вы отправляете в чат, уходит на чужие серверы. Проходит через них. И вы не знаете и не можете контролировать, кто может получить к ним доступ.

Работаете напрямую с поставщиком модели — данные попадают к нему. Используете сервис или агрегатор — они проходят еще и через этот сервис. Дальше всё зависит от его правил.

Персональные данные

Представим, что вы хотите попросить модель подготовить ответ клиенту. Копируете переписку, имя, телефон, адрес и номер заказа. Для вас это несколько строк текста, а с точки зрения закона и договора — персональные данные конкретного человека.

Если у вас нет права передавать такие сведения внешнему обработчику, могут возникнуть проблемы. Точная оценка зависит от страны, типа информации, согласия человека и условий договора.

Обезличивайте данные

Обычно для работы модели не нужны настоящие данные. Вместо:

Иван Петров, заказ № 18472, телефон +7..., задержка доставки на Ленинградский проспект, 12

можно передать:

Клиент А, заказ № 18472, задержка доставки по адресу клиента

Модели важно только корректно описать ситуацию и не более того.

Что нельзя отправлять в обычный чат

Никогда. Ни при каких условиях:

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

Случайно отправили секрет?

Считайте его скомпрометированным. Удаление сообщения не поможет — запрос уже улетел на сервер и попал в логи.

Что делать:

1. Немедленно отзовите ключ.
2. Смените пароль.
3. Проверьте журнал входов.
4. Убедитесь, что никто не успел воспользоваться доступом.

Простого удаления сообщения недостаточно.

Если ИИ пишет приложение

Вторая большая проблема появляется, когда вы просите модель или агента помочь с сайтом, ботом или приложением.

Агент или ассистент не должен получать без необходимости:

• Пароль от сервера.
• Доступ администратора к базе данных.
• Ключи платёжной системы.
• Основной ключ к API модели.
• Право удалять файлы и пользователей.

Принцип минимальных прав

Модель может написать код, который работает, но делает это небезопасно.

Типичные проблемы

1. SQL-инъекции

Модель может сгенерировать код, который подставляет пользовательский ввод прямо в SQL-запрос:

Плохо:

query = f"SELECT * FROM users WHERE email = '{user_email}'"

Если user_email содержит ' OR '1'='1, запрос вернёт всех пользователей.

Хорошо:

cursor.execute("SELECT * FROM users WHERE email = ?", (user_email,))

2. Открытые API без аутентификации

Модель может создать API-эндпоинт, который возвращает данные без проверки прав доступа.

3. Хранение паролей в открытом виде

Модель может предложить хранить пароли в базе как обычный текст. Это недопустимо. Пароли должны хешироваться.

4. Отсутствие валидации входных данных

Если приложение принимает файлы от пользователей, модель может забыть проверить тип файла, размер и содержимое. В результате кто-то может загрузить исполняемый файл вместо изображения.

Автоматические сканеры уязвимостей

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

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

Ответ модели тоже нужно проверять

Безопасность — это не только защита от взлома.

Если вы отправили клиенту выдуманный факт, опубликовали неправильный совет или неверно посчитали сумму, последствия тоже могут быть вполне реальными.

Что проверять перед использованием ответа

• Факты, даты, суммы.
• Ссылки на источники.
• Расчёты и формулы.
• Если модель ссылается на закон или техническую документацию, проверяйте обязательно.

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

Ответ модели не может быть единственным основанием для медицинского, юридического, финансового или критически важного технического решения.

Как защититься

Опасные действия требуют подтверждения:

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

Перед тем как нажать кнопку отправки, задайте себе четыре вопроса:

1. Удалены ли пароли, ключи, телефоны и другие лишние данные?
2. Разрешено ли передавать этот материал внешнему сервису?
3. Понимаю ли я, где хранятся история и загруженные файлы?
4. Что произойдёт, если ответ окажется ошибочным?

Если хотя бы на один вопрос ответ "не знаю", сначала разберитесь с ним. И только потом отправляйте.

Б-Безопасность

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

Регулярно:

• Отзывайте старые ключи.
• Меняйте важные пароли (доступы и ключи к серверам и важным сервисам).
• Настройте автоматическое создание резервных копий баз данных и сервисов.
• Храните эти бекапы на другом физическом сервере.

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

Но привычку думать о безопасности лучше формировать сразу, а не после того, как что-то пошло не так.