Arquitectura e instalación de Monopam
Qué ha cambiado
Cada actualización del contenido se versiona. Seleccione una versión para compararla con la anterior.
Versión 1 → 2
Actualización4 lecciones actualizadasduración
Actualización de contenido. Se notificó a los estudiantes inscritos.
La duración cambió de 11 a 15 minutos.
Monopam no guarda contraseñas locales. El usuario es enviado al proveedor de identidad configurado para el inquilino, normalmente Monosign, y vuelve con un resultado firmado que Monopam guarda en una cookie de autenticación. Esa única decisión de diseño responde a varias preguntas de planificación a la vez.
| Pregunta | Respuesta | Por qué |
| --- | --- | --- |
| ¿Dónde exigimos la MFA? | En el proveedor de identidad | Monopam no tiene MFA propia. Las credenciales y la MFA son tarea del proveedor, así que las políticas de acceso de Monosign también se aplican a los usuarios privilegiados |
| ¿De dónde salen los grupos y permisos? | Del proveedor, dentro de la cookie de autenticación | Monopam los lee de la cookie en cada petición |
| ¿Por qué un cambio de rol aún no se aplica? | El usuario debe iniciar sesión de nuevo | La cookie todavía lleva los grupos antiguos |
::diagram pam-signin-path
### La trampa del proxy
Como los grupos y permisos viajan en la cookie, la respuesta que cierra el inicio de sesión es grande y crece con cada grupo del usuario. Un proxy inverso con búferes pequeños para las cabeceras de respuesta rechaza esa respuesta.
Un caso típico: una empresa coloca nginx delante de Monopam. La mayoría entra sin problemas. El equipo de plataforma, miembro de decenas de grupos, recibe `502 Bad Gateway` al volver de Monosign, y el registro de nginx dice `upstream sent too big header`. Sus cuentas están bien. La solución es ampliar los búferes de cabeceras de respuesta (en nginx, `proxy_buffer_size` y `proxy_buffers`) en **cada** salto de proxy delante de Monopam. Un solo salto olvidado basta para romper el inicio de sesión, y solo para los usuarios con muchos grupos, por lo que parece un problema de permisos.
> TipConsejo: si el inicio de sesión falla solo para usuarios muy privilegiados, revise los proxies antes que las políticas.
### El uso de licencias pasa por Monosign
Monopam nunca llama por sí mismo a los servicios de Monofor. Cada 15 minutos cuenta los módulos licenciados de cada inquilino y envía solo los números, sin nombres ni contenidos, al Monosign del inquilino. Monosign los añade a su propio latido de licencia. La clave de API REST de Monosign que usa Monopam necesita el permiso `System.API.System.Usage`. Una instalación actualizada desde una versión anterior sigue funcionando sin él, pero no informa de nada: el registro de Monopam muestra `License usage could not be reported to Monosign` y el portal de licencias no muestra uso de Monopam hasta que se concede el permiso.
### Qué comprobar primero
| Síntoma | Compruebe primero |
| --- | --- |
| `502 Bad Gateway` al volver de Monosign, solo en usuarios con muchos grupos | Los búferes de cabeceras de respuesta en cada salto de proxy |
| Un rol o grupo nuevo no se aplica | Si el usuario ha vuelto a iniciar sesión desde el cambio |
| El portal de licencias no muestra uso de Monopam | El permiso `System.API.System.Usage` en la clave de la API REST de Monosign y la línea de registro `License usage could not be reported to Monosign` |
El servidor web de Monopam no abre sesiones hacia los destinos. Eso lo hace un **gateway**: se sitúa donde puede alcanzar los destinos y lleva la sesión de vuelta a Monopam. Por eso, cuando los servidores de producción viven en un segmento aislado, no se abren puertos ni una VPN hacia el segmento. Se despliega un gateway que lo alcance y las sesiones pasan por él. La segmentación se mantiene y cada sesión sigue intermediada y grabada.
::diagram pam-gateway-path
### Sitios: enrutamiento según la ubicación
Un **sitio** es una ubicación como una planta, una sucursal o un centro de datos. Los gateways y los recursos se asignan a él (`Site` en el gateway, `Advanced` > `Site` en el recurso). Los sitios son opcionales: una instalación que nunca crea uno se comporta como antes. El valor por defecto es `Unassigned`.
Monopam elige el gateway de una conexión en un orden estricto:
| Orden | Regla | Resultado |
| --- | --- | --- |
| 1 | Hay un gateway seleccionado de forma explícita en el recurso o en la política | Esa selección siempre gana |
| 2 | El recurso está asignado a un sitio que tiene gateways | Solo se usan los gateways del sitio |
| 3 | Ninguna de las dos | Cualquier gateway activo |
::diagram pam-gateway-order
De esta tabla salen directamente dos incidentes.
**"Gateway not found" tras ordenar.** Un equipo crea el sitio "Planta Bursa", asigna el gateway de la planta y mueve cuarenta recursos al sitio. Hasta entonces esos recursos podían usar cualquier gateway activo. Ahora solo pueden usar los del sitio. Si ese gateway está inactivo o no es del tipo de conexión necesario, todas las conexiones fallan con `Gateway not found`. La insignia `Gateways` de la lista `Sites` muestra el número de gateways activos y se pone ámbar en cero. Los sitios nunca deciden quién puede conectarse, solo qué gateway se usa.
**Un recurso que ignora su sitio.** Un servidor está asignado al sitio Estambul, cuyos gateways están sanos, pero sus sesiones van por Ankara. La regla 1 lo explica: un gateway seleccionado hace tiempo en el recurso o en su política sigue ganando. Quite la selección explícita y el sitio toma el control.
### Un detalle para los recursos de base de datos
Los usuarios del proxy de base de datos conectan su cliente al puerto del proxy en el gateway, que muestra la ventana de conexión. El campo `Port` del recurso de base de datos es otra cosa: es el puerto propio de la base de datos (5432 en PostgreSQL), que el proxy usa para llegar al backend. Si se pone ahí el puerto del proxy, el proxy se llama a sí mismo y las conexiones fallan.
> Consejo: cuando una conexión falla con `Gateway not found`, recorra el orden desde arriba. ¿Hay un gateway seleccionado de forma explícita en el recurso o en su política? ¿Está el recurso en un sitio? ¿Muestra la insignia `Gateways` de ese sitio un gateway activo, y es del tipo de conexión necesario?
Una instalación de Monopam es **una base de datos, un Redis y una clave de vault**. Aun así puede ejecutarse en varios servidores de aplicación. Un proveedor de servicios, por ejemplo, mantiene un servidor principal para la mayoría de sus clientes y añade uno dedicado para un cliente grande. El inquilino de una petición se deduce únicamente del nombre de host de la petición, y una sesión iniciada queda ligada al inquilino para el que se emitió.
Cada servidor de aplicación tiene dos listas independientes en su entorno:
| Ajuste | Decide | Si está mal |
| --- | --- | --- |
| `MONOPAM_SERVED_TENANTS` | A qué inquilinos responde este servidor en la web | Un host que corresponde a un inquilino fuera de la lista recibe una página que dice que el inquilino no se sirve desde este servidor |
| `MONOPAM_JOB_TENANTS` | Para qué inquilinos ejecuta este servidor los trabajos en segundo plano: rotación, alertas, sincronizaciones, actualizaciones de agentes | Un inquilino en dos servidores ejecuta sus trabajos dos veces. Los de un inquilino en ningún servidor esperan en la cola |
| `MONOPAM_VAULT_KEY` | La clave que descifra los datos del vault | Un servidor con otra clave no puede descifrar y las conexiones fallan |
::diagram pam-multi-server
Las dos primeras están separadas a propósito. Servir a un inquilino no implica ejecutar sus trabajos, ni al revés.
### Ejemplo
El proveedor añade el servidor B para el inquilino "acme" y apunta a él el DNS de acme.
1. Los usuarios ven "Tenant 'acme' is not served by this server." La base de datos y Redis están sanos. El servidor B no incluye acme en `MONOPAM_SERVED_TENANTS`. Añádalo.
2. Una semana después las contraseñas de acme rotan dos veces y sus correos de alerta llegan duplicados. El servidor A todavía incluye acme en `MONOPAM_JOB_TENANTS` y el servidor B ahora también. Los trabajos de un inquilino pertenecen a **exactamente un** servidor. Quítelo de uno de ellos.
3. Ambos servidores, y todos los gateways, deben tener el mismo `MONOPAM_VAULT_KEY` y alcanzar el mismo Redis. Lo que cambia por servidor son las dos listas de inquilinos.
### Lo que una base de datos dedicada no aporta
A un inquilino se le puede dar su propia base de datos. A veces los clientes lo interpretan como un muro de seguridad entre sus datos y los demás servidores de aplicación de la instalación. No lo es: la clave de vault y el plano de control son compartidos por toda la instalación. Dígalo con claridad. Quien necesite esa separación necesita una instalación aparte.
### Qué comprobar primero
| Síntoma | Compruebe primero |
| --- | --- |
| La página dice que este servidor no sirve al inquilino | `MONOPAM_SERVED_TENANTS` en el servidor al que apunta el nombre de host |
| Las rotaciones o los correos de alerta ocurren dos veces | `MONOPAM_JOB_TENANTS` en cada servidor: el inquilino figura en dos |
| Los trabajos de un inquilino esperan en la cola | `MONOPAM_JOB_TENANTS`: el inquilino no figura en ningún servidor |
| Las conexiones fallan solo por un servidor o gateway | `MONOPAM_VAULT_KEY` allí difiere del resto |
El agente de Monofor se ejecuta en un host Windows, Linux o macOS y atiende operaciones locales como el descubrimiento de cuentas y la ejecución de scripts. Cuatro momentos de su vida requieren el criterio de un administrador.
::diagram pam-agent-lifecycle
### 1. Inscripción
`Import Resource with Agent` genera un script de instalación de una línea con una **clave de configuración** incluida. La clave vale 24 horas y puede inscribir muchas máquinas. Quien tenga el script y alcance Monopam puede inscribir una máquina en su inquilino hasta que la clave caduque, así que trate el script como una credencial: entréguelo a quien hace la instalación, no lo deje en una wiki y genere uno nuevo la próxima vez.
### 2. Conectividad
| Vía | Dirección | Cuándo |
| --- | --- | --- |
| Agent Channel | El agente llama a Monopam y mantiene la conexión abierta. Monopam envía las peticiones por ella | Siempre preferida. Funciona detrás de NAT y sin regla de firewall de entrada |
| Escucha entrante | Un gateway llama al agente | Alternativa, solo donde un gateway alcanza el host |
La columna `Connection` de la página `Agents` muestra `Channel` o `Inbound` según el estado en ese momento.
### 3. Confianza
Cada petición de Monopam a un agente va firmada. El agente fijó la clave pública de Monopam al inscribirse y comprueba cada firma, una marca de tiempo y un número de un solo uso, de modo que una clave de API de agente robada no basta para manejar un agente. Dos consecuencias operativas:
- **Relojes.** Los relojes del agente y del servidor deben diferir como mucho 300 segundos. Si un agente recién inscrito responde 401 a todo aunque la inscripción funcionó, compruebe primero la sincronización horaria en ambos extremos.
- **Restauraciones.** La clave privada de firma de Monopam está protegida por la clave de protección de datos de la aplicación. Si restaura Monopam en un host nuevo sin esa clave, la clave de firma no se puede leer, se genera una nueva y todos los agentes la rechazan hasta que se inscriben de nuevo. Incluya la clave de protección de datos en su plan de copias.
### 4. Actualizaciones
`Update agent` en una fila, o `Update all agents`, indica a los agentes qué versión instalar. El agente descarga el paquete, verifica su suma de comprobación, sustituye su propio binario y se reinicia. La configuración y la inscripción no se tocan, y nada se actualiza por sí solo.
Planifique dos cosas. Una actualización de flota avanza a cinco agentes por inquilino cada 30 segundos, así que cien hosts tardan unos diez minutos. Y cada agente se reinicia unos segundos, por lo que una operación que pase por él en ese momento falla y debe reintentarse. Un agente con `"AllowUpdate": false` en su `config.json` se niega y lo indica en el resultado del trabajo: cambie el ajuste en el host o actualice con el instalador.
### Qué comprobar primero
| Síntoma | Compruebe primero |
| --- | --- |
| Un agente recién inscrito responde 401 a todo | La sincronización horaria en ambos extremos: los relojes deben estar dentro de 300 segundos |
| Tras restaurar en un host nuevo, todos los agentes rechazan a Monopam | La clave de protección de datos no se restauró y se generó una nueva clave de firma. Hay que inscribir de nuevo los agentes |
| Un agente rechaza `Update agent` | `"AllowUpdate": false` en su `config.json`. El resultado del trabajo lo indica |
| Una operación falló durante la actualización de la flota | El agente se estaba reiniciando en ese momento. Repita la operación |