Política de Segurança da Informação

Esta política cobre o Marinero em todas as suas superfícies — o painel da marina, o aplicativo do cliente, o aplicativo do operador, os serviços de integração e o banco de dados que sustenta os três. Ela se aplica a Marinero Tecnologia LTDA, nome fantasia Marinero (CNPJ 68.280.793/0001-83), fornecedora do sistema.

O Marinero não opera servidores próprios nem mantém sala de equipamentos. Toda a infraestrutura é de provedores gerenciados, e por isso os controles descritos aqui são de identidade, acesso lógico, criptografia, segredo e rastreabilidade — não de perímetro físico. Onde a proteção depende do provedor, dizemos qual é.

A marina é a controladora dos dados dos seus clientes; o Marinero é operador. A divisão de responsabilidades está na Política de Privacidade, e esta política descreve como cumprimos a parte que é nossa.

A separação entre marinas não é feita por filtro na aplicação: é feita no próprio banco de dados, com Row Level Security do PostgreSQL. Toda tabela que carrega dado de marina tem RLS ativa e políticas que amarram a linha ao vínculo do usuário com aquela marina. Hoje são mais de 60 tabelas protegidas por mais de 100 políticas.

A consequência prática é que uma consulta feita com a credencial de um usuário de uma marina não devolve linha de outra, mesmo que a aplicação tenha um defeito. Tabelas que carregam material mais sensível — as referências de cartão, por exemplo — vão além e têm o acesso direto revogado dos papéis de navegador: só o servidor alcança.

As regras de isolamento têm testes automatizados de banco (pgTAP) que rodam no processo de integração contínua sobre uma base recriada do zero a partir das migrações.

A autenticação é feita pelo provedor de identidade (Supabase Auth). O Marinero não armazena senha: o provedor guarda apenas o resumo criptográfico, e nem a aplicação nem quem a mantém consegue ler a senha de alguém.

Dentro da marina, o acesso é por papel, e cada papel recebe só o que precisa:

• Administrador da marina — acesso completo ao painel da própria marina.
• Financeiro — clientes, embarcações, cobranças e pagamentos. Não opera navegação.
• Operador — agenda, operação e loja. Não enxerga cobrança nem pagamento.
• Loja — conta dedicada de ponto de venda, restrita à loja, sem acesso ao painel.
• Cliente — apenas os próprios dados, as próprias embarcações e as próprias cobranças, pelo aplicativo do cliente.

Cada permissão é verificada no servidor, a cada ação, e não apenas escondendo botão na tela. Um usuário pode pertencer a mais de uma marina; nesse caso os vínculos são independentes e o papel de uma não vale na outra.

O número do cartão e o código de segurança são transmitidos ao Asaas, instituição de pagamento regulada, e não são armazenados por nós em nenhum momento. Do cartão salvo guardamos apenas o token devolvido pelo Asaas, a bandeira, os quatro últimos dígitos e o nome impresso — o suficiente para você reconhecer o cartão na tela e nada além disso. O token fica restrito ao servidor.

Toda saída de dinheiro da conta digital da marina — saque, Pix a terceiro, boleto, Pix copia-e-cola — exige uma segunda barreira além do login: um PIN financeiro guardado como hash scrypt, conferido em tempo constante, com bloqueio de 15 minutos após cinco tentativas erradas. Somam-se a isso trava de destino e limites de valor configuráveis.

As comunicações recebidas do Asaas (webhooks) são autenticadas por um segredo próprio de cada marina e, quando alteram dinheiro, revalidadas contra a API do Asaas com a credencial daquela marina: nem um segredo vazado basta para forjar um pagamento. As rotinas automáticas exigem segredo próprio no cabeçalho.

Habilitações, títulos de inscrição, apólices e DPEM ficam em repositório de arquivos privado — nenhum arquivo tem URL pública. O acesso passa pelas mesmas regras de vínculo com a marina aplicadas ao banco, e o repositório limita tipo e tamanho de arquivo aceito. Os links de visualização são temporários e assinados.

Chaves de API, credenciais do Asaas, segredos de rotina e chaves de serviço vivem exclusivamente como variáveis de ambiente nas plataformas de hospedagem e banco. Nenhum segredo é versionado no repositório — arquivos de ambiente estão fora do controle de versão, e o que existe no repositório é apenas um modelo com os nomes das variáveis, sem valor.

