Безопасность SEO AI Tools — соответствие ФЗ-152, ФЗ-242, ФЗ-266, GDPR, ISO/IEC 27001, OWASP
Security & Compliance Overview · v2.4

Безопасность платформы SEO AI Tools

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

ФЗ-152 (РФ) GDPR-aligned (EU 2016/679) ISO/IEC 27001 — принципы ISO/IEC 27017 / 27018 OWASP Top 10 (2021) OWASP API Security Top 10 NIST SP 800-53 — отдельные контроли PCI-DSS Level 1 (через Stripe) SOC 2 Type II — поставщики инфраструктуры

Содержание

1. Резюме для руководителя

SEO AI Tools — SaaS-платформа для SEO/GEO-оптимизации и генерации контента, построенная по принципам defense-in-depth: каждый уровень (сеть, приложение, данные, ИИ-слой) имеет независимые контроли. Платформа разработана с учётом требований enterprise-клиентов в e-commerce, фарме, финансах и YMYL-нишах.

  • Идентификация и аутентификация: bcrypt с 12 раундами соли, серверные сессии в PostgreSQL, блокировка после 10 неудачных попыток, прогрессивная задержка ответов, OAuth 2.0 (Google).
  • Шифрование: TLS 1.2+ для всего входящего трафика, HSTS, AES-256 at rest на уровне СУБД (Neon Postgres / Google Cloud SQL).
  • Изоляция клиентов: логическая мультитенантность с явной фильтрацией по userId на каждом запросе и дополнительными проверками checkProjectAccess в MCP-слое.
  • Платежи: данные банковских карт не проходят через нашу инфраструктуру — используется Stripe Checkout (PCI-DSS Level 1).
  • ИИ-слой: единый шлюз AI Gateway, серверная инжекция системных промптов, блокировка промпт-инъекций, маскирование ключей в логах.
  • Аудит: неизменяемый журнал действий (audit_log), журнал сессий (user_session_log), маскирование чувствительных полей в логах.
  • Реагирование: уведомление Роскомнадзора и затронутых лиц в сроки, установленные ст. 21 ФЗ-152.
Краткий вывод для ИБ-службы

Подключение по API к SEO AI Tools не требует передачи персональных данных конечных пользователей клиента, банковских реквизитов или секретов CMS со стороны клиента. Интеграция происходит через токен с ограниченной областью применения (scope) и возможностью мгновенного отзыва. Передаваемые данные (микроразметка, мета-теги, тексты страниц) — публичная или уже размещённая на сайте информация.

2. Соответствие стандартам и нормативным требованиям

РФ · ЕС · международные best practices

Стандарт / НормаСтатусПрименение
Федеральный закон № 152-ФЗ «О персональных данных»СоблюдаетсяСогласия, правовые основания обработки, права субъектов, Privacy Policy, политика обработки ПДн
Ст. 18 ч. 5 ФЗ-152 (закон о локализации, ФЗ-242 от 21.07.2014)Соблюдается архитектурноУчётные данные пользователей-граждан РФ (e-mail, имя, хеш пароля) и журналы аудита (audit_log, user_session_log) хранятся в БД на территории РФ; см. § 12
Ст. 12 ФЗ-152 (трансграничная передача, ред. ФЗ-266 от 14.07.2022)В процессе оформленияУведомление Роскомнадзора о ТГП обезличенных эксплуатационных данных в EU подаётся; до завершения процедуры передача осуществляется только при явном согласии субъекта
Ст. 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)Уведомление в процессе подачиУведомление об осуществлении обработки ПДн готовится к подаче; реквизиты оператора — см. § 21
Приказ ФСТЭК № 21 (защита ПДн в ИСПДн)Целевой уровень УЗ-3Реализованы организационные и технические меры: идентификация/аутентификация, контроль доступа, регистрация событий, антивирус, обнаружение вторжений на уровне субпроцессоров
Федеральный закон № 149-ФЗ «Об информации»СоблюдаетсяХранение логов, защита информации, порядок реагирования на запросы уполномоченных органов
Регламент EU 2016/679 (GDPR)AlignedПринципы lawfulness, minimization, retention, права субъектов — для клиентов из ЕС
ISO/IEC 27001:2022Принципы внедреныСМИБ, оценка рисков, контроль доступа, инциденты
ISO/IEC 27017 (cloud security)Через субпроцессоровAWS / GCP / Neon / Stripe сертифицированы
ISO/IEC 27018 (PII в облаке)Через субпроцессоровШифрование PII at rest, разделение обязанностей
OWASP Top 10 (2021)МитигированыA01-A10: SSDLC-практики, см. § 14
OWASP API Security Top 10 (2023)МитигированыBOLA, BFLA, broken auth, mass assignment, rate limiting
NIST SP 800-53 Rev. 5Отдельные контролиAC, AU, IA, SC, SI семейства
PCI-DSS Level 1Через StripeКарточные данные не касаются нашей инфраструктуры
SOC 2 Type IIЧерез инфраструктурных партнёровAWS, GCP, Neon, Stripe — ежегодные отчёты

