Triade CIA nella cybersecurity: riservatezza, integrità e disponibilità

Cosa succede quando un dato viene letto da una persona non autorizzata, alterato senza autorizzazione o non è disponibile proprio quando serve? Sono tre problemi diversi e richiedono controlli diversi. Per distinguerli possiamo usare uno dei modelli più semplici e utili della sicurezza informatica.

La triade CIA è il modello fondamentale della cybersecurity formato da tre principi: riservatezza, integrità e disponibilità. L'acronimo deriva dai termini inglesi Confidentiality, Integrity e Availability. Insieme aiutano a capire che cosa proteggere e quale rischio ridurre, dai documenti aziendali fino a un'infrastruttura cloud.

Perché la triade CIA è fondamentale

La triade CIA non è soltanto una definizione teorica. È un criterio pratico per analizzare un sistema, stabilire le priorità e scegliere controlli coerenti con il rischio.

Un servizio può essere sempre raggiungibile, ma non sicuro se permette a chiunque di leggere dati riservati. Un file può essere protetto da accessi esterni, ma diventare inutile se una modifica non autorizzata ne compromette il contenuto. Un backup può preservare una copia corretta dei dati, ma non garantisce da solo che il servizio continui a funzionare.

Per questo i tre principi della sicurezza informatica vanno considerati insieme. Vediamo cosa significano e come tradurli in scelte operative.

Riservatezza: proteggere dati e accessi

La riservatezza garantisce che dati, sistemi e risorse siano accessibili soltanto alle persone e ai servizi autorizzati. Non significa semplicemente nascondere un'informazione: significa controllare chi può leggerla, in quale contesto e per quanto tempo.

Le minacce più comuni includono:

• le violazioni di dati, nelle quali informazioni protette vengono esposte o sottratte;
• l'intercettazione del traffico mentre i dati attraversano la rete;
• l'ingegneria sociale, cioè la manipolazione di una persona per ottenere credenziali o informazioni;
• permessi eccessivi o controlli di accesso configurati male.

La crittografia protegge il contenuto rendendolo illeggibile senza la chiave corretta, sia durante il trasferimento sia quando è archiviato. Da sola, però, non basta. Se un account dispone di privilegi più ampi del necessario o una chiave viene esposta, il dato può comunque essere letto.

Il principio del minimo privilegio assegna a ogni utente o processo soltanto gli accessi indispensabili per svolgere il proprio compito. Su un sistema Linux, per esempio, un file .env contenente configurazioni sensibili può essere limitato al proprietario:

chmod 600 .env

Il valore 600 concede lettura e scrittura al proprietario del file e nessun permesso al gruppo e agli altri utenti. È una protezione utile, purché siano corretti anche il proprietario del file, gli account presenti sul sistema e le autorizzazioni del processo che lo utilizza.

Anche password, token e chiavi non dovrebbero essere scritti direttamente nel codice. Un secret manager è un sistema centralizzato che conserva i segreti, ne controlla l'accesso e può facilitarne rotazione e tracciamento. HashiCorp Vault è un esempio di questo tipo di strumento:

# Da evitare
database_password="password-in-chiaro"

# Il secret manager valorizza la variabile a runtime
database_password="${DATABASE_PASSWORD}"

Nel secondo esempio l'applicazione legge una variabile valorizzata a runtime dall'integrazione con il secret manager. La modalità esatta dipende dallo strumento utilizzato. Il punto è evitare che il valore del segreto finisca nel repository, nell'immagine del container o in un file condiviso senza adeguate protezioni.

Integrità: impedire modifiche non autorizzate

L'integrità assicura che dati e informazioni rimangano accurati, completi e affidabili durante tutto il loro ciclo di vita. Una modifica deve essere autorizzata, tracciabile e coerente con il processo previsto.

L'integrità può essere compromessa da un attaccante, ma anche da errori accidentali, malware, configurazioni errate o attacchi man-in-the-middle. In quest'ultimo caso, un soggetto si inserisce nella comunicazione tra due parti e può intercettare o alterare i dati scambiati.

Un primo controllo consiste nel calcolare un checksum, cioè un'impronta derivata dal contenuto di un file. Con SHA-256 possiamo salvare il valore atteso e verificare in seguito se il file è cambiato:

sha256sum release.tar.gz > checksum.txt
sha256sum -c checksum.txt

Il checksum rileva una variazione rispetto al valore atteso, ma non dimostra da solo chi abbia prodotto quel valore. Se un attaccante potesse sostituire sia l'archivio sia checksum.txt, potrebbe generare una coppia coerente ma malevola.

Una firma digitale aggiunge la verifica della provenienza collegata alla chiave del firmatario. Con GPG, un'implementazione dello standard OpenPGP, possiamo firmare un artefatto e controllarne la firma:

gpg --armor --detach-sign release.tar.gz
gpg --verify release.tar.gz.asc release.tar.gz

Il checksum e la firma digitale, quindi, non sono equivalenti: il primo serve a confrontare il contenuto con un'impronta attesa; la seconda permette anche di verificare che la firma sia stata generata con una determinata chiave privata. La verifica è affidabile solo se la chiave pubblica è stata associata correttamente al firmatario e la chiave privata è protetta.

Lo stesso principio può essere applicato ai commit Git:

git config --global commit.gpgsign true
git config --global user.signingkey YOUR_GPG_KEY_ID
git commit -S -m "Add new feature"
git log --show-signature

