> ## Documentation Index > Fetch the complete documentation index at: https://developers.googa.com.br/llms.txt > Use this file to discover all available pages before exploring further. # Segurança da informação — visão geral > Criptografia, isolamento multi-tenant e defesa em profundidade: o que já está em produção hoje e o que é desenho de destino. 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](https://supabase.com) (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](/architecture/supabase-auth-model) 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](/security/child-data-eca)). 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](/architecture/supabase-auth-model#partner-gateway-a-camada-que-conecta-as-duas-pontas). 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](/architecture/supabase-auth-model)) 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](/security/incident-response) é 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. Severidade, tempos de resposta e o fluxo de comunicação — incluindo quando um incidente aciona notificação à ANPD. Base legal, direitos do titular, retenção, DPO, RIPD e transferência internacional — artigo por artigo.