Оператор персональных данных — ООО «Люмени», ИНН 121518775090, ОГРН 309121527900023. Подача уведомления в Реестр операторов ПДн Роскомнадзора (ст. 22 ФЗ-152) и уведомления о трансграничной передаче (ст. 12 ФЗ-152) осуществляется в рамках текущего регуляторного roadmap. Актуальный статус и регистрационные номера предоставляются по запросу ИБ-службы клиента.

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-лимитирует подозрительный трафик. Сертификаты — Let's Encrypt с автоматическим обновлением через 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 · NIST SP 800-63B

  • Хеширование паролей: 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: поддержка входа через Google (GOOGLE_CLIENT_ID / GOOGLE_CLIENT_SECRET). Токены провайдера не хранятся — используются только для первичной верификации e-mail.
  • Logout: уничтожение серверной сессии + очистка cookie. Возможен принудительный logout всех сессий пользователя (incident response).
  • MFA-готовность: архитектура поддерживает добавление TOTP/WebAuthn для корпоративных тарифов по запросу.

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.

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'и (Stripe, CMS) валидируются по HMAC-подписи с использованием секретов из окружения.

7. Шифрование данных

УровеньАлгоритм / ПротоколГде применяется
In transit (внешний)TLS 1.2 / 1.3, ECDHEВесь публичный HTTPS-трафик; HSTS включён
In transit (внутренний)TLS внутри VPC провайдеровСоединения app → БД, app → Stripe / OpenAI / Google
At rest (БД)AES-256Neon Postgres / Google Cloud SQL — по умолчанию
At rest (бэкапы)AES-256Снапшоты на уровне облачного провайдера
Паролиbcrypt, 12 раундовТаблица users, поле password_hash
СессииCryptographically random IDПодписан секретом сессии (HMAC-SHA256)
API-токены клиентов CMSХранятся как есть в зашифрованной БДДоступ только для владельца проекта; будет добавлено application-level шифрование (AES-256-GCM с KMS) для Enterprise-тарифов

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, БД, Stripe, OAuth) находятся в переменных окружения (process.env) и никогда не коммитятся в репозиторий. Файл .env исключён через .gitignore.
  • Маскирование в логах: функция maskApiKey заменяет середину ключа на ***, оставляя только первые и последние 4 символа. То же применяется в API-ответах.
  • Ротация: ключи провайдеров AI могут быть обновлены динамически через таблицу ai_tool_settings без перезапуска приложения. Сервисные аккаунты Google Vertex изолированы в файле ~/.vertex-credentials-gateway.json с правами 0600.
  • Доступ к production-секретам: ограничен ролью DevOps; передача — только через зашифрованные каналы.
  • Запрет утечек: CI-пайплайн проверяет добавляемые файлы на паттерны секретов (regex для AWS keys, OpenAI keys, Stripe keys).

10. Безопасность ИИ-слоя

OWASP Top 10 for LLM Applications (2025)

  • AI Gateway: единая точка вызова всех LLM-провайдеров (OpenAI, Anthropic, Google Vertex, YandexGPT, GigaChat). Прямые вызовы из кода запрещены архитектурно.
  • Серверная инжекция промптов: системные инструкции добавляются на стороне сервера и недоступны для модификации пользователем — это ключевая митигация LLM01 (Prompt Injection).
  • Контекст даты: buildDateContext() автоматически инжектируется в каждый системный промпт для предотвращения галлюцинаций об устаревших данных.
  • Логирование вызовов: каждый вызов AI пишется в ai_api_usage с токенами, latency, моделью и метаданными проекта — для аудита и контроля стоимости.
  • Output handling: ответы LLM, отображаемые в UI, проходят через React-эскейпинг. Markdown рендерится через библиотеку с sanitization (исключены <script>, onerror атрибуты).
  • Контроль чувствительной информации: в промпты не включаются хешированные пароли, токены сессий, банковские данные. PII попадает в промпты только в объёме, необходимом для задачи (имя автора статьи, e-mail контакта — по явному запросу пользователя).
  • Поставщики моделей: используем только провайдеров, заявляющих data-not-used-for-training по умолчанию для API-вызовов (OpenAI API, Anthropic API, Google Vertex). Для РФ-чувствительных данных — YandexGPT/GigaChat в РФ-юрисдикции.

