Как Databasus обеспечивает безопасность?

Databasus отвечает за чувствительные данные:

  • он получает доступ к вашей БД;
  • он делает ее бекапы (то есть копирует данные);
  • он хранит учетные данные, чтобы регулярно подключаться к вашей БД;
  • он сохраняет бекапы в ваш S3 или другие облачные хранилища (если вы это включили).

Поэтому главный приоритет Databasus — безопасность и надежность корпоративного уровня.

Мы следим за тем, чтобы:

  • чувствительные данные никогда не раскрывались и всегда были зашифрованы;
  • бекапы были зашифрованы и бесполезны, даже если кто-то увидит их в облачном хранилище;
  • Databasus вообще не получал доступ к БД с правами на запись или изменение;
  • все действия журналировались и поддавались аудиту.

Все это защищает ваши данные. Как известно, стопроцентно защищенных систем не бывает, но мы делаем все возможное, чтобы приблизиться к этому. Даже в случае взлома никто не сможет испортить ваши данные.

Databasus обеспечивает безопасность на трех уровнях:

  1. шифрование чувствительных данных;
  2. шифрование бекапов;
  3. доступ к БД только на чтение.

Уровень 1: шифрование чувствительных данных

Внутри Databasus использует базу PostgreSQL для хранения параметров подключений, конфигураций, настроек уведомлений и хранилищ (S3, Google Drive, Dropbox и т.д.).

Любые чувствительные данные шифруются. Например:

  • пароли
  • токены
  • вебхуки с секретами

Так что в своей БД Databasus хранит только хеши или зашифрованные значения. Для шифрования используется алгоритм AES-256-GCM. Помимо шифрования, эти значения никогда не отдаются через API или интерфейс.

Секретный ключ шифрования хранится на локальном диске (по умолчанию ./databasus-data/secret.key) и в самой БД отсутствует. Поэтому компрометация БД не дает доступа к чувствительным данным.

Уровень 2: шифрование бекапов

Каждый файл бекапа шифруется на лету, прямо во время создания. Databasus использует алгоритм шифрования AES-256-GCM: данные бекапа нельзя прочитать без ключа шифрования, а любая подмена обнаруживается при расшифровке.

Бекапы проходят через такой конвейер:

PostgreSQL pg_dump → Compression → Encryption → Cloud Storage

Каждый бекап получает свой уникальный ключ шифрования, который выводится из:

  • мастер-ключа (хранится в ./databasus-data/secret.key)
  • ID бекапа
  • случайной соли (уникальной для каждого бекапа)

Результат: даже если кто-то получит доступ к вашему облачному хранилищу (S3, Google Drive и т.д.), прочитать бекапы без вашего мастер-ключа он не сможет.

Уровень 3: доступ к БД только на чтение

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

Прежде чем принять учетные данные базы, Databasus выполняет проверки на трех уровнях:

  1. Уровень роли: проверяет, что пользователь НЕ суперпользователь и не может создавать роли и базы данных
  2. Уровень базы: убеждается в отсутствии привилегий CREATE и TEMP
  3. Уровень таблиц: подтверждает полное отсутствие прав на запись (INSERT, UPDATE, DELETE, TRUNCATE и т.д.)

Пользователь базы считается read-only, только если прошел все три проверки. Если обнаружена хоть одна привилегия на запись, Databasus вас предупредит.

Databasus подсказывает, как создать read-only пользователей с правильными правами:

  • выдает SELECT на все текущие и будущие таблицы
  • выдает USAGE на схемы (но не CREATE)
  • явно отзывает все привилегии на запись

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

🛡️ Инженерия безопасности и надежности

Databasus работает с чувствительными данными, поэтому предотвращение уязвимостей, несанкционированного доступа и утечек — одна из главных задач. Мы вкладываемся в это с обеих сторон системы: в самом коде (проверки прав, шифрование, аккуратное обращение с секретами) и в инфраструктуре вокруг него (анализ зависимостей, реакция на CVE, практики DevSecOps). Конвейер ниже автоматически запускается на каждом коммите и PR. Ни один слой сам по себе не закрывает все, но вместе они снижают шанс, что в релиз попадет уязвимый код, небезопасные зависимости, сломанные образы или невосстановимые бекапы.

Статический анализ

Статический анализ идет в нескольких независимых проходах. CodeQL сканирует всю кодовую базу на проблемы безопасности. CodeRabbit ревьюит каждый PR и прямо в нем запускает gitleaks для поиска секретов и semgrep с правилами безопасности. У Dockerfile и CI-процессов есть свои дополнительные правила (закрепленные ссылки на actions, минимальные привилегии, подозрительные базовые образы), так что небезопасные паттерны отлавливаются до того, как попадут в основную ветку.

Поверх этих проверок на каждый PR Codex Security от OpenAI регулярно проводит более глубокие аудиты всей кодовой базы. Это отдельная программа, которая ловит архитектурные и сквозные проблемы, недоступные узким проверкам на уровне PR.

Управление зависимостями

Dependabot сверяет все наши зависимости с GitHub Advisory Database и показывает CVE уже через несколько минут после публикации. Обновления проходят через период выдержки, чтобы только что выпущенные версии успели «созреть», прежде чем мы их примем. Это осознанная защита от зараженных пакетов и атак на цепочку поставок.

Dependency Review Action сразу блокирует любой PR, который приносит новую CVE уровня HIGH или CRITICAL.

Защита контейнеров и CI

  • Образы контейнеров сканируются Trivy при каждой сборке.
  • Отдельный проход Trivy по Dockerfile ловит ошибки конфигурации до того, как они попадут в образ.
  • Все GitHub Actions закреплены на полные SHA коммитов, а не на плавающие теги вроде @v4 или @main, которые в 2025 году были активным вектором атак.
  • Процессы по умолчанию работают с минимальными привилегиями и расширяют их для отдельных задач только при реальной необходимости.

Тестирование и проверка

Критичные пути покрыты и юнит-, и интеграционными тестами, которые гоняются на настоящих контейнерах баз данных для каждой поддерживаемой СУБД и мажорной версии.

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

Остальной конвейер CI/CD запускает линтер, проверку типов, полный набор тестов, smoke-тесты образов и мультиархитектурные сборки на каждом PR. Релиз выходит, только если все это прошло.

Как сообщить об уязвимости

Нашли уязвимость? Сообщите о ней через вкладку Security на GitHub — см. SECURITY.md. Сообщения об уязвимостях мы разбираем в первую очередь.