Vai al contenuto
Docs
Event-driven
Sicurezza

Sicurezza in EDA: chi può leggere cosa (e chi non dovrebbe) 🔐

La sicurezza nei sistemi event-driven è uno di quei topic che “aggiungiamo dopo” — finché non arriva una revisione GDPR, un audit di sicurezza o, peggio, un incident. Questa guida copre le scelte da fare prima, non dopo.

Il modello di minaccia in EDA 🎯

In un sistema event-driven, le superfici di attacco principali sono:

  • accesso non autorizzato al broker: un consumer non autorizzato legge eventi di altri team/domini;
  • pubblicazione non autorizzata: un producer pubblica eventi falsi o scrive su topic altrui;
  • payload esposto: eventi con PII in chiaro su log, storage o sistemi di monitoring;
  • tampering: modifica di eventi in transito o at rest;
  • data retention eccessiva: eventi con PII conservati ben oltre il necessario.

Autenticazione al broker 🔑

Il broker deve sapere chi sta parlando con lui prima di decidere cosa può fare.

mTLS (Mutual TLS)

Sia il client (producer/consumer) che il broker si autenticano con certificati X.509.

  • Pro: autenticazione bidirezionale, forte, senza credenziali applicative.
  • Contro: gestione PKI (certificate rotation, revocation) è operativamente costosa.
  • Quando: ambienti on-premise o multi-cloud con PKI già in uso.

SASL / SCRAM

Autenticazione a username/password con challenge-response. Kafka supporta SASL/PLAIN, SASL/SCRAM-SHA-256, SASL/SCRAM-SHA-512.

  • Pro: più semplice da gestire rispetto a mTLS.
  • Contro: le credenziali vanno ruotate e protette esplicitamente.
  • Quando: ambienti meno critici o team che non vogliono gestire PKI.

OAuth 2.0 / OIDC

I client ottengono un token JWT da un identity provider (Keycloak, Okta, AWS IAM Identity Center) e lo usano per autenticarsi al broker. Kafka supporta SASL/OAUTHBEARER.

  • Pro: integrazione con IAM aziendale centralizzato, scadenza automatica token.
  • Quando: ambienti enterprise con identity provider già in uso.

IAM cloud-native

Su AWS MSK, Kinesis, SNS/SQS, Azure Service Bus: il broker usa IAM policies native del cloud provider. Il client assume un role con i permessi necessari.

  • Pro: zero credenziali da gestire, audit trail nativo, rotation automatica.
  • Quando: ambienti cloud puri con architettura IAM-first.

Autorizzazione: chi può fare cosa su quali topic 🛡️ 

    flowchart LR
  C[Consumer A] -->|ACL: CONSUME ok| T1[(Topic: ordini)]
  C2[Consumer B] -->|ACL: DENIED| T1
  P[Producer X] -->|ACL: PRODUCE ok| T1
  P2[Producer Y] -->|ACL: DENIED| T1

ACL su Kafka

Kafka supporta ACL (Access Control List) per definire quali principal (utenti/client) possono eseguire quali operazioni su quali risorse (topic, consumer group, cluster).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# permetti a consumer-ordini di leggere dal topic ordini-creati
kafka-acls.sh --add \
  --allow-principal User:consumer-ordini \
  --operation Read \
  --topic ordini-creati

# permetti a producer-ordini di scrivere sul topic
kafka-acls.sh --add \
  --allow-principal User:producer-ordini \
  --operation Write \
  --topic ordini-creati

Principio del least privilege

Ogni servizio deve avere accesso solo ai topic che usa, solo con le operazioni che gli servono. Un consumer non deve avere diritti di produzione; un producer non deve potere fare operazioni amministrative.

Consiglio pratico: gestisci le ACL via IaC (Terraform, Ansible), assegnale per nome di servizio (non per persona) e revisionarle a ogni security review.

Cifratura in transit e at rest 🔒

In transit

TLS è obbligatorio fuori da reti completamente private. Configura:

  • TLS sui listener del broker esposti a client esterni;
  • certificate rotation automatica (Let’s Encrypt, Vault, cert-manager);
  • minimo TLS 1.2, prediligi TLS 1.3.

At rest

Dipende dal broker e dall’ambiente:

  • Kafka su cloud (MSK, Confluent Cloud): cifratura at rest gestita dal cloud provider (AES-256), abilitata di default.
  • Kafka self-hosted: dipende dalla configurazione del filesystem/storage del cluster — da configurare esplicitamente.
  • Dati molto sensibili: considera cifratura a livello applicativo del payload prima di pubblicare (envelope encryption con KMS), così i dati sono cifrati anche per chi ha accesso al broker.

