Projekt anfragen
Hand hält einen Schlüssel mit angehängtem USB-Stick, Nahaufnahme als Sinnbild für Schlüsselverwaltung

Schlüssel, Zugriffe, Protokolle

Datensicherheit in Cloud- und Datenplattformen

Wir entwerfen und setzen den technischen Schutz Ihrer Daten um: Schlüsselverwaltung, Verschlüsselung, Zugriffe bis auf Zeilenebene, Maskierung, Abflusskontrollen und manipulationsgeschützte Audit-Logs. Für IT-Leitung, CTO und Datenverantwortliche.

Projekt anfragen Schutzbedarfs-Matrix ansehen
  • Abstufung nach Datenklasse statt alles auf Maximum
  • Schlüsselmaterial bleibt in Ihrer Hoheit

Autor: Ibrahim Yesilay, Gründer und Geschäftsführer Stand:

01Typische Ausgangslage

Wo der Datenschutz-Unterbau in der Praxis Lücken hat

Datensicherheit heißt hier technische und organisatorische Schutzmaßnahmen an Systemen. Rechtliche Bewertungen übernimmt Ihr Datenschutzbeauftragter; wir arbeiten ihm zu.

  • Schlüssel ohne Besitzer

    „Verschlüsselt“ steht im Konzept, aber niemand kann sagen, wer die Schlüssel verwaltet, wie sie rotiert werden und was bei Verlust passiert.

  • Alle sehen alles

    Anwendungen, Analysten und Dienstleister nutzen dieselbe Datenbank, weil Zugriffsmodelle über Jahre gewachsen sind.

  • Produktivdaten im Testsystem

    Ohne Maskierung landen echte Daten in Test- und Analyseumgebungen.

  • Protokolle, die niemand liest

    Es gibt Logs, aber sie sind weder vollständig noch manipulationsgeschützt, und niemand wertet sie aus.

  • Migration gefährdet den Schutz

    Eine Plattformmigration steht an: Wie bleiben Schutz und Schlüsselhoheit erhalten? Siehe Datenbankmigration und Cloud Security.

02Schutzbedarfs-Matrix

Welche Datenklasse bekommt welchen Schutz

Die Matrix ist unser Ausgangspunkt für den Maßnahmenkatalog. Die Datenklassen sind Beispiele; Ihre Einstufung ersetzt sie. „Standard“ heißt: wird für die Klasse grundsätzlich umgesetzt, „bei Bedarf“: wird nach Risiko und Aufwand entschieden.

Schutzmaßnahmen je Datenklasse: Verschlüsselung, Schlüsselhoheit, Zugriff, Maskierung, Audit-Log
Datenklasse (Beispiel)Verschlüsselung ruhendSchlüsselhoheitZugriffMaskierung in Nicht-ProduktionAudit-Log
Öffentlich (Produktdaten, Website-Inhalte)Plattform-StandardAnbieter-KMS genügtLesen breit, Schreiben nach Rollenicht nötigÄnderungen
Intern (Betriebsdaten, interne Dokumente)Standard auf Volume- und DatenbankebeneAnbieter-KMS mit getrennten ZuständigkeitenRollenmodell nach Least Privilegebei BedarfZugriffe auf Administratorebene
Vertraulich (Kundendaten, Verträge, personenbezogene Daten)Standard, zusätzlich Feldverschlüsselung bei bestimmten FeldernKundengehaltene oder getrennt verwaltete Schlüssel (KMS mit Kunden-Schlüsselverwaltung oder OpenBao)Row-Level-Security, getrennte Datenbankrollen, privilegierter Zugriff nur befristetStandard (maskiert oder synthetisch)Lese- und Schreibzugriffe, Export-Vorgänge
Streng vertraulich (Gesundheits-, Finanz-, Zugangsdaten, Schlüsselmaterial)Standard, Anwendungs- oder Feldverschlüsselung, Hardware-gestützter Schutz wo verfügbarEigene Schlüsselhierarchie mit Vier-Augen-Prinzip für SchlüsselzugriffJe Zweck freigegeben, kein Dauerzugriff für MenschenStandard, keine Produktivdaten außerhalb ProduktionVollständig, manipulationsgeschützt, Alarmierung

Welche Kombination für Ihre Daten gilt, ergibt sich aus Schutzbedarf, Rechtsgrundlagen und Betriebsmodell. Der technisch sinnvolle Weg ist selten „alles auf höchster Stufe“, sondern die Abstufung nach Datenklasse.

03Schlüsselkonzept

Schlüssel rotieren, ohne alle Daten neu zu schreiben

