CloudTrail va tancar la lliçó anterior amb una limitació concreta i honesta: detecta esdeveniments, no estats. Sap que algú va cridar DeleteBucketEncryption aquest matí. No sap que mercadofresco-registros-web fa cinc mesos que no té xifratge perquè no es va configurar mai. No sap que hi ha un grup de seguretat amb 0.0.0.0/0 al port 22 des d'una prova de març que ningú no va desfer. No pot dir quants recursos del compte incompleixen l'etiquetatge obligatori de MercadoFresco. I, per descomptat, no pot arreglar res.

Aquesta és la cinquena i última pregunta que va deixar oberta el mòdul 4: res no avisa si algú desactiva el xifratge d'un bucket o obre un grup de seguretat al món.

AWS Config és la resposta. La seva idea és diferent de tot el que hem vist en aquest mòdul: en lloc de registrar el que passa, fotografia contínuament com està configurat cada recurs, desa l'historial d'aquestes fotografies i avalua cadascuna contra un conjunt de regles. Quan una configuració es desvia del que hauria de ser, Config ho marca com a no conforme, avisa i —si l'hi permets— ho corregeix sol.

És la diferència entre una càmera de seguretat que grava qui entra i un inventari que, cada nit, comprova que totes les portes estan tancades.

Avís de cost. AWS Config és, juntament amb la ingesta de registres de CloudWatch, el servei d'aquest mòdul que es dispara amb més facilitat. Cobra per cada element de configuració enregistrat i per cada avaluació de regla. Un compte amb un grup d'autoescalat que rota instàncies tot el dia pot generar desenes de milers d'elements al mes. Hi ha una secció sencera amb el càlcul i les cinc maneres de controlar-lo.

Avís de compliment. Aquest material és didàctic. Els paquets de conformitat que s'hi esmenten (CIS, PCI DSS) són ajudes, no certificacions: activar un conformance pack no et fa conforme amb PCI DSS. Qualsevol ús de Config amb finalitat de compliment normatiu real l'ha de validar un professional de compliment.

1. Què és la configuració d'un recurs
2. L'element de configuració i la línia temporal
3. Config enfront de CloudTrail
4. El flux complet: enregistrador, regles i remediació
5. Activar l'enregistrador de configuració
6. El canal de lliurament: S3 i SNS
7. Triar quins tipus de recurs s'enregistren
8. Regles: el cor del servei
9. Les regles gestionades que activa MercadoFresco
10. Activació per canvi enfront d'activació periòdica
11. L'etiquetatge obligatori amb required-tags
12. Regles personalitzades amb Lambda
13. Regles personalitzades amb Guard
14. Remediació automàtica amb Systems Manager
15. Els dos casos reals: xifratge de bucket i SG obert
16. L'advertència de provar primer en mode manual
17. Paquets de conformitat
18. El quadre de compliment de MercadoFresco
19. Consultes avançades per inventariar
20. Agregadors multicompte
21. Security Hub i GuardDuty: on encaixa cadascun
22. Cost real i com no disparar-lo
23. Neteja

La configuració d'un recurs és el conjunt de propietats que el defineixen en un moment donat. No les seves dades, no el seu trànsit: els seus ajustos.

Config és capaç d'enregistrar la configuració de més de 250 tipus de recurs de desenes de serveis, i de mantenir l'historial complet dels seus canvis.

Un element de configuració (CI, configuration item) és una fotografia completa d'un recurs en un instant concret. Config en crea un cada vegada que detecta un canvi.

Tres camps mereixen una atenció especial:

• relationships: Config no desa recursos aïllats, desa el graf. Sap que aquest bucket està xifrat amb aquella clau KMS, que aquella instància és en aquella subxarxa, que aquell SG està associat a aquell ALB. Quan vulguis saber què es trenca si esborres una clau, això és el que respon.
• supplementaryConfiguration: propietats que no arriben a la crida Describe principal i que Config recull a part. La política del bucket, per exemple.
• configurationItemStatus: OK, ResourceDiscovered, ResourceDeleted. Sí: Config també enregistra l'esborrament, així que pots veure com estava configurat un recurs que ja no existeix.

La línia temporal (configuration timeline) és la seqüència de tots els CI d'un recurs. És la vista més potent de la consola de Config i respon a la pregunta que a operacions es fa cada setmana: «això funcionava divendres; què ha canviat?»

I la consulta:

Són complementaris i es confonen constantment. La taula:

L'exemple que ho fixa. Algú afegeix una regla SSH oberta a sg-mercadofresco-basedatos:

• CloudTrail: un esdeveniment AuthorizeSecurityGroupIngress, amb la identitat, l'hora i la IP de qui ho va fer. No diu com va quedar el grup de seguretat, només què es va demanar.
• Config: un CI nou amb la configuració completa del grup després del canvi, la comparació amb el CI anterior (el diff), l'avaluació de la regla restricted-ssh marcant-lo com a NON_COMPLIANT, i —si està configurada— la remediació que revoca la regla.

S'usen junts, i de fet Config depèn de CloudTrail: fa servir els seus esdeveniments per saber que alguna cosa ha canviat i disparar l'enregistrament d'un CI nou.

Cinc peces i el seu ordre:

