Schützen, aufbewahren und nachweisen

🌐 Auch in 28 Sprachen

English · Español · 日本語 · Português (Brasil) · Français · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Mit KI erstelltes Bild

Von KI übersetzt. Noch nicht von der Community geprüft. Auf Englisch lesen

Modul 6 von 6 im Kapitel Datenqualität und Governance, Kapitel 5 des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Einwilligung und das Recht auf Vergessenwerden · Weiter: das nächste Kapitel, Stammdaten und Identität

Die Frage, die dieses Modul beantwortet: Wie schützen Sie Daten, bewahren sie so lange wie nötig auf und weisen es nach?

Wir haben Eigentümer und Richtlinien festgelegt, schlechte Daten ferngehalten, das Glossar geschrieben, die Herkunft verfolgt, klassifiziert, was zählt, die Gesetze gelernt und die Einwilligung modelliert. Jetzt müssen wir es betreiben. Daten kommen herein, werden genutzt, kopiert und geändert, altern, und irgendwann muss ein Teil davon gehen. Und eines Tages wird jemand fragen: Weisen Sie nach, was passiert ist.

Die Governance folgt den Daten

Ich denke Governance nicht als eine Funktion. Ich denke daran, was mit den Daten passiert, vom Moment, in dem sie hereinkommen, bis wir mit ihnen fertig sind:

Erfassen → Klassifizieren → Schützen → Nutzen → Aufbewahren → Löschen → Prüfen

Keine sieben technischen Prozesse: sieben Fragen, die die Architektur beantworten muss. Erfassen und Klassifizieren haben wir behandelt: die teuren Fehler fernhalten (Modul 2) und wissen, welche Daten sensibel sind (Modul 3). Die Klassifizierung entscheidet, was in jeder späteren Phase passiert, also setzt dieses Modul dort an.

Click to enlarge

Sieben Fragen über das Leben der Daten hinweg. Werkzeuge unterstützen die Richtlinie; sie legen sie nicht fest.

Schützen: Passen Sie die Kontrolle den Daten an

Wer darf sie sehen, ändern, empfangen? Sollen sie verschlüsselt sein, außerhalb der Produktion maskiert, exportierbar, für einen Agenten erreichbar? Hier wird die Salesforce-Sicherheit Teil der Daten-Governance: Freigabe, Objekt- und Feldberechtigungen, Verschlüsselung, Maskierung, Zugriff von Integrationen. Diese Themen füllen ganze Kurse, also unterrichte ich sie nicht erneut. Der Governance-Punkt: Der Schutz folgt der Klassifizierung und der Richtlinie. Nicht jedes Feld braucht denselben Schutz, nicht jeder Benutzer denselben Zugriff, nicht jedes nachgelagerte System jedes Feld.

Verschlüsselung ist eine Kontrolle, keine Compliance

Für regulierte Daten ist die Verschlüsselung ruhender Daten vielleicht vorgeschrieben, und meine Position ist, dass Shield die Antwort auf wichtige regulatorische Anforderungen wie diese ist. Shield Platform Encryption verschlüsselt Felder und Dateien im Ruhezustand. Aber „Wir haben es verschlüsselt, also sind wir konform“ ist doppelt falsch. Verschlüsselung ist eine Kontrolle unter Zugriff, Aufbewahrung, Prüfung, Einwilligung, Überwachung, Minimierung und Löschung. Und sie hat funktionale Abwägungen, für die Sie von Anfang an entwerfen. Mit dem standardmäßigen probabilistischen Schema kann ein verschlüsseltes Feld nicht in SOQL-Klauseln WHERE, GROUP BY oder ORDER BY oder in Filtern der Datenverwaltung verwendet werden; deterministische Verschlüsselung gibt etwas Stärke auf, damit Sie nach dem Feld filtern können. Verschlüsselte Felder können keine kriterienbasierten Freigaberegeln steuern, und Sie können Listenansichten nicht danach sortieren (General Shield Platform Encryption Considerations (opens in a new tab); Filter Encrypted Data with Deterministic Encryption (opens in a new tab), auf Englisch). Verschlüsselung ist also kein Kontrollkästchen am Ende. Sie ist eine Architekturentscheidung. Das Kapitel zur Datensicherheit geht tiefer.

Kopieren Sie das Risiko der Produktion nicht in die Sandbox

