Como protegemos os dados de sua gente.

Criptografia AES-256-GCM aplicada aos campos sensíveis no banco de dados: e-mails de usuários e colaboradores, secret TOTP do 2FA, tokens de API de suas integrações HRIS, client secret de OIDC e o RUT nos dados de faturamento.

As chaves são gerenciadas via AWS KMS em produção, com suporte de rotação incremental. Para lookups que não exigem descriptografar (autenticação, busca de pessoas), usamos hashes SHA-256 determinísticos em índices compostos.

Todo o tráfego entre navegador, CloudFront, nginx, API e banco de dados viaja sobre TLS 1.3 com ciphers modernos. HSTS preload com max-age de 2 anos e includeSubDomains para garantir que nenhum navegador caia jamais para HTTP.

Seu banco de dados (Neon PostgreSQL serverless), Redis, S3 e infraestrutura de computação vivem em AWS sa-east-1. Os dados não saem da região sem sua autorização explícita.

Única exceção: as chamadas a Claude (Anthropic) e Voyage AI (embeddings) viajam fora da região, mas com PII redatada e sob contrato enterprise que proíbe treinamento.

Para buscar usuários por e-mail sem necessidade de descriptografar (login, password reset, convite), armazenamos um emailHash SHA-256 em um índice composto (companyId, emailHash). Isso evita descriptografar o campo em cada request e elimina o risco de side-channel attacks por timing em queries.

Mesmo padrão para RefreshToken.tokenHash, ApiKey.keyHash, InviteToken.token e PasswordResetToken.token.

Os JWTs viajam em cookies HttpOnly, SameSite=None, Secure, inacessíveis a partir do JavaScript do cliente (evita roubo via XSS).

Os cookies são divididos por path: access_token (15 min) em path / e refresh_token (7 dias) em path /api/v1/auth/refresh. Assim o refresh só é enviado quando realmente é necessário e sua exposição é reduzida.

Cada refresh token é de uso único. Se o mesmo token chega duas vezes (usedAt já marcado), assumimos possível roubo: invalidamos automaticamente TODOS os tokens do usuário incrementando tokenVersion e forçamos um re-login.

Os tokens são armazenados como hash SHA-256, nunca em claro. A rotação reduz drasticamente a janela de ataque se um token for vazado.

O logout não exige consultar uma blacklist no banco de dados em cada request. Incrementamos um campo tokenVersion em User, e nossa JWT strategy compara payload.tv === user.tokenVersion. Qualquer JWT emitido antes do logout deixa de validar instantaneamente.

Vantagem: zero latência por request (sem query extra) e permite invalidar TODAS as sessões de um usuário em uma única mudança atômica.

Suporte completo de 2FA por TOTP (Google Authenticator, Authy, 1Password). O secret é armazenado criptografado AES-256-GCM com uma chave dedicada (TOTP_ENCRYPTION_KEY), separada da chave principal.

Ao ativar 2FA geramos 10 backup codes hashed com bcrypt para recuperação. Adicionalmente suportamos WebAuthn / passkeys, permitindo login sem senha com Face ID, Touch ID, Windows Hello ou chaves de hardware (YubiKey).

Modelo SsoConfig ativo para clientes Enterprise: armazena entryPoint SAML, issuer e certificado do IdP, além das credenciais OIDC criptografadas em repouso com AES-256-GCM. O client secret de OIDC nunca é exposto em claro fora do momento de criação.

Provisioning via SCIM 2.0 disponível em preview: endpoint /scim/v2/Users com token Bearer (SHA-256 hash no DB, mostrado em claro apenas uma vez ao gerar) que permite ao seu IdP criar e desabilitar usuários. O fluxo completo de login SSO (validação de assertions SAML assinadas e troca de tokens OIDC) está no roadmap Enterprise — disponível mediante solicitação para avaliação antecipada.

Validamos cada senha contra HIBP (Have I Been Pwned) usando k-anonymity: enviamos apenas os primeiros 5 caracteres do hash SHA1, nunca a senha completa. Se estiver em breaches públicos, rejeitamos.

Lockout automático após 5 tentativas falhas (15 min de bloqueio). O login e o forgot-password retornam sempre a mesma mensagem genérica, para prevenir email enumeration.

Defesa em profundidade real no nível do banco de dados. Cada tabela tenant-scoped tem políticas ROW LEVEL SECURITY que filtram por company_id automaticamente — mesmo que uma query da aplicação esquecesse o filtro, o PostgreSQL retorna 0 linhas sem erro.

O PrismaService (REQUEST-scoped) executa SET LOCAL app.company_id = '<uuid>' no início de cada transação, lendo o id desde um AsyncLocalStorage populado pelo TenantContextMiddleware. As políticas usam current_setting('app.company_id')::uuid para comparar. Os background jobs e schedulers rodam dentro de runWithCompany(companyId, fn), garantindo que nenhuma operação toque dados fora do seu tenant.

O companyId jamais viaja no body de um request. Sempre é lido do header X-Company-ID e validamos que o usuário autenticado tenha uma Membership nessa empresa antes de continuar.

Isso significa que nem mesmo com um token JWT roubado é possível acessar dados de outra empresa: o JwtAuthGuard rejeita o request se não encontrar membership matching.