1. Enregistrador de configuració (configuration recorder): el procés que crea els CI. Només pot haver-hi un per compte i regió.
2. Canal de lliurament (delivery channel): on es dipositen els CI (un bucket de S3) i on es notifiquen els canvis (un tema d'SNS). També un per compte i regió.
3. Regles: les condicions que s'avaluen.
4. Remediació: l'acció correctiva, executada per Systems Manager Automation.
5. Agregador: la vista consolidada de diversos comptes i regions (09-04).

Pas 1: el bucket de l'historial.

Amb la seva política:

Pas 2: el rol de servei. Config necessita permís per llegir la configuració de tot:

La política gestionada AWS_ConfigRole concedeix només lectura sobre desenes de serveis. Config no necessita escriure res: la remediació l'executa Systems Manager amb un altre rol diferent, que és on hi haurà els permisos perillosos. Aquesta separació és deliberada i bona.

Pas 3: l'enregistrador.

Dues decisions que aquí valen diners:

• allSupported: false amb llista explícita. Enregistrar els 250+ tipus admesos en un compte viu genera un volum de CI enorme, i molts no aporten res.
• recordingModeOverrides amb DAILY per a instàncies i volums. Aquesta és l'optimització més important de tota la lliçó. L'ASG asg-mercadofresco-tienda llança i acaba instàncies a cada pic dels divendres; cada llançament genera CI de la instància, dels seus volums, de les seves interfícies de xarxa. En mode continu són milers de CI al mes per un recurs efímer amb una configuració sempre idèntica —ve de lt-mercadofresco-tienda—. En mode diari, un.

Pas 4: el canal de lliurament.

Pas 5: engegar-lo. Igual que amb CloudTrail, crear no és engegar:

I una advertència sobre el tema d'SNS: si connectes totes les notificacions de Config a alertas-mercadofresco, rebràs un missatge per cada canvi de configuració del compte. Amb l'ASG rotant, això és soroll pur que farà que la gent deixi de llegir els avisos. La manera correcta és enviar per SNS només les notificacions de no conformitat, i això es fa amb EventBridge (07-03) filtrant el tipus d'esdeveniment, o amb un tema separat per al soroll. MercadoFresco fa servir el tema aquí únicament perquè el canal ho exigeix, i filtra a EventBridge el que arriba a les persones.

La taula de decisió de MercadoFresco, que és el patró que cal copiar:

Les tres últimes files són les que més diners estalvien en comptes reals. NetworkInterface i ManagedInstanceInventory són, de bon tros, els dos tipus que més CI generen per accident.

Recursos globals: IAM i CloudFront són globals. Si actives includeGlobalResourceTypes en diverses regions, pagaràs el mateix CI diverses vegades. S'activa en una sola regió —MercadoFresco fa servir eu-west-1— i s'enregistren explícitament els tipus d'IAM tal com hem fet més amunt.

Una regla de Config avalua recursos i els assigna un estat:

Hi ha tres classes de regla:

Comença sempre per les gestionades: cobreixen el 90 % del que necessites i no cal mantenir-les.

Són 29 regles. Activar-les:

I la consulta de l'estat general:

La distinció no és arbitrària. Una regla per canvi necessita un recurs a què associar-se. Regles com cloudtrail-enabled o iam-password-policy avaluen una propietat del compte, no d'un recurs concret, així que només poden ser periòdiques.

I hi ha un matís de cost important: una regla per canvi sobre un tipus de recurs que canvia molt —instàncies EC2 amb l'ASG rotant— s'avalua moltíssimes vegades. Una regla periòdica cada 24 hores s'avalua 30 vegades al mes i prou. Quan una comprovació no necessiti detecció immediata, posa-la periòdica.

Es pot combinar:

Avalua en canviar i un cop al dia, que és la xarxa de seguretat per si s'ha perdut algun CI.

L'etiquetatge de MercadoFresco és Proyecto, Entorno, Componente, Propietario, CentroCoste. Fins ara era una norma escrita que ningú no comprovava. Config la converteix en una regla:

Detalls de la sintaxi que no són evidents:

• tagNKey sense tagNValue exigeix que l'etiqueta existeixi, amb qualsevol valor. Així estan Componente, Propietario i CentroCoste: els seus valors són lliures.
• tagNValue amb una llista separada per comes exigeix que el valor sigui un d'aquests. Entorno només pot ser produccion, preproduccion o desarrollo.
• Màxim 6 etiquetes per regla. Si en necessites més, dues regles.

I el resultat la primera vegada que s'executa, que és el moment més instructiu:

La fila dels volums és la troballa real, i és un problema que gairebé tothom té sense saber-ho: els volums EBS creats automàticament per un ASG no hereten les etiquetes de la instància llevat que es configuri explícitament a la plantilla de llançament:

Conseqüència directa i mesurable: al mòdul 11, quan la Sara reparteixi el cost per CentroCoste, els volums de la botiga apareixerien com a «sense assignar». Una regla de Config ha trobat un forat a la comptabilitat de costos que ningú no havia vist en mesos. És el millor argument per activar required-tags des del primer dia.

Quan cap regla gestionada no serveix. El cas de MercadoFresco: cap bucket de dades de negoci pot tenir una regla de cicle de vida que esborri objectes abans de 30 dies, perquè la Sara necessita poder recalcular informes del mes.

Quatre coses que cal fer bé i que s'obliden:

• Retornar NOT_APPLICABLE per al que no aplica, no COMPLIANT. Si retornes COMPLIANT per a tots els buckets del món, el quadre de compliment menteix: semblarà que 40 buckets compleixen una regla que només s'aplica a dos.
• Tractar ResourceDeleted. Avaluar un recurs que ja no existeix deixa registres orfes marcats com a no conformes per sempre.
• Annotation és el text que es veu a la consola al costat del recurs no conforme. Un bon missatge aquí estalvia mitja hora d'investigació. Màxim 256 caràcters.
• ResultToken cal retornar-lo tal qual. És el que associa la resposta amb l'avaluació.

I el registre de la regla:

Cost: 0,001 USD per avaluació més el cost de la invocació de Lambda. Amb pocs buckets és menyspreable; amb una regla personalitzada sobre instàncies EC2 en un compte amb molt moviment, pot sorprendre.

AWS CloudFormation Guard és un llenguatge declaratiu de regles, molt més curt que una Lambda per a comprovacions sobre la configuració. Les regles de Config escrites en Guard s'anomenen Custom Policy rules i no requereixen cap funció: no hi ha codi a mantenir, ni rol, ni cost de Lambda.

La mateixa idea d'abans, en Guard, comprovant que els buckets de negoci estan xifrats amb la clau de MercadoFresco i no amb la d'AWS:

El bloc entre << i >> és el missatge d'error, que apareix com a anotació a la consola.

La diferència pràctica: Guard només pot mirar el que hi ha a l'element de configuració. Si la teva comprovació necessita cridar una altra API —com l'exemple de Lambda, que consultava get_bucket_lifecycle_configuration—, necessites Lambda. Per a tota la resta, Guard.

Detectar és bo. Corregir sol és millor, i és el que converteix Config en una eina operativa i no en un informe més que ningú no llegeix.

La remediació s'executa amb un document de Systems Manager Automation: un procediment predefinit amb passos i paràmetres. AWS proporciona dotzenes de documents AWS-* a punt per fer servir.

El rol de remediació. Aquí és on hi ha els permisos perillosos, i per això és un rol a part del de Config, amb el mínim estricte:

Fixa't en tres decisions de mínim privilegi, totes del manual de 04-01:

• s3:PutEncryptionConfiguration només sobre mercadofresco-*. El rol no pot tocar buckets aliens.
• Condició d'etiqueta a les accions sobre SG: només actua sobre recursos del projecte.
• No hi ha ec2:AuthorizeSecurityGroupIngress. El rol pot treure regles, mai afegir-ne. Si algú comprometés aquest rol, el pitjor que podria fer és tancar coses. Aquesta asimetria és deliberada i és el tipus de detall que separa una configuració segura d'una de perillosa.

Cas 1: reactivar el xifratge d'un bucket.

El ResourceValue: RESOURCE_ID és la peça clau: li diu a la remediació que el nom del bucket sigui el del recurs que ha fallat l'avaluació. Sense això, la remediació no sabria sobre què actuar.

Cronologia completa del que passa ara si algú desactiva el xifratge:

Vuit minuts, sense intervenció humana. I amb el rastre complet: CloudTrail sap qui el va desactivar, Config sap com va quedar, la remediació ho va arreglar, i la línia temporal ho explica sencer. Aquesta és la resposta a l'última pregunta del mòdul 4.

Cas 2: revocar una regla de grup de seguretat oberta al món.

Aquest document revoca totes les regles d'entrada amb origen 0.0.0.0/0 o ::/0 del grup, no només la del 22. És agressiu, i cal saber-ho: si el teu ALB públic és en un grup de seguretat que legítimament permet 0.0.0.0/0 al 443, aquesta remediació el tombaria.

Per això MercadoFresco acota l'abast de la regla, no el de la remediació:

Amb TagKey/TagValue, la regla —i per tant la remediació— només s'aplica als grups de seguretat etiquetats com a Componente=basedatos. sg-mercadofresco-alb, que ha d'estar obert al món al 443, en queda fora. És el mateix raonament de l'abast mínim que apliquem a les exclusions de WAF a 04-05.

Cas 3, el més rendible: posar retenció als grups de registres.

Aquesta és la que hauria evitat l'incident dels 610 USD de l'exercici 3 de 05-01. Qualsevol grup de registres nou —creat per una Lambda, per l'agent, per un servei— rep 30 dies de retenció automàticament en qüestió de minuts. És la remediació amb millor relació cost-benefici de tot el mòdul.

No activis mai Automatic: true en una remediació que no hagis provat. Una remediació és codi amb permisos que modifica la teva producció sense que ningú no ho aprovi. Si està malament, ho fa molt ràpid i arreu.

El procediment de MercadoFresco, i és innegociable:

Fase 1 — Només detecció, 1 setmana. La regla, sense remediació. S'observa quins recursos marca. Aquí surten els falsos positius: recursos que incompleixen la lletra de la regla per bones raons.

Fase 2 — Remediació manual, 2 setmanes. Automatic: false. La remediació existeix però cal llançar-la a mà des de la consola, recurs a recurs:

S'executa sobre un recurs poc crític, es comprova que fa exactament el que s'espera i res més, i es revisa el registre de l'execució a Systems Manager.

Fase 3 — Automàtica, amb abast acotat. Automatic: true, però primer només sobre els recursos etiquetats Entorno=desarrollo. Una setmana. Després, producció.

Fase 4 — Amb límits. MaximumAutomaticAttempts i RetryAttemptSeconds són un fre important: si la remediació falla 3 vegades, Config deixa d'intentar-ho en lloc d'entrar en bucle. Un bucle de remediació pot generar milers de crides a l'API i una factura considerable.

I tres tipus de remediació que MercadoFresco NO automatitza mai:

La regla mental: automatitza el que afegeix seguretat i és reversible (activar xifratge, posar retenció, treure accés públic). No automatitzis mai el que treu disponibilitat o és irreversible.

Un conformance pack és una plantilla que desplega un conjunt de regles i remediacions de cop, com una unitat, i que es pot aplicar a tota una organització.

AWS publica plantilles alineades amb marcs coneguts:

L'advertència que cal repetir. Desplegar el paquet de PCI DSS no et fa conforme amb PCI DSS. És una ajuda: comprova automàticament un subconjunt de controls tècnics. La conformitat real inclou processos, formació, contractes, avaluacions i una auditoria formal per un avaluador qualificat. Presentar un quadre verd de Config com a prova de conformitat és un error greu. Aquestes decisions les valida un professional de compliment, no un curs.

Cost: un paquet no costa res per si mateix; costen les regles que conté. Un paquet de PCI DSS amb 90 regles avaluant-se sobre centenars de recursos és la manera més ràpida de multiplicar la factura de Config per deu. Llegeix-lo abans de desplegar-lo.

El primer resultat, tres dies després d'activar-ho tot. Aquest és el moment realment valuós, perquè treu a la llum el que feia mesos que era allà:

Sis regles no conformes, 14 recursos. I cap d'aquests catorze no havia disparat mai una alarma de CloudWatch ni havia aparegut en una investigació de CloudTrail, perquè cap no era un esdeveniment: eren estats. Feia mesos que eren allà.

Les tres troballes que la Marta no esperava:

1. mercadofresco-registros-web sense xifratge des del març. Es va crear a mà a 03-03 per als registres de l'ALB, abans que existís la política de xifratge de 04-02, i ningú no hi va tornar.
2. El SG amb el 22 obert des d'una prova de maig. La regla es va afegir «un moment» per depurar i s'hi va quedar tres mesos.
3. El grup de seguretat per defecte de vpc-mercadofresco amb regles. És el clàssic de 03-02: ningú no el fa servir, però hi és, permissiu, esperant que algú llanci una instància sense especificar grup.

El pla de correcció, ordenat per risc:

Fixa't en el patró: les quatre primeres s'automatitzen perquè afegeixen seguretat i són reversibles. Les tres últimes requereixen criteri humà, i per això no s'automatitzen.

Config inclou un motor de consultes SQL sobre l'inventari actual de tots els recursos enregistrats. És una de les seves funcions més infravalorades.

Aquest motor respon en segons a preguntes que altrament requeririen recórrer desenes de crides Describe paginades. I a diferència d'Athena sobre CloudTrail (05-03), no costa res per consulta: forma part del servei.

Una consulta que la Marta executa cada mes i que ja ha justificat el cost de Config diverses vegades:

Un volum available és un volum que existeix, que es paga cada mes, i que no està connectat a res. Solen quedar d'instàncies acabades. És exactament una de les troballes que també reporta Trusted Advisor, que és la lliçó següent.

Un agregador consolida les dades de Config de diversos comptes i regions en una sola vista.

Amb AWS Organizations es fa servir --organization-aggregation-source i l'agregador recull automàticament tots els comptes de l'organització, inclosos els que es creïn en el futur. Aquesta és la configuració correcta per a qualsevol empresa amb diversos comptes, i és la lliçó 09-04.

MercadoFresco té un compte avui, així que l'agregador només aporta la vista multiregió —útil per detectar recursos oblidats en regions on no s'hauria de tenir res, el cas de l'exercici 3 de 05-03—.

És fàcil confondre aquestes tres eines. La taula que les separa:

Exemples concrets que aclareixen la divisió del treball:

• Config: «mercadofresco-registros-web no té xifratge.» És un problema de configuració.
• GuardDuty: «Una instància d'asg-mercadofresco-tienda està resolent dominis associats a mineria de criptomonedes» o «credencials del rol d'instància usades des d'una IP externa a AWS». És un problema d'intrusió, i cap regla de configuració no ho detectaria.
• Security Hub: «El teu compte compleix el 82 % del CIS Benchmark; aquestes 14 troballes són crítiques», amb les troballes de Config i de GuardDuty a la mateixa llista prioritzada.

Recomanació pràctica: si vas a activar els tres, activa'ls en aquest ordre —Config primer, perquè és la base i perquè Security Hub consumeix les seves regles; GuardDuty després, perquè és el que detecta el que Config no pot veure; Security Hub al final, com a capa d'agregació—. I tingues present que els tres costen diners i els tres generen troballes que algú ha de llegir. Activar els tres i no mirar-los és pitjor que activar només Config i revisar-lo mensualment.

Càlcul per a MercadoFresco:

I ara el mateix càlcul sense les optimitzacions, que és el que li passa a la majoria dels comptes:

Trenta-quatre vegades més car, i amb exactament la mateixa capacitat de detecció dels problemes que importen. La diferència és tota en tres decisions de configuració.

Les cinc maneres de disparar la factura de Config, per freqüència real:

1. allSupported: true en un compte amb autoescalat. Cada llançament d'instància genera CI de la instància, els seus volums, les seves interfícies de xarxa i les seves associacions. Milers al mes.
2. No fer servir recordingFrequency: DAILY per a recursos efímers. L'optimització més rendible i la menys coneguda.
3. Enregistrar recursos globals (IAM) en diverses regions. Es paga el mateix CI tantes vegades com regions tinguin l'enregistrador amb includeGlobalResourceTypes.
4. Desplegar un conformance pack de 200 regles sense llegir-lo. Cada regla s'avalua contra cada recurs aplicable, a cada canvi.
5. Regles personalitzades amb Lambda sobre tipus de recurs molt canviants. Es paga l'avaluació i la invocació.

Les cinc defenses:

1. Llista explícita de resourceTypes, mai allSupported.
2. recordingFrequency: DAILY per a AWS::EC2::Instance, AWS::EC2::Volume i tot el que sigui efímer.
3. Recursos globals en una sola regió.
4. Regles periòdiques cada 24 h en lloc de per canvi sempre que no necessitis detecció immediata.
5. Un pressupost d'AWS Budgets filtrat per servei = Config (mòdul 11), amb avís al 80 %.

El pas 4 és l'important. Esborrar regles no atura la despesa: els CI es continuen enregistrant mentre l'enregistrador estigui actiu. Aturar l'enregistrador és el que talla la facturació. I si en algun moment veus un càrrec de Config que no esperes, comença sempre per describe-configuration-recorder-status a totes les regions: un enregistrador oblidat en una regió que no fas servir és un clàssic.

1. Activar allSupported: true sense pensar-hi. És l'error de cost número u del servei. Llista explícita, sempre.

2. No fer servir recordingFrequency: DAILY per a instàncies i volums. Amb un ASG actiu, és la diferència entre 6 i 216 USD al mes.

3. Enregistrar recursos globals en diverses regions. Es paga el mateix CI diverses vegades. IAM i CloudFront en una sola regió.

4. Activar Automatic: true en una remediació sense provar-la. Detecció una setmana, remediació manual dues setmanes, automàtica en desenvolupament una setmana, i després producció. Sense dreceres.

5. Automatitzar remediacions destructives. Esborrar recursos, aturar instàncies o modificar IAM automàticament pot convertir una regla mal escrita en una caiguda. Automatitza només el que afegeix seguretat i és reversible.

6. Confondre Config amb CloudTrail. «Qui ho ha canviat?» → CloudTrail. «Com està i compleix?» → Config. Es fan servir junts.

7. Retornar COMPLIANT en lloc de NOT_APPLICABLE en una regla personalitzada. El quadre de compliment queda inflat i deixa de ser útil.

8. Connectar totes les notificacions de Config a SNS. Un missatge per cada canvi de configuració és soroll garantit, i el soroll fa que la gent deixi de llegir els avisos importants. Filtra amb EventBridge (07-03) i envia a les persones només les no conformitats.

9. Creure que un conformance pack et certifica. No. Comprova controls tècnics; la conformitat real inclou processos, contractes i una auditoria formal. Que ho validi un professional de compliment.

10. Aplicar una remediació de SG sense acotar l'abast de la regla. RemoveUnrestrictedSourceIngressRules sobre sg-mercadofresco-alb tombaria la botiga. Acota amb TagKey/TagValue.

11. Esborrar regles creient que s'atura la despesa. El que factura són els CI de l'enregistrador. stop-configuration-recorder.

12. Oblidar start-configuration-recorder. Com amb CloudTrail, crear no és engegar.

13. Escriure una regla amb Lambda quan n'hi havia prou amb Guard. Si la comprovació només mira l'element de configuració, Guard és més curt, més barat i no cal mantenir cap runtime.

Consell final: activa Config amb poques regles i ben triades abans que amb un paquet de conformitat complet. Deu regles que algú revisa cada mes valen infinitament més que dues-centes que generen un quadre vermell permanent al qual tothom s'acostuma. L'objectiu no és tenir moltes regles: és arribar a zero no conformitats i que qualsevol de nova sigui un senyal real.

MercadoFresco vol activar Config amb un pressupost màxim de 12 USD al mes. Inventari real del compte:

Requisits: cal detectar en menys de 15 minuts que un bucket perd el xifratge o que un SG s'obre al món; cal comprovar l'etiquetatge obligatori; cal vigilar la retenció dels grups de registres.

Dissenya: la llista de resourceTypes amb la seva recordingFrequency, el conjunt de regles amb el seu tipus d'activació, i calcula el cost total. Justifica cada exclusió. Si et passes del pressupost, explica què retallaries i quina capacitat de detecció perdries.

MercadoFresco té una política interna: tota instantània d'RDS de més de 90 dies ha d'estar xifrada i no ha de ser pública, i les de més de 365 dies s'han d'esborrar llevat que portin l'etiqueta Retencion=legal.

• a) Explica per què aquesta comprovació no es pot fer amb una sola regla gestionada, i quines regles gestionades cobreixen part del problema.
• b) Escriu la regla personalitzada (Lambda o Guard, justificant l'elecció) que avalua les instantànies.
• c) Dissenya la remediació. Decideix quina part s'automatitza i quina no, i justifica-ho amb el criteri de la lliçó.
• d) Calcula el cost afegit si MercadoFresco té 120 instantànies i la regla és periòdica cada 24 hores, enfront de per canvi de configuració.

