Rumbleo | Security Overview | Arquitectura y controles

Security overview

Última actualización del documento: 4 de mayo de 2026

Resumen claro de la arquitectura, controles técnicos y límites actuales de Rumbleo para revisiones de seguridad B2B

Este resumen describe el diseño y controles públicos de Rumbleo a la fecha indicada. No sustituye anexos contractuales ni auditorías independientes

Resumen ejecutivo

1.1Rumbleo está diseñado para que organizaciones consulten datos internos mediante lenguaje natural sin entregar acceso directo a la base analítica a proveedores de IA o usuarios finales

1.2La plataforma gobierna identidad, tenant, permisos, modelo semántico, policy engine, validación de consultas, ejecución segura, auditoría, artefactos y consumo. El agente puede razonar y solicitar información autorizada, pero la plataforma conserva el control de acceso y ejecución

Arquitectura de despliegue

2.1Webapp pública desplegada como servicio separado
2.2Orquestador interno para gobierno, semántica, ejecución analítica, auditoría, almacenamiento y límites
2.3Servidor MCP público opcional para conectar clientes compatibles como ChatGPT, Claude, Codex u otros asistentes
2.4Servicios desplegados en AWS ECS Fargate detrás de un Application Load Balancer cuando se usa la infraestructura CDK del proyecto
2.5Servicios backend en subredes privadas con salida controlada, comunicación interna por Cloud Map y acceso al almacén analítico mediante rutas autorizadas
2.6Base de datos de plataforma en PostgreSQL/RDS o conexión equivalente gestionada por el entorno
2.7Almacenamiento de artefactos en bucket S3 con bloqueo de acceso público y cifrado gestionado por S3

Identidad, autenticación y roles

3.1Autenticación mediante AWS Cognito en la infraestructura CDK actual
3.2Self sign-up deshabilitado: los usuarios son invitados o gestionados por administradores autorizados
3.3Política de contraseña con longitud mínima de 12 caracteres y requisitos de mayúsculas, minúsculas, dígitos y símbolos
3.4Tokens de acceso e identidad con validez limitada y refresh tokens con caducidad definida
3.5Roles funcionales: analista, admin de tenant y admin interno de plataforma
3.6El tenant, usuario y rol se resuelven desde la sesión/autenticación y no se aceptan como verdad desde inputs controlables por el cliente

Aislamiento por tenant

4.1Cada tenant representa una única empresa cliente
4.2El modelo semántico, agentes, usuarios, límites, historial y configuración se asocian al tenant
4.3Las rutas y tools deben validar autenticación, autorización, tenant activo y rol antes de acceder a datos o ejecutar acciones
4.4Los usuarios de un tenant pueden consultar los datos disponibles para ese tenant, pero no los de otros tenants
4.5Los administradores de tenant no pueden ver conversaciones, respuestas, queries ni datos concretos de otros usuarios; solo estadísticas agregadas de uso

Acceso a datos analíticos

5.1Las bases analíticas de clientes se consultan en modo solo lectura
5.2Los agentes externos no reciben credenciales de base de datos, no abren conexiones directas y no deciden su propio tenant o rol
5.3Las consultas analíticas pasan por validación de lectura antes de ejecutarse
5.4La validación bloquea operaciones de escritura, DDL, comandos administrativos y patrones incompatibles con el modo de lectura
5.5La plataforma aplica límites de filas, timeout y control de consumo por tenant
5.6Las queries generadas no se muestran al usuario final, aunque pueden quedar guardadas para auditoría interna autorizada

Cifrado y secretos

6.1Todo tráfico público debe operar sobre HTTPS en entornos desplegados con dominio y certificado configurados
6.2Los artefactos en S3 se almacenan con cifrado en reposo gestionado por S3 y con acceso público bloqueado
6.3Las credenciales analíticas se cifran en entornos desplegados mediante envelope encryption con AWS KMS
6.4La clave KMS se crea por CDK con rotación habilitada y permisos restringidos al rol runtime del orquestador
6.5El frontend y el servidor MCP no tienen permiso directo para descifrar credenciales analíticas
6.6Los secretos operativos de plataforma se referencian desde AWS SSM Parameter Store SecureString en la infraestructura CDK
6.7Las credenciales OpenAI por tenant, cuando se configuran, siguen el mismo patrón de secreto recuperable por el orquestador y no se exponen al frontend

IA, prompts y proveedores de modelos

7.1Rumbleo no comparte conversaciones, resultados, adjuntos, modelo semántico ni datos de cliente con proveedores de IA para entrenamiento de modelos
7.2Rumbleo puede usar OpenAI para funcionalidad conversacional cuando existe clave configurada, bajo condiciones API/empresariales de no entrenamiento por defecto salvo opt-in explícito
7.3Algunos tenants pueden aportar su propia clave OpenAI para flujos donde Rumbleo invoca directamente al proveedor LLM y mantener control contractual propio
7.4En modo MCP con Analítica Externa Gobernada, el host externo ejecuta su propio modelo y llama a tools de Rumbleo; Rumbleo no necesita entregar credenciales analíticas al host
7.5Las credenciales, cadenas de conexión, acceso directo a bases analíticas y permisos internos nunca se entregan al proveedor de IA
7.6Los prompts, preguntas, resultados y adjuntos se tratan como información confidencial del cliente y se minimizan según la funcionalidad usada
7.7El producto está diseñado para pedir aclaraciones cuando falte contexto o haya ambigüedad, en lugar de inventar decisiones de negocio

Logging, auditoría y monitorización

