Security posture & TOMs

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

Обновлено: 21 июля 2026

Безопасность — суть продукта, а не надстройка. Ниже — конкретные меры, которые мы применяем к самому TrustFlare и его инфраструктуре. Соответствие стандартам — на странице [ISO 27001 и инфраструктура](/legal/iso/).

Наш подход

Мы проектируем от угроз: минимум доверия по умолчанию, минимум собираемых данных, минимум поверхности атаки. Чувствительные решения (например, доверие к устройству) проверяются криптографически, а не по самоотчёту клиента.

Архитектура и поверхность атаки

  • Self-hosted-модель: факты об устройствах, решения о доступе и журналы остаются в контуре клиента — у нас нет к ним доступа по умолчанию.
  • Ядро (core-api) по умолчанию слушает loopback; наружу демо-стенд выходит только через access-gate и Cloudflare-туннель, порты на хост не публикуются.
  • Публичный сайт статический (Cloudflare Pages); динамика ограничена немногими serverless-функциями (форма заявки, DSAR, отчёт о безопасности) — нет SSH, ОС-патчинга и постоянных серверов приложений.

Жизненный цикл безопасной разработки (SDLC)

  • Spec-first: изменения контрактов и доменов фиксируются в спецификации до кода.
  • Обязательное код-ревью для auth/secrets-кода двумя ролями (code-reviewer + security-reviewer).
  • Строгие гейты качества: типизация (pyright --strict), линтеры (ruff, 20 групп правил), тесты (порог покрытия), документируемость.
  • Гигиена зависимостей и воспроизводимые сборки (uv.lock, фиксированные образы).

Технические меры (TOMs)

  • Шифрование в транзите: HTTPS/TLS для всего внешнего трафика (терминация на Cloudflare).
  • Подпись данных устройства: детач-подпись Ed25519 над каноникализацией RFC 8785 (JCS) — факты об устройстве нельзя подделать в пути.
  • Passkey с привязкой к устройству (WebAuthn): синхронизируемые в облако ключи отклоняются; user verification обязателен.
  • Одноразовые challenge и живой nonce (nonce = cid) против replay; секрет браузера (poll_token) не попадает в deep-link URL.
  • Подтверждение операций сравнением с постоянным временем (constant-time), лимит попыток, TTL и one-time-коды.
  • Rate-limiting на чувствительных эндпоинтах; секреты — в SOPS/Cloudflare secrets, не в git.
  • Изоляция контейнеров стенда: gVisor (runsc), non-root, read-only rootfs, cap_drop ALL, no-new-privileges.

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

  • Принцип минимальных привилегий и разделение доступа.
  • MFA на критических системах; ключи SOPS/age хранятся в Apple Secure Enclave, ключи для CI отделены от рабочих.
  • Отдельные окружения (prod/stage), отсутствие доступа третьих лиц к инфраструктуре по умолчанию.

Соответствие

Меры сопоставлены с контрольными целями ISO/IEC 27001; сводная матрица и позиция по сертификации — на странице ISO 27001 и инфраструктура. Соответствие GDPR — здесь, 152-ФЗ — здесь.

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

У нас есть процедура: обнаружение → локализация → устранение → уведомление → анализ. Уведомления регуляторов идут по двум таймлайнам:

  • Роскомнадзор (152-ФЗ): уведомление о факте инцидента — в течение 24 часов, о результатах внутреннего расследования — в течение 72 часов.
  • GDPR (ст. 33–34): уведомление надзорного органа в течение 72 часов, а субъектов — при высоком риске для их прав.

Сообщить

Сообщение о проблеме безопасности

Форма уходит напрямую команде TrustFlare. Ответим на указанный email в течение 3 рабочих дней.