IAM AWS: Least Privilege e Policy Management — Guida Avanzata per Chi non Vuole Regali di Natale a Metà Prezzo

Hai un account AWS con decine di utenti, ruoli e policy che non ricordi più chi ha accesso a cosa? Non sei solo. Lo vediamo ogni giorno quando ci chiamano per ripulire ambienti AWS cresciuti senza controllo. Il risultato? Un permesso S3:DeleteObject su un bucket di fatture, una policy con Effect:Allow, Action:* su un account di sviluppo, e la sensazione che un attacco sia solo questione di tempo.

Noi, di Meteora Web, veniamo anche dalla contabilità: bilanci, partita doppia, IVA. Per questo ragioniamo sui numeri. Un overprivileged account non è solo un rischio di sicurezza — è un costo nascosto. Più permessi di quanti servono significano più superficie d'attacco, più audit log da analizzare, più possibilità di errore umano. E quando arriva una breach, il costo di remediation è esponenziale.

In questa guida avanzata vediamo come applicare il principio del minimo privilegio (least privilege) su AWS, gestendo policy in modo granulare, con esempi reali e codice copia‑incolla. Partiamo dalla teoria, arriviamo al comando da eseguire oggi.

Perché il Minimo Privilegio non è un Optional

Immagina di dare a ogni dipendente le chiavi di tutti i magazzini, della cassa e del server dei dati clienti. Sembra assurdo, ma su AWS è la configurazione più comune. Il principio del minimo privilegio dice: ogni utente, ruolo o servizio deve avere solo i permessi strettamente necessari per fare il suo lavoro, e niente di più.

Non è solo sicurezza. È anche economia: meno permessi = meno log da filtrare, meno incidenti, meno tempo speso a indagare falsi positivi. Quando un cliente ci chiede "Ho un accesso che non serve più, ma non so chi l'ha creato", capiamo subito il problema. Ecco perché le policy AWS vanno trattate come contratti: chiare, firmate e revocabili.

L'Approccio "Nega per Default"

AWS parte da un principio implicito: tutto è negato fino a quando non viene esplicitamente permesso. Sembra banale, ma la maggior parte degli incidenti deriva da policy che danno un Allow troppo ampio, magari con Action: * su una risorsa critica. La regola d'oro: scrivi le policy come se il tuo account venisse violato domani.

Esempio concreto: una policy per un EC2 che deve solo leggere da un bucket S3.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::mio-bucket-dati",
        "arn:aws:s3:::mio-bucket-dati/*"
      ]
    }
  ]
}

Niente s3:PutObject, niente s3:DeleteObject. Se l'EC2 viene compromesso, l'attaccante non può cancellare il bucket. Sembra ovvio? Eppure, in revisioni su account di clienti, abbiamo visto policy che concedevano s3:* su Resource: "*".

Policy AWS: Tipi, Struttura e Best Practice

Le policy in AWS si dividono in identity‑based (allegate a utenti, gruppi, ruoli) e resource‑based (allegate a risorse come bucket S3 o CodeBuild). Entrambi i tipi possono essere usati per least privilege, ma con attenzione alle interazioni.

Identity‑Based Policy: il Cavallo di Battaglia

Sono le più comuni. Scriville sempre con azioni specifiche, mai con iam:* se non in fase iniziale di bootstrap. Per ogni ruolo, chiediti: "Qual è la lista minima di API che questo ruolo deve chiamare?"

