Política de Segurança

1. Abordagem

VERA pode publicar, enviar e gastar em seu nome, então a propriedade de segurança mais importante não é criptográfica: é que VERA não age sem você. Ações externas são registradas como propostas e executadas somente depois que você as aprova, ou de acordo com uma regra de automação que você mesmo configurou. A exigência de aprovação é aplicada no caminho de código que executa as ações, e não apenas declarada em política.

O segundo princípio é que as credenciais são as joias da coroa. A VERA guarda tokens de plataformas que podem movimentar dinheiro, publicar para um público e ler as contas de uma empresa. Eles são criptografados com uma chave separada de todo o resto e nunca são exibidos de volta na interface nem gravados em logs.

2. O que já está em vigor

Cada um dos itens a seguir está implementado no produto hoje.

• Criptografia em trânsito. Todo o tráfego é servido via HTTPS. Em produção, requisições HTTP simples são redirecionadas permanentemente para HTTPS na borda, e o HTTP Strict Transport Security é declarado com max-age de dois anos, includeSubDomains e preload.
• Criptografia de segredos em repouso. As credenciais de conectores e as chaves de API são criptografadas com AES-256-GCM, uma cifra autenticada, de modo que um texto cifrado adulterado falha na descriptografia em vez de gerar dados alterados. A chave é um valor dedicado que a validação de inicialização em produção exige que esteja presente, seja distinto e tenha comprimento suficiente.
• Segurança de senhas. As senhas são criptografadas com hash bcrypt com fator de trabalho 12 e nunca são armazenadas nem registradas em formato legível. Um comprimento mínimo é exigido. A verificação de e-mail é obrigatória antes que uma conta com senha possa fazer login.
• Gerenciamento de sessões. As sessões são JSON Web Tokens assinados que carregam um contador de revogação, verificado no banco de dados a cada solicitação autenticada. Incrementar esse contador invalida todas as sessões emitidas de uma só vez, e é isso que faz com que a redefinição de senha, a opção “sair de todos os dispositivos” e a suspensão de conta realmente encerrem as sessões ativas, em vez de apenas impedir novas.
• Redefinição de senha e verificação. Os links de redefinição são de uso único, expiram após 1 hora, têm limite de envio com intervalo de espera e revogam todas as sessões quando usados. Os links de verificação expiram após 24 horas. A solicitação de redefinição nunca revela se uma conta existe.
• Limite de requisições. Login, cadastro, redefinição de senha e ações de IA têm limite de taxa por meio de contadores duráveis de janela fixa mantidos no banco de dados, para que os limites sobrevivam a reinicializações de processo e se apliquem a todas as instâncias, e não apenas dentro de uma.
• Isolamento de tenants. Toda consulta é restrita à conta autenticada. Uma verificação de propriedade que falha é, ela própria, registrada como evento de segurança.
• Funções e licenças da equipe. Uma conta empresarial pode ter várias pessoas. Cada membro é convidado pelo titular da conta, aceita o convite com as próprias credenciais em vez de um login compartilhado e recebe uma função cujas permissões são verificadas no servidor, e não apenas refletidas na interface. Os membros podem ser desativados, o que encerra o acesso deles, mas mantém o nome deles nos registros que enviaram. Envios de funcionários, como despesas e quilometragem, são atribuídos à conta que os enviou.
• Controle de acesso administrativo. O console interno de operações é restrito a uma lista explícita de operadores autorizados configurada no ambiente. Toda ação de operador é gravada em um log de auditoria administrativa somente de inclusão, que registra quem fez o quê e em qual conta.
• Trilha de auditoria. Cada proposta, aprovação, edição, recusa, execução e falha é registrada em um log de auditoria somente de acréscimo (append-only) por conta, junto com eventos de segurança como alterações de senha, revogações de sessão, suspensões e rotações de links de orçamento. Segredos, tokens e hashes de senha são excluídos por design.
• Cabeçalhos de segurança HTTP. Uma Content Security Policy que restringe scripts, estilos, frames e destinos de formulários; X-Frame-Options DENY e frame-ancestors none contra clickjacking; X-Content-Type-Options nosniff; uma política de referrer strict-origin-when-cross-origin; e uma Permissions-Policy definida como camera=(), microphone=(self), geolocation=(self). Microfone e localização são permitidos apenas nas páginas da própria VERA, nunca a um terceiro incorporado, e só entram em vigor depois que você concede ao navegador a permissão para o recurso que a solicita.
• Integridade de webhooks. Os webhooks recebidos são verificados de acordo com o esquema de assinatura de cada provedor antes do processamento, incluindo as assinaturas do Stripe, o cabeçalho HMAC da Meta, o HMAC do Jobber, a chave de assinatura do Square e o token verificador dedicado do QuickBooks. As entregas são desduplicadas pelo ID do evento, para que um reenvio não possa aplicar um efeito duas vezes.
• Proteção contra falsificação de solicitação do lado do servidor. Quando o produto acessa uma URL fornecida por você, como o domínio de uma loja ou um site a ser analisado, o endereço é validado pelo esquema, pela porta e pela resolução de todos os IPs para os quais ele aponta, rejeitando faixas de loopback, privadas, link-local, de NAT de nível de operadora e de metadados de nuvem. Os redirecionamentos são tratados de forma que um host público não possa desviar uma solicitação para um host interno.
• Segurança dos links públicos. Os links de orçamento enviados aos clientes usam 256 bits de aleatoriedade criptograficamente segura. Os proprietários podem gerar um novo link, o que invalida imediatamente o antigo e registra uma impressão digital irreversível dele para auditoria. Consultas de token malsucedidas são limitadas para que o endpoint não possa ser atacado por força bruta, e os tokens são mascarados sempre que, de outra forma, apareceriam em logs ou telas de administração.
• Escopos de integração com privilégio mínimo. As integrações solicitam apenas os escopos de que seus recursos precisam, e várias são somente leitura por design, incluindo QuickBooks Online e Jobber. As análises de cobrança usam uma chave separada, restrita e somente leitura do provedor de pagamentos, para que uma visualização de análise nunca possa alterar o estado da cobrança.
• Isolamento dos dados de pagamento. Os números de cartão nunca chegam à VERA. O pagamento é recebido no checkout hospedado da Stripe e gerenciado pelo portal de cobrança da Stripe, de modo que os sistemas da VERA não fazem parte do caminho dos dados do titular do cartão.
• Configuração segura por padrão. A validação na inicialização se recusa a rodar em produção com o segredo de sessão de desenvolvimento, sem um segredo de sessão ou sem uma chave dedicada de criptografia de segredos, e emite alertas sobre integrações configuradas pela metade que falhariam silenciosamente.
• Backups diários criptografados. O banco de dados de produção é exportado uma vez por dia, criptografado com AES256 antes de sair da máquina que gerou a cópia, e armazenado separadamente do provedor do banco de dados. Em seguida, cada execução restaura a cópia criptografada que acabou de gerar em um banco de dados descartável e falha se essa restauração falhar ou voltar vazia; assim, um backup só é contabilizado depois de ter sido restaurado. Os backups são mantidos por 30 dias, e a recuperação pontual (point-in-time recovery) do próprio provedor do banco de dados cobre as horas entre eles.
• Suspensão da conta. Uma conta comprometida ou usada de forma abusiva pode ser suspensa, o que bloqueia todos os pontos de entrada autenticados e revoga as sessões ativas, sem excluir dados e de forma reversível.

