CloudTrail cerró la lección anterior con una limitación concreta y honesta: detecta eventos, no estados. Sabe que alguien llamó a DeleteBucketEncryption esta mañana. No sabe que mercadofresco-registros-web lleva cinco meses sin cifrado porque nunca se configuró. No sabe que hay un grupo de seguridad con 0.0.0.0/0 en el puerto 22 desde una prueba de marzo que nadie deshizo. No puede decir cuántos recursos de la cuenta incumplen el etiquetado obligatorio de MercadoFresco. Y desde luego no puede arreglar nada.

Esta es la quinta y última pregunta que dejó abierta el módulo 4: nada avisa si alguien desactiva el cifrado de un bucket o abre un grupo de seguridad al mundo.

AWS Config es la respuesta. Su idea es distinta a todo lo que hemos visto en este módulo: en lugar de registrar lo que pasa, fotografía continuamente cómo está configurado cada recurso, guarda el histórico de esas fotografías, y evalúa cada una contra un conjunto de reglas. Cuando una configuración se desvía de lo que debería ser, Config lo marca como no conforme, avisa, y —si se lo permites— lo corrige solo.

Es la diferencia entre una cámara de seguridad que graba a quien entra y un inventario que, cada noche, comprueba que todas las puertas están cerradas.

Aviso de coste. AWS Config es, junto con la ingesta de registros de CloudWatch, el servicio de este módulo que más fácilmente se dispara. Cobra por cada elemento de configuración registrado y por cada evaluación de regla. Una cuenta con un grupo de autoescalado que rota instancias todo el día puede generar decenas de miles de elementos al mes. Hay una sección entera con el cálculo y las cinco formas de controlarlo.

Aviso de cumplimiento. Este material es didáctico. Los paquetes de conformidad que se mencionan (CIS, PCI DSS) son ayudas, no certificaciones: activar un conformance pack no te hace conforme con PCI DSS. Cualquier uso de Config con finalidad de cumplimiento normativo real debe validarlo un profesional de cumplimiento.

1. Qué es la configuración de un recurso
2. El elemento de configuración y la línea temporal
3. Config frente a CloudTrail
4. El flujo completo: grabador, reglas y remediación
5. Activar el grabador de configuración
6. El canal de entrega: S3 y SNS
7. Elegir qué tipos de recurso se graban
8. Reglas: el corazón del servicio
9. Las reglas gestionadas que activa MercadoFresco
10. Disparo por cambio frente a disparo periódico
11. El etiquetado obligatorio con required-tags
12. Reglas personalizadas con Lambda
13. Reglas personalizadas con Guard
14. Remediación automática con Systems Manager
15. Los dos casos reales: cifrado de bucket y SG abierto
16. La advertencia de probar primero en modo manual
17. Paquetes de conformidad
18. El cuadro de cumplimiento de MercadoFresco
19. Consultas avanzadas para inventariar
20. Agregadores multicuenta
21. Security Hub y GuardDuty: dónde encaja cada uno
22. Coste real y cómo no dispararlo
23. Limpieza

La configuración de un recurso es el conjunto de propiedades que lo definen en un momento dado. No sus datos, no su tráfico: sus ajustes.

Config es capaz de grabar la configuración de más de 250 tipos de recurso de decenas de servicios, y de mantener el histórico completo de sus cambios.

Un elemento de configuración (CI, configuration item) es una fotografía completa de un recurso en un instante concreto. Config crea uno cada vez que detecta un cambio.

Tres campos merecen atención especial:

• relationships: Config no guarda recursos aislados, guarda el grafo. Sabe que este bucket está cifrado con esa clave KMS, que esa instancia está en esa subred, que ese SG está asociado a ese ALB. Cuando quieras saber qué se rompe si borras una clave, esto es lo que responde.
• supplementaryConfiguration: propiedades que no vienen en la llamada Describe principal y que Config recoge aparte. La política del bucket, por ejemplo.
• configurationItemStatus: OK, ResourceDiscovered, ResourceDeleted. Sí: Config graba también el borrado, así que puedes ver cómo estaba configurado un recurso que ya no existe.

La línea temporal (configuration timeline) es la secuencia de todos los CI de un recurso. Es la vista más potente de la consola de Config y responde a la pregunta que en operaciones se hace cada semana: «esto funcionaba el viernes; ¿qué ha cambiado?»

Y la consulta:

Son complementarios y se confunden constantemente. La tabla:

El ejemplo que lo fija. Alguien añade una regla SSH abierta a sg-mercadofresco-basedatos:

• CloudTrail: un evento AuthorizeSecurityGroupIngress, con la identidad, la hora y la IP de quien lo hizo. No dice cómo quedó el grupo de seguridad, solo qué se pidió.
• Config: un CI nuevo con la configuración completa del grupo después del cambio, la comparación con el CI anterior (el diff), la evaluación de la regla restricted-ssh marcándolo como NON_COMPLIANT, y —si está configurada— la remediación que revoca la regla.

Se usan juntos, y de hecho Config depende de CloudTrail: usa sus eventos para saber que algo ha cambiado y disparar la grabación de un CI nuevo.

Cinco piezas y su orden:

1. Grabador de configuración (configuration recorder): el proceso que crea los CI. Solo puede haber uno por cuenta y región.
2. Canal de entrega (delivery channel): dónde se depositan los CI (un bucket de S3) y a dónde se notifican los cambios (un tema de SNS). También uno por cuenta y región.
3. Reglas: las condiciones que se evalúan.
4. Remediación: la acción correctiva, ejecutada por Systems Manager Automation.
5. Agregador: la vista consolidada de varias cuentas y regiones (09-04).

