Remediación automática y su riesgo

Una remediación automática es una identidad con permisos de escritura que actúa sin que nadie la mire, a la hora que sea, sobre recursos de producción. El riesgo tiene dos caras. Una: la remediación puede romper un uso legítimo (el recurso estaba "mal" según la regla pero era así a propósito). Otra: la identidad que remedia puede tener más permisos de los que necesita, y entonces es una pieza que alguien puede abusar o que se equivoca con más alcance.

Las dos se reducen igual: acotar lo que la remediación toca, lo que puede hacer, y cuándo hace falta que una persona dé el visto bueno.

El orden sensato empieza por mirar y termina, solo para lo que lo merece, en automático. Primero se activa la regla en modo detectar y se mide qué recursos tocaría. Luego se pasa a una remediación manual, que alguien lanza tras revisar cada caso. Solo después, y para tipos de recurso de bajo riesgo y comportamiento bien entendido, se automatiza, con un alcance limitado (por ejemplo, cuentas de desarrollo antes que producción), un tope de intentos y una alerta cada vez que actúe.

En AWS Config, MaximumAutomaticAttempts y RetryAttemptSeconds acotan los reintentos de una remediación automática fallida; no sustituyen a la revisión previa de lo que la remediación hace.

Abre registro-remediacion.log. Cuenta lo que pasó entre las 02:10 y las 03:44 de una noche: qué regla detectó qué, qué acción se ejecutó y qué alarma saltó después. El efecto lo dice el propio registro: una acción que tuvo éxito técnico y dejó un servicio de cara al cliente respondiendo 403.

rol-remediacion-s3.json es la política de permisos del rol que ejecuta la remediación. La nota del propio archivo dice qué hace de verdad el documento: activar el bloqueo de acceso público de un bucket y consultarlo. Todo permiso que no sirva a eso es superficie de más, y cuanto más amplio es el rol, más daño hace una remediación equivocada o una identidad comprometida.

Compara lo que el documento necesita con lo que el rol puede hacer. Hay un permiso que no tiene nada que ver con el bloqueo de acceso público y que además puede destruir datos.

La primera remediación y la primera reversión manual delimitan el tiempo en que el portal estuvo sin servicio por la regla. En el registro, la alarma salta a los pocos minutos y la persona de guardia deshace el bloqueo más tarde, con un ticket de incidente. Después se ve algo peor: la regla vuelve a evaluar, vuelve a detectar y vuelve a remediar, porque el recurso incumple la regla otra vez.

Mide el primer tramo: desde que la remediación se ejecuta hasta que alguien revierte a mano.