Noi usiamo spesso policy condizionali per limitare ulteriormente. Ad esempio, permettere l'accesso a un bucket solo se la richiesta viene da una VPC specifica:

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::mio-bucket/*",
  "Condition": {
    "StringEquals": {
      "aws:SourceVpc": "vpc-12345678"
    }
  }
}

Questo blocca accessi da internet anche se le credenziali vengono rubate. Una delle poche volte in cui un Allow rimane sicuro perché vincolato.

Resource‑Based Policy: Quando la Risorsa Decide

I bucket S3, le funzioni Lambda, le code SQS hanno policy proprie. Il least privilege si applica anche qui: non dare mai Principal:"*" senza una condizione forte. Esempio su un bucket che deve essere pubblico per una landing page statica:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::mio-sito-public/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": ["203.0.113.0/24", "198.51.100.0/24"]
        }
      }
    }
  ]
}

Attenzione: qui Principal:"*" è accettabile solo perché limitato a IP trusted e azione sola lettura. Mai usarlo su risorse critiche.

Gestione delle Policy: Organizzazione e Versioning

Con la crescita, le policy diventano un groviglio. Noi di Meteora Web abbiamo visto account con oltre 200 policy customer managed, molte inutilizzate. Le policy vanno curate come il codice: versionate, commentate, testate.

Policy Manager: Strumenti e Comandi

Usa l'AWS CLI per listare e analizzare le policy. Comando base per vedere le policy allegate a un utente:

aws iam list-attached-user-policies --user-name mario.rossi

Per capire quali policy non sono mai state usate, combina con last-accessed. Un comando che eseguiamo spesso nelle revisioni:

aws iam generate-service-last-accessed-details --arn arn:aws:iam::123456789012:policy/MyUselessPolicy
aws iam get-service-last-accessed-details --job-id 

Se una policy non ha accessi recenti, probabilmente non serve. Valuta di eliminarla o restringerla.

Naming Convention e Tagging

Adotta uno standard: [env]-[servizio]-[azione]-[risorsa], ad esempio prod-s3-get-mybucket. Usa i tag AWS per marcare le policy con proprietario, data di creazione, severità. Questo facilita le revisioni periodiche.

Ruoli IAM vs Utenti: Quando Usare Cosa

Uno degli errori più comuni: creare utenti IAM umani. Per persone, usa sempre ruoli con federazione (SAML, SSO). Per servizi, usa ruoli con assunzione automatica. Gli utenti IAM con chiavi lunga durata sono bombe a orologeria. Le chiavi scadono, si dimenticano, finiscono nei repository GitHub. Lo abbiamo visto decine di volte.

Esempio: un EC2 che deve accedere a DynamoDB. Crea un ruolo IAM con la policy necessaria, allegarlo al profilo dell'istanza. Nessuna chiave segreta da gestire.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:Query"
      ],
      "Resource": "arn:aws:dynamodb:eu-west-1:123456789012:table/Ordini"
    }
  ]
}

Niente *, solo lettura su una tabella specifica. E l'istanza non può fare PutItem o DeleteTable — minimo privilegio perfetto.

Policy Boundaries: Un Giro di Vite Ulteriore

Le policy boundaries (confini di autorizzazione) sono il livello successivo. Permettono di limitare i permessi massimi che un ruolo può avere, anche se le policy allegate concedono di più. Utili per delegare la creazione di ruoli a team diversi senza perdere controllo.

Esempio: un boundary che impedisce qualsiasi azione su risorse S3 di produzione, anche se il team crea una policy che concede s3:*. Il boundary prevale.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::produzione-*"
    }
  ]
}

Questa boundary va allegata al ruolo del team di sviluppo. Così, anche se sbagliano, non possono toccare i dati di produzione.

Audit e Monitoraggio: Non Fidarti, Verifica

Applicare il minimo privilegio è un processo continuo. Usa AWS Config per rilevare policy non conformi, CloudTrail per tracciare le azioni, e IAM Access Analyzer per trovare policy troppo permissive. Esegui revisioni trimestrali. Noi le inseriamo nei contratti di manutenzione dei clienti: un'ora al mese per analizzare e pulire le policy.

Uno strumento pratico: IAM Access Analyzer identifica automaticamente le policy che concedono accesso a entità esterne (oltre il tuo account). Attivalo e configura le notifiche per ogni nuovo avviso.

In Sintesi — Cosa Fare Adesso

Non aspettare l'incidente. Esegui questi passi oggi:

1. Audit delle policy attuali: usa aws iam list-policies --scope Local e controlla quante hanno Action: "*". Per ciascuna, chiediti: serve davvero?
2. Elimina o restringi le policy con asterisco multiplo. Sostituisci con la lista di azioni effettivamente necessarie. Usa l'elenco ufficiale delle azioni AWS per trovare quelle specifiche.
3. Passa da utenti IAM a ruoli federati. Se hai utenti umani con chiavi, migra a SSO o IAM Identity Center entro 30 giorni.
4. Implementa policy boundaries per ogni ruolo creato da altri team. Crea una customer managed policy di boundary con un Deny su risorse critiche (produzione, dati sensibili).
5. Attiva IAM Access Analyzer e AWS Config. Configura regole per rilevare policy non conformi e ricevi notifiche via SNS.

La sicurezza su AWS non è un prodotto che compri — è una pratica quotidiana. Noi di Meteora Web lo viviamo ogni giorno con i clienti. Se vuoi un check approfondito del tuo account, contattaci. Intanto, inizia dalla revisione delle policy. Il tuo futuro te (e il tuo budget) ti ringrazieranno.