Paso 1: el bucket del historial.

Con su política:

Paso 2: el rol de servicio. Config necesita permiso para leer la configuración de todo:

La política gestionada AWS_ConfigRole concede solo lectura sobre decenas de servicios. Config no necesita escribir nada: la remediación la ejecuta Systems Manager con otro rol distinto, que es donde estarán los permisos peligrosos. Esa separación es deliberada y buena.

Paso 3: el grabador.

Dos decisiones que aquí valen dinero:

• allSupported: false con lista explícita. Grabar los 250+ tipos soportados en una cuenta viva genera un volumen de CI enorme, y muchos no aportan nada.
• recordingModeOverrides con DAILY para instancias y volúmenes. Esta es la optimización más importante de toda la lección. El ASG asg-mercadofresco-tienda lanza y termina instancias en cada pico de los viernes; cada lanzamiento genera CI de la instancia, de sus volúmenes, de sus interfaces de red. En modo continuo son miles de CI al mes por un recurso efímero cuya configuración es siempre la misma —viene de lt-mercadofresco-tienda—. En modo diario, uno.

Paso 4: el canal de entrega.

Paso 5: arrancarlo. Igual que CloudTrail, crear no es arrancar:

Y una advertencia sobre el tema de SNS: si conectas todas las notificaciones de Config a alertas-mercadofresco, recibirás un mensaje por cada cambio de configuración de la cuenta. Con el ASG rotando, eso es ruido puro que hará que la gente deje de leer los avisos. La forma correcta es enviar por SNS solo las notificaciones de no conformidad, y eso se hace con EventBridge (07-03) filtrando el tipo de evento, o con un tema separado para el ruido. MercadoFresco usa el tema aquí únicamente porque el canal lo exige, y filtra en EventBridge lo que llega a las personas.

La tabla de decisión de MercadoFresco, que es el patrón que hay que copiar:

Las tres últimas filas son las que más dinero ahorran en cuentas reales. NetworkInterface y ManagedInstanceInventory son, con diferencia, los dos tipos que más CI generan por accidente.

Recursos globales: IAM y CloudFront son globales. Si activas includeGlobalResourceTypes en varias regiones, pagarás el mismo CI varias veces. Se activa en una sola región —MercadoFresco usa eu-west-1— y se graban explícitamente los tipos de IAM como hemos hecho arriba.

Una regla de Config evalúa recursos y les asigna un estado:

Hay tres clases de regla:

Empezar siempre por las gestionadas: cubren el 90 % de lo que necesitas y no hay que mantenerlas.

Son 29 reglas. Activarlas:

Y la consulta del estado general:

La distinción no es arbitraria. Una regla por cambio necesita un recurso al que asociarse. Reglas como cloudtrail-enabled o iam-password-policy evalúan una propiedad de la cuenta, no de un recurso concreto, así que solo pueden ser periódicas.

Y hay un matiz de coste importante: una regla por cambio sobre un tipo de recurso que cambia mucho —instancias EC2 con el ASG rotando— se evalúa muchísimas veces. Una regla periódica cada 24 horas se evalúa 30 veces al mes y punto. Cuando una comprobación no necesite detección inmediata, ponla periódica.

Se puede combinar:

Evalúa al cambiar y una vez al día, que es la red de seguridad por si se perdió algún CI.

El etiquetado de MercadoFresco es Proyecto, Entorno, Componente, Propietario, CentroCoste. Hasta ahora era una norma escrita que nadie comprobaba. Config la convierte en una regla:

Detalles de la sintaxis que no son evidentes:

• tagNKey sin tagNValue exige que la etiqueta exista, con cualquier valor. Así están Componente, Propietario y CentroCoste: sus valores son libres.
• tagNValue con una lista separada por comas exige que el valor sea uno de esos. Entorno solo puede ser produccion, preproduccion o desarrollo.
• Máximo 6 etiquetas por regla. Si necesitas más, dos reglas.

Y el resultado la primera vez que se ejecuta, que es el momento más instructivo:

La fila de los volúmenes es el hallazgo real, y es un problema que casi todo el mundo tiene sin saberlo: los volúmenes EBS creados automáticamente por un ASG no heredan las etiquetas de la instancia salvo que se configure explícitamente en la plantilla de lanzamiento:

Consecuencia directa y medible: en el módulo 11, cuando Sara reparta el coste por CentroCoste, los volúmenes de la tienda aparecerían como «sin asignar». Una regla de Config ha encontrado un agujero en la contabilidad de costes que nadie había visto en meses. Es el mejor argumento para activar required-tags desde el primer día.

Cuando ninguna regla gestionada sirve. El caso de MercadoFresco: ningún bucket de datos de negocio puede tener una regla de ciclo de vida que borre objetos antes de 30 días, porque Sara necesita poder recalcular informes del mes.

Cuatro cosas que hay que hacer bien y que se olvidan:

• Devolver NOT_APPLICABLE para lo que no aplica, no COMPLIANT. Si devuelves COMPLIANT para todos los buckets del mundo, el cuadro de cumplimiento miente: parecerá que 40 buckets cumplen una regla que solo aplica a dos.
• Tratar ResourceDeleted. Evaluar un recurso que ya no existe deja registros huérfanos marcados como no conformes para siempre.
• Annotation es el texto que se ve en la consola junto al recurso no conforme. Un buen mensaje ahí ahorra media hora de investigación. Máximo 256 caracteres.
• ResultToken hay que devolverlo tal cual. Es lo que asocia la respuesta con la evaluación.

