SEGURANÇA
Segurança que o comprador audita.
O Valid está em protótipo. Esta página lista os controles que o código cumpre hoje e, com o mesmo destaque, os que ele não cumpre. A lista de ausências é a parte mais útil daqui, e ela vem antes de qualquer dado real entrar.
O QUE EXISTE
Os controles que o código cumpre
Criptografia em trânsito e repouso
TLS com HSTS em toda comunicação, e repouso gerido pelo Google Cloud.
Token do titular com prazo curto
Link opaco, não sequencial, válido por 15 minutos. O banco guarda o hash, nunca o token.
Banco fechado ao navegador
As regras declaradas do Firestore são deny-all. Quem lê é o servidor, nunca o cliente.
A consulta nunca reserva
Reserva de direito só nasce de confirmação de titularidade no canal do próprio titular.
Decisão determinística e auditável
Regra versionada com autor e vigência. Toda decisão sai com protocolo, data e critério aplicado.
Resposta a incidente pela LGPD
Comunicação ao controlador, para o dever do art. 48 com o titular e a ANPD.
O QUE NÃO EXISTE
As ausências, declaradas
Nenhum dos itens abaixo está em construção silenciosa. Eles são o que separa este protótipo de um produto que pode receber dado de pessoa real, e estão aqui para serem lidos antes dessa decisão, não depois.
Não há autenticação nas telas de operação
As telas de /app/* respondem sem login. O protótipo troca o login por um seletor de persona, e o gate que existe é de interface, resolvido no navegador. Não trate isso como controle de acesso.
Não há conta, nem isolamento por cliente
O Valid não tem conta de usuário nem separação por empresa. Não existe associação de dado a conta para o servidor conferir, então não afirmamos que ela é conferida.
Não há papéis aplicados no servidor
As personas mudam o que a interface mostra, não o que o servidor entrega. Quem alcança a tela alcança o dado que ela carrega.
Não há registro de consentimento
O produto não guarda data, escopo, canal nem revogação da autorização do titular, e nada impede uma decisão de nascer sem ela.
Não há expurgo de dado de elegibilidade
Decisões, direitos, leituras, contestações e leads não têm prazo de retenção definido e não são eliminados por rotina alguma. O prazo está pendente de definição com o cliente.
O dado não está em solo brasileiro
O ambiente publicado roda em us-central1, nos Estados Unidos. Residência no Brasil é postura de produção, não o que está no ar.
O detalhe de cada controle. A base legal e os prazos de retenção estão na Política de Privacidade.
O ambiente que está no ar
O ambiente publicado é semeado com CPF sintético de fixture (faixa 000.000.000-XX, que não fecha dígito verificador e não corresponde a pessoa alguma). Até a data desta página, nenhum dado de titular real foi carregado nele.
É por isso que as ausências acima são toleráveis hoje, e é por isso que elas estão escritas: a mesma configuração com gente de verdade dentro seria outra conversa.
Criptografia
- Criptografia em trânsito (TLS) em todas as comunicações, com HSTS ligado.
- Criptografia em repouso gerida pelo Google Cloud, padrão do provedor em todos os serviços que armazenam dados.
O acesso do titular ao próprio caso
Este é o controle mais forte do produto hoje, porque é o único caminho de dado que nasceu com fechadura.
- Token opaco e de prazo curto. O endereço que o titular abre não é sequencial, não carrega o protocolo da decisão e vale 15 minutos. Print de tela, link reenviado ou histórico de navegador não dão acesso a nada depois do prazo.
- O banco guarda o hash, nunca o token. Quem lê um despejo da base não consegue abrir tela alguma, pelo mesmo motivo que um despejo de senhas com hash não dá login.
- A consulta identifica, não autentica. Consultar um CPF no balcão não reserva direito nenhum. A reserva só nasce da confirmação de titularidade feita no canal do próprio titular, e os dados do ato saem da decisão já emitida, nunca de um formulário.
- Link vencido continua reconhecível por 24 horas, para a tela conseguir dizer "peça outro link" em vez de "isso não existe". Depois disso o registro é descartado.
O banco
As coleções do Valid vivem no Firestore, e as regras que o repositório declara são deny-all para o banco inteiro: nenhum navegador lê ou escreve direto, o acesso é só pelo servidor, que usa credencial de administrador e não passa por essas regras.
A ressalva honesta: publicar as regras é um passo separado do deploy da aplicação. Regra que vive no repositório e não foi publicada não protege banco nenhum, e conferir isso é item de checagem antes de dado real, não suposição.
A região do ambiente publicado é us-central1, nos Estados Unidos, e a página de privacidade trata da transferência internacional que isso implica.
Autorização no servidor
O Valid não tem. Ele não tem conta, não tem papel aplicado no servidor e não tem separação por empresa. As telas de operação respondem sem login, e o gate que existe é de interface: ele decide o que renderizar depois que o navegador resolve a sessão, e não protege o dado que o servidor já entregou.
O esqueleto sobre o qual este produto foi construído tem o mecanismo (validação do token de autenticação e do papel no servidor, aplicada às rotas de API que exigem papel). Nenhuma tela do Valid passa por ele. Dizer o contrário seria vender como controle deste produto um controle de outro.
Fechar isso é pré-requisito de dado real, e o caminho é o que o esqueleto já tem: sessão verificada no servidor, papel decidido no servidor, e o dado da tela buscado atrás dessa verificação.
Registro de decisões de acesso
O mecanismo do esqueleto transforma cada decisão de autorização (permitida ou negada) num evento estruturado em log: quem, quando, qual recurso e o motivo da negação. Os registros seguem a retenção padrão do Google Cloud Logging.
Ele não cobre as telas do Valid, pela razão da seção anterior: onde não há autorização, não há decisão de acesso a registrar. O que o Valid registra é outra trilha, e ela é de negócio: cada decisão de elegibilidade guarda protocolo, data, critério aplicado e versão da regra, e cada revogação em lote guarda autor, motivo e instante.
Dados e modelos de IA
Nenhum dado de titular vai para inferência hoje. A superfície do assistente está desligada por configuração neste produto, e nenhum caminho do Valid envia CPF, leitura de fonte, decisão ou contestação para modelo algum. A decisão de elegibilidade é determinística, por regra versionada, e não passa por modelo.
O provedor contratado, quando o assistente existir, é o Google Vertex AI, cujos termos preveem que o conteúdo enviado para inferência não é usado para treinar modelos do Google.
Incidentes de segurança
Em caso de incidente envolvendo dados pessoais tratados pelo Valid, Levver Ltda comunica o controlador imediatamente, para que ele cumpra a comunicação ao titular e à ANPD conforme o art. 48 da LGPD. A comunicação incluirá a natureza do incidente, os dados afetados, as medidas técnicas e administrativas em curso e os riscos envolvidos.
Contato
Para reportar um problema de segurança ou tratar de proteção de dados, fale com o encarregado de dados em dpa@levver.ai.