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 scrypt com os parâmetros recomendados pela OWASP — N=131072, r=8, p=1 — cada uma com seu próprio salt 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 torna caro atacar com as placas gráficas que deixam a quebra comum de senhas barata. Contas criadas no nosso esquema anterior são atualizadas automaticamente na próxima vez que o titular entrar.
• 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 recebem um desafio. Login, cadastro, redefinição de senha e o formulário de contato ficam atrás de um desafio antibots que preserva a privacidade, além de limites de tentativas, 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 contorna 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 física), um app autenticador, ou um código enviado por e-mail. Passkeys são a opção mais forte e a única resistente a phishing, porque a assinatura é vinculada a closerev.com. Códigos por e-mail são a mais fraca — quem alcança sua caixa de entrada alcança o código — e dizemos isso onde você os ativa. Códigos de recuperação de uso único cobrem um dispositivo perdido. Uma vez ativado, qualquer fator se aplica a todas as formas de entrar na conta, incluindo "Entrar com o Google": uma segunda via de login não é um atalho para contorná-lo. O dono de um espaço de trabalho também pode exigir a verificação em duas etapas de todos no espaço, para que ninguém alcance os dados dele apenas com uma senha. 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, alterar sua senha, exportar tudo ou alterar uma configuração de segurança do espaço de trabalho exigem que você prove que ainda é você — o código do seu app autenticador, se tiver um; sua senha, caso contrário. 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 é toda a questão. Para a maioria delas, a prova vale por 30 minutos, então uma sequência de tarefas administrativas pergunta uma vez. Ativar ou desativar uma exigência para todo o espaço de trabalho — verificação em duas etapas, login único — pergunta sempre, nos dois sentidos: uma configuração que reduz o que é preciso para alcançar seus dados nunca deve se apoiar em uma prova dada para outra coisa.
• 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 que qualquer outro site em um domínio vizinho grave um cookie que nossos servidores leriam como seu. Podem ser revogados no servidor, e alterar sua senha invalida imediatamente todas as outras sessões. Requisições que alteram algo precisam partir do próprio CloseRev; um formulário no site de outra pessoa enviando para o nosso é recusado antes de chegar aos seus dados. Os tokens de sessão são armazenados apenas como um hash, então uma cópia do nosso banco de dados não serviria para entrar na conta de ninguém. Uma sessão termina após 30 dias, ou após 7 dias sem uso. E quando sua conta é acessada de um navegador que nunca vimos, enviamos um e-mail — com um link que desconecta todos os dispositivos, caso não tenha sido você.
• 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, downloads 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, no nosso banco de dados, e uma cópia feita toda noite é guardada por até 6 anos em um armazenamento que não pode ser alterado, para que a pergunta “alguém olhou isto?” continue podendo ser respondida por mais tempo do que qualquer plano mantém seus dados. Esses registros são encadeados: cada um é selado com um hash que cobre o registro anterior, e o banco de dados se recusa a alterar ou selar novamente um registro já selado. Remover ou editar um registro depois do fato quebra a cadeia naquele ponto, e uma verificação que roda toda noite informa onde. Uma cópia do selo mais recente da cadeia também é gravada toda noite em um repositório mantido sob credenciais separadas, para que o registro e o selo que o atesta não possam ser reescritos juntos.
• 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.
• Os arquivos baixados são seguros 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 o arquivo que você baixou. 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.

Não assinamos acordos de associado comercial (BAAs) da HIPAA, então não envie informações de saúde protegidas — um diagnóstico, um tratamento, dados de convênio ou uma consulta ligados a um paciente. Um registro de venda com nome, telefone, e‑mail, valor e data de um serviço que não diz nada sobre a saúde de ninguém pode ser enviado; se você é um prestador de saúde, deixe de fora tudo o que revele a saúde de uma pessoa.

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.
• 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, em condições normais. O produto é autoatendimento e o suporte não precisa ler seus registros. Não existe um recurso de “entrar como este cliente” nem nenhuma forma de se passar por um usuário, 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 autenticação multifator. 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.
• Os e‑mails que você nos envia. E‑mails para support@ viram um caso no nosso próprio console, e os anexos ficam guardados com o caso no nosso próprio armazenamento e são excluídos com ele depois de 24 meses. A caixa de entrada da nossa equipe recebe uma cópia do remetente, do assunto e do texto de cada mensagem enviada a um endereço closerev.com — nunca os anexos.

Como testamos o que publicamos

Quatro 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 — nossas páginas públicas, em claro e escuro, em larguras de computador e de celular, procurando transbordamento, corte e contraste, automaticamente sempre que uma mudança afeta o que elas mostram; as páginas com login da mesma forma, quando rodamos a auditoria com uma conta de teste.
• 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, cobrança, tokens públicos e ciclo de vida dos dados é condição para a disponibilidade geral. Ela foi executada repetidamente, mais recentemente como duas passagens dedicadas antes do lançamento, contra a configuração de pagamento em produção e dentro de uma cópia real do ambiente em que publicamos. Ambos os relatórios registram o que não foi provado com a mesma clareza do 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 no registro 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: retroceder 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 não existe mais.

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. O estado dos componentes é publicado na nossa página de status, que mede em vez de ser atualizada à 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 patch, 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