Y el registro de la regla:

Coste: 0,001 USD por evaluación más el coste de la invocación de Lambda. Con pocos buckets es despreciable; con una regla personalizada sobre instancias EC2 en una cuenta con mucho movimiento, puede sorprender.

AWS CloudFormation Guard es un lenguaje declarativo de reglas, mucho más corto que una Lambda para comprobaciones sobre la configuración. Las reglas de Config escritas en Guard se llaman Custom Policy rules y no requieren ninguna función: no hay código que mantener, ni rol, ni coste de Lambda.

La misma idea de antes, en Guard, comprobando que los buckets de negocio están cifrados con la clave de MercadoFresco y no con la de AWS:

El bloque entre << y >> es el mensaje de error, que aparece como anotación en la consola.

La diferencia práctica: Guard solo puede mirar lo que hay en el elemento de configuración. Si tu comprobación necesita llamar a otra API —como el ejemplo de Lambda, que consultaba get_bucket_lifecycle_configuration—, necesitas Lambda. Para todo lo demás, Guard.

Detectar es bueno. Corregir solo es mejor, y es lo que convierte a Config en una herramienta operativa y no en un informe más que nadie lee.

La remediación se ejecuta con un documento de Systems Manager Automation: un procedimiento predefinido con pasos y parámetros. AWS proporciona docenas de documentos AWS-* listos para usar.

El rol de remediación. Aquí es donde están los permisos peligrosos, y por eso es un rol aparte del de Config, con el mínimo estricto:

Fíjate en tres decisiones de mínimo privilegio, todas del manual de 04-01:

• s3:PutEncryptionConfiguration solo sobre mercadofresco-*. El rol no puede tocar buckets ajenos.
• Condición de etiqueta en las acciones sobre SG: solo actúa sobre recursos del proyecto.
• No hay ec2:AuthorizeSecurityGroupIngress. El rol puede quitar reglas, nunca añadirlas. Si alguien comprometiera este rol, lo peor que podría hacer es cerrar cosas. Esa asimetría es deliberada y es el tipo de detalle que separa una configuración segura de una peligrosa.

Caso 1: reactivar el cifrado de un bucket.

El ResourceValue: RESOURCE_ID es la pieza clave: le dice a la remediación que el nombre del bucket sea el del recurso que ha fallado la evaluación. Sin eso, la remediación no sabría sobre qué actuar.

Cronología completa de lo que pasa ahora si alguien desactiva el cifrado:

Ocho minutos, sin intervención humana. Y con el rastro completo: CloudTrail sabe quién lo desactivó, Config sabe cómo quedó, la remediación lo arregló, y la línea temporal lo cuenta entero. Esa es la respuesta a la última pregunta del módulo 4.

Caso 2: revocar una regla de grupo de seguridad abierta al mundo.

Este documento revoca todas las reglas de entrada con origen 0.0.0.0/0 o ::/0 del grupo, no solo la del 22. Es agresivo, y hay que saberlo: si tu ALB público está en un grupo de seguridad que legítimamente permite 0.0.0.0/0 en el 443, esta remediación lo tumbaría.

Por eso MercadoFresco acota el alcance de la regla, no de la remediación:

Con TagKey/TagValue, la regla —y por tanto la remediación— solo se aplica a los grupos de seguridad etiquetados como Componente=basedatos. sg-mercadofresco-alb, que debe estar abierto al mundo en el 443, queda fuera. Es el mismo razonamiento del alcance mínimo que aplicábamos a las exclusiones de WAF en 04-05.

Caso 3, el más rentable: poner retención a los grupos de registros.

Esta es la que habría evitado el incidente de los 610 USD del ejercicio 3 de 05-01. Cualquier grupo de registros nuevo —creado por una Lambda, por el agente, por un servicio— recibe 30 días de retención automáticamente en cuestión de minutos. Es la remediación con mejor relación coste-beneficio de todo el módulo.

Nunca actives Automatic: true en una remediación que no hayas probado. Una remediación es código con permisos que modifica tu producción sin que nadie lo apruebe. Si está mal, lo hace muy rápido y en todas partes.

El procedimiento de MercadoFresco, y es innegociable:

Fase 1 — Solo detección, 1 semana. La regla, sin remediación. Se observa qué recursos marca. Aquí salen los falsos positivos: recursos que incumplen la letra de la regla por buenas razones.

Fase 2 — Remediación manual, 2 semanas. Automatic: false. La remediación existe pero hay que lanzarla a mano desde la consola, recurso a recurso:

Se ejecuta sobre un recurso poco crítico, se comprueba que hace exactamente lo esperado y nada más, y se revisa el registro de la ejecución en Systems Manager.

Fase 3 — Automática, con alcance acotado. Automatic: true, pero primero solo sobre los recursos etiquetados Entorno=desarrollo. Una semana. Después, producción.

Fase 4 — Con límites. MaximumAutomaticAttempts y RetryAttemptSeconds son un freno importante: si la remediación falla 3 veces, Config deja de intentarlo en lugar de entrar en bucle. Un bucle de remediación puede generar miles de llamadas a la API y una factura considerable.

Y tres tipos de remediación que MercadoFresco NO automatiza nunca:

La regla mental: automatiza lo que añade seguridad y es reversible (activar cifrado, poner retención, quitar acceso público). Nunca automatices lo que quita disponibilidad o es irreversible.

Un conformance pack es una plantilla que despliega un conjunto de reglas y remediaciones de golpe, como una unidad, y que se puede aplicar a toda una organización.

AWS publica plantillas alineadas con marcos conocidos:

La advertencia que hay que repetir. Desplegar el paquete de PCI DSS no te hace conforme con PCI DSS. Es una ayuda: comprueba automáticamente un subconjunto de controles técnicos. La conformidad real incluye procesos, formación, contratos, evaluaciones y una auditoría formal por un evaluador cualificado. Presentar un cuadro verde de Config como prueba de conformidad es un error serio. Estas decisiones las valida un profesional de cumplimiento, no un curso.

Coste: un paquete no cuesta nada por sí mismo; cuestan las reglas que contiene. Un paquete de PCI DSS con 90 reglas evaluándose sobre cientos de recursos es la forma más rápida de multiplicar la factura de Config por diez. Léelo antes de desplegarlo.

El primer resultado, tres días después de activar todo. Este es el momento realmente valioso, porque saca a la luz lo que llevaba meses ahí:

Seis reglas no conformes, 14 recursos. Y ninguno de esos catorce había disparado nunca una alarma de CloudWatch ni aparecido en una investigación de CloudTrail, porque ninguno era un evento: eran estados. Llevaban ahí meses.

Los tres hallazgos que Marta no esperaba:

1. mercadofresco-registros-web sin cifrado desde marzo. Se creó a mano en 03-03 para los registros del ALB, antes de que existiera la política de cifrado de 04-02, y nadie volvió.
2. El SG con el 22 abierto desde una prueba de mayo. La regla se añadió «un momento» para depurar y se quedó tres meses.
3. El grupo de seguridad por defecto de vpc-mercadofresco con reglas. Es el clásico de 03-02: nadie lo usa, pero está ahí, permisivo, esperando a que alguien lance una instancia sin especificar grupo.

El plan de corrección, ordenado por riesgo:

Fíjate en el patrón: las cuatro primeras se automatizan porque añaden seguridad y son reversibles. Las tres últimas requieren criterio humano, y por eso no se automatizan.

Config incluye un motor de consultas SQL sobre el inventario actual de todos los recursos grabados. Es una de sus funciones más infravaloradas.

Este motor responde en segundos a preguntas que de otro modo requerirían recorrer decenas de llamadas Describe paginadas. Y a diferencia de Athena sobre CloudTrail (05-03), no cuesta nada por consulta: es parte del servicio.

Una consulta que Marta ejecuta cada mes y que ya ha justificado el coste de Config varias veces:

Un volumen available es un volumen que existe, que se paga cada mes, y que no está conectado a nada. Suelen quedar de instancias terminadas. Es exactamente uno de los hallazgos que también reporta Trusted Advisor, que es la lección siguiente.

Un agregador consolida los datos de Config de varias cuentas y regiones en una sola vista.

Con AWS Organizations se usa --organization-aggregation-source y el agregador recoge automáticamente todas las cuentas de la organización, incluidas las que se creen en el futuro. Esa es la configuración correcta para cualquier empresa con varias cuentas, y es la lección 09-04.

MercadoFresco tiene una cuenta hoy, así que el agregador solo aporta la vista multirregión —útil para detectar recursos olvidados en regiones donde no se debería tener nada, el caso del ejercicio 3 de 05-03—.

Es fácil confundir estas tres herramientas. La tabla que las separa:

Ejemplos concretos que aclaran la división del trabajo:

• Config: «mercadofresco-registros-web no tiene cifrado.» Es un problema de configuración.
• GuardDuty: «Una instancia de asg-mercadofresco-tienda está resolviendo dominios asociados a minado de criptomonedas» o «credenciales del rol de instancia usadas desde una IP externa a AWS». Es un problema de intrusión, y ninguna regla de configuración lo detectaría.
• Security Hub: «Tu cuenta cumple el 82 % del CIS Benchmark; estos 14 hallazgos son críticos», con los hallazgos de Config y de GuardDuty en la misma lista priorizada.

Recomendación práctica: si vas a activar los tres, actívalos en este orden —Config primero, porque es la base y porque Security Hub consume sus reglas; GuardDuty después, porque es el que detecta lo que Config no puede ver; Security Hub al final, como capa de agregación—. Y ten presente que los tres cuestan dinero y los tres generan hallazgos que alguien tiene que leer. Activar los tres y no mirarlos es peor que activar solo Config y revisarlo mensualmente.

Cálculo para MercadoFresco:

Y ahora el mismo cálculo sin las optimizaciones, que es lo que le pasa a la mayoría de las cuentas:

Treinta y cuatro veces más caro, y con exactamente la misma capacidad de detección de los problemas que importan. La diferencia está entera en tres decisiones de configuración.

Las cinco formas de disparar la factura de Config, por frecuencia real:

1. allSupported: true en una cuenta con autoescalado. Cada lanzamiento de instancia genera CI de la instancia, sus volúmenes, sus interfaces de red y sus asociaciones. Miles al mes.
2. No usar recordingFrequency: DAILY para recursos efímeros. La optimización más rentable y la menos conocida.
3. Grabar recursos globales (IAM) en varias regiones. Se paga el mismo CI tantas veces como regiones tengan el grabador con includeGlobalResourceTypes.
4. Desplegar un conformance pack de 200 reglas sin leerlo. Cada regla se evalúa contra cada recurso aplicable, en cada cambio.
5. Reglas personalizadas con Lambda sobre tipos de recurso muy cambiantes. Se paga la evaluación y la invocación.

