Quali permessi dare a un nuovo dipendente in AWS (e quali no)

Entra qualcuno di nuovo in azienda e ha bisogno di "accesso ad AWS". La cosa veloce è creare un utente, dargli AdministratorAccess e andare avanti con la giornata. È anche ciò che trasforma l'errore di uno stagista, o una password rubata, in un account svuotato o in una fattura da migliaia di euro. Quasi tutti gli spaventi con AWS nelle piccole aziende cominciano con qualcuno che aveva molti più permessi di quelli che gli servivano.

La regola è semplice: ogni persona può fare solo quello che le serve per il suo lavoro, e niente di più. Si chiama privilegio minimo e non richiede competenze di sicurezza. Richiede di pensare un minuto a cosa farà quella persona: guardare? accendere e spegnere macchine? creare e cancellare cose? Con quella risposta, AWS ha già i permessi pronti e basta sceglierli.

Questa guida usa i gruppi invece di dare permessi a ogni utente uno per uno. È la differenza tra decidere una volta per ogni funzione e decidere ogni volta che entra qualcuno.

Passo dopo passo

1. Decidi che funzione ha la persona

   Prima di toccare la console, rispondi a una domanda: cosa deve fare questa persona in AWS? Per una piccola azienda, quasi tutto rientra in tre funzioni:

   • Vedere: guardare lo stato delle macchine, consultare la fattura, leggere i log. È quello che serve a chi fa assistenza, a chi tiene la contabilità o a un capo che vuole "vedere come va".
   • Operare: oltre a vedere, accendere, spegnere e riavviare macchine, fare istantanee, ripristinare. È quello che serve a chi gestisce il giorno per giorno del server.
   • Amministrare: creare e cancellare macchine, cambiare le reti, gestire gli utenti. Questo serve solo a una o due persone, e dovrebbero essere quelle che ne sanno di più.

   Se sei indeciso tra due, comincia da quella con meno permessi. Salire è un clic; scoprire che qualcuno ha cancellato ciò che non doveva, no.

2. Crea i tre gruppi in IAM

   Apri IAM, menu di sinistra User groups, pulsante Create group. Fanne tre, con nomi che capisca chiunque: ver, operar e administrar. Creando ogni gruppo, nel blocco Attach permissions policies cerca e spunta la policy che gli spetta:

   • Gruppo ver: ReadOnlyAccess. Permette di consultare qualsiasi servizio senza cambiare nulla. Se vuoi solo che vedano la fattura, esiste AWSBillingReadOnlyAccess, più limitata.
   • Gruppo operar: ReadOnlyAccess e in più una policy propria con le azioni di avviare, fermare e riavviare (passo successivo). Per Lightsail non c'è una policy gestita intermedia, quindi la scriverai tu; per EC2 non ce n'è una che si limiti ad accendere e spegnere.
   • Gruppo administrar: PowerUserAccess, che permette quasi tutto tranne gestire utenti e permessi. Lascia AdministratorAccess a una sola persona, quella che custodisce anche l'account root.

   I gruppi si creano una volta sola. Da lì in poi, dare accesso a qualcuno significa metterlo nel gruppo giusto.

3. Scrivi la policy del gruppo "operar"

   In IAM, Policies, Create policy. Premi la scheda JSON e incolla questo, che permette di accendere, spegnere e riavviare macchine di Lightsail ed EC2, e fare istantanee, ma non creare né cancellare macchine:

   {
     "Version": "2012-10-17",
     "Statement": [
       { "Effect": "Allow", "Action": [
           "lightsail:StartInstance", "lightsail:StopInstance", "lightsail:RebootInstance",
           "lightsail:CreateInstanceSnapshot",
           "ec2:StartInstances", "ec2:StopInstances", "ec2:RebootInstances",
           "ec2:CreateSnapshot"
         ], "Resource": "*" }
     ]
   }

   Premi Next, chiamala operar-maquinas e creala. Poi, in User groups, entra in operar, scheda Permissions, Add permissions, Attach policies, e spunta operar-maquinas.

   Nota che non compare nessuna azione con "Delete" né "Terminate". È la differenza tra poter spegnere una macchina e poterla far sparire. Se vuoi limitarla anche a macchine specifiche, in Resource puoi mettere l'identificativo di ciascuna al posto dell'asterisco; per EC2 è semplice, per Lightsail bisogna usare l'ARN di ogni istanza.

4. Crea l'utente e mettilo in un gruppo

   IAM, Users, Create user. Nome: quello della persona (maria.lopez), mai qualcosa di condiviso come soporte. Spunta Provide user access to the AWS Management Console, scegli I want to create an IAM user e lascia spuntato che deve cambiare la password al primo accesso.

   Nella schermata dei permessi scegli Add user to group e spunta solo il gruppo che hai deciso al passo 1. Non collegare policy direttamente all'utente: tra sei mesi nessuno ricorderà perché ha quel permesso sciolto. Crea l'utente e annota l'indirizzo di accesso (contiene il numero del tuo account) per inviarglielo insieme alla password temporanea attraverso canali diversi: l'indirizzo via email, la password di persona o con un messaggio che scade.

   Se la persona non userà programmi che parlano con AWS, non creare chiavi di accesso. Si possono aggiungere il giorno in cui serviranno.

5. Rendi obbligatorio il doppio fattore

   Chiedi alla persona che, al primo accesso, vada nel menu con il suo nome, Security credentials, e assegni un dispositivo MFA con l'app del cellulare. Ma non lasciarlo alla buona volontà: in IAM, Policies, crea una policy che neghi tutto tranne la configurazione dell'MFA quando l'utente non è entrato con il doppio fattore, e collegala ai tre gruppi. AWS la propone come esempio nella sua documentazione con il nome "permettere agli utenti di gestire il proprio MFA"; copia il JSON da lì così com'è.

   L'effetto: chi entra senza MFA vede solo la schermata per attivarlo. Tutto il resto risulta bloccato finché non lo fa. È l'unico modo perché davvero ce l'abbiano tutti.

6. Controlla quello che nessuno dovrebbe avere

   Prima di dare per chiusa l'attivazione, ripassa in IAM, Users, colonna delle policy collegate:

   • AdministratorAccess su più di una o due persone: è di troppo. Nessuno che si limiti a operare le macchine ne ha bisogno.
   • IAMFullAccess su qualcuno che non gestisce utenti: con quel permesso può darsi da solo qualsiasi altro.
   • Permessi collegati direttamente all'utente invece che tramite gruppi: spostali nel gruppo o cancellali.
   • Chiavi di accesso su utenti di persone che non programmano nulla.

   Se trovi qualcosa del genere su utenti vecchi, approfittane per correggerlo. È il momento in cui risulta più facile.

7. Prepara l'uscita fin dal primo giorno

   Il giorno in cui qualcuno se ne va, il suo accesso ad AWS deve sparire lo stesso giorno, prima che riconsegni il computer. In IAM, Users, seleziona l'utente: prima disattiva l'accesso alla console e le chiavi di accesso (scheda Security credentials), aspetta una o due settimane per verificare che nulla dipendesse da quella persona, e poi elimina l'utente.

   Annotalo nella lista delle cose da fare all'uscita insieme all'email e alle chiavi dell'ufficio. E una volta a trimestre, scarica il Credential report di IAM: ti dice di ogni utente quando è entrato l'ultima volta, se ha l'MFA e se le sue chiavi vengono usate. Un utente che non entra da tre mesi è un utente che probabilmente non dovrebbe più esistere.

Cosa può andare storto