Un dilluns, la regla mercadofresco-s3-cifrado marca mercadofresco-informes-analitica com a NO CONFORME. La remediació automàtica encara és en mode manual. Dades:

• La línia temporal mostra que el CI no conforme es va crear el diumenge a les 04:17.
• El CI anterior, del dijous, era conforme.
• La regla mercadofresco-etiquetado-obligatorio marca el mateix bucket com a no conforme des del diumenge a les 04:17: li falta l'etiqueta Propietario.
• Hi ha tres buckets nous al compte, creats el diumenge entre les 04:10 i les 04:25, cap amb xifratge ni etiquetes.
• CloudTrail mostra 46 crides d'escriptura aquell diumenge entre les 04:05 i les 04:30, totes amb userIdentity.type = "AssumedRole" i sessionIssuer.userName = "rol-despliegue-infra".

Explica: què ha passat amb tota probabilitat; com ho confirmaries combinant Config i CloudTrail (amb comandes i consultes concretes); per què Config va detectar una cosa que CloudTrail tot sol no hauria fet saltar; quina remediació aplicaries i en quin ordre; i quin arranjament de fons proposaries perquè no torni a passar, indicant en quin mòdul del curs s'estudia.

Solució 1

Anàlisi de l'inventari. El problema està concentrat en tres files: instàncies (620), volums (640) i interfícies de xarxa (1.280). Són 2.540 dels 2.679 canvis mensuals: el 95 %. Tots generats per la rotació de l'ASG i tots de configuració idèntica, perquè vénen de lt-mercadofresco-tienda.