Las cinco defensas:

1. Lista explícita de resourceTypes, nunca allSupported.
2. recordingFrequency: DAILY para AWS::EC2::Instance, AWS::EC2::Volume y todo lo efímero.
3. Recursos globales en una sola región.
4. Reglas periódicas cada 24 h en vez de por cambio siempre que no necesites detección inmediata.
5. Un presupuesto de AWS Budgets filtrado por servicio = Config (módulo 11), con aviso al 80 %.

El paso 4 es el importante. Borrar reglas no detiene el gasto: los CI se siguen registrando mientras el grabador esté activo. Detener el grabador es lo que corta la facturación. Y si en algún momento ves un cargo de Config que no esperas, empieza siempre por describe-configuration-recorder-status en todas las regiones: un grabador olvidado en una región que no usas es un clásico.

1. Activar allSupported: true sin pensarlo. Es el error de coste número uno del servicio. Lista explícita, siempre.

2. No usar recordingFrequency: DAILY para instancias y volúmenes. Con un ASG activo, es la diferencia entre 6 y 216 USD al mes.

3. Grabar recursos globales en varias regiones. Se paga el mismo CI varias veces. IAM y CloudFront en una sola región.

4. Activar Automatic: true en una remediación sin probarla. Detección una semana, remediación manual dos semanas, automática en desarrollo una semana, y luego producción. Sin atajos.

5. Automatizar remediaciones destructivas. Borrar recursos, detener instancias o modificar IAM automáticamente puede convertir una regla mal escrita en una caída. Automatiza solo lo que añade seguridad y es reversible.

6. Confundir Config con CloudTrail. «¿Quién lo cambió?» → CloudTrail. «¿Cómo está y cumple?» → Config. Se usan juntos.

7. Devolver COMPLIANT en vez de NOT_APPLICABLE en una regla personalizada. El cuadro de cumplimiento queda inflado y deja de ser útil.

8. Conectar todas las notificaciones de Config a SNS. Un mensaje por cada cambio de configuración es ruido garantizado, y el ruido hace que la gente deje de leer los avisos importantes. Filtra con EventBridge (07-03) y envía a personas solo las no conformidades.

9. Creer que un conformance pack te certifica. No. Comprueba controles técnicos; la conformidad real incluye procesos, contratos y una auditoría formal. Que lo valide un profesional de cumplimiento.

10. Aplicar una remediación de SG sin acotar el alcance de la regla. RemoveUnrestrictedSourceIngressRules sobre sg-mercadofresco-alb tumbaría la tienda. Acota con TagKey/TagValue.

11. Borrar reglas creyendo que se detiene el gasto. Lo que factura son los CI del grabador. stop-configuration-recorder.

12. Olvidar start-configuration-recorder. Como con CloudTrail, crear no es arrancar.

13. Escribir una regla con Lambda cuando bastaba Guard. Si la comprobación solo mira el elemento de configuración, Guard es más corto, más barato y no hay que mantener un runtime.

Consejo final: activa Config con pocas reglas y bien elegidas antes que con un paquete de conformidad completo. Diez reglas que alguien revisa cada mes valen infinitamente más que doscientas que generan un cuadro rojo permanente al que todo el mundo se acostumbra. El objetivo no es tener muchas reglas: es llegar a cero no conformidades y que cualquier nueva sea una señal real.

MercadoFresco quiere activar Config con un presupuesto máximo de 12 USD al mes. Inventario real de la cuenta:

Requisitos: hay que detectar en menos de 15 minutos que un bucket pierde el cifrado o que un SG se abre al mundo; hay que comprobar el etiquetado obligatorio; hay que vigilar la retención de los grupos de registros.

Diseña: la lista de resourceTypes con su recordingFrequency, el conjunto de reglas con su tipo de disparo, y calcula el coste total. Justifica cada exclusión. Si te pasas del presupuesto, explica qué recortarías y qué capacidad de detección perderías.

MercadoFresco tiene una política interna: toda instantánea de RDS de más de 90 días debe estar cifrada y no debe ser pública, y las de más de 365 días deben borrarse salvo que lleven la etiqueta Retencion=legal.

• a) Explica por qué esta comprobación no se puede hacer con una sola regla gestionada, y qué reglas gestionadas cubren parte del problema.
• b) Escribe la regla personalizada (Lambda o Guard, justificando la elección) que evalúa las instantáneas.
• c) Diseña la remediación. Decide qué parte se automatiza y qué parte no, y justifícalo con el criterio de la lección.
• d) Calcula el coste añadido si MercadoFresco tiene 120 instantáneas y la regla es periódica cada 24 horas, frente a por cambio de configuración.

Un lunes, la regla mercadofresco-s3-cifrado marca mercadofresco-informes-analitica como NO CONFORME. La remediación automática está en modo manual todavía. Datos:

• La línea temporal muestra que el CI no conforme se creó el domingo a las 04:17.
• El CI anterior, del jueves, era conforme.
• La regla mercadofresco-etiquetado-obligatorio marca el mismo bucket como no conforme desde el domingo a las 04:17: le falta la etiqueta Propietario.
• Hay tres buckets nuevos en la cuenta, creados el domingo entre las 04:10 y las 04:25, ninguno con cifrado ni etiquetas.
• CloudTrail muestra 46 llamadas de escritura ese domingo entre las 04:05 y las 04:30, todas con userIdentity.type = "AssumedRole" y sessionIssuer.userName = "rol-despliegue-infra".

