Come Garantire la Conformità per Apache Cassandra

Introduzione

Apache Cassandra è un database NoSQL distribuito noto per la scalabilità e l’alta disponibilità. Le organizzazioni si affidano sempre più a Cassandra per archiviare carichi di lavoro sensibili — come transazioni finanziarie, dati sanitari e identificatori personali — che rientrano in regolamentazioni rigorose come GDPR, HIPAA e PCI DSS.

Garantire la conformità in Cassandra implica auditing, controllo accessi, crittografia e mascheramento. Questa guida esplora le funzionalità native di conformità di Cassandra e dimostra come DataSunrise le potenzia attraverso automazione e governance centralizzata.

Conformità per Apache Cassandra con Funzionalità Native

Passo 1: Abilitare l’Audit Logging

Cassandra include l’Audit Logging per tracciare l’attività del database. Abilitalo nel file cassandra.yaml:

audit_logging_options:
    enabled: true                              # Default: false
    logger:
      - class_name: BinAuditLogger             # Logger in formato binario
    audit_logs_dir: /var/log/cassandra/audit   # Obbligatorio: specificare la directory dei log
    included_categories: DML, DDL, AUTH        # Categorie da auditare
    excluded_keyspaces: system, system_schema  # Escludi keyspace di sistema
    roll_cycle: HOURLY                         # Frequenza di rotazione dei log
    block: true                                # Blocca se la coda si riempie (garantisce nessuna perdita di audit)
    max_log_size: 17179869184                  # 16 GiB per file di log

Parametri chiave:

• audit_logs_dir: deve essere specificato quando si abilita l’audit logging
• included_categories: scegli tra QUERY, DML, DDL, DCL, AUTH, ERROR, PREPARE
• block: impostare su true per una conformità rigorosa (per non perdere eventi di audit)

Questo fornisce audit trail per la conformità ma i log rimangono locali al nodo e devono essere aggregati manualmente nei cluster.

Passo 2: Catturare l’Attività delle Query

Usa il Full Query Logging (FQL) per le indagini. Nota che FQL è disabilitato di default e deve essere configurato:

full_query_logging_options:
    log_dir: /var/log/cassandra/fql     # Obbligatorio: specificare la directory dei log
    roll_cycle: HOURLY                  # Frequenza di rotazione dei log
    block: true                         # Blocca se la coda si riempie
    max_queue_weight: 268435456         # Peso massimo della coda: 256 MiB
    max_log_size: 17179869184           # 16 GiB per file di log

Abilita FQL dinamicamente tramite nodetool:

$ nodetool enablefullquerylog --path /var/log/cassandra/fql

Riproduci le query catturate per l’analisi:

$ bin/fqltool replay --target localhost:9042 /var/log/cassandra/fql

Nota: FQL cattura solo le query riuscite, creando punti ciechi per tentativi di autenticazione falliti o accessi non autorizzati — critici per il monitoraggio della conformità.

Passo 3: Applicare il Controllo Accessi Basato su Ruoli

Cassandra supporta il RBAC per limitare l’accesso:

CREATE ROLE compliance_auditor
WITH LOGIN = true
AND PASSWORD = 'StrongPass#2025'
AND SUPERUSER = false;

GRANT SELECT ON KEYSPACE finance_data TO compliance_auditor;

Questo impone un controllo accessi di base basato sui ruoli (RBAC). Tuttavia, RBAC manca di politiche contestuali e mascheramento condizionale.

Passo 4: Proteggere i Dati con il Mascheramento (Cassandra 5.0+)

Cassandra 5.0 introduce il Dynamic Data Masking (DDM).

Esempio di implementazione:

-- Crea un keyspace se non esiste
CREATE KEYSPACE IF NOT EXISTS healthcare
WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 1};

USE healthcare;

-- Crea una tabella con colonne mascherate
CREATE TABLE patients (
   id UUID PRIMARY KEY,
   name TEXT MASKED WITH mask_inner(1, null),
   birth DATE MASKED WITH mask_default()
);

Gli utenti non privilegiati vedono i valori mascherati, mentre gli utenti privilegiati con permesso UNMASK possono visualizzare i dati in chiaro.

Nota: Le versioni precedenti di Cassandra non supportano il mascheramento; la conformità richiedeva soluzioni alternative lato applicazione.

Passo 5: Crittografare i Dati a Riposo e in Transito

A Riposo

