Los riesgos de automatizar, cuentas, dueños y silencios

Cada tarea automática corre con una cuenta de servicio, y los permisos de esa cuenta son el daño máximo posible si el script se equivoca o alguien lo modifica. Una tarea que solo exporta datos no necesita la cuenta que puede cambiarlo todo en el directorio de usuarios. El análisis empieza por ordenar las automatizaciones por el alcance de sus permisos.

Abre inventario-de-automatizaciones.txt y busca la tarea con el permiso más amplio de toda la tabla.

El principio de mínimo privilegio dice que cada tarea debe tener los permisos que necesita y no más. En la práctica son cuentas separadas por tarea, con un alcance acotado a lo que la tarea toca, y una revisión periódica para que los permisos no crezcan sin que nadie lo note. Una cuenta compartida entre muchas tareas hace lo contrario: junta todos los riesgos en una sola credencial.

Una automatización sin dueño no se revisa, no se actualiza cuando cambia el entorno y, cuando falla, no hay a quién avisar. El dueño no tiene que ser quien la escribió: es quien responde por ella. Contar las que no lo tienen mide cuánta parte del inventario depende de la buena suerte.

Una revisión aprueba un archivo en una fecha. Si el archivo se modifica después, la aprobación ya no corresponde a lo que corre. Comparar la fecha de la última modificación con la de la última aprobación es una de las comprobaciones más baratas y más reveladoras de todo el inventario.

Abre versiones-y-aprobaciones.txt y compara las dos columnas de fechas fila por fila.

La nota de incidente cuenta que nadie recibió alerta, porque la tarea terminó con código 0. Casi todos los silencios se contienen con el mismo control: que la propia tarea avise cuando falla o cuando no se ejecuta, y que el aviso llegue a alguien con nombre. Revisar los registros a mano una vez al mes llega tarde y depende de que alguien se acuerde.