Un inventario IAM non risponde alla domanda giusta
In un singolo account, chiedere chi può fare cosa è già difficile. In AWS Organizations la domanda cambia forma: chi può raggiungere cosa, attraverso quali ruoli, da quale account, con quale esito pratico.
Esistono policy documentate, permessi allegati e trust policy. Ciò che spesso manca è il grafo dei percorsi effettivi tra di essi. Un sts:AssumeRole ben intenzionato in un account membro può essere il salto successivo da un’identità che nessuno ha rivisto come insieme.
Il rischio non appare sempre come una policy JSON sovradimensionata. Appare come una catena.
Perché le organizzazioni multi-account nascondono percorsi
AWS Organizations introduce fiducia strutturale: ruoli di accesso cross-account, account di management, SCP, amministratori delegati, Identity Center, Access Analyzer a scala di org. Ogni pezzo ha senso da solo. Insieme definiscono un perimetro raramente disegnato per intero.
Pattern comuni nelle review:
- trust policy ampie o condizioni deboli tra account
- jump role usati da pipeline o vendor che accumulano portata
- privilegi nell’account di management non soggetti agli stessi SCP dei membri
- percorsi che compaiono solo quando l’inventario IAM è combinato con le relazioni dell’organizzazione
Senza quella mappa, i team di sicurezza rispondono con controlli locali. Un attaccante, o un auditor, pensa in percorsi.
Cosa contribuisce STRAP
STRAP è tooling interno TechRebel per analizzare percorsi di attacco a scala di organizzazione AWS. Lo usiamo negli engagement di cloud security e lo mettiamo a disposizione dei clienti quando il problema è capire l’accesso effettivo oltre un singolo account.
Non sostituisce IAM Access Analyzer né un inventario di policy. Complementa quelle fonti con una lettura orientata ai percorsi: da identità a identità, da account a account, fino a privilegi che contano per il business.
L’output utile non è un elenco infinito di finding. È un insieme prioritizzato di percorsi che spiegano come qualcuno con un foothold in un punto possa raggiungerne un altro.
Come si inserisce in un engagement
Nel lavoro di AWS & Cloud Security partiamo di solito da tre layer:
- postura e copertura (account, regioni, logging, controlli di base)
- accesso effettivo (ruoli, trust, percorsi cross-account)
- prioritizzazione (quali percorsi contano e quali remediation sono realistiche)
STRAP alimenta soprattutto il secondo. Aiuta a passare da «abbiamo molte policy» a «questi sono i percorsi da tagliare per primi».
Cosa non promettiamo
Nessuno strumento elimina la complessità di una grande organizzazione AWS. STRAP non inventa da solo una postura sicura. Dipende da un ambito di lettura concordato e da credenziali, dalla qualità dell’inventario e da decisioni umane su cosa correggere.
Il suo valore è rendere visibili percorsi che il design account-per-account tende a lasciare fuori dal radar.
Per revisionare l’accesso effettivo nella vostra organizzazione AWS, prenotate una riunione o vedete più contesto su Research.