Configuració proposada de l'enregistrador:

Càlcul d'elements de configuració:

Regles proposades:

Cost total: 0,52 + 1,03 + ~0,02 de S3 = ~1,57 USD/mes. Molt per sota dels 12 USD.

Amb el marge sobrant es pot: afegir el paquet de conformitat CIS complet (~50 regles, uns 3-4 USD més), passar required-tags a activació per canvi per a una detecció més ràpida, o incloure AWS::EC2::NetworkInterface si alguna vegada calgués per a una investigació de xarxa.

Justificació de les exclusions:

• NetworkInterface: 1.280 CI (3,84 USD) per interfícies efímeres que l'ASG crea i destrueix. La seva configuració és sempre la mateixa i ve de la plantilla de llançament. Si calgués investigar la xarxa, hi ha els VPC Flow Logs (03-01) i CloudTrail (05-03).
• Instàncies i volums en mode diari: es perd la detecció immediata d'un canvi en una instància concreta. Importa? Les instàncies són bestiar, no mascotes: si una es degrada, l'ASG la reemplaça. Els canvis que importen són a la plantilla de llançament, no a la instància. El compromís és correcte.

El que es perdria retallant més: si calgués baixar d'1,57 USD, la retallada següent seria required-tags (0,75 USD, gairebé la meitat del total). Es perdria la detecció del forat de CentroCoste als volums, que al mòdul 11 val molt més de 0,75 USD. No es retalla.

