Docs

Sicurezza

Cloud sicuro ☁️🔐

Cloud sicuro: identità, segreti e firewall ☁️🔐

Il cloud non è una nuvola magica che protegge tutto da sola: serve metodo, attenzione e qualche buona pratica per evitare che i dati finiscano dove non dovrebbero (tipo su un forum pubblico o in una cartella condivisa con mezzo mondo). In questa guida introduttiva trovi tutto quello che serve per costruire una strategia di sicurezza cloud solida, senza perdere il sonno (o almeno, non troppo spesso).

Fondamenti di Identity & Access Management (IAM) 🪪

L’Identity & Access Management (IAM) è il cuore della sicurezza cloud: senza una gestione rigorosa delle identità e dei permessi, il rischio di accessi non autorizzati è dietro l’angolo. IAM permette di:

Definire chi può accedere a cosa e quando
Tracciare ogni azione rilevante
Automatizzare la gestione delle identità su larga scala

Componenti chiave di IAM 🧩

Utenti: rappresentano persone reali o applicazioni che necessitano di accedere a risorse. Ogni utente dovrebbe avere un’identità unica e non condivisa.
Gruppi: aggregano utenti con esigenze simili, semplificando la gestione dei permessi. Ad esempio, un gruppo “sviluppatori” può avere accesso in sola lettura a certi ambienti.
Ruoli: ideali per accessi temporanei o per delegare permessi a servizi/applicazioni. I ruoli sono perfetti per task automatizzati o per chi deve svolgere attività specifiche solo in certi momenti.
Policy: regole che stabiliscono cosa è consentito o vietato. Le policy dovrebbero essere chiare, granulari e documentate, per evitare sorprese. Esempi pratici di policy:
- Permettere agli utenti di ruotare le proprie credenziali senza intervento dell’amministratore
- Consentire a un servizio di accedere solo a una specifica risorsa per un tempo limitato
- Abilitare un utente a gestire solo le risorse di un determinato progetto

Identità = chi. Policy = chi può fare cosa, dove e quando. Semplice, no?

Controlli di accesso a privilegio minimo 🦶

Il principio del privilegio minimo (Principle of Least Privilege, PoLP) è una delle colonne portanti della sicurezza informatica. Immagina di dare a un idraulico le chiavi di casa: gli daresti solo la chiave del bagno e del locale caldaia, non quella della cassaforte. Lo stesso vale per il cloud.

Ogni identità (umana o macchina) deve avere solo i permessi strettamente necessari per svolgere il proprio lavoro, niente di più. Questo riduce drasticamente:

Il rischio di errori umani: un comando sbagliato con privilegi eccessivi può causare danni enormi.
L’impatto di eventuali compromissioni: se un account viene violato, l’attaccante avrà accesso solo a un perimetro limitato.
La superficie d’attacco complessiva: meno privilegi in giro, meno porte aperte per potenziali minacce.

Come implementarlo in pratica

Parti da zero: quando crei un nuovo utente o servizio, non assegnare alcun permesso di default.
Aggiungi solo il necessario: concedi i permessi uno alla volta, solo quando emerge una necessità reale e documentata.
Sii granulare: invece di dare accesso a un intero servizio (es. s3:*), concedi solo le azioni specifiche necessarie (es. s3:GetObject).
Usa accessi a tempo: per operazioni sensibili, concedi permessi che scadono automaticamente dopo un breve periodo.

Consiglio pratico: rivedi periodicamente i permessi assegnati (almeno ogni 90 giorni) e automatizza la revoca di quelli inutilizzati con strumenti di Cloud Infrastructure Entitlement Management (CIEM). Meglio un utente che chiede un permesso in più, che uno che può fare troppo senza motivo!

Soluzioni di identità centralizzate e decentralizzate 🏢🔗

La gestione delle identità digitali può seguire due approcci principali: centralizzato e decentralizzato. La scelta dipende dal contesto, dai requisiti di sicurezza e dalla filosofia dell’organizzazione.

Soluzioni centralizzate 🏛️

In un sistema centralizzato, un’unica autorità, chiamata Identity Provider (IdP), gestisce tutte le identità e le policy di accesso. Pensa a come accedi ai servizi Google: usi un solo account per Gmail, Drive e Calendar. Quello è un sistema centralizzato.

