Qué ha cambiado

Cada actualización del contenido se versiona. Seleccione una versión para compararla con la anterior.

Versión 8 → 9

Actualización

Dos secciones nuevas: acceso durante la tarea (el privilegio permanente frente a las solicitudes con ventana de tiempo) y Sites, que encaminan las sesiones por los Gateways de una ubicación.

2 lecciones actualizadasduración

Actualización de contenido. Se notificó a los estudiantes inscritos.

La duración cambió de 16 a 17 minutos.

Qué hace Monopam

Monopam es la plataforma de **gestión de accesos privilegiados** de Monofor. Su función es fácil de resumir: las personas y herramientas que necesitan cuentas potentes obtienen **acceso a una sesión, no a una contraseña**. En lugar de entregar a un administrador la contraseña root de un servidor, Monopam la guarda en su Vault (bóveda de contraseñas), abre la conexión en nombre del usuario y puede grabar lo que ocurre. Cuando termina el trabajo, el acceso se acaba y la evidencia permanece. ::diagram pgs-brokered-access ### Las ideas principales - **Acceso intermediado:** los usuarios se conectan a través de Monopam; el Gateway (pasarela) inyecta la credencial y el usuario no la ve. - **Primero la política:** las políticas deciden quién llega a qué recurso, con qué cuenta y en qué condiciones (portapapeles, transferencia de archivos, grabación, aprobación). - **Evidencia:** con la grabación activa, las sesiones RDP se guardan como vídeo y las de terminal como transcripción. Las revelaciones, las conexiones y las solicitudes dejan registros de auditoría. ### El inicio de sesión viene de un proveedor de identidad Monopam no tiene contraseñas locales ni MFA propia. Los usuarios inician sesión en un proveedor de identidad, normalmente **Monosign**, mediante un método OAuth2 u OpenID Connect configurado por tenant. Por eso las credenciales y la MFA son tarea del proveedor de identidad, y los grupos y permisos del usuario llegan con ese inicio de sesión. ### Acceso durante la tarea Muchas organizaciones dan a los administradores un acceso poderoso una vez y lo dejan así durante años. Eso es **privilegio permanente (standing privilege)**: el acceso existe se use o no. Monopam permite sustituirlo por un acceso que se pide cuando hace falta. Un usuario envía una solicitud, un aprobador decide en **Requests**, y la solicitud aprobada lleva la ventana de tiempo durante la que se permite el acceso. Cuando la ventana termina, también termina el acceso. Eso es el **acceso just-in-time** en la práctica. Ejemplo: un contratista tiene que parchear un servidor el sábado. En lugar de una cuenta que funciona todos los días, solicita ese servidor para la mañana del sábado. El aprobador ve quién pide qué y durante cuánto tiempo, y el lunes no queda nada que limpiar. > Consejo: Si un cliente pregunta dónde exigir MFA para el acceso privilegiado, la respuesta es el proveedor de identidad, no un ajuste de Monopam.

Los componentes: Vault, Gateway y agentes

Una implantación de Monopam tiene unas pocas piezas que trabajan juntas. ::diagram pgs-building-blocks ### Consola web En la **aplicación web** se definen recursos, elementos del Vault (bóveda de contraseñas) y políticas, se deciden solicitudes y se revisan sesiones. Los usuarios abren aquí sus sesiones de navegador. ### Vault El **Vault** guarda cuentas y secretos: usuario y contraseña, claves PKI, texto secreto, semillas OTP y otros tipos de elemento. Los secretos se cifran, y cada guardado crea una **versión** que un administrador ve en Password History. Una **Vault Access Policy** decide quién puede revelar cada campo. Cada revelación o copia se audita, y el navegador borra el valor mostrado a los 30 segundos. ### Gateway El **Gateway** (pasarela) es el proxy que habla con los sistemas de destino. Abre la conexión, inyecta la credencial del Vault, transmite la sesión al navegador y escribe la grabación. Los Gateways envían una señal cada cinco segundos y aparecen en **System > Gateways**. Puede colocarlos cerca de las redes a las que sirven y agruparlos con **Sites**. ### Agente El **agente de Monofor** es un software opcional para equipos Windows, Linux y macOS. Se registra en Monopam, crea un recurso o se asocia a uno existente y realiza el trabajo con cuentas locales: listar cuentas, verificar y establecer contraseñas, eliminar cuentas. Compruebe la ruta de red según la plataforma: - Los **agentes de Linux y macOS** salen por el **Agent Channel** en el puerto 443, así que no necesitan un puerto de entrada para ello. Queda un listener de entrada en el puerto 4482 como alternativa, y en las instalaciones nuevas de macOS viene desactivado. - Los **agentes de Windows** del MSI publicado aún no tienen el canal. Funcionan **solo con conexión entrante**: el Gateway debe llegar al agente por el puerto 4482. ### Sites: Gateways cerca de los sistemas a los que sirven Una empresa con varias ubicaciones suele tener un Gateway en cada una. Un **Site** modela una de esas ubicaciones: una planta, un centro de datos o una sucursal. Se le asocian Gateways y recursos, y Monopam elige entonces el Gateway según la ubicación, en este orden: 1. Si un recurso está fijado a Gateways concretos, esa fijación siempre gana. 2. Si no, un recurso que pertenece a un site usa los Gateways de ese site. 3. Si no, puede usarse cualquier Gateway, como antes de que existieran los sites. Ejemplo: un fabricante tiene plantas en Bursa y en Izmir. Cada planta pasa a ser un site con sus propios Gateways y sus propias máquinas. Una sesión hacia una máquina de Izmir pasa por un Gateway de Izmir sin que nadie lo elija. La página **Sites** muestra la salud de los Gateways de cada ubicación, y cada site tiene un **Activity Report**. Los sites son opcionales. Una instalación que nunca crea uno se comporta exactamente igual que antes. > Consejo: La insignia **Connection** de la lista **Agents** muestra `Channel` o `Inbound` para cada agente, según lo que esté conectado en ese momento.