Skip to main content
As medidas citadas abaixo refletem o estado real em produção hoje — não uma promessa genérica de compliance.

​
Criptografia

Toda comunicação entre app/cliente e a API — hoje servida diretamente pelo Supabase (PostgREST, Auth, Edge Functions) — é criptografada com TLS, terminado na borda da infraestrutura do provedor. É nativo do Supabase, não uma configuração que a Googa precisa manter manualmente: não há endpoint HTTP sem TLS em nenhum produto.
O Postgres de cada projeto Supabase roda sobre disco criptografado por padrão pelo provedor de nuvem subjacente (criptografia de volume, AES-256) — isso vale para todos os três projetos (Novel, HistorinhAI, e o projeto Platform — já existente no código, com deploy em produção pendente). A Googa não precisa (e hoje não configura) nada adicional para que o dado em disco esteja cifrado.
As chaves de criptografia em repouso são geridas pelo KMS do provedor de nuvem que sustenta o Supabase — não por um KMS operado diretamente pela Googa. Isso é adequado para o nível de risco atual, mas vale registrar com transparência: a Googa hoje não possui uma chave própria (CMK/BYOK) sobre esse material, então a rotação e as políticas de chave seguem o padrão do provedor, não uma política definida pela Googa. Uma central de secrets própria por aplicação (para credenciais de parceiro, chaves de LLM, etc. — separado do KMS de disco) ainda não existe hoje — ver Modelo de autenticação para o desenho do Partner Gateway.

​
Isolamento & controle de acesso

RLS do Postgres é a linha de defesa principal em produção hoje, em todos os projetos: cada política filtra por auth.uid() (leitor) ou por family_id/partner_id resolvido server-side — nunca por um valor que o próprio cliente envia na requisição. Esse controle passa por auditoria ativa, não só por um desenho único no início do projeto:
  • Em historinhai, a policy de insert de reading_sessions exige consistência entre family_id e child_id — um usuário autenticado só consegue gravar uma sessão apontando para um child_id que pertence à mesma família informada, o que evita poluição de dado entre famílias.
  • Em novelai/novelaudio, toda função security definer (incluindo remove_reading_progress) roda com search_path = '' e qualifica tudo explicitamente por public. — o padrão adotado em todo o projeto como defesa em profundidade contra search_path hijacking em funções que rodam com privilégio elevado.
NovelAI e NovelAudio compartilham um projeto Supabase; HistorinhAI roda em um projeto inteiramente separado — decisão deliberada dado o tratamento de dados de crianças (ver Proteção de dados de menores). Não existe hoje nenhuma consulta cross-projeto no nível de banco: qualquer travessia entre produtos passa por uma Edge Function que valida a chamada de novo.
As Edge Functions de TTS, e-mail e geração de URL assinada de áudio respondem com uma allowlist explícita de origem, não com Access-Control-Allow-Origin: *. A autenticação real é por header Authorization (JWT), não por cookie — então CORS aberto não permitiria forjar sessão de outra origem — mas a allowlist é mantida como defesa em profundidade: evita que qualquer site arbitrário chame esses endpoints pagos (TTS, e-mail, signed URL de áudio) em nome de um usuário já autenticado em outra aba.
A função generate_short_code — usada para código de convite de família e de indicação/promo — usa gen_random_bytes() (extensão pgcrypto), um CSPRNG de verdade, e não random() do Postgres, que não é criptograficamente seguro. Relevante porque um código previsível de convite de família permitiria a um atacante entrar em uma família de terceiros sem ser convidado.
Escopos diferenciados por parceiro e por rota estão implementados no Partner Gateway: cada endpoint exige um escopo específico (entitlements:write, subscriber:read, billing:read), verificado contra os escopos gravados na credencial do parceiro — um token sem o escopo da rota recebe 403. Ver Modelo de autenticação. O que ainda não existe é isso rodando em produção — o deploy do Partner Gateway está pendente; até lá, o único controle de acesso em produção é o do usuário final do produto.

​
Defesa & resposta

O site institucional (googa.com.br) já publica cabeçalhos de segurança na borda (X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Strict-Transport-Security: max-age=63072000; includeSubDomains; preload, Content-Security-Policy restritiva, Referrer-Policy: strict-origin-when-cross-origin) via public/_headers do provedor de hospedagem. Isso é real e está em produção — mas é a borda do site estático, não da API. A API em si (PostgREST/Edge Functions do Supabase) hoje só tem o rate-limit interno do próprio Supabase para proteção da plataforma, não um rate-limit configurável por parceiro/rota.
A Googa não opera hoje um WAF dedicado, um SIEM, ou um programa de pentest periódico contratado — além do que a própria infraestrutura de hospedagem/Supabase já aplica para proteção geral da plataforma. O desenho para fechar essa lacuna é um proxy de borda (Cloudflare, à frente do Custom Domain do Supabase — ver Modelo de autenticação) fazendo WAF gerenciado e rate-limit por token de API antes de chegar ao backend, mais um ciclo de pentest externo contratado antes do go-live com qualquer parceiro enterprise.
Hoje a operação é pequena o suficiente para não ter um SOC 24×7 nem alertas de anomalia automatizados de segurança. O processo de resposta a incidentes descrito em Resposta a incidentes é o desenho que operacionaliza o compromisso de SLA (P1 em 15 minutos) — não uma prática já rodando com essa maturidade.

​
Alinhamento a padrões

A Googa segue os controles da ISO 27001 como referência de boas práticas de gestão de segurança da informação — isso significa alinhamento aos controles, não uma certificação ISO 27001 obtida por auditoria de terceira parte. Não há certificação a apresentar hoje — onde um processo de licitação exigir evidência de certificação formal, isso não é algo que a Googa possa reivindicar como já obtido.

Resposta a incidentes

Severidade, tempos de resposta e o fluxo de comunicação — incluindo quando um incidente aciona notificação à ANPD.

LGPD

Base legal, direitos do titular, retenção, DPO, RIPD e transferência internacional — artigo por artigo.