Кратко
SealTask шифрует читаемое содержимое рабочего пространства на вашем устройстве с помощью ChaCha20-Poly1305 до синхронизации. У сервиса нет ключей для расшифровки этого содержимого, но он продолжает обрабатывать метаданные аккаунта, биллинга, безопасности, аудита, сервиса и рабочего пространства. Сохранённый вами резервный ключ может один раз восстановить доступ после утраты пароля. Такая архитектура способствует минимизации данных; для регулируемого использования всё равно нужны соответствующие соглашения и меры контроля.
Термин безопасности должен описывать границу, а не украшать заявление.
Термины со страниц SealTask о безопасности, руководствах, сравнениях и инцидентах. Понятия с полным объяснением ведут на каноническую страницу.
Открыть весь центр знанийНаш базовый принцип.
Читаемое содержимое рабочего пространства шифруется на вашем устройстве до отправки на наши серверы. SealTask спроектирован так, чтобы компания не могла расшифровать открытый текст задач, заметок, комментариев, чек-листов, названий списков и вложений. Сервис продолжает обрабатывать перечисленные ниже метаданные. Эту границу защиты содержимого мы называем zero-knowledge.
Чем SealTask отличается.
Обычные таск-менеджеры.
Как работают конкуренты
- • Хранят данные в открытом виде на своих серверах
- • Могут читать каждую задачу, комментарий и файл
- • Могут сканировать содержимое для рекламы, обучения ИИ или «функций»
- • Взлом или санкционированный доступ может раскрыть читаемое содержимое и метаданные
SealTask (zero-knowledge).
Как работаем мы
- • Шифрует на вашем устройстве до отправки на серверы
- • Мы не можем расшифровать ваши задачи, даже если бы хотели
- • Никакого сканирования, никакого обучения ИИ на вашей частной работе
- • Взлом базы может раскрыть шифротекст и метаданные, но не читаемое содержимое без клиентских ключей
Как работает zero-knowledge шифрование.
Вы создаёте аккаунт.
При регистрации пароль никогда не покидает браузер в открытом виде. Вместо этого:
- Мы используем протокол OPAQUE PAKE, поэтому серверы никогда не видят пароль в открытом виде
- После успешной регистрации или входа OPAQUE выдаёт браузеру секретный export key, который мы никогда не получаем
- На устройстве генерируется случайный 32-байтный «ключ данных»
- Этот ключ данных локально шифруется обёрточным ключом, полученным из OPAQUE export key
- Зашифрованный ключ данных хранится на наших серверах — но без клиентского материала разблокировки мы его не расшифруем
- Вы можете скачать одноразовый резервный ключ. Он оборачивает тот же ключ данных в браузере, а мы храним только зашифрованную обёртку восстановления
Главное: ключ разблокировки и ключ данных обрабатываются в браузере. Мы храним только зашифрованные обёртки, а не пароли или ключи workspace в открытом виде.
Зачем тогда хранить зашифрованный ключ данных?
Чтобы вы могли входить с любого устройства. Когда вы пересаживаетесь на другой компьютер или открываете телефон, мы отправляем зашифрованный блок, браузер локально разблокирует его после безопасного входа — и вы внутри. Без такого хранения пришлось бы вручную копировать 32-байтный ключ между устройствами — ужасный UX при той же безопасности.
Вы создаёте рабочий список или задачу.
Читаемое содержимое шифруется на вашем устройстве; операционные метаданные остаются видимыми серверу:
- Названия и описания рабочих списков
- Названия задач, содержимое, чек-листы и комментарии
- Содержимое шаблона повторяющейся задачи зашифровано; cron-расписание, часовой пояс, активное состояние, номер итерации и время материализации остаются видимыми серверу
- Всё шифруется с помощью ChaCha20-Poly1305 AEAD (современный, проверенный шифр)
- У каждого рабочего списка собственный ключ шифрования, выводимый из вашего ключа данных
Сервер хранит зашифрованные данные рабочего пространства и раскрытые операционные метаданные; без клиентских ключей он не может прочитать зашифрованный открытый текст.
Вы приглашаете участников.
При совместной работе над рабочими списками:
- Каждый участник получает свою зашифрованную копию ключа списка
- Ключи обмениваются через HPKE (Hybrid Public Key Encryption)
- Открытые ключи приглашений записываются в журнал прозрачности Merkle. Ранее доверенная контрольная точка может выявить расхождение при проверке, но текущий клиент не остаётся в состоянии fail-closed и не сохраняет это обнаружение: он может отбросить точку и повторить проверку от начала
- Удаление участника отзывает его доступ к списку, авторизованный сервером. Сервер, зафиксировавший изменение, после коммита сигнализирует своим активным потокам; изменения с другого сервера, массовые и иные несигнализированные изменения проверяются повторно не позднее чем через 30 секунд. Уже доставленные или буферизованные транспортом данные отозвать нельзя. Текущая версия не выполняет автоматическую ротацию ключа списка, не перешифровывает список и не удаляет содержимое или ключи, полученные во время разрешённого доступа. Для новой криптографической границы создайте новый список только для текущих участников.
Сервер проверяет согласованность HMAC без расшифровки данных.
Доступ авторизуют состояние сессии и активного членства в базе. Отдельно браузер выводит из ключа списка с помощью HKDF и фиксированной протокольной константы ключ привязки данных для этого списка; тот же ключ копируется для каждого членства и хранится сервером.
Сервер использует этот ключ для проверки HMAC над шифротекстом. Доказательство показывает только соответствие HMAC байтам шифротекста без их расшифровки.
- Браузер выводит ключ привязки для списка из ключа списка с помощью HKDF; это не ключ расшифровки содержимого рабочего пространства
- До авторизации запроса сервер проверяет аутентифицированную сессию и активное членство
- Сервер хранит скопированный ключ привязки и может проверять или вычислять совпадающие HMAC над шифротекстом
- HMAC не доказывает свежесть, не предотвращает повтор, не привязывает данные к сущности или участнику и не подтверждает подлинность перед сервером
Что серверы (не) видят.
Мы НЕ видим
- × Читаемые названия задач
- × Читаемые тексты задач и заметок
- × Читаемое содержимое шаблонов повторяющихся задач
- × Читаемые тексты комментариев
- × Читаемое содержимое чек-листов
- × Читаемые названия и описания списков
- × Открытый текст вложений
- × Пароли аккаунтов в открытом виде
- × Ключи расшифровки содержимого рабочего пространства
Примеры видимых метаданных рабочего пространства (неполный список)
- ✓ E-mail аккаунта (для входа)
- ✓ Связи участников (кто в каком списке)
- ✓ Статус задачи (открыта/закрыта) и приоритет
- ✓ Сроки и временные метки
- ✓ Назначения делегирования (только ID пользователей)
- ✓ Метаданные для запросов (ID, даты создания)
- ✓ Соли и доказательства для каждого членства, а также хранимый сервером ключ привязки данных для списка, которым сервер проверяет или вычисляет совпадающие HMAC; это не ключ расшифровки содержимого рабочего пространства
- ✓ Расписание повторений, часовой пояс, активное состояние, итерация и время материализации
- ✓ Связи вложений, идентификаторы хранилища, размер шифротекста, состояние и временные метки
- ✓ Типы событий реального времени, идентификаторы участников и сущностей, названия изменённых полей, временные метки и число пропущенных событий
Объём и чувствительность: Показанный список содержит неисчерпывающие примеры видимых серверу метаданных рабочего пространства; это не полный перечень текущих моделей хранения, ответов API или событий SSE. Это также не полный реестр персональных данных: аутентификация аккаунта, биллинг, безопасность и аудит, предотвращение злоупотреблений и телеметрия сервиса — отдельные области, описанные в политике конфиденциальности неисчерпывающим образом. Метаданные сами по себе могут быть чувствительными. Размер шифротекста вложения обычно приблизительно раскрывает размер исходного файла.
Гарантии безопасности.
Разблокировка с аутентификацией по паролю (только на клиенте).
Пароль никогда не покидает устройство в открытом виде. Успешная аутентификация OPAQUE даёт браузеру export key, который локально разворачивает ключ данных. Затем HKDF выводит из него отдельные ключи для каждого рабочего списка.
Сервер не может расшифровать зашифрованные данные рабочего пространства.
Backend не расшифровывает зашифрованные данные рабочего пространства. Запросы авторизуют проверки сессии и членства в базе. Хранимый ключ привязки для списка позволяет серверу проверить или вычислить HMAC, совпадающий с шифротекстом; это доказывает согласованность шифротекста, но не свежесть, защиту от повтора, привязку к сущности или участнику и не подлинность перед сервером.
Отзыв доступа ограничен и не действует задним числом.
Удаление участника отзывает его доступ к списку, авторизованный сервером. Сервер, зафиксировавший изменение, после коммита сигнализирует своим активным потокам; изменения с другого сервера, массовые и иные несигнализированные изменения проверяются повторно не позднее чем через 30 секунд. Уже доставленные или буферизованные транспортом данные отозвать нельзя. Текущая версия не выполняет автоматическую ротацию ключа списка, не перешифровывает список и не удаляет содержимое или ключи, полученные во время разрешённого доступа. Для новой криптографической границы создайте новый список только для текущих участников.
Прозрачность ключей приглашений.
Открытые ключи приглашений записываются в Merkle-дерево с добавлением записей. Ранее доверенная контрольная точка может выявить расхождение, но текущий клиент может отбросить её и повторить проверку от начала; эта попытка и первое использование остаются границами доверия, а не безусловной гарантией непрерывности.
Резервные ключи остаются zero-knowledge.
Резервный ключ создаётся в браузере, и сохранить его должны вы. Он создаёт отдельную зашифрованную обёртку для того же ключа данных; мы храним только recovery credential file и зашифрованную обёртку, поэтому без сохранённого ключа не можем сбросить пароль или прочитать данные.
Open-source криптография.
Мы используем проверенные библиотеки: strong-box (ChaCha20-Poly1305), OPAQUE (аутентификация по паролю), HKDF (вывод ключей), Argon2id (password hardening OPAQUE и legacy-миграция) и HPKE (обмен ключами). Весь криптографический код открыт и поддаётся аудиту.
Как мы проверяем нашу безопасность.
Наши заявления о безопасности проверяемы, а не просто маркетинг. Так мы убеждаемся, что zero-knowledge архитектура работает как обещано:
- Open-source криптокод на GitHub для публичного аудита исследователями безопасности
- Проверенные библиотеки: ChaCha20-Poly1305 (RFC 8439), Argon2id, OPAQUE PAKE (RFC 9807) и HPKE
- Хранимый сервером ключ привязки для списка позволяет проверить или вычислить HMAC, совпадающий с шифротекстом; доступ авторизуют проверки сессии и членства в базе, а HMAC не доказывает свежесть, защиту от повтора, привязку к сущности или участнику и не подлинность перед сервером
- Доказательства Merkle могут показать расхождение относительно доверенной контрольной точки, но текущий клиент может отбросить её и повторить проверку от начала
- Клиентская разблокировка из OPAQUE export keys гарантирует, что мы не видим ни пароль, ни ключи шифрования
- Одноразовые резервные ключи создаёт и хранит пользователь, а не SealTask
Компромиссы zero-knowledge.
Резервный ключ может восстановить доступ при потере пароля.
Сохраните резервный ключ один раз и держите его в закрытом месте. Если вы потеряете пароль, этот ключ позволит сбросить его и сохранить доступ к зашифрованным данным. Поскольку SealTask не хранит копию, аккаунты без сохранённого резервного ключа остаются невосстановимыми.
Нет серверного поиска.
Поскольку содержимое задач зашифровано, мы не можем предложить серверный полнотекстовый поиск по всем задачам. Поиск выполняется в браузере после расшифровки.
Снижение риска: мы оптимизируем клиентский поиск индексированными запросами и быстрой расшифровкой, чтобы он оставался быстрым.
Технические характеристики.
| Симметричное шифрование | ChaCha20-Poly1305 AEAD (через библиотеку strong-box) |
| Разблокировка ключа данных | OPAQUE export key + HKDF-SHA256 — выводит локальные обёрточные ключи для зашифрованного ключа данных |
| Иерархия ключей | HKDF-SHA256 — выводит ключи списков и членств из ключа данных |
| Аутентификация по паролю | OPAQUE PAKE (кривая Ristretto255) |
| Двухфакторная аутентификация | TOTP из приложения-аутентификатора (RFC 6238) с одноразовыми резервными кодами; включается по желанию для аккаунта |
| Резервные ключи | Один активный одноразовый резервный ключ на пользователя; создаётся на клиенте и хранится у пользователя |
| Обмен ключами (приглашения) | HPKE (Hybrid Public Key Encryption) с X25519 |
| Проверки согласованности данных | HMAC-SHA256 |
| Сериализация | CBOR (Concise Binary Object Representation) |
| Размер ключа | 256 бит (32 байта) для всех симметричных ключей |
Все криптографические операции выполняются в браузере через WebCrypto API и аудированные WASM-модули, скомпилированные из Rust.
Аудиты и прозрачность.
Open-source криптостек.
Вся наша криптографическая реализация открыта и доступна на GitHub. Мы приглашаем исследователей безопасности проводить аудит нашего кода.
Открыть на GitHubСоответствие.
Архитектура zero-knowledge поддерживает минимизацию данных по GDPR и может помочь с техническими мерами защиты. До любого использования PHI SealTask должен дать прямое письменное согласие. Если применяется HIPAA, стороны до начала использования обязаны заключить BAA, соответствующее HIPAA. Шифрование — лишь одна мера; программа соответствия должна обеспечить необходимые операционные контроли и оценку поставщика.
Частые вопросы.
Что будет, если вас взломают?
Злоумышленник с доступом к базе может получить шифротекст, а также метаданные аккаунта, маршрутизации, аудита и рабочего пространства. Сохранённое содержимое нельзя прочитать без клиентских ключей расшифровки; защита также зависит от криптографии, клиентов и обращения с ключами.
Могут ли власти заставить вас расшифровать мои данные?
Законное требование может обязать нас предоставить шифротекст и видимые серверу метаданные аккаунта, биллинга, безопасности, аудита, сервиса и рабочего пространства. У нас нет ключей, необходимых для расшифровки читаемого содержимого.
Что если я забуду пароль?
Если вы сохранили резервный ключ, его можно один раз использовать для сброса пароля и сохранения доступа к зашифрованным данным. Если резервный ключ не сохранён, SealTask не сможет восстановить данные за вас.
Чем это отличается от «шифрования при хранении»?
«Шифрование при хранении» означает, что данные шифруются на дисках сервера, но у сервера есть ключи для расшифровки. Сквозное шифрование — это когда ключи есть только у вас (у конечных точек), а сервер никогда не имеет доступа к открытому тексту.
Могут ли сотрудники SealTask видеть мои данные?
Сотрудники SealTask и администраторы базы не имеют клиентских ключей для расшифровки данных рабочего пространства. Авторизованные системы и сотрудники всё же могут обращаться к видимым серверу метаданным, описанным на этой странице.
Что если я хочу экспортировать данные?
Вы можете в любой момент экспортировать расшифрованные данные из приложения. Расшифровка происходит в браузере, поэтому вы получите читаемые файлы JSON/CSV, а не зашифрованные блоки.
Поддерживает ли SealTask двухфакторную аутентификацию?
Да. В настройках безопасности можно включить двухфакторную аутентификацию через приложение-аутентификатор (RFC 6238 TOTP) и сохранить одноразовые резервные коды. Для входа тогда нужны пароль и актуальный код. Это защищает вход в аккаунт и действует отдельно от клиентского шифрования, которое защищает содержимое рабочего пространства.
Источники и стандарты.
Наши криптографические решения опираются на индустриальные стандарты и рецензируемые спецификации.
- 01 RFC 8439: ChaCha20 and Poly1305 for IETF Protocols — Наш стандарт симметричного шифрования
- 02 RFC 9807: The OPAQUE Augmented PAKE Protocol — Аутентификация по паролю zero-knowledge
- 03 RFC 9180: Hybrid Public Key Encryption (HPKE) — Обмен ключами для приглашений в команды
- 04 RFC 9106: Argon2 Memory-Hard Function — Вывод ключа на основе пароля
- 05 NIST SP 800-175B: Guideline for Using Cryptographic Standards — Федеральные криптографические рекомендации
- 06 GDPR Article 32: Security of Processing — Требования ЕС к защите данных
- 07 RFC 6238 — TOTP — Двухфакторная аутентификация
Готовы к настоящей приватности?
Присоединяйтесь к командам, которые доверяют SealTask приватность своей работы. Начните с Free — банковская карта не нужна.
Начать бесплатноВопросы по безопасности? Напишите нам на security@sealtask.com