Solució 2

a) Per què no n'hi ha prou amb una regla gestionada.

Hi ha regles gestionades que cobreixen parts:

El que cap no cobreix és la lògica combinada: «més de 90 dies i sense xifrar», «més de 365 dies i sense l'etiqueta Retencion=legal». Config no permet compondre regles gestionades amb condicions entre elles. Això exigeix una regla pròpia.

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

Guard només pot mirar el que hi ha a l'element de configuració. Aquí necessitem calcular l'antiguitat respecte a la data actual, i Guard no té aritmètica de dates contra «ara». A més, convé una activació periòdica que avaluï totes les instantànies, no només les que canvien —una instantània no canvia: simplement envelleix—. Aquest és l'argument decisiu: l'incompliment apareix amb el pas del temps, no amb un canvi de configuració.

Quatre detalls que fan que aquesta funció funcioni en producció i no només a l'exemple:

• SnapshotType="manual": les automàtiques les gestiona RDS amb la seva pròpia retenció (02-04) i s'esborren soles. Avaluar-les generaria no conformitats impossibles de remeiar.
• put_evaluations en lots de 100: és el límit de l'API. Amb 120 instantànies, una sola crida fallaria.
• Annotation amb l'edat concreta: qui miri la consola sabrà immediatament de què es tracta.
• La comprovació de publicitat fa una crida extra per instantània. Amb 120 instantànies són 120 crides cada 24 hores: acceptable. Amb 10.000, caldria paral·lelitzar o separar en una altra regla.

