L'auditor del cliente ci ha chiesto di aprire un 'ruolo di audit di sicurezza AWS' sul nostro account cloud: quanti permessi dobbiamo concedere?

La distinzione fondamentale è tra ReadOnlyAccess e SecurityAudit. Se assegnate ReadOnlyAccess, l'auditor può scaricare i file dagli storage di oggetti e spulciare fin troppo i metadati dei database. Un auditor di sicurezza necessita unicamente della policy SecurityAudit e, se proprio serve, di un paio di dashboard di monitoraggio limitate.

Per un ruolo di audit sicuro non saltate questi tre passaggi: 1) Aggiungete una condizione ExternalId casuale e non indovinabile alla trust policy del ruolo. 2) Impostate la durata massima della sessione (MaxSessionDuration) a un'ora. 3) Inserite una restrizione sull'indirizzo IP nella resource policy per vincolare il ruolo a un blocco IP specifico.

Sono davvero pochi gli standard di audit che impongono all'auditor esterno di accedere direttamente all'account AWS di produzione. Nella maggior parte dei casi i report di configurazione e gli export bastano e avanzano. Prima di farli entrare nell'account, avete chiesto per iscritto perché non accettano semplicemente i report di configurazione?

correzione: mi ricordavo male il numero, era un po' più basso.

Prima di definire qualsiasi accesso è necessario siglare un accordo di non divulgazione (NDA) bilaterale con la società di audit. In questo accordo devono essere specificati chiaramente il perimetro dell'audit, le risorse a cui si accederà e la responsabilità dei log di sessione. Nessuna autorizzazione sull'account deve essere condivisa prima di aver definito il quadro legale.

L'anno scorso abbiamo affrontato due audit simili. Abbiamo tenuto attivo il ruolo solo per una finestra di 72 ore e limitato la sessione a 3 ore. L'auditor ha lanciato in tutto appena 42 query API diverse e ha finito il suo lavoro. Non appena è scaduto il tempo abbiamo rimosso il ruolo, zero problemi.

la prima volta ci si fa prendere dall'ansia, normalissimo... ma niente panico: se dite all'auditor del cliente "per policy interna non possiamo fornire utenti console diretti creiamo un ruolo di audit con identificativo esterno", dimostrate subito grande professionalità.

dopo aver creato il ruolo filtrate su cloudtrail per il nome del ruolo dell'auditor e date un'occhiata ogni tanto a cosa combina. onestamente se gira a vuoto tra servizi che nn c'entrano glielo chiedete subito.

Senza perdere tempo andate sul pannello IAM, create un nuovo ruolo, scegliete come tipologia un altro account AWS, inserite l'ID account del cliente, spuntate la casella dell'External ID collegate solo il permesso SecurityAudit e salvate.

Racconto la mia esperienza. Il vero problema non è il numero, ma su cosa si basa quel numero.

Sono curioso di sapere se qualcuno lo fa in modo diverso.

Guardando al processo, il quadro cambia. Se cerchi di cambiare tutto insieme, niente si stabilizza.

È tutto, scusate se mi sono dilungato.

C'è anche un aspetto di misurazione. Un report di scansione automatica e un penetration test non sono la stessa cosa.

Sono curioso di sapere se qualcuno lo fa in modo diverso.

Ha ragione.

Se volete procedere così, risolvete questo punto fin dall'inizio. Il fatto che tutti facciano una cosa non significa che sia quella giusta.

Le modifiche ai dati di pagamento non vanno mai verificate tramite il canale di provenienza. Sono curioso di sapere se qualcuno lo fa in modo diverso.

Avete ragione, sono passato anch'io per la stessa strada. Gli ambienti di test dimenticati diventano spesso un punto d'accesso più frequente del sistema live.

Dopo aver vissuto questa cosa, il mio punto di vista è cambiato. Nessun processo migliora senza tracciamento, perché non sai cosa correggere.

Un report di scansione automatica e un penetration test non sono la stessa cosa. Confermato dall'esperienza.

Non lo sapevo.

Ho vissuto la stessa cosa.

Approfondisco l'aspetto tecnico. Gran parte del tempo perso si accumula nelle pratiche in attesa di approvazione.

Naturalmente cambia se la vostra situazione è diversa.