CyberArk: safes, rotación automática, sesiones grabadas y una cuenta que el CPM no cambia

Qué vas a conseguir

Un CyberArk en el que las cuentas con más poder de la organización viven en safes con dueño, cambian de contraseña solas, se usan a través de una sesión grabada sin que nadie vea la credencial y, en las más sensibles, solo con una segunda aprobación y un ticket. Y el método para resolver el ticket más habitual de la plataforma: una cuenta que el CPM no consigue cambiar.

Vale para Privilege Cloud y para PAM self-hosted: cambia dónde vive el Vault y cómo se entra al portal; safes, plataformas, CPM y PSM funcionan igual (en Privilege Cloud, CPM y PSM son conectores en tu red).

Antes de empezar

• Un usuario con permisos de administración de safes y plataformas (en self-hosted, miembro de Vault Admins; en Privilege Cloud, el rol de administrador de Privilege Cloud).
• Al menos un CPM y un PSM con alcance de red a los servidores: el CPM habla con los controladores de dominio y los servidores (RPC/SMB, WinRM o SSH según la plataforma) y el PSM abre las sesiones RDP y SSH.
• Una cuenta de reconciliación por dominio: una cuenta del propio Vault con permiso para restablecer contraseñas en las OU de las cuentas gestionadas, y nada más.
• El inventario: qué cuentas privilegiadas existen, quién las usa y en qué servidores, servicios o tareas programadas está escrita cada contraseña.

1. Safes y sus miembros: el diseño que no se rehace

Un safe es un contenedor de cuentas con su propia lista de acceso. El error típico es un safe por equipo con todo dentro; lo que aguanta en el tiempo es un safe por tipo de cuenta y ámbito, con nombres que se entiendan solos.

• Los miembros son grupos del directorio, no personas: el alta y la baja del puesto se hacen en AD o Entra ID y el safe lo hereda.
• Connect only permite abrir una sesión por PSM sin ver ni copiar la contraseña. Es el permiso que lleva casi todo el mundo; Retrieve (ver o copiar) es la excepción y queda justificada.
• Quien administra el safe no usa sus cuentas sin pasar por el flujo de aprobación.

2. Dar de alta una cuenta con su plataforma

La plataforma decide cómo se trata la cuenta: cada cuántos días cambia, cómo se verifica, con qué cuenta se reconcilia y por qué componente se conecta. Tres casos habituales:

• En la cuenta de dominio, el campo Address es el dominio (contoso.local) y el CPM cambia la contraseña contra un controlador de dominio. En la local, Address es el servidor.
• La cuenta de reconciliación se asocia en la plataforma o en cada cuenta. Es la que el CPM usa cuando la contraseña del Vault ya no coincide con la real.
• Para una cuenta de servicio se dan de alta también sus dependencias (servicio de Windows, tarea programada, grupo de aplicaciones de IIS): el CPM cambia la contraseña en el directorio y después en cada dependencia. Si no sabes dónde está escrita, no la pongas a rotar todavía.

3. Rotar, verificar y reconciliar: el ciclo del CPM

• Change: el CPM genera una contraseña según la política de la plataforma y la cambia en el destino. Puede ser periódico, tras cada uso (one-time password) o manual.
• Verify: el CPM prueba que la contraseña guardada en el Vault funciona. Es lo que detecta que alguien la cambió por fuera.
• Reconcile: si la verificación falla, el CPM entra con la cuenta de reconciliación y fuerza una contraseña nueva. Con reconciliar automáticamente cuando la contraseña no está sincronizada activado en la plataforma, no hace falta que nadie intervenga.

Pon primero las cuentas nuevas solo a verificar durante unos días. Si la verificación pasa, activa el cambio periódico; si falla, has encontrado una contraseña que alguien tiene escrita en algún sitio, antes de que la rotación rompa algo.

4. Conectarse por PSM y la doble aprobación

El administrador pulsa Connect sobre la cuenta, elige el servidor y el componente (PSM-RDP o PSM for SSH). El PSM abre la sesión con la credencial, la graba y el usuario nunca la ve. Para el usuario es un RDP normal; para auditoría, cada tecla y cada ventana quedan asociadas a una persona con nombre.

En la Master Policy (o como excepción por plataforma) se activan, para las cuentas más sensibles:

• Doble control: la petición de acceso necesita la aprobación de un miembro con permiso de aprobador del safe. El aprobador ve quién pide, qué cuenta, para cuánto tiempo y por qué.
• Motivo obligatorio y, si hay integración con el sistema de tickets, un número de ticket válido que se comprueba antes de conceder el acceso.
• Acceso exclusivo (check-in/check-out): mientras alguien tiene la cuenta, nadie más puede usarla, y al devolverla el CPM cambia la contraseña.

Las cuentas de emergencia y una cuenta de reconciliación como mínimo tienen que poder usarse si el Vault o el PSM no responden. Su contraseña se guarda fuera de CyberArk (sobre cerrado, caja fuerte) y su uso se avisa y revisa.

5. El ticket: "el CPM no puede cambiar la contraseña: la cuenta aparece en fallo"

La cuenta svc-backup aparece en rojo en la lista de cuentas:

Se lee de fuera hacia dentro:

1. ¿Qué paso falló? No es lo mismo que falle el cambio en el directorio que el de una dependencia. El detalle de la cuenta y el registro del CPM (pm_error.log y PMTrace.log en la carpeta Logs del CPM) lo dicen.
2. Acceso denegado (5) al cambiar en el dominio: la cuenta no puede cambiar su propia contraseña (la opción El usuario no puede cambiar la contraseña está marcada) o la directiva de dominio lo impide (antigüedad mínima de contraseña). La solución es una reconciliación, con una cuenta de reconciliación que tenga Restablecer contraseña delegado en esa OU.
3. Error de inicio de sesión (1326) al verificar: la contraseña del Vault ya no es la real. Alguien la cambió por fuera. Se reconcilia y se averigua quién y por qué.
4. Ruta de red no encontrada (53) o tiempo de espera: el CPM no llega al servidor o al controlador de dominio. Cortafuegos, DNS o el servidor apagado.
5. Falla una dependencia: la contraseña ya ha cambiado en AD, pero el servicio o la tarea siguen con la anterior. Se comprueba que la cuenta del CPM tiene permisos de administrador en srv-bkp-01 y que la dependencia está dada de alta con el nombre exacto.

›New-PASSession -BaseURI https://pvwa.contoso.local -Credential $cred -type LDAP›$a = Get-PASAccount -search "svc-backup" -safeName "WIN-SERVICIO-BACKUP"›$a.secretManagementautomaticManagementEnabled : Truestatus                     : failurelastModifiedTime           : 1753862400lastReconciledTime         :lastVerifiedTime           : 1761552000›Invoke-PASCPMOperation -AccountID $a.id -ReconcileTask

Si el CPM ya había deshabilitado la gestión automática, tras corregir la causa se reanuda con Resume. Y una pregunta para el cierre del ticket: si una cuenta de servicio que se usa en un solo servidor podría ser una gMSA, que Windows rota sola, ya no necesita que el CPM la cambie.

6. Revisar grabaciones y lo que miras cada mes

Las grabaciones de PSM están en la sección de grabaciones del portal (Monitoring › Recordings en PVWA), con quién, qué cuenta, qué servidor y cuánto duró. Se revisan con criterio: fuera de horario, largas con cuentas de dominio o con un motivo vago.

Cada mes:

• Cuentas en fallo o con la gestión automática deshabilitada: ninguna debería pasar de una semana.
• Cuentas privilegiadas del directorio que no están en CyberArk (un administrador de dominio nuevo creado a mano es la primera señal de que alguien se salta el proceso).
• Miembros de cada safe frente a la lista de personas del equipo y permisos Retrieve que siguen activos sin motivo.
• Aprobaciones concedidas sin ticket válido y usos de cuentas de emergencia.

Siguientes pasos

• La guía de Microsoft 365: Global Admin y PIM es la pieza complementaria: PIM controla los roles de Entra ID y Microsoft 365 con activación temporal; CyberArk, las cuentas y contraseñas del directorio local y de los servidores.
• Microsoft Sentinel: los eventos del Vault y del PSM enviados por syslog permiten alertar de una cuenta de emergencia usada o de una aprobación fuera de horario.
• ISO 27001/NIS2/RGPD en IT: el control de accesos privilegiados es uno de los primeros puntos que pide una auditoría, y las grabaciones son la evidencia.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.