c) La remediació, i aquí hi ha el criteri.

Aquesta taula és exactament la regla de la lliçó: automatitza el que afegeix seguretat i és reversible; mai el que és destructiu. La instantània pública es tanca sola en minuts; l'esborrament l'aprova una persona.

Per a les dues que no s'automatitzen, la resposta correcta és notificar bé: una regla d'EventBridge (07-03) que capturi el canvi a no conformitat i enviï a alertas-mercadofresco un missatge que inclogui l'Annotation de l'avaluació, que és on hi ha l'explicació concreta («412 dies d'antiguitat i sense xifrar»). Un avís que només diu «hi ha un recurs no conforme» obliga a entrar a la consola; un que diu quina instantània i per què es resol des del mòbil.

I una revisió trimestral al calendari de la Marta per decidir què s'esborra, amb la llista al davant.

d) Cost.

Opció periòdica cada 24 hores:

• 120 instantànies × 30 dies = 3.600 avaluacions/mes = 3,60 USD
• Invocacions de Lambda: 30/mes (una per avaluació de la regla, no per instantània) ≈ 0,00 USD
• Crides a l'API d'RDS: gratuïtes
• Total: ~3,60 USD/mes

Opció per canvi de configuració:

• Les instantànies manuals canvien poquíssim: potser 10 CI/mes.
• 10 avaluacions = 0,01 USD
• Total: ~0,01 USD/mes

