La più ampia superficie di attacco oggi is your cloud.
Revisione di configurazione, identità e segmentazione su AWS, Azure e GCP. La maggior parte degli incidenti in cloud non nasce da un guasto del fornitore: nasce da un permesso troppo ampio, una risorsa esposta senza volerlo o un segreto dimenticato.
In cloud l'errore raramente è del fornitore
Il modello di responsabilità condivisa divide il lavoro: il fornitore protegge l'infrastruttura, la configurazione è tua. Gli incidenti avvengono nella tua metà: un bucket aperto per comodità durante una prova, un ruolo con permesso amministrativo concesso di fretta, una rete lasciata senza segmentazione perché la consegna era in ritardo. Nulla di questo compare come vulnerabilità in una scansione; compare come una decisione di configurazione che nessuno ha più riesaminato.
- Un permesso concesso in via temporanea non viene quasi mai revocato dopo.
- Una risorsa creata fuori dal processo standard non eredita le protezioni che quel processo applica.
- I segreti in variabili d'ambiente e nei repository restano la via più breve per entrare.
- Senza segmentazione, un solo punto d'appoggio raggiunge account e ambienti che dovrebbero essere separati.
What's included
L'ambito qui sotto è lo standard per un engagement tipico. Tutto è modificabile durante lo scoping, senza costi.
- Politiche ampie e caratteri jolly in azioni e risorse
- Ruoli assumibili e catene di elevazione di privilegi
- Chiavi di accesso di lunga durata e rotazione
- Federazione, provider di identità e sessioni
- Account di servizio e permessi dei carichi di lavoro
- Separazione tra amministrazione e operatività
- Esposizione pubblica di oggetti e contenitori
- Cifratura a riposo e gestione delle chiavi
- Politiche di accesso e condivisione tra account
- Versionamento, conservazione e protezione da cancellazione
- Copie di sicurezza e prove di ripristino
- Dati sensibili fuori dall'archivio previsto
- Regole in ingresso aperte a tutta internet
- Segmentazione tra ambienti e tra account
- Bilanciatori, gateway e terminazione del traffico
- Servizi di gestione raggiungibili dall'esterno
- Connettività privata e peering di rete
- Superficie di contenitori e orchestrazione
- Traccia di audit attiva in tutte le regioni
- Conservazione e protezione dei registri stessi
- Copertura degli eventi del piano di controllo
- Allarmi sui cambi sensibili di permessi
- Centralizzazione su un account separato
- Integrazione con il monitoraggio esistente
- IAM, ruoli, politiche e federazione delle identità
- VPC, gruppi di sicurezza, NACL, peering ed esposizione pubblica
- S3, RDS, DynamoDB, Blob Storage e Cloud Storage
- EC2, Lambda, ECS, EKS, AKS e GKE
- CloudTrail, AWS Config, Microsoft Sentinel e Security Command Center
- Provider di identità e SSO federato
Modalities
adjustable to scopeRevisione della configurazione
Lettura sistematica dell'ambiente da un ruolo di audit: identità, rete, archiviazione, registri e protezione dei dati, confrontati con la documentazione del fornitore e con riferimenti pubblici.
Prova dei percorsi
Invece di elencare configurazioni, partiamo da una posizione plausibile — credenziale applicativa, contenitore compromesso, utente comune — e verifichiamo fin dove arriva nell'ambiente.
Revisione continua e dell'infrastruttura come codice
Analisi dei modelli e dei moduli che costruiscono l'ambiente, più un ciclo ricorrente di verifica. Correggere all'origine impedisce che la stessa deviazione torni a ogni nuovo account, progetto o rilascio.
Quando rivedere l'ambiente cloud
La configurazione in cloud cambia ogni giorno, per molte mani. Alcuni momenti concentrano il rischio più di altri.
Un ambiente spostato di fretta porta con sé permessi ampi concessi per sbloccare il passaggio, con la promessa di stringerli dopo, e il dopo arriva di rado.
Ogni team ha creato il suo, ogni progetto ne ha aperto un altro. Senza uno standard centrale le protezioni divergono e nessuno ha la visione d'insieme.
Una spesa anomala a volte è spreco, a volte è una risorsa creata da qualcuno che non avrebbe dovuto poterla creare. Vale la pena sapere quale delle due.
L'evidenza dei controlli in cloud è ormai una voce obbligata nella maggior parte dei questionari. Meglio trovare la lacuna prima di chi dovrà valutare.
How we conduct it
[pipeline]Ricognizione dell'ambiente
Partiamo da ciò che esiste: account, sottoscrizioni, progetti, regioni attive e risorse in uso. Un ambiente cloud è quasi sempre più grande di quanto suggerisca la documentazione, e la risorsa assente dall'inventario è di solito quella senza protezione.
Analisi di identità e permessi
Mappiamo chi può fare cosa, incluso ciò che è possibile per ereditarietà e assunzione di ruolo. Non conta la politica scritta ma il permesso effettivo, che tende a essere ben più ampio di quanto immagini chi lo ha concesso.
Revisione della configurazione
Archiviazione, rete, cifratura, registri, copie di sicurezza e servizi gestiti vengono confrontati con la documentazione del fornitore e con riferimenti pubblici di configurazione sicura, annotando ogni deviazione e perché conta in quell'ambiente.
Verifica della portata
Simuliamo posizioni di partenza realistiche e misuriamo la portata di ciascuna: cosa può leggere una credenziale applicativa, cosa raggiunge un contenitore compromesso, se è possibile passare da un ambiente all'altro. È questo a separare un elenco di deviazioni da un rischio dimostrato.
Valutazione di registri e allarmi
Verifichiamo se le azioni eseguite hanno lasciato traccia, se quella traccia è protetta dalla cancellazione e se i cambi sensibili di permessi generano un allarme. Un ambiente senza traccia affidabile non permette di indagare dopo un incidente.
Rapporto e piano di correzione
Le deviazioni sono raggruppate per causa e non per risorsa: dieci voci che nascono dalla stessa politica sono una correzione, non dieci. Ogni gruppo riceve indicazioni applicabili e un suggerimento per impedire la ricomparsa all'origine.
Riferimenti pubblici che guidano il lavoro
La revisione poggia sulla documentazione dei fornitori stessi e su riferimenti aperti di configurazione, il che rende ogni rilievo verificabile in modo indipendente.
- CIS Benchmarks
- Le linee di base di configurazione per AWS, Azure e GCP offrono un riferimento oggettivo e verificabile, voce per voce, con cui confrontare lo stato dell'ambiente.
- Well-Architected (pilastro sicurezza)
- Il materiale di architettura di ciascun fornitore descrive la pratica che loro stessi raccomandano, il che evita di discutere sull'origine della raccomandazione.
- Modello di responsabilità condivisa
- Definisce con chiarezza dove finisce la responsabilità del fornitore e comincia la tua: esattamente il confine dove avviene la maggior parte degli incidenti.
- MITRE ATT&CK for Cloud
- La matrice specifica per il cloud dà un nome alle tecniche di abuso dell'identità, persistenza e raccolta, e serve a valutare la copertura della detection.
- NIST SP 800-53
- Il catalogo dei controlli è il ponte tra il rilievo tecnico e il linguaggio che governance e audit già usano.
- Privilegio minimo
- Non è una norma ma il criterio che orienta l'analisi dei permessi: ogni identità dovrebbe raggiungere solo il necessario, e ogni scostamento richiede una motivazione esplicita.
- Azure Security Benchmark
- La linea di base di Microsoft per Azure, utile quando l'ambiente è prevalentemente Azure e l'audit si attende quel riferimento.
- CSA Cloud Controls Matrix
- La matrice della Cloud Security Alliance mappa i domini di sicurezza cloud e si incrocia con altre norme, il che aiuta quando il questionario del cliente è lungo.
- ISO/IEC 27017 e 27018
- Le norme specifiche per la sicurezza cloud e per i dati personali nel cloud, spesso citate nei contratti con clienti enterprise.
- Corrispondenza con GDPR e PCI-DSS
- Quando l'ambiente tratta dati personali o di pagamento, ogni rilievo esce anche riferito al requisito corrispondente, così da servire direttamente come evidenza.
Deliverables
dual view · NDAInventario di ciò che esiste
L'elenco reale di account, progetti, regioni e risorse attive. Per molti team è la prima consegna utile, perché fa emergere ambienti che nessuno ricordava di avere.
Mappa dei permessi effettivi
Chi raggiunge cosa nella pratica, inclusi i percorsi indiretti per ereditarietà e assunzione di ruolo. Di solito sorprende più dell'elenco delle configurazioni.
Deviazioni raggruppate per causa
I rilievi organizzati per origine comune, ciascuno con il riferimento pubblico. Correggere la causa chiude più voci in una volta ed evita la ricomparsa.
Percorsi dimostrati
Per i rischi più rilevanti, il tragitto concreto: da dove parte, cosa raggiunge e perché conta. Trasforma una deviazione di configurazione in un rischio comprensibile.
Valutazione di traccia e detection
Cosa è rimasto registrato delle azioni eseguite, cosa era disattivato e quali cambi sensibili oggi passerebbero inosservati.
Piano di correzione prioritizzato
Un ordine di lavoro che pesa rischio e sforzo, separando ciò che si risolve in configurazione da ciò che va cambiato nell'infrastruttura come codice per non tornare.
Frequently asked
No. La revisione si esegue con un profilo di audit in sola lettura, offerto nativamente da tutti e tre i fornitori. Per la verifica della portata concordiamo a parte credenziali specifiche e limitate, con ambito e durata definiti per iscritto.
Li integra, non li sostituisce. Lo strumento di postura copre volume e segue la deviazione in modo continuo, il che ha valore. Ciò che non fa è concatenare permessi per mostrare che una credenziale applicativa raggiunge un dato che dovrebbe essere isolato, ed è quella dimostrazione a cambiare le priorità.
Sì. L'ambiente misto è il caso comune, e il confronto tra fornitori spesso rivela protezioni disomogenee: lo stesso tipo di risorsa protetta in uno ed esposta nell'altro, perché costruite da team diversi.
L'orchestrazione rientra nell'ambito: ruoli e associazioni di accesso, contesto di sicurezza dei contenitori, politiche di rete tra servizi, esposizione del piano di controllo, gestione dei segreti e il legame tra identità del cluster e identità del cloud, una via di elevazione frequente.
L'ambiente che serve la produzione, come minimo. Gli account di sviluppo e collaudo meritano di rientrare quando hanno un percorso di rete o di identità verso la produzione, cosa più comune di quanto si creda, e proprio dove la protezione tende a essere più debole.
Correggendole all'origine. Quando l'ambiente nasce da infrastruttura come codice, la correzione va nel modulo e vale per ogni rilascio futuro. Per ciascun gruppo di deviazioni il rapporto indica se vada trattato sulla risorsa o nel modello che la crea.
Sì. Ogni rilievo porta il riferimento pubblico corrispondente e l'evidenza della configurazione osservata, in una forma che un revisore può verificare in modo indipendente senza rifare l'analisi.
Pronto a scoprire le tue falle?
La prima call di scoping è gratuita e coperta da NDA. In 48 ore ricevi proposta tecnica, scope e cronoprogramma. Senza moduli burocratici.