Explica: qué ha pasado con toda probabilidad; cómo lo confirmarías combinando Config y CloudTrail (con comandos y consultas concretas); por qué Config detectó algo que CloudTrail por sí solo no habría hecho saltar; qué remediación aplicarías y en qué orden; y qué arreglo de fondo propondrías para que no vuelva a ocurrir, indicando en qué módulo del curso se estudia.

Solución 1

Análisis del inventario. El problema está concentrado en tres filas: instancias (620), volúmenes (640) e interfaces de red (1.280). Son 2.540 de los 2.679 cambios mensuales: el 95 %. Todos generados por la rotación del ASG y todos de configuración idéntica, porque vienen de lt-mercadofresco-tienda.

Configuración propuesta del grabador:

Cálculo de elementos de configuración:

Reglas propuestas:

Coste total: 0,52 + 1,03 + ~0,02 de S3 = ~1,57 USD/mes. Muy por debajo de los 12 USD.

Con el margen sobrante se puede: añadir el paquete de conformidad CIS completo (~50 reglas, unos 3-4 USD más), pasar required-tags a disparo por cambio para detección más rápida, o incluir AWS::EC2::NetworkInterface si alguna vez hiciera falta para una investigación de red.

Justificación de las exclusiones:

• NetworkInterface: 1.280 CI (3,84 USD) por interfaces efímeras que el ASG crea y destruye. Su configuración es siempre la misma y viene de la plantilla de lanzamiento. Si hiciera falta investigar red, están los VPC Flow Logs (03-01) y CloudTrail (05-03).
• Instancias y volúmenes en modo diario: se pierde la detección inmediata de un cambio en una instancia concreta. ¿Importa? Las instancias son ganado, no mascotas: si una se degrada, el ASG la reemplaza. Los cambios que importan están en la plantilla de lanzamiento, no en la instancia. El compromiso es correcto.

Lo que se perdería recortando más: si hubiera que bajar de 1,57 USD, el siguiente recorte sería required-tags (0,75 USD, casi la mitad del total). Se perdería la detección del agujero de CentroCoste en los volúmenes, que en el módulo 11 vale mucho más de 0,75 USD. No se recorta.

Solución 2

a) Por qué no basta una regla gestionada.

Hay reglas gestionadas que cubren partes:

Lo que ninguna cubre es la lógica combinada: «más de 90 días y sin cifrar», «más de 365 días y sin la etiqueta Retencion=legal». Config no permite componer reglas gestionadas con condiciones entre ellas. Eso exige una regla propia.

b) La regla. Elección: Lambda, no Guard.

Guard solo puede mirar lo que está en el elemento de configuración. Aquí necesitamos calcular la antigüedad respecto a la fecha actual, y Guard no tiene aritmética de fechas contra «ahora». Además, conviene un disparo periódico que evalúe todas las instantáneas, no solo las que cambian —una instantánea no cambia: simplemente envejece—. Ese es el argumento decisivo: el incumplimiento aparece con el paso del tiempo, no con un cambio de configuración.

Cuatro detalles que hacen que esta función funcione en producción y no solo en el ejemplo:

• SnapshotType="manual": las automáticas las gestiona RDS con su propia retención (02-04) y se borran solas. Evaluarlas generaría no conformidades imposibles de remediar.
• put_evaluations en lotes de 100: es el límite de la API. Con 120 instantáneas, una sola llamada fallaría.
• Annotation con la edad concreta: quien mire la consola sabrá inmediatamente de qué se trata.
• La comprobación de publicidad hace una llamada extra por instantánea. Con 120 instantáneas son 120 llamadas cada 24 horas: aceptable. Con 10.000, habría que paralelizar o separar en otra regla.

c) La remediación, y aquí está el criterio.

Esa tabla es exactamente la regla de la lección: automatiza lo que añade seguridad y es reversible; nunca lo destructivo. La instantánea pública se cierra sola en minutos; el borrado lo aprueba una persona.

Para las dos que no se automatizan, la respuesta correcta es notificar bien: una regla de EventBridge (07-03) que capture el cambio a no conformidad y envíe a alertas-mercadofresco un mensaje que incluya la Annotation de la evaluación, que es donde está la explicación concreta («412 días de antigüedad y sin cifrar»). Un aviso que solo dice «hay un recurso no conforme» obliga a entrar en la consola; uno que dice qué instantánea y por qué se resuelve desde el móvil.

Y una revisión trimestral en el calendario de Marta para decidir qué se borra, con la lista delante.

d) Coste.

Opción periódica cada 24 horas:

• 120 instantáneas × 30 días = 3.600 evaluaciones/mes = 3,60 USD
• Invocaciones de Lambda: 30/mes (una por evaluación de la regla, no por instantánea) ≈ 0,00 USD
• Llamadas a la API de RDS: gratuitas
• Total: ~3,60 USD/mes

Opción por cambio de configuración:

• Las instantáneas manuales cambian poquísimo: quizá 10 CI/mes.
• 10 evaluaciones = 0,01 USD
• Total: ~0,01 USD/mes