Questo approccio facilita:

L’onboarding e l’offboarding degli utenti: un solo posto per creare o disattivare un account.
L’applicazione di policy coerenti: le regole di sicurezza sono uniformi per tutti i servizi collegati.
Il monitoraggio e l’audit: è più semplice tracciare chi ha fatto cosa e quando.

Attenzione: un sistema centralizzato è comodo, ma rappresenta anche un single point of failure. Se l’IdP è compromesso, tutti gli account e i servizi collegati sono a rischio. Per questo è fondamentale proteggerlo con autenticazione forte (MFA), monitoraggio costante e backup regolari. Esempi comuni sono Azure Active Directory, Okta o Auth0.

Soluzioni decentralizzate 🪪

Le soluzioni decentralizzate, come il modello Decentralized Identity (DID) e le Verifiable Credentials (VC), restituiscono il pieno controllo dell’identità all’utente. Non c’è un’autorità centrale che può creare, modificare o revocare la tua identità digitale. L’utente conserva le proprie credenziali in un “wallet” digitale personale e le presenta quando necessario.

Questo approccio è ideale per:

Scenari di privacy avanzata: l’utente decide quali informazioni condividere, senza intermediari.
Applicazioni che richiedono self-sovereign identity (SSI): l’identità è di proprietà e controllo esclusivo dell’individuo.
Ecosistemi distribuiti e federati: permette l’interoperabilità tra sistemi diversi senza bisogno di accordi di federazione complessi.

Questo modello, basato su standard del W3C, sta emergendo come la base per un’identità digitale più sicura, privata e portabile nel Web3 e oltre.

Esempio pratico e confronto visivo 🔍

Supponiamo di voler accedere a un portale aziendale e, in un altro scenario, a un servizio che supporta identità decentralizzate:

Centralizzato: l’utente usa SSO aziendale (IdP) e ottiene un token per il portale. L’azienda controlla provisioning, policy e revoca.
Decentralizzato: l’utente presenta una credenziale verificabile (VC) dal proprio wallet; il servizio verifica la firma tramite un registro pubblico (DID Registry) senza coinvolgere un IdP centrale.

Quando scegliere cosa?

Scegli centralizzato se vuoi onboarding/offboarding rapido, controllo granulare e integrazione con sistemi esistenti (HR, SCIM, MDM).
Scegli decentralizzato se priorità sono privacy, portabilità delle credenziali, interoperabilità tra domini senza federazioni complesse.

Meccanismi di autenticazione e autorizzazione 🔑

L’autenticazione risponde alla domanda “chi sei?”. L’autorizzazione risponde a “cosa puoi fare?”. Entrambe sono fondamentali per la sicurezza.

Autenticazione: come dimostrare chi sei 🕵️‍♀️

Single Sign-on (SSO): permette di accedere a più servizi con un solo login. Riduce la fatica (e la tentazione di usare la stessa password ovunque), ma va protetto con MFA.
Identità federata: consente di usare credenziali di un provider esterno per accedere a servizi diversi. Utile per collaborazioni tra aziende o per integrare servizi cloud e on-premise.
Multi-factor authentication (MFA): aggiunge un ulteriore livello di sicurezza. Non basta più solo la password: serve anche un codice temporaneo, una chiave fisica o un dato biometrico.
Password: la soluzione più diffusa (e più attaccata). Usale solo se non puoi farne a meno, e sempre con MFA.

Single Sign-on (SSO) 🔗

Un login per domarli tutti. Con il Single Sign-On, un utente si autentica una sola volta presso un Identity Provider (IdP) fidato e ottiene l’accesso a più applicazioni e servizi senza dover inserire nuovamente le credenziali.

Come funziona? Dopo il login iniziale, l’IdP genera un token (come SAML o OIDC) che viene presentato alle altre applicazioni come prova di identità.
Vantaggi: migliora l’esperienza utente, riduce la “password fatigue” e centralizza la gestione degli accessi.
Rischi: se l’account principale viene compromesso, un attaccante potrebbe accedere a tutti i servizi collegati. Per questo, l’SSO deve essere sempre protetto da Multi-Factor Authentication (MFA).

