Política de Segurança da Informação

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 e verificável. A infraestrutura sobre a qual esses controles rodam, e as certificações dela, estão na seção 13.

1. Responsabilidade compartilhada

A INGESTIA protege a Plataforma. O Cliente protege o que está do lado dele.

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, no momento em que o acesso começa;
• o Cliente é avisado automaticamente dentro do próprio ambiente: por sete dias após o acesso, uma faixa no topo da tela informa que a equipe entrou, quando, e quantas vezes. O aviso não depende de e-mail nem de qualquer configuração do Cliente;
• ele não é usado para finalidade diversa de suporte, operação e segurança da Plataforma.

O aviso é dado na tela do próprio ambiente, onde a entrega é certa, e fica na trilha de auditoria.

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. A recuperação é feita pelo Cliente no console de Dados, com consulta ao estado anterior, ou pelo suporte, a pedido.
• 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. Infraestrutura e certificações

A Plataforma roda na infraestrutura do Google Cloud, região São Paulo (BigQuery, Cloud Storage e Cloud Run para o datalake e o processamento), com a aplicação e o banco de metadados também no Brasil. A lista completa de fornecedores e regiões está na Lista de Subprocessadores.

• Controles físicos, de rede e de infraestrutura são os do Google Cloud, auditados por terceiros e certificados nas normas ISO/IEC 27001, 27017 e 27018 e nos relatórios SOC 1, SOC 2 e SOC 3. Os relatórios são obtidos diretamente com o provedor, no portal de conformidade do Google Cloud.
• Controles da Plataforma (identidade, papéis, isolamento entre clientes, cifragem de credenciais, auditoria, guardas de consulta e de IA) são os das seções 2 a 12, operados pela INGESTIA. As certificações acima são do provedor de infraestrutura; a INGESTIA responde pelos controles da Plataforma descritos neste documento.
• Nuvem própria: no modelo em que o datalake roda no projeto Google Cloud do cliente, os dados ficam sob a conta e as políticas dele, inclusive chaves, auditoria e retenção da própria nuvem.
• Chave de cifragem das credenciais: guardada como segredo protegido do ambiente de execução, separada do banco onde ficam as credenciais cifradas e inacessível pelo navegador. A rotação é feita por procedimento operacional que recifra todas as credenciais.
• Teste de intrusão pelo cliente: autorizado mediante pedido prévio, conforme a seção 12.

14. Contato

Segurança: seguranca@ingestia.io · Privacidade e titulares: privacidade@ingestia.io · Encarregado: Encarregado de Dados (DPO) — encarregado@ingestia.io