Datenschutzmuster
Weitere Informationen zu Well-Architected Trust → Datenschutz und Privatsphäre
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 |
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 |
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 |
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 |
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 |