Безопасность и защита данных

Самое ценное в TEASE — это ваши данные фанов (переписки, портреты, заметки операторов) и живой доступ к вашему аккаунту. Именно к этому мы относимся как к «драгоценностям» и вокруг этого выстраиваем защиту слоями: шифрование на диске, строгую изоляцию между клиентами, вход, который нельзя обойти, и проверку каждого действия на сервере. На этой странице — честно и без «воды»: что защищено, в каком состоянии и что это даёт вам на практике. По любым вопросам безопасности пишите на security@tease.link.

Ваши данные зашифрованы

Чувствительные вещи хранятся на диске в зашифрованном виде сильным современным шифрованием — украденная копия базы или бэкапа не отдаёт их в открытом виде.

• Учётные данные, ключи интеграций и секреты прокси зашифрованы на диске.
• Самые чувствительные данные фанов из переписок — психологические портреты, заметки операторов, превью сообщений — тоже зашифрованы на диске. Утёкшая база или бэкап не раскроют эти тексты.
• Секрет двухфакторной аутентификации зашифрован на диске: по слитой копии базы нельзя восстановить материал, из которого генерируются ваши одноразовые коды, и обойти 2FA.
• Мастер-ключ можно вынести в облачный сервис управления ключами: тогда украденная база, бэкап или снимок диска бесполезны без отдельного, аудируемого доступа — а любая попытка массовой расшифровки фиксируется.
• Шифрование прозрачно: оно защищает вас, никак не меняя того, как продукт работает изо дня в день.
• В нашем коде и в отслеживаемой документации нет ни одного секретного значения — и мы это проверяем.

Каждый воркспейс изолирован

Данные одного клиента никогда не видны другому: запрос к чужой записи просто «не находит» её.

• Изоляция держится и для аналитики — суммы, счётчики и графики посчитаны в границах вашего воркспейса, а не только отдельные записи.
• Это подтверждено повторными адверсариальными аудитами (внутренними ред-тимами) и покрыто автоматическими регресс-тестами — не просто заявлено.
• Единственная межклиентская утечка, найденная во время внутреннего ред-тима, была закрыта и «забетонирована» тестами до того, как могла попасть в прод.
• Действия уровня владельца платформы («god-mode») доступны только владельцу платформы — клиент или тиммейт не может до них дорасти.

Вход нельзя обойти или подобрать

• Пароли хранятся в виде хеша современным алгоритмом; доступна двухфакторка (приложение-аутентификатор) с одноразовыми резервными кодами.
• Можно входить по ключу входа (passkey) — отпечаток / Face ID / аппаратный ключ вместо пароля. Приватный ключ не покидает ваше устройство, привязан к нашему домену и его нельзя ни выудить фишингом, ни украсть из базы.
• Подбор пароля не работает: после серии неверных попыток аккаунт временно запирается, замок переживает перезапуск сервиса, и владелец получает сигнал.
• Подбор второго фактора тоже не работает: неверные коды запирают второй фактор сразу на всех дверях (и вход, и каждое повторное подтверждение).
• Одноразовый код — строго одноразовый: перехваченный шестизначный код нельзя переиграть даже в его короткое окно действия, а резервный код нельзя потратить дважды даже при гонке запросов.
• Нельзя выведать, существует ли аккаунт, по времени ответа: вход и регистрация с известным и с неизвестным адресом занимают одинаковое время.
• «Двери в обход входа» закрыты: для аккаунта с 2FA сброс пароля, смена почты, выпуск API-ключа и вход через Telegram требуют второй фактор — а не только доступ к почте или сессии.

Вы управляете сессиями

• Вы видите свои активные сессии (устройство, страна, сеть, когда) и можете завершить любую одну — например, забытую или украденную — не выходя из остальных. Есть и «выйти на всех устройствах».
• Давно неактивная сессия может погаснуть сама (таймаут простоя), и есть глобальный «стоп-кран».
• Сессию можно привязать к ключу устройства, который никогда его не покидает — тогда кука, скопированная на чужой компьютер, быстро умирает и её нельзя продлить.
• Опасные действия требуют свежего подтверждения: удаление аккаунта просит пароль (и код 2FA), а катастрофические действия владельца платформы (удаление клиента, вход под клиентом, сброс его 2FA) переспрашивают пароль — угнанная или забытая сессия не наделает необратимого.
• Смена пароля выкидывает украденные «соседние» куки.

Least-privilege доступ команды

• Доступ команды гранулярный: тиммейты получают права по разделам (просмотр/редактирование), а не «всё или ничего».
• Тиммейт с правами на изменение или экспорт обязан включить двухфакторку, прежде чем сможет что-либо менять или выгружать — до этого он работает в режиме «только просмотр» (собственная страница включения 2FA при этом никогда не блокируется, так что запереть себя нельзя).
• Массовая выгрузка данных (все фаны, переписки, вольт) поставлена под второй фактор плюс суточную квоту плюс запись в защищённый от подделки аудит — тихо выкачать всю базу из одной сессии больше нельзя.
• Дорогие ИИ-функции и машинный доступ ограничены по частоте на пользователя — тиммейт не сможет гонять их в цикле и жечь бюджет ИИ/API.
• Руководитель никогда не может выдать права выше своих.

