Siamo passati ad AWS — c'è un tool per verificare la sicurezza cloud da soli senza pagare un auditor?

La primissima cosa su cui concentrarsi sono storage e permessi IAM. Dalla console attivate il blocco dell'accesso pubblico a livello di intero account con un solo clic. Poi andate a beccare nelle policy IAM gli utenti con permessi di amministrazione illimitati (quelli con l'asterisco) e riduceteli secondo il principio del minimo privilegio. Non dimenticatevi di attivare il servizio di audit logging in tutte le regioni.

Anche a noi a New York avevano fatto un preventivo simile mentre migravamo l'infrastruttura e-commerce, ci avevano chiesto 5.500 dollari. Due nostri sviluppatori hanno fatto girare degli script di audit open source. Sono venuti fuori 18 errori critici di configurazione, di cui 11 erano vecchi security group dimenticati. Abbiamo risolto tutto in 3 giorni a costo zero.

I tool open source automatici sono ottimi ma non fidatevi ciecamente. Quegli scanner controllano solo i settaggi dell'infrastruttura cloud. Non vi diranno mai se c'è una falla di autorizzazione nel codice o se il database è vulnerabile a SQL injection. In pratica l'infrastruttura può risultare tutta verde anche se l'applicazione è un colabrodo.

La cosa più urgente da fare stasera stessa: smettetela di usare l'utenza root per il lavoro quotidiano. Create un nuovo account dev, impostate una chiave di sicurezza fisica sull'account root e blindate la password in cassaforte. La maggior parte dei data breach sul cloud scoppia proprio per chiavi admin finite online.

I clienti con cui state per firmare richiedono un report di conformità standard o la firma di un auditor indipendente ufficiale? Perché se nel capitolato è obbligatoria una certificazione formale la scansione fatta da voi da sola potrebbe non bastare in sede contrattuale.

anche noi eravamo andati nel panico appena migrati poi abbiamo installato due scanner open source diversi, collegati alla console e ci hanno sputato fuori un bel report html. la cosa più assurda è ke su un server di test rimasto esposto c'erano migliaia di tentativi di login in soli 2 giorni abbiamo chiuso subito le porte.

con il budget tirato quei 6.000 dollari non spendeteli assolutamente. la scheda gratuita del consulente integrato e i soliti script di audit su GitHub bastano e avanzano. dedicateci un fine settimana, mettetevi lì col team e smarcate i puni uno a uno.

La sicurezza non è un controllo una tantum, è un processo continuo. Anche se oggi spendete 6.000 dollari per avere un report immacolato, basterà che un dev la prossima settimana apra una regola sbagliata per ritrovarvi vulnerabili. Per questo conviene integrare il tool di audit open source come step automatico nella pipeline di deploy del codice.

Se volete procedere così, risolvete questo punto fin dall'inizio. Cercare di farlo da soli è la strada più costosa.

La maggior parte degli incidenti non inizia da una vulnerabilità, ma da una password trapelata.

Sosterrò l'opposto, non prendetela male. Cercare di farlo da soli è la strada più costosa.

È tutto, scusate se mi sono dilungato.

Sono d'accordo.

Ci proverò. Se cerchi di cambiare tutto insieme, niente si stabilizza.

È tutto, scusate se mi sono dilungato.

Questo thread è archiviato.

c'è anche un aspetto di misurazione. avere il backup accessibile sulla stessa rete e con le stesse credenziali lo rende parte del bersaglio.

se scrivete qui il risulltato sarà utile anche ad altri.

La discussione si è dispersa la riassumo. Cercare di farlo da soli è la strada più costosa.

Se scrivete qui il risultato, sarà utile anche ad altri.

Sono d'accordo, anzi vorrei sottolinearlo. Se non lo rendete scritto fin dall'inizio, poi nascono discussioni.

Correggetemi se sbaglio.

Se scendiamo nei dettagli: Prendere appunti per due settimane dà risultati migliori rispetto a una stima di sei mesi.

sosterrrò l'opposto, non prendetela male. prendere misure senza fare un inventario lascia aperta una porta che non vedi.