O middleware Prisma tem duas listas explícitas: SCOPED_MODELS (54 modelos que exigem filtro por companyId) e ALLOWED_MODELS (modelos globais sem tenant: enums, plan catalog, etc.).

Qualquer modelo não incluído em ambas as listas dispara uma exception imediata. É impossível introduzir acidentalmente um novo modelo sem passar por code review explícito de segurança.

O modelo trabalha com representações simbólicas, não com dados pessoais reais. Cada redação é registrada em PromptGuardrailEvent para auditoria.

Reconhecemos e bloqueamos 18 padrões distintos de prompt injection: 'ignore previous instructions', 'DAN mode', 'jailbreak', 'pretend you are', 'forget your rules', 'override your instructions', 'role play as', 'developer mode', 'simulate being', entre outros.

Cada tentativa fica registrada com hash SHA-256 do input (não o conteúdo) em PromptGuardrailEvent, junto com o userId e companyId, para detectar abuso sistemático.

Quando injetamos dados de sua empresa em um prompt RAG, os envolvemos em marcadores claros: <<<COMPANY_DATA>>>...<<<END_COMPANY_DATA>>> e <<<USER_QUESTION>>>...<<<END_USER_QUESTION>>>.

Isso evita prompt confusion: o modelo distingue o que é contexto factual de sua empresa, qual é a pergunta do usuário, e quais são suas próprias instruções do system prompt. Padrão recomendado na literatura de LLM safety.

Usamos Anthropic Claude em tier enterprise: por contrato, nenhum input nem output é usado para treinar modelos públicos. O mesmo com Voyage AI (embeddings): não armazena queries.

Não há model fine-tuning com dados de um cliente que beneficie outro. Suas informações ficam com você.

Cada recomendação tem duas camadas: Layer 1 (regras determinísticas) que sempre se executa e garante uma resposta, e Layer 2 (Claude) que enriquece com critério qualitativo.

Se a IA falha por qualquer motivo (rate limit, timeout, erro de rede, output inválido), a camada de regras responde. O cliente nunca vê tela vazia e também não vê degradação em segurança.

Operamos sob os padrões da Lei 19.628 sobre Proteção da Vida Privada do Chile. Os dados pessoais de seus colaboradores são tratados com consentimento, finalidade específica e direito de acesso/retificação/cancelamento.

Documento DPA (Data Processing Agreement) disponível para todos os clientes que o requeiram.

Cumprimos com a LGPD brasileira: bases legais claras para cada tratamento, direitos do titular (acesso, correção, eliminação, portabilidade) e notificação de incidentes em prazos razoáveis.

Para clientes brasileiros, o DPA específico de LGPD e o contato do Encarregado de Dados estão disponíveis sob solicitação.

Embora nosso foco seja LATAM, implementamos os direitos GDPR como baseline: portabilidade (export ZIP com todos seus dados em JSON), direito ao esquecimento (soft/hard delete com anonymization), minimização (só coletamos o necessário) e transparência (esta página).

Operamos com controles equivalentes à ISO 27001 (criptografia AES-256-GCM, segregação por tenant fail-closed com RLS DB-level, audit log imutável, 2FA obrigatório em planos Enterprise, hard-delete GDPR, guardrails contra prompt injection, etc.) e com um Sistema de Gestão de Segurança da Informação (SGSI) estabelecido — 16 políticas formais ratificadas pela direção em 2026-05-15. O certificado externo é o próximo passo.

Enquanto isso, oferecemos DPA bilateral sob solicitação (support@talyzr.com), lista atualizada de sub-processadores e respondemos questionários de segurança pré-preenchidos (CAIQ Lite, SIG Lite, custom).

Toda ação crítica fica registrada em uma tabela AuditLog que jamais é apagada: USER_LOGIN, USER_LOGOUT, criação/modificação/eliminação de cargos, sucessores, decisões de talent review, mudanças de criticidade, impersonações de platform-admin, mudanças de subscription.

Cada entry guarda before/after JSON, userId, companyId, entityType, entityId e timestamp. Se um usuário se apaga (GDPR), seu userId é anonimizado mas o log permanece para cumprimento legal.

Se cancela sua subscription, os dados ficam disponíveis 90 dias antes do cleanup automático.

Para empresas chilenas que exijam fatura eletrônica para deduzir IVA, emitimos DTE (Documento Tributário Eletrônico) automaticamente ao confirmar cada pagamento. Integração com Bsale e Nubox.

Você recebe PDF + XML por e-mail com folio atribuído pelo SII. O RUT em CompanyBillingInfo é armazenado criptografado AES-256 em repouso.

CloudFront protegido com AWS WAFv2 aplicando AWSManagedRulesCommonRuleSet (OWASP Top 10), AWSManagedRulesSQLiRuleSet e regras custom de rate limiting. Logs de violações revisados periodicamente para detectar padrões de abuso.

Os webhooks externos (Paddle, Talana, Resend) usam assinatura HMAC + idempotency em Redis por 24h.

Monitoramento de erros com Sentry, configurado com sendDefaultPii: false e um hook beforeSend que substitui e-mails em breadcrumbs por [email] antes de enviar.

tracesSampleRate: 0.2 em produção para manter custo controlado. Cada request leva um requestId único (ULID) propagado em headers e logs JSON estruturados para correlação entre frontend, backend, queue e Sentry.