Клиентская сводка — что тиммейт может и чего не может (без порогов и внутренних чисел):

Подробнее о ролях и вкладках — в гайде Доступ команды.

Каждое действие проверяется на сервере

• Права проверяются на сервере на каждый запрос данных, а не только прячутся в интерфейсе — именно этот класс атак (когда «дёргают» внутренний API в обход экрана) он и закрывает.
• Платёжные и сторонние вебхуки проверяются криптографически и закрыты по умолчанию — ошибка настройки никогда не «принимает всё», а повторно присланный платёж не может списаться дважды.
• Типовые веб-атаки закрыты: нет внедрения SQL/команд, нет открытых редиректов, нет обхода путей; загрузки картинок защищены от «бомб» распаковки; XML разбирается безопасно.
• Когда наш сервер идёт по адресу, который задал клиент (проверка кастомного домена, почтовый хост), его нельзя увести на внутренний адрес сети или на облачную метадату (защита от SSRF).
• Подписи графиков и названия источников/доменов выводятся как текст, поэтому вредный код в названии не исполнится в дашборде владельца (нет stored-XSS).
• Панель управления объявляет браузеру строгую политику загрузки и изолирована от окна, которое её открыло; ответы об ошибке никогда не отражают присланный пароль/код обратно и не «роняют» стек-трейс.

Мы замечаем злоупотребления и быстро запираемся

• Мы сигналим об аномальном объёме чтения на клиента (когда кто-то массово скачивает фанов или переписки) — ровно тот сигнал, которого не было у взломанных конкурентов.
• Угон живой сессии отслеживается не только на входе: если действующая сессия вдруг приходит из другой страны, сети или браузера — это фиксируется, а владелец получает оповещение.
• Встроен детектор аномального входа (нетипичная гео-скорость, смена сети).
• Есть анти-инсайдерские ловушки («honeytoken»), которые сигналят владельцу, если кто-то трогает хранилище секретов.
• Аудит-журнал защищён от подделки задним числом — записи сцеплены и подписаны, историю нельзя переписать, а «голова» цепочки ежедневно публикуется владельцу как внешний якорь.
• Ручки, которые шлют письма/уведомления или запускают тяжёлую работу, ограничены по частоте — их нельзя превратить в «почтовую бомбу», перебор промокодов или рычаг исчерпания ресурсов.

Кастомные домены — доказанные, а не просто направленные

• Подключить внешний домен теперь можно, только доказав владение им (публикация секретной DNS-записи) — простого «домен указывает на нас» недостаточно.
• Обслуживаются только подтверждённые домены: неподтверждённый или «захваченный» хост не отдаёт контент.
• При удалении домена связанные записи убираются, чтобы не осталось «висячих», которые кто-то мог бы перехватить.

Крепкий периметр

• Весь трафик идёт через Cloudflare: файрвол веб-приложений (управляемые правила + OWASP), защита от ботов, анти-DDoS, лимиты частоты на вход и блокировка утёкших паролей.
• Сервер-источник принимает только трафик Cloudflare.
• Доступ по SSH — только по ключу (пароли отключены).
• Соединение с посетителями зашифровано; ужесточение канала до источника (взаимный TLS) и сокрытие IP источника — в планах.

Приватность, минимизация и удаление по запросу

• Мы минимизируем то, что храним: IP-адреса хранятся огрублённо (подсеть, а не точный адрес), а гео — как центр региона, а не точная точка.
• Вы можете запросить удаление своих данных — с реальной очисткой (стирание плюс сжатие хранилища) и сроком хранения.
• Зашифрованные инкрементальные бэкапы в объектное хранилище готовы; проверка восстановления и защита от перезаписи (иммутабельность) — в планах.

Как мы держим планку

• Версии зависимостей зафиксированы, у фронтенда — контроль целостности сборки.
• Безопасность пересматривается непрерывно: несколько раундов адверсариальных аудитов (внутренних ред-тимов) с выкаченными фиксами и покрытием тестами.
• Мы соответствуем практикам признанных стандартов информационной безопасности; формальных сертификатов (SOC 2 / ISO 27001) у нас пока нет — мы описываем суть, а не значок.
• В планах: авто-сканеры уязвимостей в сборочном конвейере (CI), публичный контакт безопасности / политика раскрытия уязвимостей (VDP) и внешний пентест после ужесточения периметра.

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

Нашли слабое место? Мы будем благодарны за ответственное раскрытие. Напишите на security@tease.link — по возможности с шагами воспроизведения и без публичной огласки, пока мы не выпустим исправление.

Частые вопросы

---

Последний пересмотр: 2026-07-18. · См. также Надёжность и доставляемость. Детальные разборы уязвимостей мы намеренно держим приватно — так безопаснее для всех клиентов.