Least Privilege e Shared Responsibility nel cloud

“Fidarsi è bene, non fidarsi è meglio.” Questo vale soprattutto quando si parla di sicurezza nel cloud. Per questo motivo, oggi esploreremo due concetti fondamentali: Least Privilege e Shared Responsibility Model.

Least Privilege e Shared Responsibility nel cloud: cosa sono?

A volte passare al cloud può essere visto come la soluzione panacea. Tuttavia, ci sono concetti fondamentali da comprendere per un uso consapevole delle tecnologie cloud. Due di questi sono il Least Privilege (privilegio minimo) e il Shared Responsibility Model (modello di responsabilità condivisa).

Comprendere e tenere sempre a mente questi principi è fondamentale per costruire soluzioni cloud sicure.

Shared Responsibility: quando la responsabilità è condivisa

Il modello di responsabilità condivisa è cruciale quando si lavora con servizi cloud. Molti pensano erroneamente che, migrando al cloud, la sicurezza diventi completamente responsabilità del provider.

Niente di più sbagliato.

Il modello stabilisce che:

• Il provider cloud è responsabile della sicurezza del cloud: infrastruttura fisica, datacenter, hardware, networking.

• Il cliente è responsabile della sicurezza nel cloud: configurazione dei servizi, gestione degli accessi, crittografia dei dati, patch delle applicazioni.

Esempio pratico con AWS S3: AWS garantisce che il servizio sia disponibile e sicuro. Ma se create un bucket S3 pubblico, quella è vostra responsabilità. AWS non può sapere se volete che il bucket sia pubblico: è una vostra scelta di configurazione.

Least Privilege: Il principio del privilegio minimo

Il principio del Least Privilege stabilisce che ogni utente, processo o servizio dovrebbe avere solo i permessi minimi necessari. Niente di più.

Immaginiamo un’applicazione web che deve leggere file da S3. La tentazione potrebbe essere assegnare il ruolo AmazonS3FullAccess.

Errore grave. Se l’applicazione viene compromessa, l’attaccante avrà accesso completo a tutti i bucket S3 dell’account.

La soluzione corretta? Creare una policy IAM personalizzata:

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

Questa policy permette solo la lettura da un bucket specifico. Niente scrittura, niente cancellazione, niente accesso ad altri bucket.

Come Applicare questi principi

1. Audit regolari delle policy IAM: Rivedete periodicamente tutte le policy e rimuovete i permessi non necessari.

2. Separazione degli ambienti: Non usate le stesse credenziali per sviluppo, staging e produzione.

3. Principio del “Need to Know”: Solo chi ha effettivamente bisogno di accedere a una risorsa dovrebbe avere i permessi.

4. Revisione periodica: La sicurezza non è un “set and forget”. Pianificate revisioni periodiche.

Conclusioni

Il cloud offre vantaggi incredibili, ma con responsabilità. Comprendere il modello di responsabilità condivisa e applicare il least privilege sono fondamentali per costruire soluzioni cloud sicure.

La sicurezza è un processo continuo. Ogni configurazione, ogni policy, ogni permesso dovrebbe essere giustificato e documentato.