+150 XP

Privacy- und Access-Audit für Ihren Data Stack

# Privacy- und Access-Audit für Ihren Data Stack

Ein Customer-Success-Mitarbeiter in einem mittelgroßen SaaS-Unternehmen kann im BI-Tool (Business Intelligence) mit drei Klicks die E-Mail-Adresse, die Rechnungsadresse und die komplette Support-Ticket-Historie jedes Nutzers aufrufen: ungefiltert, nicht geloggt, ohne Freigabe. Niemand hat das absichtlich so gebaut. Es hat sich angesammelt: Ein Dashboard für ein Team wurde weitergegeben, eine eigentlich temporäre Rolle lief nie ab, ein Reverse-ETL-Sync (Extract, Transform, Load) schob Warehouse-Felder in ein Sales-Tool, ohne dass jemand geprüft hat, was „select all columns“ tatsächlich umfasst.

Das ist der Normalzustand der meisten Data Stacks im Jahr 2026. Die Lösung ist kein riesiges Compliance-Projekt. Es ist ein wiederkehrendes, checklistenbasiertes Audit, das Sie an einem Nachmittag durchführen können.

Warum das ein Governance-Problem ist und nicht nur ein IT-Problem

Data Governance ist die Summe der Regeln, Rollen und Prozesse, die festlegen, wer auf Daten zugreifen, sie ändern oder verschieben darf, und wie Sie das nachweisen. In SaaS ist das praktische Risiko nicht abstrakt: Ein Support-Agent sieht die Zahlungsdaten eines anderen Kunden, oder ein Growth-Analyst exportiert PII (personally identifiable information, also Namen, E-Mail-Adressen oder IP-Adressen) in eine Tabelle, die auf einem privaten Laptop landet.

Regulierer interessieren sich dafür, weil das Gesetz es so vorsieht. Nach der DSGVO der EU (Datenschutz-Grundverordnung) müssen Unternehmen „Datenschutz durch Technikgestaltung und durch Voreinstellungen“ umsetzen (Artikel 25) und riskieren bei schweren Verstößen Bußgelder von bis zu 4 % des globalen Jahresumsatzes oder 20 Millionen Euro, je nachdem, welcher Betrag höher ist (EU-DSGVO-Text). In den USA gibt es kein einheitliches Bundesdatenschutzgesetz, aber Landesgesetze wie CCPA/CPRA (California Consumer Privacy Act, geändert durch den California Privacy Rights Act) geben der California Privacy Protection Agency Durchsetzungsbefugnisse, und Branchenregeln wie HIPAA (Health Insurance Portability and Accountability Act) greifen, wenn Ihr SaaS-Produkt Gesundheitsdaten berührt.

Auditoren und Enterprise-Kunden fragen inzwischen routinemäßig nach SOC 2-Berichten (System and Organization Controls 2, ein US-Audit-Framework der AICPA), bevor sie Verträge unterschreiben. Access Control ist eines der ersten Dinge, die ein SOC-2-Auditor prüft.

Die drei Ebenen, auf denen PII tatsächlich abfließt

Die meisten SaaS-Unternehmen speichern Kundendaten in einem Data Warehouse (einer zentralen, auf Analytics optimierten Datenbank, z. B. Snowflake, BigQuery, Redshift). Von dort fließen Daten in zwei Richtungen:

1. In BI-Tools (Looker, Tableau, Power BI, Metabase) für Dashboards und Reporting.

2. Heraus über Reverse ETL (Tools wie Census oder Hightouch, die Warehouse-Daten zurück in operative Tools wie Salesforce, HubSpot oder Intercom schieben).

Jede Ebene braucht ihr eigenes Audit, weil Berechtigungen nicht automatisch von einer auf die nächste übertragen werden. Eine im Warehouse maskierte Spalte kann trotzdem abfließen, wenn das BI-Tool einen alten Extract cached oder wenn ein Reverse-ETL-Sync eingerichtet wurde, bevor die Maskierungsregel existierte.

Die Checkliste: Warehouse-Ebene

Führen Sie das quartalsweise durch, oder nach jeder Personalveränderung in Datenteams.

  • Listen Sie jede Rolle und jeden User mit Query-Zugriff auf. In Snowflake oder BigQuery ziehen Sie die Access Grants direkt:
sql
-- Snowflake example: who can query the customers table?
SHOW GRANTS ON TABLE analytics.core.customers;
  • **Markieren Sie Rollen mit SELECT * auf rohen PII-Tabellen.** Wer nicht zum Data Engineering gehört oder eine benannte Datenschutzrolle hat, sollte keinen unbeschränkten Zugriff auf rohe Spalten wie email, phone, ssn, ip_address haben.
  • Prüfen Sie Masking auf Spaltenebene. Moderne Warehouses unterstützen Dynamic Data Masking und zeigen nicht-privilegierten Rollen j***@***.com statt einer echten E-Mail-Adresse. Bestätigen Sie, dass das tatsächlich auf Produktionstabellen angewendet wird, nicht nur auf Staging.
  • Überprüfen Sie Service Accounts. Das sind nicht-menschliche Logins, die von Pipelines genutzt werden. Sie haben oft weitreichenderen Zugriff als jeder einzelne Mitarbeiter und werden selten überprüft. Ein Service Account für ein Marketing-Tool sollte keinen Schreibzugriff auf Billing-Tabellen haben.
  • Bestätigen Sie, dass Query-Logs aufbewahrt und durchsuchbar sind. Sie müssen die Frage „Wer hat die Daten von Kunde X abgefragt, und wann?“ für mindestens 90 Tage, idealerweise 12 Monate, beantworten können, um auf einen Regulierer oder ein Auskunftsersuchen eines Kunden zu reagieren (DSAR, data subject access request, ein von der DSGVO garantiertes Recht zu erfahren, welche Daten ein Unternehmen über Sie hält).

Die Checkliste: BI-Tool-Ebene

  • Mappen Sie Dashboards auf die zugrundeliegenden Tabellen. Ein Dashboard für das Marketing-Team sollte nicht stillschweigend eine Support-Tabelle mit rohem Beschwerdetext und Kundennamen joinen.
  • Prüfen Sie Security-Einstellungen auf Row- und Column-Level. Lookers PDTs (persistent derived tables) und Access Filter oder Tableaus Row-Level Security sollten einschränken, was jeder Viewer sieht, nicht nur, was er bearbeiten kann.
  • Auditieren Sie „Explore“- oder Ad-hoc-Query-Berechtigungen. Die meisten BI-Tools erlauben Power Usern, kuratierte Dashboards zu umgehen und das zugrundeliegende Modell direkt abzufragen. Genau dort versteckt sich Over-Permissioning meist.
  • Prüfen Sie Export- und Download-Rechte. Kann ein User eine vollständige Kundenliste als CSV exportieren? Wenn ja, wer, und wird es geloggt?
  • Überprüfen Sie Embedded- und Shared-Links. Viele BI-Tools erlauben es, einen öffentlichen oder halb-öffentlichen Link zu einem Dashboard zu erzeugen. Suchen Sie nach allen, die PII offenlegen und nie widerrufen wurden.

Die Checkliste: Reverse-ETL-Ebene

Reverse ETL ist neuer und weniger geprüft, was es 2026 zur Ebene mit dem höchsten Risiko macht.

  • Listen Sie jeden aktiven Sync und sein Ziel auf (CRM, Ad-Plattform, Support-Tool, E-Mail-Marketing).
  • Prüfen Sie das Mapping auf Feldebene. Ein Sync, der „customer tier“ an ein Marketing-Tool senden soll, sollte nicht zusätzlich „lifetime support notes“ mitführen, weil jemand die ganze Tabelle statt einzelner Spalten ausgewählt hat.
  • Verifizieren Sie den Zugriff auf der Zielseite. Sobald PII in HubSpot oder im Audience-Tool einer Ad-Plattform landet, gilt Masking auf Warehouse-Ebene nicht mehr. Wenn Sie gehashte E-Mail-Adressen synchronisieren, um eine Ad Audience aufzubauen (ein üblicher Ansatz für Retargeting), bestätigen Sie, dass das Hashing tatsächlich vor dem Sync passiert, nicht danach.
  • Prüfen Sie Sync-Frequenz und Aktualität. Wenn ein Kunde sein DSGVO-Recht auf Löschung ausübt („Recht auf Vergessenwerden“, Artikel 17) und Sie ihn aus dem Warehouse löschen: Propagiert der nächste Sync diese Löschung nach unten, oder bleiben veraltete PII unbegrenzt in einem Marketing-Tool liegen?

