Wie man die Einhaltung von Vorgaben für Apache Cassandra sicherstellt

Einführung

Apache Cassandra ist eine verteilte NoSQL-Datenbank, die für ihre Skalierbarkeit und hohe Verfügbarkeit bekannt ist. Organisationen verlassen sich zunehmend auf Cassandra, um sensible Arbeitslasten – wie Finanztransaktionen, Gesundheitsdaten und persönliche Kennungen – zu speichern, die strengen Vorschriften wie GDPR, HIPAA und PCI DSS unterliegen.

Die Sicherstellung der Einhaltung von Vorgaben in Cassandra umfasst die Protokollierung, Zugangskontrolle, Verschlüsselung und Maskierung. Dieser Leitfaden untersucht die nativen Compliance-Funktionen von Cassandra und zeigt, wie DataSunrise diese durch Automatisierung und zentralisierte Steuerung verbessert.

Einhaltung von Vorgaben für Apache Cassandra mit nativen Funktionen

Schritt 1: Audit-Logging aktivieren

Cassandra enthält Audit-Logging, um die Datenbankaktivität zu verfolgen. Aktivieren Sie es in cassandra.yaml:

audit_logging_options:
    enabled: true                              # Standard: false
    logger:
      - class_name: BinAuditLogger             # Logger im Binärformat
    audit_logs_dir: /var/log/cassandra/audit   # Erforderlich: Verzeichnis für Logs angeben
    included_categories: DML, DDL, AUTH        # Zu protokollierende Kategorien
    excluded_keyspaces: system, system_schema  # System-Keyspaces ausschließen
    roll_cycle: HOURLY                         # Häufigkeit der Log-Rotation
    block: true                                # Blockieren, falls Queue voll wird (sichert den vollständigen Audit-Verlauf)
    max_log_size: 17179869184                  # 16 GiB pro Log-Datei

Wichtige Parameter:

• audit_logs_dir: Muss angegeben werden, wenn Audit-Logging aktiviert wird
• included_categories: Auswahlmöglichkeiten: QUERY, DML, DDL, DCL, AUTH, ERROR, PREPARE
• block: Auf true setzen für strikte Einhaltung (niemals Audit-Ereignisse verlieren)

Dies stellt Audit-Trails für die Einhaltung bereit, jedoch verbleiben die Logs knotenlokal und müssen in Clustern manuell aggregiert werden.

Schritt 2: Erfassung von Abfrageaktivitäten

Verwenden Sie Full Query Logging (FQL) für Untersuchungen. Beachten Sie, dass FQL standardmäßig deaktiviert ist und konfiguriert werden muss:

full_query_logging_options:
    log_dir: /var/log/cassandra/fql     # Erforderlich: Verzeichnis für Logs angeben
    roll_cycle: HOURLY                  # Häufigkeit der Log-Rotation
    block: true                         # Blockieren, falls Queue voll wird
    max_queue_weight: 268435456         # 256 MiB Queue-Gewicht
    max_log_size: 17179869184           # 16 GiB pro Log-Datei

Aktivieren Sie FQL dynamisch über nodetool:

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

Wiedergeben der erfassten Abfragen zur Analyse:

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

Hinweis: FQL erfasst nur erfolgreiche Abfragen, wodurch blinde Flecken bei fehlgeschlagenen Authentifizierungsversuchen oder unautorisierten Zugriffsversuchen entstehen – was für das Compliance-Monitoring kritisch ist.

Schritt 3: Durchsetzen der rollenbasierten Zugriffskontrolle

Cassandra unterstützt RBAC zur Zugriffsbeschränkung:

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

GRANT SELECT ON KEYSPACE finance_data TO compliance_auditor;

Dies erzwingt eine grundlegende rollenbasierte Zugriffskontrolle (RBAC). Allerdings fehlen in RBAC kontextsensitive Richtlinien und bedingte Maskierung.

Schritt 4: Schutz der Daten durch Maskierung (Cassandra 5.0+)

Cassandra 5.0 führt Dynamic Data Masking (DDM) ein.

Beispielhafte Implementierung:

-- Erstellen Sie zunächst ein Keyspace (falls nicht vorhanden)
CREATE KEYSPACE IF NOT EXISTS healthcare
WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 1};

USE healthcare;

-- Erstellen Sie eine Tabelle mit maskierten Spalten
CREATE TABLE patients (
   id UUID PRIMARY KEY,
   name TEXT MASKED WITH mask_inner(1, null),
   birth DATE MASKED WITH mask_default()
);

Unberechtigte Benutzer sehen maskierte Werte, während privilegierte Benutzer mit UNMASK-Berechtigung die unmaskierten Daten einsehen können.

Einschränkung: Frühere Cassandra-Versionen unterstützen keine Maskierung; für die Einhaltung der Vorgaben waren Workarounds auf Anwendungsebene erforderlich.

Schritt 5: Verschlüsseln Sie Daten im Ruhezustand und während der Übertragung

Im Ruhezustand

Cassandra bietet keine native Verschlüsselung im Ruhezustand. Verwenden Sie Dateisystem- oder Festplattenverschlüsselung (LUKS, dm-crypt oder Verschlüsselung durch den Cloud-Anbieter).

Während der Übertragung