Pero la opción por cambio NO SIRVE, y esa es la conclusión del apartado. El incumplimiento aquí aparece con el paso del tiempo, no con un cambio: una instantánea creada hoy sin cifrar es conforme, y dentro de 91 días deja de serlo sin que nada haya cambiado en ella. Una regla por cambio nunca la volvería a evaluar y la no conformidad jamás se detectaría.

3,60 USD al mes es el precio de detectar incumplimientos que dependen del tiempo, y TwentyFour_Hours ya es la frecuencia periódica más espaciada que admite Config: no hay margen por ahí. La única palanca real de ahorro sería emitir una sola evaluación agregada por regla en lugar de una por instantánea, pero entonces la consola diría «la regla no se cumple» sin decir cuál de las 120 instantáneas es la culpable, que es justo el dato que hace falta para actuar. Se paga el detalle, y merece la pena.

Solución 3

Qué ha pasado, con toda probabilidad.

Los datos apuntan de forma inequívoca a un despliegue automatizado de infraestructura el domingo de madrugada que creó recursos sin las propiedades obligatorias, y que además modificó un bucket existente.

Las pistas, en orden:

1. Domingo a las 04:17, hora sin actividad humana: es un proceso automático.
2. rol-despliegue-infra con 46 llamadas de escritura en 25 minutos: es un pipeline o una ejecución de infraestructura como código.
3. Tres buckets nuevos sin cifrado ni etiquetas, creados en la misma ventana.
4. Un bucket existente que pasó de conforme a no conforme exactamente a la misma hora.

El punto 4 es el más grave y el más revelador: la plantilla no solo creó recursos nuevos mal configurados, sino que redefinió un bucket que ya existía, sobrescribiendo su cifrado y sus etiquetas con una definición incompleta. Es el patrón clásico de una plantilla de CloudFormation o Terraform que declara un recurso que ya existía y lo «alinea» con una especificación pobre.

Confirmación, paso a paso.

1. Ver exactamente qué cambió en el bucket (esto es lo que solo Config puede dar):

Comparando el CI del jueves con el del domingo se ve el diff: serverSideEncryptionConfiguration desapareció y las etiquetas se redujeron. Esto es información que CloudTrail no tiene: CloudTrail registra la llamada PutBucketEncryption o su ausencia, pero no el estado resultante completo del bucket.

2. Ver quién hizo la llamada concreta (esto es lo que solo CloudTrail puede dar):

Se busca: el userAgent (¿cloudformation.amazonaws.com? ¿Terraform/1.7?), el nombre de sesión, y si hay un DeleteBucketEncryption explícito o simplemente un CreateBucket sobre un bucket existente.

3. Ver todos los recursos afectados a la vez, con la consulta avanzada de Config:

4. Cuadro de cumplimiento completo, para ver si hay más daños de los que se sabía:

Por qué CloudTrail solo no habría hecho saltar nada.

Esta es la pregunta central del ejercicio, y hay tres razones:

1. CloudTrail no evalúa. Registra 46 llamadas de un rol de despliegue un domingo. Eso es completamente normal para un pipeline programado. No hay nada anómalo en el evento en sí.
2. La alarma de 05-03 no habría saltado. Los filtros de métricas que montamos vigilaban DeleteBucketEncryption y PutBucketPolicy, pero desde un rol de despliegue legítimo, y probablemente sin DeleteBucketEncryption explícito: si la plantilla simplemente no declara cifrado al crear el bucket, no hay ninguna llamada que registrar. La ausencia de una llamada no genera un evento.
3. CloudTrail no conoce la política de MercadoFresco. No sabe que todos los buckets deben estar cifrados ni que hacen falta cinco etiquetas. Config sí, porque se lo hemos dicho con reglas.

Config detecta el estado resultante; CloudTrail detecta el acto. Aquí el acto era legítimo y el estado resultante no lo era. Ese es exactamente el hueco que esta lección viene a cubrir.

Remediación, en orden de riesgo:

El paso 3 merece comentario: los objetos escritos mientras el cifrado por defecto estaba desactivado se guardaron sin cifrar, y activarlo ahora no los cifra retroactivamente. Hay que reescribirlos:

Este detalle se pasa por alto constantemente y es lo que convierte un incidente de configuración en un incidente de datos.

Los arreglos de fondo, que son la parte importante:

La lección de fondo, y merece subrayarse porque es el argumento más fuerte a favor de este servicio: la misma regla de Guard que escribes para Config puede ejecutarse en el pipeline con cfn-guard antes del despliegue. Config es la red de seguridad que atrapa lo que se escapó; la validación en el pipeline es la que evita que se escape. Las dos, con la misma regla escrita una vez. Ese es el patrón que MercadoFresco adopta, y que se cierra en el módulo 8.

MercadoFresco ya tiene la última pieza que le faltaba. Sabes qué es la configuración de un recurso —sus ajustes, no sus datos— y qué es un elemento de configuración: una fotografía completa con sus relationships, su supplementaryConfiguration y su estado, que Config crea en cada cambio y que incluso registra cuando el recurso se borra. Conoces la línea temporal, que responde a la pregunta que se hace cada semana en operaciones: «esto funcionaba el viernes; ¿qué ha cambiado?».

Tienes clara la diferencia esencial con la lección anterior: CloudTrail graba la llamada, Config graba el estado. CloudTrail dice quién llamó a AuthorizeSecurityGroupIngress; Config dice cómo quedó el grupo de seguridad, si cumple, y lo arregla. Y sabes que Config depende de CloudTrail para enterarse de los cambios: no compiten, se apoyan.

