Segurança

O isolamento não depende do código da aplicação lembrar de filtrar. Ele é imposto pelo próprio banco de dados, com Row Level Security: cada linha carrega a qual conta e a qual empresa pertence, e a política do banco recusa a leitura de qualquer linha fora da conta de quem está autenticado.

A diferença prática: uma consulta escrita errado por nós não vira vazamento de dados de outro cliente — ela simplesmente não retorna nada. A trava está uma camada abaixo do lugar onde os erros acontecem.

• Em trânsito: todo o tráfego usa TLS. O acesso por HTTP simples é redirecionado.
• Em repouso: banco de dados e arquivos armazenados são criptografados em disco pelo provedor de infraestrutura.
• Senhas: nunca são armazenadas em texto. Guardamos apenas o hash, e ele não permite recuperar a senha original — nem por nós.

Cada pessoa tem login próprio. Dentro da conta há papéis distintos, e as ações que mexem em dinheiro ou apagam histórico — zerar uma empresa, alterar assinatura, remover usuários — são verificadas no servidor, não apenas escondidas na tela.

Essa distinção importa: esconder um botão no navegador não protege nada, porque a requisição pode ser feita sem passar pela tela. A verificação de papel acontece no mesmo lugar onde a alteração é gravada.

Sobre o cookie de sessão, vale a precisão em vez do slogan: o do app é lido pela biblioteca de autenticação dentro do navegador, então não é HttpOnly — é assinado, expira e é revogado no logout, mas quem executasse JavaScript na página conseguiria lê-lo. Os cookies do portal do cliente e o de sessão de suporte, esses sim, são HttpOnly.

A URL do portal, sozinha, não abre nada: quem chega nela sem sessão vê a tela de acesso. A credencial é um link de uso pessoal enviado por e-mail, válido por 24 horas, que estabelece uma sessão daquele portal — validada no servidor a cada requisição e derrubada na hora quando o usuário é desativado. Dito de forma direta: não há senha, então quem tiver acesso à caixa de e-mail do destinatário dentro dessas 24 horas entra.

Os dados exibidos no portal são lidos por um caminho privilegiado no servidor, atrás dessa verificação de sessão. Não há como consultá-los a partir do navegador sem estar autenticado naquele portal específico.

Cada entrada no portal e cada documento enviado pelo cliente ficam registrados, com data e autor. O portal é de leitura e envio; não há download de documento por lá.

Boa parte da segurança de um financeiro está no que o software deliberadamente não pode fazer:

• Não temos acesso às suas contas bancárias. Extratos entram por arquivo importado por você.
• Não enviamos ordens de pagamento ao banco. Geramos o arquivo CNAB; quem envia e aprova, no canal do próprio banco, é você.
• Não custodiamos valores. O boleto que você emite é registrado no seu banco, por arquivo de remessa, e o dinheiro cai na sua conta — sem passar por nós em momento algum.

A consequência é direta: um comprometimento da plataforma não move dinheiro sozinho — ainda seria preciso passar pela aprovação no banco.

Existe uma função de suporte que permite a um administrador nosso assumir a sessão do titular de uma conta para diagnosticar um problema que não se reproduz de fora. É restrito a administradores do FinanceiroX, com a verificação feita no servidor, e o acesso registra quem, qual conta e quando. Esse registro ainda não bloqueia o acesso quando falha ao gravar — está no item 12.

Está escrito aqui pelo mesmo motivo do item 12: uma página de segurança que só lista o que protege, e omite quem consegue entrar, não está descrevendo o sistema.

O banco de dados tem backup automático diário, com retenção conforme o plano de infraestrutura (até 30 dias) e possibilidade de restauração a ponto no tempo.

Independentemente disso, você tira os seus dados da plataforma sem pedir para ninguém: relatórios e extrato de conta em CSV, e os lançamentos no layout do seu sistema contábil. O que ainda não existe na tela é a exportação integral da base numa operação só; até existir, ela é atendida por pedido ao suporte. Está escrito aqui porque backup que depende de pedir ao fornecedor é backup que não existe no dia em que ele é preciso — e essa parte, hoje, ainda depende de pedir.

A aplicação roda em infraestrutura gerenciada, com atualização de sistema operacional e patches de segurança a cargo do provedor. O banco de dados é gerenciado, com atualizações aplicadas pelo fornecedor.

Chaves de serviço e segredos ficam em variáveis de ambiente do servidor, nunca no código enviado ao navegador, e são rotacionáveis sem alteração de código.

Cada versão passa por checagem de tipos, build completo, testes das regras de cálculo e uma verificação que percorre o código atrás de gravações no banco cujo erro esteja sendo ignorado. Hoje essas quatro rodam como parte do processo de publicação, não como trava automática de repositório — amarrá-las a um pipeline que barre a publicação é item do roteiro (ver 12).

Essa última existe por um motivo aprendido na prática: a biblioteca que usamos não interrompe a execução quando o banco recusa uma gravação — ela devolve o erro em um campo que é fácil não ler. Código que ignora esse campo silenciosamente dá a impressão de que gravou. Em um sistema financeiro, isso é a diferença entre "pago" e "acha que pagou".

Em caso de incidente com risco relevante, comunicamos os clientes afetados em até 72 horas da confirmação, com o que já se sabe: o que aconteceu, quais dados foram envolvidos, o que foi contido e o que recomendamos fazer. Autoridades e titulares são comunicados quando a lei exigir.

Não esperamos ter todas as respostas para avisar. Avisamos com o que temos e atualizamos depois.

Se você encontrou algo, escreva para seguranca@financeirox.com.br com a descrição e os passos para reproduzir. Respondemos em até 3 dias úteis.

Pedimos que a análise se limite a contas de sua própria titularidade e que não haja acesso, cópia ou alteração de dados de terceiros. Reportes feitos de boa-fé, dentro desses limites, não geram medida de nossa parte.

Um item de segurança que está no roteiro não é um item entregue. Hoje não oferecemos:

• Autenticação em dois fatores (MFA) — está no roteiro.
• Login corporativo via SSO/SAML.
• Certificação SOC 2 ou ISO 27001. Não somos certificados e não afirmamos ser.
• Teste de intrusão por empresa independente com relatório publicado.
• Trilha de auditoria completa de todas as alterações. Hoje existem registros específicos — entrada e envio no portal, uso da função de suporte, remessas geradas, envios de cobrança —, não um histórico de toda alteração.
• Pipeline que barre a publicação quando uma verificação falha (as verificações existem; a trava automática não).
• Exportação integral da base em uma operação, pela própria tela.
• Registro bloqueante do acesso de suporte: hoje ele é gravado, mas não impede o acesso se falhar.
• Cancelamento da assinatura pela própria tela (hoje é por e-mail).

Se algum desses itens é requisito do seu processo de compras, fale conosco antes de contratar — preferimos dizer "ainda não" agora do que na renovação.