Die Produktion ist abgesichert. Dann aktualisiert jemand eine vollständige Sandbox, und Entwicklung, Test, Auftragnehmende und Testintegrationen halten jetzt Kopien echter personenbezogener Daten, die sie nie gebraucht haben. Die Umgebung hat sich geändert; die Sensibilität der Daten nicht. Genau dafür gibt es die Maskierungswerkzeuge von Salesforce. Beachten Sie eine Änderung: Das verwaltete Paket Data Mask erreicht am 31. Dezember 2026 das Ende des Supports, und sein Nachfolger ist Data Mask & Seed (Data Mask (Legacy) (opens in a new tab), auf Englisch). Aber das Werkzeug unterstützt die Richtlinie, und die Frage kommt zuerst: Braucht diese Umgebung überhaupt echte sensible Daten? Wenn realistische, nicht sensible Daten das Testen leisten können, ist das die bessere Antwort.

Nutzen: Erlaubnis betrifft nicht nur Menschen

Benutzer, Integrationen, Analytik, Partner, Automatisierung und Agenten nutzen alle die Daten. Einwilligung (Modul 5), Eigentümerschaft (Modul 1) und Klassifizierung (Modul 3) treffen sich hier zur Laufzeit. Soll dieser Benutzer die Telefonnummer des Empfängers sehen? Soll diese Integration sie bekommen, oder Snowflake, oder dieser Agent als Grounding? Die Antwort kann nicht lauten „Na ja, technisch kann er es.“ Das ist der Unterschied zwischen Fähigkeit und Governance: Die Architektur entscheidet, ob er es sollte.

Aufbewahren: Alles für immer zu behalten ist nicht neutral

Viele Organisationen haben eine zufällige Aufbewahrungsrichtlinie: für immer. Niemand hat das entschieden; Speicher war vorhanden, also blieben die Daten. Aber Daten zu behalten kostet Speicher und Leistung, vergrößert die Angriffsfläche für Datenschutz und Sicherheit, schafft Offenlegungspflichten und gibt Ihnen mehr Orte zum Durchsuchen, wenn jemand vergessen werden will. Für jede wichtige Kategorie: Warum behalten, wie lange, was startet die Uhr, gibt es ein gesetzliches Minimum oder ein Datenschutz-Maximum, und was passiert am Ende: archivieren, löschen, entidentifizieren?

Und Archivieren ist nicht dasselbe wie die Aufbewahrung zu lösen. „Wir haben es archiviert.“ Ist die Aufbewahrungsanforderung verschwunden? Die Datenschutzanforderung? Die Sicherheit? Sie haben geändert, wo die Daten liegen, nicht was sie sind. Ein Archiv braucht Zugriffskontrollen, Aufbewahrungs- und Löschregeln, Durchsuchbarkeit und Prüfung. Schieben Sie personenbezogene Daten in ein Archiv, das alle vergessen, und die Governance ist gerade schlechter geworden.

Löschen: Der Lebenszyklus braucht einen Ausgang

Löschen ist nicht nur für einzelne Datenschutzanfragen da. Daten erreichen das Ende ihrer Aufbewahrungsfrist; temporäre Datensätze überleben ihren Zweck; Archive laufen ab; ein Prozess entidentifiziert nach einer festgelegten Zeit. Was immer die Richtlinie sagt, die Architektur braucht einen Ausgang, nicht erfassen → speichern → mehr speichern → für immer speichern. Und wie Modul 5 gezeigt hat, reicht es nicht, den Salesforce-Datensatz zu löschen, wenn Kopien woanders leben.

Auch Historie ist Daten

Manchmal reicht der aktuelle Wert nicht. Der rechtliche Name eines Partners, die Klassifizierung eines Kunden, ein Einwilligungsstatus, ein Finanzattribut: Das Geschäft oder eine Aufsichtsbehörde muss vielleicht wissen, was er vorher war, wann er sich geändert hat und wer ihn geändert hat. Diese Historie ist Daten, und sie braucht ihre eigene Aufbewahrungsentscheidung.