La firma non impedisce il furto delle credenziali e non certifica che il codice sia privo di vulnerabilità. Permette però di verificare che il commit sia associato a una chiave attesa. La fiducia dipende anche dalla custodia della chiave privata e dalla procedura usata per validare le chiavi del team.

In una pipeline CI/CD, checksum, firme, revisioni e log delle modifiche aumentano la tracciabilità degli artefatti dal codice al rilascio. È un tema centrale nella difesa proattiva della supply chain software.

Disponibilità: mantenere operativi sistemi e dati

La disponibilità garantisce che sistemi, servizi e informazioni siano accessibili agli utenti autorizzati quando ne hanno bisogno. Non coincide con il semplice fatto che un server sia acceso: comprende la capacità dell'intero servizio di resistere ai guasti e di essere ripristinato entro tempi accettabili.

Un attacco DDoS, cioè un sovraccarico distribuito di richieste, può rendere un servizio irraggiungibile. Lo stesso risultato può derivare da un guasto hardware, un bug applicativo, un errore operativo o un ransomware che cifra dati e sistemi.

Ridondanza e failover riducono la dipendenza da una singola risorsa. La ridondanza rende disponibili più istanze o componenti; il failover trasferisce il servizio verso una risorsa funzionante quando quella principale non è più utilizzabile. Per essere efficaci, devono evitare i single point of failure, ossia componenti il cui guasto può interrompere l'intero servizio.

In Kubernetes, un Deployment può eseguire più repliche e usare controlli di stato chiamati probe:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
        - name: web
          image: myapp:1.0.0
          ports:
            - containerPort: 8080
          livenessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 5
            failureThreshold: 3
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 3

replicas: 3 è un esempio, non un minimo universale: il numero corretto dipende da carico, requisiti di continuità, capacità dei nodi e architettura. La liveness probe verifica se il container continua a funzionare e, dopo errori ripetuti, può portare al suo riavvio. La readiness probe stabilisce invece se il Pod è pronto a ricevere traffico; se fallisce, Kubernetes lo esclude temporaneamente dagli endpoint del servizio.

Le repliche migliorano la continuità, ma non sostituiscono un backup. Se un errore cancella un dato o un ransomware lo cifra, la modifica può propagarsi a tutte le copie attive. La regola 3-2-1 prevede almeno tre copie dei dati, su due supporti differenti, con una copia conservata fuori sede. È essenziale anche eseguire prove di ripristino: un backup mai verificato offre una garanzia soltanto teorica. Un esempio operativo è descritto nell'articolo sull'automazione dei backup su Proxmox.

Come bilanciare i tre principi della triade CIA

I tre pilastri non hanno sempre la stessa priorità. Un archivio sanitario richiede controlli molto severi sulla riservatezza e sull'integrità; un servizio di emergenza deve prestare particolare attenzione anche alla disponibilità. La scelta dei controlli deve quindi partire dal contesto e da quattro domande:

1. Quali dati proteggiamo? Occorre identificarne sensibilità, valore e ciclo di vita.
2. Quali sono le conseguenze di una violazione? Bisogna valutare l'impatto operativo, economico, legale e reputazionale.
3. Chi necessita realmente dell'accesso? La risposta permette di applicare il minimo privilegio senza bloccare il lavoro.
4. Qual è il tempo di inattività accettabile? Questo requisito orienta ridondanza, monitoraggio e strategia di ripristino.

Un controllo può rafforzare un pilastro e incidere sugli altri. Una procedura di autenticazione molto rigida può aumentare la riservatezza, ma rendere più lento l'accesso durante un'emergenza. Replicare un servizio in più ambienti può migliorarne la disponibilità, ma amplia il numero di sistemi sui quali proteggere accessi e coerenza dei dati.

L'obiettivo non è massimizzare ogni principio in astratto. È trovare un equilibrio sostenibile sulla base dei rischi e dei requisiti reali.

Checklist pratica per applicare la triade CIA

Queste domande aiutano a trasformare il modello in una prima verifica operativa. Per un controllo più ampio puoi consultare i 7 controlli di sicurezza essenziali per una PMI e approfondire i rischi informatici che possono bloccare una PMI.

Riservatezza

• Gli accessi seguono il principio del minimo privilegio?
• Password, token e chiavi sono conservati fuori dal codice?
• I dati sensibili sono protetti durante il trasferimento e l'archiviazione?

Integrità

• File e artefatti critici vengono verificati con hash o firme?
• Le modifiche al codice e alle configurazioni sono tracciate e attribuibili?
• Le chiavi di firma sono protette e la loro provenienza viene verificata?

Disponibilità

• Esistono single point of failure nei servizi critici?
• I backup vengono ripristinati periodicamente in un test controllato?
• Monitoraggio, failover e procedure di ripristino rispettano il tempo di inattività accettabile?

Conclusione

La triade CIA offre un metodo semplice per leggere problemi di sicurezza molto diversi. La riservatezza limita l'accesso, l'integrità protegge accuratezza e affidabilità delle informazioni, mentre la disponibilità mantiene dati e servizi utilizzabili quando servono.

Nessuno dei tre principi può essere progettato in isolamento. Accessi, firme, repliche e backup diventano davvero efficaci quando fanno parte di una valutazione coerente del rischio e vengono verificati nel tempo.

Per una consulenza o una verifica della tua situazione:

Contattami qui