Problema

Los playbooks de ransomware modernos ya no se limitan a cifrar discos. Un paso recurrente es comprometer el plano de control de identidad: modificar configuraciones de Azure AD, Okta, OneLogin o cualquier IdP, desactivar MFA, eliminar aplicaciones SSO o cambiar políticas de acceso condicional. El objetivo es doble: mantener persistencia y, al mismo tiempo, bloquear a los equipos de respuesta que dependen de esas credenciales para contener la brecha.

En entornos donde los datos críticos están respaldados en almacenamiento inmutable (S3, snapshots de VM, etc.), la pérdida del estado del IdP deja a los administradores sin una “botón de restaurar”. No hay una instantánea de la configuración del tenant que pueda ser revertida con un clic. Cuando el IdP se vuelve inoperable, la recuperación completa del entorno se vuelve mucho más lenta y costosa.

Este patrón se repite en cualquier organización que confíe en un IdP externo para SSO, gestión de usuarios y control de acceso. Si no se cuenta con una estrategia de respaldo y validación de la configuración de identidad, el ransomware puede “quemar” la puerta de entrada y dejar el resto del ecosistema aislado.

Causa

  1. Falta de respaldo nativo – La mayoría de los IdP no ofrecen snapshots automáticos de su configuración. Azure AD permite exportar ciertos objetos, pero no hay un “snapshot completo” integrado.

  2. Dependencia de configuraciones en la nube – Los ajustes de políticas, aplicaciones y asignaciones de grupos se guardan únicamente en la nube. Un atacante con privilegios de administrador puede borrarlos o modificarlos sin dejar rastro en los logs de backup tradicionales.

  3. Ausencia de control de versiones – Sin versionado, cualquier cambio accidental o malicioso sobrescribe la configuración anterior. No hay forma de volver a un estado conocido.

  4. Procedimientos de recuperación manual – En muchos equipos la restauración se hace “a mano” mediante recreación de aplicaciones y políticas, lo que lleva horas o días y aumenta la superficie de error.

  5. Privilegios excesivos – Cuentas de servicio con permisos de “Global Administrator” o “Super Admin” son objetivo directo. Cuando esas credenciales son comprometidas, el atacante puede ejecutar cambios críticos sin barreras.

Solución

Una estrategia de respaldo y restauración de IdP debe combinar exportación automatizada, control de versiones y validación periódica. El objetivo es tratar la configuración del IdP como código (IaC) y almacenarla en un repositorio inmutable.

1. Exportación programada mediante API

  • Azure AD: usar az ad o PowerShell para exportar usuarios, grupos, aplicaciones y políticas a JSON.
  • Okta: usar la API /api/v1/meta/schemas y /api/v1/apps para descargar la definición completa.
  • OneLogin: exportar mediante /api/1/users, /api/1/apps y /api/1/policy_rules.

Programar la extracción cada 24 h (o con mayor frecuencia según el nivel de cambio) y enviarla a un bucket S3 con Object Lock o a un repositorio Git con firmas GPG.

2. Versionado con GitOps

Almacenar los archivos JSON en un repositorio Git privado. Cada commit representa un “snapshot” de la configuración. Aplicar branch protection y signed commits para evitar alteraciones no autorizadas.

Ejemplo de flujo:

  1. Cron job ejecuta script de exportación.
  2. Si el hash del nuevo dump difiere del último commit, se crea una rama idp-backup-YYYYMMDD.
  3. Se abre un Pull Request automático que requiere aprobación de al menos dos administradores.
  4. Al mergearse, el commit queda registrado y disponible para restauración.

3. Restauración automatizada

Crear scripts que, a partir de un commit específico, vuelvan a aplicar la configuración usando la misma API. La restauración debe ser idempotente: si un objeto ya existe, el script lo actualiza; si falta, lo crea.

Para entornos críticos, probar la restauración en una suscripción/tenant de pruebas antes de ejecutar en producción.

4. Monitoreo de integridad

  • Hash de configuración: calcular SHA‑256 del dump completo y comparar contra el valor almacenado en un registro de auditoría.
  • Alertas de cambio: usar Azure Monitor, CloudWatch o Splunk para disparar alertas cuando la API de cambios (/auditLogs) registre modificaciones de objetos críticos (MFA, Conditional Access).

5. Principio de menor privilegio

  • Crear cuentas de servicio exclusivas para backup con roles ReadOnly o Directory Readers.
  • Rotar esas credenciales cada 30 días y almacenarlas en un vault (AWS Secrets Manager, Azure Key Vault).

