L'auditor chiede la policy SecurityAudit per l'ambiente AWS, quanto è sicuro questo accesso?

La policy SecurityAudit non include i permessi per scaricare oggetti dallo storage, quindi non possono prelevare i dati dei clienti. Possono però leggere i dati di configurazione delle funzioni o di bootstrap delle istanze. Se avete lasciato password in chiaro nel codice o negli user data delle VM, l'auditor le vedrà. Fate pulizia lì prima di iniziare.

Quando configurate il ruolo mettete tassativamente l'External ID obbligatorio. Aggiungete anche una restrizione sugli IP sorgente nella trust relationship in modo che possano loggarsi solo dagli IP del loro ufficio o della loro VPN. Finite le due settimane, cancellate il ruolo con un clic e siete a posto.

L'azienda di revisione userà uno scanner automatico o gli ingegneri controlleranno a mano da console? Se collegano tool cloud automatici, avete già chiesto per iscritto il loro account ID terzo da inserire nella trust relationship e la relativa policy per l'External ID?

Noi abbiamo definito un ruolo simile per un audit di conformità. Il controllo è durato 12 giorni. Non appena il processo è terminato, abbiamo eliminato il ruolo IAM e verificato la sessione dell'auditor tramite i log di audit; avevano effettuato in totale circa 14.200 chiamate API di sola lettura. Nessun tentativo di scaricare dati.

nn creare assolutamente un utente iam dandogli le access key. comunque poi quelle chiavi rimangono dimenticate da qlc parte. create solo un ruolo impostate l'external id e appena finiscono cancellate il ruolo e via.

Le società di revisione vogliono sempre la pappa pronta, ma non siete obbligati a concedere un ruolo direttamente sull'account di produzione. Molte aziende estraggono autonomamente i report di configurazione e gli output di sicurezza tramite strumenti da riga di comando e li consegnano come file. Perché mai dovreste aprire l'intero account a un'analisi dal vivo?

Nel contratto di riservatezza firmato prima dell'inizio dell'audit, deve essere formalizzato un impegno chiaro su come verranno trattati i dati di configurazione, dopo quanti giorni verranno distrutti i log archiviati nella cache degli strumenti di audit e che tali dati non saranno condivisi con terze parti.

Riassumendo: SecurityAudit accede alle configurazioni e non ai dati, motivo per cui è una richiesta standard. Ciononostante, concedete i permessi tramite un ruolo impostando External ID, restrizioni IP e un limite di tempo, e il giorno in cui l'audit termina eliminate il ruolo e controllate i log di sistema.

Ha ragione. Se cerchi di cambiare tutto insieme, niente si stabilizza.

Spero che le sia utile.

Esatto, e non è nemmeno così noto. La maggior parte degli incidenti non inizia da una vulnerabilità ma da una password trapelata.

Anche da noi è così.

C'è una parte che non ho capito. Più è difficile tornare indietro su una decisione, più lentamente dovreste prenderla.

Lascio una nota, potrebbe servire.

bisogna procedere con ordine. quando prendete una decisione scrivete anche lo scenario peggiore non solo quello migliore.

naturalmente cambia se la vostra situazione è diversa.

Sono d'accordo. Nessun processo migliora senza tracciamento, perché non sai cosa correggere.

È tutto, scusate se mi sono dilungato.

Il mio dubbio è stato chiarito, grazie. Non abbiate paura di chiedere, chi non chiede paga sempre di più.

corretto poi se rimproverate i falsi allarmi nessuno segnalerà più nulla.

io seuirei questa strada.

Sono passato da qui, vi racconto. Le persone difendono le abitudini, non i processi. La resistenza nasce da lì.

scrivo questo per evitare che facciate lo stesso errore. il tempo che impiegate a rilevare un problema ne determina direttamente il costo.

io seguirei questa strada.