1. Резюме для руководителя
SEO AI Tools — SaaS-платформа для SEO/GEO-оптимизации и генерации контента, построенная по принципам defense-in-depth: каждый уровень (сеть, приложение, данные, ИИ-слой) имеет независимые контроли. Платформа спроектирована под требования ИБ-служб крупных российских маркетплейсов, сетей в e-commerce, фарме, финансах и YMYL-нишах.
Пять ключевых гарантий для ИБ-службы Enterprise-клиента
- Контур РФ — default для российских Enterprise-клиентов. Приложение, БД, логи, бэкапы, KMS/Vault, очереди, AI-вызовы и все эксплуатационные SEO-данные физически размещены в ЦОД на территории Российской Федерации (Timeweb Cloud / Yandex Cloud, Москва). ИИ-вызовы выполняются российскими LLM-провайдерами — YandexGPT (Yandex Cloud) и GigaChat (СберБанк); приём платежей — через ЮKassa. Локализация ПДн граждан РФ реализована по ст. 18 ч. 5 ФЗ-152. См. §§ 12, 18.
- Envelope encryption API-токенов CMS — стандарт Enterprise-интеграции. Payload токена шифруется AES-256-GCM на уникальном DEK; мастер-ключ (KEK) хранится в KMS/Vault РФ-провайдера и не покидает HSM/KMS-границу; регулярная ротация DEK, аварийный rotate KEK по security-каналу, мгновенный отзыв токена клиентом. Standard-тариф использует AES-256 at rest на уровне БД РФ-провайдера + TLS 1.2+ при передаче. См. §§ 7, 19.
- Прозрачные роли по ФЗ-152 и локализация ПДн в РФ. Правовые основания обработки определяются по ст. 6 ФЗ-152 (договор с корпоративным клиентом и/или согласие субъекта ПДн). Все ПДн граждан РФ обрабатываются и хранятся на территории Российской Федерации (ст. 18 ч. 5 ФЗ-152). Роли оператор/обработчик зафиксированы в DPA: для SaaS-аккаунта (учётные данные пользователей платформы) оператор — ООО «Люмени»; для CMS-интеграции с контентом корпоративного клиента ООО «Люмени» выступает обработчиком по поручению клиента (ст. 6 ч. 3 ФЗ-152). Сведения о статусе оператора в реестре операторов ПДн Роскомнадзора (ст. 22 ФЗ-152) предоставляются ИБ-службе клиента по запросу при vendor security review. См. §§ 2, 12, 23.
- Нет доступа к коммерчески чувствительным данным клиента. Scoped API-токен интеграции на уровне платформы (whitelist методов CMS-адаптера) и на стороне клиента (scopes API-ключа) категорически не имеет доступа к: заказам, покупателям, платежам, ценам, остаткам, складам, отгрузкам, корзинам, личным кабинетам. Передаваемые данные — только микроразметка, мета-теги, SEO-поля карточек, статьи блога. См. §§ 19, 20, 22.
- AI не публикует изменения в production CMS без ручного approve. Для Enterprise-сегмента обязателен workflow draft → approve → publish: AI-агент готовит изменение в статусе draft, ответственный сотрудник клиента просматривает diff и явно подтверждает publish; автопубликация отключена на уровне тарифа и DPA; любое изменение откатывается одним действием. См. § 20.
Дополнительные технические контроли:
- Идентификация и аутентификация: bcrypt с 12 раундами соли, серверные сессии в PostgreSQL, блокировка после 10 неудачных попыток, прогрессивная задержка ответов, OAuth 2.0 через Yandex ID.
- Шифрование канала: TLS 1.2+ для всего входящего трафика, HSTS, AES-256 at rest на уровне СУБД (Timeweb Cloud / Yandex Cloud, Москва).
- Изоляция клиентов: логическая мультитенантность с явной фильтрацией по
userId на каждом запросе и дополнительными проверками checkProjectAccess в MCP-слое.
- Платежи: данные банковских карт не проходят через нашу инфраструктуру — используется ЮKassa Checkout (соответствие ОПДн Банка России и ПДСС РФ).
- ИИ-слой: единый шлюз AI Gateway, серверная инжекция системных промптов, блокировка промпт-инъекций, маскирование ключей в логах.
- Аудит: неизменяемый журнал действий (
audit_log), журнал сессий (user_session_log), маскирование чувствительных полей в логах.
- Еженедельный AI-аудит безопасности: автоматизированное сканирование кодовой базы и инфраструктурных конфигов российскими ИИ-моделями с авто-устранением находок в рамках стандартного SSDLC (см. § 15).
- Защита API от несанкционированного доступа: многоуровневые контроли — scoped-токены, per-token rate-limit, мониторинг аномалий, мгновенный отзыв токена клиентом (см. § 6).
- Реагирование на инциденты: уведомление Роскомнадзора и затронутых лиц в сроки, установленные ст. 21 ФЗ-152 (ФЗ-266: 24 часа на первичное, 72 часа на результаты расследования).
2. Соответствие стандартам и нормативным требованиям
Российская Федерация · отраслевые best practices
| Стандарт / Норма | Статус | Применение |
|---|
| Федеральный закон № 152-ФЗ «О персональных данных» | Соблюдается | Согласия, правовые основания обработки, права субъектов, Privacy Policy, политика обработки ПДн |
| Ст. 18 ч. 5 ФЗ-152 (закон о локализации, ФЗ-242 от 21.07.2014) | Соблюдается архитектурно | Все ПДн граждан РФ (учётные данные, журналы аудита, эксплуатационные SEO-данные) хранятся в БД на территории РФ; см. § 12 |
| Ст. 12 ФЗ-152 «Трансграничная передача персональных данных» (в ред. ФЗ-23 от 28.02.2025, действ. с 01.07.2025) | Соблюдается архитектурно | Архитектура продукта реализует локализацию обработки в РФ: все вычисления, включая ИИ-вызовы к YandexGPT и GigaChat, выполняются на узлах в юрисдикции РФ |
| Ст. 21 ч. 3.1 ФЗ-152 (ФЗ-266: уведомление об инцидентах) | Регламент внедрён | Уведомление РКН в течение 24 часов с момента факта утечки и 72 часов с результатами расследования; см. § 16 |
| Ст. 13.11 КоАП (ред. ФЗ-420 от 30.11.2024, действ. с 30.05.2025) | Учтено в модели рисков | Оборотные штрафы за утечки ПДн; митигация — минимизация PII, шифрование, мониторинг (§§ 7, 13, 16) |
| Ст. 272.1 УК РФ (введ. с 30.05.2025) | Учтено | Уголовная ответственность за незаконный оборот ПДн; внутренние политики и контроль доступа (§§ 5, 9) |
| Реестр операторов ПДн Роскомнадзора (ст. 22 ФЗ-152) | Уведомление в порядке ст. 22 ФЗ-152 | Все ПДн граждан РФ обрабатываются и хранятся исключительно на территории Российской Федерации (ст. 18 ч. 5 ФЗ-152; см. § 12). ИИ-вызовы выполняются российскими LLM-провайдерами — YandexGPT (Yandex Cloud) и GigaChat (СберБанк); приём платежей — через ЮKassa в РФ-юрисдикции. Правовые основания обработки — по ст. 6 ФЗ-152 (договор с корпоративным клиентом и/или согласие субъекта ПДн). Сведения о статусе оператора в реестре предоставляются ИБ-службе клиента по запросу при vendor security review. Реквизиты оператора — см. § 23 |
| Приказ ФСТЭК № 21 (защита ПДн в ИСПДн) | Целевой уровень УЗ-3 | Реализованы организационные и технические меры: идентификация/аутентификация, контроль доступа, регистрация событий, антивирус, обнаружение вторжений на уровне субпроцессоров |
| Федеральный закон № 149-ФЗ «Об информации» | Соблюдается | Хранение логов, защита информации, порядок реагирования на запросы уполномоченных органов |
| Федеральный закон № 54-ФЗ (онлайн-кассы) | Соблюдается через ЮKassa | Формирование и передача чеков в ОФД — на стороне платёжного оператора |
| Положение Банка России о защите ПДн (ОПДн) | Соблюдается через ЮKassa | Платёжные операции и защита карточных данных — ответственность платёжного оператора |
| OWASP Top 10 (2021) | Митигированы | A01-A10: SSDLC-практики, см. § 14 |
| OWASP API Security Top 10 (2023) | Митигированы | BOLA, BFLA, broken auth, mass assignment, rate limiting |
| OWASP Top 10 for LLM Applications (2025) | Митигированы | LLM01–LLM10: серверная инжекция промптов, output handling, контроль чувствительной информации (§ 10) |
Оператор персональных данных — ООО «Люмени», ИНН 5047325684, ОГРН 1265000034320. Правовые основания обработки определяются по ст. 6 ФЗ-152 (договор с корпоративным клиентом и/или согласие субъекта ПДн). Локализация обработки и хранения ПДн граждан РФ на территории Российской Федерации реализована по ст. 18 ч. 5 ФЗ-152 (см. § 12). Роли оператор/обработчик зафиксированы в DPA с корпоративным клиентом (см. § 12). Сведения о статусе оператора в реестре операторов ПДн Роскомнадзора (ст. 22 ФЗ-152) предоставляются ИБ-службе клиента по запросу при vendor security review.
Состав нормативной базы сверен с действующим на 21.05.2026 законодательством Российской Федерации по открытым официальным источникам (КонсультантПлюс, Гарант, официальный сайт Роскомнадзора, опубликованные Постановления Правительства РФ и приказы ФСТЭК России за 2025–2026 гг.). Новых актов, применимых к SaaS-обработке ПДн в конфигурации платформы (контур РФ, без КИИ-сегментов клиента, с архитектурной локализацией обработки в РФ), относительно набора, перечисленного в таблице выше, по состоянию на 21.05.2026 не выявлено. Следующая плановая сверка нормативной базы — через 6 месяцев или при вступлении в силу значимого нового регулирования.
3. Архитектура и периметр безопасности
Платформа построена на принципе defense-in-depth с несколькими независимыми слоями защиты:
- Слой 1 — Сеть: reverse-proxy (nginx) с TLS-терминацией, ограничением методов, защитой от Slowloris, лимитами на размер тела запроса. UFW-файрвол на origin-серверах разрешает только 80/443/SSH.
- Слой 2 — РФ-периметр: для трафика клиентов из РФ используется выделенный reverse-proxy на VPS-площадке Timeweb (Москва, ЦОД с аттестацией по 152-ФЗ, УЗ-3). Прокси терминирует TLS 1.2/1.3, проверяет заголовки
Origin/Referer, ограничивает методы и rate-лимитирует подозрительный трафик. Сертификаты выпускаются и продлеваются автоматически через ACME-провайдера с использованием certbot. Все учётные данные пользователей и аудит-журналы остаются в БД на территории РФ (см. § 12).
- Слой 3 — Приложение: Express.js + строгие middleware (rate limiting, CSRF Origin check, валидация Zod на всех входах, заголовки безопасности).
- Слой 4 — Данные: отдельные роли БД для приложения и миграций, явная фильтрация по
userId, шифрование at rest.
- Слой 5 — ИИ-шлюз: единая точка вызова всех LLM-провайдеров с централизованными контролями.
Все компоненты разработаны на TypeScript со строгой типизацией; схема БД определяется через Drizzle ORM, миграции выполняются исключительно raw SQL для явного контроля над изменениями схемы.
4. Аутентификация и управление сессиями
OWASP ASVS V2 · ст. 19 ФЗ-152 (требования к обеспечению безопасности ПДн)
- Хеширование паролей: bcrypt, 12 раундов соли (≈ 250 мс на хеш на современном CPU). Пароли никогда не хранятся и не логируются в открытом виде.
- Сессии: stateful, хранятся в PostgreSQL через
connect-pg-simple; secure cookie, httpOnly, SameSite=Lax. Идентификатор сессии — криптографически стойкий random string. Срок жизни — 7 дней с rolling-обновлением.
- Защита от брутфорса: блокировка аккаунта (
lockedUntil) после 10 неудачных попыток на 15 минут; прогрессивная задержка ответов (exponential backoff); rate limiting 15 запросов на вход за 15 минут с одного IP.
- Восстановление пароля: одноразовый токен с TTL 1 час, отправляется только на зарегистрированный e-mail; ответ API не раскрывает существование аккаунта (защита от user enumeration).
- OAuth 2.0: поддержка входа через Yandex ID. Токены провайдера не хранятся — используются только для первичной верификации e-mail.
- Logout: уничтожение серверной сессии + очистка cookie. Возможен принудительный logout всех сессий пользователя (incident response).
5. Контроль доступа и роли
- RBAC: роли пользователя —
USER, ADMIN, SUPER_ADMIN. Middleware requireMinRole применяется на уровне маршрута.
- Принцип наименьших привилегий: каждая операция явно проверяет принадлежность ресурса пользователю. Нет «общих» эндпоинтов, возвращающих данные по
id без проверки владения.
- BOLA-mitigation (OWASP API #1): все запросы к ресурсам (Project, Keyword, Cluster, Page) фильтруются по
userId текущей сессии в слое запросов — невозможно получить чужие данные подменой id в URL.
- Административный доступ: к Admin Panel и PII-данным имеют доступ только пользователи с ролью
SUPER_ADMIN; все действия фиксируются в неизменяемом audit_log с userId, IP, User-Agent и timestamp. Доступ выдаётся персонально, отзывается при увольнении/смене роли, ротация ключей доступа — по регламенту.
6. Защита API
OWASP API Security Top 10 (2023)
- Rate limiting (express-rate-limit): дифференцированные лимиты — login 15/15 мин, регистрация и forgot-password 5/60 мин, общий API 200 запросов/мин.
- CSRF-защита: кастомная проверка заголовков
Origin и Referer против allow-list разрешённых хостов (big-lab.ai, 12nemtsev.ru, seoaitools.ru, white-label-домены).
- CORS: явный allow-list на уровне специфических эндпоинтов (например,
/api/landing-contact); по умолчанию запрещены cross-origin запросы.
- Валидация входа: все тела запросов и параметры проходят валидацию через Zod-схемы из
shared/schema.ts; нет «доверенных» полей.
- Mass-assignment-mitigation: insert-схемы Drizzle используют
.omit() для явного исключения полей, контролируемых сервером (userId, createdAt, role).
- SQL-injection: все запросы — параметризованные (Drizzle ORM либо
pool.query с плейсхолдерами); прямой конкатенации SQL в коде нет.
- XSS: React автоматически экранирует значения;
dangerouslySetInnerHTML используется только с санитизированным HTML.
- Заголовки безопасности:
Strict-Transport-Security, X-Content-Type-Options: nosniff, X-Frame-Options: DENY (для админ-панели), Referrer-Policy: strict-origin-when-cross-origin.
- Webhook-подписи: все входящие webhook'и (платёжная система, CMS) валидируются по HMAC-подписи с использованием секретов из окружения.
Защита от несанкционированного доступа к API
Подблок отвечает на ключевой вопрос корпоративного ИБ-ревью: «что произойдёт, если злоумышленник целенаправленно попытается подключиться к API SEO AI Tools — без токена, с украденным токеном клиента, или автоматизированным перебором». Ниже — threat-model по трём сценариям и контроли, которые применяются на каждом из них. Дублирования с §§ 4, 16, 19, 20 нет — даны перекрёстные ссылки.
Сценарий 1. Подключение без токена или с невалидным токеном.
- Все защищённые эндпоинты требуют валидной серверной сессии (см. § 4) либо валидного API-токена. Запросы без учётных данных отбиваются на уровне middleware ещё до попадания в бизнес-логику и до любых обращений к БД.
- Reverse-proxy (nginx) на входе ограничивает HTTP-методы, размер тела запроса и применяет первичные rate-лимиты ещё до приложения (см. § 3, слой 1–2).
- Ответы на неавторизованные запросы не раскрывают существование ресурсов: consistent 401/404, без user enumeration, без утечки имён пользователей/проектов/идентификаторов CMS (согласовано с § 4 — защитой от user enumeration на flow восстановления пароля).
- Заголовки безопасности (HSTS,
X-Content-Type-Options, Referrer-Policy, X-Frame-Options) и строгий CORS-allow-list — см. список выше — исключают cross-origin-атаки и кликджекинг как путь обхода аутентификации.
Сценарий 2. Использование украденного или утёкшего токена клиента.
- Scoped-токены: токен интеграции имеет область применения, ограниченную исключительно SEO-namespace (микроразметка, мета-теги, SEO-поля карточек, статьи блога). Доступа к заказам, клиентским базам, платежам, ценам, остаткам, складам у токена нет — ни на стороне платформы (whitelist CMS-методов), ни на стороне клиентского CMS (scopes API-ключа). Подробнее — §§ 19, 20.
- Per-token rate limiting: к общему лимиту 200 запросов/мин добавляется per-token лимит — аномальные всплески по конкретному токену автоматически throttle'ятся до ручного разбора.
- Мониторинг аномалий: отслеживаются нетипичные паттерны использования токена — всплески по новым IP, нестандартные user-agent, нетипичная география запросов, нехарактерные эндпоинты. При срабатывании детектора — автоматический throttle и алерт в ИБ-канал.
- Allow-list IP / доменов — Enterprise: по запросу под DPA для Enterprise-клиента к токену привязывается явный allow-list исходящих IP клиента и/или доменов; запросы с других источников отклоняются вне зависимости от валидности токена.
- Принудительная ротация по подозрению на компрометацию: по нашей инициативе либо по запросу клиента токен инвалидируется, клиенту выпускается новый, старый перестаёт работать в течение того же запроса. Для Enterprise — аварийный rotate KEK через security-канал делает все ранее зашифрованные токены нечитаемыми (см. § 19, envelope encryption).
- Мгновенный отзыв клиентом: клиент в любой момент отзывает токен из личного кабинета — интеграция останавливается без побочных эффектов, никаких отложенных операций по отозванному токену не выполняется (детали — § 19).
- Полный audit log по токену: каждый вызов токена фиксируется в
audit_log (userId, токен, метод, URL, before/after diff для записей в CMS, IP, user-agent, timestamp); журнал доступен ИБ-службе клиента в UI и экспортом по API (см. §§ 13, 20).
Сценарий 3. Перебор и автоматизированные атаки (credential stuffing, fuzzing, scraping, DDoS).
- Многоуровневый rate limiting: per-IP, per-account, per-token, per-endpoint — с конкретными значениями для чувствительных flow (login — 15/15 мин, регистрация и forgot-password — 5/60 мин, общий API — 200/мин; см. начало § 6 и § 4).
- Прогрессивная задержка ответов (exponential backoff) на flow аутентификации и блокировка аккаунта (
lockedUntil) после 10 неудачных попыток на 15 минут — делают credential stuffing экономически нецелесообразным (см. § 4).
- Защита от Slowloris и больших тел запроса на уровне reverse-proxy — ограничение времени удержания соединения, размера body, числа одновременных соединений с одного IP (см. § 3, слой 1).
- Защита от типовых SQLi/XSS-паттернов на уровне nginx-правил и на уровне приложения (параметризованные запросы Drizzle ORM, валидация Zod, React-эскейпинг — см. бюллетени § 6 выше).
- Защита от ботов: отсев нестандартных и пустых user-agent на flow аутентификации, отказ в обслуживании при явных признаках автоматизированного fuzzing.
Реакция на подозрение на компрометацию токена клиента. Процедура согласована с § 16 «Реагирование на инциденты»:
- Detection: срабатывание детектора аномалий по токену либо сигнал от клиента → инцидент классифицируется по тяжести в течение 1 часа.
- Containment: отзыв скомпрометированного токена, throttle/блокировка подозрительных IP, принудительный logout затронутых сессий пользователя; для Enterprise — аварийный rotate KEK (§ 19).
- Уведомление клиента: в сроки, согласованные DPA (как правило, 24–72 часа), с технической детализацией для собственных регуляторных уведомлений клиента (см. § 16, ФЗ-266).
- Совместное расследование: предоставление выписки из
audit_log по токену, согласование root cause, post-mortem и плана предотвращения повтора.
У злоумышленника без валидного токена нет ни одной точки входа в данные клиента; украденный токен ограничен по scope, по rate, по гео/IP (Enterprise) и отзываем за секунды.
7. Шифрование данных
| Уровень | Алгоритм / Протокол | Где применяется |
|---|
| In transit (внешний) | TLS 1.2 / 1.3, ECDHE | Весь публичный HTTPS-трафик; HSTS включён |
| In transit (внутренний) | TLS внутри VPC провайдеров | Соединения app → БД, app → ЮKassa / YandexGPT / GigaChat |
| At rest (БД) | AES-256 | PostgreSQL на Timeweb Cloud / Yandex Cloud (Москва) — по умолчанию |
| At rest (бэкапы) | AES-256 | Снапшоты на уровне облачного провайдера |
| Пароли | bcrypt, 12 раундов | Таблица users, поле password_hash |
| Сессии | Cryptographically random ID | Подписан секретом сессии (HMAC-SHA256) |
| API-токены клиентов CMS | Enterprise: envelope encryption (AES-256-GCM payload + KEK в KMS/Vault) — стандарт интеграции. Standard: AES-256 at rest на уровне БД РФ-провайдера + TLS 1.2+ при передаче. | Enterprise — стандарт Enterprise-интеграции (не опция по запросу): payload токена шифруется AES-256-GCM на уникальном DEK, мастер-ключ (KEK) и DEK хранятся в KMS/Vault РФ-провайдера и не покидают HSM/KMS-границу, регулярная ротация DEK, аварийный rotate KEK по security-каналу, мгновенный отзыв ключа и токена через UI. Standard — fallback-режим: токены хранятся в БД РФ-провайдера с AES-256 at rest, доступ только для владельца проекта, передача в CMS поверх TLS 1.2+ с проверкой сертификата, отзыв токена клиентом на своей стороне в любой момент. См. § 19. |
8. Изоляция клиентов (multi-tenancy)
Платформа использует логическую мультитенантность с общей схемой БД и строгой фильтрацией по userId:
- Application-level isolation: каждая сущность (Project, Keyword, Cluster, Page, ApiKey) содержит явное поле
userId. Все SQL-запросы используют .where(eq(table.userId, currentUserId)) — невозможно «забыть» фильтр.
- MCP-сервер: доступ к инструментам ограничен
MCPAuthContext.allowedProjectIds; каждая операция обёрнута в withAccessCheck.
- Code review: любой PR, добавляющий новый запрос к БД без userId-фильтра, отклоняется на ревью.
- Enterprise-опция: для крупных клиентов доступна выделенная схема БД или dedicated instance (по запросу).
9. Управление секретами
- Хранение: все секреты (API-ключи провайдеров AI, БД, платёжной системы, OAuth) находятся в переменных окружения (
process.env) и никогда не коммитятся в репозиторий. Файл .env исключён через .gitignore.
- Маскирование в логах: функция
maskApiKey заменяет середину ключа на ***, оставляя только первые и последние 4 символа. То же применяется в API-ответах.
- Ротация: ключи провайдеров AI могут быть обновлены динамически через таблицу
ai_tool_settings без перезапуска приложения. Сервисные аккаунты Yandex Cloud и ключи GigaChat изолированы в файлах внутри домашней директории non-root пользователя с правами 0600.
- Доступ к production-секретам: ограничен ролью DevOps; передача — только через зашифрованные каналы.
- Запрет утечек: CI-пайплайн проверяет добавляемые файлы на паттерны секретов (regex для ключей облачных провайдеров, AI-ключей, ключей платёжной системы).
10. Безопасность ИИ-слоя
OWASP Top 10 for LLM Applications (2025)
- AI Gateway: единая точка вызова всех LLM-провайдеров (YandexGPT, GigaChat). Прямые вызовы из кода запрещены архитектурно. Маршрутизация на RU-провайдеров активируется флагом
LLM_RF_ONLY для Enterprise-RU тенантов или per-call опцией forceRussianLLM.
- Серверная инжекция промптов: системные инструкции добавляются на стороне сервера и недоступны для модификации пользователем — это ключевая митигация LLM01 (Prompt Injection).
- Контекст даты:
buildDateContext() автоматически инжектируется в каждый системный промпт для предотвращения галлюцинаций об устаревших данных.
- Логирование вызовов: каждый вызов AI пишется в
ai_api_usage с токенами, latency, моделью и метаданными проекта — для аудита и контроля стоимости.
- Output handling: ответы LLM, отображаемые в UI, проходят через React-эскейпинг. Markdown рендерится через библиотеку с sanitization (исключены
<script>, onerror атрибуты).
- Контроль чувствительной информации: в промпты не включаются хешированные пароли, токены сессий, банковские данные. PII попадает в промпты только в объёме, необходимом для задачи (имя автора статьи, e-mail контакта — по явному запросу пользователя). Передача такой ПДн в составе пользовательского контента в LLM-субпроцессор (YandexGPT / GigaChat) выполняется в рамках поручения субпроцессору по ст. 6 ч. 3 ФЗ-152 и соответствующего DPA с провайдером LLM в юрисдикции РФ (см. § 12, карточка ролей оператор/обработчик).
- Поставщики моделей: для Enterprise-RU тенантов используются исключительно российские LLM-провайдеры, заявляющие data-not-used-for-training по умолчанию для API-вызовов: YandexGPT (Yandex Cloud) и GigaChat (СберБанк). Маршрутизация управляется на уровне AI Gateway флагом
LLM_RF_ONLY; все вызовы LLM выполняются к российским провайдерам в юрисдикции РФ.
11. Платежи (ЮKassa)
- ЮKassa Checkout: весь процесс ввода и хранения карточных данных происходит в инфраструктуре ЮKassa (соответствие требованиям ПДСС РФ и ОПДн Банка России, регулярный аудит). Наш сервер никогда не видит номер карты, CVV или срок действия.
- Хранимые данные платежа: только идентификатор покупателя, идентификатор подписки и
last4 цифры — значения, безопасные для хранения.
- Webhook ЮKassa: все события валидируются по HMAC-подписи с секретом, известным только серверу. Запросы без валидной подписи отклоняются.
- Идемпотентность: входящие события обрабатываются с учётом
event.id для защиты от двойной обработки.
- 3-D Secure 2: поддерживается автоматически на стороне ЮKassa.
- 54-ФЗ (онлайн-кассы): формирование чеков и передача в ОФД — на стороне ЮKassa.
12. Локализация данных (ст. 18 ч. 5 ФЗ-152, ред. ФЗ-23 от 28.02.2025)
Контур РФ — default для российских Enterprise-клиентов. Платформа хранит и обрабатывает все данные пользователей и их проектов исключительно на территории Российской Федерации в соответствии с ФЗ-242 (закон о локализации) и ст. 18 ч. 5 ФЗ-152 в ред. ФЗ-23 от 28.02.2025 (действ. с 01.07.2025). Все компоненты продуктового контура — application, БД, логи, бэкапы, KMS/Vault, очереди, AI-вызовы — физически размещены в ЦОД на территории РФ (Timeweb Cloud / Yandex Cloud, Москва). ИИ-вызовы выполняются российскими LLM-провайдерами — YandexGPT (Yandex Cloud) и GigaChat (СберБанк); приём платежей — через ЮKassa в РФ-юрисдикции (54-ФЗ + ОФД, ОПДн Банка России, ПДСС РФ).
| Категория | Где хранится | Юрисдикция | Срок хранения |
|---|
| Учётные данные пользователей (e-mail, имя, хеш пароля, роль, статус) | PostgreSQL на площадке РФ-провайдера (Timeweb/Yandex Cloud, Москва) | РФ | Срок действия аккаунта + 12 месяцев, далее обезличивание |
Журналы аутентификации и аудита (user_session_log, audit_log, IP, User-Agent) | PostgreSQL на площадке РФ-провайдера | РФ | Сессии — 180 дней; аудит — 3 года |
Платёжные метаданные (идентификатор покупателя, идентификатор подписки, last4) | ЮKassa + ссылочная запись в БД РФ | РФ | ≥ 5 лет (бухучёт) |
| Эксплуатационные SEO-данные: URL и тексты страниц клиента, ключевые слова, кластеры, метрики позиций, AI-генерации | PostgreSQL на application-узле (Timeweb Cloud, Москва) | РФ | Срок действия аккаунта; удаление по запросу — в течение 30 дней |
| Логи приложения (request/response, ошибки) | Файлы на application-узле | РФ | 30–90 дней |
| Бэкапы БД | Снапшоты у РФ-провайдера, AES-256, in-region РФ | РФ | 30 дней rolling |
Соблюдение ст. 18 ч. 5 ФЗ-152 и ФЗ-23 от 01.07.2025
Все персональные данные граждан РФ — регистрационные сведения пользователей платформы (e-mail, имя, хеш пароля), связанные с ними журналы и все эксплуатационные SEO-данные — подлежат первичной записи, систематизации, накоплению, хранению, уточнению и извлечению исключительно в базах данных, физически расположенных на территории Российской Федерации (Timeweb Cloud / Yandex Cloud, Москва).
ИИ-вызовы выполняются российскими LLM-провайдерами (YandexGPT, GigaChat). Приём платежей — через ЮKassa в РФ-юрисдикции. Все операционные узлы платформы (application, БД, KMS/Vault, бэкапы) размещены в ЦОД на территории РФ.
Роли по ФЗ-152: оператор и обработчик
Распределение ролей по ст. 3 и ст. 6 ч. 3 ФЗ-152 определяется сценарием обработки и фиксируется в DPA с корпоративным клиентом:
- SaaS-аккаунт платформы (учётные данные пользователей платформы — e-mail, имя, хеш пароля, роль, журналы аудита доступа к платформе): оператор — ООО «Люмени». Правовые основания — ст. 6 ч. 1 п. 5 ФЗ-152 (исполнение договора с субъектом ПДн) и согласие пользователя при регистрации.
- CMS-интеграция и обработка контента корпоративного клиента (тексты статей, мета-теги, SEO-поля карточек товаров, имена авторов и иные ПДн третьих лиц, которые могут содержаться в контенте клиента): оператор — корпоративный клиент, обработчик по поручению — ООО «Люмени» (ст. 6 ч. 3 ФЗ-152). Поручение, перечень действий, требования к защите и срок обработки фиксируются в DPA. Ответственность перед субъектом ПДн несёт оператор; ООО «Люмени» отвечает перед оператором в объёме поручения и с учётом ограничений ответственности, согласованных в DPA.
- Субпроцессоры по поручению ООО «Люмени» (Timeweb Cloud / Yandex Cloud — инфраструктура, YandexGPT и GigaChat — ИИ-вызовы, ЮKassa — платежи): привлекаются с письменного согласия корпоративного клиента (ст. 6 ч. 3.1 ФЗ-152), выраженного в DPA либо в форме согласования при изменении перечня субпроцессоров с правом возражения клиента в течение согласованного срока. Ссылки на публичные DPA субпроцессоров и их актуальные редакции — приложение к DPA с корпоративным клиентом.
Data retention & deletion SLA
- Удаление по запросу субъекта ПДн / клиента: production-данные (учётные данные, эксплуатационные SEO-данные проектов, контентные генерации) удаляются из активной БД в течение 30 дней с момента подтверждённого запроса.
- Удаление учётной записи: при удалении аккаунта пользовательские данные обезличиваются через 12 месяцев (до этого срока хранятся для разрешения возможных споров и соблюдения требований законодательства).
- Бэкапы: хранятся 30 дней rolling, по истечении которых старые снапшоты автоматически удаляются у РФ-провайдера; целевое удаление данных конкретного клиента из текущих бэкапов — по запросу под DPA, итоговое полное вымывание гарантируется циклом ротации (не более 30 дней).
- Логи аутентификации и аудита: сессионные логи — 180 дней, аудит-логи — 3 года (срок обусловлен ст. 13.11 КоАП и требованиями ст. 19 ФЗ-152 к контролю доступа к ПДн).
- Платёжные метаданные: идентификатор покупателя, идентификатор подписки, last4 — ≥ 5 лет (требование бухгалтерского учёта РФ).
- Подтверждение удаления: по запросу ИБ-службы клиента предоставляется письменное подтверждение факта удаления с указанием категорий данных и даты.
Для Enterprise-клиентов доступна опция выделенной инсталляции: все данные клиента и его проектов хранятся в dedicated instance на аттестованной площадке РФ-провайдера. Конфигурация согласовывается отдельным DPA.
13. Логирование и аудит
- Audit log (
audit_log): фиксирует userId, action, entity_type, entity_id, details, ip, user_agent, timestamp. Запись — append-only.
- Session log (
user_session_log): события login, logout, heartbeat, register, password reset, lockout. Используется для forensic-анализа.
- API request log: метод, путь, статус, длительность,
userId (если есть). Тело запроса не логируется при наличии полей password, token, secret.
- Маскирование: все автоматические правила маскирования применяются до записи в лог; ключи маскируются через
maskApiKey.
- Целостность логов: логи централизованно собираются на стороне РФ-провайдеров (Timeweb / Yandex Cloud Logging) с их штатной защитой от модификации.
14. Безопасная разработка (SSDLC)
- Code review: 100% изменений проходят review до merge в
main; критические изменения (auth, billing, БД) требуют второго ревьюера.
- Static analysis: TypeScript в
strict-режиме; ESLint с security-плагинами; tsc --noEmit блокирует merge при ошибках типов.
- Dependency audit: регулярные запуски
npm audit в CI, обновление уязвимых пакетов в течение 7 дней для high/critical.
- SAST: регулярные прогоны статического анализатора кода для поиска паттернов небезопасного кода (инъекции, утечки секретов, опасные API).
- Secrets-scanning: pre-commit hook + CI-проверка на паттерны API-ключей.
- Branch protection: запрещён прямой push в основную ветку приватного git-репозитория; обязательные code review и status-checks до merge.
- Production access: SSH через ключи (без паролей), сервера обновляются через автоматизированный
script/deploy.sh от non-root пользователя deployer.
15. Управление уязвимостями и обновления
- Patch policy: critical CVE — в течение 24 часов после публикации; high — 7 дней; medium — 30 дней.
- OS-уровень: регулярные
apt upgrade на серверах, security-патчи накатываются автоматически (unattended-upgrades).
- Зависимости приложения: автоматический мониторинг уязвимостей npm-зависимостей в приватном git-репозитории; обновления тестируются в staging до выкатки в production.
- Penetration testing: внутренние тесты — ежеквартально; ежегодный внешний pentest силами независимой ИБ-команды (web-приложение, API, аутентификация, мультитенантность, ИИ-слой). Executive summary последнего внешнего pentest предоставляется ИБ-службам корпоративных клиентов под NDA; по всем находкам уровня critical/high проводится повторное тестирование (retest) после устранения с фиксацией результатов в summary. Для Enterprise-клиентов возможна совместная организация дополнительного pentest (в т. ч. силами выбранного клиентом подрядчика) с согласованием scope и rules of engagement.
- Responsible disclosure: сообщения об уязвимостях принимаются на security@12nemtsev.ru; первичный ответ — в течение 48 часов.
Еженедельный AI-аудит безопасности
В дополнение к SAST, npm audit, secrets-scanning, ежеквартальным внутренним тестам и ежегодному внешнему pentest (см. § 14 и выше) платформа использует автоматизированный AI-аудит безопасности. Это дополнительный слой контроля, а не замена перечисленных практик.
- Расписание: запуск раз в неделю по cron / scheduled job, без участия человека.
- Предмет сканирования: код приложения, инфраструктурные конфиги (nginx, systemd, pm2, deploy-скрипты), зависимости, типовые паттерны уязвимостей — инъекции, утечки секретов, опасные API, небезопасные дефолты, мисконфигурации.
- Авто-устранение находок: исправления готовятся автоматически и проходят стандартный SSDLC-контур из § 14 (code review, TypeScript strict, ESLint, CI status-checks, branch protection, staging-проверка) до попадания в production; результаты по каждому запуску фиксируются во внутреннем трекере уязвимостей с привязкой к коммиту-исправлению.
- ИИ-провайдеры: сканирование выполняется исключительно российскими LLM в юрисдикции РФ — самые мощные доступные на момент запуска модели; код и инфраструктурные конфиги при этом обрабатываются на узлах в РФ (согласовано с §§ 10, 12). Конкретные модели в публичном тексте не называются и могут меняться по мере появления более сильных российских LLM; актуальный список предоставляется ИБ-службе клиента под NDA.
16. Реагирование на инциденты
ст. 21 ФЗ-152 · ФЗ-266 · ст. 13.11 КоАП РФ
- Детектирование: мониторинг логов на аномалии (всплески 5xx, нестандартные user-agent, попытки массового перебора).
- Triage: классификация инцидента по тяжести (P0–P3) в течение 1 часа после обнаружения.
- Containment: изоляция затронутых сервисов, отзыв скомпрометированных токенов, принудительный logout затронутых пользователей.
- Уведомления (ФЗ-266 от 14.07.2022):
- Роскомнадзор — первичное уведомление о факте инцидента, повлёкшего неправомерную передачу (предоставление, распространение, доступ) ПДн, в течение 24 часов с момента обнаружения (ч. 3.1 ст. 21 ФЗ-152).
- Роскомнадзор — уведомление о результатах внутреннего расследования инцидента в течение 72 часов с момента обнаружения (ч. 3.1 ст. 21 ФЗ-152).
- ФСБ России / НКЦКИ — уведомление при признаках компьютерного инцидента в соответствии с 187-ФЗ «О безопасности КИИ» (если применимо к клиенту).
- Затронутые пользователи — без неоправданной задержки, с описанием инцидента, категорий затронутых данных и принятых мер.
- Корпоративные клиенты с DPA/договором — в сроки, согласованные договором (как правило, 24–72 часа), с технической детализацией для их собственных регуляторных уведомлений.
- Уведомление контрагентов и партнёров платформы — в сроки, согласованные двусторонними договорами и DPA.
- Eradication & Recovery: устранение root cause, восстановление сервиса, post-mortem с уроками и планом предотвращения.
- Документация: каждый инцидент документируется во внутреннем регистре с timeline, ответственными, действиями.
17. Резервное копирование и Business Continuity
- Бэкапы БД: автоматические снапшоты ежедневно, point-in-time recovery до 7 дней назад, hourly-снапшоты для Enterprise. Срок хранения — 30 дней rolling.
- Шифрование: бэкапы хранятся в шифрованном виде (AES-256) на стороне облачного провайдера.
- RPO / RTO: RPO ≤ 1 час (Enterprise) / 24 часа (Standard); RTO ≤ 4 часа.
- DR-тестирование: ежеквартальная проверка восстановления БД на staging. Последний прогон — 28 апреля 2026 г. (восстановление полного снапшота prod на staging-узел, время — 38 минут, целостность контрольных таблиц подтверждена); следующий запланирован на июль 2026 г. Отчёт предоставляется по запросу ИБ-службы клиента.
- SLA: 99.5% uptime для Standard, 99.9% для Enterprise (по договору).
18. Субпроцессоры (sub-processors)
В соответствии с принципами прозрачности и требованиями ст. 9 ФЗ-152 ниже приведён список ключевых субпроцессоров, привлекаемых для оказания услуг:
| Поставщик | Назначение | Сертификации | Юрисдикция |
|---|
| Timeweb Cloud | VPS РФ для application-узла, БД (учётные данные, аудит-журналы, эксплуатационные SEO-данные), reverse-proxy, хостинг сайта | 152-ФЗ УЗ-3, аттестация ЦОД ФСТЭК | РФ (Москва) |
| Yandex Cloud | Резервная площадка для РФ-БД (по запросу Enterprise); LLM YandexGPT; объектное хранилище для бэкапов | ФСТЭК, ФСБ, 152-ФЗ УЗ-1 | РФ |
| СберБанк (GigaChat) | LLM для генерации контента и ИИ-агентов | 152-ФЗ, ФСТЭК | РФ |
| ЮKassa (ООО НКО «ЮMoney») | Приём платежей, подписки, чеки 54-ФЗ через ОФД | ОПДн Банка России, 152-ФЗ, ПДСС РФ | РФ |
| СДЭК / Почта России | Доставка закрывающих бухгалтерских документов корпоративным клиентам по заключённым договорам | 152-ФЗ | РФ |
Актуальный полный список с указанием обрабатываемых категорий данных предоставляется по запросу при подписании DPA (Data Processing Agreement).
19. Подключение по API — что получает клиент
Когда корпоративный клиент (например, маркетплейс или e-commerce) подключает SEO AI Tools к своему сайту — происходит односторонний поток данных от нас к клиенту. Объём и характер передачи:
| Что мы передаём клиенту | Как | Содержит ли PII? |
|---|
| SEO-микроразметка (Schema.org JSON-LD: Product, Article, BreadcrumbList, FAQ) | Через API клиента или CMS-плагин | Нет — только данные о товарах/контенте |
| Мета-теги (title, description, canonical, Open Graph) | API клиента / CMS-плагин | Нет |
| Сгенерированный текстовый контент (карточки товаров, статьи блога) | API клиента / CMS-плагин | Только если клиент сам передал PII во входе |
| Результаты технического аудита (отчёт) | UI / API | Нет |
| Boost Widget (виджет на сайте) | JS-скрипт, загружаемый клиентом | Нет, телеметрия только агрегированная |
Что мы получаем от клиента: API-токен с ограниченной областью применения (только запись микроразметки/контента в нужный namespace), URL площадки. Мы не запрашиваем доступ к данным заказов, клиентским базам, платёжной информации.
Безопасность интеграции
- Передача токена клиента происходит при первичной настройке через личный кабинет; для Enterprise токен защищается envelope encryption (AES-256-GCM + KEK в KMS/Vault РФ-провайдера) по умолчанию, для Standard — AES-256 at rest на уровне БД РФ-провайдера (подробнее — подблок ниже и § 7).
- Все вызовы API клиента идут поверх HTTPS с проверкой сертификата.
- Клиент может в любой момент отозвать токен на своей стороне — интеграция остановится без побочных эффектов.
- Логи всех записей в CMS клиента доступны клиенту в UI с возможностью отката изменений.
- Для 1С-Битрикс / Тильда / InSales используются официальные API-подключения с минимальным набором scopes; для WordPress — наш плагин с опубликованным исходным кодом.
Шифрование API-токенов CMS — envelope encryption (стандарт Enterprise)
Шифрование API-токенов CMS клиента в Enterprise-интеграции — это стандарт, применяемый по умолчанию ко всем Enterprise-клиентам, а не опция «по запросу» и не функциональность из roadmap. Standard-тариф работает на уровне шифрования БД и TLS-канала.
- Envelope encryption по умолчанию: payload токена шифруется AES-256-GCM на уникальном data-encryption key (DEK); DEK шифруется мастер-ключом (KEK), который хранится в KMS/Vault РФ-провайдера и не покидает HSM/KMS-границу. Application-level шифрование токенов работает в production для Enterprise-сегмента.
- Ротация ключей: регулярная ротация DEK и плановая ротация KEK с перешифровкой всех существующих секретов без простоя интеграции.
- Мгновенный отзыв: Enterprise-клиент отзывает конкретный токен через UI или запрашивает аварийный rotate KEK через security-канал; следствие — все ранее зашифрованные токены становятся нечитаемыми в течение того же запроса.
- Audit: каждая операция доступа к KMS/Vault и дешифровки токена фиксируется в append-only audit-логе с userId, operation, timestamp.
- Standard-тариф (fallback): токены защищены AES-256 at rest на уровне БД РФ-провайдера + TLS 1.2+ при передаче с проверкой сертификата; envelope encryption поверх БД — часть Enterprise-DPA.
Шифрование тела ответа (payload), передаваемого клиенту
- Канал защищён TLS 1.2/1.3 с ECDHE и проверкой сертификата — конфиденциальность и целостность трафика обеспечены на транспортном уровне.
- HMAC-подпись запросов (HMAC-SHA256, поле
X-Signature) — по умолчанию для всех клиентских API-вызовов; защита от подмены и replay-атак на уровне приложения.
- Дополнительное application-level шифрование payload (AES-256-GCM, pre-shared key) — включается по DPA для Enterprise, если этого требуют внутренние стандарты клиента; передаваемые данные — микроразметка, мета-теги, контент — PII не содержат.
20. Enterprise marketplace integration
Сборный vendor-review-ready блок для ИБ-служб крупных маркетплейсов и e-commerce-площадок
Для Enterprise-клиентов в e-commerce (маркетплейсы, сети магазинов косметики, фармы, fashion) интеграция SEO AI Tools — контролируемый, scoped и ревизируемый процесс. Ключевые гарантии (продублированы в § 1):
К чему у нас категорически нет доступа
Scoped API-токен интеграции не имеет доступа к следующим коммерчески чувствительным сущностям клиентского CMS — ни на чтение, ни на запись:
- Заказы (orders, статусы, суммы, состав).
- Покупатели (customers, e-mail, телефоны, адреса, история покупок).
- Платежи (transactions, банковские реквизиты, чеки, возвраты).
- Цены (price lists, скидки, промокоды, акции).
- Остатки и склады (inventory, stock, отгрузки, поставки).
- Корзины (carts, незавершённые сессии покупателей).
- Личные кабинеты покупателей (account-данные, токены сессий).
Ограничение фиксируется одновременно на стороне клиента (scopes API-ключа CMS) и на стороне платформы (whitelist методов CMS-адаптера). Передаваемые данные — только SEO-namespace: микроразметка, мета-теги, SEO-поля карточек, статьи блога.
Контур РФ — default для российских Enterprise
- Приложение, БД, логи, бэкапы, KMS/Vault, очереди, AI-провайдеры, эксплуатационные SEO-данные — всё в юрисдикции РФ (см. §§ 12, 18). Это default-конфигурация, а не опция «по запросу».
- ИИ-вызовы выполняются российскими LLM-провайдерами — YandexGPT (Yandex Cloud) и GigaChat (СберБанк); приём платежей — через ЮKassa в РФ-юрисдикции.
- Локализация обработки и хранения ПДн граждан РФ на территории Российской Федерации реализована архитектурно (ст. 18 ч. 5 ФЗ-152 в ред. ФЗ-23 от 28.02.2025).
Scoped API-токен
- Токен интеграции выпускается клиентом и имеет область применения, ограниченную исключительно SEO-namespace: запись/обновление микроразметки, мета-тегов, SEO-полей карточек, статей блога. См. список «к чему у нас нет доступа» выше.
- Хранение токена — envelope encryption AES-256-GCM + KEK в KMS/Vault как стандарт Enterprise-интеграции (см. §§ 7, 19); мгновенный отзыв через UI либо на стороне клиента.
Workflow «draft → approve → publish» — без автопубликации
- AI-агент не публикует изменения в production CMS Enterprise-клиента напрямую. Двухступенчатый workflow: автономный AI-агент готовит изменения в статусе draft, ответственный сотрудник клиента просматривает diff и явно подтверждает approve, только после этого изменение уходит в CMS как publish.
- Автопубликация без ручного approve для Enterprise-сегмента отключена на уровне тарифа и DPA — лазейки в виде «авторежима» или «фонового агента, минующего approve» не предусмотрено.
- Любая публикация откатывается к предыдущему состоянию одним действием (rollback).
Audit log + rollback
- Каждое изменение, ушедшее в CMS клиента, фиксируется в
audit_log: userId, projectId, метод, URL, before/after diff, timestamp, идентификатор согласовавшего сотрудника клиента.
- Журнал доступен ИБ-службе клиента в UI и экспортом по API.
- Rollback к любому состоянию из журнала — одним действием без побочных эффектов.
Конкретные SLA, scopes, список разрешённых CMS-методов, формат audit-экспорта и конфигурация выделенной инсталляции согласовываются в индивидуальном DPA с ИБ-службой клиента.
22. Что мы НЕ собираем и НЕ обрабатываем
- Банковские реквизиты: номера карт, CVV, сроки действия — не касаются нашей инфраструктуры (всё через ЮKassa).
- Биометрические данные.
- Специальные категории ПДн (раса, политические взгляды, религия, здоровье, судимость) по ст. 10 ФЗ-152.
- Данные несовершеннолетних: сервис не предназначен для лиц младше 18 лет (см. Privacy Policy § 11).
- Полные клиентские базы клиента-заказчика: при интеграции мы не запрашиваем e-mail/телефоны конечных покупателей клиента.
- Данные заказов и транзакций клиента-заказчика.