Problema

En muchas organizaciones el personal de Recursos Humanos (HR) considera que las credenciales de los usuarios corporativos son un “activo de IT” que pueden y deben centralizarse en un archivo accesible. La petición suele venir acompañada de argumentos como “facilita la recuperación” o “evita tickets repetidos”. En la práctica, esa práctica rompe con los principios básicos de security y privacy, genera un punto único de falla y expone a la empresa a auditorías negativas. El problema se vuelve crítico cuando:

  • Un empleado bloquea su cuenta repetidamente y HR quiere que el equipo local tenga una lista con todas las contraseñas.
  • La infraestructura está basada en Azure AD con MFA, pero el equipo local no tiene privilegios de administración.
  • No existe un proceso formal de gestión de credenciales ni de privileged access.

El reto para el sysadmin es responder a la solicitud sin crear un repositorio inseguro, alineando la solución con políticas de cybersecurity, cumplimiento normativo y la arquitectura de la nube.

Causa

  1. Falta de procesos de gestión de credenciales
    Cuando la empresa no define claramente quién puede ver o resetear contraseñas, HR tiende a buscar atajos. La ausencia de un Password Vault o de Self‑Service Password Reset (SSPR) deja a los equipos de soporte como último recurso.

  2. Desconocimiento de las capacidades de Azure AD
    HR a menudo no sabe que Azure AD ya provee mecanismos para delegar la recuperación de cuentas sin exponer la contraseña: SSPR, Azure AD Password Protection, y Privileged Identity Management (PIM).

  3. Cultura de “control de activos” mal interpretada
    Tratar una cuenta de usuario como un activo físico lleva a la idea de “inventariarlo” en un archivo plano. Esa mentalidad ignora que la credencial es información sensible, no un bien material.

  4. Comunicación deficiente entre IT y HR
    La presión de HR para “resolver rápido” sin entender el impacto de seguridad genera fricción y decisiones improvisadas.

Solución

Implementar un flujo de gestión de contraseñas que satisfaga a HR (rapidez en la recuperación) y a security (ningún acceso a contraseñas en texto plano). El enfoque se compone de tres capas:

1. Habilitar Self‑Service Password Reset (SSPR) en Azure AD

SSPR permite que el propio usuario restablezca su contraseña mediante MFA, sin intervención del equipo de IT. Configurar políticas de verificación (correo, teléfono, preguntas de seguridad) y comunicar el proceso a los usuarios reduce drásticamente los tickets.

2. Adoptar un Password Vault con control de acceso granular

Herramientas como Azure Key Vault, CyberArk o HashiCorp Vault pueden almacenar credenciales de cuentas de servicio y de administradores. Los usuarios de IT reciben permisos de read‑only o reset‑only mediante role‑based access control (RBAC). HR nunca accede al vault; solo recibe informes de auditoría.

3. Definir un proceso de escalamiento basado en Privileged Identity Management (PIM)

Cuando un usuario necesita que su cuenta sea desbloqueada, el ticket abre una solicitud de elevación temporal en PIM. Un administrador con privilegios aprobados otorga la elevación por un tiempo limitado, realiza el desbloqueo y la revoca automáticamente. El registro queda en los logs de Azure AD y en Azure Monitor.

Pasos de implementación

  1. Activar SSPR

    • En Azure portal → Azure AD → Password reset → “Properties”.
    • Seleccionar “All” o “Selected” según el grupo de usuarios.
    • Configurar métodos de verificación (correo + teléfono es lo mínimo recomendado).

  2. Crear un vault y políticas de acceso

    • Deploy Azure Key Vault (o la solución elegida).
    • Definir secret “admin‑accounts” con credenciales de cuentas de servicio.
    • Asignar RBAC: Key Vault Secrets User a los técnicos de soporte; Key Vault Secrets Officer solo a los administradores de seguridad.

  3. Configurar PIM para Azure AD roles

    • En Azure AD → Privileged Identity Management → Azure AD roles.
    • Activar “eligible” para los roles Password Administrator y Global Administrator.
    • Establecer duración de la elevación (ej. 1 hora) y requerir justificación.

  4. Comunicar el nuevo flujo a HR

    • Entregar un documento de “Procedimiento de recuperación de cuenta”.
    • Incluir SLA: SSPR = <5 min, PIM = <15 min tras aprobación.
    • Resaltar que el vault nunca será entregado a HR; solo se proveen reportes de auditoría.