3. O que ainda não está em vigor

Estes são controles sobre os quais um avaliador de segurança perguntaria com razão. A VERA não os tem hoje. Nós os listamos em vez de deixar que o leitor deduza sua existência a partir da seção acima.

• Sem certificações. A VERA não concluiu uma auditoria SOC 2 Tipo I ou Tipo II, não possui certificação ISO 27001, não tem um programa de business associate da HIPAA e não é avaliada pelo PCI DSS por conta própria. O processamento de cartões de pagamento é inteiramente delegado à Stripe.
• Sem autenticação multifator. Atualmente, a VERA não oferece autenticação de dois fatores, aplicativos autenticadores, chaves de segurança físicas nem passkeys. Ao entrar com o Google, você herda a proteção multifator que tiver na sua conta Google, que é hoje a opção mais forte disponível.
• Sem login único (SSO). Não há SSO corporativo via SAML ou OIDC, nem provisionamento via SCIM.
• Sem gerenciamento de usuários baseado em diretório. Os membros da equipe são convidados e gerenciados dentro da VERA. Não há provisionamento nem desprovisionamento automático a partir de um provedor de identidade; portanto, remover alguém do seu próprio diretório não remove o acesso dessa pessoa à VERA. Você também precisa desativá-la na VERA.
• Sem teste de invasão independente nem programa de bug bounty. A VERA não contratou um teste de intrusão realizado por terceiros e não opera um programa pago de recompensa por bugs.
• Sem chaves de criptografia gerenciadas pelo cliente. As chaves de criptografia são gerenciadas pela VERA. Não é possível usar sua própria chave.
• Sem opção de residência de dados. Os dados são processados nos Estados Unidos. Não há opção de hospedagem na UE ou regional.
• Sem arquivo de backups de longo prazo. Os backups diários são mantidos por 30 dias. Não há arquivo mensal ou anual, nem terceira cópia externa, nem restauração de uma conta individual a partir de um backup: uma restauração recupera o banco de dados inteiro, portanto é uma medida de resposta a incidentes, e não um serviço de recuperação oferecido aos clientes.
• Sem operações de segurança 24/7. Não há um centro de operações de segurança com equipe 24 horas, nenhuma escala formal de plantão divulgada aos clientes e nenhum produto de detecção de intrusão além dos controles no nível da aplicação listados acima.
• Sem compromisso de disponibilidade. A VERA não oferece acordo de nível de serviço. Consulte os Termos de Serviço.

