--- schema_version: "1" id: 7693cfeeb6ac9f33fdb9060b9581045f8146366af9ad796e88603f1cbb1e1fa2 title: Datenschutzmuster collection: architect version: current locale: de-de portal_url: https://docs.salesforce.com/architect/current/de-de/well-architected/guides/trust-data-protection-patterns.md canonical_url: https://architect.salesforce.com/docs/architect/de-de/well-architected/guide/trust-data-protection-patterns.html source_site: architect.salesforce.com content_type: documentation content_hash: 8f6a2ca2f5769df98971625ada81f28d78793c5d10e13d4f7902268f63e98058 products: - Gut strukturiertes Framework - Architect Site Content Repo --- # Datenschutzmuster
Weitere Informationen zu Well-Architected [Trust](/docs/architect/de-de/well-architected/guide/trust.html) → [Datenschutz und Privatsphäre](/docs/architect/de-de/well-architected/guide/trust.html#data-protection-and-privacy) ## Datenklassifizierung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Datenklassifizierungsschema | ✅ Klassifizierungsschema dokumentiert mit Ebenen (Öffentlich, Intern, Vertraulich, Eingeschränkt)
✅ Geschäftsbeispiele für jede Klassifizierungsebene
✅ Klassifizierungsschema, das an behördlichen Verpflichtungen (HIPAA, PCI DSS, DSGVO) ausgerichtet ist
✅ Datenmodellierer, die während des Designs für die einheitliche Anwendung der Klassifizierung geschult wurden
✅ Neue Felder, die als Teil des Datenmodellierungsprozesses klassifiziert werden, nicht rückwirkend | | Feldebenenklassifizierung | ✅ Klassifizierung wird auf Feldebene angewendet, nicht nur auf Objektebene
✅ Felder in einem einzelnen Objekt können unterschiedliche Klassifizierungen aufweisen
✅ Feldebenensicherheit spiegelt Klassifizierungsunterschiede wider
✅ Nicht klassifizierte Daten werden standardmäßig auf die höchste geeignete Schutzebene festgelegt
✅ Klassifizierung steuert Schutzsteuerungen (Verschlüsselung, Zugriff, Aufbewahrung) | | Benutzerdefinierte Objekte und Felder | ✅ Alle benutzerdefinierten Objekte verfügen über eine dokumentierte Datenklassifizierung
✅ Als vertraulich oder eingeschränkt klassifizierte sensible Felder (Gehalt, SSN, PHI, Zahlungsdaten)
✅ Öffentliche Felder (Firmenname, Website), die als "Öffentlich" dokumentiert sind
✅ In Feldbeschreibungen erfasste Klassifizierungsmetadaten
✅ Klassifizierung während Codeüberprüfungen und ARB überprüft | | Standardobjekte | ✅ Standardobjektfelder werden anhand des Klassifizierungsschemas ausgewertet
Shield Platform Encryption für eingeschränkte Standardfelder aktiviert
✅ Auf vertrauliche Standardfelder angewendete Feldebenensicherheit
✅ Berichte und Listenansichten gefiltert, um die Offenlegung vertraulicher Standardfelder zu verhindern | | Integrationsdaten | ✅ Daten, die durch Integrationen fließen, die vor der Implementierung klassifiziert wurden
✅ Externe Systemdatenvertraulichkeit ausgewertet und dokumentiert
✅ Integrationsendpunkte, die eingeschränkte Daten verarbeiten, verwenden zertifikatsbasierte Authentifizierung
✅ Datenklassifizierung über Systemgrenzen hinweg beibehalten | | Compliance-Zuordnung | ✅ HIPAA-PHI-Felder identifiziert und mit "Eingeschränkt" markiert
✅ PCI-Karteninhaberdaten werden nach Möglichkeit in Salesforce vermieden – zur Reduzierung des Umfangs über das Zahlungs-Gateway tokenisiert. Verwenden Sie dort, wo sie gespeichert werden müssen, "Verschlüsselte benutzerdefinierte Felder" unter PCI DSS-Steuerelementen.
✅ Identifizierte personenbezogene Daten der DSGVO, die Datenschutzkontrollen unterliegen
✅ SOX-Finanzdaten klassifiziert und unterliegen der Aufgabentrennung | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Einheitlicher Schutz | ⚠️ Gleicher Schutz für alle Felder unabhängig von der Empfindlichkeit
⚠️ Daten mit niedrigem Wert sind überschützt (Verschwendung von Ressourcen), während Daten mit hohem Wert unterschützt sind
⚠️ Öffentliche Unternehmensinformationen werden genauso behandelt wie PHI- oder Zahlungskartendaten
⚠️ Jedes verschlüsselte Feld ohne Klassifizierungsberechtigung | | Rückwirkende Klassifizierung | ⚠️ Nach Bereitstellung in der Produktion klassifizierte Daten
⚠️ Sensible Daten, die durch Compliance-Prüfungen und nicht durch Designüberprüfungen ermittelt wurden
⚠️ Nur nach Sicherheitsvorfällen klassifizierte Daten
⚠️ "Wir werden die Klassifizierung später herausfinden" ist der Standard während der Entwicklung | | Nur Klassifizierung auf Objektebene | ⚠️ Ganze Objekte, die einheitlich klassifiziert werden, wenn Felder unterschiedliche Empfindlichkeit aufweisen
⚠️ Zugriff auf Objektebene ohne Feldebenensicherheit für sensible Felder
⚠️ Alle Felder in Account- oder Kontaktobjekten weisen dieselbe Klassifizierung auf.
⚠️ Objektberechtigungen, die als einzige Zugriffssteuerung für Objekte mit gemischter Sensitivität verwendet werden | | Tribal Knowledge | ⚠️ Klassifizierung undokumentiert, nur in Knowledge wichtiger Personen vorhanden
⚠️ Entwickler vertrauten darauf, "nur zu wissen", welche Felder vertraulich sind
⚠️ Kein schriftliches Klassifizierungsschema, auf das alle Datenmodellierer zugreifen können
⚠️ Neue Teammitglieder ohne Klassifizierungstraining | ## Verschlüsselung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Verschlüsselung im Leerlauf | ✅ Alle auf Infrastrukturebene über Hyperforce verschlüsselten Daten
Shield Platform Encryption für eingeschränkte Daten aktiviert
✅ Verschlüsselungsschema (probabilistisch, deterministisch, deterministisch mit Berücksichtigung der Groß- und Kleinschreibung), ausgewählt anhand der Anforderungen an Abfrage und Eindeutigkeit
✅ Verschlüsselungskonflikte während des Datenmodelldesigns ausgewertet | | Shield Platform Encryption-Strategie | ✅ Probabilistische Verschlüsselung für die meisten eingeschränkten Felder (unterstützt alle Abfragevorgänge)
✅ Deterministische Verschlüsselung, die für Felder verwendet wird, die exakt übereinstimmende WHERE-Klauseln oder Eindeutigkeit erfordern
✅ Deterministisches Element mit Berücksichtigung der Groß- und Kleinschreibung, bei dem die Unterscheidung von Kundenvorgängen für die Geschäftslogik wichtig ist
✅ Verhalten des verschlüsselten Felds vor der Produktionsbereitstellung getestet
✅ Formelfeldverweise auf entsprechend verarbeitete verschlüsselte Felder (bei Bedarf in Apex verschoben) | | Schlüsselverwaltung | ✅ Wichtige Rotationsvorgänge dokumentiert und automatisiert
✅ Wichtige Zerstörungsszenarien, die während der Notfallwiederherstellung getestet wurden
✅ Vom Kunden verwaltete Schlüssel (BYOK), die auf Compliance hin ausgewertet wurden und eine explizite Schlüsselkontrolle erfordern
✅ Wichtige Widerrufsverfahren dokumentiert
✅ Lebenszyklus des Verschlüsselungsschlüssels, der gemäß den Compliance-Anforderungen verwaltet wird | | Verschlüsselung während der Übertragung | ✅ TLS 1.2 oder höher für alle Integrationen erforderlich
✅ zertifikatsbasierte gegenseitige Authentifizierung für Integrationen, die eingeschränkte Daten verarbeiten
✅ HSTS-Kopfzeilen, die für Experience Cloud-Sites konfiguriert sind, um ein Herunterstufen des Protokolls zu verhindern
✅ TLS-Zertifikatablauf überwacht und automatische Verlängerung konfiguriert
✅ Schwache Chiffren und Protokolle deaktiviert | | Code und Konfiguration | ✅ Anmeldeinformationen, die nie in Code, Konfigurationsdateien oder Versionskontrolle eingebettet sind
✅ Anmeldeinformationen mit Namen und externe Anmeldeinformationen, die zur zentralen Verwaltung der Authentifizierung verwendet werden
✅ In die Architektur integrierte Rotationsfunktionen für Anmeldeinformationen
✅ Abstrakte Authentifizierung von Anmeldeinformationen mit Namen aus Code, wodurch Aktualisierungen ohne Codeänderungen ermöglicht werden | | AppExchange-Pakete | ✅ Vor der Installation bewertete Paketsicherheitsanforderungen
✅ Verschlüsselte Felder, auf die Pakete nur zugreifen können, wenn sie geschäftlich gerechtfertigt sind
✅ Über die Ereignisüberwachung überwachte Paketdatenzugriffsmuster
✅ Pakete, die Zugriff auf eingeschränkte Daten erfordern, werden einer erweiterten Überprüfung unterzogen | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Verschlüsselung ohne Auswertung | ⚠️ Probabilistische Verschlüsselung für alle Felder ohne Tests aktiviert
⚠️ Kritische Berichte, bei denen in der Produktion ein Fehler festgestellt wurde, da verschlüsselte Felder nicht aggregiert werden können
⚠️ Verschlüsselung für Formelfeldquellen aktiviert, ohne Auswirkungen zu verstehen
⚠️ Felder, die in SOQL LIKE-Abfragen verwendet werden, die ohne Wechsel zur deterministischen Verschlüsselung verschlüsselt wurden | | Eingebettete Anmeldeinformationen | ⚠️ In Code, benutzerdefinierte Einstellungen oder Versionskontrolle eingebettete Anmeldeinformationen
⚠️ In Apex Klassen hartcodierte API-Schlüssel, Kennwörter und Zertifikate
⚠️ In Quellcodeverwaltungs-Repositorys übernommene Anmeldeinformationen
⚠️ In benutzerdefinierten Metadaten oder benutzerdefinierten Einstellungen ohne Verschlüsselung gespeicherte Anmeldeinformationen | | Schwache oder ältere Protokolle | ⚠️ TLS 1.0 oder 1.1 akzeptiert (ersetzt und gefährdet)
⚠️ OAuth-Flow mit Benutzername und Kennwort zulässig, wenn JWT-Bearer verfügbar ist
⚠️ In Produktionsintegrationen akzeptierte selbstsignierte Zertifikate
⚠️ Zertifikatvalidierung deaktiviert, damit die Integration funktioniert | | Keine Schlüsselverwaltung | Shield Platform Encryption ist ohne Schlüsselrotationsverfahren aktiviert
⚠️ Keine dokumentierten Schlüsselvernichtungsszenarien
⚠️ Standardschlüssel, die verwendet werden, ohne vom Kunden verwaltete Schlüssel auf Compliance auszuwerten
⚠️ Schlüsselrotation und Widerrufsverfahren nie getestet | | Überverschlüsselung | ⚠️ Öffentliche oder interne Klassifizierungsdaten verschlüsselt, was Kosten ohne Nutzen verursacht
⚠️ Shield Platform Encryption für jedes Feld aktiviert, wodurch unnötige Komplexität entsteht
⚠️ BYOK wird verwendet, wenn die Compliance dies nicht erfordert (fügt operativen Overhead hinzu)
⚠️ Verschlüsselung erforderlich, wenn die Datenklassifizierung dies nicht rechtfertigt | ## Datenmaskierung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Sandbox-Strategie | ✅ Eingeschränkte Daten gelangen niemals in Entwicklungs- oder Testumgebungen
✅ Teilweise Sandbox-Kopie schließt eingeschränkte Objekte und Felder aus
✅ Sandbox-Vorlagen definieren, welche Objekte und Felder nach Umgebungstyp eingeschlossen werden sollen
✅ Data Mask für Sandbox-Instanzen konfiguriert, die produktionsähnliche Daten erfordern | | Data Mask Regeln | ✅ Data Mask Regeln verbergen sensible Felder und behalten gleichzeitig die Dateneigenschaften bei
✅ Muster behalten die referenzielle Integrität bei (dieselbe Eingabe erzeugt dieselbe maskierte Ausgabe)
✅ E-Mail-Adressen werden maskiert, bleiben aber für Tests gültig
✅ Telefonnummern maskiert, aber gültiges Format beibehalten
✅ Datumsverschiebungen durchgängige Aufrechterhaltung relativer Beziehungen
✅ Numerische Felder randomisiert innerhalb realistischer Bereiche | | Synthetische Daten | ✅ Entwicklungsumgebungen verwenden die Generierung synthetischer Daten
✅ Synthetische Daten weisen realistische Eigenschaften auf, die effektive Tests ermöglichen
✅ Keine Produktionsdaten für die Entwicklung erforderlich
✅ Testdatengenerierung automatisiert in Entwicklungs-Pipelines | | Nicht-Produktionsumgebungen | ✅ Produktionsdaten wurden nie in persönliche Entwicklerorganisationen kopiert
✅ Screenshots und Demos verwenden maskierte oder synthetische Daten
✅ Trainingsumgebungen verwenden synthetische Daten oder stark maskierte Produktionsdaten
✅ Zugriff von Vertragsnehmern und Anbietern auf Nicht-Produktionsdaten auf die Klassifizierung "Nur zur geschäftlichen Verwendung" | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Produktionsdaten in Sandbox-Instanzen | ⚠️ Vollständige Sandbox-Instanzen mit nicht maskierten Produktionsdaten für die Entwicklung aktualisiert
⚠️ Eingeschränkte Daten, die zur Bequemlichkeit in Entwickler-Sandbox-Instanzen kopiert werden
⚠️ Entwicklern wurde umfassender Zugriff auf Produktionsdaten-Sandbox-Instanzen gewährt
⚠️ Sandbox-Instanzen wurden mit sensiblen Daten aktualisiert, "weil Tests mit echten Daten einfacher sind" | | Keine synthetischen Daten | ⚠️ Produktionsdaten, die nur für alle Tests verwendet werden
⚠️ Keine synthetische Datengenerierung für Entwicklungsumgebungen
⚠️ "Wir brauchen echte Daten" angenommen, ohne synthetische Alternativen zu bewerten
⚠️ Manuelle Testdaten, die erstellt werden, wenn die Generierung automatisiert werden kann | ## Datenschutz nach Design **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Datenminimierung | ✅ Nur Daten, die für angegebene Geschäftszwecke erforderlich sind, werden erfasst
✅ Jede Feldergänzung wird mit "Welche architektonische Entscheidung erfordert diese Daten?"
✅ Daten, die nicht mehr dem Sammlungszweck dienen, wurden entfernt
✅ Optionale Felder sind klar gekennzeichnet und ohne geschäftliche Begründung nicht erforderlich
✅ Historische Datenaufbewahrung an der Rechtsgrundlage ausgerichtet, nicht "alles für immer beibehalten" | | Zweckbegrenzung | ✅ Berechtigungssätze schränken den Datenzugriff basierend auf dem Zweck der Auftragsfunktion ein
✅ Marketingbenutzer können ohne dokumentierte Begründung nicht auf Support-Kundenvorgangsdetails zugreifen
✅ Vertriebsbenutzer können nur dann auf Kundendienstverläufe zugreifen, wenn der Auftrag dies erfordert
✅ Funktionsübergreifender Datenzugriff erfordert explizite Genehmigung und Überwachung
✅ Datenzugriffszweck in Berechtigungssatzbeschreibungen dokumentiert | | Einwilligungsverwaltung | ✅ Einwilligung, die auf individueller Ebene für Marketing, Analysen und optionale Verarbeitung erfasst wird
✅ Einwilligung ist granular (zweckspezifisch), nicht binäre pauschale Einwilligung
✅ Workflows zum Widerruf von Einwilligungen werden in integrierte Systeme übernommen
✅ Einwilligungsentscheidungen mit Zeitstempel, Version und Mechanismus verfolgt
✅ Einwilligungsbenutzeroberfläche erklärt eindeutig, womit der Benutzer einverstanden ist | | Rechte der betroffenen Person | ✅ Zugriffsanforderungs-Workflows stellen Datenkopien innerhalb der Frist bereit, die von der maßgebenden Verordnung für Ihre Bereitstellung festgelegt wurde
✅ Korrektur-Workflows korrigieren Ungenauigkeiten mit Audit-Trail
✅ Lösch-Workflows löschen Daten, sofern gesetzlich zulässig (unter Berücksichtigung von Aufbewahrungspflichten)
✅ Workflows zur Übertragbarkeit exportieren Daten in maschinenlesbarem Format
✅ Regelmäßig getestete Workflows für Rechte betroffener Personen zur Validierung von Zeitachsen
✅ Workflow-Automatisierung stellt sicher, dass regulatorische Zeitpläne einheitlich eingehalten werden | | Datenschutzkontrollen | ✅ Datenschutzkontrollen werden technisch erzwungen, nicht nur durch Richtlinien
✅ Freigaberegeln implementieren Zweckbegrenzung
✅ Feldebenensicherheit schützt sensible Attribute
✅ Audit Trails erfassen datenschutzrelevante Ereignisse
✅ Datenschutzkontrollen in CI/CD-Pipelines validiert | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Sammeln Sie alles | ⚠️ Ansatz “Alle möglichen Daten erfassen, wir könnten sie eines Tages benötigen”
⚠️ Felder, die ohne dokumentierten Geschäftszweck hinzugefügt wurden
⚠️ Unbegrenzt gespeicherte Daten ohne Aufbewahrungsrechtfertigung
⚠️ Optionale Daten, die durch Pflichtfelder erfasst werden | | Leere Einwilligung | ⚠️ Single "Akzeptieren" Einwilligung für alle Zwecke
⚠️ Marketingeinwilligung kombiniert mit Servicebereitstellung in einem einzigen Kontrollkästchen
⚠️ Alles-oder-nichts-Einwilligung, wenn Zwecke getrennt werden können
⚠️ Einwilligung in 20-seitige Nutzungsbedingungen eingebettet | | Police ohne Erzwingung | ⚠️ In der Datenschutzerklärung werden ideale Vorgehensweisen beschrieben, die technisch nicht umgesetzt werden
⚠️ Benutzerschulung erforderlich, um unangemessenen Datenzugriff zu verhindern
⚠️ Datenschutzgrundsätze ohne Implementierung technischer Kontrollen dokumentiert
⚠️ Annahme der Policenkonformität ohne Überwachung und Validierung | | Manuelle Anforderungen betroffener Personen | ⚠️ DSGVO/CCPA-Anforderungen, die über manuelle IT-Tickets verarbeitet werden, die Monate dauern
⚠️ Keine dokumentierten Verfahren für Zugriff, Berichtigung, Löschung, Übertragbarkeit
⚠️ Das Fenster für den Abschluss von Anforderungen, das in der maßgebenden Verordnung für Ihre Bereitstellung festgelegt ist, wurde verpasst
⚠️ Anforderung, dass Workflows, die bei Prüfungen gefunden wurden, nicht vorhanden sind | | Übermäßige Datenfreigabe | ⚠️ Weitreichender Datenzugriff über Abteilungen hinweg ohne Zweckgrund
⚠️ Marketing-Zugriff auf Support-Kundenvorgangsdetails
⚠️ Vertrieb erlaubt Zugriff auf Kundendienstverläufe ohne dokumentierte Notwendigkeit
⚠️ Öffentlicher Lese-/Schreibzugriff für Objekte, die personenbezogene Daten enthalten | ## Datenresidenz **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Regionale Hyperforce-Bereitstellung | ✅ In Hyperforce Region bereitgestellte Organisation, die die Anforderungen an die Datenresidenz erfüllt
✅ Datenspeicherung und -verarbeitung erfolgen innerhalb der erforderlichen geografischen Grenzen
✅ Regionale Anforderungen vor der Bereitstellung dokumentiert und validiert
✅ Anforderungen an mehrere Regionen, die bei Bedarf durch eine Architektur mit mehreren Organisationen erfüllt werden | | Datenflusszuordnung | ✅ Datenfluss ordnet Dokument zu, woher die Daten stammen, weitergeleitet werden und sich dort befinden
✅ Grenzüberschreitende Datenübertragungen identifiziert und anhand von Vorschriften ausgewertet
✅ Standardvertragsklauseln oder verbindliche Unternehmensregeln für internationale Transfers
✅ Datentransferpfade, die auf die Einhaltung der Residenzen hin ausgewertet wurden, nicht nur Speicherort | | Umfang der Datenresidenz | ✅ Datenspeicherort (welche Hyperforce Region)
✅ Datenverarbeitungsstandort (Rechenregionen)
✅ Backup-Speicherort
✅ Speicherort für Protokollierungs- und Überwachungsprotokolle
✅ Integrationstransitpfade für grenzüberschreitende Datenbewegungen ausgewertet | | Architektur mit mehreren Organisationen | ✅ Architektur mit mehreren Organisationen, die verwendet wird, wenn behördliche Anforderungen in einer einzelnen Organisation nicht erfüllt werden können
✅ Jede Organisation wird in der entsprechenden Region für ihre Daten bereitgestellt
✅ Integrationsmuster berücksichtigen Einschränkungen bei der Datenresidenz
✅ In AS dokumentierte Kompromisse bei der betrieblichen Komplexität | | Compliance-Validierung | ✅ Datenresidenzanforderungen nach Gerichtsbarkeit dokumentiert
✅ Hyperforce Regionsauswahl vor der Bereitstellung anhand der Anforderungen validiert
✅ Regelmäßige Prüfungen bestätigen, dass die Daten innerhalb der erforderlichen Grenzen bleiben
✅ Änderungen an Residenzbestimmungen lösen Architekturüberprüfung aus | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Residenzaufsicht | ⚠️ Bei Compliance-Prüfungen festgestellte Verstöße gegen die Datenresidenz
⚠️ Bereitstellung von Organisationen ohne Bewertung regionaler Anforderungen
⚠️ "Cloud is Cloud" (Cloud ist Cloud) wird ohne Berücksichtigung von Datenstandortbestimmungen angenommen
⚠️ Rechtsordnungen hinzugefügt, ohne die Residenzpflichten zu überprüfen | | Transit ignoring residency (Residenz zum Ignorieren von Transitvorgängen) | ⚠️ Nur Speicherort berücksichtigt, während Transitpfade ignoriert werden
⚠️ Durch Regionen außerhalb der Compliance-Grenzen weitergeleitete Daten
⚠️ Integrations-Middleware, die in nicht kompatiblen Regionen verwendet wird
⚠️ In anderen Regionen als Primärdaten gespeicherte Sicherungen | | Unnötige Multi-Organisation | ⚠️ Architektur für mehrere Organisationen, die verwendet wird, wenn eine einzelne Organisation mit Hyperforce Regionen ausreicht
⚠️ Operative Komplexität, Lizenzkosten und Integrations-Overhead multipliziert ohne regulatorische Notwendigkeit
⚠️ Multi-Organisation implementiert "nur um sicher zu sein" ohne eine spezifische Compliance-Anforderung
⚠️ Multi-Organisation standardmäßig verwendet, wenn Datenklassifizierung und Zugriffssteuerungen ausreichend sind |