Seguridad de las automatizaciones: credenciales, permisos y rastro

Una automatización es un usuario más: entra a sistemas, lee información y ejecuta operaciones. La diferencia es que no olvida, no se cansa y nadie la ve trabajar. Por eso sus credenciales, sus permisos y su rastro merecen el mismo gobierno que los de una persona, y con frecuencia reciben bastante menos.

A continuación: por qué la credencial incrustada es el problema central, qué permisos corresponden, cómo se separa quién ordena de quién ejecuta, qué rastro exige una auditoría y qué revisar periódicamente.

Cuando una organización pasa de tres automatizaciones a treinta, aparece una pregunta que nadie hizo al principio: ¿con qué usuario entran a los sistemas? La respuesta habitual, y la incómoda, es que con el de la persona que las construyó.

Ese arreglo funciona hasta que esa persona cambia de rol, rota su contraseña o se va. Entonces varias automatizaciones dejan de funcionar a la vez y nadie sabe cuáles ni por qué, lo que es a la vez un incidente operativo y la señal de un problema de control más profundo.

La credencial incrustada, que es el problema central

Escribir un usuario y una contraseña dentro del proceso es la práctica más extendida y la que más consecuencias acumula. Además del riesgo evidente —queda en texto legible para quien pueda ver el proyecto— garantiza una interrupción cada vez que la política de seguridad hace su trabajo y rota la contraseña.

El efecto perverso es conocido: los equipos piden que las credenciales de las automatizaciones queden exentas de rotación, y una política correcta termina debilitada para que los robots no se rompan.

La alternativa es un almacén de secretos del que la automatización obtiene la credencial en tiempo de ejecución. No es exótico ni caro, y resuelve las dos cosas a la vez: la contraseña deja de estar en el proyecto y puede rotarse sin romper nada.

Qué permisos corresponden

El criterio es el mismo que para una persona, aplicado con más rigor porque el alcance es mayor. Una automatización debe poder hacer exactamente lo que su proceso requiere y nada más.

En la práctica esto se incumple por comodidad. Es más rápido pedir un perfil amplio que enumerar operaciones, y quien concede el acceso rara vez tiene contexto para discutirlo. El resultado es un usuario técnico con permisos de administrador ejecutando una tarea de lectura.

Conviene además una identidad por automatización, no una compartida por todas. Cuesta un poco más de administración y devuelve algo que no se puede obtener después: saber qué proceso hizo qué. Con una credencial compartida, el registro de auditoría dice que «el robot» modificó un registro, lo cual no responde ninguna pregunta útil.

Separar quién ordena de quién ejecuta

Hay una categoría de riesgo específica de la automatización que no existe con trabajo manual: quien puede modificar el proceso puede, en la práctica, ejecutar cualquier operación que ese proceso tenga permitida.

Si una automatización de pagos tiene permiso para ordenar transferencias, quien pueda editar su lógica tiene ese mismo poder sin pasar por ninguna aprobación. No hace falta mala intención para que eso sea un problema de control: basta con que un auditor pregunte quién puede hacer qué.

El diseño que lo resuelve separa los entornos —construir no es publicar— y exige aprobación de un segundo par de ojos para pasar a producción. Es la misma disciplina que se aplica a cualquier software, y las automatizaciones suelen quedar fuera de ella porque se perciben como configuración y no como código.

El rastro que exige una auditoría

Tres registros responden casi cualquier pregunta razonable. Qué hizo: cada operación con su resultado y su marca de tiempo. Con qué entrada: qué caso procesó y de dónde lo tomó. Y quién la cambió: historial de modificaciones de la propia automatización, con autor y fecha.

El tercero es el que casi nunca existe y el que más se pide. Cuando una cifra sale mal, la pregunta no es qué hizo el robot ayer sino desde cuándo lo hace así, y sin historial de cambios no hay forma de contestar.

Conviene además decidir cuánto se conserva. En operaciones sujetas a revisión, los registros de lo que tocó datos financieros o personales tienen requisitos propios, y la decisión de retención se toma junto con ciberseguridad y no por defecto del sistema.

El caso de las automatizaciones que un área construyó sola