Però l'opció per canvi NO SERVEIX, i aquesta és la conclusió de l'apartat. L'incompliment aquí apareix amb el pas del temps, no amb un canvi: una instantània creada avui sense xifrar és conforme, i d'aquí a 91 dies deixa de ser-ho sense que hagi canviat res en ella. Una regla per canvi no la tornaria a avaluar mai i la no conformitat no es detectaria mai.

3,60 USD al mes és el preu de detectar incompliments que depenen del temps, i TwentyFour_Hours ja és la freqüència periòdica més espaiada que admet Config: no hi ha marge per aquí. L'única palanca real d'estalvi seria emetre una sola avaluació agregada per regla en lloc d'una per instantània, però llavors la consola diria «la regla no es compleix» sense dir quina de les 120 instantànies en té la culpa, que és justament la dada que cal per actuar. Es paga el detall, i val la pena.

Solució 3

Què ha passat, amb tota probabilitat.

Les dades apunten de manera inequívoca a un desplegament automatitzat d'infraestructura el diumenge de matinada que va crear recursos sense les propietats obligatòries, i que a més va modificar un bucket existent.

Les pistes, en ordre:

1. Diumenge a les 04:17, hora sense activitat humana: és un procés automàtic.
2. rol-despliegue-infra amb 46 crides d'escriptura en 25 minuts: és un pipeline o una execució d'infraestructura com a codi.
3. Tres buckets nous sense xifratge ni etiquetes, creats a la mateixa finestra.
4. Un bucket existent que va passar de conforme a no conforme exactament a la mateixa hora.

El punt 4 és el més greu i el més revelador: la plantilla no només va crear recursos nous mal configurats, sinó que va redefinir un bucket que ja existia, sobreescrivint-ne el xifratge i les etiquetes amb una definició incompleta. És el patró clàssic d'una plantilla de CloudFormation o Terraform que declara un recurs que ja existia i l'«alinea» amb una especificació pobra.

Confirmació, pas a pas.

1. Veure exactament què va canviar al bucket (això és el que només Config pot donar):

Comparant el CI del dijous amb el del diumenge es veu el diff: serverSideEncryptionConfiguration va desaparèixer i les etiquetes es van reduir. Això és informació que CloudTrail no té: CloudTrail registra la crida PutBucketEncryption o la seva absència, però no l'estat resultant complet del bucket.

2. Veure qui va fer la crida concreta (això és el que només CloudTrail pot donar):

Es busca: el userAgent (cloudformation.amazonaws.com? Terraform/1.7?), el nom de sessió, i si hi ha un DeleteBucketEncryption explícit o simplement un CreateBucket sobre un bucket existent.

3. Veure tots els recursos afectats alhora, amb la consulta avançada de Config:

4. Quadre de compliment complet, per veure si hi ha més danys dels que se sabien:

Per què CloudTrail tot sol no hauria fet saltar res.

Aquesta és la pregunta central de l'exercici, i hi ha tres raons:

1. CloudTrail no avalua. Registra 46 crides d'un rol de desplegament un diumenge. Això és completament normal per a un pipeline programat. No hi ha res anòmal en l'esdeveniment en si.
2. L'alarma de 05-03 no hauria saltat. Els filtres de mètriques que vam muntar vigilaven DeleteBucketEncryption i PutBucketPolicy, però des d'un rol de desplegament legítim, i probablement sense DeleteBucketEncryption explícit: si la plantilla simplement no declara xifratge en crear el bucket, no hi ha cap crida a registrar. L'absència d'una crida no genera un esdeveniment.
3. CloudTrail no coneix la política de MercadoFresco. No sap que tots els buckets han d'estar xifrats ni que calen cinc etiquetes. Config sí, perquè l'hi hem dit amb regles.

Config detecta l'estat resultant; CloudTrail detecta l'acte. Aquí l'acte era legítim i l' estat resultant no ho era. Aquest és exactament el buit que aquesta lliçó ve a cobrir.

Remediació, en ordre de risc:

El pas 3 mereix un comentari: els objectes escrits mentre el xifratge per defecte estava desactivat es van desar sense xifrar, i activar-lo ara no els xifra retroactivament. Cal reescriure'ls:

Aquest detall es passa per alt constantment i és el que converteix un incident de configuració en un incident de dades.

Els arranjaments de fons, que són la part important:

La lliçó de fons, i mereix subratllar-se perquè és l'argument més fort a favor d'aquest servei: la mateixa regla de Guard que escrius per a Config es pot executar al pipeline amb cfn-guard abans del desplegament. Config és la xarxa de seguretat que atrapa el que se't va escapar; la validació al pipeline és la que evita que s'escapi. Totes dues, amb la mateixa regla escrita un cop. Aquest és el patró que MercadoFresco adopta, i que es tanca al mòdul 8.

MercadoFresco ja té l'última peça que li faltava. Saps què és la configuració d'un recurs —els seus ajustos, no les seves dades— i què és un element de configuració: una fotografia completa amb els seus relationships, la seva supplementaryConfiguration i el seu estat, que Config crea a cada canvi i que fins i tot enregistra quan el recurs s'esborra. Coneixes la línia temporal, que respon a la pregunta que es fa cada setmana a operacions: «això funcionava divendres; què ha canviat?».

Tens clara la diferència essencial amb la lliçó anterior: CloudTrail enregistra la crida, Config enregistra l'estat. CloudTrail diu qui va cridar AuthorizeSecurityGroupIngress; Config diu com va quedar el grup de seguretat, si compleix, i ho arregla. I saps que Config depèn de CloudTrail per assabentar-se dels canvis: no competeixen, es donen suport.

