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

Вы доверяете Slicer личные видео, голос и тексты. Эта страница подробно и без маркетинга описывает, как мы их защищаем: что зашифровано и чем, кто и при каких условиях может получить доступ, что происходит при входе, оплате и удалении аккаунта. Мы намеренно не публикуем детали, которые облегчили бы атаку, — имена ключей, внутренние адреса и пороги срабатывания защиты.

Нашли уязвимость? Напишите на security@slicer.media — как это сделать, описано в конце страницы, в разделе «Сообщить об уязвимости».

1. Принципы#

• Минимум данных. Мы собираем только то, без чего сервис не работает: материалы монтажа, email для входа, историю операций с токенами. Данные карт мы не получаем вовсе.
• Шифрование по умолчанию. Файлы пользователей и чувствительные поля базы данных хранятся только в зашифрованном виде. Копия диска, резервная копия или выгрузка базы без ключа сервера бесполезны.
• Доступ только владельца. Каждый запрос проверяет, что объект принадлежит вам. Чужой проект для вас не существует — даже его id ничего не даёт. Файл дополнительно сверяется с владельцем, записанным в его зашифрованном заголовке.
• Журнал на каждый доступ. Входы, выходы, удаления, действия администрации и любой доступ к данным пользователя записываются в журнал безопасности, который нельзя незаметно изменить.

От чего это защищает#

Честные ограничения#

• Сервер расшифровывает данные, пока работает. Монтаж, ИИ-анализ и отдача ролика вам требуют открытого содержимого. Шифрование защищает данные «в покое» — на дисках, в резервных копиях и выгрузках, — но не от того, кто полностью захватил работающий сервер. Поэтому ключи хранятся отдельно от данных, а доступ к серверам ограничен.
• ИИ-провайдеры получают фрагменты материалов — ровно столько, сколько нужно для монтажа (раздел 12). Сквозное шифрование «только у пользователя» при серверном ИИ-монтаже невозможно.
• Ваше устройство. Браузер может кэшировать ролики, приложение хранит токен входа в защищённом хранилище системы (Keychain). Защищайте устройство паролем.

2. Шифрование файлов#

Все файлы пользователей — исходники, свои фото, видео и музыка, готовые ролики, обложки, — а также рабочие каталоги проектов хранятся зашифрованными.

• Алгоритм — AES-256-GCM. Файл шифруется блоками, каждый блок подписан: номер блока и признак последнего блока входят в подпись, поэтому блоки нельзя переставить, а файл — незаметно обрезать или подменить. Перемотка видео расшифровывает только нужные блоки.
• Свой ключ у каждого файла. Ключ файла случайный (256 бит) и хранится в заголовке файла только в завёрнутом виде: мастер-ключом сервера и открытым ключом эскроу (раздел 4). Мастер-ключ хранится в секретах окружения сервера — не в коде, не в базе и не в хранилище файлов.
• Владелец в подписи. Заголовок файла содержит владельца и вид объекта, и они тоже подписаны. При отдаче файла сервер сверяет владельца: если в записи пользователя каким-то образом оказался ключ чужого файла, файл не будет отдан, а попытка попадёт в журнал.
• Ротация ключей перешифровывает только заголовки файлов, содержимое переписывать не нужно.

Где файл бывает расшифрован#

Рабочий каталог расшифровывается только под арендой задачи. Если процесс аварийно завершился, аренда истекает, а регулярная проверка находит брошенные каталоги и шифрует их снова. Файлы заменяются атомарно: читатель никогда не видит наполовину записанный файл.

3. Шифрование данных в базе#

Чувствительные поля базы данных зашифрованы отдельно, ключом, производным от мастер-ключа:

• личные данные — email, имя, логин, токены провайдеров входа;
• тексты и документы — названия проектов и файлов, документы монтажа, расшифровки речи, описания кадров, планы режиссёра, пожелания режиссёру, промпты ИИ-эффектов;
• устройства и журнал — IP-адреса и данные браузера сессий, детали записей журнала безопасности;
• соцсети — токены доступа платформ, имена аккаунтов, заголовки и описания публикаций;
• API — имена API-токенов, последние IP их использования, секреты подписи вебхуков;
• описания операций с токенами.

Служебные значения — id, статусы, размеры, длительности, суммы, настройки стиля — не зашифрованы: по ним работают поиск, сортировка и учёт. Поиск по зашифрованным полям (например, по названию проекта) выполняется в памяти сервера, а не в базе.

