Ja tenim una organització amb molts comptes (subcapítol 30.1), creades i governades amb Control Tower (subcapítol 30.2). Però aquesta estructura multi-compte crea un nou repte: si tens la seguretat i els registres (logs) repartits en desenes de comptes, com els vigiles i gestiones de forma conjunta? Revisar compte per compte seria impossible. La solució és centralitzar la seguretat i els logs: reunir-ho tot en un lloc comú per veure-ho i controlar-ho de forma global. En aquest subcapítol veiem per què i com.

Recorda tota la seguretat i observabilitat que vam veure (Capítols 23 i 24): logs d’activitat, troballes d’amenaces, registres d’auditoria... Si cadascun dels teus 50 comptes genera la seva pròpia seguretat i els seus propis logs per separat, vigilar-ho tot es torna inviable:

Necessites una visió i gestió central de la seguretat i els logs de tota l’organització, no fragmentada compte per compte.

La pràctica recomanada és centralitzar la seguretat i els logs en comptes dedicats. És molt habitual tenir:

• Un compte de logs (log archive): on es reuneixen els registres de tots els comptes, guardats de forma segura.
• Un compte de seguretat (security/audit): des d’on l’equip de seguretat vigila i gestiona la seguretat de tota l’organització.

Recorda que Control Tower (subcapítol 30.2) sol crear aquests comptes especialitzats automàticament com a part de la landing zone.

Analogia: centralitzar la seguretat i els logs és com tenir una central de seguretat i un arxiu central per a tota una cadena de botigues. En lloc que cada botiga guardi les seves pròpies gravacions de càmeres i tingui el seu propi vigilant aïllat (sense que ningú vegi el conjunt), totes les càmeres envien el seu senyal a una central de seguretat única, i totes les gravacions es guarden en un arxiu central protegit. Així, un equip central vigila totes les botigues alhora, detecta patrons que creuen diverses, i les gravacions estan a resguard encara que algú manipuli una botiga concreta.

Reunir els logs de tots els comptes en un compte de logs dedicat aporta:

Tens tots els registres en un lloc, cosa que permet analitzar l’activitat de tota l’organització de forma conjunta (per exemple, amb les eines d’observabilitat del Capítol 24, o un data lake de logs, recorda el Capítol 29).

Si els logs de cada compte es guarden fora d’aquell compte (al compte central de logs, al qual els equips normals no tenen accés d’esborrat), ningú pot manipular o esborrar els registres del seu propi compte per ocultar alguna cosa. Això és clau per a l’auditoria i la seguretat: els logs són fiables i intactes.

Tenir tots els registres centralitzats i protegits facilita enormement demostrar compliment a auditors i reguladors (enllaça amb el Capítol 23): hi ha un únic lloc, segur, amb tot el rastre.

Gestionar la seguretat des d’un compte de seguretat central permet:

L’equip de seguretat veu i gestiona la seguretat de tots els comptes des d’un punt. Recorda Security Hub (subcapítol 23.4) i GuardDuty (subcapítol 23.3): es poden configurar per agregar les troballes de tota l’organització al compte de seguretat, donant aquesta visió central que vam veure tan valuosa.

Alguns atacs toquen diversos comptes. Només veient-los de forma conjunta (des del compte central) es detecten aquests patrons que, compte per compte, passarien desapercebuts.

Davant un incident, l’equip de seguretat central pot coordinar la resposta a través dels comptes afectats, en lloc d’actuar a cegues en cadascun.

El model que emergeix és molt potent: cada equip opera de forma autònoma al seu compte (llibertat per treballar), però la seguretat i els logs es governen de forma central (control i visió global). El millor dels dos mons: autonomia per als equips i control per a l’organització.

Exemple del món real: una empresa amb 40 comptes centralitza la seva seguretat i logs. Tots els registres dels 40 comptes s’envien a un compte de logs protegit, al qual els equips de producte no tenen accés d’esborrat. Tota la detecció d’amenaces (GuardDuty, Security Hub) dels 40 comptes s’agrega al compte de seguretat, on l’equip de seguretat vigila el conjunt. Un dia, un atacant compromet les credencials d’un equip i intenta moure’s cap a altres comptes. Com que la seguretat està centralitzada, l’equip detecta el patró (activitat sospitosa creuant comptes) que en comptes aïllats hauria passat desapercebut, i respon de forma coordinada. A més, l’atacant no pot esborrar els logs del compte que va comprometre (estan al compte central), així que queda tot el rastre per investigar. La centralització va ser decisiva.

• Amb molts comptes, tenir la seguretat i els logs dispersos en cadascun fa impossible vigilar-los en conjunt, detectar atacs que creuen comptes o demostrar el compliment global.
• La solució és centralitzar en comptes dedicats: un compte de logs (reuneix els registres de tots els comptes) i un compte de seguretat (des d’on es vigila tota l’organització). Els crea Control Tower (subcap. 30.2). Com una central de seguretat i arxiu central per a una cadena de botigues.
• Centralitzar logs dona: visió completa, protecció a prova de manipulació (ningú esborra els logs del seu propi compte, queden a resguard com a prova) i compliment més fàcil.
• Centralitzar seguretat dona: vigilància global (GuardDuty/Security Hub agregats, Cap. 23), detecció d’amenaces que creuen comptes i resposta coordinada.
• El model resultant: govern central (seguretat i logs) + operació distribuïda (equips autònoms als seus comptes) = llibertat i control alhora.

A l’últim subcapítol del capítol veurem com gestionar tota aquesta estructura multi-compte amb Terraform, és a dir, Terraform a escala multi-compte.