Identità federata 🌍

L’identità federata è un’evoluzione del SSO che funziona tra diverse organizzazioni. Permette a un utente di un’azienda A di accedere ai servizi di un’azienda B usando le proprie credenziali aziendali.

Come funziona? Si basa su una relazione di fiducia tra gli Identity Provider delle due organizzazioni.
Vantaggi: elimina la necessità di creare account duplicati per partner e collaboratori esterni, semplificando la gestione e migliorando la sicurezza.
Esempio: un consulente esterno che accede alla rete di un cliente usando il proprio account aziendale.

Workflow di autenticazione federata 🔄

Il processo di federazione è orchestrato da protocolli standard come SAML 2.0 o OpenID Connect (OIDC).

L’utente tenta di accedere a un’applicazione (Service Provider, SP).
L’SP reindirizza l’utente al suo Identity Provider (IdP) per l’autenticazione.
L’utente si autentica (con password e MFA).
L’IdP genera un’asserzione (un token firmato digitalmente) contenente le informazioni sull’utente e la invia all’SP.
L’SP verifica la firma dell’asserzione, si fida dell’IdP e concede l’accesso all’utente.

Questo flusso evita la proliferazione di account e password, centralizzando il controllo e la sicurezza.

Multi-factor authentication (MFA) 🛡️

Due (o più) fattori per essere davvero sicuri che sei tu:

Qualcosa che sai (password, PIN)
Qualcosa che hai (OTP, chiave fisica)
Qualcosa che sei (impronta, posizione)

Consiglio: attiva sempre MFA dove possibile, soprattutto per account amministrativi e servizi critici.

Autorizzazione: chi può fare cosa? 🗝️

RBAC (Role-based Access Control)

Permessi assegnati in base al ruolo aziendale. È semplice da capire e governare.

Punti di forza: facile da auditare, ben supportato nei cloud, ottimo per scenari stabili.
Limiti: può crescere a dismisura (role explosion) e gestire male condizioni dinamiche (es. orario, contesto dispositivo).
Esempio: ruoli viewer, developer, ops, admin con scope su progetto/ambiente.
Best practice: ruoli compositi a granularità fine, separazione tra ruoli umani e workload identity, evita ruoli “catch-all”.

Pattern utile: mappa ruoli → permessi → risorse con scope chiaro (es. project:prod, namespace:payments). Usa gruppi per assegnare i ruoli agli utenti.

ABAC (Attribute-based Access Control)

Permessi determinati da attributi e condizioni (es: orario, dipartimento, localizzazione, device posture).

Punti di forza: flessibile, contestuale, riduce la proliferazione di ruoli.
Limiti: regole complesse, rischio di inconsistenze se non documentato/versionato.
Esempio: “Utenti del dipartimento Finance possono accedere ai report solo in orario di ufficio, da device conformi e da IP aziendali”.
Best practice: definisci un data model di attributi, centralizza la policy (es. OPA/Rego), versiona le regole e aggiungi test.

Pattern avanzati correlati:

ReBAC (Relationship-based): autorizzazioni basate su relazioni (es. grafo “Alice è owner del repo X”). Utile per collaboration e risorse condivise.
PBAC (Policy-based): separa le policy dal codice/ruoli usando un motore di policy (es. OPA), ottimo per Zero Trust.

Suggerimento operativo: parti da RBAC per baseline e aggiungi ABAC per i casi che richiedono contesto (geografia, device, orario). Monitora l’effetto delle regole con audit e metriche.

Gestione dei segreti 🤫

I “segreti” sono le chiavi del regno digitale: password, chiavi API, token, certificati. Se finiscono nelle mani sbagliate, le conseguenze possono essere disastrose. Gestirli non è (solo) una questione di fiducia, ma una necessità critica che richiede strumenti e processi robusti per prevenire accessi non autorizzati, fughe di dati e interruzioni del servizio.

Tipi di segreti 🔑

Password di utenti e servizi
Chiavi API, di cifratura, SSH
Certificati TLS/SSL
Credenziali cloud e database
Token di accesso temporanei

Secret management: la tabella della verità 📊