• Email ищется по слепому индексу — криптографическому хэшу с секретным ключом. По нему можно найти аккаунт при входе, но нельзя восстановить адрес.
• Пароли хранятся как хэш argon2id с параметрами не ниже рекомендаций OWASP, а сам хэш дополнительно зашифрован. Пароль не может совпадать с email и не должен быть из списка распространённых; требований «цифра и заглавная буква» нет — по рекомендациям NIST длина важнее.

4. Доступ администрации#

Иногда доступ к материалу действительно нужен — например, по обращению самого пользователя в поддержку или по законному требованию. Для этого есть единственный путь, и он устроен так, чтобы им нельзя было воспользоваться тайно.

• Эскроу-ключ. Ключ каждого файла дополнительно завёрнут открытым ключом RSA-OAEP (SHA-256, не короче 3072 бит). Закрытая часть этого ключа хранится офлайн у одного ответственного человека — супер-админа — на зашифрованных носителях и никогда не попадает на сервер.
• Сервер не расшифровывает файлы для администрации. Он отдаёт только шифротекст, расшифровка возможна лишь на компьютере супер-админа его закрытым ключом.
• Каждый доступ — с основанием. Чтобы получить шифротекст, супер-админ входит в админ-панель паролем и одноразовым кодом (TOTP), недавно подтверждает вход кодом ещё раз и указывает основание — номер обращения или запроса. Сначала пишется запись в журнал, потом выдаётся файл; без записи файла нет. Даже просмотр списка объектов пользователя записывается.
• Журнал нельзя переписать. Журнал безопасности только дополняется: изменение и удаление записей запрещены на уровне базы данных, а каждая запись содержит хэш предыдущей. Удалённая или изменённая запись разрывает цепочку, и проверка это показывает.
• Админ-панель — отдельное приложение на своём адресе, со своей сессией и строгой политикой безопасности содержимого. Обычная сессия пользователя в ней не действует, а изменяющие действия требуют свежего подтверждения кодом и пишутся в журнал.

5. Вход и сессии#

• Серверные сессии. Сессия хранится на сервере, токен в браузере или приложении — лишь её номер. Выход отзывает сессию сразу. В Профиль → Вход и безопасность видны все устройства; можно выйти на одном или на всех других. Сессия живёт до 30 дней и завершается после 14 дней без активности.
• Cookie в браузере — с префиксом __Host-, Secure, HttpOnly и SameSite=Strict: скрипты страницы её не видят, а другие сайты не могут её отправить.
• Защита от подделки запросов (CSRF). Изменяющий запрос с cookie принимается только с адресов приложений Slicer — по заголовку Origin. API принимает только JSON.
• Вход в приложении для iPhone, iPad и Mac идёт через системный браузер. Приложение получает одноразовый код, который живёт минуты и обменивается на сессию только вместе с секретом, выданным этому приложению в начале входа, — по принципу PKCE. Перехватив код, чужое приложение сессию не получит. Токен сессии хранится в защищённом хранилище системы.
• Email и пароль. Регистрация и восстановление пароля — с кодом из письма. Ответы на регистрацию и «Забыли пароль?» одинаковы для занятого и свободного адреса, а время ответа при входе выравнивается — по ним нельзя узнать, есть ли у человека аккаунт. Попытки входа и ввода кодов ограничены.
• Google, Apple, VK ID. Аккаунт провайдера привязывается к существующему аккаунту Slicer только по подтверждённому провайдером email. Неподтверждённый email не даёт доступа к чужому аккаунту.
• Подтверждение для важных действий. Смена email и пароля, удаление аккаунта, создание API-токена требуют недавнего входа — иначе Slicer попросит подтвердить, что это вы.

6. API и MCP#

