Seu dado operacional não é argumento de venda. É responsabilidade.

⚿ Senhas nunca em texto puro

Toda senha é transformada por bcrypt antes de tocar o banco. O hash é unidirecional: o sistema não consegue ler a senha de volta, só confere se a digitação bate com o hash.

• Comparação por hash, sem-store e com custo de cálculo ajustável
• Nenhum log de aplicação registra a senha do usuário

⌘ Sessão com token de renovação

O acesso usa token JWT com expiração curta — 15 minutos por padrão —, pareado a um refresh token guardado no banco. Se o token principal expira, a sessão se renova sem exigir novo login; se a senha mudar ou o token for revogado, o acesso morre junto.

• RefreshToken e DeviceToken no IsiHub e IsiBox
• Revogação possível sem esperar o token principal expirar

◎ Isolamento por empresa

O filtro de empresa é aplicado no servidor, em cada consulta, a partir do token do usuário — não é uma condição que o front-end deixa de fora. Usuário de uma empresa não enxerga, não busca e não exporta registro de outra, mesmo mudando a URL.

• Escopo derivado de companyId no próprio acesso a dados
• Perfil de-root é caso explícito e auditado, não uma falha de filtro

⌗ Auditoria de ações

Os módulos mantêm registro de auditoria: quem fez a alteração, em qual empresa, o que mudou e quando. Isso responde à pergunta que aparece depois de qualquer problema em campo.

• AuditLog no IsiHub, IsiCore e IsiBox
• Auditoria de leitura disponível conforme o perfil do usuário

↻ Proteção contra força bruta

O acesso é limitado por taxa em duas camadas: no proxy, por rota, e na aplicação, por usuário e IP. Rota de login tem orçamento bem mais apertado que o resto da API, justamente porque é a porta de entrada.

• Limite específico para autenticação, separado das demais rotas
• Cabeçalhos de segurança e política de CORS por origem

⬡ Criptografia em trânsito e headers

Todo o site e todos os módulos respondem em HTTPS com TLS 1.2 ou superior, redirecionamento obrigatório de HTTP, HSTS ativo e cookies de sessão marcados como HttpOnly e SameSite.

• Certificado Let's Encrypt com renovação automática
• Strict-Transport-Security, nosniff, proteção de frame

! Não há autenticação em dois fatores

O acesso depende de senha forte e de gestão de quem tem conta. Não existe segundo fator por aplicativo ou token. Para operações que precisam de trilha mais forte, isso é item de evolução — e vale entrar na conversa na contratação.

! Papéis são definidos por empresa

As permissões seguem o perfil do usuário dentro da empresa. Perfis muito específicos (por exemplo, separar "vê Preço" de "vê Serviço" dentro do mesmo setor) demandam ajuste na implantação.

! Anonimização não é padrão

Dados pessoais de técnicos e clientes (CPF, contato, assinatura) aparecem como foram cadastrados. Não há mascaramento por perfil nem pseudonização automática.

! O app de campo guarda dados localmente

Para funcionar sem sinal, o aplicativo mantém pedidos, fotos e assinaturas no aparelho até sincronizar. O dispositivo do técnico precisa estar protegido por senha e por bloqueio de tela.

◈ O que você pode pedir

• Confirmação da existência de tratamento sobre os seus dados
• Acesso aos dados e correção de informações incompletas
• Eliminação ou bloqueio de dados desnecessários
• Portabilidade a outro fornecedor, mediante requisição
• Informação sobre com quem seus dados foram compartilhados

✉ Como exercer

Escreva para isiecosystem@proton.me. O pedido é respondido por Arthur Farias, responsável pelo tratamento. Pedidos sobre dados de uma empresa cliente são encaminhados ao responsável daquela empresa, que é o controlador.