Confiança na Squish

A Squish é uma plataforma multisserviço. O site voltado ao cliente (squish.co) e o CRM interno (work.squish.co) rodam em Cloudflare Workers / Pages. Cinco backends Node.js — squish-backend, squish-crm-backend, squish-provisioning, squish-email e squish-hosting — rodam na Railway, na região US-East. Os registros de clientes ficam no Salesforce; estado transacional, logs de auditoria e metadados de provisionamento ficam no Google Firestore (região dos EUA). Os dados de pagamento são mantidos pela Stripe — por design, a Squish está fora do escopo PCI.

O registro de domínios é intermediado pela NameSilo. A hospedagem web compartilhada roda em nós Plesk hospedados em droplets da DigitalOcean; os VPS do Managed Cloud usam CyberPanel por padrão, em droplet próprio. Os sites hospedados ficam atrás do CDN e do WAF da Bunny. O licenciamento do Microsoft 365 é intermediado pela Pax8 (CSP).

• Em trânsito: TLS 1.3 (mínimo TLS 1.2) de ponta a ponta via Cloudflare. HSTS aplicado em todos os domínios voltados ao cliente.
• Em repouso: criptografia padrão do Firestore (AES-256), criptografia de plataforma do Salesforce; a Stripe processa todos os dados de cartão com controles PCI DSS Nível 1.
• Segredos: todas as chaves de API, credenciais de contas de serviço e strings de conexão de banco de dados ficam em variáveis de ambiente da Railway e secret bindings da Cloudflare — nunca versionados no código-fonte.
• Backups: recuperação point-in-time do Firestore (janela de 7 dias). Os registros de clientes do Salesforce ficam na plataforma Salesforce, com replicação e recuperação de desastres integradas.

• Autenticação de clientes: Firebase Auth (e-mail + senha, além de provedores OAuth opcionais). JWTs de curta duração (TTL de 1 hora).
• Autenticação da equipe: Cloudflare Access na frente de todas as superfícies internas. SSO + MFA obrigatórios. Tokens de sessão com escopo por aplicativo.
• Serviço a serviço: chave de API interna compartilhada + gates de função por rota (admin / suporte / vendas).
• Impersonação: toda sessão de equipe "agindo como cliente" é registrada com motivo, ações de ponta a ponta e horários de início/fim. Ações destrutivas (alteração de forma de pagamento, transferências de registrador) são bloqueadas durante a impersonação por uma denylist explícita.

Toda ação privilegiada é gravada em uma destas coleções append-only do Firestore:

• security_events — falhas de autenticação, negações de RBAC, tentativas de IDOR, acionamentos de rate limit
• impersonation_sessions — sessões de equipe agindo como cliente, com subcoleção por ação
• billing_actions — emissão de reembolsos, justificativas de limite por função, cadeias de segunda aprovação
• email_log — todo e-mail enviado, com tipo, motivo de supressão e status de envio
• webhook_events — leases de idempotência de webhooks da Stripe / NameSilo / Pax8
• cron_runs — heartbeat de cada job agendado (para que execuções ausentes fiquem visíveis)

Os controles de segurança não estão apenas descritos nesta página — os mais críticos são verificados em código, para que o próximo deploy não possa enfraquecê-los silenciosamente.

• Gate de CI nos cabeçalhos de segurança das respostas: todo PR executa um teste smoke em vitest que quebra o build se os cabeçalhos Content-Security-Policy, Cross-Origin-Resource-Policy, anti-clickjacking ou referrer-policy divergirem dos valores esperados.
• Verificação de permissões de terceiros na inicialização: ao subir, o backend confirma que a chave de API da Stripe configurada tem todos os escopos de que o dashboard e os fluxos de checkout dependem; um escopo ausente é registrado de forma explícita no boot, em vez de aparecer como falha silenciosa para o cliente.
• Helpers SOQL orientados a tipos rejeitam identificadores malformados no ponto de chamada, em vez de convertê-los silenciosamente em um valor que ampliaria a consulta — defesa contra injeção de SOQL no lado das integrações.
• Manifesto de prontidão das variáveis de ambiente: cada serviço declara todas as variáveis que consome, marcadas como obrigatórias ou opcionais, e um endpoint interno informa quais faltam na instância em execução — assim um segredo ausente aparece em uma verificação deliberada após o deploy, e não na primeira requisição de cliente que precisava dele.

Dados operacionais são mantidos por janelas curtas e justificáveis; registros financeiros são mantidos pelos 7 anos exigidos pela legislação tributária dos EUA. Solicitações de exclusão de clientes são atendidas em até 30 dias para dados não financeiros.

Fornecedores que processam dados de clientes em nosso nome. Cada um opera sob seu próprio programa de conformidade — os links levam às suas páginas públicas de confiança.

• Contato de segurança: security@squish.co — a equipe é alertada em tempo real.
• Política de divulgação responsável: /.well-known/security.txt
• SLA de resposta inicial: em até um dia útil.
• Notificação ao cliente: em até 72 horas após a confirmação de uma violação que afete dados de clientes, conforme o Artigo 33 do GDPR.
• Status do sistema em tempo real: squish.co/status

Hoje: A Squish opera um programa de segurança autoatestado, sustentado pelos controles descritos acima. A maior parte do conjunto de controles do SOC 2 Type 1 (controle de acesso, criptografia, registro de auditoria, gestão de fornecedores, gestão de mudanças) já está implementada; a auditoria formal está no roadmap.

SOC 2 Type 1: em andamento. Atestação prevista para o fim deste ano.

SOC 2 Type 2: o período de observação começa após a conclusão da atestação Type 1.

Para equipes de compras: teremos prazer em preencher um questionário de segurança (CAIQ-Lite, SIG-Lite ou o seu próprio formato). Fale conosco em security@squish.co.

Acordo de Processamento de Dados (DPA): nosso DPA padrão, alinhado ao Artigo 28 do GDPR e incluindo as Cláusulas Contratuais Padrão da UE, está publicado em squish.co/dpa e é incorporado automaticamente aos nossos Termos de Serviço.