• API-токены. Токен — 256 случайных бит с узнаваемым префиксом slc_ и контрольной суммой: сканеры утечек находят его в репозиториях, а сервер отсекает подделку ещё до поиска в базе. В базе хранится только HMAC токена — сам токен показывается один раз и восстановить его нельзя. У токена есть области доступа, срок и месячный лимит расходов; он отзывается в профиле мгновенно, а при удалении или блокировке аккаунта — автоматически. О создании токена приходит письмо.
• Только заголовок. Публичное API и MCP принимают токен только в заголовке Authorization и не принимают cookie — сайт, открытый в вашем браузере, не может действовать от вашего имени.
• OAuth 2.1 для ИИ-агентов. PKCE (S256) обязателен, токен привязан к ресурсу — MCP-серверу Slicer (RFC 8707), ответ авторизации содержит издателя (RFC 9207), что защищает от подмены сервера. Адреса возврата проверяются; опасные схемы запрещены. Код авторизации одноразовый и живёт 10 минут, токен доступа — час. Токены обновления меняются при каждом использовании, и повторное использование старого токена — как и повтор кода авторизации — отзывает всё подключение: так обнаруживается кража.
• Окно согласия показывает, какое приложение просит доступ, куда вернётся ответ, какие права и какой лимит расходов вы выдаёте. Приложения, зарегистрированные автоматически, помечены как непроверенные.
• Подтверждение цены. Ни одна платная операция API и MCP не тратит токены без явно подтверждённой цены, а лимит расходов не даёт превысить бюджет даже при ошибке в программе или в рассуждениях модели.
• Кадры для вашего ИИ-ассистента — только по запросу. Когда ассистент монтирует сам (Свой режиссёр), кадры исходников уходят в ИИ, который выбрали вы, — только по вашему токену с областью projects:read, только те, что ассистент запросил (до 16 за вызов, 512 точек), и только в ответе инструмента: ссылок на файлы при этом не появляется. Кадры извлекаются под той же защитой рабочего каталога, что рендер, и сразу удаляются.
• Правила режиссёра остаются на сервере. Ассистент получает только ваш материал — речь по словам, паузы, дубли, пожелания — и общие советы: правил и уроков ИИ-режиссёра Slicer нет ни в брифе, ни в промптах MCP, ни в ответах инструментов. Правила применяются к плану ассистента на сервере, а в ответ приходят исправления и замечания. По той же причине запись Задание режиссёру в «Чате» по умолчанию не показывается.
• План ассистента — данные. План ролика и наблюдения по кадрам от ассистента ничего не исполняют: Slicer проверяет их схемой, применяет к ним свои правила и только потом сохраняет ролик новой ревизией.
• Защита MCP от подмены адреса. Браузерные запросы к MCP-серверу принимаются только с доверенных источников — это защищает от атак через подмену DNS.
• Лимиты запросов считаются на токен и на подключение; идемпотентные ключи исключают двойные списания при повторах.

7. Вебхуки#

• Каждое событие подписано HMAC-SHA256 с меткой времени в заголовке Slicer-Signature. Получатель проверяет подпись и отклоняет запросы старше 5 минут — так перехваченное событие нельзя отправить повторно (как проверять).
• Секрет подписи показывается один раз и хранится зашифрованным.
• Адрес вебхука — только публичный https; он проверяется при создании и перед каждой отправкой, а перенаправления не выполняются — поэтому вебхук нельзя направить во внутреннюю сеть Slicer.
• В тело события не попадают секреты и токены — только те же данные, что отдаёт API владельцу.

8. Защита сервера#

• Запросы во внешний мир (SSRF). Когда сервер скачивает файл по ссылке — результат ИИ, импорт по адресу, загрузка в соцсеть, — он обращается только по https и только к публичным адресам, проверяя каждое перенаправление и ограничивая размер. Внутренние сети, адреса облачных метаданных и локальные адреса недоступны.
• Обработка видео без сети. Видеопроцессор запускается без командной оболочки, с таймаутом и с запретом сетевых протоколов; файлы пользователей открываются только по белому списку форматов для своего вида. Плейлисты и списки внутри «видео», которыми можно было бы прочитать файлы сервера, не открываются.
• Проверка загрузок — по расширению и по фактическому содержимому файла, с ограничениями размера, длительности и разрешения кадра. Имена файлов очищаются от путей, управляющих и невидимых символов. Квоты на загрузки защищают от переполнения диска.
• Лимиты запросов — по адресу и по токену, отдельно для входа, платных операций и загрузки.
• Заголовки безопасности: строгая политика содержимого (CSP), HSTS, Referrer-Policy: no-referrer, Cross-Origin-Resource-Policy, запрет кэширования ответов API с личными данными, таймауты медленных запросов.
• Проверка конфигурации при запуске. Сервер не стартует в рабочем режиме с небезопасными настройками: со слабыми или стандартными секретами, без ключей шифрования, с адресами без https.
• Ошибки без подробностей. Клиент получает понятный код и текст ошибки, но не внутренние сообщения, пути или ответы сторонних сервисов.

