Registros, retención y alertas

Un registro que vive en la misma cuenta que lo genera lo puede borrar quien administra esa cuenta, incluido quien la ha comprometido. Por eso la política de Valle Claro pide enviar los registros a una cuenta aparte, la de seguridad, a la que los equipos de aplicación no tienen acceso de escritura. Es la misma lógica de una caja negra: no la custodia quien pilota.

La primera regla pide el registro de actividad de administración encendido en toda cuenta de producción. Una cuenta sin él es un incidente que no dejaría rastro: si pasa algo, no habrá nada que leer. Abre registro_por_cuenta; el guion significa vacío.

Otra cuenta sí tiene el registro encendido, pero lo guarda en su propia cuenta en lugar de enviarlo a la central. Cumple la primera regla y rompe la tercera. Es el tipo de hallazgo que no aparece si solo se pregunta «¿está activado?».

La política pide 365 días para la actividad de administración y 90 para el flujo de red. Un registro que se conserva menos que eso no alcanza para reconstruir un incidente que se descubre tarde: los incidentes suelen detectarse semanas después. Para decir cuánta retención falta, compara los días de fuentes_de_registro con los de la política y resta.

Una alerta es útil solo si llega a alguien que la atienda. En la exportación, cada alerta apunta a un buzón y la columna destinatario_activo dice si ese buzón tiene hoy a una persona responsable. Una alerta crítica dirigida a un buzón sin nadie detrás se dispara y no la lee nadie, lo cual es peor que no tenerla, porque da una falsa seguridad.