Daten werden mit Datenschlüsseln verschlüsselt, diese mit übergeordneten Schlüsseln, deren Zugriff getrennt geregelt und protokolliert wird. So lässt sich ein Schlüssel rotieren, ohne alle Daten neu zu schreiben, und der Zugriff auf Schlüssel bleibt vom Zugriff auf Daten getrennt.

Schlüsselhierarchie mit Trennung der Zuständigkeiten Dreistufige Schlüsselhierarchie: Wurzelschlüssel, Schlüsselverschlüsselungsschlüssel, Datenschlüssel; seitlich Audit-Log und Rotations- und Notfallverfahren. Schlüsselhierarchie mit Trennung der Zuständigkeiten 1 · WURZELSCHLÜSSEL2 · SCHLÜSSELVERSCHLÜSSELUNGSSCHLÜSSEL3 · DATENSCHLÜSSEL Im KMS oder in OpenBaoJe Mandant oder DatenklasseJe Datenbank, Volume oder Objekt Nie exportierbar, Vier-Augen-PrinzipRotierbarKurzlebig, vom Mittelschlüssel verschlüsselt verschlüsseltverschlüsselt Audit-LogRotations- undNotfallverfahren jedes Schlüsselzugriffsmanipulationsgeschütztfür alle drei Stufen
Schlüsselhierarchie mit Trennung der Zuständigkeiten
Schlüsselhierarchie mit Trennung der Zuständigkeiten Dreistufige Schlüsselhierarchie: Wurzelschlüssel, Schlüsselverschlüsselungsschlüssel, Datenschlüssel; darunter Audit-Log und Rotations- und Notfallverfahren. Schlüsselhierarchie mitTrennung der Zuständigkeiten 1 · WURZELSCHLÜSSEL2 · SCHLÜSSELVERSCHLÜSSELUNGS-SCHLÜSSEL3 · DATENSCHLÜSSEL Im KMS oder in OpenBaoJe Mandant oder DatenklasseJe Datenbank, Volume oder Objekt Nie exportierbar, Vier-Augen-PrinzipRotierbarKurzlebig, vom Mittelschlüsselverschlüsselt verschlüsseltverschlüsselt Audit-LogRotations- undNotfallverfahren jedes Schlüsselzugriffsmanipulationsgeschütztfür alle drei Stufen
Schlüsselhierarchie mit Trennung der Zuständigkeiten

04Schlüsselhoheit

Anbieter-KMS oder eigene OpenBao-Instanz

Technische Basis ist das KMS Ihres Cloud-Anbieters oder ein selbst betriebenes Secrets-Management wie OpenBao, je nach Souveränitätsanforderung.

OpenBao stellt laut Dokumentation unter anderem eine Transit-Engine (Verschlüsselung als Dienst), eine PKI-Engine für Zertifikate und Engines für dynamische Zugangsdaten bereit.

  • Wer hält welche Schlüssel, wo, mit welcher Rotation
  • Notfallverfahren für den Schlüsselverlust
  • Vier-Augen-Prinzip bei streng vertraulichen Daten
Glasfaser-Steckverbinder mit Beschriftung an einem Netzwerk-Switch, Detailaufnahme im Serverschrank

05Vorgehen im Projekt

Von der Datenklasse bis zum Restore-Test

Acht Bausteine, die wir nach Ihrem Schutzbedarf zusammenstellen.

  1. 01

    Datenklassifikation und Datenfluss

    Grundlage

    Gemeinsam bilden wir Datenklassen und Datenwege ab: Entstehung, Speicherung, Verarbeitung, Weitergabe, Löschung. Daraus folgt, welche Maßnahme für welche Daten angemessen ist. Die fachliche Einstufung liefern Sie.

  2. 02

    Schlüsselkonzept

    Aus der Datenklasse folgt die Hierarchie: welche Schlüsselebenen es gibt, wer sie verwaltet und was bei Verlust oder Verdacht auf Kompromittierung passiert.

  3. 03

    Verschlüsselung

    Ruhende Daten, Übertragung (TLS) und Backups; wo nötig auf Feld- oder Anwendungsebene.

  4. 04

    Zugriff

    Rollenmodell, Datenbankrollen, Row-Level-Security in PostgreSQL, getrennte Zugänge für Anwendung, Betrieb und Auswertung.

  5. 05

    Maskierung und Pseudonymisierung

    Für Test-, Analyse- und Support-Umgebungen.

  6. 06

    Abfluss-Kontrollen (DLP)

    Kontrollpunkte dort, wo Daten die Plattform verlassen, mit realistischer Erwartung an das, was DLP leisten kann.

  7. 07

    Audit-Logging

    Wer hat wann auf welche Daten zugegriffen, manipulationsgeschützt abgelegt und auswertbar.

  8. 08

    Nachweise und Übergabe

    Abschluss

    Konfigurationsstände, Rotationsnachweise, Restore-Tests, Runbooks und Einweisung Ihres Teams.