9. Ссылки без входа#

Файлы отдаются только владельцу — после входа или по токену API. Исключений три, все узкие и временные:

Публичных ссылок на скачивание готовых роликов нет.

Доступ ИИ к файлам проекта#

Обычно сервисы ИИ получают от Slicer нужные куски напрямую, без ссылок. Но некоторые модели берут файл только по адресу — сейчас это удаление объекта. Для них действуют правила:

• Только с разрешения. Без него файл не уходит: перед операцией Slicer показывает окно Доступ ИИ к файлу — Разрешить один раз, Разрешить для проекта или Не разрешать. Разрешение для проекта действует только в этом проекте и выключается в его Параметры; по умолчанию оно выключено.
• Только нужный кусок. У удаления объекта — кусок фрагмента до 5 секунд и маска объекта, каждый — отдельной ссылкой. Не весь исходник, не проект и не аккаунт.
• Ненадолго. Ссылка действует не дольше часа и отзывается сразу после ответа модели, копия куска удаляется. Ссылки, которые не удалось отозвать сразу (например, при перезапуске сервера), гасит регулярная уборка по сроку.
• Под шифрованием. Копия куска хранится зашифрованной, как все файлы пользователей, и отдаётся только по ссылке, без кэширования. Сама ссылка — 256 случайных бит; в журнал она не записывается.
• Журнал. Каждая выданная ссылка видна вам в Параметры проекта, в списке Выданные ссылки: для чего, что открыто (номер исходника и секунды куска, без текста и имён файлов), когда выдана, сколько раз её скачали и отозвана ли. Кнопка Отозвать все ссылки гасит действующие немедленно, выключение переключателя — тоже. Выдача и каждое скачивание записываются и в журнал сервера.

Подробно для пользователя — Доступ ИИ к файлам.

10. Платежи#

• Пакеты оплачиваются на странице ЮKassa — данные карты вводятся там, Slicer их не получает и не хранит.
• Токены зачисляются только после того, как сервер сам запросил статус платежа в API ЮKassa. Содержимому входящего уведомления мы не доверяем: оно лишь повод проверить.
• Ответ ЮKassa сверяется с нашей записью: номер платежа, сумма и связь с покупкой. Расхождение не зачисляется и записывается в журнал.
• Зачисление идемпотентно: повторное уведомление или проверка не начислят токены дважды. Неподтверждённые платежи регулярно сверяются с ЮKassa.
• Все движения токенов — записи, которые только добавляются; баланс вычисляется из них, а не правится вручную.

11. Хранение и удаление#

Удаление аккаунта (Профиль → Вход и безопасность) необратимо: отзываются все сессии, API-токены и подключённые приложения, останавливаются идущие операции, удаляются проекты, файлы и шаблоны, отзывается доступ входа через Apple, а запись пользователя обезличивается — email, имя, пароль и коды стираются.

Что остаётся после удаления:

• обезличенные платежи и операции с токенами — их требует бухгалтерский учёт;
• журнал безопасности — он только дополняется, а детали записей зашифрованы;
• метка «бесплатный ролик использован» — в виде слепого индекса email, по которому адрес восстановить нельзя. Она нужна, чтобы бесплатный первый ролик нельзя было получать повторно, пересоздавая аккаунт.

12. ИИ-провайдеры#

Монтаж выполняют ИИ-модели внешних провайдеров. Каждый получает только то, что нужно для своей задачи:

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

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

Если вы нашли уязвимость в Slicer — в приложениях, API, MCP-сервере или на сайтах, — напишите на security@slicer.media. Контакты для исследователей также опубликованы в файле /.well-known/security.txt.

Что указать в письме:

• где уязвимость: адрес, эндпоинт, экран или версию приложения;
• шаги воспроизведения и что удалось получить;
• как с вами связаться для уточнений.

Просим исследователей:

• проверять только на своих аккаунтах и данных, не обращаться к чужим данным и не изменять их;
• не нагружать сервис (никаких DoS и массового перебора) и не использовать социальную инженерию против пользователей и команды;
• не раскрывать уязвимость публично, пока мы её не исправим.

Мы подтвердим получение письма, будем сообщать о ходе исправления и с вашего согласия упомянем вас в благодарностях.

Что дальше#