Меры защиты информации

1. Технические меры

• серверные сессии со случайными токенами; пароль хранится как стойкий scrypt-хеш с индивидуальной солью;
• защищенные атрибуты cookies и отдельный CSRF-токен для изменяющих запросов;
• ролевой контроль и проверка принадлежности каждой генерации, заявки и платежа конкретному пользователю;
• административные действия выполняются через сервер и регистрируются в журнале аудита;
• защитные HTTP-заголовки, ограничения запросов, нормализация входных данных и хранение API-ключей только на сервере;
• ограниченные права доступа к базе, резервное копирование и хеширование технических идентификаторов в журналах согласий.

2. Организационные меры

1. доступ предоставляется по принципу минимальных привилегий, а административная роль не выдается через публичную регистрацию;
2. секреты хранятся отдельно от исходного кода и передаются на сервер по защищенному каналу;
3. перед внешней AI-обработкой изображения перекодируются с удалением исходного имени, EXIF и GPS; данные аккаунта и сетевые идентификаторы пользователя в запрос провайдеру не включаются;
4. результаты внешней генерации выдаются через авторизованный прокси PRELUSION, который проверяет владельца задания;
5. создаются резервные копии базы и ведется журнал административных и платежных событий;
6. изменения инфраструктуры, состава данных и подключенных подрядчиков проходят отдельную проверку;
7. для инцидентов применяется порядок блокирования неправомерного доступа, расследования и уведомления уполномоченного органа в предусмотренных законом случаях.

3. Изоляция пользователей

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

4. Сообщить об уязвимости

Не публикуйте сведения об уязвимости до устранения. Направьте описание, шаги воспроизведения и оценку влияния на noreply@prelusion.ru. Не получайте доступ к чужим данным, не нарушайте работу сервиса и не используйте социальную инженерию.

Защита API-доступа

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

Внутренняя диагностика предназначена для уполномоченных сотрудников. Конфиденциальность коммерческих настроек не ограничивает предусмотренные законом права субъектов данных. Подробности использования приведены в Условиях API.