Entità	Segreti	Infrastruttura IT
Utenti	Credenziali utente	App
App	API Key	Database
Servizi	Chiavi di cifratura	Cloud resources

Gestione centralizzata dei segreti 🧑‍💼

La pratica di hardcodare i segreti nel codice o nei file di configurazione è una delle principali cause di incidenti di sicurezza. Un sistema di gestione centralizzata dei segreti (come HashiCorp Vault, AWS Secrets Manager o Azure Key Vault) risolve questo problema fornendo:

Storage sicuro: i segreti vengono cifrati sia a riposo (on-disk) che in transito (over-the-network) utilizzando algoritmi crittografici robusti.
Rotazione automatica: le policy possono imporre la rotazione periodica di password e chiavi, riducendo la finestra di opportunità per un attaccante in caso di compromissione.
Access control granulare: solo le identità (utenti o macchine) autorizzate possono accedere a specifici segreti, e solo per il tempo strettamente necessario (accesso just-in-time).
Audit e monitoring dettagliato: ogni accesso, tentativo di accesso o modifica a un segreto viene registrato, fornendo una traccia di audit completa per il monitoraggio e le indagini forensi.

Best practice: non salvare mai segreti in chiaro nel codice, nei file di configurazione o nei repository Git. Usa sistemi di gestione centralizzata e inietta i segreti dinamicamente al runtime. Automatizza la rotazione per ridurre il rischio legato a segreti statici e longevi.

Rotazione automatica 🔄

I segreti statici sono un bersaglio facile. Più a lungo una chiave o una password rimane invariata, maggiore è il rischio che venga compromessa e utilizzata in modo improprio. La rotazione automatica è una difesa proattiva che invalida periodicamente le vecchie credenziali e le sostituisce con nuove.

Frequenza: la frequenza di rotazione dipende dalla criticità del segreto. Ad esempio: chiavi API ogni 90 giorni, password di servizio ogni 60-90 giorni, certificati TLS prima della scadenza (con auto-rinnovo). I token di accesso a breve termine possono durare solo pochi minuti.
Tecniche: i moderni sistemi di gestione dei segreti si integrano con le applicazioni per rendere la rotazione trasparente. Utilizzano versioning dei segreti e riferimenti dinamici, in modo che le applicazioni recuperino sempre la versione più recente senza bisogno di riavvii o modifiche manuali.
Antifragilità: la rotazione non deve essere un evento eccezionale. Testala regolarmente in ambienti di non produzione per assicurarti che i processi funzionino correttamente e per evitare sorprese (e interruzioni) in produzione.

Audit & monitoring 👀

Se non puoi vederlo, non puoi proteggerlo. Un logging completo di tutti gli accessi ai segreti è fondamentale per la sicurezza e la compliance. Se succede qualcosa, la prima domanda sarà: “Chi ha avuto accesso a cosa e quando?”.

Log minimi: ogni record di log dovrebbe includere: l’identità che ha richiesto l’accesso (chi), il segreto a cui si è tentato di accedere (cosa), il timestamp (quando), l’esito dell’operazione (successo/fallimento), l’indirizzo IP di origine (da dove) e, se possibile, una giustificazione per l’accesso.
Alert utili: configura alert automatici per attività sospette, come un numero elevato di accessi falliti, accessi a segreti critici fuori dal normale orario di lavoro, o richieste provenienti da geografie insolite.
Conservazione e protezione: i log di audit sono dati sensibili. Devono essere protetti da manomissioni (ad esempio, scrivendoli in storage WORM - Write-Once, Read-Many) e conservati per un periodo definito dalle policy aziendali e normative. L’integrazione con un sistema SIEM (Security Information and Event Management) permette di correlare gli eventi e ottenere una visione d’insieme della postura di sicurezza.

Classificazione e segmentazione dei dati 🗂️

La classificazione e la segmentazione dei dati sono fondamentali per sapere cosa proteggere e come. Non tutti i dati sono uguali!

Classificazione dei dati 🏷️

Organizzare i dati in base a sensibilità, valore e normative. Ad esempio:

Dati pubblici: possono essere condivisi senza problemi
Dati interni: accessibili solo all’organizzazione
Dati riservati: accesso limitato a pochi
Dati regolamentati: soggetti a normative specifiche (GDPR, PCI-DSS, HIPAA)

Dati sensibili e regolamentati ⚖️

PII (dati personali): nome, email, telefono, impronta digitale, ecc.
Dati finanziari: transazioni, conti, carte di credito.
PHI (dati sanitari): diagnosi, terapie, assicurazioni…

Regolamenti: GDPR, CCPA, PCI-DSS, SOX, HIPAA, PIPEDA

Segmentazione dei dati 🪓

Dividere i dati in segmenti separati per uso, accesso o compliance. Così, se qualcuno entra, non trova tutto il tesoro in un colpo solo.

Isolamento logico 🧱

Separazione tramite software: reti virtuali isolate, permessi granulari, cifratura, tagging. Ideale per ambienti multi-tenant o per separare ambienti di sviluppo, test e produzione.

Pattern: account/project per ambiente, VPC/VNET per dominio, subnet per tier, security boundary per team/prodotto.
Tagging/labels: usali per policy di accesso, cifratura, backup, DLP e cost allocation.
Zero Trust: applica policy di accesso per servizio (mTLS, identity-based policies) invece di perimetri fidati.

Isolamento fisico 🏢

Separazione hardware: server dedicati, regioni specifiche, cloud privato. Utile per dati altamente sensibili o per esigenze di compliance stringenti.

Scelte tipiche: regioni con residenza dati richiesta, host dedicati per workload regolamentati, HSM dedicati per chiavi critiche.
Trade-off: costi più alti, meno elasticità; usalo dove il rischio/compliance lo giustifica.

Tecniche di cifratura 🔒

La cifratura è la cintura di sicurezza dei dati: senza, ogni altro controllo rischia di essere inutile.

Cifratura a riposo 🛌

Proteggi i dati archiviati su dischi, database e backup. Usa algoritmi robusti e gestisci le chiavi con attenzione.

Scelte pratiche: abilita encryption by default su storage, database e snapshot/backup.
Chiavi: preferisci KMS con chiavi gestite dal provider (PMK) o gestite dal cliente (CMK) dove serve controllo/rotazione.
Verifica: includi controlli di cifratura nelle pipeline e nei benchmark di configurazione (CIS, org policy).

Cifratura in transito 🚚

Proteggi i dati mentre viaggiano tra client, server e servizi. Usa protocolli sicuri come TLS e verifica sempre la configurazione.

TLS ovunque: forza HTTPS, disabilita cipher deboli, usa HSTS e TLS moderni (1.2+ o 1.3).
mTLS: per comunicazioni servizio-servizio interne e per accessi amministrativi sensibili.
Rotazione: automatizza rinnovo certificati e verifica la catena (OCSP/CRL) dove necessario.

Gestione delle chiavi 🗝️

Le chiavi di cifratura sono il vero tesoro: vanno generate, archiviate, ruotate e revocate con processi sicuri. Non lasciarle mai in chiaro o in posti accessibili a tutti.

KMS/HSM: usa servizi di gestione chiavi con HSM certificati per materiale critico.
Accesso: separa i ruoli tra key admin e data admin; applica dual-control per operazioni sensibili.
Lifecycle: definisci politiche di rotazione, dismissione sicura e tracciabilità delle key version.

Data Loss Prevention (DLP) 🛑

La Data Loss Prevention (o Data Leakage Prevention) è un insieme di strategie e strumenti progettati per impedire che dati sensibili escano dai confini dell’organizzazione in modo non autorizzato, sia per un errore umano che per un’azione malevola. La DLP non si concentra sulle minacce in ingresso, ma sul controllo dei dati in uscita.

Gli strumenti e le pratiche DLP agiscono come un guardiano intelligente:

Monitorano il traffico di rete, le email, i messaggi istantanei e i trasferimenti di file verso dispositivi USB o servizi di cloud storage.
Identificano i dati sensibili in base a regole, parole chiave o espressioni regolari (es. numeri di carte di credito, codici fiscali).
Bloccano i trasferimenti non autorizzati o applicano azioni correttive, come la cifratura automatica o la notifica a un responsabile della sicurezza.
Segnalano comportamenti anomali che potrebbero indicare un tentativo di esfiltrazione di dati.