6. Pruebas de recuperación (DR drills)

Ejecutar simulacros trimestrales donde se restaure una versión anterior en un tenant de pruebas. Documentar tiempos y problemas encontrados; ajustar scripts según sea necesario.

Cuándo aplicar esta solución

  • Se detectan cambios inesperados en políticas de acceso condicional, MFA o aplicaciones SSO.
  • Los logs de auditoría muestran actividades de cuentas con privilegios de administrador fuera del horario habitual.
  • Se planea una migración a otro IdP o se implementan nuevas políticas de seguridad; tener un baseline facilita la comparación.
  • Entornos con cumplimiento regulatorio (PCI DSS, HIPAA) que exigen evidencia de control de cambios y capacidad de restauración.

No es necesario en entornos extremadamente estáticos donde la configuración no cambia más de una vez al año, aunque aun así se recomienda al menos un backup anual por motivos de auditoría.

Código

#!/usr/bin/env bash
# backup_idp.sh – Exporta configuraciones de Azure AD y Okta a JSON y los versiona en Git

set -euo pipefail

# Variables
TMPDIR=$(mktemp -d)
DATE=$(date +%Y%m%d)
GIT_REPO="/srv/git/idp-backups"
AZURE_TENANT="mytenant.onmicrosoft.com"
OKTA_ORG="myorg.okta.com"
OKTA_TOKEN="${OKTA_API_TOKEN}"

# 1. Azure AD export (usuarios, grupos, apps, policies)
az ad user list --all --output json > "$TMPDIR/azure_users.json"
az ad group list --all --output json > "$TMPDIR/azure_groups.json"
az ad app list --all --output json > "$TMPDIR/azure_apps.json"
az ad conditional-access policy list --output json > "$TMPDIR/azure_ca_policies.json"

# 2. Okta export (users, apps, policies)
curl -s -H "Authorization: SSWS $OKTA_TOKEN" \
     "https://${OKTA_ORG}/api/v1/users?limit=200" > "$TMPDIR/okta_users.json"

curl -s -H "Authorization: SSWS $OKTA_TOKEN" \
     "https://${OKTA_ORG}/api/v1/apps" > "$TMPDIR/okta_apps.json"

curl -s -H "Authorization: SSWS $OKTA_TOKEN" \
     "https://${OKTA_ORG}/api/v1/policies" > "$TMPDIR/okta_policies.json"

# 3. Commit to Git
cd "$GIT_REPO"
git checkout main
mkdir -p "backup_$DATE"
cp "$TMPDIR"/*.json "backup_$DATE/"
git add "backup_$DATE"
git commit -m "IdP backup $DATE"
git push origin main

# 4. Clean up
rm -rf "$TMPDIR"

Verificación

  1. Hash de integridad – Después del backup, ejecutar sha256sum backup_*/ *.json y comparar con el registro almacenado en el vault.
  2. Prueba de restauración – En un tenant de pruebas, ejecutar el script restore_idp.sh (versión inversa del anterior) apuntando a un commit anterior y validar que:
    • Todos los usuarios aparecen en Azure AD (az ad user list).
    • Las aplicaciones SSO aparecen en Okta (curl .../apps).
    • Las políticas de Conditional Access están activas (az ad conditional-access policy list).
  3. Alertas – Confirmar que la herramienta de monitoreo genera un evento cuando el dump difiere del hash esperado.

Notas adicionales

  • Límites de API: tanto Azure AD como Okta imponen cuotas de llamadas. Programa los backups fuera de los picos de tráfico y usa paginación adecuada.
  • Objetos no exportables: algunos atributos (por ejemplo, contraseñas o certificados) no pueden exportarse por razones de seguridad. Asegúrate de tener un proceso separado para la rotación de secretos.
  • Impacto en producción: la exportación es mayormente de solo‑lectura, pero en entornos con millones de objetos puede generar una carga perceptible. Prueba en una ventana de mantenimiento si notas latencia.
  • Almacenamiento inmutable: habilita Object Lock en S3 o Immutable Blob en Azure para que los backups no puedan ser sobrescritos ni borrados por un atacante con acceso al bucket.
  • Documentación interna: mantén un runbook que detalle los pasos de restauración, los roles involucrados y los contactos de emergencia. Un documento vivo reduce la fricción durante un incidente real.