Der standardmäßige Feldverlauf verfolgt bis zu 20 Felder pro Objekt und bewahrt Änderungen bis zu 18 Monate auf, bis zu 24 Monate nur über die API, mit Data Loader oder queryAll() (Field History Tracking Overview (opens in a new tab), auf Englisch). Und bei langen Textfeldern hält er nur fest, dass das Feld bearbeitet wurde, nicht, was darin stand: eine Lücke, wenn das Ihr Nachweis ist. Field Audit Trail, Teil von Shield oder einzeln gekauft, verfolgt bis zu 200 Felder pro Objekt und bewahrt die Historie auf, bis Sie sie löschen, in einem Archiv, das Sie über die API erreichen (Field Audit Trail (opens in a new tab), auf Englisch). Meine Position: Der Standard-Feldverlauf ist die Voreinstellung; nutzen Sie Field Audit Trail, wenn eine Vorschrift oder Compliance-Pflicht eine längere, nachweisbare Historie verlangt. Nicht weil „Prüfung gut klingt“.

Prüfen und Überwachen sind nicht dasselbe

Der Feldverlauf beantwortet Fragen zu Änderungen an ausgewählten Feldern. Weitere Fragen (wer hat sich angemeldet, wer hat Daten exportiert, welche APIs wurden aufgerufen, wer hat was angesehen) sind Überwachung, und das ist Event Monitoring. Nach meiner Erfahrung braucht man es typischerweise bei stärker regulierten Kunden, und hier ist meine stärkste Position in diesem Kapitel: Richten Sie es ein, bevor Sie es brauchen, und leiten Sie die Ereignisse vorab in ein Repository, etwa Splunk oder ein anderes SIEM.

Hier ist der Grund. Ereignisprotokolldateien werden ohne das Zusatzprodukt 1 Tag aufbewahrt, und das nur für einige Ereignistypen; mit Shield oder dem Zusatzprodukt Event Monitoring standardmäßig 30 Tage, und bis zu 365 Tage, wenn Sie die Aufbewahrung verlängern (Event Monitoring FAQ (opens in a new tab), auf Englisch). Alles Ältere ist weg, wenn Sie es nicht exportiert haben. Und die kostenpflichtigen Protokolle lassen sich für keinen Zeitraum vor Vertragsbeginn abrufen (dieselbe FAQ): Wer das Zusatzprodukt erst nach dem Vorfall kauft, bekommt die Vergangenheit nicht zurück. Eines der schlimmsten Gespräche, die man in der Architektur führen kann, lautet also: „Können wir sehen, was vor sechs Monaten passiert ist?“ „Nein.“ „Warum nicht?“ „Wir haben es nicht erfasst.“ Man will nicht auf ein Problem stoßen und dann feststellen, dass man diese Ereignisse nicht erfasst und gespeichert hat. Dann ist die Antwort einfach weg.

Click to enlarge

Richten Sie es ein, bevor Sie es brauchen.

Aber schwenken Sie nicht zu „alles protokollieren“. Was wollen Sie nachweisen? Welche Ereignisse zählen, wer braucht sie, wie lange, wer darf die Protokolle lesen, und könnten die Protokolle selbst sensible Daten enthalten? Protokollieren erzeugt Daten, und diese Daten brauchen auch Governance. Und Nachweise brauchen einen Eigentümer: Wem gehört das Repository, wer prüft Warnungen, wer kontrolliert, dass die Aufbewahrung funktioniert, wer bemerkt, dass der Feed vor drei Monaten still ausgefallen ist? Technologie ohne Eigentümer ist keine Governance; wir sind wieder bei Eigentümer:in, Steward und Verwaltenden aus Modul 1.

Weisen Sie die Kontrolle nach, nicht nur die Konfiguration

„Empfängerdaten sind nur für die Crews verfügbar, die dem Stopp zugewiesen sind.“ Woher wissen wir das? Die Sicherheitskonfiguration zeigt, was passieren sollte. Betriebliche Nachweise (wer tatsächlich darauf zugegriffen hat, ungewöhnliche Exporte, eine Integration, die sie abruft, geänderte Zugriffskontrollen) zeigen, was passiert ist. Gute Governance braucht oft beides.

Über die Prüfung hinaus: Was KI ändert. Wenn Agenten vom Antworten zum Handeln übergehen, braucht die Governance Nachweise darüber, was der Agent gesehen, was er entschieden oder erzeugt und was er getan hat, und wer oder was ihn gestartet hat, unter welcher Richtlinie. Die Protokollierungsmechanismen werden sich ändern; die Anforderung nicht: Wenn eine autonome Aktion zählt, entwerfen Sie jetzt, wie Sie sie später rekonstruieren.

Steve Trucking: der Lebenszyklus an einem Feld

