Categorías
Seguridad

Cómo vencimos al «borrado silencioso»: Monitorización de integridad en la sincronización SCIM con Netskope

Descubrimos un enemigo silencioso en la sincronización SCIM con Netskope: el SCIM Drift. Te contamos cómo lo detectamos y cómo construimos una sonda de monitorización de integridad para no volver a ser sorprendidos.

El problema: cuando todo está «Verde» pero algo va mal

En el ecosistema de VitalyTech, la automatización de identidades es sagrada. Confiar en que nuestros usuarios se sincronicen correctamente entre Google Workspace y nuestras herramientas de seguridad (como Netskope) es fundamental para garantizar que nadie acceda a lo que no debe… y que todos tengan lo que necesitan.

Sin embargo, descubrimos un enemigo silencioso: el «SCIM Drift».

Si administras un tenant de Netskope sincronizado con Google Workspace (o Azure AD/Okta), quizás te hayas encontrado con él «cara a cara».

Este problema se vuelve especialmente crítico en entornos multi-dominio, donde conviven varios sufijos de correo (@empresa-madre.com, @adquirida.com…). En estos escenarios es muy común que el Directory Importer pierda el rastro de ciertos usuarios, o que una regla dinámica falle tras un cambio de atributos, provocando que grupos críticos de ZTNA se queden vacíos de la noche a la mañana.

Lo peor es que las alertas nativas de conexión no siempre saltan en estos casos. El sistema te dice que la conexión con Google Workspace está «Verde» (porque hay conectividad), pero no te avisa de que el problema es lógico: se han borrado miembros legítimos silenciosamente.

Nuestra estrategia: Monitorización de Integridad

Necesitábamos detectar anomalías de integridad, no solo de disponibilidad. Si un grupo de 500 personas pasa a tener 340 miembros, la API responde «200 OK» (porque la consulta funcionó), pero operativamente es un desastre.

La solución fue integrar una sonda personalizada en nuestro sistema de monitorización (Nagios) capaz de detectar exactamente este tipo de degradación silenciosa.

La Solución Lógica: el Algoritmo

Desarrollamos una sonda que interactúa con la API v2 de Netskope siguiendo este flujo de decisión:

1. Snapshot vs. Realidad

El sistema guarda una «foto» (archivo JSON local) con el conteo de usuarios de la última ejecución exitosa. Cada 30 minutos, compara la realidad actual contra esa foto.

2. El problema de los Filtros SCIM

Descubrimos que la API estándar SCIM de Netskope tiene limitaciones graves de rendimiento cuando intentas evaluar y contar miembros de Dynamic Groups muy poblados. Si fuerzas la expansión de atributos para sacar la lista de usuarios, la latencia se dispara. La solución arquitectónica definitiva fue pivotar: abandonamos SCIM para esta tarea y atacamos directamente el endpoint de gestión interno (/getgroups).

3. Persistencia del Error (Safety Lock)

Este es el punto clave de nuestra defensa.

Comportamiento normal: Si hay un fallo temporal, el sistema de monitorización suele volver a «Verde» cuando el servicio se restablece o se acepta el nuevo estado.

Nuestro enfoque: Si la sonda detecta una caída masiva de usuarios (ej. >15%), lanzamos una alerta crítica y congelamos la línea base. Esto impide que el sistema acepte el borrado como «el nuevo estado normal». La alerta se mantiene activa hasta que un administrador revisa manualmente si el borrado fue legítimo o un error de sincronización.

Detalles Técnicos: los dos endpoints clave

Uno de los retos fue consultar los datos sin descargar la base de datos entera de usuarios cada vez. Tras investigar la documentación de la API v2 de Netskope, identificamos dos endpoints específicos:

1. Para la «Foto Global» (rápido y ligero)

GET /api/v2/users/counts

Este endpoint devuelve un JSON muy simple con el conteo total de usuarios y grupos en milisegundos. Perfecto para detectar caídas masivas globales sin procesar datos.

{
  "totalUsers": 1389,
  "activeAccounts": 1261,
  "inactiveAccounts": 128,
  "totalGroups": 12,
  "totalOUs": 1,
  "lastModified": 1739082912.123
}

2. Para los Grupos Críticos

Endpoint: POST /api/v2/users/getgroups

En lugar de utilizar la API estándar de SCIM (que nos obligaría a descargar y contar miles de miembros uno a uno, ralentizando el sistema), utilizamos el endpoint de grupos con proyecciones.

Al configurar la consulta para que solo nos devuelva el atributo calculado userCount, obligamos a la API de Netskope a entregarnos el número exacto de usuarios procesado en sus servidores. Esto transforma una respuesta que podría pesar varios megabytes en un JSON de apenas unos bytes, permitiendo una monitorización en tiempo real sin impacto en el rendimiento del tenant.

Payload de la consulta:

payload = {
    "query": {
        "paging": { "limit": 500, "offset": 0 },
        "projection": [ "id", "displayName", "userCount" ]
    }
}

El resultado en la práctica

Cuando todo va bien, la sonda reporta:

Conectando a API Netskope...
--- 1. Mapeando IDs de grupos... ---
--- 2. Consultando miembros (Método Force Attributes) ---
CHECK: ztna-grupo-a    -> 447 miembros
CHECK: ztna-grupo-b    -> 1167 miembros
CHECK: ztna-grupo-c    -> 2162 miembros

--- 3. Comparando con estado anterior ---
Usuarios: 77 -> 77 (Diferencia: 0)

--- 4. Resultado Final ---
OK - Estable. Usuarios: 77, Grupos: 5

Cuando se detecta una anomalía (por ejemplo, modificando el JSON de estado para simular una pérdida de miembros), la alerta salta inmediatamente:

--- 4. Resultado Final ---
CRITICAL - Grupo ztna-grupo-a perdió 30 miembros

Resultados

Gracias a esta implementación, hemos pasado de reaccionar ante tickets de usuarios sin acceso, a recibir una alerta proactiva en el momento exacto en que la integridad del directorio se ve comprometida, permitiéndonos detener la sincronización antes de que afecte al negocio.

La monitorización de disponibilidad es necesaria, pero no suficiente. En sistemas de identidad críticos, necesitas monitorizar también la integridad lógica de los datos.

¿Te has encontrado con el SCIM Drift en tu entorno? Cuéntanos tu experiencia en los comentarios.

Deja un comentario