Этот раздел для тех, кто проверяет продукт перед внедрением. Здесь без общих слов: какие механизмы защиты применяются, что именно шифруется и какие решения администратор может проверить самостоятельно.
Обмен между клиентом и сервером идёт по HTTPS и WSS. В production приложение проверяет, что публичный адрес использует HTTPS, refresh-cookie помечаются как Secure, а межсайтовые запросы разрешены только доверенным origin из списка.
TLS
HTTPS для запросов и WSS для веб-сокетов.
Secure cookie
Refresh-токен не передаётся по незащищённому соединению.
CORS allowlist
Разрешены только явно перечисленные источники, а не произвольные домены.
Пароли пользователей не хранятся в открытом виде — сохраняется bcrypt-хэш. Пароли подключённых почтовых ящиков шифруются алгоритмом AES-256-GCM отдельным ключом окружения, поэтому доступ к базе сам по себе не даёт доступа к чужой почте.
bcrypt
Хэширование паролей пользователей.
AES-256-GCM
Шифрование паролей почтовых аккаунтов отдельным ключом.
Хэши токенов
Refresh-токены хранятся в базе в виде хэшей, а не открытых значений.
Access-токены короткоживущие. Refresh-токены непрозрачные, ротируются при каждом обновлении и отзываются при выходе, смене пароля или подозрении на повторное использование — попытка применить старый токен инвалидирует цепочку сессии.
Вход, регистрация, обновление токена и выход ограничены rate limit по пользователю или IP, что осложняет перебор паролей.
Сообщения и файлы защищены транспортным шифрованием и серверной моделью доступа, а не сквозным шифрованием — это осознанное решение: серверная модель позволяет администрировать права, вести аудит и разворачивать продукт в контуре компании.
Каждый запрос проверяется на стороне сервера: роль участника, эффективные права, приватность канала, участие в проекте и права руководителя проекта. Интерфейс не является границей доступа.
Роли и эффективные права участников
Приватные каналы с проверкой участия
Права на уровне проекта, включая роль project lead
Изоляция данных на уровне рабочего пространства
Для каждого вебхука создаётся отдельный Secret URL и signing secret, подписи GitHub, GitLab и Bitbucket проверяются на стороне сервера. Секреты можно перевыпустить, если появилось подозрение на утечку.
Административные действия фиксируются в журнале аудита, а журнал доставок вебхуков показывает статус ответа и ошибку внешнего сервиса.
Когда регламент требует хранить данные внутри периметра, Atlas разворачивается на вашей инфраструктуре. В этом случае к перечисленным механизмам добавляются ваши политики: сетевая изоляция, схема бэкапов, управление доступом к серверам и сроки хранения.
Нет. Защита строится на транспортном шифровании и серверной модели доступа. Это сознательный компромисс: он позволяет администрировать права, вести аудит и разворачивать продукт в контуре компании. Если требуется, чтобы данные физически не покидали периметр, используется on-premise развёртывание.
В облачной версии — в нашем объектном хранилище, в on-premise — в хранилище на вашей инфраструктуре. Доступ к файлу проверяется теми же правилами, что и доступ к каналу или проекту.
Refresh-токены отзываются, активные сессии перестают обновляться. То же происходит при выходе и при обнаружении повторного использования уже применённого токена.
Да, административные действия фиксируются в журнале аудита. Для интеграций отдельно доступен журнал доставок вебхуков.
Если служба безопасности готовит опросный лист — присылайте, ответим по пунктам. Развернуть тестовый контур можно до принятия решения.