Just-in-time privileged access management

En el Radar compartido: Trial (valoración de la edición aportada).

Cómo funciona

Una política establece quién puede solicitar qué rol, sobre qué recurso y durante cuánto tiempo. El flujo concede acceso tras las comprobaciones y registra su expiración.

Ejemplo de uso

Un operador solicita treinta minutos de lectura de logs para un incidente. El sistema registra el ticket, obtiene la aprobación configurada, asigna el rol y lo retira al vencer la ventana.

Modelo de acceso

Concepto	Descripción
Acceso permanente	Mínimo: lo que la persona necesita todos los días (lectura de su servicio)
Elegibilidad	Roles que puede solicitar, no que tiene
Solicitud	Rol, recurso, duración y justificación (ticket, incidente)
Aprobación	Automática, por un par o por un responsable, según el riesgo
Concesión	Se asigna el rol con fecha de expiración
Auditoría	Quién pidió qué, quién aprobó, qué hizo durante la ventana

Ejemplo en Google Cloud

Con Privileged Access Manager se definen entitlements (qué roles se pueden pedir, por quién, cuánto tiempo y con qué aprobación) y las personas solicitan grants:

gcloud pam grants create \
  --entitlement=lectura-logs-prod \
  --requested-duration=1800s \
  --justification="INC-2041: errores 5xx en pagos" \
  --location=global --project=krediya-prod

Una alternativa más simple, sin flujo de aprobación, es una vinculación IAM con condición de expiración:

gcloud projects add-iam-policy-binding krediya-prod \
  --member="user:ana@krediya.example" --role="roles/logging.viewer" \
  --condition='expression=request.time < timestamp("2026-10-17T18:00:00Z"),title=incidente-2041'

Equivalentes en otras plataformas

Plataforma	Mecanismo
Azure / Entra ID	Privileged Identity Management (PIM)
AWS	Temporary elevated access con IAM Identity Center
Kubernetes, servidores, bases de datos	Teleport, StrongDM, Boundary u otras soluciones de acceso
Multinube y SaaS	Plataformas de gobierno de accesos (Opal, ConductorOne…)

Diseño de las políticas

Riesgo del rol	Política sugerida
Lectura de logs y métricas de producción	Autoaprobación con justificación, 1–4 horas
Lectura de datos de clientes	Aprobación de un par, 1 hora, registro de consultas
Escritura en producción, IAM, claves	Aprobación de un responsable, 30–60 minutos, sesión grabada
Acceso de emergencia (break-glass)	Cuentas especiales en sobre cerrado, alerta inmediata y revisión posterior

Métricas

Número de cuentas con privilegios permanentes (debe tender a cero), solicitudes por semana, tiempo de aprobación (si es alto, la gente buscará atajos) y concesiones usadas fuera de un incidente o cambio registrado. Es un control central en Zero Trust y en auditorías de cumplimiento (continuous compliance).

Criterios de implementación

Evitar roles demasiado amplios y contemplar accesos de emergencia. La retirada del rol no garantiza revocación inmediata de todas las sesiones: comprobar el comportamiento del proveedor.