Nehmen Sie die Telefonnummer des Empfängers. Erfassen: Sie kommt mit der Ladeliste des Partners; prüfen Sie, ob sie dort brauchbar ist, wo der Prozess sie braucht. Klassifizieren: personenbezogene Daten. Schützen: Nur Menschen und Systeme mit operativem Bedarf bekommen sie, und Crews sehen sie nur für ihre eigenen Stopps, am Tag selbst. Nutzen: Die Crew stimmt die Lieferung ab; das Messaging nutzt sie für einen genehmigten Zweck; ein Agent nutzt sie nur, wenn die Richtlinie es erlaubt. Aufbewahren: so lange, wie die genehmigte Geschäfts- und Datenschutzrichtlinie sagt. Löschen oder entidentifizieren: wenn diese Frist endet oder eine gültige Anfrage kommt, über jede Kopie in der Landschaft. Prüfen: die Nachweise behalten, dass die Kontrollen und Maßnahmen stattgefunden haben.

Nehmen Sie jetzt einen Verteilzentrumscode. Erfassen Sie ihn genau, klassifizieren Sie ihn als nicht sensible Referenzdaten, schützen Sie ihn mit gewöhnlichem operativem Zugriff, nutzen Sie ihn breit, bewahren Sie ihn auf, wie das Geschäft es braucht, und prüfen Sie Änderungen, wenn sie zählen. Derselbe Lebenszyklus, andere Kontrollen. Dafür ist die Klassifizierung da.

Governance ist nie fertig

Eine neue Vorschrift erscheint. Ein neues System oder eine neue Integration schafft eine weitere Kopie. Ein Team erfindet ein weiteres Feld. Eine neue Plattform geht live. Ein Agent bekommt Zugriff. Eine Aufbewahrungsregel ändert sich. Ein neuer Handelspartner kommt dazu. Die Architektur bewegt sich, und die Governance bewegt sich mit. Das Ziel sind keine perfekten Daten, unendlichen Kontrollen oder ein Governance-Dokument, das niemand liest. Es sind bewusste Entscheidungen über die Daten, eingebaut in die Architektur.

Was Architekt:innen hier entscheiden

• Welche Schutzkontrollen jede Datenkategorie bekommt, je nach Klassifizierung, Richtlinie und tatsächlicher Nutzung, einschließlich der Abwägungen der Verschlüsselung.
• Wie lange Daten und ihre Historie aufbewahrt werden, was die Uhr startet und was am Ende passiert.
• Wann der Standard-Feldverlauf reicht und wann eine Vorschrift Field Audit Trail verlangt.
• Welche Ereignisse erfasst werden, wo die Nachweise über die Aufbewahrungsfrist der Plattform hinaus gespeichert werden und wem sie gehören.
• Wie die Architektur wichtige Aktionen von Menschen, Integrationen und Agenten im Nachhinein nachweist.

Dieses Kapitel begann mit einer Idee: Governance wird in die Org hineinentworfen, nicht danebengeschrieben. Eigentümer:innen legen die Richtlinie fest, und Architekt:innen setzen sie durch. Halten Sie schlechte Daten dort fern, wo es zählt. Wissen Sie, was Ihre Daten bedeuten, woher sie kommen und wie sensibel sie sind. Achten Sie die Gesetze, modellieren Sie die Einwilligung, kontrollieren Sie, wohin personenbezogene Daten gehen. Schützen, bewahren und löschen Sie nach Richtlinie. Und erfassen Sie die Nachweise, bevor jemand danach fragt, denn sechs Monate nach einem Vorfall ist ein schrecklicher Zeitpunkt, um herauszufinden, dass die Nachweise nur dreißig Tage existiert haben.

Weiterlesen

• Salesforce-Hilfe, General Shield Platform Encryption Considerations (opens in a new tab) und Filter Encrypted Data with Deterministic Encryption (opens in a new tab) (auf Englisch), geprüft am 2026-10-14.
• Salesforce-Hilfe, Field History Tracking Overview (opens in a new tab) (auf Englisch), geprüft am 2026-10-14.
• Salesforce-Hilfe, Field Audit Trail (opens in a new tab) (auf Englisch), geprüft am 2026-10-14.
• Salesforce-Hilfe, Salesforce Event Monitoring Frequently Asked Questions (opens in a new tab) (auf Englisch), geprüft am 2026-10-14.
• Salesforce-Hilfe, Secure Your Sandbox Data with Salesforce Data Mask (Legacy) (opens in a new tab) (auf Englisch), geprüft am 2026-10-14.