Como o Databasus garante a segurança?

O Databasus é responsável por dados sensíveis:

  • acessa a sua base de dados;
  • faz backup dela (ou seja, cria uma cópia dos dados);
  • guarda credenciais para poder acessar a sua base de dados de forma regular;
  • salva backups no seu S3 ou em outros armazenamentos na nuvem (se você ativar);

Por isso, a principal prioridade do Databasus é ser seguro e confiável em nível empresarial.

Para garantir que:

  • os dados sensíveis nunca ficam expostos e estão sempre criptografados;
  • os backups são criptografados e inúteis mesmo que alguém os veja no armazenamento na nuvem;
  • o Databasus nem sequer recebe acesso de escrita ou alteração à base de dados;
  • todas as ações são registradas e podem ser auditadas;

Todos esses passos protegem os seus dados. Não existe sistema 100% seguro, mas fazemos o possível para chegar perto disso. Mesmo em caso de invasão, ninguém conseguirá corromper os seus dados.

O Databasus aplica segurança em três níveis:

  1. Criptografia de dados sensíveis;
  2. Criptografia de backups;
  3. Acesso só de leitura à base de dados.

Nível 1: criptografia de dados sensíveis

Internamente, o Databasus usa uma base de dados PostgreSQL para guardar detalhes de conexão e as configurações de notificadores e armazenamentos (S3, Google Drive, Dropbox, etc.).

Todos os dados sensíveis são criptografados. Por exemplo:

  • senhas
  • tokens
  • webhooks com segredos

Assim, na base de dados o Databasus guarda apenas hashes ou valores codificados. Para a criptografia é usado o algoritmo AES-256-GCM. Além disso, apesar da criptografia, esses valores nunca são expostos via API ou interface.

A chave secreta usada na criptografia fica no armazenamento local (./databasus-data/secret.key por padrão) e não está presente na própria base de dados. Assim, comprometer a base de dados não dá acesso aos dados sensíveis.

Nível 2: criptografia de backups

Cada arquivo de backup é criptografado em tempo real durante a criação do backup. O Databasus usa o algoritmo AES-256-GCM, que garante que os dados do backup não podem ser lidos sem a chave de criptografia e que qualquer adulteração é detectada durante a descriptografia.

Os backups passam por este pipeline:

PostgreSQL pg_dump → Compression → Encryption → Cloud Storage

Cada backup recebe uma chave de criptografia única derivada de:

  • Chave mestra (guardada em ./databasus-data/secret.key)
  • ID do backup
  • Salt aleatório (único por backup)

Resultado: mesmo que alguém consiga acesso ao seu armazenamento na nuvem (S3, Google Drive, etc.), não consegue ler os backups sem a sua chave mestra.

Nível 3: acesso só de leitura à base de dados

O Databasus aplica o princípio do menor privilégio: só precisa de acesso de leitura para criar backups, nunca de acesso de escrita. Isso protege a sua base de dados contra corrupção de dados acidental ou maliciosa através da ferramenta de backup.

Antes de aceitar credenciais de base de dados, o Databasus faz verificações em três níveis:

  1. Nível de role: confirma que o usuário NÃO é superuser e não pode criar roles nem bases de dados
  2. Nível de base de dados: garante que não há privilégios CREATE nem TEMP
  3. Nível de tabela: confirma zero permissões de escrita (INSERT, UPDATE, DELETE, TRUNCATE, etc.)

O usuário da base de dados precisa passar nas três verificações para ser considerado só de leitura. Se for detectado qualquer privilégio de escrita, o Databasus avisa.

O Databasus sugere a criação de usuários só de leitura com as permissões adequadas:

  • Concede SELECT em todas as tabelas atuais e futuras
  • Concede USAGE nos esquemas (mas não CREATE)
  • Revoga explicitamente todos os privilégios de escrita

Resultado: mesmo que o Databasus seja comprometido, o servidor invadido, a chave secreta roubada e as credenciais descriptografadas, os atacantes não conseguem corromper a sua base de dados.

🛡️ Engenharia de segurança e confiabilidade

O Databasus trabalha com dados sensíveis, por isso prevenir vulnerabilidades, acessos não autorizados e vazamentos de dados é uma preocupação central. Investimos nisso dos dois lados do sistema: no próprio código (verificações de permissões, criptografia, tratamento cuidadoso de segredos) e na infraestrutura ao redor dele (análise de dependências, resposta a CVEs, práticas de DevSecOps). O pipeline abaixo roda automaticamente em cada commit e PR. Nenhuma camada chega sozinha, mas juntas reduzem a probabilidade de código vulnerável, dependências inseguras, imagens quebradas ou backups não restauráveis chegarem a uma release.

Análise estática

A análise estática roda em várias passagens independentes. O CodeQL analisa todo o código em busca de problemas de segurança. O CodeRabbit revisa cada PR e executa o gitleaks para deteção de segredos e o semgrep para regras de segurança inline. Os Dockerfiles e os workflows de CI têm regras adicionais próprias (referências de actions fixadas, permissões de menor privilégio, imagens base suspeitas), por isso padrões inseguros são sinalizados antes de chegarem a ser integrados.

Além dessas verificações por PR, o Codex Security da OpenAI executa auditorias regulares e mais profundas de todo o código. É um programa separado que encontra problemas arquiteturais e transversais que as análises limitadas ao PR não veem.

Gestão de dependências

O Dependabot vigia todas as nossas dependências contra a GitHub Advisory Database e sinaliza CVEs minutos depois da publicação. As atualizações passam por um período de espera para que as versões recém-publicadas amadureçam antes de as adotarmos, uma defesa deliberada contra incidentes de pacotes comprometidos, como ataques à cadeia de suprimentos.

A Dependency Review Action bloqueia de imediato qualquer PR que introduza um novo CVE HIGH ou CRITICAL.

Endurecimento de containers e CI

  • As imagens de containers são analisadas com Trivy em cada build.
  • Uma passagem separada do Trivy sobre o Dockerfile detecta configurações erradas antes de entrarem numa imagem.
  • Todas as GitHub Actions estão fixadas a SHAs de commit completos, em vez de tags flutuantes como @v4 ou @main, que foram um vetor de ataque ativo em 2025.
  • Os workflows usam permissões de menor privilégio por padrão e só as elevam por job quando é realmente necessário.

Testes e verificação

Os caminhos críticos estão cobertos por testes unitários e de integração, executados contra containers de bases de dados reais para cada motor suportado e cada versão principal.

A restauração é o caminho que mais importa numa ferramenta de backup, por isso a testamos explicitamente: cada PR executa ciclos completos de backup e restauração contra esses mesmos containers reais, confirmando que os backups podem realmente ser restaurados de ponta a ponta, e não apenas escritos com sucesso.

O resto do pipeline de CI/CD executa lint, verificação de tipos, a suíte completa de testes, smoke tests das imagens e builds multiarquitetura em cada PR. Uma release só sai se tudo isso passar.

Reportar uma vulnerabilidade

Encontrou uma vulnerabilidade? Reporte-a pela aba Security do GitHub. Veja o SECURITY.md. Os relatórios de segurança são a fila de trabalho com maior prioridade.