Als praktische Checklisten-Vorlage: Der OWASP-Leitfaden zum Datenschutz ist für Security Engineers geschrieben, aber seine Access-Control-Prinzipien lassen sich direkt auf Data-Stack-Audits übertragen.

Wissenscheck

1. Warum ist unbeschränkter Zugriff auf Kunden-PII in einem BI-Tool besser als Governance-Problem einzuordnen denn als rein technisches IT-Problem?

2. Ein Dashboard wurde ursprünglich für ein Team gebaut, später aber breit geteilt, und eine temporäre Rolle wurde nie entzogen. Was zeigt dieses Szenario am besten?

3. Ein Unternehmen will verhindern, dass ein Reverse-ETL-Sync versehentlich sensible Warehouse-Felder in ein Sales-Tool schiebt. Was ist die wirksamste Governance-orientierte Lösung?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE korrekten Antworten dazu aus, warum Regulierer und Enterprise-Kunden sich für Zugriffskontrollen in SaaS-Produkten interessieren.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE korrekten Antworten zu den praktischen Risiken aus, die unkontrollierter Datenzugriff im Stack eines SaaS-Unternehmens erzeugt.

Wählen Sie alle richtigen Antworten aus.

Ein durchgerechnetes Mini-Beispiel: Ihr Exposure quantifizieren

Angenommen, Ihr Warehouse hat 40 Mitarbeiter-Accounts und 15 Service Accounts mit irgendeiner Form von Query-Zugriff. Sie prüfen die Grants und finden:

  • 6 menschliche Accounts haben unbeschränktes SELECT * auf einer rohen customers-Tabelle (sollten 2 sein: Data-Engineering-Lead und der vom DSB benannte Analyst).
  • 3 Service Accounts, die Reverse-ETL-Tools befüllen, haben Zugriff auf Spalten über das hinaus, was ihr Sync tatsächlich nutzt.

Das sind 9 über-berechtigte Accounts von 55, also rund 16 % aller Access Grants. Genau diese Art von Kennzahl will ein Board oder ein SOC-2-Auditor Quartal für Quartal verfolgt sehen, idealerweise mit Trend gegen null. Die absolute Zahl zählt weniger als die Frage, ob Sie sie auf Abruf liefern und einen Rückgang zeigen können.

Wer das organisatorisch verantwortet

Governance scheitert, wenn sie niemandes ausdrückliche Aufgabe ist. In der Praxis:

  • Ein Datenschutzbeauftragter (DSB) ist nach DSGVO für Unternehmen mit umfangreicher Verarbeitung sensibler Daten gesetzlich vorgeschrieben; kleinere SaaS-Unternehmen geben diese Rolle oft in Teilzeit an einen Legal- oder Ops-Lead.
  • Data Engineering verantwortet Grants und Masking-Regeln auf Warehouse-Ebene.
  • Analytics- und BI-Leads verantworten Berechtigungen auf Dashboard-Ebene.
  • RevOps oder Growth Ops verantworten Reverse-ETL-Syncs und haben von den drei Gruppen oft die geringste Security-Schulung. Deshalb muss die Checklisten-Verantwortung auf dieser Ebene explizit zugewiesen werden, nicht stillschweigend angenommen.

Die wichtigsten Punkte

  • Auditieren Sie alle drei Ebenen getrennt: Warehouse-Grants, BI-Tool-Berechtigungen und Reverse-ETL-Sync-Mappings. Zugriffsrechte bleiben über die Ebenen hinweg nicht automatisch konsistent.
  • Service Accounts und Ad-hoc-„Explore“-Query-Modi sind die zwei am häufigsten übersehenen Quellen von Over-Permissioning.
  • DSGVO (EU) und CCPA/CPRA (Kalifornien) schaffen reales Durchsetzungsrisiko; SOC-2-Berichte sind das faktische kommerzielle Eintrittstor für Enterprise-SaaS-Deals, und beides hängt an nachweisbarer Access Control.
  • Verfolgen Sie eine einfache Kennzahl pro Quartal: über-berechtigte Accounts als Anteil aller Access Grants, und zeigen Sie, dass sie sinkt.
  • Reverse ETL ist Stand 2026 die neueste und am wenigsten auditierte Ebene: Im Warehouse angewendetes Masking folgt den Daten nicht, sobald sie in einem CRM oder auf einer Ad-Plattform landen.