Konfigurieren Sie sowohl die Verschlüsselung von Client zu Node als auch von Node zu Node in cassandra.yaml:

Client-zu-Node-Verschlüsselung (Anwendungen zu Cassandra):

client_encryption_options:
    enabled: true                        # Verschlüsselung aktivieren
    optional: false                      # Unverschlüsselte Verbindungen ablehnen
    keystore: conf/.keystore            # Speicherort des Serverzertifikats
    keystore_password: cassandra        # Keystore-Passwort
    require_client_auth: false          # Auf true setzen für gegenseitiges TLS
    # If require_client_auth is true:
    # truststore: conf/.truststore
    # truststore_password: cassandra

Verschlüsselung zwischen Knoten (innerhalb des Clusters):

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

Verschlüsselungsstufen für internode_encryption:

• none: Keine Verschlüsselung (Standard)
• dc: Verschlüsselt nur Verkehr zwischen Rechenzentren
• rack: Verschlüsselt Verkehr zwischen Racks
• all: Verschlüsselt alle Kommunikation zwischen Knoten (empfohlen für die Einhaltung von Vorgaben)

Verschlüsselung ist essenziell für die Einhaltung von GDPR und HIPAA.

Native Cassandra-Compliance: Wichtige Überlegungen

Dieser Ansatz erfordert tiefgehendes Cassandra-Fachwissen und wird zunehmend komplex, wenn die Einhaltung von Vorgaben über mehrere Datenbanktypen hinweg (MySQL, PostgreSQL, MongoDB etc.) verwaltet werden muss. Jedes System verwendet unterschiedliche Konfigurationsdateien, Audit-Formate und Verwaltungsbefehle – was potenziell zu betrieblichen Herausforderungen und inkonsistenten Richtlinien führt.

Wie DataSunrise die Einhaltung von Vorgaben bei Cassandra vereinfacht

Während bei nativem Cassandra eine manuelle Konfiguration auf jedem Knoten und ständige Neustarts erforderlich sind, bietet DataSunrise einen einzigen Steuerungspunkt für alle Compliance-Anforderungen – ohne die cassandra.yaml zu ändern oder Cluster neu zu starten.

Konfigurationsfreie Compliance

Problem bei nativem Cassandra: Jede Compliance-Funktion erfordert das Bearbeiten von YAML-Dateien, das Schreiben von CQL-Skripten und Cluster-Neustarts. Selbst das Aktivieren der Basis-Authentifizierung kann die Rollenverwaltung beeinträchtigen, wenn sie nicht perfekt konfiguriert ist.

DataSunrise-Lösung: Einmal bereitstellen und über eine Web-Oberfläche konfigurieren. Kein YAML-Bearbeiten, kein CQL-Scripting, keine Neustarts. DataSunrise fungiert als transparenter Proxy – Ihre Anwendungen merken nicht einmal, dass es da ist.

Einheitliche Multi-Datenbank-Governance

Problem bei nativem Cassandra: Die Verwaltung der Compliance über Cassandra, MySQL, PostgreSQL und MongoDB hinweg bedeutet, vier verschiedene Konfigurationssyntaxen, Audit-Formate und Verwaltungstools erlernen zu müssen.

DataSunrise-Lösung: Eine einzige Oberfläche steuert die Compliance für über 40 Datenbanktypen. Legen Sie eine Richtlinie einmal fest, und sie wird überall angewendet. Ihre Cassandra-Audit-Logs sehen identisch aus wie Ihre PostgreSQL-Logs – dasselbe Format, dasselbe Dashboard, dieselben Berichte.

Cassandra vs. DataSunrise: Governance und Compliance

Automatisierte Compliance ohne manuelle Berichte

Nativer Ansatz: Logs manuell aggregieren, benutzerdefinierte Parser schreiben, Berichte erstellen und darauf hoffen, dass Auditoren Ihr Format akzeptieren.

DataSunrise-Ansatz: Klicken Sie auf “Bericht erstellen” → Wählen Sie die Vorschrift (GDPR, HIPAA, PCI DSS, SOX) → Laden Sie prüfungsfertige Dokumentation herunter. Der Compliance Manager weiß genau, was jede Vorschrift erfordert, und formatiert Berichte entsprechend.

Geschäftliche Auswirkungen

Die Einführung von DataSunrise für die Einhaltung von Vorgaben bei Cassandra bringt folgende Vorteile:

• Reduziertes Risiko – Automatisierte Durchsetzung verhindert Fehlkonfigurationen.
• Betriebseffizienz – Eliminierung manueller Log-Prüfungen.
• Prüfungsvorbereitung – Immer vorbereitet mit exportierbaren Compliance-Berichten.
• Plattformübergreifende Abdeckung – Unterstützung von über 40 DBMS neben Cassandra.

Fazit

Native Compliance-Tools von Cassandra – Audit-Logs, RBAC und das neue DDM – bieten einen Ausgangspunkt, bleiben aber fragmentiert. Für Organisationen, die sich fragen, wie sie die Einhaltung von Vorgaben für Apache Cassandra sicherstellen können, liegt die Antwort in der Automatisierung.

DataSunrise vereint Überwachung, Maskierung, Erkennung und Berichterstattung und verwandelt Cassandra in eine konforme, prüfungsbereite Plattform.