Cassandra non fornisce crittografia nativa a riposo. Usa la crittografia a livello di file system o disco (LUKS, dm-crypt o crittografia del provider cloud).

In Transito

Configura sia la crittografia client-to-node che node-to-node nel file cassandra.yaml:

Crittografia client-to-node (dalle applicazioni a Cassandra):

client_encryption_options:
    enabled: true                        # Abilita la crittografia
    optional: false                      # Rifiuta connessioni non crittografate
    keystore: conf/.keystore            # Posizione del certificato server
    keystore_password: cassandra        # Password del keystore
    require_client_auth: false          # Imposta true per TLS reciproco
    # Se require_client_auth è true:
    # truststore: conf/.truststore
    # truststore_password: cassandra

Crittografia node-to-node (tra nodi del cluster):

server_encryption_options:
    internode_encryption: all            # Opzioni: none, dc, rack, all
    keystore: conf/.keystore
    keystore_password: cassandra
    truststore: conf/.truststore
    truststore_password: cassandra

Livelli di crittografia per internode_encryption:

• none: Nessuna crittografia (default)
• dc: Crittografa solo il traffico cross-datacenter
• rack: Crittografa il traffico cross-rack
• all: Crittografa tutta la comunicazione inter-node (raccomandato per conformità)

La crittografia è essenziale per la conformità a GDPR e HIPAA.

Conformità Nativa di Cassandra: Considerazioni Chiave

Questo approccio richiede una significativa esperienza con Cassandra e diventa sempre più complesso gestire la conformità su più tipi di database (MySQL, PostgreSQL, MongoDB, ecc.). Ogni sistema usa file di configurazione, formati di audit e comandi amministrativi differenti — potenzialmente creando sfide operative e politiche incoerenti.

Come DataSunrise Semplifica la Conformità per Cassandra

Dove Cassandra nativa richiede configurazioni manuali su ogni nodo e riavvii continui, DataSunrise fornisce un punto unico di controllo per tutte le esigenze di conformità — senza modificare cassandra.yaml o riavviare cluster.

Conformità Zero-Configurazione

Problema con Cassandra nativo: Ogni funzionalità di conformità richiede modifiche YAML, script CQL e riavvii del cluster. Anche abilitare l’autenticazione base può rompere la gestione dei ruoli se non configurata perfettamente.

Soluzione DataSunrise: Deploy una volta, configura tramite interfaccia web. Niente editing YAML, nessuno scripting CQL, nessun riavvio. DataSunrise agisce come proxy trasparente — le tue applicazioni nemmeno sanno che è lì.

Governance Unificata Multi-Database

Problema con Cassandra nativo: Gestire la conformità tra Cassandra, MySQL, PostgreSQL e MongoDB significa apprendere quattro sintassi di configurazione, formati di audit e strumenti amministrativi diversi.

Soluzione DataSunrise: Un’interfaccia controlla la conformità per oltre 40 tipi di database. Imposta una policy una volta, applicala ovunque. I tuoi log di audit Cassandra appaiono identici a quelli PostgreSQL — stesso formato, stesso dashboard, stessi report.

Cassandra vs. DataSunrise: Governance e Conformità

Conformità Automatica Senza Report Manuali

Approccio Nativo: Aggrega manualmente i log, scrivi parser custom, crea report e spera che gli auditor accettino il formato.

Approccio DataSunrise: Clicca “Genera Report” → Scegli la regolamentazione (GDPR, HIPAA, PCI DSS, SOX) → Scarica la documentazione pronta per l’auditor. Il Compliance Manager conosce esattamente cosa richiede ogni regolamentazione e formatta i report di conseguenza.

Impatto sul Business

L’adozione di DataSunrise per la conformità in Cassandra offre:

• Riduzione del Rischio – Applicazione automatica previene errori di configurazione.
• Efficienza Operativa – Elimina revisioni manuali dei log.
• Prontezza per Audit – Sempre preparati con report di conformità esportabili.
• Copertura Multi-Piattaforma – Supporta oltre 40 DBMS oltre Cassandra.

Conclusioni

Gli strumenti di conformità nativi di Cassandra — audit log, RBAC e nuovo DDM — offrono un punto di partenza ma rimangono frammentati. Per le organizzazioni che si chiedono come garantire la conformità per Apache Cassandra, la risposta è l’automazione.

DataSunrise unifica monitoraggio, mascheramento, scoperta e reporting, trasformando Cassandra in una piattaforma conforme e pronta per l’audit.