Segurança

Como seus dados são protegidos

• Criptografados em trânsito e em repouso. TLS 1.2+ em todo lugar; armazenamento criptografado na camada da plataforma.
• Isolamento entre workspaces. Todo registro carrega um identificador de workspace e toda consulta é limitada a ele, inclusive os endpoints que agem sobre um único registro — então um identificador adivinhado em uma conta não alcança os dados de outra.
• Tratamento de senhas. As senhas passam por hash com scryptcom os parâmetros recomendados pela OWASP — — cada uma com seu próprio sal aleatório, e nunca são armazenadas nem registradas de forma recuperável. A verificação é de tempo constante, exigimos no mínimo 10 caracteres e recusamos senhas que aparecem em bases de vazamentos conhecidas. O scrypt édifícil em memória: cada tentativa exige 128 MB de memória além de tempo, e é isso que a torna cara de atacar com as placas de vídeo que barateiam a quebra de senhas comum. Antes usávamos uma construção encadeada de PBKDF2 e dizíamos isso aqui, porque nossa plataforma limita uma única chamada de PBKDF2 a 100.000 iterações e encadear era a única forma de comprar mais trabalho; o scrypt elimina esse compromisso, então esta página agora pode nomear um algoritmo padrão e seu custo exato, em vez de descrever uma construção nossa. Contas criadas antes da mudança são atualizadas automaticamente no próximo login do seu dono.
• Sua conta não existe até você provar que o endereço é seu. O cadastro registra uma inscrição pendente e envia um link por e-mail; a conta, o workspace e a sessão são criados quando você clica nele. Isso elimina uma classe inteira de ataque em vez de se defender dela — ninguém consegue registrar uma conta no seu e-mail, definir uma senha nela e esperar que você se cadastre e a adote.
• Tentativas automatizadas de login são desafiadas. Login, cadastro e redefinição de senha ficam atrás de um desafio antibô que preserva a privacidade, além de limites de taxa, para que percorrer uma lista de senhas vazadas custe mais do que rende. Os limites contam contra a conta que está sendo tentada, além do endereço de onde vem a tentativa, porque um atacante com um conjunto de endereços derruba um limite baseado só em endereço trocando de endereço — e falhas repetidas em uma mesma conta são desaceleradas progressivamente, e não bloqueadas, por minutos, nunca de forma permanente. A redefinição de senha é contada separadamente do login, então alguém queimando de propósito suas tentativas de login não consegue também fechar o caminho que você usaria para voltar.
• Verificação em duas etapas. Três opções: passkeys (Face ID, Touch ID, Windows Hello ou uma chave de segurança), um aplicativo autenticador, ou um código enviado por e-mail. As passkeys são a mais forte e a única resistente a phishing, porque a assinatura está vinculada a closerev.com. Códigos por e-mail são os mais fracos — quem alcança sua caixa de entrada alcança o código — e dizemos isso no lugar onde você os ativa. Códigos de recuperação de uso único cobrem a perda de um aparelho. Uma vez que qualquer fator esteja ativo, ele vale para todas as formas de entrar na conta, inclusive "Entrar com o Google": uma segunda rota de login não é uma forma de contorná-lo. Adicionar um método exige outro que você já tenha, e enviamos um e-mail sempre que um é adicionado. Caso contrário, quem tivesse acesso a um aparelho em que você está conectado poderia adicionar um deles autenticador e manter o acesso mesmo depois de você trocar a senha. O aviso vai para o seu endereço, e não para a tela de quem fez isso, e leva um link que desconecta todos os dispositivos, inclusive o dessa pessoa. Métodos podem ser adicionados, mas não removidos. Quem tivesse acesso a um aparelho em que você está conectado poderia, de outra forma, remover os métodos que não tem e manter o que tem — deixando sua conta protegida exatamente pelo que foi roubado. Perdeu um aparelho? Troque a senha, o que desconecta todas as outras sessões imediatamente, e depois fale com a gente: confirmamos quem você é e removemos o método, e essa redefinição fica registrada na trilha à prova de adulteração abaixo.
• As ações mais arriscadas perguntam de novo. Encerrar sua conta, remover um segundo fator ou exportar tudo exigem que você prove que ainda é você — o código do seu aplicativo autenticador, quando você tem um, ou sua senha. Um cookie de sessão diz que alguém entrou; não diz que a pessoa no teclado ainda é você, e para essas poucas ações essa diferença é a questão inteira. A prova vale por 30 minutos, então uma sequência de tarefas administrativas pergunta uma vez só.
• Login único. Workspaces Enterprise e Agency podem exigir que todos entrem pelo próprio provedor de identidade via OpenID Connect. Um domínio precisa ser comprovado no DNS antes de poder ser usado, então ninguém consegue configurar login único para um domínio que não controla. Uma vez exigido, senhas e login com Google param de funcionar para aquele domínio — com uma exceção deliberada, o proprietário do workspace, para que um provedor mal configurado não tranque uma empresa para fora dos próprios dados. Sessões criadas assim duram uma semana em vez de um mês, porque o login único por si só não revoga acesso quando alguém sai. O client secret que você nos dá é criptografado antes de ser armazenado.
• Sessões.Tokens opacos e com validade, em cookies httpOnly, Secure e SameSite com o prefixo, o que impede qualquer outro site em um domínio vizinho de gravar um cookie que nossos servidores leriam como seu. Eles são revogáveis no servidor, e trocar sua senha invalida todas as outras sessões imediatamente. Requisições que alteram algo precisam ter origem na própria CloseRev; um formulário no site de outra pessoa enviando para o nosso é recusado antes de chegar aos seus dados.
• Links por e-mail. Links de verificação e de redefinição são de uso único e expiram, e guardamos apenas um hash SHA-256 de cada token — um vazamento do banco não renderia links funcionais. O uso único é imposto pelo banco de dados em uma única etapa, então dois cliques chegando no mesmo instante não podem ambos ter sucesso.
• Pagamentos. Os dados do cartão vão direto para a Stripe e nunca chegam aos nossos servidores, o que nos mantém fora do escopo de tratamento de dados de cartão.
• Trilha de auditoria. Uploads, correspondências, decisões de revisão, exportações e exclusões são registrados por workspace. Separadamente, toda vez que alguém da CloseRev abre um console interno capaz de ver sua conta, isso também é registrado — quem, o que consultou e quando. Guardamos esse registro por 24 meses, que é o período mais longo que qualquer plano guarda seus dados, para que a pergunta "alguém olhou isso?" continue respondível enquanto os dados existirem. Essas entradas são encadeadas: cada uma é selada com um hash que cobre a entrada anterior, e o banco de dados se recusa a alterar ou reselar uma entrada já selada. Remover ou editar uma entrada depois quebra a cadeia naquele ponto, e uma verificação noturna informa onde.
• Exclusão de verdade. Excluir uma importação remove seus registros, seus resultados de correspondência e o arquivo original enviado do armazenamento — não apenas uma marcação em uma linha.
• Exportações são seguras de abrir.Uma planilha trata uma célula que começa com , , ou como uma fórmula a executar, então um valor que alguém colocou em um CSV enviado por você poderia virar um comando na máquina de quem abrir a sua exportação. Neutralizamos essas células de um jeito que sobrevive ao arquivo ser salvo e reaberto, e deixamos números comuns e valores negativos em paz.