Consiglio: implementa policy DLP graduali. Inizia in modalità di solo monitoraggio per capire come i dati si muovono e per ridurre i falsi positivi. Successivamente, attiva le regole di blocco per le categorie di dati più critiche. Esempi di policy includono: bloccare la condivisione esterna di documenti etichettati come “Riservato”, mascherare automaticamente gli IBAN nelle email in uscita, o generare un alert quando un utente tenta di caricare un intero database di clienti su un servizio di storage personale. La sensibilizzazione degli utenti sui rischi della condivisione impropria rimane una componente fondamentale di qualsiasi strategia DLP.

Network firewall e sicurezza perimetrale 🔥

Il firewall è il portiere del cloud: decide chi entra e chi esce. Un firewall ben configurato blocca la maggior parte degli attacchi più banali.

Funzionalità principali del firewall 🌐

Access control: definisce chi può comunicare con cosa
Intrusion prevention: blocca tentativi di attacco noti
Traffic monitoring: registra e analizza il traffico
Data privacy: protegge i dati in transito

Security group: il bodyguard delle risorse 🦾

Firewall virtuali che controllano il traffico in entrata e uscita. Essenziali per la sicurezza cloud. Definisci regole chiare e limita l’accesso solo alle porte e agli IP necessari.

Principi: deny by default, whitelist minimo necessario, separa ingress da egress.
Pratiche: usa security group per tier (web/app/db), limita SSH/RDP a bastion/SSM, preferisci private endpoints.
Visibilità: abilita flow logs per audit e tuning delle regole.

Regole inbound e outbound 🚦

Le regole inbound stabiliscono chi può accedere alle risorse. Le regole outbound controllano cosa può uscire. Rivedile regolarmente e chiudi tutto ciò che non serve.

Inbound: esponi solo porte necessarie (es. 443), filtra per CIDR o fonte (LB/WAF). Niente 0.0.0.0/0 su porte sensibili.
Outbound: limita egress verso Internet; usa NAT controllati, egress-only per IPv6, e policy basate su domini/servizi.
Change management: versiona le regole, valida in staging, automatizza il deploy con IaC e controlli.

Web Application Firewall (WAF) 🕸️

Il WAF protegge app e API dalle minacce più comuni (e da qualche utente troppo curioso). È fondamentale per chi espone servizi web su Internet.

Minacce esterne più comuni 🚨

DDoS: attacchi che mirano a saturare le risorse
Vulnerabilità applicative: SQL injection, XSS, ecc.
Bot: scraping, brute force, automazioni malevole

Caratteristiche chiave del WAF 🛡️

Filtri a regole personalizzabili
Protezione contro le OWASP Top 10
Mitigazione bot e DDoS
Monitoraggio in tempo reale e alert

Best practice WAF:

Modalità “monitor” iniziale per ridurre falsi positivi, poi enforcement graduale.
Integrazione con CI/CD per aggiornare le regole insieme alle release.
Rate limiting, geo/IP reputation, protezione API (schema validation, JWT checks).

Checklist operativa 🧰

IAM: MFA ovunque, SSO protetto, ruoli minimi, review trimestrale permessi.
Segreti: vault centralizzato, rotazione automatica, mai in repo, audit su accessi.
Dati: classificazione, segmentazione per ambiente/progetto, backup cifrati e testati.
Cifratura: TLS obbligatorio, cifratura a riposo gestita da KMS, rotazione chiavi.
Rete: security group restrittivi, egress controllato, bastion/zero-trust per admin.
WAF/DDoS: regole OWASP Top 10, rate limiting, protezione bot e CDN.
DLP: regole su email/storage, alert anomali, sensibilizzazione utenti.
Logging: centralizzazione log, retention definita, allarmi su eventi critici.

Risorse correlate 🔗

La sicurezza cloud non è mai “finita”. Va rivista, aggiornata e testata regolarmente. E ricordati: la miglior difesa è la consapevolezza di chi usa e gestisce il cloud.

Ultimo aggiornamento il 5 ottobre 2025

Crittografia 🔐