06PostgreSQL in der Praxis

Was PostgreSQL schützt und wo die Grenzen liegen

Die PostgreSQL-Dokumentation zu Verschlüsselungsoptionen beschreibt Optionen und Grenzen klar. Daraus ergeben sich Entscheidungen, die wir offen benennen.

  • Datenpartition verschlüsseln

    Schützt vor dem Lesen unverschlüsselter Daten bei Diebstahl von Laufwerken oder Rechner, laut Dokumentation aber nicht vor Angriffen, während das Dateisystem eingebunden ist. Wer Zugriff auf das laufende System hat, sieht die Daten im Klartext.

  • Spaltenverschlüsselung mit pgcrypto

    Der Schlüssel wird vom Client geliefert, entschlüsselt wird auf dem Server. Daten und Schlüssel liegen dort kurzzeitig im Klartext vor; ein Administrator mit Vollzugriff auf den Server könnte sie abgreifen.

  • Clientseitige Verschlüsselung

    Der Weg, wenn dem Serveradministrator nicht vertraut werden kann: Unverschlüsselte Daten erscheinen nie auf dem Datenbankserver. Der Preis: Suche und Auswertung auf diesen Feldern sind eingeschränkt.

  • Transparente Datenverschlüsselung

    Die Dokumentation beschreibt sie nicht als PostgreSQL-Funktion; sie wird über Dateisystem- oder Volume-Verschlüsselung gelöst. Wer sie als Datenbankfunktion braucht, wählt einen Plattformdienst oder eine Erweiterung und bewertet deren Garantien.

  • Row-Level-Security (RLS)

    Begrenzt Zeilen je Rolle (Dokumentation). Superuser und Rollen mit BYPASSRLS umgehen RLS immer, Tabelleneigentümer normalerweise ebenfalls, es sei denn, die Tabelle ist mit FORCE ROW LEVEL SECURITY konfiguriert. Referenzielle Integritätsprüfungen umgehen RLS und können bei unvorsichtigem Schema-Design Informationen über verdeckte Kanäle preisgeben; Richtlinien, die auf andere Zeilen oder Tabellen verweisen, können Race Conditions erzeugen. RLS ersetzt keine saubere Rollentrennung.

  • Verschlüsselte Übertragung

    TLS für Verbindungen zur Datenbank, mit Zertifikatsprüfung durch den Client. Pro Host lässt sich über hostssl in pg_hba.conf erzwingen, dass verschlüsselt verbunden wird.

Datenbankbetrieb

Betrieb und Hochverfügbarkeit der Datenbank selbst

Dafür gibt es eigene Seiten: PostgreSQL-Beratung für Betrieb und Hochverfügbarkeit, Managed PostgreSQL für die Absicherung als Managed Service.

Managed PostgreSQL

07Abflusskontrolle

DLP: was es leisten kann und was nicht

Data-Loss-Prevention erkennt und begrenzt den Abfluss sensibler Daten an definierten Kontrollpunkten: ausgehender Verkehr, Datei-Uploads, Exporte, Freigaben. Die Wirkung hängt davon ab, dass Datenklassen sauber erkannt werden und die Kontrollpunkte vollständig sind.

Wir starten mit wenigen, klar abgegrenzten Datenklassen und Kontrollpunkten und messen Treffer und Fehlalarme, bevor Blockierung eingeschaltet wird.

  • DLP ergänzt Zugriffskontrolle und Verschlüsselung, ersetzt sie nicht.
  • Verschlüsselter Verkehr und Daten in Bildern oder Archiven entziehen sich der Inhaltsprüfung, wenn der Kontrollpunkt sie nicht entschlüsseln darf.
  • Regeln brauchen Pflege; zu viele Fehlalarme führen dazu, dass Alarme ignoriert werden.
  • Inhaltsprüfung von Mitarbeiterkommunikation berührt Datenschutz und Mitbestimmung: Das klären Sie vorab mit Datenschutzbeauftragtem und gegebenenfalls Arbeitnehmervertretung.
Türkisfarbene Glasfaser-Patchkabel an einem Netzwerk-Switch im Serverschrank, Nahaufnahme

08Nachvollziehbarkeit

Audit-Logs, die Sie auswerten können

