--- title: "Datensicherheit in Cloud- und Datenplattformen | SKAFFON" description: "Datensicherheit beratend und technisch umgesetzt: Schlüsselverwaltung, Verschlüsselung, Zugriff, Maskierung, DLP und Audit-Logging, mit Schutzbedarfs-Matrix." url: https://skaffon.de/cybersecurity/datensicherheit/ --- ![Hand hält einen Schlüssel mit angehängtem USB-Stick, Nahaufnahme als Sinnbild für Schlüsselverwaltung](/_astro/hand-schluessel-usb-stick.BUS0g6JM_Z10P0t7.jpg) 1. [Startseite](/) 2. [Cybersecurity](/cybersecurity/) 3. Datensicherheit in Cloud- und Datenplattformen 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](/projekt-anfragen/) [Schutzbedarfs-Matrix ansehen](/cybersecurity/datensicherheit/#schutzbedarfs-matrix) - Abstufung nach Datenklasse statt alles auf Maximum - Schlüsselmaterial bleibt in Ihrer Hoheit Autor: [Ibrahim Yesilay](/unternehmen/ibrahim-yesilay/), Gründer und Geschäftsführer Stand: 13.11.2026 Typische 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](/daten/datenbank-migration/) und [Cloud Security](/cybersecurity/cloud-security/). Schutzbedarfs-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 ruhend | Schlüsselhoheit | Zugriff | Maskierung in Nicht-Produktion | Audit-Log | | --------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | --------------------------------------------------- | ------------------------------------------------ | | Öffentlich (Produktdaten, Website-Inhalte) | Plattform-Standard | Anbieter-KMS genügt | Lesen breit, Schreiben nach Rolle | nicht nötig | Änderungen | | Intern (Betriebsdaten, interne Dokumente) | Standard auf Volume- und Datenbankebene | Anbieter-KMS mit getrennten Zuständigkeiten | Rollenmodell nach Least Privilege | bei Bedarf | Zugriffe auf Administratorebene | | Vertraulich (Kundendaten, Verträge, personenbezogene Daten) | Standard, zusätzlich Feldverschlüsselung bei bestimmten Feldern | Kundengehaltene oder getrennt verwaltete Schlüssel (KMS mit Kunden-Schlüsselverwaltung oder OpenBao) | Row-Level-Security, getrennte Datenbankrollen, privilegierter Zugriff nur befristet | Standard (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ügbar | Eigene Schlüsselhierarchie mit Vier-Augen-Prinzip für Schlüsselzugriff | Je Zweck freigegeben, kein Dauerzugriff für Menschen | Standard, keine Produktivdaten außerhalb Produktion | Vollstä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. Schlü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 Schlüsselhierarchie mit Trennung der Zuständigkeiten Schlüsselhoheit ## Anbieter-KMS oder eigene OpenBao-Instanz Technische Basis ist das KMS Ihres Cloud-Anbieters oder ein selbst betriebenes Secrets-Management wie [OpenBao](https://openbao.org/docs/), je nach Souveränitätsanforderung. OpenBao stellt laut [Dokumentation](https://openbao.org/docs/secrets/) 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](/_astro/glasfaser-steckverbinder-rack.C7qw2gfJ_sa4D.jpg) Vorgehen 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. PostgreSQL in der Praxis ## Was PostgreSQL schützt und wo die Grenzen liegen Die [PostgreSQL-Dokumentation zu Verschlüsselungsoptionen](https://www.postgresql.org/docs/current/encryption-options.html) 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](https://www.postgresql.org/docs/current/ddl-rowsecurity.html)). 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](/daten/postgresql-datenbanken/) für Betrieb und Hochverfügbarkeit, [Managed PostgreSQL](/managed-services/managed-postgresql/) für die Absicherung als Managed Service. [Managed PostgreSQL](/managed-services/managed-postgresql/) Abflusskontrolle ## 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](/_astro/glasfaser-patchfeld-switch.C7rA1wBj_Z1b5FAo.jpg) Nachvollziehbarkeit ## 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](/cybersecurity/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. Arbeitsweise ## 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. Was Sie mitbringen Eine Ansprechperson für Datenklassen und Schutzbedarf, Architekturunterlagen mit lesendem Zugriff auf Konfigurationen, die Klärung gesetzlicher und vertraglicher Vorgaben für Speicherort und Schlüsselhoheit sowie die Datenbank- und Anwendungsverantwortlichen für Abnahme und Restore-Tests. Umfang 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. Passung ## 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. ## 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](/cybersecurity/), für Identitäten und Zugriffe auf Plattformebene siehe [IAM und Zero Trust](/cybersecurity/iam-zero-trust/). [Projekt anfragen](/projekt-anfragen/) [Cybersecurity-Überblick](/cybersecurity/)