🔒
Credenciales del lado del servidor
Los tokens y las claves de los servicios que integrás no se exponen en el navegador: los llamados salen del servidor.
Producto
Seguridad
Cómo se protegen las credenciales, los servicios publicados y el acceso a la aplicación.
🎫
Token en cabecera
Los servicios desplegados exigen su token de consumo por cabecera, nunca por la URL, para que no quede en los access logs.
👥
Aislamiento por usuario
Los flujos llevan dueño y no se cruzan entre usuarios, ni desde la aplicación ni desde el servidor MCP.
📝
Registro auditable
Cada corrida deja su rastro: qué nodo llamó a dónde, qué respondió y cuánto tardó.
🏠
Tu infraestructura, o gestionada
On-premise: se instala donde digas y los datos no salen de tu red. Gestionada: IVZ Global opera la plataforma por vos, con acceso y respaldo acordados.
🚦
Superficie mínima
Las operaciones administrativas exigen sesión; público queda solo el contrato que consume el otro sistema.
Dónde viven los datos
Hay dos modalidades. On-premise: IVZ Integrator se instala en tu infraestructura; los flujos, las credenciales y el registro de corridas quedan en tu servidor —en SQL Server o en archivos, según cómo lo configures— y los llamados salen desde ahí hacia los destinos que definas, sin un servicio nuestro en el medio. Gestionada por IVZ Global: nosotros operamos la plataforma por vos; dónde viven los datos, quién accede y cómo se respalda se acuerda por contrato.
Acceso a la aplicación
Todo lo administrativo exige sesión iniciada: listar y abrir flujos, publicarlos, borrarlos, ver registros, administrar usuarios y tocar la configuración. Sin sesión, esas operaciones responden 401.
Quedan abiertas a propósito solo las rutas que forman el contrato público de un servicio publicado —ejecutarlo, su SOAP, su Swagger y su WSDL—, porque son las que consume el sistema del otro lado. Ese es el punto que se protege con el token de consumo.
Aislamiento entre usuarios
Cada flujo queda sellado con su dueño. Un usuario no ve, ni abre, ni borra los flujos de otro: un identificador ajeno se comporta como inexistente. El lienzo de trabajo también es por usuario y lo sigue de un navegador a otro.
Servicios desplegados
Cuando un flujo se despliega como contenedor aparte, se le generan dos secretos distintos:
- Token de consumo — quien invoque el servicio debe presentarlo en la cabecera
X-Ivz-Consumo. Solo por cabecera, nunca en la URL, para que no quede escrito en los registros de acceso del servidor. Sin él, la ejecución responde 401. - Token de control — habilita las acciones de administración remota desde el Monitor. Nunca viaja al navegador.
Las rutas de diagnóstico (versión y estado de vida) quedan abiertas para poder monitorear el servicio sin repartir secretos.
Operación por IA
El servidor MCP siempre exige un token, y ese token identifica al usuario: un asistente actúa sobre el contexto de esa persona y nada más. No existe el acceso anónimo.
La integración con Amanda sigue la misma regla en la otra dirección: el token de canal que la vincula es un secreto de servidor —se guarda en el servidor, viaja solo entre servidores por HTTPS y al navegador vuelve únicamente enmascarado—. El nodo IA también lo resuelve del lado del servidor: en el flujo queda la URL del punto MCP, nunca la credencial.
Buenas prácticas al instalar. Cambiar la contraseña del usuario administrador antes de
exponer el sitio, publicarlo detrás de HTTPS y restringir por red lo que no necesite ser público.
¿Necesitás una revisión más a fondo?
Podemos repasar el modelo de seguridad con tu equipo de sistemas antes de una instalación.