Segurança da Informação

1. Nosso compromisso

Trabalhamos com três princípios permanentes:

• Menor privilégio — cada pessoa e cada componente só acessa o que precisa para cumprir a sua função;
• Defesa em profundidade — nenhuma proteção é a única barreira; controles se sobrepõem;
• Fail-closed — em situação ambígua, o sistema nega o acesso em vez de conceder.

2. Contas e autenticação

• Senhas armazenadas exclusivamente como hash criptográfico (algoritmo bcrypt) — nunca em texto claro; nem nós conseguimos lê-las.
• Verificação em duas etapas (2FA/TOTP) disponível para todas as contas — e obrigatória para administradores da plataforma e para quem aprova pagamentos.
• O segredo do segundo fator é guardado cifrado (AES-256-GCM), com códigos de recuperação de uso único.
• Sessões de acesso são tokens opacos com registro no servidor, entregues em cookie HttpOnly (inacessível a scripts) e com expiração controlada; trocar a senha invalida as sessões antigas.
• Limitação de tentativas de login por origem, com registro de falhas no canal de segurança.

3. Proteção dos dados

• Todo o tráfego entre o seu navegador e a plataforma usa criptografia TLS (HTTPS).
• Proteção ativa contra CSRF (requisições forjadas entre sites) em todas as operações de escrita.
• Consultas ao banco de dados exclusivamente com parâmetros preparados — a defesa estrutural contra injeção de SQL.
• Dados de cada empresa são segregados por identificador obrigatório em todas as tabelas de negócio — o isolamento entre clientes é imposto pelo próprio banco de dados, não apenas pela aplicação.
• Logs de sistema aplicam mascaramento de dados pessoais e redação de segredos; senhas de certificados e credenciais de terceiros que o fluxo exige não são persistidas.
• Credenciais de integração ficam fora do código-fonte, em configuração restrita do servidor.

4. Controle de acesso

• Papéis e permissões por empresa (RBAC): cada usuário só enxerga e opera as empresas às quais foi vinculado, com permissões granulares por módulo.
• Operações financeiras críticas seguem segregação de funções: quem cria um pagamento não pode aprová-lo (maker-checker).
• Alterações relevantes geram trilha de auditoria com autor, data e diferença do que mudou.
• Áreas administrativas exigem segundo fator ativo — sem exceção, inclusive para leitura.

5. Cópias de segurança

• Backup diário e automático do banco de dados, transmitido por conexão segura (HTTPS) para provedor de armazenamento independente da hospedagem — uma falha na infraestrutura principal não compromete as cópias.
• Cada cópia passa por verificação de integridade antes de ser considerada válida (tamanho, formato e marcador de conclusão do arquivo).
• O processo de restauração é exercitado como parte da rotina de desenvolvimento — backup que nunca foi restaurado é apenas uma esperança.
• Retenção controlada, com descarte automático das cópias antigas.
• Falha na rotina de backup gera alerta imediato por e-mail à equipe.

6. Monitoramento e alertas

• Monitoramento externo e independente de disponibilidade: indisponibilidade gera alerta em minutos.
• Vigilância automática dos logs: entradas de erro ou de segurança disparam notificação à equipe.
• Eventos de segurança (logins, falhas, negações de acesso, alterações administrativas) são registrados em canal próprio e revisados periodicamente.

7. Desenvolvimento seguro

• Toda alteração de código passa por testes automatizados (mais de 700 verificações no momento desta versão) e análise estática em integração contínua antes de chegar à produção.
• Algoritmos financeiros críticos têm vetores de teste compartilhados entre as camadas do sistema — a mesma conta tem que fechar em todos os lugares.
• A plataforma passa por auditorias internas de segurança registradas e acompanhadas (a mais recente cobriu autenticação, autorização, injeção e exposição de dados).
• Correções de segurança têm prioridade sobre qualquer outra entrega.

8. Resposta a incidentes

Mantemos um fluxo definido de resposta: detecção (monitoramento e alertas descritos acima) → contenção e correção → avaliação de impacto → comunicação. Incidente de segurança com risco relevante a titulares de dados é comunicado à ANPD e aos afetados nos termos do art. 48 da LGPD, como descrito na seção 10 da Política de Privacidade.

9. Encontrou uma vulnerabilidade? (divulgação responsável)

Se você identificou uma possível falha de segurança no SynX Economy, agradecemos o reporte responsável — pesquisadores de boa-fé são bem-vindos.

• Canal: contato@synxbr.com com o assunto [Segurança]. Padrão legível por máquina em /.well-known/security.txt.
• O que incluir: descrição da falha, passos para reproduzir, endereço/rota afetada e, se possível, evidência (captura de tela ou requisição). Quanto mais reproduzível, mais rápido corrigimos.
• Nosso compromisso: confirmar o recebimento em até 5 dias úteis, manter você informado do andamento e creditar o achado, se desejar, após a correção.
• Pedimos: divulgação coordenada (não publicar a falha antes da correção), não acessar, alterar ou reter dados de terceiros além do mínimo necessário à demonstração, e não executar ataques de negação de serviço, spam ou engenharia social contra usuários.
• Escopo: a plataforma em economy.synxbr.com. Sistemas de terceiros (bancos, provedores integrados) estão fora do nosso escopo — reporte-os aos respectivos responsáveis.

10. Contato

Assuntos de segurança: contato@synxbr.com (assunto [Segurança]). Assuntos de privacidade e dados pessoais: Encarregado (DPO) Matheus Ferreira — matheus.ferreira@synxbr.com. Veja também a Central de Privacidade.