11. Платежи и PCI-DSS

  • Stripe Checkout / Customer Portal: весь процесс ввода и хранения карточных данных происходит в инфраструктуре Stripe (PCI-DSS Level 1, ежегодный аудит). Наш сервер никогда не видит номер карты, CVV или срок действия.
  • Хранимые данные платежа: только customerId, subscriptionId и last4 цифры — значения, безопасные для хранения по PCI-DSS.
  • Webhook Stripe: все события валидируются по подписи stripe-signature с секретом, известным только серверу. Запросы без валидной подписи отклоняются.
  • Идемпотентность: события Stripe обрабатываются с учётом event.id для защиты от двойной обработки.
  • SCA / 3D-Secure: поддерживается автоматически на стороне Stripe (PSD2 compliance).

12. Хранение данных и юрисдикция (ст. 18 ч. 5 ФЗ-152)

Платформа разделяет данные по двум зонам хранения исходя из требований ФЗ-242 (закон о локализации) и принципа минимизации:

КатегорияГде хранитсяЮрисдикцияСрок хранения
Учётные данные пользователей (e-mail, имя, хеш пароля, роль, статус)PostgreSQL на площадке РФ-провайдера (Timeweb/Yandex Cloud, Москва)🇷🇺 РФСрок действия аккаунта + 12 месяцев, далее обезличивание
Журналы аутентификации и аудита (user_session_log, audit_log, IP, User-Agent)PostgreSQL на площадке РФ-провайдера🇷🇺 РФСессии — 180 дней; аудит — 3 года
Платёжные метаданные (customerId, subscriptionId, last4)Stripe (PCI-DSS L1) + ссылочная запись в БД РФ🇷🇺 РФ (ссылка) · 🇪🇺/🇺🇸 (Stripe)≥ 5 лет (бухучёт)
Эксплуатационные SEO-данные: URL и тексты страниц клиента, ключевые слова, кластеры, метрики позиций, AI-генерацииPostgreSQL на application-узле (DigitalOcean, Amsterdam)🇪🇺 EU (NL)Срок действия аккаунта; удаление по запросу — в течение 30 дней
Логи приложения (request/response, ошибки)Файлы на application-узле🇪🇺 EU (NL)30–90 дней
Бэкапы БДСнапшоты у соответствующего провайдера, AES-256, in-region (РФ-БД — только в РФ)По юрисдикции исходной БД30 дней rolling
Соблюдение ст. 18 ч. 5 ФЗ-152 (закон о локализации, ФЗ-242)

Все персональные данные граждан РФ — регистрационные сведения пользователей платформы (e-mail, имя, хеш пароля) и связанные с ними журналы — подлежат первичной записи, систематизации, накоплению, хранению, уточнению и извлечению в БД, физически расположенной на территории Российской Федерации. На application-узле в ЕС обрабатываются только обезличенные эксплуатационные данные о продвигаемых сайтах (URL, ключевые слова, технические метрики, контент страниц) — информация, которая является публичной (находится в открытом доступе на сайтах клиентов) и не относится к ПДн в смысле ст. 3 ФЗ-152.

Передача обезличенных эксплуатационных данных на узел в ЕС квалифицируется как трансграничная передача обезличенных данных и осуществляется в соответствии со ст. 12 ФЗ-152: уведомление в Роскомнадзор о ТГП готовится к подаче, до завершения процедуры основанием передачи служит явное согласие пользователя, фиксируемое при регистрации.

Для Enterprise-клиентов доступна опция «РФ-only»: все эксплуатационные данные клиента и его проектов хранятся исключительно в БД на территории РФ, без трансграничной передачи. Конфигурация согласовывается отдельным 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.
  • Целостность логов: логи централизованно собираются на стороне облачных провайдеров (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, обновление уязвимых пакетов в течение 7 дней для high/critical.
  • SAST: по запросу запускаются Semgrep / SonarQube для поиска паттернов небезопасного кода.
  • Secrets-scanning: pre-commit hook + CI-проверка на паттерны API-ключей.
  • Branch protection: запрещён прямой push в main; обязательные status-checks.
  • 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).
  • Зависимости приложения: Dependabot-style мониторинг; обновления тестируются в staging до production.
  • Penetration testing: внутренние тесты — ежеквартально; внешний pentest — по запросу Enterprise-клиента (за счёт клиента или совместно).
  • Responsible disclosure: сообщения об уязвимостях принимаются на security@12nemtsev.ru; первичный ответ — в течение 48 часов.

16. Реагирование на инциденты

ст. 21 ФЗ-152 · GDPR Art. 33-34 · ISO/IEC 27035

  • Детектирование: мониторинг логов на аномалии (всплески 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 часа), с технической детализацией для их собственных регуляторных уведомлений.
    • GDPR Art. 33–34 (для ЕС-клиентов) — уведомление supervisory authority в течение 72 часов.
  • 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.
  • SLA: 99.5% uptime для Standard, 99.9% для Enterprise (по договору).