4. Infraestrutura

A VERA é executada como uma aplicação Next.js em contêiner sobre Node.js, implantada a partir de um build multiestágio que gera uma imagem de runtime autossuficiente, com um banco de dados PostgreSQL gerenciado. Um endpoint de integridade é disponibilizado para o monitoramento da plataforma.

Fotografias enviadas, imagens geradas e documentos importados são armazenados como dados codificados no banco de dados da aplicação, e não em um serviço separado de armazenamento de objetos. Isso significa que não existe um bucket configurado separadamente que possa ficar com leitura pública, e também significa que o armazenamento de arquivos herda a criptografia em repouso que o provedor do banco de dados aplicar.

Hospedagem, proteção em nível de rede e segurança física são fornecidas pelos provedores de plataforma indicados na Lista de Subprocessadores, de acordo com seus próprios programas de segurança. A VERA não opera data centers próprios.

5. Monitoramento e resposta a incidentes

O registro de logs da aplicação e de erros funciona em produção, e o console interno de operações exibe a saúde do sistema, o status das tarefas em segundo plano, as falhas de integração e um painel de segurança que informa itens como o acúmulo de links de orçamento ainda em um formato de token legado.

Se tomarmos conhecimento de um incidente de segurança que afete dados de clientes, investigamos, contemos o incidente e avaliamos quais dados foram envolvidos. No caso de dados pessoais tratados em nome de um cliente empresarial, a VERA notifica o cliente afetado sem demora injustificada e em até 72 horas após tomar conhecimento, conforme exigido pelo Adendo de Processamento de Dados. As notificações a autoridades reguladoras e a indivíduos são responsabilidade do controlador, e nós prestamos assistência.

Atualmente, a VERA não publica uma página de status nem um histórico público de incidentes.

6. Como comunicar uma vulnerabilidade

Comunique problemas de segurança para support@meetmyvera.com com o assunto “Security report”. Inclua detalhes suficientes para reproduzir o problema: a URL ou o recurso afetado, as etapas e o impacto que você acredita que ele tem. Comunicações criptografadas são bem-vindas; é só pedir que providenciaremos.

Procuramos confirmar o recebimento de um relato em até 3 dias úteis e apresentar uma avaliação em até 10 dias úteis. Manteremos você informado enquanto trabalhamos em uma correção e avisaremos quando ela for lançada. Teremos prazer em dar crédito a você publicamente, se desejar.

7. Divulgação responsável e porto seguro

Se você pesquisar a segurança da VERA de boa-fé e dentro dos limites abaixo, não tomaremos medidas legais contra você e consideraremos sua pesquisa autorizada nos termos da legislação aplicável sobre uso indevido de computadores. Pedimos que você:

• Teste apenas a sua própria conta. Use uma conta criada por você. Não acesse, modifique nem retenha dados de outro cliente. Se você se deparar inadvertidamente com dados de outra pessoa, pare, não os salve e nos conte o que aconteceu.
• Evite causar danos. Sem negação de serviço, sem testes de carga ou de estresse, sem spam, sem engenharia social contra nossa equipe ou nossos clientes e sem ataques físicos.
• Não use scanners automatizados em grande volume. Varreduras automatizadas agressivas são indistinguíveis de um ataque e farão com que você tenha suas requisições limitadas ou seja bloqueado.
• Dê-nos tempo. Comunique o problema de forma privada e nos dê um prazo razoável para corrigi-lo antes de divulgá-lo. Nossa expectativa padrão é de 90 dias; normalmente somos muito mais rápidos e avisaremos você se algo precisar de mais tempo.
• Não pratique extorsão. Reter detalhes até receber pagamento não é um relatório de segurança. A VERA não mantém um programa de recompensas pago e não pode oferecer recompensa.

8. Sua parte

Use uma senha forte e exclusiva e prefira entrar com o Google se a sua conta Google tiver a autenticação multifator ativada, já que o VERA ainda não oferece a sua própria.

Não compartilhe suas credenciais. Dê a cada pessoa que precisa do VERA sua própria conta autorizada, convidando-a e atribuindo uma função, em vez de distribuir um login: o login do titular da conta compartilhado concede acesso total, inclusive ao faturamento e a todas as plataformas conectadas, e impede que o registro de atividades indique quem realmente fez cada ação. Desative um membro assim que ele não precisar mais de acesso.

Conceda integrações apenas onde precisar do recurso e desconecte as que deixar de usar. Gere um novo link de orçamento se ele tiver sido encaminhado para onde você não pretendia. Revise sua trilha de auditoria se algo parecer errado e nos avise em support@meetmyvera.com se suspeitar de acesso não autorizado.