Minimização de dados

A correspondência precisa de um telefone ou um e-mail, e de um valor. Você escolhe quais colunas mapear, e preferimos que você envie menos. Dados de categoria especial estão totalmente fora de escopo — veja a Política de Uso Aceitável.

O que ainda não fizemos

Preferimos dizer isso com todas as letras a deixar uma página de confiança sugerir mais do que é verdade:

• Sem certificação SOC 2 ou ISO 27001. Somos um produto em estágio inicial e ainda não passamos por uma auditoria.
• Ainda sem teste de invasão por terceiros. Planejado antes da disponibilidade geral.
• Sem residência de dados configurável pelo cliente. A região de armazenamento é atualmente a padrão da plataforma.

Se algum desses pontos for um impedimento para o seu processo de compras, nos avise — é útil sabermos qual deles fazer primeiro.

Quem na CloseRev pode ver seus dados

• Ninguém, no curso normal. O produto é autoatendimento e o suporte não precisa ler seus registros. Não existe um recurso de "entrar como este cliente" e não existe personificação, deliberadamente — no momento em que um existe, ele vira o caminho mais curto para os dados de todos os clientes.
• O console interno não consegue ler seus registros enviados, de forma alguma. Ele mostra informações de conta e faturamento e contagens do que você processou. Não tem acesso aos registros de vendas ou de leads em si.
• Leituras são registradas, não só escritas. Tudo o que um administrador consulta é registrado com quem, o quê, quando e de onde. Se você um dia perguntar quem na CloseRev olhou sua conta, a resposta vem de um registro, não da memória de alguém.
• O acesso exige login único com múltiplos fatores. O console fica atrás do Cloudflare Access e ainda confere a identidade verificada contra uma lista de permissões, então não existe uma senha nossa que pudesse ser obtida por phishing para entrar nele.

Como testamos o que publicamos

Duas verificações rodam sobre o código a cada alteração, porque raciocinar sobre isolamento não é o mesmo que verificá-lo:

• Toda consulta que toca dados de clientes é enumerada e revisada. Uma verificação extrai cada consulta e mantém uma linha de base revisada, para que uma consulta nova ou reescrita que não esteja limitada a um workspace tenha de ser examinada em vez de passar despercebida.
• O isolamento é testado sobre HTTP real, não deduzido. Três workspaces separados são criados em uma cópia real do nosso ambiente, e cada endpoint que aceita um identificador é solicitado a devolver os dados de outro workspace — pelo mesmo código que o site executa, com o mesmo banco de dados, armazenamento e vínculos de sessão. Um teste que não tem como falhar não vale nada, então cada um desses roda ao lado de um controle que prova que o dono legítimo continua recebendo seus dados.
• As páginas são medidas em um navegador, não avaliadas a olho — cada página, em claro e escuro, em larguras de computador e de celular, procurando transbordamento, corte e contraste.
• Alterações no banco de dados são aplicadas por um executor que mantém um registro, que se recusa a aplicar qualquer coisa duas vezes, fora de ordem, ou quando o histórico registrado e o código já não concordam.

Uma revisão de segurança por escrito cobrindo isolamento entre clientes, autenticação, uploads, faturamento, tokens públicos e ciclo de vida dos dados é condição para a disponibilidade geral. Ela já foi feita duas vezes, a segunda com uma configuração de pagamento real e dentro de uma cópia real do ambiente em que publicamos. Os dois relatórios registram o que não foi provado com a mesma clareza com que registram o que foi.

Backups, retenção e exclusão

• Você define a janela de retenção por workspace, dentro do que seu plano mantém. Uma rotina noturna exclui importações além desse prazo — os registros, os resultados de correspondência e os CSVs originais no armazenamento de objetos — e escreve o que fez na trilha de atividade do próprio workspace.
• Excluir significa excluir. Remover uma importação remove seus registros e arquivos. Encerrar sua conta remove a conta e, onde você é o dono, o workspace e todos os arquivos que pertencem a ele. Faturas são mantidas apenas onde a legislação fiscal exige.
• Os backups são da plataforma, com recuperação para um ponto no tempo cobrindo os últimos 30 dias do banco de dados. Eles servem para nos recuperar de uma falha nossa, não são uma segunda cópia que você possa consultar.
• Uma restauração não pode desfazer uma exclusão em silêncio. Este é o único lugar onde "excluir significa excluir" precisou de mais do que um delete: rebobinar o banco de dados para se recuperar de alguma falha não relacionada traria de volta tudo o que foi removido desde então, e ninguém saberia. Então toda exclusão é registrada — o que foi removido, de qual workspace, quando e por quê, sem nenhum dos dados em si — e reaplicar esses registros é uma etapa do nosso procedimento de restauração, não algo a lembrar. Arquivos enviados não são cobertos por esse retrocesso; uma vez que um arquivo é excluído do armazenamento de objetos, ele acabou.

Se algo der errado

• Violações de dados pessoais: notificamos os clientes afetados sem demora indevida e em até 72 horas depois de tomarmos conhecimento, com o que sabemos e o que estamos fazendo. Esse compromisso é contratual — está no DPA, não apenas aqui.
• Interrupções que afetem a integridade ou o acesso aos dados: enviamos e-mail aos proprietários dos workspaces em vez de esperar que alguém consulte uma página, e de novo quando o problema é resolvido. A saúde dos componentes é publicada na nossa página de status, que mede em vez de ser atualizado à mão.

Por que esta página é específica

Nomear o algoritmo e seus parâmetros de custo é deliberado, e é o que os padrões de segurança pedem, não algo que estamos conseguindo fazer sem sermos notados. Um sistema deve ser seguro quando tudo sobre ele, exceto as chaves, é público — esse princípio é mais antigo que a indústria, e é por isso que o NIST publica seus padrões criptográficos abertamente em vez de descrevê-los de forma vaga. Um projeto que só se sustenta enquanto ninguém sabe como funciona não é um projeto que se sustenta.

O que você não vai encontrar aqui é nada que seja de fato secreto: nenhuma versão de software ou nível de correção, nenhum nome de host interno ou desenho de rede, nenhum material de chave, e nenhum limiar que um atacante pudesse calibrar — quantas tentativas disparam um bloqueio, ou quanto tempo dura um limite de taxa. Os números desta página são compromissos que assumimos com você, não configurações nas quais você poderia mirar.

Se você está nos avaliando e algo aqui não é específico o bastante para responder à sua pergunta, pergunte. Preferimos escrever a resposta a deixar você adivinhar.

Como relatar uma vulnerabilidade

E-mail security@closerev.com, ou leia a versão legível por máquina em /.well-known/security.txt. Confirmamos o recebimento em 2 dias úteis, dizemos se conseguimos reproduzir o problema em 10 dias úteis, e mantemos você informado até o caso ser encerrado. Pedimos 90 dias antes da divulgação pública, e menos se a correção sair antes.

Por favor, não acesse, altere ou guarde dados que não são seus, não rode varreduras automatizadas que degradem o serviço para clientes, e não use engenharia social com nossa equipe ou nossos fornecedores. Dentro desses limites, não processaremos pesquisadores agindo de boa-fé, e damos crédito a você se quiser.

Relacionados

Política de Privacidade · Contrato de Tratamento de Dados · Suboperadores