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, origens Git 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.

Proteja também cada conta de usuário:

• ative a autenticação em dois fatores (2FA) com um app autenticador (TOTP)
• acompanhe o histórico de login dos últimos 7 dias em Conta
• mantenha ativas as notificações de login e de alteração de senha

Veja Segurança da conta.

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 .env de 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 salvar um segredo novo como variável de ambiente, as instâncias do projeto são reiniciadas automaticamente para ler o valor atualizado; veja Variáveis de ambiente.

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, MariaDB e ClickHouse/Analytics) e serviços Valkey 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 root ou superuser
• fora da implantação conjunta por template, DATABASE_URL (ou as variáveis equivalentes) deve 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
• não conte com backup automático: mantenha rotinas próprias de backup (por exemplo, dumps periódicos) e teste a restauração

Rede e exposição pública

Projetos HTTP públicos recebem uma URL da Zenifra e podem usar domínio próprio conforme o plano. Para aplicações internas, administrativas, workers ou automações que não precisam receber tráfego externo, crie ou altere o projeto para exposure: private para evitar domínio público.

Quando o projeto precisa continuar público, revise os controles de acesso por IP, disponíveis a partir do plano Premium Plus; veja Acesso de rede.

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

A plataforma mostra o histórico de login de cada usuário e o último acesso e último IP de cada API Key. Quando precisar de trilha de auditoria formal das operações da aplicação, defina internamente o que deve ser registrado e registre esses eventos na própria aplicação.

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:

1. rotacione chaves e senhas afetadas
2. revise membros e permissões da organização
3. verifique logs da aplicação
4. reduza exposição pública se necessário
5. acione o suporte ([email protected]) com contexto objetivo

Para acompanhar a disponibilidade da plataforma e incidentes em andamento, consulte a página de status em status.zenifra.com.

Próximos passos

• Checklist antes de ir para produção
• Limites e quotas
• Organizações
• Configuração do projeto

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.