Este documento descreve os controles de segurança que a UDISOFTBOX CONSULTORIA E TECNOLOGIA LTDA ("INGESTIA") mantém na plataforma ingestia.io. Ele existe para ser lido por quem avalia um fornecedor — time de segurança, jurídico, compras — e por qualquer cliente que queira saber como seus dados são protegidos.
Cada medida abaixo corresponde a um controle implementado. Nada aqui é aspiração: o que ainda não existe está na seção 13, nomeado.
1. Responsabilidade compartilhada
A INGESTIA protege a Plataforma. O Cliente protege o que está do lado dele.
| Responsabilidade da INGESTIA | Responsabilidade do Cliente |
|---|---|
| Isolamento entre ambientes de clientes | Quem recebe acesso ao ambiente, e com qual papel |
| Cifragem das credenciais que o Cliente cadastra | Força das senhas e ativação do segundo fator pelos seus usuários |
| Trilha de auditoria das ações na Plataforma | Revisar essa trilha e agir sobre o que vê |
| Disponibilidade e recuperação da Plataforma | Segurança das fontes de dados, redes e dispositivos próprios |
| Guardas de custo e de consulta | Decidir que dado entra na Plataforma, e se ele pode entrar |
Controle da Plataforma não substitui segurança da origem. Uma fonte exposta continua exposta depois de conectada.
2. Acesso, identidade e papéis
- Senha é armazenada como derivação criptográfica (scrypt), nunca em texto legível. A INGESTIA não tem como ler a senha de ninguém.
- Segundo fator (MFA) por aplicativo autenticador (TOTP) está disponível para qualquer conta. Quando ativado, o código é exigido também no acesso por senha — ativar é decisão do usuário ou do administrador do ambiente.
- Acesso único (SSO) pela conta udiApps, para quem já usa o ecossistema.
- Provisionamento automático (SCIM 2.0) para clientes que gerenciam usuários por diretório corporativo: criar, atualizar e desativar usuário sem passar pela nossa mesa.
- Papéis e permissões: cinco papéis (proprietário, administrador, membro, leitor e administrador de organização) sobre uma lista fechada de 32 ações. Papel de leitor não executa, não exporta e não gasta; a verificação é feita no servidor, em cada ação, e não na tela.
3. Isolamento entre clientes
Este é o controle que mais importa num produto de dados, e por isso é o mais explícito:
- cada cliente tem conjuntos de dados próprios no armazém analítico, com nomes derivados de um prefixo exclusivo;
- as permissões de infraestrutura são escopadas a esse prefixo;
- consulta que tente alcançar endereço fora do prefixo autorizado é recusada antes de executar — não é filtrada depois;
- o cache de resultados é segregado por cliente: resposta de um ambiente não é servida a outro;
- o destino de cada consulta não vem do pedido do navegador, e sim do painel ou do modelo que a originou — pedido não escolhe de que ambiente ler.
4. Criptografia
- Em trânsito: TLS em todo o acesso à Plataforma e às nossas interfaces de programação.
- Em repouso, nas credenciais: tudo que o Cliente cadastra como segredo — senha de banco de origem, chave de serviço, token de API e a chave de IA própria do Cliente — é cifrado com AES-256-GCM antes de ir ao banco. A chave de cifragem vive em variável de ambiente do servidor e não é acessível pelo navegador.
- Segredo não volta. A interface nunca reexibe um segredo cadastrado: mostra, no máximo, os quatro últimos caracteres para reconhecimento. Segredo também não é escrito em registro de execução.
- Em repouso, nos dados de negócio: cifragem gerenciada pela infraestrutura de armazenamento, conforme a Lista de Subprocessadores.
5. Trilha de auditoria
Toda ação relevante na Plataforma é registrada com autor, ação, recurso, momento, e — quando se aplica — o SQL executado e o custo daquela execução. A trilha é visível ao Cliente dentro do próprio ambiente e fica guardada por 730 dias, conforme a Política de Retenção.
A existência do SQL na trilha tem consequência de privacidade e está declarada: uma consulta pode conter valor de filtro que seja dado pessoal. Isso está descrito na Política de Privacidade, e é por isso que a trilha tem prazo e expurgo automático.
6. Acesso administrativo da INGESTIA
Dizer "acesso restrito" sem dizer o que ele alcança não informa nada. Então:
- a equipe da INGESTIA possui um mecanismo de acesso administrativo que permite abrir o ambiente de um cliente para dar suporte e diagnosticar problema;
- ele é limitado a contas de super-administrador, controladas por variável de ambiente do servidor — não é concedido por tela nem por convite;
- o uso fica registrado na trilha de auditoria;
- ele não é usado para finalidade diversa de suporte, operação e segurança da Plataforma.
O que ainda não existe: notificação automática ao Cliente quando esse acesso ocorre. Está na seção 13.
7. Resiliência e recuperação
- Armazém analítico: recuperação de estado anterior por sete dias (time travel), o que cobre exclusão ou transformação equivocada feita pelo próprio Cliente.
- Zona de entrada dos arquivos: versionamento de objetos — sobrescrever não destrói a versão anterior.
- Banco de metadados: cópia de segurança e recuperação a ponto no tempo, pelo serviço gerenciado descrito na Lista de Subprocessadores.
- Verificação de saúde: a Plataforma expõe uma verificação profunda que reporta o estado real de cada capacidade. Em produção, caminho que não tem credencial configurada falha de forma visível em vez de simular sucesso — é uma regra de arquitetura, com trava em teste.
8. Guardas de execução
- Teto de custo por consulta: a execução é recusada pelo motor quando ultrapassaria o volume máximo de dados autorizado, antes de gerar custo.
- Parâmetros nomeados na geração de SQL — defesa contra injeção por valor de filtro.
- Limite de taxa nos pontos sensíveis (autenticação, formulários públicos, interfaces de integração), distribuído entre instâncias.
- Cabeçalhos de segurança do navegador, incluindo política de conteúdo (CSP) por área da aplicação e restrição de enquadramento em moldura.
9. Desenvolvimento e mudança
- Todo o código da Plataforma é coberto por uma suíte automatizada executada antes de cada publicação, com travas específicas para as regras que já causaram prejuízo — entre elas o congelamento byte a byte das saídas do motor de consulta e a proibição de caminho que finja sucesso em produção.
- Mudança de esquema de banco é aditiva e versionada em migração.
- Formatos salvos pelo Cliente (painel, filtro, tema) usam envelope versionado com leitura da versão anterior obrigatória: atualização nossa não destrói configuração dele.
10. Fornecedores
Papel, finalidade, dados envolvidos e país de cada fornecedor constam da Lista de Subprocessadores, mantida pública e atualizada. Fornecedor material novo é informado com pelo menos 15 dias de antecedência, conforme o Acordo de Tratamento de Dados (DPA).
Quando o Cliente cadastra chave de IA própria, o provedor de IA por ela atendido não é subprocessador da INGESTIA: a contratação e a política de retenção de prompts são entre o Cliente e esse provedor.
11. Incidentes de segurança
Confirmado incidente que envolva dados pessoais do Cliente, a INGESTIA notifica sem demora injustificada e, sempre que viável, em até 24 horas, com o que estiver disponível: natureza, categorias e volume estimado, titulares afetados, contenção, riscos e ponto de contato — e atualiza conforme a investigação avança.
A comunicação à Autoridade Nacional de Proteção de Dados e aos titulares é decisão do Cliente, na condição de controlador, observado o prazo regulatório vigente. A INGESTIA apoia a investigação e a comunicação.
12. Teste de intrusão e relato de falha
Teste de intrusão, varredura ou carga contra a Plataforma exige autorização escrita prévia — pedidos por seguranca@ingestia.io.
Quem encontra uma falha de boa-fé deve reportá-la pelo mesmo canal. A INGESTIA não trata relato de boa-fé como violação da Política de Uso Aceitável. O procedimento e o compromisso estão na Política de Divulgação de Vulnerabilidades.
13. O que este documento NÃO afirma
Esta seção existe porque documento de segurança que só lista virtudes não é informação, é propaganda — e porque afirmar certificação que não se tem é, além de tudo, declaração falsa.
- A INGESTIA não possui certificação ISO/IEC 27001, SOC 2 ou equivalente. Nenhum material nosso afirma possuir.
- Não há relatório de teste de intrusão independente disponível para compartilhamento nesta data.
- O acesso administrativo descrito na seção 6 não gera notificação automática ao Cliente. Ele é auditado; o Cliente precisa consultar a trilha.
- Não há percentual de disponibilidade comprometido em contrato. O que existe é prazo de atendimento e objetivos internos, descritos no documento de Nível de Serviço (SLA) — e a razão de não haver percentual está escrita lá: não há série de medição persistida que o sustente.
- A cifragem de credenciais em repouso usa chave em variável de ambiente, não serviço gerenciado de custódia de chaves com rotação automática.
Quando qualquer item acima mudar, ele sai desta seção e entra na seção correspondente, na mesma data em que o controle passar a existir.
14. Contato
Segurança: seguranca@ingestia.io · Privacidade e titulares: privacidade@ingestia.io · Encarregado: Encarregado de Dados (DPO) — encarregado@ingestia.io