18. Субпроцессоры (sub-processors)

В соответствии с принципами прозрачности GDPR/ФЗ-152 ниже приведён список ключевых субпроцессоров, привлекаемых для оказания услуг:

ПоставщикНазначениеСертификацииЮрисдикция
Timeweb CloudVPS РФ для БД учётных данных и аудит-журналов; reverse-proxy РФ-периметра; хостинг сайта152-ФЗ УЗ-3, аттестация ЦОД🇷🇺 РФ (Москва)
Yandex CloudРезервная площадка для РФ-БД (по запросу Enterprise); LLM YandexGPTФСТЭК, ФСБ, ISO 27001/17/18, 152-ФЗ🇷🇺 РФ
DigitalOceanApplication-узлы (обработка обезличенных SEO-данных)SOC 2 Type II, ISO 27001🇪🇺 EU (NL, Amsterdam)
Neon / Google Cloud SQLPostgreSQL для эксплуатационных SEO-данных (опционально, по тарифу)SOC 2 Type II, ISO 27001/17/18, PCI-DSS🇪🇺 EU / 🇺🇸 US (регион выбирается)
Google Cloud PlatformVertex AI (Gemini), Cloud LoggingISO 27001/17/18, SOC 2, PCI-DSS🇪🇺/🇺🇸 (регион выбирается)
StripeПлатежи и подпискиPCI-DSS Level 1, SOC 1/2, ISO 27001US, IE
OpenAIGPT-модели для ИИ-агентовSOC 2 Type IIUS
AnthropicClaude-моделиSOC 2 Type IIUS
Yandex (YandexGPT)LLM для РФ-задачФСТЭК, 152-ФЗРФ
SberCloud (GigaChat)LLM для РФ-задач152-ФЗ, ФСТЭКРФ
Bright DataSERP-парсинг публичной выдачиSOC 2, ISO 27001EU/US

Актуальный полный список с указанием обрабатываемых категорий данных предоставляется по запросу при подписании 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 площадки. Мы не запрашиваем доступ к данным заказов, клиентским базам, платёжной информации.

Безопасность интеграции
  • Передача токена клиента происходит при первичной настройке через личный кабинет; токен хранится в БД с шифрованием.
  • Все вызовы API клиента идут поверх HTTPS с проверкой сертификата.
  • Клиент может в любой момент отозвать токен на своей стороне — интеграция остановится без побочных эффектов.
  • Логи всех записей в CMS клиента доступны клиенту в UI с возможностью отката изменений.
  • Для Shopify используется официальное OAuth App-подключение с минимальным набором scopes; для WordPress — наш плагин с опубликованным исходным кодом и аудитом ИБ-контролей.

20. Что мы НЕ собираем и НЕ обрабатываем

  • Банковские реквизиты: номера карт, CVV, сроки действия — не касаются нашей инфраструктуры (всё через Stripe).
  • Биометрические данные.
  • Специальные категории ПДн (раса, политические взгляды, религия, здоровье, судимость) по ст. 10 ФЗ-152.
  • Данные несовершеннолетних: сервис не предназначен для лиц младше 18 лет (см. Privacy Policy § 11).
  • Полные клиентские базы клиента-заказчика: при интеграции мы не запрашиваем e-mail/телефоны конечных покупателей клиента.
  • Данные заказов и транзакций клиента-заказчика.

21. Контакты для службы информационной безопасности

Для официальных запросов от ИБ-служб корпоративных клиентов (DPA, security questionnaire, vendor risk assessment, отчёт о subprocessors, pentest coordination):

Юридические реквизиты оператора:
ООО «Люмени»
ИНН: 121518775090 · ОГРН: 309121527900023
Юр. адрес: 141707, Московская область, г. Долгопрудный, Старое Дмитровское шоссе, 17
Уведомление в Реестр операторов персональных данных Роскомнадзора (ст. 22 ФЗ-152) и уведомление о трансграничной передаче (ст. 12 ФЗ-152) — готовятся к подаче в рамках регуляторного roadmap. Регистрационные номера предоставляются по запросу ИБ-службы клиента после внесения в реестр.

Готовы предоставить дополнительную документацию

По запросу выдаём: DPA-договор, Security Questionnaire (CAIQ Lite / SIG Lite), архитектурную диаграмму, список субпроцессоров с DPA, отчёты pentest, согласование выделенной инсталляции.

Запросить документацию

Дата последнего обновления: 12 мая 2026 г. · Версия документа: 2.5 · Владелец документа: ООО «Люмени», направление безопасности продукта SEO AI Tools.
Документ предоставляется в информационных целях и не является публичной офертой. Конкретные условия по безопасности фиксируются в договоре и DPA с корпоративным клиентом.