Segurança, privacidade e confiabilidade
A segurança na Zenifra combina controles da plataforma, configuração correta do projeto e boas práticas da equipe que opera a aplicação. Esta página descreve os pontos públicos que devem ser revisados antes de colocar cargas importantes em produção.
Modelo de acesso
Contas CPF e CNPJ operam por meio de organizações. Dentro de uma organização, o acesso pode ser separado por papéis e permissões granulares.
Use organizações para:
- separar projetos pessoais, empresas e clientes
- convidar membros sem compartilhar credenciais
- limitar acesso a projetos, bancos, billing, GitHub e chaves de IA
- revisar quem pode editar variáveis, ver logs, acionar deploys ou alterar cobrança
Para detalhes de papéis e permissões, consulte Organizações e Permissões.
Segredos e variáveis de ambiente
Segredos de aplicação devem ficar fora do código-fonte. Use variáveis de ambiente no console para armazenar:
DATABASE_URL- tokens de serviços externos
- chaves privadas
- API keys
- credenciais de registry privado
Boas práticas:
- não comite
.envde produção - use nomes consistentes entre ambiente local e produção
- rotacione credenciais quando alguém sair da equipe
- separe chaves por ambiente, cliente ou integração
- conceda permissão de edição apenas a quem realmente precisa
Atenção: Variáveis de ambiente podem ser lidas ou alteradas por membros com permissão no projeto. Não coloque segredos em código frontend, artefatos públicos, imagens Docker públicas ou logs de build. Ao trocar um segredo, publique uma nova versão ou reinicie a aplicação quando necessário para que o processo leia o valor atualizado.
API keys
Projetos e recursos podem expor chaves usadas para automação ou integração. Trate essas chaves como segredos de produção.
Recomendações:
- copie e guarde a chave no momento em que ela for exibida
- não envie chaves em mensagens, issues públicas ou logs
- use uma chave por integração quando possível
- limite API keys globais por IP quando a origem da automação for fixa
- conceda apenas as permissões RBAC necessárias para a automação
- remova ou substitua chaves que possam ter vazado
- documente internamente quem é responsável por cada chave
Risco: API keys da Zenifra permitem automações sobre recursos da organização. Não use essas chaves em aplicações web executadas no navegador nem em clientes mobile distribuídos publicamente; use apenas em ambientes controlados, como servidores, pipelines e ferramentas internas. Se houver suspeita de vazamento, revogue a chave e crie uma nova.
Banco de dados
Bancos gerenciados PostgreSQL e MariaDB mostram dados de conexão no console. A aplicação precisa receber esses dados por variável de ambiente.
Pontos de atenção:
- o usuário da aplicação não deve ser tratado como
rootousuperuser DATABASE_URLdeve ser configurada manualmente no projeto HTTP- storage persistente continua relevante mesmo quando a aplicação está parada
- upgrade de versão pode causar indisponibilidade temporária
- backup, retenção e restauração devem ser validados conforme a necessidade do projeto e o plano contratado
Rede e exposição pública
Projetos HTTP recebem uma URL da Zenifra e podem usar domínio próprio conforme o plano. Para aplicações internas, administrativas ou em homologação, revise controles de acesso por IP quando disponíveis.
Antes de produção:
- valide DNS e domínio
- use HTTPS nos endpoints públicos
- limite acesso administrativo
- evite expor painéis internos sem autenticação
- trate URLs de banco e tokens como dados sensíveis
Logs e auditoria operacional
Logs ajudam a investigar falhas, mas também podem vazar dados se a aplicação registrar informações sensíveis.
Evite escrever em logs:
- senhas
- tokens
- headers de autorização
- documentos pessoais
- payloads completos com dados sensíveis
Quando precisar de trilha de auditoria formal, defina internamente o que deve ser registrado pela aplicação e valide com o suporte quais eventos da plataforma estão disponíveis para o seu plano.
LGPD e dados pessoais
A Zenifra deve ser usada de forma compatível com a LGPD e com a política de dados da sua organização. A aplicação publicada na plataforma continua responsável por definir base legal, minimização, retenção e exclusão dos dados que coleta.
Boas práticas:
- colete apenas os dados necessários
- documente retenção e exclusão
- proteja dados pessoais em logs e integrações
- revise permissões de membros com frequência
- mantenha canal interno para solicitações de titulares
Incidentes
Se suspeitar de vazamento de chave, acesso indevido ou comportamento anormal:
- rotacione chaves e senhas afetadas
- revise membros e permissões da organização
- verifique logs da aplicação
- reduza exposição pública se necessário
- acione suporte com contexto objetivo
Próximos passos
FAQ
A Zenifra substitui a segurança da aplicação?
Não. A plataforma fornece controles operacionais, mas autenticação da aplicação, autorização de usuários finais, validação de entrada e proteção de dados continuam sendo responsabilidade do projeto.
Posso compartilhar uma conta entre pessoas?
Não é recomendado. Use organizações, convites e permissões para separar acessos e manter rastreabilidade operacional.
Onde guardar segredos?
Guarde segredos no console como variáveis de ambiente ou no cofre interno da sua organização. Nunca versionar segredos no repositório.