Has activat l'enregistrador grabador-mercadofresco amb el seu rol de només lectura, el seu canal cap a mercadofresco-config-historial i el seu tema d'SNS, amb les dues decisions que valen diners: allSupported: false amb llista explícita, i recordingFrequency: DAILY per a instàncies i volums, que és l'optimització més rendible i menys coneguda del servei. I saps que crear no és engegar: start-configuration-recorder.

Coneixes les 29 regles gestionades que MercadoFresco activa, cadascuna lligada a alguna cosa que vam construir en un mòdul anterior —s3-bucket-server-side-encryption-enabled per 04-02, restricted-ssh per 03-02, cloudtrail-enabled per 05-03, cw-loggroup-retention-period-check per l'incident de 610 USD de 05-01— i la diferència entre activació per canvi (minuts, però s'avalua a cada canvi) i periòdica (fins a 24 hores, però cost fix i única opció per a comprovacions de compte). required-tags t'ha trobat el forat que ningú no veia: els volums EBS creats per l'ASG no hereten etiquetes, i al mòdul 11 haurien aparegut com a cost sense assignar.

Saps escriure regles pròpies: amb Lambda quan necessites cridar altres API o calcular amb dates —retornant NOT_APPLICABLE en lloc de COMPLIANT, tractant ResourceDeleted i escrivint una Annotation útil— i amb Guard, declaratiu, sense runtime, sense cost extra i sense manteniment, que és el que cal fer servir per defecte quan n'hi ha prou amb mirar l'element de configuració.

I has muntat la remediació automàtica amb documents de Systems Manager, que és el que converteix Config en una eina operativa: AWS-EnableS3BucketEncryption restaura el xifratge d'un bucket en vuit minuts sense intervenció humana, RemoveUnrestrictedSourceIngressRules tanca un grup de seguretat obert, i SetCloudWatchLogGroupRetention posa 30 dies a qualsevol grup de registres nou. Amb el rol de remediació separat del de Config, amb permisos acotats per prefix i per etiqueta, i sense AuthorizeSecurityGroupIngress: el rol pot tancar, mai obrir. I amb el procediment innegociable de quatre fases —detecció, remediació manual, automàtica en desenvolupament, automàtica en producció— i la regla que ho resumeix tot: automatitza el que afegeix seguretat i és reversible; mai el que és destructiu ni el que treu disponibilitat.

Coneixes els paquets de conformitat alineats amb CIS, PCI DSS, NIST i RGPD, amb l'advertència que cal repetir sempre: desplegar el paquet de PCI DSS no et fa conforme amb PCI DSS. I el quadre de compliment t'ha donat el resultat que justifica el servei sencer: sis regles no conformes i catorze recursos, entre ells un bucket sense xifrar des del març, un port 22 obert des del maig i el grup de seguretat per defecte amb regles. Catorze problemes que feia mesos que eren allà i que no haurien disparat mai una alarma de CloudWatch ni haurien aparegut en una investigació de CloudTrail, perquè no eren esdeveniments: eren estats.

I tens les consultes avançades, gratuïtes, que inventarien el compte en segons: buckets sense xifrar, volums sense associar que es paguen cada mes sense servir per a res, recursos sense CentroCoste. Amb l'agregador per a la vista multicompte que arribarà a 09-04, i el repartiment clar de feina amb GuardDuty —que detecta intrusions, no configuracions— i Security Hub, que agrega les troballes de tots.

Tot per uns 6,40 USD al mes, enfront dels 216 USD que costaria exactament la mateixa capacitat de detecció sense les tres decisions de configuració correctes. Aquest factor de trenta- quatre és el resum de per què aquesta lliçó dedica una secció sencera al cost.

Amb això queden respostes les cinc preguntes del mòdul 4. L'avís arriba de debò, els registres estan correlacionats, la comanda de vuit segons té culpable i arranjament, sabem qui va desxifrar la còpia, i ara res no pot desactivar el xifratge d'un bucket sense que salti un avís —i es corregeixi sol en vuit minuts—.

Queda una última peça, i és diferent de tot l'anterior. Config comprova les regles que tu li has dit. És potent i és exacte, però té un límit evident: no et pot avisar del que no se t'ha acudit. No sap que tens tres volums EBS orfes costant diners, ni que hi ha una IP elàstica sense associar que es factura per no fer-se servir, ni que l'asg-mercadofresco-tienda és a punt de xocar amb una quota de servei que ningú no ha mirat mai, ni que una de les teves instàncies fa dos mesos que està al 4 % de CPU. Ningú no ha escrit regles per a això, i ningú no les escriurà, perquè per escriure-les caldria sospitar primer que el problema existeix.

Hi ha un servei que fa precisament aquest repàs: comparar el teu compte amb les bones pràctiques que AWS ha destil·lat de milions de clients, i dir-te el que no havies pensat a preguntar. A la lliçó 05-05, «AWS Trusted Advisor», veurem les seves cinc categories —optimització de costos, rendiment, seguretat, tolerància a errors i límits de servei—, quines comprovacions veus de debò amb el pla de suport Basic i quines no, com suplir el que falta amb el que ja saps, un recorregut comentat per un informe real de l'arquitectura de MercadoFresco, les quotes de servei i el cas concret de l'ASG que no pot passar de quatre instàncies per un límit de vCPU que ningú no havia mirat, i la rutina de revisió mensual que adopta la Marta. I amb ella tancarem el mòdul sencer.