PII negli eventi: il problema concreto 🧬

Gli eventi tendono ad “accumulare” dati sensibili nel tempo. Un evento UtenteRegistrato con email, nome e data di nascita sarà conservato nel log di Kafka per mesi o anni. Questo crea problemi di GDPR non banali.

Strategie per gestire la PII negli eventi

1. Minimizzazione del payload

Pubblica solo ciò che è strettamente necessario. Se il consumer ha bisogno dell’email, probabilmente dovrebbe fare una chiamata al servizio di profilo — non riceverla nell’evento di default.

2. Tokenizzazione / Pseudoanonimizzazione

Sostituisci il valore PII con un token opaco (UUID) che può essere risolto solo da chi ha accesso al servizio di lookup.

1
2
3
4

{
  "ordine_id": "ord-123",
  "cliente_ref": "tok-7f3a9c"
}

Il campo cliente_ref è un token — non la PII diretta. Solo i servizi autorizzati possono risolvere il token verso i dati reali.

3. Cifratura per-campo (crypto-shredding)

Cifra i campi PII nel payload con una chiave per utente gestita da KMS. Quando l’utente richiede la cancellazione (GDPR right to erasure), cancella la chiave nel KMS: i dati cifrati rimangono nel log ma diventano permanentemente illeggibili.

    flowchart LR
  EV[Evento con PII] -->|cifra campo con chiave utente| ENC[Evento con campo cifrato]
  ENC --> KAFKA[(Kafka / Event Store)]
  KMS[(KMS)] -->|chiave per user_id| ENC
  KMS -->|cancella chiave| DEL[Right to erasure - GDPR]

Questo è l’unico modo pratico per soddisfare il diritto all’oblio in un sistema Event Sourcing, dove gli eventi sono immutabili per design.

4. Separazione dei tier di dato

Distingui eventi di notifica (payload minimo, senza PII) da archivi di dati (con PII, retention policy e access control dedicati). Non tutti gli eventi devono portare tutto — spesso è una scelta di design, non un vincolo tecnico.

GDPR e retention degli eventi ⚖️

Kafka non è progettato per la cancellazione selettiva di messaggi. Le strategie pratiche per la compliance:

  • Retention policy: configura retention.ms o retention.bytes sui topic con PII (es. 30 giorni invece di “forever”).
  • Log compaction + tombstone: per topic compatti, un “delete tombstone” (messaggio con valore null per una chiave) rimuove il record con quella chiave; utile per dati per chiave utente.
  • Crypto-shredding (vedi sopra): elimina la chiave KMS invece del dato fisico.

Nessuna di queste è “gratis”: pianifica la retention nel design degli eventi, non come afterthought.

Audit trail 📋

In EDA, l’audit trail è spesso un effetto collaterale naturale con Event Sourcing. Anche senza ES, conviene loggare esplicitamente:

  • chi produce un evento (identity del producer, da autenticazione);
  • quando e da dove (timestamp + service mesh identity o IP sorgente);
  • cosa è stato modificato (per eventi di aggiornamento, almeno i campi sensibili coinvolti).

Strumenti:

  • AWS CloudTrail / CloudWatch per broker gestiti su AWS;
  • Kafka audit log per Confluent Platform Enterprise;
  • OpenTelemetry per tracing distribuito con identity propagata nel trace context.

Checklist sicurezza EDA ✅

  • Autenticazione: ogni client ha una propria identity (no credenziali condivise tra servizi).
  • Autorizzazione: ACL o policy IAM per topic, con principio del least privilege.
  • Cifratura in transit: TLS abilitato su tutti i listener esposti, con rotation automatica.
  • Cifratura at rest: verificata per lo storage tier del broker.
  • PII inventory: identificati tutti gli eventi che contengono PII — già nel design.
  • Retention policy: configurata per tutti i topic con PII prima del go-live.
  • Strategia right to erasure: crypto-shredding o tokenizzazione definiti per i dati GDPR-sensibili.
  • Audit trail: chi pubblica cosa è tracciato (identity + timestamp + topic).
  • Security review: schema degli eventi revisionato per minimizzazione del dato prima del deploy.

Prossimi passi 🚀

Ultimo aggiornamento il
TestingTool ed ecosistema