8.1La plataforma registra eventos funcionales y técnicos necesarios para operar, proteger y mejorar el servicio
8.2La auditoría puede incluir tenant, usuario, rol, canal, agente, pregunta, conversación, modelo semántico consultado, métricas, dimensiones, plan analítico, tablas o entidades usadas, query generada, resultado, artefactos, respuesta, estado, errores, duración y consumo
8.3En MCP y analítica externa gobernada se auditan tool calls, argumentos, host externo, resultados devueltos, queries internas, filas, truncados, bloqueos por política y errores
8.4Los logs de servicios AWS se envían a CloudWatch Logs con retención diferenciada por entorno en la infraestructura CDK
8.5El acceso a auditoría completa queda reservado a admins internos autorizados para soporte, seguridad, calidad o investigación de errores

Frontera de datos y minimización

9.1Rumbleo separa datos de identidad, metadatos de auditoría, modelo semántico, credenciales analíticas, resultados de consulta y artefactos generados para que cada capa acceda solo a lo que necesita
9.2Las credenciales de base de datos y los parámetros de conexión no se envían al navegador, al servidor MCP ni a proveedores de IA
9.3El modelo semántico se usa para interpretar métricas, dimensiones y reglas de negocio, pero se trata como información confidencial del tenant
9.4Los resultados analíticos devueltos a la experiencia conversacional deben estar limitados por permisos, tenant, límites de filas, timeout y configuración del servicio
9.5Cuando una funcionalidad requiere llamar a un proveedor LLM, la plataforma debe evitar enviar secretos, conexiones, credenciales, SQL administrativo o información innecesaria para la respuesta

Seguridad de aplicación

10.1Las rutas de aplicación y APIs deben resolver usuario, tenant y rol desde la sesión autenticada antes de ejecutar acciones
10.2Las entradas controlables por el cliente no se aceptan como fuente de verdad para tenant, usuario, rol, permisos o alcance de datos
10.3Las operaciones administrativas deben validar permisos y registrar trazabilidad suficiente para soporte y seguridad
10.4Las consultas analíticas pasan por validación de solo lectura antes de tocar fuentes de datos conectadas
10.5Los errores user-facing deben evitar exponer credenciales, queries internas, trazas, nombres sensibles de infraestructura o detalles que faciliten abuso

Acceso interno y operaciones

11.1El acceso interno a auditoría completa se reserva a personal autorizado y solo para soporte, seguridad, calidad, investigación de errores o cumplimiento contractual
11.2Los admins de tenant pueden ver consumo y estadísticas agregadas, pero no contenido de conversaciones, respuestas, queries o datos concretos de otros usuarios
11.3Los cambios de infraestructura deben aplicarse desde CDK como fuente de verdad y no desde consolas cloud manuales
11.4Los secretos de runtime se gestionan mediante servicios de secretos o parámetros seguros y no deben copiarse a código, logs o archivos versionados
11.5La separación entre webapp, orquestador y MCP reduce exposición directa de datos y mantiene el gobierno analítico dentro del backend

Gestión de vulnerabilidades y evidencias

12.1El repositorio mantiene pruebas automatizadas para invariantes críticos de aislamiento por tenant, SQL solo lectura, auditoría, consumo y acceso a modelos semánticos y artefactos
12.2Los cambios que afecten autenticación, autorización, tenant, uso, auditoría, acceso analítico o almacenamiento deben acompañarse de revisión y pruebas proporcionales al riesgo
12.3Las dependencias, imágenes y servicios de terceros deben revisarse cuando haya actualizaciones relevantes o avisos de seguridad aplicables
12.4Para auditorías de cliente se pueden preparar evidencias adicionales, como configuración cloud, capturas de controles, resultados de pruebas, runbooks o respuestas a cuestionarios
12.5Las certificaciones formales solo se declararán cuando exista un certificado vigente o una auditoría independiente completada

Backups, continuidad y restauración

13.1Los artefactos de producción en S3 están configurados con versionado cuando se usa el stack CDK de producción
13.2La base de datos de plataforma depende de la configuración del entorno RDS o PostgreSQL utilizado por el despliegue
13.3El runbook de backups, restauración y pruebas periódicas de restore debe cerrarse contractualmente o como evidencia operativa antes de tratar datos críticos de cliente
13.4La infraestructura documenta como trabajo pendiente alarmas CloudWatch, WAF, estrategia de rotación y runbooks de recuperación para endurecimiento productivo

Gestión de cambios y despliegue

14.1La infraestructura se define en CDK y no debe modificarse manualmente en consolas cloud como fuente de verdad
14.2Las migraciones SQL son forward-only y se registran con checksums para evitar cambios silenciosos en migraciones aplicadas
14.3El pipeline de producción usa GitHub Actions, imágenes runtime versionadas y despliegue mediante ramas de release
14.4Las pruebas de integración cubren invariantes críticos de tenant, SQL solo lectura, auditoría, consumo y acceso a modelo semántico/artefactos

Roadmap de endurecimiento

15.1WAF en el Application Load Balancer
15.2Alarmas CloudWatch para 5xx, health checks, reinicios ECS, CPU, memoria y errores de logs
15.3Runbook formal de backups y restauración con pruebas periódicas
15.4Estrategia de rotación de credenciales de plataforma, OpenAI y secretos de sesión
15.5Revisión de residencia, retención y borrado por tipo de dato
15.6Evaluación formal de SOC 2, ISO 27001 o Vanta cuando el volumen de clientes lo justifique

Seguridad, arquitectura y controles de Rumbleo