Este documento describe los controles de seguridad que UDISOFTBOX CONSULTORIA E TECNOLOGIA LTDA ("INGESTIA") mantiene en la plataforma ingestia.io. Existe para ser leído por quien evalúa un proveedor —equipo de seguridad, jurídico, compras— y por cualquier cliente que quiera saber cómo se protegen sus datos.
Cada medida de abajo corresponde a un control implementado. Nada de esto es aspiración: lo que todavía no existe está en la sección 13, con nombre.
1. Responsabilidad compartida
INGESTIA protege la Plataforma. El Cliente protege lo que está de su lado.
| Responsabilidad de INGESTIA | Responsabilidad del Cliente |
|---|---|
| Aislamiento entre entornos de clientes | Quién recibe acceso al entorno, y con qué papel |
| Cifrado de las credenciales que el Cliente registra | Fuerza de las contraseñas y activación del segundo factor por sus usuarios |
| Traza de auditoría de las acciones en la Plataforma | Revisar esa traza y actuar sobre lo que ve |
| Disponibilidad y recuperación de la Plataforma | Seguridad de las fuentes de datos, redes y dispositivos propios |
| Barreras de costo y de consulta | Decidir qué dato entra en la Plataforma, y si puede entrar |
Un control de la Plataforma no sustituye la seguridad del origen. Una fuente expuesta sigue expuesta después de conectarse.
2. Acceso, identidad y papeles
- La contraseña se almacena como derivación criptográfica (scrypt), nunca en texto legible. INGESTIA no tiene forma de leer la contraseña de nadie.
- El segundo factor (MFA) por aplicación autenticadora (TOTP) está disponible para cualquier cuenta. Al activarlo, el código se exige también en el acceso por contraseña — activarlo es decisión del usuario o del administrador del entorno.
- Acceso único (SSO) por la cuenta udiApps, para quien ya usa el ecosistema.
- Aprovisionamiento automático (SCIM 2.0) para clientes que gestionan usuarios por directorio corporativo: crear, actualizar y desactivar usuario sin pasar por nuestra mesa.
- Papeles y permisos: cinco papeles (propietario, administrador, miembro, lector y administrador de organización) sobre una lista cerrada de 32 acciones. El papel de lector no ejecuta, no exporta y no gasta; la verificación se hace en el servidor, en cada acción, y no en la pantalla.
3. Aislamiento entre clientes
Es el control que más importa en un producto de datos, y por eso es el más explícito:
- cada cliente tiene conjuntos de datos propios en el almacén analítico, con nombres derivados de un prefijo exclusivo;
- los permisos de infraestructura están limitados a ese prefijo;
- una consulta que intente alcanzar una dirección fuera del prefijo autorizado se rechaza antes de ejecutarse — no se filtra después;
- la caché de resultados está segregada por cliente: la respuesta de un entorno no se sirve a otro;
- el destino de cada consulta no viene del pedido del navegador, sino del panel o del modelo que la originó — un pedido no elige de qué entorno leer.
4. Cifrado
- En tránsito: TLS en todo el acceso a la Plataforma y a nuestras interfaces de programación.
- En reposo, en las credenciales: todo lo que el Cliente registra como secreto — contraseña de base de origen, clave de servicio, token de API y la clave de IA propia del Cliente — se cifra con AES-256-GCM antes de llegar a la base. La clave de cifrado vive en una variable de entorno del servidor y no es accesible desde el navegador.
- El secreto no vuelve. La interfaz nunca vuelve a mostrar un secreto registrado: muestra, como máximo, los cuatro últimos caracteres para reconocimiento. El secreto tampoco se escribe en registros de ejecución.
- En reposo, en los datos de negocio: cifrado gestionado por la infraestructura de almacenamiento, conforme a la Lista de Subencargados.
5. Traza de auditoría
Toda acción relevante en la Plataforma se registra con autor, acción, recurso, momento y — cuando corresponde — el SQL ejecutado y el costo de esa ejecución. La traza es visible al Cliente dentro de su propio entorno y se guarda por 730 días, conforme a la Política de Retención de Datos.
La presencia del SQL en la traza tiene consecuencia de privacidad y está declarada: una consulta puede contener un valor de filtro que sea dato personal. Está descrito en la Política de Privacidad, y por eso la traza tiene plazo y purga automática.
6. Acceso administrativo de INGESTIA
Decir "acceso restringido" sin decir qué alcanza no informa nada. Entonces:
- el equipo de INGESTIA cuenta con un mecanismo de acceso administrativo que permite abrir el entorno de un cliente para dar soporte y diagnosticar un problema;
- está limitado a cuentas de superadministrador, controladas por variable de entorno del servidor — no se concede por pantalla ni por invitación;
- su uso queda registrado en la traza de auditoría;
- no se usa para finalidad distinta de soporte, operación y seguridad de la Plataforma.
Lo que todavía no existe: notificación automática al Cliente cuando ese acceso ocurre. Está en la sección 13.
7. Resiliencia y recuperación
- Almacén analítico: recuperación de un estado anterior por siete días (time travel), lo que cubre borrado o transformación equivocada hecha por el propio Cliente.
- Zona de entrada de los archivos: versionado de objetos — sobrescribir no destruye la versión anterior.
- Base de metadatos: copia de seguridad y recuperación a un punto en el tiempo, por el servicio gestionado descrito en la Lista de Subencargados.
- Verificación de salud: la Plataforma expone una verificación profunda que reporta el estado real de cada capacidad. En producción, un camino sin credencial configurada falla de forma visible en lugar de simular éxito — es una regla de arquitectura, con traba en prueba automatizada.
8. Barreras de ejecución
- Techo de costo por consulta: la ejecución se rechaza por el motor cuando superaría el volumen máximo de datos autorizado, antes de generar costo.
- Parámetros nombrados en la generación de SQL — defensa contra inyección por valor de filtro.
- Límite de tasa en los puntos sensibles (autenticación, formularios públicos, interfaces de integración), distribuido entre instancias.
- Encabezados de seguridad del navegador, incluida política de contenido (CSP) por área de la aplicación y restricción de encuadre en marco.
9. Desarrollo y cambio
- Todo el código de la Plataforma está cubierto por una suite automatizada ejecutada antes de cada publicación, con trabas específicas para las reglas que ya causaron perjuicio — entre ellas el congelamiento byte a byte de las salidas del motor de consulta y la prohibición de cualquier camino que simule éxito en producción.
- El cambio de esquema de base de datos es aditivo y versionado en una migración.
- Los formatos guardados por el Cliente (panel, filtro, tema) usan sobre versionado con lectura obligatoria de la versión anterior: una actualización nuestra no destruye su configuración.
10. Proveedores
El papel, la finalidad, los datos involucrados y el país de cada proveedor constan en la Lista de Subencargados, mantenida pública y actualizada. Un proveedor material nuevo se informa con al menos 15 días de antelación, conforme al Acuerdo de Tratamiento de Datos (DPA).
Cuando el Cliente registra clave de IA propia, el proveedor de IA atendido por ella no es subencargado de INGESTIA: la contratación y la política de retención de prompts son entre el Cliente y ese proveedor.
11. Incidentes de seguridad
Confirmado un incidente que involucre datos personales del Cliente, INGESTIA notifica sin demora injustificada y, siempre que sea viable, en hasta 24 horas, con lo que esté disponible: naturaleza, categorías y volumen estimado, titulares afectados, contención, riesgos y punto de contacto — y actualiza conforme avanza la investigación.
La comunicación a la autoridad brasileña de protección de datos (ANPD) y a los titulares es decisión del Cliente, en su condición de responsable, observado el plazo regulatorio vigente. INGESTIA apoya la investigación y la comunicación.
12. Prueba de intrusión y reporte de fallas
La prueba de intrusión, el escaneo o la prueba de carga contra la Plataforma exigen autorización escrita previa — pedidos a seguranca@ingestia.io.
Quien encuentre una falla de buena fe debe informarla por el mismo canal. INGESTIA no trata un reporte de buena fe como violación de la Política de Uso Aceptable. El procedimiento y el compromiso están en la Política de Divulgación de Vulnerabilidades.
13. Lo que este documento NO afirma
Esta sección existe porque un documento de seguridad que solo enumera virtudes no es información, es publicidad — y porque afirmar una certificación que no se tiene es, además de todo, una declaración falsa.
- INGESTIA no posee certificación ISO/IEC 27001, SOC 2 ni equivalente. Ningún material nuestro afirma poseerla.
- No hay informe de prueba de intrusión independiente disponible para compartir en esta fecha.
- El acceso administrativo descrito en la sección 6 no genera notificación automática al Cliente. Está auditado; el Cliente necesita consultar la traza.
- No hay porcentaje de disponibilidad comprometido en contrato. Lo que existe es plazo de atención y objetivos internos, descritos en el documento de Nivel de Servicio (SLA) — y la razón de no haber porcentaje está escrita allí: no hay serie de medición persistida que lo sustente.
- El cifrado de credenciales en reposo usa una clave en variable de entorno, no un servicio gestionado de custodia de claves con rotación automática.
Cuando cualquiera de los puntos anteriores cambie, sale de esta sección y entra en la correspondiente, en la misma fecha en que el control pase a existir.
14. Contacto
Seguridad: seguranca@ingestia.io · Privacidad y titulares: privacidade@ingestia.io · Encargado de datos: Encarregado de Dados (DPO) — encarregado@ingestia.io