A chave de serviço, que ignora as regras de RLS por definição, é usada apenas em código de servidor, jamais entregue ao navegador nem ao aplicativo. Toda variável obrigatória é validada na inicialização: o sistema falha de forma explícita em vez de operar com configuração pela metade.

Usamos o Sentry para saber quando algo quebra. Os padrões desse tipo de ferramenta são generosos demais para um sistema que recebe cartão — enviariam corpo de requisição, variáveis locais, cookies e cabeçalhos. Fechamos esses canais na origem:

• Corpo de requisição e de resposta não é coletado.
• Variáveis locais das pilhas de erro não são coletadas.
• Cookies não são coletados — eles carregam o token de sessão.
• Cabeçalhos de autorização e sessão são bloqueados.
• Parâmetros de consulta ao banco não são coletados, apenas a forma da consulta.
• O log da aplicação não é enviado.

Como última barreira, todo evento passa por uma limpeza que apaga campos de nome sensível (cartão, CVV, token, senha, autorização) e qualquer sequência com formato de número de cartão em qualquer texto do evento. Essa limpeza tem testes automatizados próprios.

Ações que movem dinheiro ou alteram o estado operacional deixam registro: emissão, baixa e estorno de cobrança guardam trilha de auditoria; cada transição de navegação registra quem executou e quando, com o nome do responsável preservado mesmo que o cadastro mude depois; o aceite dos documentos legais guarda a versão aceita, a data, o endereço IP e o dispositivo.

Os registros de acesso e a telemetria de infraestrutura são mantidos pelos provedores de autenticação e hospedagem, com os prazos declarados na Política de Privacidade.

Toda alteração de banco é uma migração versionada no repositório, aplicada em ordem e reproduzível do zero — não há alteração manual em produção sem registro correspondente. Toda alteração de código passa por integração contínua antes de chegar à branch principal: verificação de tipos, análise estática e testes automatizados, além da bateria de testes de banco que exercita as políticas de isolamento.

A comunicação com o sistema é criptografada em trânsito por TLS, incluindo a comunicação entre o sistema e cada fornecedor. Os fornecedores que tratam dados por nossa conta estão nomeados, um a um, na Política de Privacidade.

O banco de dados roda em serviço gerenciado, e backup e restauração são os oferecidos por esse provedor no plano contratado. Não mantemos rotina própria de cópia por cima disso, e preferimos declarar o fato a descrever um controle que não operamos. A aplicação é reconstruível a partir do repositório: código, migrações e configuração de infraestrutura estão versionados.

Nenhum sistema é imune. Se identificarmos incidente de segurança que possa acarretar risco ou dano relevante, comunicamos a marina afetada assim que houver informação confirmada, apoiamos a comunicação dela aos titulares e à Autoridade Nacional de Proteção de Dados nos prazos da LGPD, e registramos o que ocorreu, o que foi alcançado e o que foi feito para conter.

Suspeita de vulnerabilidade ou de acesso indevido deve ser comunicada a admin@marinero.com.br. Pedidos de boa-fé de pesquisadores de segurança são bem-vindos e não serão tratados como hostilidade.

Parte da segurança está fora do nosso alcance técnico e é responsabilidade de quem opera o sistema no dia a dia. Cabe à marina:

• Manter uma conta por pessoa. Login compartilhado apaga a rastreabilidade e é a falha mais comum que vemos.
• Revogar o acesso de quem sai da equipe, no mesmo dia.
• Conceder a cada funcionário o papel mínimo necessário — operador não precisa ver cobrança.
• Não repassar senha por mensagem, papel ou planilha.
• Proteger os dispositivos que ficam logados no painel e na TV da operação.

O sistema oferece os papéis, a revogação e a trilha; o uso correto deles é da marina, como controladora dos dados.

Esta política é revisada quando a arquitetura muda de forma relevante e, no mínimo, uma vez por ano. Mudanças sobem a versão e a data no topo da página.

Também é honesto dizer o que ainda não fazemos, para que ninguém conte com o que não existe: não há segundo fator obrigatório no login do painel, não passamos por teste de intrusão contratado e não possuímos certificação ISO 27001 ou SOC 2. São itens de evolução, não controles em vigor.

Dúvidas sobre esta política, ou pedido de informação adicional para processo de contratação: Igor Andrey Strejevitch, admin@marinero.com.br.