Acceso Just-in-Time Explicado: Cómo Eliminar Privilegios Permanentes en su Empresa

La mayoría de incidentes de seguridad empresarial que implican acceso privilegiado comparten una causa raíz común: la cuenta comprometida tenía acceso que no necesitaba, a sistemas que no había utilizado en semanas, con credenciales que habían sido válidas durante meses. El atacante no escaló privilegios — los privilegios ya estaban allí, permanentes, esperando. Este es el problema de los privilegios permanentes, y es la brecha específica que el acceso just-in-time está diseñado para cerrar.

Qué es el Acceso Just-in-Time — y Cómo Difiere del PAM Tradicional

El PAM tradicional opera con un modelo de almacén y préstamo. Las credenciales privilegiadas se almacenan en un almacén (Vault). Cuando un administrador de sistemas necesita acceso, retira credenciales, se conecta al sistema objetivo y devuelve las credenciales al terminar. Esto es mejor que hojas de cálculo compartidas y notas adhesivas, pero aún tiene un problema estructural fundamental: la cuenta privilegiada en sí existe permanentemente en el sistema objetivo. La cuenta Administrator en el servidor Windows, la cuenta root en el host Linux, la cuenta sa en la base de datos — estas cuentas siempre están presentes, siempre habilitadas, siempre son un objetivo.

El acceso just-in-time (JIT) adopta un enfoque diferente: eliminar la cuenta permanente por completo, o como mínimo garantizar que la cuenta esté deshabilitada y las credenciales se roten inmediatamente antes y después de cada uso. El acceso se provisiona bajo demanda para un usuario específico, un objetivo específico y una ventana de tiempo específica. Cuando la ventana expira, el acceso se revoca automáticamente — no se devuelve, sino que se elimina.

El principio zero standing privileges (ZSP) extiende esto aún más: ninguna cuenta privilegiada debe tener acceso persistente a ningún sistema de producción. Cada sesión privilegiada es una concesión temporal con un inicio definido, un fin definido, y un rastro de auditoría completo. Cuando ninguna sesión está activa, no existe acceso privilegiado.

La diferencia práctica entre PAM tradicional y JIT/ZSP:

• PAM Tradicional: El grupo Domain Admins tiene 15 miembros. Las credenciales están almacenadas. Los miembros retiran credenciales cuando es necesario. Las cuentas existen 24/7 en cada servidor unido al dominio.
• PAM JIT: Sin membresía permanente en Domain Admins. Cuando un administrador de sistemas necesita acceso elevado, envía una solicitud con alcance a un servidor específico y una duración específica. El sistema provisiona el acceso, crea la sesión, la registra, y la revoca al final de la ventana de tiempo.

La superficie de ataque en el modelo tradicional es cada momento que la cuenta existe, contra cada sistema al que pueda acceder. La superficie de ataque en el modelo JIT es la duración de la sesión aprobada, contra el objetivo específico aprobado.

Antes de JIT vs Después de JIT — Un Escenario Concreto

Antes de JIT: Un administrador de sistemas senior en una empresa de 500 personas ha estado en el equipo durante cuatro años. Es miembro permanente del grupo Domain Admins y tiene acceso RDP de administrador permanente a aproximadamente 200 servidores — desarrollo, staging y producción. Utiliza este acceso activamente para quizás 20 servidores de forma regular. Los otros 180 son infraestructura que configuró durante migraciones y no ha tocado desde entonces. Sus credenciales están en el SSO corporativo, su cuenta nunca ha sido revisada para reducción de alcance, y su acceso no ha cambiado desde que se unió.

Cuando su portátil es comprometido en un ataque dirigido de phishing, el atacante tiene acceso inmediato, persistente y sin desafíos a los 200 servidores. El radio de explosión es toda la infraestructura.

Después de JIT: El mismo administrador de sistemas no tiene acceso privilegiado permanente. Cuando necesita realizar mantenimiento en un servidor de producción específico, envía una solicitud: "Necesito acceso RDP de administrador a prod-db-03 durante 4 horas para aplicar el parche trimestral." La solicitud es revisada por su gerente y un miembro del equipo de seguridad a través de un flujo de aprobación de Slack. Una vez aprobada, el sistema provisiona una credencial limitada en tiempo y con alcance a ese servidor específico. La sesión se registra automáticamente de principio a fin. Al final de 4 horas, el acceso se revoca y la credencial se rota.

Cuando su portátil es comprometido, el atacante tiene acceso a cualquier sesión activa que exista en ese momento. Si ninguna sesión está actualmente aprobada y activa, el atacante no tiene acceso privilegiado a ningún sistema de producción. El radio de explosión está limitado por lo que fue aprobado y estaba activo en el momento del compromiso — no toda la huella de infraestructura de la carrera del administrador de sistemas.