Cuándo aplicar esta solución

Aplica cuando:

  • La organización usa Azure AD (o un IdP con funcionalidades similares).
  • Existen casos recurrentes de bloqueo de cuentas y HR solicita acceso a contraseñas.
  • Se necesita cumplir con normativas como GDPR, ISO 27001 o NIST‑800‑53 que prohíben el almacenamiento de contraseñas en texto plano.

No aplica si:

  • La empresa no tiene Azure AD y depende de directorios locales sin mecanismos de SSPR.
  • El entorno es extremadamente pequeño (menos de 5 usuarios) y no justifica la complejidad de un vault. En ese caso, un proceso manual documentado puede ser suficiente, aunque sigue sin recomendarse almacenar contraseñas en archivos.

Código

# Habilitar SSPR para todos los usuarios (Azure CLI)
az ad password reset policy update \
  --enable-self-service true \
  --methods-email true \
  --methods-phone true \
  --methods-security-questions false

# Crear un Azure Key Vault y asignar RBAC a un grupo de soporte
az keyvault create \
  --name it-support-vault \
  --resource-group RG-IT \
  --location eastus

az role assignment create \
  --assignee <group-object-id> \
  --role "Key Vault Secrets User" \
  --scope $(az keyvault show -n it-support-vault -g RG-IT --query id -o tsv)

# Configurar PIM para que el rol Password Administrator sea elegible
az ad pim role assign create \
  --role-id <PasswordAdministrator-role-id> \
  --principal-id <user-object-id> \
  --duration PT1H \
  --justification "Necesario para desbloquear cuenta bloqueada"

Verificación

  1. SSPR: Un usuario intenta “¿Olvidó su contraseña?” y completa la verificación con correo y teléfono. La nueva contraseña se establece sin intervención de IT.
  2. Vault: Ejecuta az keyvault secret show con una cuenta de soporte; debe poder leer pero no crear o eliminar secretos.
  3. PIM: Genera una solicitud de elevación desde Azure portal, aprueba y verifica que la cuenta tenga el rol Password Administrator solo durante la ventana configurada. Revisa los logs en Azure Monitor para confirmar que la actividad quedó registrada.

Notas adicionales

  • Auditoría continua: Configura Azure AD Diagnostic Settings para enviar logs a Log Analytics; crea alertas cuando se use el rol Password Administrator.
  • Educación a HR: Un breve workshop de 30 min sobre conceptos de “credential vault” y “least privilege” suele cerrar la resistencia.
  • MFA obligatoria: Asegúrate de que todos los métodos de verificación en SSPR tengan MFA habilitado; de lo contrario, el proceso se vuelve un vector de ataque.
  • Política de contraseñas: Refuerza la longitud y complejidad; contraseñas débiles aumentan la frecuencia de bloqueos y la presión de HR.
  • Documentación interna: Mantén un runbook actualizado con los pasos de SSPR, PIM y vault. Un documento vivo reduce la necesidad de “explicar por qué no podemos entregar el archivo”.

Implementar este flujo no solo apaga la petición de HR de crear un “archivo con todas las contraseñas”, sino que establece una arquitectura de gestión de credenciales alineada con mejores prácticas de security, mejora la experiencia del usuario y brinda trazabilidad para auditorías. En entornos donde la cuenta corporativa es un activo digital, la solución está en delegar la recuperación, aislar el almacenamiento y controlar la elevación de privilegios, no en compartir contraseñas en texto plano.