Has activado el grabador grabador-mercadofresco con su rol de solo lectura, su canal hacia mercadofresco-config-historial y su tema de SNS, con las dos decisiones que valen dinero: allSupported: false con lista explícita, y recordingFrequency: DAILY para instancias y volúmenes, que es la optimización más rentable y menos conocida del servicio. Y sabes que crear no es arrancar: start-configuration-recorder.

Conoces las 29 reglas gestionadas que MercadoFresco activa, cada una atada a algo que construimos en un módulo anterior —s3-bucket-server-side-encryption-enabled por 04-02, restricted-ssh por 03-02, cloudtrail-enabled por 05-03, cw-loggroup-retention-period-check por el incidente de 610 USD de 05-01— y la diferencia entre disparo por cambio (minutos, pero se evalúa en cada cambio) y periódico (hasta 24 horas, pero coste fijo y única opción para comprobaciones de cuenta). required-tags te ha encontrado el agujero que nadie veía: los volúmenes EBS creados por el ASG no heredan etiquetas, y en el módulo 11 habrían aparecido como coste sin asignar.

Sabes escribir reglas propias: con Lambda cuando necesitas llamar a otras API o calcular con fechas —devolviendo NOT_APPLICABLE en lugar de COMPLIANT, tratando ResourceDeleted y escribiendo una Annotation útil— y con Guard, declarativo, sin runtime, sin coste extra y sin mantenimiento, que es lo que hay que usar por defecto cuando basta con mirar el elemento de configuración.

Y has montado la remediación automática con documentos de Systems Manager, que es lo que convierte Config en una herramienta operativa: AWS-EnableS3BucketEncryption restaura el cifrado de un bucket en ocho minutos sin intervención humana, RemoveUnrestrictedSourceIngressRules cierra un grupo de seguridad abierto, y SetCloudWatchLogGroupRetention pone 30 días a cualquier grupo de registros nuevo. Con el rol de remediación separado del de Config, con permisos acotados por prefijo y por etiqueta, y sin AuthorizeSecurityGroupIngress: el rol puede cerrar, nunca abrir. Y con el procedimiento innegociable de cuatro fases —detección, remediación manual, automática en desarrollo, automática en producción— y la regla que resume todo: automatiza lo que añade seguridad y es reversible; nunca lo destructivo ni lo que quita disponibilidad.

Conoces los paquetes de conformidad alineados con CIS, PCI DSS, NIST y RGPD, con la advertencia que hay que repetir siempre: desplegar el paquete de PCI DSS no te hace conforme con PCI DSS. Y el cuadro de cumplimiento te ha dado el resultado que justifica el servicio entero: seis reglas no conformes y catorce recursos, entre ellos un bucket sin cifrar desde marzo, un puerto 22 abierto desde mayo y el grupo de seguridad por defecto con reglas. Catorce problemas que llevaban meses ahí y que nunca habrían disparado una alarma de CloudWatch ni aparecido en una investigación de CloudTrail, porque no eran eventos: eran estados.

Y tienes las consultas avanzadas, gratuitas, que inventarían la cuenta en segundos: buckets sin cifrar, volúmenes sin asociar que se pagan cada mes sin servir para nada, recursos sin CentroCoste. Con el agregador para la vista multicuenta que llegará en 09-04, y el reparto claro de trabajo con GuardDuty —que detecta intrusiones, no configuraciones— y Security Hub, que agrega los hallazgos de todos.

Todo por unos 6,40 USD al mes, frente a los 216 USD que costaría exactamente la misma capacidad de detección sin las tres decisiones de configuración correctas. Ese factor de treinta y cuatro es el resumen de por qué esta lección dedica una sección entera al coste.

Con esto quedan respondidas las cinco preguntas del módulo 4. El aviso llega de verdad, los registros están correlacionados, el pedido de ocho segundos tiene culpable y arreglo, sabemos quién descifró la copia, y ahora nada puede desactivar el cifrado de un bucket sin que salte un aviso —y se corrija solo en ocho minutos—.

Queda una última pieza, y es distinta de todo lo anterior. Config comprueba las reglas que tú le has dicho. Es potente y es exacto, pero tiene un límite evidente: no puede avisarte de lo que no se te ha ocurrido. No sabe que tienes tres volúmenes EBS huérfanos costando dinero, ni que hay una IP elástica sin asociar que se factura por no usarse, ni que el asg-mercadofresco-tienda está a punto de chocar con una cuota de servicio que nadie ha mirado nunca, ni que una de tus instancias lleva dos meses al 4 % de CPU. Nadie ha escrito reglas para eso, y nadie las escribirá, porque para escribirlas habría que sospechar primero que el problema existe.

Existe un servicio que hace precisamente ese repaso: comparar tu cuenta con las buenas prácticas que AWS ha destilado de millones de clientes, y decirte lo que no habías pensado en preguntar. En la lección 05-05, «AWS Trusted Advisor», veremos sus cinco categorías —optimización de costes, rendimiento, seguridad, tolerancia a fallos y límites de servicio—, qué comprobaciones ves de verdad con el plan de soporte Basic y cuáles no, cómo suplir lo que falta con lo que ya sabes, un recorrido comentado por un informe real de la arquitectura de MercadoFresco, las cuotas de servicio y el caso concreto del ASG que no puede pasar de cuatro instancias por un límite de vCPU que nadie había mirado, y la rutina de revisión mensual que adopta Marta. Y con ella cerraremos el módulo entero.