Estimados amigos de Inseguros !!!
Seguimos con el control 8 de los CIS, gestión de logs, y hoy toca el 8.12: centralizar y revisar los logs de acceso. Y este control es el complemento perfecto del 8.11. Porque una cosa es saber quién se autentica… y otra cosa es saber qué hace después. Además, herramientas como Azure sentinel pueden facilitar mucho esta gestión.
Aquí es donde mucha gente se engaña con el “ya tenemos MFA”. Perfecto. Pero si el atacante entra con credenciales válidas, MFA puede no saltar siempre (por sesión persistente, por token, por dispositivo ya confiable, por bypass, por fatiga…). Y aunque salte, si entra, lo que importa es: ¿a qué accede? ¿qué toca? ¿qué consulta? ¿qué descarga? ¿qué borra? ¿qué cambia?
Qué son “logs de acceso” en la práctica
Depende del entorno, pero la idea es: acceso a sistemas, acceso a recursos, acceso a datos.
Ejemplos muy típicos en empresa:
accesos a servidores (RDP/SSH), accesos a shares y ficheros, accesos a aplicaciones internas, accesos a APIs, accesos a bases de datos, accesos a SaaS (SharePoint, OneDrive, Teams, CRM…), accesos a recursos cloud (storage, vaults, VMs, roles, etc.).
Y lo importante: no vale con que “existan logs”. Hay que centralizarlos y revisarlos con criterio. Un SIEM como Azure sentinel es clave para centralización y análisis de eventos.
Por qué esto es tan valioso para detección
Porque los accesos dejan patrones.
Un usuario que nunca descarga ficheros y de repente baja 20 GB.
Un usuario que accede a un share que no le toca.
Un invitado que entra a un repositorio sensible.
Un admin que accede a un vault fuera de horario.
Un servicio que empieza a consultar datos a un ritmo que no es normal.
Una cuenta que toca recursos críticos justo después de un login raro.
Esto es lo que en investigaciones te da la evidencia de “qué pasó”.
Y si lo tienes bien montado, te permite incluso detectar antes de que el daño sea irreversible. Por cierto, Azure sentinel puede generar alertas precisas ante estos patrones.
Qué deberías centralizar sí o sí
En entornos Microsoft, aquí hay dos fuentes muy jugosas:
los logs de M365 (acceso a SharePoint/OneDrive/Exchange/Teams),
y los logs de Azure/Entra (acceso a recursos, activity logs, etc.).
En on-prem, lo típico es:
Windows Security logs (con auditoría bien configurada), logs de file servers, logs de aplicaciones, logs de base de datos si aplica.
Y ojo con una cosa: sin auditoría bien configurada, muchos accesos no quedan registrados. Hay que habilitarlo de forma consciente, y esto a veces tiene impacto (volumen y rendimiento). Por eso este control también es de diseño.
Cómo se revisa sin ahogarte
Lo mismo de siempre: casos de uso.
No puedes revisar cada acceso.
Tienes que revisar señales.
Accesos a datos sensibles.
Accesos fuera de horario.
Accesos desde ubicaciones raras.
Accesos masivos.
Cambios de permisos seguidos de accesos.
Accesos a recursos “joya” (vaults, admin panels, repos críticos).
Y lo ideal es correlacionarlo con autenticación (8.11) y con alertas (8.8). Si lo miras aislado, te pierdes contexto. Si lo miras unido, tienes historia completa.
Si quieres aprender a montar detección basada en accesos con enfoque real, pásate por www.seguridadsi.com y mira los cursos de ciberseguridad online para profesionales que tenemos en la academia.
Gracias por leerme !!!
