Entrega de implementaciones de Monofor
Qué ha cambiado
Cada actualización del contenido se versiona. Seleccione una versión para compararla con la anterior.
Versión 8 → 9
ActualizaciónCuatro lecciones nuevas cubren las lagunas respecto al examen MCIP: control de cambios dentro de los productos, restricciones de diseño que debe encontrar el descubrimiento, salvaguardas para los primeros cambios en producción y evidencias de aceptación con tareas de operación. Cada comprobación de conocimientos tiene dos preguntas nuevas. Se añadieron diagramas a las lecciones nuevas.
4 lecciones actualizadas
Actualización de contenido. Se notificó a los estudiantes inscritos.
Un plan de cambio vale tanto como su idea de lo que hace el producto cuando alguien pulsa `Save`. Varios comportamientos del producto deciden si un plan cuidadoso se sostiene en la práctica. Esta lección reúne los más importantes durante la entrega, cada uno con el acuerdo de trabajo que exige.
### La decisión de seguir o parar es una comprobación, no una impresión
Antes de cada oleada, escriba criterios de salida medibles: tasa de registro, tasa de fallos de inicio de sesión, incidencias del servicio de asistencia por cada cien usuarios. Acuerde los umbrales antes de que empiece la oleada y pruebe la vuelta atrás antes de la reunión. Así el comité de dirección compara cifras con umbrales en lugar de intercambiar impresiones, y una decisión equivocada sale barata porque el camino de vuelta ya está probado.
### Monosync: el historial de cambios es un registro, no un deshacer
Cada guardado de una integración es un commit con un comentario y un número de ticket. `Show Commits` muestra quién cambió qué y enseña la diferencia. No tiene ningún control para restaurar.
| Comportamiento del producto | Acuerdo de trabajo |
| --- | --- |
| Dos personas editan la misma integración. El segundo guardado muestra `Integration Is Changed` y, tras `Overwrite`, sustituye el trabajo de la primera | Un solo editor por integración a la vez, un número de ticket en cada commit, revisión con `Show Commits` |
| Una versión anterior no se puede restaurar con un clic | El plan de cambio registra los valores anteriores para poder introducirlos de nuevo a mano |
| Los valores ya escritos en un sistema de destino permanecen allí | La vuelta atrás indica quién repara los datos del destino y cómo |
### Programaciones y ventanas de mantenimiento
Las programaciones son expresiones cron en **UTC**. Una programación nueva o editada en una integración activa suele ejecutarse una vez justo después de guardar, porque su siguiente hora de ejecución ya ha pasado. Por eso, "preparar" el viernes una programación para una ventana del sábado inicia una ejecución el viernes. Guarde los cambios de programación dentro de la ventana. Una integración nunca ejecuta dos trabajos al mismo tiempo.
Cuando un sistema de destino se detiene por mantenimiento, `Start Maintenance` pone en pausa las integraciones. Tres detalles deben figurar en el runbook:
- No espera a los trabajos en ejecución. Abra `Integration Jobs` y confirme que no hay nada en ejecución antes de detener el destino, o elija `Start Maintenance with stopping tasks.` para abortarlos.
- `Run Once` sigue funcionando en una integración en pausa. Indique a los operadores que no lo usen durante la ventana.
- Después de la ventana, las programaciones continúan desde el momento de la parada. Las ejecuciones perdidas durante la ventana no se recuperan.
### Monosign: tres cambios que no admiten piloto
**Actualizaciones.** Lea en las notas de la versión la ruta exacta. La actualización de v2026.07 a v2026.09 exige una parada completa de todos los nodos de aplicación y versiones idénticas del migrador, porque una flota mixta duplica trabajo y pierde invalidaciones de caché. En esa ruta no existe la actualización progresiva nodo a nodo, así que acuerde pronto una ventana con parada del servicio.
**Textos personalizados.** Un elemento de contenido editado, como el texto de una plantilla de correo, o una traducción editada sobrevive a una actualización solo mientras la versión distribuida de ese elemento no cambie. Cuando una versión del producto sube ese número, el texto predeterminado distribuido sustituye la edición en todos los tenants. La nota de la versión incluye una advertencia para esos elementos. Guarde una copia de cada personalización y reserve tiempo para volver a aplicarla.
**API Security.** El interruptor pertenece a la aplicación y afecta a todas las claves de esa aplicación a la vez. No se puede hacer un piloto con una sola clave. Enumere los endpoints que llama cada clave, conceda esos permisos en la pestaña `Permissions` de la clave y, después, active el interruptor en una ventana de cambio. "Funciona con la clave maestra" no es una prueba: una aplicación maestra supera comprobaciones para las que una clave normal necesita un permiso.
::diagram del-change-control
### Ejemplo práctico
Un partner va a cambiar un mapeo y mover la programación de una integración de producción el sábado a las 22:00. Un plan que respeta el producto es así:
1. Un único editor con nombre. Nadie más abre la integración esa noche.
2. Los valores anteriores del mapeo y el cron anterior se pegan en el ticket.
3. La programación se guarda a las 22:05, dentro de la ventana, y se espera una ejecución inmediata.
4. Criterio para seguir: ningún objeto fallido en esa primera ejecución. En caso contrario, los valores anteriores se introducen de nuevo a mano.
5. Un responsable con nombre en el sistema de destino repara los valores que ya se hayan escrito.
El dimensionamiento responde a la pregunta "qué tamaño". Algunos hallazgos del descubrimiento responden a otra: "¿funcionará siquiera?". Preguntarlo en un taller no cuesta nada, y descubrirlo después de la puesta en producción cuesta mucho. Añada estos cinco puntos a su plantilla de descubrimiento.
### 1. ¿Pueden los servidores de Monosign llegar al servicio de licencias?
Monosign contacta con regularidad con el servicio de licencias de Monofor, por defecto en `services.monofor.com`. Con la comprobación en línea activada, el inicio de sesión se rechaza cuando el último contacto correcto tiene más de 7 días. Por eso, una red de cliente sin ruta de salida necesita una licencia emitida con la comprobación en línea desactivada. La caducidad y la validación de hosts siguen aplicándose a esa licencia. Una licencia no se puede importar desde la interfaz, así que resuélvalo con su contacto de Monofor antes de firmar el diseño, no el día de la instalación.
### 2. ¿Qué tamaño tiene el directorio?
Una fuente de Active Directory o LDAP lee como máximo `Limit` objetos por ejecución (500000 por defecto) en páginas de `Page Size` (1000 por defecto). Un directorio mayor se sincroniza **parcialmente y sin ningún error**. Pida el número de objetos de cada directorio. Si la cifra está cerca del valor por defecto o lo supera, anote en el diseño que hay que subir `Limit` y que la primera sincronización se compara con el recuento del propio directorio.
### 3. ¿Qué hay entre los usuarios y Monopam?
Monopam no tiene contraseñas locales. Los usuarios inician sesión en el proveedor de identidad, normalmente Monosign, y Monopam guarda el resultado en una cookie que lleva los grupos y permisos del usuario. Eso hace que la respuesta del inicio de sesión sea grande. Cada proxy inverso y cada balanceador de carga del camino debe aceptar cabeceras de respuesta grandes. Basta un solo salto con los búferes por defecto para romper el inicio de sesión de los usuarios con muchos grupos, normalmente con `502 Bad Gateway`. Enumere cada salto y su responsable.
### 4. ¿Cómo funcionará Monosync con carga?
Monosync se distribuye como una sola imagen de contenedor. Dos variables de entorno deciden el rol de un nodo:
| Rol del nodo | Ajuste |
| --- | --- |
| Solo interfaz | `MONOSYNC_DISABLE_SERVICE=true` |
| Solo nodo de servicio (ejecutor de integraciones) | `MONOSYNC_DISABLE_UI=true` |
| Ambos roles | Ninguna de las dos variables definida |
Todos los nodos comparten **una** base de datos y **un** Redis autenticado, que guarda el estado de los trabajos y la elección del nodo maestro. Cuando muchas integraciones deben ejecutarse en paralelo mientras los operadores trabajan en la interfaz, separe los roles y añada nodos de servicio. No dé a los nodos instancias de Redis separadas, porque dejarían de coordinarse.
### 5. ¿Dónde se guardan las grabaciones de sesión?
Un Gateway de Monopam graba una sesión solo cuando tiene configuradas sus dos rutas de captura. Sin ellas sigue abriendo sesiones, pero sin grabarlas. Las rutas pertenecen al host del Gateway: a su archivo de configuración o, en un contenedor, a las variables de entorno `MONOPAM_GW_CAPTURE_TEMP_PATH` y `MONOPAM_GW_CAPTURE_VIDEO_PATH`. Si el tenant no tiene un CDN configurado, las grabaciones se quedan en el Gateway. Por eso, un Gateway en contenedor necesita volúmenes persistentes en ambas rutas, dimensionados para las grabaciones previstas. De lo contrario, las grabaciones desaparecen con el contenedor.
::diagram del-design-constraints
### Escenario
Un banco quiere que se grabe cada sesión privilegiada, ejecuta sus gateways como contenedores y bloquea el acceso saliente a internet. De ahí salen tres líneas de diseño antes de empezar a dimensionar:
| Hallazgo | Línea de diseño |
| --- | --- |
| Sin ruta al servicio de licencias | Una licencia con la comprobación en línea desactivada, solicitada al contacto de Monofor |
| Gateways en contenedor, la grabación es obligatoria | Volúmenes persistentes en las dos rutas de captura de cada Gateway |
| Dos proxies delante de Monopam | Búferes grandes para cabeceras de respuesta en ambos, con un responsable designado |
Ninguna de estas líneas cambia el número de servidores. Cada una detendría el proyecto en su primera semana de producción.
Las horas de más riesgo de un proyecto son los primeros cambios en un tenant en producción: la primera política aplicada, la primera sincronización de directorio, el primer certificado y el primer cambio de clave. Cada uno tiene una salvaguarda sencilla. Incluya las cuatro en el plan de puesta en marcha.
### Un camino de vuelta antes de exigir MFA
Una política de autenticación mal configurada puede dejar fuera a todo el mundo, incluidos los administradores. Antes de que una política se aplique a todos los usuarios, asegúrese de que existe una cuenta de administrador de emergencia que la política no pueda bloquear, y demuéstrelo: inicie sesión con ella ese mismo día, desde la red que usaría en un incidente. Las buenas prácticas generales para una cuenta así son:
- Es una cuenta identificada, documentada en el runbook y propiedad del cliente.
- Sus credenciales se guardan selladas, por ejemplo en un vault que registra cada retirada.
- Cada uso se revisa después.
Dejar a todos los administradores fuera de MFA no es lo mismo. Debilita las cuentas más poderosas todos los días para cubrir un solo día malo.
### Primera sincronización de un directorio grande: empiece por poco
Un error de mapeo se extiende a todos los usuarios que toca la sincronización. Por eso, mantenga pequeña la primera ejecución:
1. Apunte `User Base DN` a una OU piloto y pulse `Test`.
2. Ejecute la sincronización y compruebe a mano unos cuantos usuarios: atributos, pertenencia a grupos, estado.
3. Corrija mapeos y filtros mientras solo está afectado el grupo piloto.
4. Amplíe la base DN al alcance completo y compare el número sincronizado con el recuento del propio directorio.
No conecte ninguna automatización que deshabilite o elimine cuentas hasta haber superado el paso 4.
### Sustituir el certificado con `monofor cert install`
| Comportamiento | Qué significa para su plan |
| --- | --- |
| Comprueba que el certificado y la clave forman un par válido antes de cambiar nada | Un par de archivos incorrecto se rechaza y el sistema en ejecución no se toca |
| Restaura el certificado y la configuración anteriores si falla un paso posterior | Un intento fallido no requiere reinstalar |
| Un certificado caducado necesita `--allow-expired` instala un certificado que ya ha caducado | Use la opción solo a propósito, por ejemplo en un entorno de pruebas |
| `monofor status` avisa 30 días antes de la caducidad | Anote la fecha de caducidad y el responsable de la renovación en el traspaso |
### Clave del vault de Monopam: el orden importa
El anillo de claves del vault se lee del entorno cuando arranca un proceso. Un proceso en ejecución no detecta una variable modificada. El orden seguro es:
1. Defina la misma `MONOPAM_VAULT_KEY` y su versión en **todos** los procesos que leen secretos: Web, Gateway con sus proxies, Automator y RemoteSession.
2. Reinícielos todos.
3. Solo entonces ejecute el trabajo de recifrado.
Si el trabajo se ejecuta mientras el Gateway conserva el anillo de claves antiguo, Web reescribe filas que el Gateway no puede descifrar y todas las conexiones que pasan por él fallan. Además, no hay recuperación para una clave perdida, así que registre dónde se guarda y quién es su responsable, nunca la clave en sí.
::diagram del-commissioning-day
### Escenario
Un plan del día de puesta en marcha construido sobre estas salvaguardas:
| Hora | Paso | Prueba |
| --- | --- | --- |
| 09:00 | Inicio de sesión del administrador de emergencia probado | Persona designada, resultado anotado |
| 09:30 | Fuente de AD limitada a la OU piloto y sincronizada | 40 usuarios comprobados a mano |
| 11:00 | Certificado del cliente instalado | `monofor status` muestra la fila Certificate sin aviso |
| 13:00 | Clave del vault definida en cinco procesos, todos reiniciados, trabajo ejecutado | Una sesión RDP y una SSH abiertas a través del Gateway |
Cada línea tiene un nombre y una hora. Esa misma lista es su primera evidencia de aceptación.
La aceptación es el momento en que el cliente confirma que el alcance acordado funciona. El traspaso es el momento en que los operadores del cliente pasan a ser responsables de que siga funcionando. Ambos dependen de leer correctamente los registros del propio producto.
### Un UAT que demuestra algo
Un recorrido muestra actividad. Una prueba demuestra cobertura. Para la firma deben cumplirse tres cosas:
- Cada caso de prueba remite a un requisito del alcance acordado, y cada requisito tiene al menos un caso de prueba.
- Las personas del cliente ejecutan los casos, o los ejecutan junto con usted. Las pruebas hechas solo por el partner demuestran únicamente que el partner está satisfecho.
- Cada resultado se registra con fecha, persona que prueba, resultado y evidencia, como una fila de informe o una captura de pantalla.
| Requisito | Caso de prueba | Evidencia |
| --- | --- | --- |
| Asignar un grupo en Monosign añade al usuario al grupo de AD | Asignar un usuario piloto y esperar la escritura de vuelta | La fila en Reports → `Provisions` y su historial en `View Logs` |
::diagram del-uat-evidence
### Lea el informe de aprovisionamiento hasta el final
Reports → `Provisions` muestra las escrituras de vuelta de grupos de directorio y los aprovisionamientos de recursos, cada uno con su **último** intento. Una fila en estado `Provisioned` puede haber fallado varias veces antes de salir bien. El menú de fila `View Logs` abre cada intento con fecha, estado y mensaje. Úselo cuando un cliente pregunte si un aprovisionamiento tuvo errores por el camino. Conozca también el límite: el estado de los envíos SCIM no forma parte de este informe.
### Lo que falla en silencio
`Dead Letters`, en Management → System → Services, reúne notificaciones, trabajos de aprovisionamiento y webhooks que no llegaron a entregarse. **No se genera ninguna alerta por ellos.** Alguien tiene que abrir la página. Por eso el runbook designa un responsable y un ritmo de revisión, y da criterios para las dos acciones:
| Acción | Efecto | Úsela cuando |
| --- | --- | --- |
| `Requeue` | Devuelve el elemento a su estado listo. Puede fallar de nuevo y volver a la lista | La causa está corregida, por ejemplo el servidor de correo vuelve a estar accesible |
| `Discard` | Quita la fila de la lista y no envía nada. La fila y su error permanecen en la base de datos | Ya no merece la pena enviar el elemento |
### El aviso de licencia
Con la comprobación en línea activada, Management muestra un aviso cuando el servidor de licencias lleva 3 horas sin estar accesible. El inicio de sesión se rechaza cuando el último contacto correcto tiene más de 7 días. Enseñe a los operadores a tratar el aviso como urgente. Los 7 días son el tiempo que tienen para restablecer el acceso saliente, no un motivo para esperar.
### La retención es una decisión firmada
| Producto | Comportamiento | Decisión que hay que registrar |
| --- | --- | --- |
| Monosign | Activar la regla `Audit` en `Data Retention` elimina de forma permanente las filas de auditoría antiguas, sin archivarlas antes | El número de días y dónde se guardan los registros antiguos si cumplimiento los necesita más tiempo |
| Monosync | Las purgas de registros tampoco tienen archivo, y las ejecuciones incrementales dependen del registro de la última ejecución correcta | Valores de días por encima del mayor intervalo que espera entre ejecuciones correctas |
Haga que el responsable de cumplimiento del cliente firme ambas líneas en el paquete de traspaso. Un valor de retención que nadie eligió es el tipo de hallazgo que aparece en una auditoría un año después.
### Lista de comprobación del traspaso para estos puntos
- Registro de UAT con requisito, caso, persona que prueba, resultado y evidencia en cada línea
- Responsable y ritmo de revisión de `Dead Letters` escritos en el runbook
- Aviso de licencia explicado, con el contacto que restablece el acceso saliente
- Valores de retención firmados por el responsable de cumplimiento