Für Einrichtungen unter dem BSI-Gesetz stützt dieser Baustein insbesondere die Bereiche Kryptographie und Zugriffskontrolle aus § 30 Absatz 2 BSIG; die vollständige Zuordnung steht auf der Seite NIS2-Beratung.

  • Festlegen, welche Ereignisse protokolliert werden (Anmeldungen, Rollenänderungen, Lese- und Schreibzugriffe auf vertrauliche Daten, Exporte, Schlüsselzugriffe) und wie lange.
  • Logs getrennt von der protokollierten Plattform ablegen, schreibgeschützt oder unveränderlich, mit synchronisierter Zeit.
  • Auswertung und Alarmierung an Ihr bestehendes SIEM anbinden; ein eigener Security-Operations-Betrieb ist nicht Teil dieser Leistung.
  • Log-Inhalte können selbst personenbezogene Daten enthalten; Aufbewahrung und Zugriff stimmen wir mit Ihrem Datenschutzbeauftragten ab.

09Arbeitsweise

Schlüsselmaterial verlässt Ihre Hoheit nicht

Wir arbeiten mit Konfigurationen, Metadaten und Test- oder Staging-Daten. Zugriff auf Produktivdaten erfolgt nur, wo es für eine Maßnahme unvermeidbar ist, befristet und nach Ihrer Freigabe.

Schlüsselmaterial wird in Ihrem KMS oder Ihrer OpenBao-Instanz erzeugt und nie in Repositories, Tickets oder Chats abgelegt. Änderungen an produktiven Datenplattformen laufen über Ihre Änderungsprozesse und IaC-Reviews.

10Umfang und Angebot

Was ein Datensicherheitsprojekt größer oder kleiner macht

Den Aufwand bestimmen vor allem:

  • die Zahl der Datenspeicher und Plattformen,
  • die Zahl der Datenklassen und Mandanten,
  • die gewünschte Schlüsselhoheit (Anbieter-KMS oder eigene Instanz),
  • der Anteil von Altsystemen ohne Verschlüsselungsunterstützung,
  • die Tiefe der Umsetzung (Konzept, Umsetzung, Betrieb),
  • die Anbindung an vorhandene SIEM-, Backup- und Identitätssysteme.

Nach einem Erstgespräch erstellen wir ein Angebot mit klar abgegrenztem Leistungsumfang.

11Passung

Technische Umsetzung ja, Rechtsgutachten und Alarmbearbeitung nein

Das passt

  • Sie wollen Schlüsselverwaltung, Zugriffe, Maskierung und Protokollierung technisch sauber und betreibbar umsetzen.
  • Sie wollen Schutzmaßnahmen nach Datenklasse abstufen statt pauschal alles auf höchster Stufe.

Das passt nicht

  • Sie suchen eine datenschutzrechtliche Bewertung oder ein Verzeichnis von Verarbeitungstätigkeiten als Rechtsdokument.
  • Sie wollen ein DLP-Produkt kaufen und es ohne Klassifikation und Pflege „einschalten“.
  • Sie erwarten von dieser Leistung, dass wir als Security-Operations-Team Alarme bewerten und bearbeiten.
  • Sie suchen ein Zertifikat oder Testat für Dritte.

12

Häufige Fragen

Reicht die Verschlüsselung der Datenpartition aus?

Sie schützt laut PostgreSQL-Dokumentation vor dem Lesen der Daten bei Diebstahl von Laufwerken oder Rechner, nicht vor Angriffen, während das Dateisystem eingebunden ist. Ob das für Ihre Datenklasse genügt, zeigt die Schutzbedarfs-Matrix.

Ersetzt DLP die Zugriffskontrolle?

Nein. DLP ergänzt Zugriffskontrolle und Verschlüsselung, ersetzt sie aber nicht.

Übernehmen Sie die datenschutzrechtliche Bewertung?

Nein. Rechtsgrundlagen, Auftragsverarbeitung und Folgenabschätzung übernimmt Ihr Datenschutzbeauftragter; wir arbeiten ihm zu.

Haben Sie dauerhaft Zugriff auf unsere Produktivdaten?

Nein. Wir arbeiten mit Konfigurationen, Metadaten und Test- oder Staging-Daten. Produktivzugriff gibt es nur, wo er unvermeidbar ist, befristet und nach Ihrer Freigabe.

Erstgespräch

Beschreiben Sie Plattformen, Datenarten und Ziel

Weitere Bereiche finden Sie im Cybersecurity-Überblick, für Identitäten und Zugriffe auf Plattformebene siehe IAM und Zero Trust.

Projekt anfragen Cybersecurity-Überblick