Este documento resume, para fins de transparência pública, os principais controles técnicos de segurança da Plataforma. Integra os Termos de Serviço e o Adendo de Processamento de Dados (DPA) por referência — em caso de conflito de interpretação para Cliente que tenha aceito o DPA, prevalece o disposto neste último. Este resumo descreve controle efetivamente implementado no código desta Plataforma; não é, e não substitui, relatório de auditoria, certificação de terceiro ou questionário de segurança específico — para evidência de conformidade, ver o processo descrito na Seção 9 do DPA. É um modelo base e não constitui aconselhamento jurídico — revise antes do primeiro deploy em produção.
1. Criptografia em trânsito e em repouso
Toda comunicação entre o Cliente e a Plataforma trafega sob TLS. Em repouso, o dado é armazenado com a criptografia de disco oferecida pelo provedor de banco de dados e de armazenamento de objeto contratado pelo Fornecedor (TODO: Provedor de nuvem, TODO: sa-east-1) — a Plataforma não implementa uma segunda camada própria de criptografia de aplicação sobre esse armazenamento além do que esses provedores já oferecem nativamente.
2. Isolamento multi-tenant por Row-Level Security
Cada Organização só acessa a própria linha de dado. Esse isolamento é reforçado no próprio banco de dados PostgreSQL por meio de Row-Level Security (RLS) — política aplicada a cada tabela de escopo de organização, não apenas checagem no código da aplicação. Uma falha de autorização na camada de aplicação, portanto, não é suficiente sozinha para expor dado de uma Organização a outra: o banco recusa a consulta fora do escopo autorizado.
3. Controle de acesso: RBAC e autenticação de dois fatores
O acesso dentro de uma Organização segue controle de acesso baseado em papel (RBAC): permissão declarativa por papel, papel padrão configurável e papéis dinâmicos adicionais que a própria Organização pode criar e atribuir a Membros. Autenticação de dois fatores (2FA) está disponível como camada adicional de proteção da conta do usuário, habilitável a qualquer momento nas configurações de conta.
4. Chaves de API e Chave BYOK — rotação e revogação
Chave de API de Organização e chave de API global de integração podem ser rotacionadas ou revogadas pelo Cliente a qualquer momento, sem necessidade de abrir chamado de suporte. O mesmo vale para a Chave BYOK, quando o Cliente opta por trazer sua própria credencial de provedor de inteligência artificial — ver Transparência de IA. Chave revogada deixa de autenticar qualquer requisição imediatamente.
5. Trilha de auditoria imutável
Toda mutação sensível realizada na Plataforma — por tela, API ou pela camada
de inteligência artificial — gera um registro na trilha de auditoria
(audit_log), incluindo quem agiu, quando e o que mudou. Esse registro não é
editável nem removível por um usuário da Organização, inclusive um
administrador; é a base de investigação de incidente e de resposta a
solicitação de titular de dado.
6. Segregação de acesso interno
O papel de plataforma (staff/owner) — usado pela equipe do próprio
Fornecedor para operação e suporte — é um eixo de acesso totalmente separado
do RBAC de uma Organização cliente. Leitura de dado de uma Organização por
esse papel de plataforma só ocorre sob escopo explícito de acesso
administrativo, e fica sujeita à mesma trilha de auditoria da Seção 5.
7. Encontrou uma falha de segurança?
Reporte de vulnerabilidade segue processo, escopo e prazo próprios, descritos em Divulgação Responsável de Vulnerabilidade.
8. Contato
Dúvidas sobre este resumo de segurança: TODO: security@exemplo.com.br.