Acceso JIT y Cumplimiento — Cómo ZSP se Asigna a NIS2, SOC 2 e ISO 27001

El acceso JIT y los privilegios zero standing no son solo buena práctica de seguridad — son cada vez más requisitos explícitos en los marcos de cumplimiento que las empresas de CEE y Europa deben satisfacer.

NIS2 Artículo 21 — Least Privilege: NIS2 requiere que las entidades esenciales implementen control de acceso basado en principios de menor privilegio. "Menor privilegio" en el contexto de NIS2 significa que el acceso debe concederse solo en la medida necesaria para realizar una tarea específica. El acceso permanente de administrador a 200 servidores falla esta prueba por definición — el administrador de sistemas que utiliza regularmente 20 de esos servidores tiene acceso permanente a 180 que no necesita. El acceso JIT refuerza el menor privilegio estructuralmente: el acceso siempre está limitado al sistema específico y la ventana de tiempo de la necesidad real.

SOC 2 CC6.3 — Revocación de Acceso: Los Criterios de Servicios de Confianza de SOC 2 requieren que el acceso se elimine oportunamente cuando ya no sea necesario. CC6.3 específicamente cubre la revocación de acceso para empleados terminados, cambios de rol y finalizaciones de proyectos. El acceso JIT satisface CC6.3 automáticamente: el acceso expira al final de la ventana de tiempo aprobada sin ningún paso de revocación manual. La pregunta del auditor — "¿cómo garantiza que el acceso se elimine cuando ya no sea necesario?" — tiene una respuesta determinista: "Expira automáticamente; aquí está el registro de auditoría de cada expiración de sesión."

ISO 27001 Anexo A.9.2 — Provisión de Acceso: ISO 27001 A.9.2.2 requiere un proceso formal de provisión de acceso, y A.9.2.3 requiere que los derechos de acceso privilegiado se asignen sobre una base de necesidad de uso. "Necesidad de uso" es el lenguaje de ISO 27001 para menor privilegio, y se asigna directamente a JIT: el acceso debe existir cuando sea necesario y no existir cuando no sea necesario. A.9.2.5 requiere revisión periódica de los derechos de acceso del usuario — con acceso JIT, la revisión es continua en lugar de periódica, porque el acceso se otorga nuevamente desde cero para cada sesión.

El argumento de cumplimiento para JIT es directo: los privilegios permanentes son estructuralmente no compatibles con el principio de menor privilegio que NIS2, SOC 2 CC6.3 e ISO 27001 A.9.2 todos requieren. JIT es el patrón de implementación que hace que el menor privilegio sea operativamente viable a escala.

Cómo VaultPAM Implementa el Acceso JIT

VaultPAM implementa el acceso JIT a través de cuatro mecanismos integrados:

Flujos de trabajo de aprobación: Cuando un usuario solicita acceso privilegiado a un sistema objetivo, VaultPAM dirige la solicitud al aprobador apropiado — gerente, equipo de seguridad, o ambos, según el nivel de acceso y la sensibilidad del sistema. Las aprobaciones se pueden completar a través de la interfaz web de VaultPAM o canales de notificación integrados. La solicitud incluye el sistema objetivo, la duración solicitada y la justificación, dando al aprobador el contexto para tomar una decisión informada.

Sesiones limitadas en tiempo: Cada concesión de acceso aprobada incluye un tiempo de caducidad estricto. La ventana de sesión se establece en el momento de la aprobación — 1 hora, 4 horas, 8 horas, o una duración personalizada hasta el máximo de política. Cuando la ventana de sesión expira, VaultPAM revoca el acceso automáticamente. No hay pasos manuales, no hay correos electrónicos recordatorios, no hay dependencia del usuario cerrando sesión. El acceso simplemente deja de existir.

Expiración automática y rotación de credenciales: Para sesiones RDP y SSH, VaultPAM provisiona una credencial específica de sesión al inicio de la ventana aprobada y la rota al vencer. La credencial que existió para la sesión aprobada ya no funciona después de la caducidad. Un atacante que capture la credencial a mitad de la sesión no puede reutilizarla después de que se cierre la ventana.

Rastro de auditoría: Cada solicitud JIT — envío, aprobación o denegación, inicio de sesión, duración de sesión, grabación de sesión y caducidad — se registra en el registro de auditoría inmutable de VaultPAM. El rastro de auditoría incluye la identidad del aprobador, la marca de tiempo de aprobación, el texto de justificación, y una grabación completa de la actividad de la sesión. Este es el paquete de evidencia que satisface solicitudes de auditoría de NIS2, muestreo de auditor de SOC 2 e inspecciones aleatorias de ISO 27001.

Vea el acceso JIT de VaultPAM en acción — elimine privilegios permanentes en su entorno