Las herramientas de bajo código pusieron la capacidad de automatizar en manos de gente que no pertenece a TI, y eso es bueno: quien conoce el proceso suele ser quien mejor lo automatiza. Trae, eso sí, un problema de control que conviene nombrar antes de que crezca.

Una automatización construida por un área suele ejecutarse con la credencial personal de quien la hizo, vivir en su equipo o en su cuenta, y no aparecer en ningún inventario. Funciona perfectamente hasta que esa persona cambia de rol, y entonces nadie sabe que existía hasta que algo deja de llegar.

La respuesta que funciona no es prohibirlas, porque volverán a aparecer sin permiso. Es ofrecer un camino: un lugar donde registrarlas, identidades técnicas disponibles sin un trámite de tres semanas, y una revisión ligera antes de que toquen datos sensibles o sistemas productivos. Un gobierno que cuesta menos que esconderse es un gobierno que se cumple.

Qué revisar, y cada cuánto

Cuatro cosas, en una revisión que puede ser trimestral y ocupar poco tiempo si el inventario existe. Automatizaciones activas contra inventario: qué corre que nadie registró. Permisos contra necesidad: qué accesos se concedieron para algo que ya no se hace. Credenciales: cuáles siguen incrustadas y cuáles no rotan. Y responsables: qué piezas quedaron sin dueño tras un cambio de equipo.

La primera suele dar sorpresas. En organizaciones sin gobierno de automatización es habitual encontrar procesos corriendo cuyo propósito nadie recuerda, y esa es una decisión de retiro antes que de seguridad.

Conviene que la revisión produzca decisiones y no un informe. Cada hallazgo debería salir con una de tres etiquetas —se corrige, se acepta con justificación escrita, o se retira la pieza— y con una fecha. Una lista de observaciones sin dueño ni plazo reaparece idéntica en la revisión siguiente, y a la tercera vez el ejercicio pierde credibilidad y se deja de hacer.

Dónde encaja esta disciplina

Estas decisiones no pertenecen al proyecto que construye una automatización: pertenecen al estándar bajo el que se construyen todas. Definirlas caso por caso produce treinta criterios distintos y ningún control.

Es una de las decisiones que concentra un centro de excelencia, junto con qué entra al portafolio y quién responde por cada pieza. Y cuando la operación diaria se delega, forma parte de lo que cubre un modelo de servicios administrados: vigilar que las piezas corran, que sus credenciales estén vigentes y que alguien reaccione cuando fallan.

La evaluación del punto de partida la hace un assessment de ciberseguridad, que revisa control de accesos e identidades entre sus dominios y contrasta la postura con el marco de protección de datos que aplica en Colombia o en México.

Preguntas frecuentes

¿Con qué usuario deben entrar las automatizaciones a los sistemas?

Con una identidad propia por automatización, nunca con la de la persona que la construyó ni con una credencial compartida entre todas. Una identidad por pieza es lo único que permite saber después qué proceso hizo qué.

¿Dónde se guardan las credenciales?

En un almacén de secretos del que la automatización las obtiene en tiempo de ejecución, no escritas dentro del proceso. Así la contraseña puede rotar sin romper nada y deja de estar en texto legible en el proyecto.

¿Qué permisos debe tener una automatización?

Exactamente los que su proceso requiere. En la práctica se conceden perfiles amplios por comodidad, y es habitual encontrar un usuario técnico con permisos de administrador ejecutando una tarea de solo lectura.

¿Cuál es el riesgo específico de la automatización?

Que quien puede modificar el proceso puede ejecutar cualquier operación que ese proceso tenga permitida, sin pasar por aprobación. Se controla separando construir de publicar y exigiendo un segundo par de ojos para producción.

¿Qué registros hay que conservar?

Qué hizo la automatización con su marca de tiempo, con qué entrada, y quién la modificó. El tercero casi nunca existe y es el que más se pide: cuando una cifra sale mal, la pregunta es desde cuándo se comporta así.

¿Cada cuánto conviene revisar?

Trimestralmente basta si existe inventario: automatizaciones activas contra inventario, permisos contra necesidad real, credenciales incrustadas o sin rotar, y piezas que quedaron sin responsable tras un cambio de equipo.