Trust

Bei Salesforce ist Trust unser wichtigster Wert. Sie ist die Grundlage jeder architektonischen Entscheidung auf der Plattform. Für Architekten wird Trust durch eine einzigartige Partnerschaft erreicht: Salesforce bietet eine sichere, konforme Plattform – die Infrastruktur, Metadaten und Tools, um sie zu Ihrer eigenen zu machen –, während Sie sichere Lösungen entwickeln, die auf dieser Grundlage basieren.

Diese Partnerschaft wird über das Modell der gemeinsamen Verantwortung abgewickelt, bei dem es sich um ein Framework handelt, das die Sicherheitsaufgaben klar aufteilt:

• Salesforce ist für die Sicherheit der Plattform verantwortlich, einschließlich Infrastruktur-, Patching- und Compliance-Zertifizierungen.
• Sie sind für die Sicherheit auf der Plattform verantwortlich, einschließlich Konfiguration, Zugriffssteuerungen, benutzerdefiniertem Code und Datenverwaltung.

Diese Aufteilung ist wichtig, da sie die architektonische Verantwortlichkeit definiert. Salesforce betreibt eine mandantenfähige Architektur, in der Tausende von Organisationen die Infrastruktur gemeinsam nutzen. Die Plattform bietet einen starken Sicherheitsschutz auf Infrastrukturebene. Ihre architektonischen Entscheidungen bestimmen, ob Ihre spezifischen Lösungen das Vertrauen der Beteiligten gewinnen.

Mit dem Modell für die gemeinsame Verantwortung können Sie sichere Lösungen entwerfen, während physische Sicherheit, Netzwerkschutz, Plattformpatches und Infrastrukturverschlüsselung für Sie erledigt werden. Auf diese Weise können Sie sich auf die Entwicklung sicherer Lösungen konzentrieren, die auf dieser Grundlage basieren (z. B. Identitäts- und Zugriffsverwaltung, Datenschutz, Integrationssicherheit, sichere Entwicklungspraktiken, Compliance und Einhaltung gesetzlicher Vorschriften sowie Funktionen zur Reaktion auf Vorfälle).

Wenn Trust während des Designs vernachlässigt wird, kommt die technische Verschuldung hinzu. Eine fehlende Verschlüsselungsstrategie wird zu einer kostspieligen Nachrüstung, wenn sich Vorschriften ändern. Eine nicht verwaltete Integration wird zu einer Schwachstelle, wenn Anmeldeinformationen kompromittiert werden. Trust von Anfang an aufzubauen ist durchweg kostengünstiger als später nachzurüsten.

Trust umfasst vier Architekturdimensionen, die kohärent zusammenarbeiten:

• Sicherheitssteuerungen schützen Systeme und Daten
• Die Identitätsverwaltung regelt den Zugriff
• Datenschutzpraktiken berücksichtigen die Benutzeragentur
• Compliance-Frameworks erfüllen gesetzliche Verpflichtungen

Architekten, die für alle vier Dimensionen entwerfen, erstellen Lösungen, die Trust durch Transparenz, Kontrolle und Widerstandsfähigkeit gewinnen und erhalten.

Im Zeitalter der Agenten erstreckt sich Trust auf den vertrauenswürdigen Kontext, in dem Agenten tätig sind. Vertrauenswürdiger Kontext bedeutet, dass Agenten auf gesteuerte, überprüfte Daten mit klaren Identitäts- und Berechtigungsgrenzen zugreifen. Dadurch können AI-Systeme im Namen der Benutzer argumentieren und handeln und gleichzeitig Sicherheit, Überprüfbarkeit und Compliance gewährleisten. Das Entwerfen von vertrauenswürdigem Kontext ist die Grundlage für die Architektur von Agentic Enterprise.

Diese Säule legt die Plattformsicherheitsgrundlage fest, von der jede Salesforce-Lösung abhängt. Die Säule "Agentic Trust" baut auf dieser Grundlage auf, um Risiken anzugehen, die für autonome Agenten spezifisch sind, einschließlich der Eingabeaufforderung, der Steuerung von Aktionen und der Daten, auf die Agenten während der Überlegungen zugreifen können. Es ist wichtig, zunächst die Grundlage zu entwerfen und dann agentenspezifische Steuerelemente mithilfe der Richtlinien für Agentic Trust zu überlagern.

Diese Säule ist eng mit anderen Framework-Anliegen verbunden.

• Die Zuverlässigkeit hängt von der Infrastruktur ab, die Angriffen widersteht und sich von Verstößen erholt.
• Für Operational Excellence sind sichere Bereitstellungspipelines und Funktionen zur Reaktion auf Vorfälle erforderlich.
• Fairness erfordert einen transparenten, ethischen Umgang mit Daten und algorithmischen Entscheidungen.

Zusammen bilden diese Säulen einen einheitlichen, lösungsorientierten Ansatz, dem Organisationen bei ihren sensibelsten Vorgängen Trust schenken können.

Im Modell für die gemeinsame Verantwortung müssen Salesforce und Architekten ihrer jeweiligen Verantwortung nachkommen, um Trust aufrechtzuerhalten. Werfen wir einen genaueren Blick darauf, was jede Seite schützen muss.

Salesforce ist für die Sicherung der Plattform und ihrer globalen Infrastruktur verantwortlich, einschließlich:

• Zugriffskontrollen, Überwachung und Umweltschutzmaßnahmen für Rechenzentren
• Bei Hyperforce übernimmt der zugrunde liegende Cloud-Anbieter (beispielsweise AWS, Azure oder Google Cloud, je nach Instanz) die Sicherheit des physischen Rechenzentrums über die delegierte Verantwortung. In der Salesforce-Dokumentation "Infrastruktur und Subprozessoren" werden der Anbieter und die Subprozessoren für jeden Service angegeben.

• Sicherheitssteuerungen auf Netzwerkebene, einschließlich DDoS-Schutz und Bedrohungserkennung
• Datenverkehrsverschlüsselung im Transit (TLS 1.2+) und im Leerlauf (typischerweise AES-256)

• Reaktion auf Schwachstellen und Bereitstellung von Plattformpatches über Salesforce (weitere Informationen zu Sicherheitshinweisen finden Sie unter security.salesforce.com)
• Verwaltung der Betriebssystem- und Infrastruktursicherheit

• Zertifizierungen und Bescheinigungen: Salesforce behält SOC 1/2/3, ISO 27001/27017/27018, die FedRAMP-Autorisierung (auf Government Cloud Plus und MuleSoft Government Cloud beschränkt, nicht auf die kommerzielle Plattform mit mehreren Mandanten) und die Validierung des PCI-DSS der Ebene 1 bei.
• Regulatorische Unterstützung: Dies gilt für HIPAA-fähige Services mit Business Associate Agreements (BAAs) oder DSGVO-Compliance-Programmen.
• Weitere Informationen finden Sie unter Trust.salesforce.com und compliance.salesforce.com.

• Architektur für die Mandantenisolation: Ein freigegebener, metadatengesteuerter Kernel partitioniert die Daten und Metadaten jeder Organisation nach Organisations-ID, sodass eine Organisation nicht auf die Datensätze einer anderen Organisation zugreifen kann, obwohl beide auf einer freigegebenen Infrastruktur ausgeführt werden. Der Kernel erzwingt die Trennung bei jeder Abfrage, nicht durch eine Konfiguration, die Sie beibehalten müssen.
• Verschlüsselung auf Infrastrukturebene im Leerlauf und Sicherungsinfrastruktur: Basisplattformlizenzen enthalten die Classic-Verschlüsselung (AES-128 bietet nur benutzerdefinierte Textfelder). Für Shield Platform Encryption ist eine separate Lizenz erforderlich (AES-256 ermöglicht es Ihnen, Ihren eigenen Schlüssel mitzubringen und standardmäßige und benutzerdefinierte Felder, Dateien und Anhänge bereitzustellen).

Diese Steuerelemente stellen sicher, dass die Plattform sicher, zuverlässig und konform bleibt.

Sie sind für den Schutz Ihrer Daten, Konfigurationen und betrieblichen Prozesse verantwortlich.

• Identität und Verbund: Bei Single Sign-On (SSO) und Multi-Faktor-Authentifizierung (MFA) müssen Sie die Identität des Benutzers überprüfen.
• Zugriffseinschränkung: Technisch gesehen schränken IP-Bereiche und Anmeldezeiten ein, wie und wann Identitäten verbunden werden.
• Grundsatz der geringsten Berechtigung (PoLP): Verwenden Sie das PoLP, um nur Zugriff auf Rollen, Profile und Berechtigungssätze zu erteilen, die zum Ausführen einzelner Aufgaben erforderlich sind.
• Lebenszyklusverwaltung: Üben Sie die Benutzerlebenszyklus-Verwaltung und greifen Sie auf Richtlinien für die Neuzertifizierung zu.

• Verwenden von Datenklassifizierung, Maskierung und Objekt-/Feld-/Datensatzebenensicherheit
• CRUD-Berechtigungen und Freigaberegeln erzwingen
• Sie können eine bewährte Strategie zum Wiederherstellen der Daten Ihrer Organisation besitzen, testen und bereitstellen, um sicherzustellen, dass Datenverlust oder Korruptionsbehebung unter Ihrer Kontrolle bleiben.

• Verwenden Sie die API-Authentifizierung (z. B. OAuth 2.0 oder JWT) und Anmeldeinformationen mit Namen.
• Aktivieren Sie dedizierte Integrationsbenutzer mit PoLP-Berechtigungssätzen, damit der Zugriff auf jede Integration begrenzt und getrennt von menschlichen Benutzern überprüfbar ist.
• Sichere Endpunkte und Validierung des externen Systems.

• Verwenden Sie die Ereignisüberwachung, Audit-Trails und die SIEM-Integration (Security Information and Event Management).
• Befolgen Sie die Verfahren zur Reaktion auf Vorfälle und Sicherheitsüberprüfungen.

• Verwenden Sie sicheren benutzerdefinierten Code (z. B. Apex oder Lightning) und die Eingabevalidierung.
• Führen Sie Apex im Benutzermodus aus, damit Objekt-, Feld- und Freigabeberechtigungen im Code erzwungen werden.
• Befolgen Sie die Injektionsprävention und sichere Entwicklungspraktiken.

• Behalten Sie den Compliance-Status der Lösungen bei.
• Befolgen Sie die Richtlinien für Datenschutz/Einwilligungsverwaltung und Datenaufbewahrung.

Einige Aufgaben erfordern Zusammenarbeit:

• Antwort auf Sicherheitsvorfälle: Beide Parteien beteiligen sich an Erkennungs- und Antwortaktivitäten.
• Schwachstellenverwaltung: Salesforce Patches für die Plattform, Architekten Patches für benutzerdefinierten Code.
• Sicherheitsüberwachung: Kombinieren Sie plattformgenerierte Sicherheitssignale mit Architektenanalysen.
• Konformitätszertifizierungen: Salesforce zertifiziert die Plattform (z. B. SOC, ISO und FedRAMP für Government Cloud). Architekten sind Inhaber der darauf basierenden Elemente – benutzerdefinierte Objekte, Code, Integrationen und Konfiguration – innerhalb des zertifizierten Status, um die Einhaltung von Audits nachzuweisen.
• Identitätsverbund: Salesforce vertraut den Behauptungen, die der Identitätsanbieter des Architekten ausstellt. Architekten schützen den Anbieter und die Trust Beziehung zwischen dem Anbieter und Salesforce.
• Schlüsselverwaltung: Mithilfe der Bring-your-own-Schlüsselverschlüsselung betreibt Salesforce den Verschlüsselungsservice, während Architekten das Schlüsselmaterial zum Schutz der Daten generieren, rotieren und widerrufen.

Jedes Designprinzip, jeder Themenabschnitt und jedes Checklistenelement in diesem Dokument stellt Ihre Verantwortung als Architekt dar. Das Modell für die gemeinsame Verantwortung stellt fest, was Sie entwerfen und konfigurieren müssen, um Trust auf der Salesforce Platform zu erreichen.

Die Grenze erstreckt sich auf regulatorische Verpflichtungen. Salesforce behält die Zertifizierungen und Bescheinigungen der Plattform bei und schützt die Infrastruktur vor Verstößen. Architekten sind für die Verpflichtungen verantwortlich, die mit Ihren Daten und Ihrer Gerichtsbarkeit verbunden sind (z. B.: welche Gesetze gelten, wie Daten klassifiziert werden, welche Aufbewahrungs- und Einwilligungsregeln sie regeln und wie Sie Verstöße gegen die von Ihnen kontrollierten Daten erkennen und melden). Im Gegensatz zu den geltenden Vorschriften für Ihre Bereitstellungen müssen Architekten die spezifischen Zahlen hinter diesen Verpflichtungen (z. B. Aufbewahrungszeiträume und Benachrichtigungsfristen) anhand der geltenden Vorschriften für Ihre Bereitstellung festlegen, da sie je nach Zuständigkeit variieren und sich im Laufe der Zeit ändern können.

Verwenden Sie diese Grundsätze, um Ihre architektonischen Entscheidungen für die Sicherheit auf der Plattform zu leiten.

• Wenden Sie Zero Trust auf alle Ebenen an. Gehen Sie niemals von Trust aus, das auf dem Netzwerkstandort, der Benutzervertrautheit oder dem Systemursprung basiert. Überprüfen Sie jede Zugriffsanforderung explizit mit Authentifizierung, Autorisierung und Verschlüsselung auf Daten-, Anwendungs-, Integrations- und Infrastrukturebene. Eine mandantenfähige Architektur bedeutet, dass Sie die Infrastruktur für Tausende von Organisationen freigeben. Daher ist das Netzwerk, in dem Ihre Lösung ausgeführt wird, kein Bereich, den Sie als vertrauenswürdig behandeln können. Überprüfen Sie jede Anforderung anhand ihrer eigenen Vorzüge – Identität, Autorisierung und Kontext –, statt ihr zu vertrauen, woher sie stammt.
• Standardmäßig die geringste Berechtigung erteilen. Gewähren Sie jedem Benutzer, jeder Integration und jedem automatisierten Prozess die erforderliche Mindestzugriffsebene, um seinen Zweck zu erreichen. Beginnen Sie mit den restriktivsten Einstellungen – privaten organisationsweiten Standardeinstellungen und minimalen Berechtigungen – und erweitern Sie sie bewusst anhand dokumentierter Geschäftsanforderungen. Verwenden Sie das Zugriffsmodell mit vier Ebenen (Organisation → Objekt → Feld → Datensatz), damit jede Ebene die oben genannten Ebenen weiter einschränkt.
• Implementieren Sie Verteidigung in der Tiefe. Legen Sie mehrere Sicherheitssteuerungen übereinander, damit der Ausfall eines Steuerelements nicht das gesamte System beeinträchtigt. Kombinieren Sie vorbeugende Steuerelemente (z. B. CRUD/FLS-Erzwingungs- und Transaktionssicherheitsrichtlinien, die Vorgänge blockieren), Detektivsteuerelemente (z. B. Ereignisüberwachung) und reaktionsschnelle Steuerelemente (z. B. schrittweise Authentifizierung und Benachrichtigung zur Transaktionssicherheit). Gestalten Sie jede Ebene so, als ob die benachbarten Ebenen fehlschlagen könnten. Denken Sie daran, dass die Feldebenensicherheit Daten auch dann schützt, wenn Freigaberegeln zu freizügig sind.
• Integrieren Sie Sicherheit durch Design. Integrieren Sie Bedrohungsmodellierung, Sicherheitsanforderungen und Kontrollvalidierung in jede Architekturphase vom ersten Konzept bis zur fortlaufenden Entwicklung. Führen Sie die Bedrohungsmodellierung Spoofing, Manipulation, Ablehnung, Offenlegung von Informationen, Denial of Service und Elevation of Privilege (STRIDE) durch, bevor Sie mit der Erstellung beginnen. Sicherheit bestimmt die Technologieauswahl und Designentscheidungen.
• Integrieren Sie Sicherheit in die Automatisierung. Erstellen Sie Sicherheitssteuerungen in automatisierte Pipelines, Konfigurationsvorlagen und Plattformstandardeinstellungen. Salesforce Code Analyzer in CI/CD erkennt Schwachstellen vor der Bereitstellung. Die Konfiguration als Code erzwingt Sicherheitsgrundlagen. Die eingebettete Sicherheit gewährleistet Konsistenz und ermöglicht die Skalierung der Sicherheit mit der Komplexität der Lösung.
• Design für Datenschutz. Integrieren Sie Datenschutzprinzipien aus der anfänglichen Architekturphase. Design für die Datenminimierung (nur erforderliche Daten erfassen), Zweckbegrenzung (Zugriff nach Auftragsfunktion einschränken), Einwilligungsverwaltung (granulare, zweckspezifische Einwilligung erzwingen) und Rechte betroffener Personen (Ermöglichen des Abschlusses von Workflows für Zugriff, Berichtigung, Löschung und Übertragbarkeit innerhalb gesetzlicher Zeiträume).
• Design für Rückverfolgbarkeit. Gestalten Sie jede Folgeaktion nach der Tat zuordenbar und rekonstruierbar, bevor Sie sich darauf verlassen, Anomalien darin zu erkennen. Stellen Sie sicher, dass Änderungen an Daten, Berechtigungen und Konfigurationen in Prüfprotokollen, Feldverläufen und Ereignisprotokollen erfasst werden, und bewahren Sie diese Datensätze in einem manipulationssicheren Speicher auf. Die Rückverfolgbarkeit ist die Voraussetzung für Erkennung, Forensik und Verantwortlichkeit. Denken Sie daran: Sie können nicht untersuchen, was nie aufgezeichnet wurde.
• Design für die Reaktion auf Vorfälle. Design für die Erkennbarkeit durch Ereignisüberwachung und für Echtzeitinterventionen durch Transaktionssicherheitsrichtlinien. Ermöglichen Sie schnelle Reaktionen durch dokumentierte Verfahren und Isolationsgrenzen. Unterstützen Sie die Wiederherstellung durch Sicherungsfunktionen und die forensische Aufbewahrung. Testen Sie Antworten mithilfe von Tabletop-Übungen und Simulationen von Verstößen.

Architekten sind für die Sicherung von Lösungen auf der von Salesforce bereitgestellten Plattform verantwortlich.

Die mit Salesforce interagierenden Arbeitslasten werden zunehmend außerhalb der zentralen Plattform ausgeführt. Integrationsservices, benutzerdefinierte Anwendungen und Headless-Clients rufen häufig Salesforce-APIs auf, häufig im Namen eines Benutzers. Um dieses Muster zu beschleunigen, stellt Salesforce die Funktionen der Plattform als APIs, Tools und Befehle zur Verfügung (z. B. Salesforce Headless 360). Unabhängig davon, wer diese Anwendungen betreibt, ist der Architekt Inhaber der Trust Grenze, an der er Salesforce trifft, um zu bestimmen, wie er sich authentifiziert, welche Identität und Berechtigungen er trägt, welche Geheimnisse er besitzt und welche Daten die Grenze überschreiten.

Die folgenden Grundsätze gelten für alle Containerintegrationsplattformen (z. B. MuleSoft CloudHub).

Wenn sich ein externer Client als benannter Benutzer authentifiziert, wird das Plattformsicherheitsmodell von Salesforce automatisch angewendet. Objektberechtigungen, Feldebenensicherheit und Freigaberegeln werden genauso erzwungen wie im Browser. Die Authentifizierung pro Benutzer begrenzt jeden Aufruf auf die Berechtigungen dieser Einzelperson und behält den Überprüfungsprotokoll bei, d. h., durch Widerrufen des Tokens eines Benutzers kann der Client nicht mehr in seinem Namen handeln. Ziehen Sie dies einem freigegebenen Serviceaccount vor, wenn die Arbeit für einen bestimmten Benutzer ausgeführt wird.

Entwerfen Sie die Grenze defensiv, da ein Client, der Token für viele Benutzer enthält, Trust konzentriert und zu einem hochwertigen Proxy für einen Angreifer wird: Ein einzelnes gestohlenes OAuth-Token kann Daten für jeden Benutzer abrufen, den der Client bereitstellt. Dies ist nicht hypothetisch. Bei dem Salesloft Drift-Vorfall 2025 stahlen Angreifer OAuth-Token und nutzten sie, um Salesforce-Daten in Hunderten von Organisationen zu erhalten.

• Benutzeridentität übernehmen und nicht zusammenführen. Verwenden Sie die benutzerbasierte Authentifizierung oder den OAuth 2.0-Tokenaustausch, um die Identität eines Benutzers über Service-Hops hinweg zu übertragen (siehe Agentische Identität und Authentifizierung), damit Kompromisse auf den Kontext eines Benutzers und nicht auf alle beschränkt sind.
• Behandeln Sie OAuth-Client-Anmeldeinformationen und Aktualisierungstoken als primäres Ziel. Speichern Sie sie in einem Speicher für verwaltete Geheimnisse, rotieren Sie sie häufig und behalten Sie Designs für den sofortigen Widerruf bei. Überwachen Sie die API-Nutzung auf anomale Muster, die auf einen Proxy-Angreifer hinweisen.
• Minimieren Sie den Umfang auf beiden Seiten. Beschränken Sie die OAuth-Geltungsbereiche der externen Client-Anwendung (Externe Client-Anwendung) und die Salesforce-Berechtigungen des Integrationsbenutzers auf das für die Funktion erforderliche Minimum, damit ein kompromittierter Client nicht auf nicht zugehörige Daten umschwenken kann.
• Steuern Sie die Grenze über externe Client-Anwendungen. ECAs definieren, wie sich eine externe Anwendung authentifiziert, welche Flows zulässig sind und welche Umfänge gelten – entwerfen Sie neue Integrationen für sie (siehe Authentifizierungsarchitektur).

Gehen Sie bei Ausführung eines Clients als Agentenbenutzer oder Integrationsbenutzer mit Bedacht vor: Diese Identitäten können in einem erhöhten Kontext ausgeführt werden – oft gegen externe Systeme, die die Zugriffssteuerungen von Salesforce nicht berücksichtigen. Daher ist die Verwendung der oben beschriebenen Berechtigungs- und Überwachungsdisziplin der Grund dafür, dass diese Leistung gebunden bleibt.

Wenn Integrationen auf einer containerisierten Plattform ausgeführt werden, gilt die Isolierung auf Containerebene an sich als Sicherheitssteuerung: Jede Anwendung wird in einem dedizierten Container ohne gemeinsame Laufzeit oder Speicher zwischen Anwendungen ausgeführt.

Diese Isolation bietet Folgendes:

• Erzwingung der Mandantengrenze: Kompromittierte Anwendungen können nicht auf Daten oder Ressourcen aus benachbarten Anwendungen zugreifen, die dieselbe Umgebung verwenden. Jeder Container verfügt über ein isoliertes Dateisystem und einen Prozessbereich. Erzwingen Sie die Netzwerkisolation durch Firewall- und TLS-Konfiguration und schränken Sie den ausgehenden Datenverkehr explizit ein, statt sich auf zulässige Standardeinstellungen zu verlassen.
• Verteidigung im Detail: Durch die Containerisolierung wird eine Sicherheitsebene hinzugefügt, die über Steuerelemente auf Anwendungsebene hinausgeht. Selbst wenn der Anwendungscode Schwachstellen aufweist, begrenzen Containergrenzen den Explosionsradius.
• Compliance-Segmentierung: Regulierte Arbeitslasten (z. B. PCI und HIPAA) können in dedizierten Containern isoliert werden, wodurch verhindert wird, dass nicht kompatible Arbeitslasten miteinander vermischt werden.

Architekten, die Umgebungen mit mehreren Anwendungen entwerfen, müssen sich auf die Containerisolation verlassen, um die Trennung von Pflichten und Sicherheitsdomänen zu erzwingen. Finanzdienstleistungsintegrationen, die Karteninhaberdaten verarbeiten, müssen in separaten Containern von Marketingintegrationen ausgeführt werden, selbst in derselben Umgebung.

Der Datenverkehr zwischen Containern sollte verschlüsselt werden und gegenseitiges TLS (mTLS) sollte angewendet werden, wenn ein Regulierungsrahmen eine Authentifizierung auf beiden Seiten erfordert:

Funktionsweise:

• Konfigurieren Sie TLS-Kontexte, um bei Bedarf optionales gegenseitiges TLS (mTLS) für eingehende Verbindungen zu aktivieren.
• Verwenden Sie SSL auf Plattformebene mit Client-Zertifikatauthentifizierung, um die Kommunikation zwischen Plattformservices und Replikaten zu schützen.
• Konfigurieren Sie TLS-Kontexte so, dass mTLS aktiviert wird, wenn dies von regulatorischen Rahmenwerken gefordert wird.
• Verwalten Sie Zertifikate über den Zertifikatspeicher der Plattform, damit Lebenszyklus und Widerruf zentral bleiben.
• Erzwingen Sie Netzwerkisolationsgrenzen, die nicht autorisierten Datenverkehr zwischen Containern verhindern.

Durch die Verschlüsselung des Datenverkehrs auf Plattformebene wird die Datenübertragung umfassend geschützt. Selbst wenn das HTTPS auf Anwendungsebene falsch konfiguriert ist, bleibt der Containerdatenverkehr verschlüsselt.

Container, die über VPN mit lokalen Systemen verbunden sind, müssen für den Schutz von Daten bei der Übertragung konzipiert werden:

• Tunnelverschlüsselung: Leiten Sie den gesamten Datenverkehr zwischen Containern und lokalen Systemen durch verschlüsselte VPN-Tunnel weiter. Dies gilt unabhängig vom TLS der Anwendungsebene. Die Verteidigung im Detail stellt sicher, dass sensible Daten doppelt verschlüsselt werden.
• Erzwingung der Netzwerksegmentierung: VPN-Tunnelrichtlinien schränken ein, welche lokalen Netzwerke Container erreichen können. Kompromittierte Container können nicht auf nicht autorisierte interne Systeme außerhalb von VPN-zulässigen Netzwerken migriert werden.
• Konformitätsnachweise: Die VPN-Verschlüsselung ist einer der akzeptierten Mechanismen zum Schutz von Daten bei der Übertragung in und von Cloud-Umgebungen. Auditoren, die HIPAA-, PCI-DSS- oder SOX-Steuerelemente überprüfen, erwarten eine dokumentierte Verschlüsselung bei der Übertragung für Hybridintegrationen.

Architekten müssen VPN-Richtlinien entwerfen, die den Netzwerkzugriff mit den geringsten Berechtigungen erzwingen. Marketing-Integrationscontainer sollten nicht an interne Finanzsysteme weitergeleitet werden, selbst wenn beide über VPN erreichbar sind.

Für Vanity-Domänen (beispielsweise benutzerdefinierte URLs für Integrations-APIs) müssen Architekten TLS-Zertifikate als Trust Anker verwalten:

Für Vanity-Domänen (beispielsweise benutzerdefinierte URLs für Integrations-APIs) müssen Architekten TLS-Zertifikate als Trust Anker verwalten.

• Automatisierung des Zertifikatlebenszyklus: Implementieren Sie die automatische Verlängerung und Bereitstellung von Zertifikaten. Abgelaufene Zertifikate unterbrechen Integration Trust. Clients lehnen Verbindungen mit Zertifikatvalidierungsfehlern ab.
• Planung für den Widerruf von Zertifikaten: Entwerfen Sie Zertifikatrotationsverfahren für Sicherheitsvorfälle. Kompromittierte private Schlüssel erfordern eine schnelle erneute Ausstellung und Bereitstellung von Zertifikaten in allen Regionen.
• Konfiguration der Cipher Suite: Bei älteren TLS-Konfigurationen (TLS 1.0/1.1 und schwache Chiffren) treten bei Compliance-Audits Fehler auf. Erzwingen Sie TLS 1.2+ (Mindestanforderung) und gleichen Sie Zertifikat- und Clientkonfigurationen mit den Sicherheitsrichtlinien der Organisation ab.
• Zertifikattransparenzprotokollierung: Moderne TLS-Zertifikate werden von Zertifizierungsstellen an öffentliche Zertifikattransparenzprotokolle gesendet. Jedes CT-Protokoll gibt einen signierten Zertifikatszeitstempel (SCT) zurück, einen kryptografischen Protokollnachweis, den die Zertifizierungsstelle über eine X.509v3-Erweiterung in das Zertifikat einbettet. Architekten sollten CT-Protokolle mithilfe von Services wie crt.sh oder automatisierter Benachrichtigung auf nicht autorisierte Zertifikatsausstellung für ihre Domänen überwachen.

Missmanagement von Zertifikaten wirkt sich direkt auf den Trust-Status aus:

• Abgelaufene Zertifikate: Verursachen Sie Authentifizierungsfehler, die als Ausfälle angezeigt werden. Die Überwachung muss das Senden von Benachrichtigungen innerhalb von mehr als 30 Tagen vor Ablauf umfassen, damit Verlängerungsworkflows gestartet werden können.
• Selbstsignierte Zertifikate: Unterbrechen Sie Trust Chains für externe Clients. Produktionsintegrationen erfordern Zertifikate, die von vertrauenswürdigen Zertifizierungsstellen signiert werden.
• Platzhalterzertifikatsverbreitung: Bezieht sich auf zu breite Platzhalterzertifikate (z. B. *.company.com), die einen großen Explosionsradius verursachen, wenn sie kompromittiert werden. Zertifikate mit engem Umfang werden pro Integrationsdomäne bevorzugt.

Containerbereitstellungsregionen müssen den Anforderungen an die Datenresidenz und die Compliance entsprechen.

• DSGVO-Datenresidenz: Die DSGVO schreibt einen angemessenen Schutz personenbezogener Daten vor, die die Europäische Union (EU) verlassen, nicht jedoch die Bereitstellung durch die EU als solche. Durch die Bereitstellung von Integrationen in einer EU-Region bleiben die Containerberechnung und die Datenverarbeitung innerhalb gesetzlicher Grenzen, was die direkteste Möglichkeit darstellt, diese Anforderung zu erfüllen. Übertragungen außerhalb der EU bleiben aufgrund eines Angemessenheitsbeschlusses, Standardvertragsklauseln oder verbindlicher Unternehmensregeln zulässig.
• Datenlokalisierungsgesetze: Zu den Ländern mit Datenlokalisierungsanforderungen zählen: Russland (Bundesgesetz Nr. 152-FZ und obligatorische Lagerung) und China (PIPL/CSL für CIIOs), die möglicherweise einen Containereinsatz im Land erfordern. Indiens DPDP Act von 2023 verwendet einen Ansatz auf der schwarzen Liste, der kein allgemeines Speichermandat im Land vorschreibt. Datenübermittlungen sind in jedes Land zulässig, es sei denn, dies wird durch eine behördliche Benachrichtigung ausdrücklich eingeschränkt. Architekten müssen gebietsspezifische Vorschriften verstehen.
• Grenzüberschreitende Datenübertragungsmechanismen: Wenn eine multiregionale Bereitstellung erforderlich ist, die Daten jedoch grenzüberschreitend sein müssen, müssen Architekten SCCs, BCRs oder andere Rechtsübertragungsmechanismen implementieren.
• Compliance-Zertifizierungsausrichtung: Containerbereitstellungsregionen müssen mit Salesforce-Konformitätszertifizierungen übereinstimmen. Von FedRAMP autorisierte Arbeitslasten müssen in den USA regional bereitgestellt werden. Bei HITRUST-zertifizierten Integrationen müssen Sie überprüfen, ob die Bereitstellungsregion in einen aktiven HITRUST-Bescheinigungsumfang fällt.

Regionale Bereitstellungsentscheidungen sind Architektenverantwortungen, die sich direkt auf die Einhaltung gesetzlicher Vorschriften auswirken. Finanzteams können die Bereitstellung nur in den USA für SOX-gesteuerte Integrationen vorschreiben. Gesundheitsteams können HITRUST-zertifizierte Regionen für die Verarbeitung persönlicher Gesundheitsinformationen vorschreiben.

Container benötigen Zugriff auf Anmeldeinformationen, API-Schlüssel und Verschlüsselungsschlüssel. Architekten müssen Prozesse zur Verwaltung von Geheimnissen entwerfen, die die Offenlegung verhindern:

• Keine hartcodierten Geheimnisse: Betten Sie Anmeldeinformationen niemals in Anwendungscode oder Konfigurationsdateien ein, die in Containern bereitgestellt werden. Verwenden Sie plattformverwaltete Geheimnisspeicher.
• Plattformverwaltete geheime Injektion: Lösen Sie Geheimnisse zur Laufzeit aus dem verwalteten Shop der Plattform auf (anstatt sie im Dateisystem zu speichern) und markieren Sie Konfigurationswerte mit Anmeldeinformationen als geschützt, damit sie nicht in Protokollen oder in der Konsole angezeigt werden.
• Geheimnisrotation: Entwerfen Sie Integrationen, um rotierte Geheimnisse anmutig zu verarbeiten. Aktualisierungsmuster für OAuth-Token, Workflows zur Rotation von API-Schlüsseln und Änderungen am Datenbankkennwort dürfen keine Containerneubereitstellung erfordern.
• Zugriff auf Geheimnisse mit den geringsten Berechtigungen: Gewähren Sie Containern nur Zugriff auf die Geheimnisse, die für ihre Funktion erforderlich sind. Marketingintegrationen sollten nicht auf Anmeldeinformationen des Finanzsystems zugreifen, selbst wenn sie dieselbe Umgebung verwenden.

Offengelegte Geheimnisse sind allgemeine Integrationssicherheitsvorfälle. Architekten müssen Prozesse zur Verarbeitung von Geheimnissen entwerfen, die Codeüberprüfungen, Protokolle, Fehlermeldungen und Überwachungs-Dashboards überstehen, ohne dass Anmeldeinformationen verloren gehen.

Anwendungen an der Salesforce-Grenze generieren Überwachungsereignisse, die die Konformitätsprotokollierungsanforderungen erfüllen:

• Anforderungs-/Antwortprotokollierung: Protokolliert API-Anforderungen, Antworten und Weiterleitungsentscheidungen. Compliance-Teams verwenden diese Protokolle für Zugriffsüberprüfungen, um zu bestimmen, wer wann auf welche Daten zugegriffen hat.
• Fehler- und Ausnahmeprotokollierung: Erfasst Sicherheitsereignisse (z. B. Authentifizierungsfehler, Autorisierungsverweigerungen und ungültige Zertifikate) in den Protokollen des Containers. Die SIEM-Integration ermöglicht die Echtzeit-Sicherheitsüberwachung.
• Protokollaufbewahrungsrichtlinien: Architekten müssen Aufbewahrungszeiträume konfigurieren, die den gesetzlichen Anforderungen entsprechen. Diese Mindestwerte werden durch Verordnungen festgelegt, unterscheiden sich je nach Rahmen und ändern sich im Laufe der Zeit. Daher müssen sie aus einer gut gepflegten Compliance-Quelle abgeleitet werden, die jede Zahl anhand der geltenden Verordnung überprüft, statt Werte für die Hardcodierung zu verwenden.
• Protokollverschlüsselung und Zugriffssteuerungen: Auditprotokolle können sensible Metadaten enthalten. Protokolle müssen im Leerlauf verschlüsselt und nur für autorisiertes Sicherheits-/Compliance-Personal zugriffskontrolliert werden. Eine unzureichende Protokollierung verhindert die Untersuchung von Vorfällen und schlägt bei Compliance-Prüfungen fehl. Architekten müssen die Ausführlichkeit der Protokollierung (z. B. Leistungsauswirkungen und Speicherkosten) mit den Anforderungen der Compliance- und Sicherheitsuntersuchung abwägen.

Die Bedrohungsmodellierung muss Teil des Designs Ihrer Lösungen sein und nicht ein separater Schritt, der davor oder danach erfolgt. Sobald Sie über ein mögliches Design nachdenken müssen, müssen Sie dessen potenzielle Bedrohungen modellieren – und das Modell bei der Entwicklung des Designs erneut aufrufen, damit Sicherheit die Architektur formt, statt sie nachträglich einzubauen. Während Salesforce die Infrastruktursicherheit verwaltet (z. B. Netzwerkschutz, OS-Härtung und Schwachstellenverwaltung), müssen Sie in Ihrer Konfiguration, Ihren Integrationen und Ihrem benutzerdefinierten Code Risiken auf Anwendungsebene identifizieren. Wenden Sie das STRIDE-Framework (Spoofing, Manipulation, Ablehnung, Offenlegung von Informationen, Denial of Service, Erhöhung der Berechtigung) auf die unten aufgeführten Salesforce-spezifischen Bedrohungsvektoren an. Identifizieren Sie Trust Grenzen, wenn Daten Systeme, Netzwerke oder Berechtigungsebenen überschreiten.

Wenden Sie das STRIDE-Framework auf die folgenden Salesforce-spezifischen Überlegungen zur Bedrohungsmodellierung an:

• Multi-Organisationsdatenflüsse erstellen zusätzliche Trust Grenzen, die bei jeder Überschreitung eine explizite Authentifizierung und Autorisierung erfordern.
• Externe Integrationen verwenden APIs und Middleware, wodurch potenziell Angriffsvektoren eingeführt werden, die die Plattformsicherheitssteuerungen umgehen.
• Benutzerdefinierte Apex und Lightning erfordern sichere Codierungsanalysen für die Erzwingung von Injection, XSS und Zugriffssteuerung.
• Experience Cloud-Sites erweitern die Angriffsfläche auf nicht oder nur geringfügig authentifizierte Benutzer.
• Bei Drittanbieter- und ISV-Code (z. B. verwaltete Pakete, AgentExchange-Auflistungen, verbundene Anwendungen, Drittanbieter-Konnektoren, clientseitige JavaScript-Bibliotheken und die von Ihren Agenten aufgerufenen externen AI-Services) handelt es sich um einen Lieferkettenvektor, der zur Installationszeit oder zur Laufzeit die Trust-Grenze überschreitet.

Drittanbieter- und ISV-Code sind Teil Ihrer Trust Boundary.

Verwaltete Pakete oder AgentExchange-Auflistungen werden in Ihrer Organisation mit den Berechtigungen ausgeführt, die Sie ihnen erteilen, sodass ihr Sicherheitsstatus sofort nach der Installation zu Ihrem Sicherheitsstatus wird. Die Salesforce-Sicherheitsüberprüfung überprüft jedes aufgeführte Paket, bevor es AppExchange oder AgentExchange erreicht. Ihnen gehört nach diesem Gate alles:

• Bewerten des Pakets anhand Ihrer eigenen Datenklassifizierung und Risikoposition
• Gewähren der geringsten Anzahl an Berechtigungen, die für die dokumentierte Funktion erforderlich sind
• Aktualisieren mit den Publisher-Versionen
• Überwachen Sie die Aktivität über dieselben Ereignisüberwachungs- und Überwachungssteuerungen, die Sie auf Ihren eigenen Code anwenden.

Wenden Sie Sicherheitssteuerungen auf jeder Ebene des Lösungsstapels an. Beachten Sie, dass der Kompromiss einer Ebene nicht das gesamte System offenlegen darf.

Gestalten Sie jede Ebene so, als ob die Ebenen oben und unten fehlschlagen könnten. Denken Sie daran, dass mehrere unabhängige Steuerelemente Resilienz schaffen.

Zero Trust eliminiert impliziten Trust basierend auf der Netzwerkposition oder dem vorherigen Authentifizierungsstatus. Jede Anforderung muss unabhängig authentifiziert und autorisiert werden.

Wenden Sie Zero Trust auf Folgendes an:

• Benutzerzugriff durch kontinuierliche Überprüfung mit MFA, Sitzungsrichtlinien und kontextbasiertem bedingtem Zugriff (z. B. IP, Gerät, Uhrzeit und Verhalten)
• Integrationsverbindungen über die OAuth-Tokenvalidierung bei jedem Aufruf, zertifikatsbasiertes gegenseitiges TLS und IP-Zulassungslisten
• Systemübergreifende Kommunikation durch explizite Authentifizierung, die auch für vertrauenswürdige interne Systeme gilt
• Datenzugriff über CRUD- und FLS-Erzwingung bei jeder Abfrage und jedem Vorgang unabhängig vom Aufrufkontext

Das Sicherheitsvermögenswert-Inventar ist eine Eingabe für das Sicherheitsdesign: Sie können nur Bedrohungsmodelle erstellen, die geringsten Berechtigungen auf eine Angriffsfläche anwenden und sie überwachen, die Sie zuerst aufgezählt haben. Daher gehört das Verfolgen Ihrer sicherheitsrelevanten Vermögenswerte zu den Designentscheidungen, die davon abhängen. Dies unterscheidet sich von der Betriebskonfigurationsverwaltung, die Operational Excellence abdeckt (z. B. Versionierung der Organisationseinstellungen und Erkennung der Konfigurationsabweichung für die Betriebsstabilität). Anders ausgedrückt, die Sorge ist hier enger: Welche Vermögenswerte bergen Sicherheitsrisiken und warum?

Verwalten Sie ein aktuelles Inventar aller sicherheitsrelevanten Vermögenswerte, einschließlich benutzerdefinierter Objekte, in denen sensible Daten gespeichert werden, externer Systemintegrationen, öffentlicher APIs, privilegierter Accounts, Produktionszugriffsgewährungen und installierter Pakete mit erhöhten Berechtigungen.

Ihr Sicherheitsvermögenswert-Inventar sollte Folgendes enthalten:

• Benutzerdefinierte Objekte und Felder mit vertraulichen oder eingeschränkten Daten
• Integrationsendpunkte und Authentifizierungsmechanismen
• Benutzer mit erhöhten Berechtigungen (z. B. "Alle Daten modifizieren", "Alle Daten anzeigen" und "Benutzer verwalten")
• Nur API-Integrationsbenutzer und ihre Berechtigungsbereiche
• Externe Client-Anwendungen (Externe Client-Anwendungen, ECA) und ihre OAuth-Geltungsbereiche sowie alle älteren verbundenen Anwendungen, die noch in der Organisation vorhanden sind
• Installierte AgentExchange-Pakete und ihre Berechtigungsgewährungen
• Experience Cloud-Sites und ihre Authentifizierungs- und externen Freigabemodelle
• Benutzerdefinierte Apex Klassen mit erhöhten Freigabemodi
• Achten Sie besonders auf ältere Klassen: Code, der in API-Version 66.0 oder früher kompiliert wurde und bei dem eine Freigabedeklaration ausgelassen wird, standardmäßig auf "ohne Freigabe" festgelegt ist (z. B. Systemmodus unter Umgehung des Datensatzzugriffs des aktuellen Benutzers). Beachten Sie, dass ab API-Version 67.0 (Summer '26) eine ausgelassene Deklaration stattdessen standardmäßig auf "with sharing" festgelegt ist und Datenbankvorgänge im Benutzermodus ausgeführt werden. Vorhandene Klassen behalten jedoch das alte Verhalten bei, bis sie in Version 67.0 (oder höher) neu kompiliert werden. Daher werden nicht deklarierte Klassen, die aus früheren Versionen übernommen wurden, stillschweigend erhöht.

Es liegt in Ihrer Verantwortung, Identitätskontrollen zu entwerfen und zu konfigurieren, die die geringsten Berechtigungen erzwingen.

Sehen wir uns einmal genauer an, wie Steuerelemente mithilfe der PoLP ordnungsgemäß entworfen und konfiguriert werden.

Salesforce erzwingt die Zugriffssteuerung über vier verschiedene Ebenen: Organisation, Objekt, Feld und Datensatz. Sie müssen Lösungen entwickeln, die alle vier Ebenen bewusst nutzen. Die zentrale Zugriffssteuerung ist erteilungsbasiert, d. h., der Zugriff ist additiv und Benutzer müssen ihn auf jeder Ebene erteilen lassen, um einen Datensatz zu erreichen. Es gibt keine allgemeine Regel vom Typ "Überschreibungen verweigern – zulassen" auf der zentralen Plattform. Daher können Sie nicht gezielt ablehnen, um den Zugriff auf eine bereits erteilte umfassende Zuwendung rückgängig zu machen.

Obere Ebenen kosten keine Einschränkungen, erhöhen jedoch den Aufwand: Wenn Sie organisationsweite Standardeinstellungen oder Objektberechtigungen frühzeitig erweitern, müssen Sie sich auf die Feldebenensicherheit und die Freigabekonfiguration verlassen, um den Zugriff zurückzudrängen, der niemals hätte erteilt werden dürfen.

Einschränkungsregeln und Stummschaltungsberechtigungen sind zwei integrierte Ausnahmen, die den Zugriff subtrahieren, aber jeweils eng begrenzt sind – Einschränkungsregeln zum Filtern auf Datensatzebene und Stummschalten auf Berechtigungen, die innerhalb einer Berechtigungssatzgruppe gewährt werden – und keine generalisierte Ablehnungsebene.

Legen Sie OWDs für Objekte mit sensiblen Daten auf "Privat" fest. Durch das Öffnen von OWDs für "Öffentlicher Lesezugriff" – geschweige denn "Öffentlicher Lese-/Schreibzugriff" – werden Datensätze allgemein verfügbar gemacht und Ihre Fähigkeit, den Zugriff später einzuschränken, wird untergraben, ohne dass es zu einer signifikanten Rückarchitektur kommt. Die häufigsten Trust Debts in ausgereiften Organisationen stammen aus den bei der ersten Implementierung festgelegten zulässigen Einmalkennwörtern.

Die Datensatzebene folgt einem Modell zur Gewährung und Einschränkung, das häufig als Freigabepyramide dargestellt wird: OWDs legen die restriktive Grundlage fest und Rollenhierarchie, Freigaberegeln und manuelle Freigabe öffnen den Zugriff von dort aus nach oben. Zwei Steuerelemente kehren diesen Flow um, um ihm den Zugriff zu entziehen, statt ihn zu erteilen, und beide sollten bewusst gestaltet werden.

• Einschränkungsregeln filtern, was Benutzern in Datensätzen angezeigt werden kann, auf die sie bereits zugreifen können. Daher wird Benutzern mit breitem Objektzugriff weiterhin nur die Teilmenge angezeigt, die eine Regel zulässt.
• Stummschaltungsberechtigungen subtrahieren bestimmte Berechtigungen innerhalb einer Berechtigungssatzgruppe, sodass Sie den Zugriff aus wiederverwendbaren Gruppen zusammenstellen und dann entfernen können, was eine bestimmte Population nicht haben sollte.
• Greifen Sie auf diese Regeln zu, wenn Sie allein durch genehmigungsbasierte Ebenen gezwungen wären, den Zugriff entweder zu übermäßig bereitzustellen oder in viele enge Berechtigungssätze zu fragmentieren.

Erzwingen Sie die Multi-Faktor-Authentifizierung (MFA) für alle Benutzer, die sich über die Benutzeroberfläche bei Produktionsumgebungen anmelden, die Salesforce als Plattformanforderung vorschreibt. Diese Anforderung gilt nicht für den reinen API-Zugriff: Integrationen, die Flows vom Typ "JWT-Bearer" oder "Client-Anmeldeinformationen" verwenden, sind ausgenommen. Daher müssen Sie diese Integrationen stattdessen durch Zertifikatsverwaltung und IP-Einschränkungen schützen. Erweitern Sie die MFA-Anforderungen auf privilegierte Vorgänge.

Für SSO (Single Sign-On) werden SAML 2.0- oder OpenID Connect-Protokolle bevorzugt. Konfigurieren Sie Sitzungsrichtlinien, um Sicherheit und Benutzerfreundlichkeit in Einklang zu bringen:

• Sitzungs-Timeout: Konfigurieren Sie Sitzungs-Timeouts entsprechend den Benutzerberechtigungsebenen (kürzere Timeouts für Accounts mit hohen Berechtigungen reduzieren die Risiken unbeaufsichtigter Sitzungen).
• IP-Einschränkungen: Erzwingen Sie Einschränkungen für Verwaltungsprofile und Integrationsbenutzer.
• Anmeldezeiten: Schränken Sie Serviceaccounts auf die erwarteten Betriebszeitfenster ein.
• Geräteaktivierung: Setzen Sie auf die native Geräteaktivierung von Salesforce (Identitätsüberprüfung für Anmeldungen von nicht erkannten Geräten) und fügen Sie MFA- und IP-Einschränkungen für Accounts mit hohen Rechten hinzu. Der native Device Trust wird über einen externen Identitätsanbieter erzwungen.
• IP-Sperrung für Sitzungen: Sperren Sie Sitzungen mit der IP-Adresse, von der sie stammen, damit eine gestohlene Sitzungs-ID nicht von einem anderen Netzwerkstandort aus wiedergegeben werden kann. Dies erhöht die Sicherheit, erhöht jedoch die Reibung für mobile Benutzer und kann automatisierte Integrationen beeinträchtigen. Wenn eine Sperrung nicht möglich ist, erzwingen Sie strenge Anmelde-IP-Bereiche auf Profilebene mit "Anmelde-IP-Bereiche bei jeder Anforderung erzwingen" als Ausgleichssteuerung.
• Sitzungen mit hoher Sicherung: Legen Sie über "Richtlinien auf Sitzungssicherheitsebene" und "Zugriffsrichtlinien" eine Sitzungssicherheitsebene mit hoher Sicherung für sensible Vorgänge (z. B. den Zugriff auf Berichte oder das Verwalten von IP-Bereichen) fest, damit eine Routineanmeldung allein keine Aktionen mit großen Auswirkungen erreichen kann. In Lightning Experience wird das Hochstufen einer Standardsitzung auf "Hohe Sicherung" durch erneute Aufforderung zur Multi-Faktor-Authentifizierung nicht unterstützt. Daher sollten Sie diese Richtlinie anwenden, da Sie wissen, dass Benutzer von Standardsitzungen nicht zum Hochstufen aufgefordert werden, sondern vom Vorgang mit Toren blockiert werden.
• Schutz von Sitzungscookies: Erzwingen Sie das Attribut HttpOnly, damit Skripts das Sitzungs-ID-Cookie nicht lesen können, und sperren Sie Sitzungen in der Domäne, in der sie erstmals verwendet wurden, um Sitzungs-Hijacking abzustumpfen.
• Nur API-Zugriff für Integrationsbenutzer: Schränken Sie Integrations- und Serviceaccounts mit der Berechtigung "Nur API-Benutzer" auf die reine API-Authentifizierung ein, sodass sie sich nicht über die Benutzeroberfläche anmelden können. Weisen Sie bei neuen Builds das Profil "Minimum Access – API Only Integrations" (Mindestzugriff – Nur API-Integrationen) mit der Salesforce-Integrationsbenutzerlizenz zu. Das ältere Profil "Salesforce API Only Systems Integration" (Nur Salesforce-API-Systemintegration) ist in Organisationen, die ab der Version Spring '24 bereitgestellt werden, nicht verfügbar. Entwerfen Sie daher neue Integrationen anhand des aktuellen Profils und nicht anhand des veralteten Profils.

Wählen Sie für die API-Authentifizierung die für das Integrationsmuster geeigneten OAuth 2.0-Flows aus:

• JWT-Bearer-Flow: Verwenden Sie dies für Server-zu-Server-Integrationen, die als Integrationsbenutzer ausgeführt werden (zertifikatsbasiert, für vertrauenswürdige Umgebungen bevorzugt).
• Webserver-Flow (Autorisierungscode, mit PKCE): Verwenden Sie dies für Webanwendungen, für die eine Benutzerautorisierung erforderlich ist, und für Server-zu-Server-Integrationen, bei denen ein bestimmter Benutzerkontext beibehalten werden muss (Speichern von Aktualisierungstoken auf der Serverseite, um wiederholte Browseraufforderungen zu vermeiden).
• Gewährleisten der erneuten Wiedergabe von Autorisierungscode-Flows: Erzwingen Sie PKCE, damit ein abgefangener Autorisierungscode nur von dem Client eingelöst werden kann, der ihn angefordert hat, und rotieren Sie Aktualisierungstoken, die bei jeder Verwendung ein neues ausstellen und das vorherige ungültig machen, sodass ein gestohlenes Aktualisierungstoken ein enges Gültigkeitszeitfenster aufweist. Die Wiederverwendung eines eingestellten Tokens signalisiert Kompromisse.
• Flow für Headless-Identitätsautorisierungscode und Anmeldeinformationen (mit PKCE): Verwenden Sie dies für Clients ohne Headless, die im Kontext eines bestimmten Benutzers ausgeführt werden müssen. Der umleitungsbasierte Webserver-Flow geht von einem Browser aus, über den diese Clients nicht verfügen.
• Geräte-Flow (für Headless-Geräte): Beachten Sie, dass Salesforce seit dem 28. August 2025 den OAuth 2.0-Geräte-Flow für die standardmäßige verbundene Salesforce CLI dauerhaft blockiert hat. Verwenden Sie stattdessen den Webserver-Flow (sf org login web) oder den JWT Bearer Flow (sf org login jwt) für CLI- und CI/CD-Tools.

Verwenden Sie nicht den Flow für Benutzername und Kennwort. Salesforce hat sie standardmäßig für Organisationen blockiert, die in der Version Summer '23 oder höher erstellt wurden, und Einstellungspläne für diesen Flow veröffentlicht. Vorhandene Integrationen, die weiterhin auf dem Flow für Benutzername und Kennwort basieren, sollten jetzt zum JWT-Bearer-Flow oder zum Flow für Client-Anmeldeinformationen migriert werden, statt die Migration als zurückgestellte technische Schulden zu behandeln.

Diese Flows werden in der Anwendungsregistrierung konfiguriert, die Ihre Integration darstellt. Ab der Version Spring '26 verschiebt Salesforce diese Registrierung von "Verbundene Anwendungen" auf "Externe Client-Anwendungen": Das Erstellen neuer verbundener Anwendungen ist standardmäßig deaktiviert und der Europäische Rechnungshof ist das Konstrukt, anhand dessen neue Integrationen entworfen werden können. Vorhandene verbundene Anwendungen bleiben installiert. Sobald eine Organisation jedoch migriert wurde, verarbeitet sie die Authentifizierung nicht mehr. Berücksichtigen Sie daher die Migration, wenn Sie überprüfen, wie Integrationen sich authentifizieren, statt verbundene Anwendungen als dauerhaftes Modell zu behandeln.

Erstellen Sie zusätzlich zur Auswahl eines Authentifizierungs-Flows eine unterschiedliche Governance, für die Anwendungen eine Verbindung herstellen können:

• Eine Registrierung pro Integration: Registrieren Sie für jede neue Integration eine dedizierte externe Client-Anwendung und für jede vorhandene eine eigene verbundene Anwendung. Eine spezielle Registrierung beschränkt sich nur auf die OAuth-Geltungsbereiche, die für jede Integration erforderlich sind, statt eine allgemeine Registrierung für viele freizugeben, sodass der Zugriff jeder Integration unabhängig überprüfbar und widerruflich bleibt.
• Zugriff explizit vorab autorisieren (empfohlen): Legen Sie die Richtlinie "Zulässige Benutzer" der externen Client-Anwendung auf "Vom Administrator genehmigte Benutzer sind vorab autorisiert" fest, damit ein Administrator den Zugriff über Profile und Berechtigungssätze erteilt, statt Benutzern die Selbstautorisierung zu ermöglichen. Administratoren konfigurieren dies direkt unter "Setup" und Salesforce empfiehlt die Steuerung, um zu bestimmen, wer eine Verbindung herstellen kann.
• API-Zugriffssteuerung (strenger, zulassungslistenbasiert): Bei strengeren Steuerelementen beschränkt die API-Zugriffssteuerung vom Administrator genehmigte Benutzer nur auf verbundene Anwendungen auf der Zulassungsliste. Wenn Sie sie aktivieren möchten, müssen Sie den Salesforce-Kundensupport anfordern. Planen Sie diesen Schritt daher ein, wenn Sie ihn umgehen, statt ihn als Self-Service-Einstellung zu behandeln.

Betten Sie Anmeldeinformationen niemals in Code, Konfigurationsdateien oder Versionskontrolle ein. Verwenden Sie Anmeldeinformationen mit Namen und externe Anmeldeinformationen, um die Authentifizierung zentral mit Rotationsfunktionen zu verwalten.

Im Gegensatz zur herkömmlichen Benutzerauthentifizierung benötigen Agenten unterschiedliche Identitätsmodelle und das richtige Modell hängt davon ab, ob der Agent Mitarbeiter oder externe Benutzer bedient. Das richtige Entwerfen der Identität ist die Grundlage für die Agentensicherheit: Sie bestimmt, auf welche Daten der Agent zugreifen und welche Aktionen der Agent erreichen kann.

Sehen wir uns interne und externe Agenten genauer an. nts.

• Mitarbeiteragenten (intern): Führen Sie Aufgaben im Kontext des angemeldeten Benutzers aus. Sie übernehmen dessen Lizenzen, Berechtigungssätze, Feldebenensicherheit und Freigaberegeln, sodass keine separate Agentenidentität bereitgestellt wird und das vorhandene Sicherheits-Framework regelt, was der Agent tun kann.
• Kundenagenten (extern): Interagieren Sie über öffentliche Kanäle und führen Sie sie als dedizierte Agentenbenutzer und nicht als Gastbenutzer der öffentlichen Site aus. Wenn der Agent als dedizierter Integrationsbenutzer ausgeführt wird, kann er Backend-Aktionen ausführen und auf Daten zugreifen (was für nicht authentifizierte Gastprofile nicht möglich ist), ist jedoch weiterhin an explizite Berechtigungen mit den geringsten Berechtigungen gebunden. Wenn Sie einen Kundenagenten erstellen, erteilen Sie einem neuen Agentenbenutzer minimalen Zugriff und erteilen Sie ihm nur die spezifischen Berechtigungen, die für seine Aktionen erforderlich sind.

Wenn sich die Arbeit eines Agenten auf mehrere Services erstreckt, sollten Sie die Identität des Benutzers für jeden Service-Hop übernehmen, statt auf eine freigegebene Identität oder eine Gastidentität zurückzugreifen. Der Salesforce OAuth 2.0-Tokenaustausch-Flow unterstützt Folgendes:

Ein Client stellt das vorhandene Identitätsanbieter-Token des Benutzers dar und ein Apex Token-Austausch-Handler ordnet es einem Salesforce-Benutzer zu und stellt ein Salesforce-Zugriffstoken aus. Auf diese Weise folgt der Kontext des ursprünglichen Benutzers der Anforderung, statt ihn auf einen Serviceaccount auszublenden. Überwachen Sie die Agentenaktivität über die Ereignisüberwachung, indem Sie die Benutzeridentität des Agenten verwenden, um anormales Verhalten zu erkennen.

Die Auswahl des richtigen Modells hängt davon ab, wer die Verbindung initiiert und in welchem Kontext die Arbeit ausgeführt werden muss.

Allgemeine Verbindungsszenarien werden empfohlenen Ansätzen wie folgt zugeordnet:

Entwerfen Sie Rollenhierarchien zu Anforderungen an den Datenzugriff (die Benutzer benötigen Zugriff auf Datensätze, deren Inhaber andere Benutzer sind) – nicht zum Berichtsdiagramm der Verwaltung. Lassen Sie die Rollenhierarchietiefe echten Datenzugriffsbeziehungen folgen, statt Ebenen hinzuzufügen, die keinen zusätzlichen Zugriff erteilen, da jede Ebene den Aufwand für die Freigabeberechnung erhöht – eine Überlegung, die in Organisationen mit Einstellungen für privates Einmalkennwort und großen Datenvolumen mehr Gewicht hat.

Berechtigungssätze und Berechtigungssatzgruppen reduzieren die Notwendigkeit der Profilvermehrung, indem sie flexiblen, additiven Zugriff bieten. Gewähren Sie funktionalen Zugriff über Berechtigungssätze und Berechtigungssatzgruppen anstelle von Profilen, wodurch der Zugriff additiv und überprüfbar bleibt. Profile bleiben weiterhin erforderlich: Sie steuern neben Anmeldezeiten und IP-Einschränkungen die Seitenlayoutzuweisung, die Standardeinstellungen für Datensatztypen und die Sichtbarkeit der Anwendung. Behandeln Sie Profile als dauerhaften Teil des Zugriffsmodells und nicht als zu beseitigendes Konstrukt.

Transaktionssicherheitsrichtlinien sind nicht Teil der Grundlage, sondern eine Add-On-Funktion, die das zentrale Autorisierungsmodell ergänzt: Die oben genannten Identitäts-, Rollen-, Profil-, Berechtigungssatz- und Freigabesteuerelemente richten bereits einen sicheren Autorisierungsstatus ein und die Transaktionssicherheit fügt obendrein eine kontextbezogene Echtzeitauswertung hinzu. Konfigurieren Sie Richtlinien, um anormales Verhalten zu erkennen und zu blockieren, einschließlich Massendaten-Downloads, die normale Muster überschreiten, Anmeldungen aus unerwarteten geografischen Regionen und Berechtigungsänderungen außerhalb von Änderungsfenstern.

Sicherheitskontrollen beinhalten Kompromisse bei der Verfügbarkeit, die eine architektonische Verantwortung darstellen. Eine zu umfassende IP-Einschränkung kann legitime Benutzer während einer Netzwerkänderung aussperren und eine zu aggressiv abgestimmte Transaktionssicherheitsrichtlinie kann gültige Geschäftsaktivitäten blockieren. Daher sollten Sie diese Steuerelemente auf ein echtes Risiko beschränken, sie vor der Erzwingung im Nur-Monitor-Modus in Szene setzen und einen gläsernen Pfad für den Fall entwerfen, dass ein Steuerelement ausbricht.

Ihre Verantwortung: Entwerfen Sie Rollenhierarchien, erstellen Sie Berechtigungssätze und konfigurieren Sie Transaktionssicherheitsrichtlinien.

Traditionelle rollenbasierte Zugriffssteuerung) gewährt Berechtigungen basierend auf der Rolle eines Benutzers. ABAC (attributbasierte Zugriffssteuerung) trifft Autorisierungsentscheidungen anhand der Attribute der Daten, des Benutzers und des Kontexts.

Bei den meisten Anforderungen drückt das zentrale Freigabemodell den Zugriff vollständig aus. Wenden Sie sich an die dedizierte ABAC, wenn der Zugriff der Datenklassifizierung folgen muss, die die Freigabe pro Datensatz nicht ausdrücken kann: Data 360 ABAC bietet dies durch Tags und Anmerkungen.

Data 360 ABAC funktioniert wie folgt:

• Tag-basierte Richtlinien, die Zugriffsregeln auf der Grundlage von Tags definieren, die auf Datenobjekte angewendet werden (z. B. "Persönlich identifizierbare Informationen", "Finanzwesen", "Gesundheitswesen" und "Vertraulich").
• Anmerkungen werden auf Datenobjekte angewendet, um richtlinienbasierte Autorisierungsentscheidungen zu unterstützen.
• Standardrichtlinie "Alle zulassen" für neue und vorhandene Organisationen, die explizit gelöscht werden müssen, um Richtlinien für die genaue Verwaltung zu aktivieren.

Seine primäre architektonische Verwendung besteht in der Erzwingung der Datenklassifizierung. Informationen dazu, wie Klassifizierungsklassen die Erzwingung von ABAC vorantreiben, finden Sie unter "Datenschutz und Datenschutz" unter "Datenklassifizierung".

Diese Granularität ist mit Betriebskosten verbunden. Mit der Kernfreigabe wird die Frage beantwortet: "Wer kann diesen Datensatz anzeigen und warum?" aus einem kleinen, inspizierbaren Satz von Regeln (OWDs, Rollenhierarchien und Freigaberegeln), während ABAC seine Antworten zum Zeitpunkt der Auswertung aus der Kombination von Daten-Tags, Benutzerattributen und Kontext ableitet, sodass effektiver Zugriff schwieriger zu verstehen und zu überprüfen ist, da sich Richtlinien und Tags häufen.

Erzwingen der Überprüfbarkeit als Designanforderung: Wenden Sie Tags konsistent an, halten Sie den Richtliniensatz klein und benennen Sie ihn für die von ihm erzwungene Klassifizierung und behalten Sie die Möglichkeit, zu rekonstruieren, warum ein Benutzer einen bestimmten Datensatz erreicht hat. Reservieren Sie ABAC für klassifizierungsgesteuerte Kundenvorgänge, die die Freigabe pro Datensatz nicht wirklich ausdrücken kann, statt sie als allgemeinen Ersatz für das inhaberbasierte Modell zu behandeln.

Identifizieren und schützen Sie Accounts mit erhöhten Berechtigungen, einschließlich Systemadministratoren, Integrationsbenutzern und Accounts für automatisierte Prozesse. Diese Accounts sind Ziele von hohem Wert für Angreifer.

Wenden Sie erweiterte Steuerelemente auf Accounts mit kritischen Auswirkungen an.

• Phishing-resistente MFA erforderlich
• IP-Bereiche für die Anmeldung auf bekannte Verwaltungsstandorte beschränken
• Aktivieren von Anmeldebenachrichtigungen und Benachrichtigungen zu Berechtigungsänderungen
• Durchführen von regelmäßigen Zugriffsüberprüfungen mit dokumentierter Bescheinigung für Accounts mit hohem Recht, bei denen die Häufigkeit durch die Organisationsrisikotoleranz und die Compliance-Anforderungen bestimmt wird
• Beibehalten von Bruchglasverfahren für Notfallzugriff und Überprüfung nach der Verwendung

Für Integrations- und Serviceaccounts:

• Anwenden von OAuth-Flows; niemals Flows mit Benutzername und Kennwort
• IP-Einschränkungen erzwingen
• Implementieren von Rotationsplänen für Anmeldeinformationen
• Überwachen auf anomale API-Nutzungsmuster durch Ereignisüberwachung

Ihre Verantwortung: Identifizieren Sie wichtige Accounts, wenden Sie erweiterte Kontrollen an und führen Sie vierteljährliche Überprüfungen durch.

Entwerfen Sie automatisierte Prozesse, um Benutzern den entsprechenden anfänglichen Zugriff zu erteilen, Berechtigungen an die Entwicklung von Rollen anzupassen und die Bereitstellung umgehend aufzuheben, wenn der Zugriff nicht mehr erforderlich ist.

Implementieren Sie ein System für Cross-Domain Identity Management (SCIM) für die automatisierte Bereitstellung von Identitätsanbietern. Bei der Just-in-Time-Bereitstellung in SAML oder OpenID Connect handelt es sich um eine Alternative, die einen Benutzer bei der ersten Anmeldung erstellt, die Bereitstellung jedoch nicht rückgängig macht. Mit anderen Worten: SCIM ist das Rückgrat des Lebenszyklus und keine Entscheidung gegen ihn.

Der Identitätslebenszyklus umfasst Folgendes:

• Bereitstellung: Erstellen Sie Accounts mit Basiszugriff, der der Auftragsfunktion entspricht, die durch HR-Systemereignisse ausgelöst wird.
• Zugriffsanpassungen: Gewähren Sie zusätzliche Berechtigungen, wenn Rollen erweitert werden, und widerrufen Sie Berechtigungen, wenn sich Rollen ändern.
• Referenzielle Neuzertifizierung: Überprüfen und validieren Sie den Zugriff vierteljährlich.
• Deprovisionierung: Widerrufen Sie den Zugriff sofort, wenn die Beschäftigung endet oder Rollen keinen Salesforce-Zugriff mehr erfordern.

Implementieren Sie Prozesse zur Neuzertifizierung von Zugriffen, wenn Manager die Berechtigungen ihrer Teams regelmäßig überprüfen und validieren. Die Überprüfungshäufigkeit basiert auf Risiko- und Compliance-Anforderungen.

Ihre Verantwortung: Implementieren Sie SCIM, entwerfen Sie Bereitstellungs-Workflows und führen Sie eine vierteljährliche Neuzertifizierung durch.

Die Trennung von Daten in mehrere Organisationen wird manchmal nur als Kosten- oder Aufenthaltsentscheidung angesehen. Architektonisch gesehen handelt es sich um einen Kompromiss hinsichtlich der Sicherheit und die Governance-Konsequenzen gehören zu Ihrem Zugriffsdesign.

Isolation ist der entscheidende Vorteil. Separate Organisationen bieten die stärkste Grenze zwischen Datensets. Es gibt kein kollektives Freigabemodell und keinen mandantenübergreifenden Berechtigungsschnitt, aber es gibt eine klare regulatorische Linie für Rechtsordnungen, die eines erfordern. Dieselbe Grenze fragmentiert die Verwaltung. Alle Zugriffssteuerungen, die Sie nur einmal in einer einzelnen Organisation verwalten müssen (z. B. Berechtigungssatzdesign, Rollenhierarchie, Verhärtung wichtiger Auswirkungen auf Accounts, Grundlagen der Integritätsprüfung, Ereignisüberwachung und SIEM-Korrelation), werden nun pro Organisation multipliziert, d. h., sie müssen konsistent in allen sein. Der Wechsel zwischen Organisationen führt zu einer eigenen Angriffsfläche, da eine Berechtigung, die in einer Organisation verschärft und in einer anderen verpasst wurde, zu einer Inkonsistenz führt, die Angreifer finden und ausnutzen können. Organisationsübergreifende Integrationen fügen Grenzen für authentifizierte Trusts hinzu, die zuvor nicht vorhanden waren. Jede organisationsübergreifende Integration ist eine Verbindung, die Sie schützen und überwachen müssen.

Daher ist es wichtig, den Isolationsvorteil vor der Aufteilung einer Organisation mit dem Governance-Multiplikator abzuwägen. Reservieren Sie mehrere Organisationen für Fälle, in denen ein hartes Lokalisierungsmandat oder die vertragliche Isolationsanforderung eines Kunden in einer einzelnen Organisation nicht erfüllt werden kann. Wenn Sie sie übernehmen, müssen Sie das Zugriffsmodell, die Überwachung und die Konfigurationsgrundlagen so entwerfen, dass sie von Anfang an in jeder Organisation identisch erzwungen werden.

Ihre Verantwortung: Behandeln Sie eine Entscheidung mit mehreren Organisationen als Sicherheitsrisiko, nicht nur als Kostenfaktor. Wenn mehrere Organisationen erforderlich sind, erzwingen Sie die Zugriffssteuerungen, die Überwachung und die Grundlagen der Integritätsprüfung konsistent in jeder Organisation und schützen Sie jede organisationsübergreifende Integration als Trust Grenze.

Es liegt in Ihrer Verantwortung, Daten zu klassifizieren, die Verschlüsselung zu konfigurieren und Datenschutzeinstellungen zu entwerfen.

Sehen wir uns einmal genauer an, wie Sie Daten und Datenschutz richtig schützen können.

Damit Sie Ihre Daten richtig klassifizieren können, müssen Sie Ihre Daten kennen. Die übergreifende architektonische Aufgabe besteht darin, Ihre Geschäftsdomäne zu verstehen und ein Datenwörterbuch zu verwalten, das katalogisiert, welche Daten Sie besitzen, was sie bedeuten und wo sich sensible Daten befinden. Sie können nur Daten klassifizieren oder schützen, die Sie zuerst identifiziert haben.

Richten Sie ein Datenklassifizierungsschema ein, das geeignete Schutzsteuerungen steuert. Eine Klassifizierungsbezeichnung schützt nichts allein. Sie ist die Eingabe für die Steuerelemente, die Sie anwenden. Daher muss jede von Ihnen zugewiesene Klassifizierung einer konkreten Verschlüsselungs-, Zugriffs-, Aufbewahrungs- oder Überwachungsentscheidung zugeordnet werden. Klassifizierungsentscheidungen, die während der Datenmodellierung getroffen werden, wirken sich direkt auf Verschlüsselungsanforderungen, Zugriffssteuerungen, Aufbewahrungsrichtlinien und Compliance-Verpflichtungen aus.

Bei Salesforce wird ein vierstufiges Schema verwendet, das einen Rahmen bietet, den Sie an die regulatorischen Anforderungen und Geschäftsanforderungen Ihrer Organisation anpassen können. Viele Unternehmen verwenden ähnliche Modelle, die sich an Branchenstandards orientieren (z. B. ISO 27001 und NIST). Ihre spezifische Implementierung sollte Ihre Compliance-Verpflichtungen (z. B. HIPAA, PCI DSS, DSGVO und Branchenvorschriften) und Ihren Geschäftskontext berücksichtigen.

Wenden Sie die Klassifizierung auf Feldebene an. Ein einzelner Accountdatensatz kann öffentliche Felder (z. B. Unternehmensnamen), vertrauliche Felder (z. B. Unternehmensumsatz) und eingeschränkte Felder (z. B. Sozialversicherungsnummern) enthalten. Die Feldebenensicherheit muss diese Unterschiede widerspiegeln.

Die Klassifizierung kann durch die attributbasierte Zugriffssteuerung erzwungen werden, die die von Ihnen zugewiesenen Tags liest und Zugriffsregeln anwendet. Hierbei handelt es sich um eine metadatengesteuerte Ebene, die OWD- und Freigaberegeln ergänzt.

Durch die Abstimmung von ABAC auf Ihr Klassifizierungsschema kann die Plattform:

• Schränken Sie den Zugriff auf Daten, die als eingeschränkt oder vertraulich gekennzeichnet sind, über die Klassifizierung selbst ein und nicht über eine Freigaberegel, die pro Objekt verwaltet wird.
• Passen Sie den Zugriff an, wenn sich die Klassifizierung eines Datensatzes im Laufe der Zeit ändert. Ein Datensatz, der neu als reguliert gekennzeichnet wurde, übernimmt einen strengeren Zugriff ohne manuelle Regeländerung.
• Kombinieren Sie Datenattribute (z. B. Klassifizierung und Vertraulichkeit) mit Benutzerattributen (z. B. Abteilung und Freigabe) und Kontext (z. B. Uhrzeit und Standort) in einer einzigen Autorisierungsentscheidung.

Entwerfen Sie ABAC-Richtlinien, die an dieses Schema angepasst sind, sodass die Klassifizierung eines Felds als Eingeschränkt die Handlung ist, die seine Zugriffskontrollen steuert und die Erzwingung an der Klassifizierung verankert hält, statt Freigaberegeln separat zu verwalten.

Ihre Verantwortung: Definieren Sie ein Klassifizierungsschema, trainieren Sie Datenmodellierer, klassifizieren Sie Felder während des Entwurfs, konfigurieren Sie Steuerelemente und stimmen Sie ABAC-Richtlinien auf die Klassifizierungsklassen ab, damit Tags die Erzwingung vorantreiben.

StartBeginnen Sie mit den Informationen, die die Plattform bereits für jede Organisation bereitstellt. Daten im Leerlauf werden standardmäßig verschlüsselt. Hyperforce wendet die Verschlüsselung auf Volumenebene an, um ein gesamtes Speichervolumen unter einem einzigen Schlüssel zu schützen, dessen Inhaber Salesforce ist und der von Salesforce verwaltet wird. Diese Grundlage ist immer aktiviert und transparent für Ihre Lösung, funktioniert jedoch auf Volumenebene (nicht pro Feld). Daher liegt die Auswahl der zu verschlüsselnden und zu steuernden Elemente im Schlüssellebenszyklus bei der Plattform, nicht bei Ihnen.

Verwenden Sie Shield Platform Encryption, wenn diese Grundlage einer Konformitäts-, Vertrags- oder Datenklassifizierungsverpflichtung nicht nachkommen kann. Insbesondere, wenn Sie eines der drei Elemente benötigen, die die Verschlüsselung auf Volumenebene nicht bietet:

• Steuern des Schlüssellebenszyklus, sodass Sie das Schlüsselmaterial selbst generieren, rotieren und widerrufen können
• Selektivität, über die Standardfelder, benutzerdefinierte Felder, Dateien und Anhänge im Leerlauf verschlüsselt werden
• Die Möglichkeit, Salesforce den Zugriff auf Daten zu entziehen.

Eingeschränkte Daten und Daten, die unter expliziten behördlichen Schlüsselkontrollmandaten stehen (z. B. HIPAA, PCI DSS und DSGVO), sind die üblichen Auslöser. Die Grundlage umfasst bereits den Schutz aller anderen Elemente auf Infrastrukturebene.

Shield Platform Encryption wird auf Feldebene verschlüsselt und bietet zwei Schemata, bei denen die Sicherheit durch Abfragebarkeit ersetzt wird.

Die probabilistische Verschlüsselung ist ein sicheres Standardschema. Die damit verschlüsselten Felder können jedoch nicht in Filterkriterien, Sortier- oder Aggregatfunktionen (z. B. MAX(), MIN() und COUNT_DISTINCT()) verwendet werden.

Die deterministische Verschlüsselung ermöglicht die Filterung nach exakter Übereinstimmung in Berichten, Listenansichten und SOQL WHERE-Klauseln – unabhängig von Groß- und Kleinschreibung – mit reduzierter Stärke, da derselbe Nur-Text immer denselben Chiffrattext erzeugt.

Es wird empfohlen, standardmäßig mit dem probabilistischen Schema zu verschlüsseln und die deterministische Verschlüsselung für die spezifischen Felder zu reservieren, die Sie filtern oder sortieren müssen. Werten Sie diese Kompromisse während der Datenmodellierung aus, einschließlich der Auswirkungen auf Formelfeldverweise, Berichtsaggregation und SOQL-Vorgänge.

Kundengesteuerte Schlüssel gibt es in zwei unterschiedlichen Formen:

• Mit Bring Your Own Key (BYOK) können Sie Schlüsselmaterial außerhalb von Salesforce generieren und es der Plattform bereitstellen.
• Der Nur-Cache-Schlüsselservice speichert Ihren Datenverschlüsselungsschlüssel in einem von Ihnen gesteuerten Schlüsselservice. Salesforce ruft sie nach Bedarf ab, statt sie zu speichern.

Mit beiden Formularen können Sie wichtiges Material nach Ihrem eigenen Zeitplan rotieren und vernichten. Durch das Vernichten von Schlüsselmaterial können die geschützten Daten nicht wiederhergestellt werden. Dabei handelt es sich um eine leistungsstarke, absichtliche Kontrolle und nicht um eine Routine. Es ist auch wichtig, Ihre Schlüsselrotation und Widerrufsverfahren zu dokumentieren.

Alle Integrationen müssen TLS 1.2 oder höher verwenden (die Salesforce Platform erzwingt dies). Sie müssen jedoch die zertifikatsbasierte gegenseitige Authentifizierung für Integrationen implementieren, die eingeschränkte Daten verarbeiten (mit Ihrer eigenen Konfiguration).

Ihre Verantwortung: Legen Sie fest, wo die Grundlage auf Volumenebene der Plattform ausreicht und wo eine Compliance-, Vertrags- oder Klassifizierungsverpflichtung die Shield Platform Encryption rechtfertigt. Wählen Sie dann Verschlüsselungsschemas aus, wählen Sie eine kundengesteuerte Schlüsselstrategie aus und betreiben Sie sie und implementieren Sie die zertifikatsbasierte Authentifizierung für sensible Integrationen.

Schützen Sie sensible Daten in Nicht-Produktionsumgebungen mit Strategien, die verhindern, dass eingeschränkte Daten in Sandbox-Instanzen gelangen.

• Beim teilweisen Kopieren von Sandbox-Instanzen werden eingeschränkte Daten aus Sandbox-Aktualisierungen ausgeschlossen.
• Datenmaskierungsregeln verwirren sensible Feldwerte in Sandbox-Instanzen, indem Muster verwendet werden, die Dateneigenschaften beibehalten.
• Die synthetische Datengenerierung gilt für Entwicklungsumgebungen, in denen niemals Produktionsdaten erforderlich sind.
• Sandbox-Vorlagen definieren, welche Objekte und Felder in die einzelnen Sandbox-Typen aufgenommen werden sollen.

Das Entwerfen von Compliance-Tests ist eine architektonische Verantwortung. Erstellen Sie Entwicklungs- und Testzyklen für synthetische Daten mit realistischen Eigenschaften, damit Teams anhand von produktionsähnlichen Bedingungen validieren können, während regulierte Daten innerhalb ihrer Produktionsgrenze bleiben.

Ihre Verantwortung: Entwerfen Sie eine Sandbox-Strategie, konfigurieren Sie Data Mask-Regeln und generieren Sie synthetische Testdaten.

Entwerfen Sie Lösungen, die die Privatsphäre der Benutzer durch Architekturentscheidungen berücksichtigen.

• Datenminimierung: Erfassen Sie Daten, die nur für angegebene Geschäftszwecke erforderlich sind. Fordern Sie jede Feldergänzung heraus, indem Sie fragen: "Für welche architektonische Entscheidung sind diese Daten erforderlich?" Denken Sie daran, dass die sichersten Daten die Daten sind, die Sie niemals erfassen.
• Zweckeinschränkung: Entwerfen Sie Datenzugriffsmuster, die Zweckbeschränkungen technisch erzwingen. Verwenden Sie Berechtigungssätze und Freigaberegeln, um den Zugriff auf Daten je nach Zweck einer Auftragsfunktion einzuschränken. Marketingbenutzer sollten beispielsweise nur dann auf Support-Kundenvorgangsdetails zugreifen, wenn ihr Auftrag dies erfordert.
• Einwilligungsverwaltung: Implementieren Sie die Einwilligungsverfolgung auf Einzelpersonenebene für Marketing, Analysen und optionale Datenverarbeitung. Entwerfen Sie Workflows für den Widerruf von Einwilligungen, die in integrierte Systeme übertragen werden. Anders ausgedrückt, die Einwilligung ist granular und zweckspezifisch.
• Betroffene Personenrechte: Erstellen Sie Workflows für Zugriffsanforderungen (z. B. Bereitstellen von Datenkopien), Berichtigung (z. B. Korrigieren von Ungenauigkeiten), Löschung (z. B. Löschen von Daten, wenn dies gesetzlich zulässig ist) und Übertragbarkeit (z. B. Exportieren in ein maschinenlesbares Format). Entwerfen Sie diese Workflows so, dass sie innerhalb der Antwortfrist abgeschlossen werden, die von jedem Regelwerk vorgegeben wird. Diese Fristen variieren je nach Zuständigkeit – und sie werden regelmäßig geändert. Daher ist es wichtig, das SLA des Workflows aus einer verwalteten Compliance-Quelle zu parametrieren und jedes Fenster anhand der geltenden Verordnung zu bestätigen (anstatt einen einzelnen Wert hartzucodieren).

Ihre Verantwortung: Entwerfen Sie Datenmodelle mit Minimierung, konfigurieren Sie den Zugriff nach Zweck, implementieren Sie Einwilligungs-Workflows und erstellen Sie eine Automatisierung der Rechte betroffener Personen.

Die Datenresidenz ist eine architektonische Entscheidung, die Sie vor der Bereitstellung treffen, und keine Einstellung, die Sie anschließend umschalten. Hyperforce bietet eine regionale Bereitstellung. Es gibt jedoch nur eine Region, in der Salesforce eine betreibt. Sie müssen festlegen, wo sich die einzelnen Datenkategorien befinden müssen, überprüfen, ob eine geeignete Region verfügbar ist, und die Mechanismen für die Datenübertragung entwerfen, die legitimerweise grenzüberschreitend sind.

Statt standardmäßig auf Speicherplatz im Land zu setzen, ist es wichtig, Ihre Residenzverpflichtungen zu klassifizieren, bevor Sie beginnen.:

• Obligatorische Lokalisierung. In einigen wenigen Ländern müssen bestimmte Daten innerhalb der nationalen Grenzen bleiben (manchmal gilt dies nur für regulierte Sektoren). Wenn Salesforce nicht in einer Region im Land tätig ist, kann der native Speicher das Mandat nicht alleine erfüllen. Daher benötigen Sie ein Overlay für die Datenresidenz oder eine separate Organisation für diese Daten. Da sich diese Liste möglicherweise verschiebt, ist es wichtig, das spezifische Mandat im Vergleich zur geltenden Verordnung zu bestätigen.
• Rechenschaftspflichtige Frameworks. Die meisten Regime erzwingen kein Lokalisierungsmandat. Sie werden von einem regionalen Zentrum mit einem geeigneten grenzüberschreitenden Übertragungsmechanismus unterstützt. In diesen Fällen basiert die Entscheidung darauf, welche Region die Latenz minimiert und die Einhaltung vereinfacht.

Wenn Daten einen Rahmen überschreiten, geht es vor der Konfiguration um das Bewusstsein. Mit anderen Worten, Sie müssen wissen, welche Übertragungen auf welcher Rechtsgrundlage erfolgen, und dann den Zugriff so gestalten, dass die Daten durchgängig geregelt werden. Sofern vorhanden, haben Angemessenheitsentscheidungen die geringste Reibung. Verbindliche Unternehmensregeln und Standardvertragsklauseln decken die meisten verbleibenden Übertragungen ab. Verwenden Sie die ausdrückliche Einwilligung nur als letztes Mittel.

Kombinieren Sie den Übertragungsmechanismus mit restriktivem Datensatzzugriff (z. B. private Einmalkennwörter und zweckgebundene Freigabe), damit eine zulässige Übertragung nicht zu weit gefasst wird. Dokumentdatenflusszuordnungen, um anzuzeigen, woher die einzelnen Datenkategorien stammen, wohin sie gelangen und wo sie sich befinden. Besuchen Sie sie erneut, wenn sich Vorschriften oder regionale Verfügbarkeiten ändern.

Ihre Verantwortung: Klassifizieren Sie die Residenzverpflichtungen pro Datenkategorie, bestätigen Sie die regionale Verfügbarkeit vor der Bereitstellung, wählen Sie Übertragungsmechanismen (Angemessenheit, BCRs/SCCs) für grenzüberschreitende Flows aus und dokumentieren Sie Datenflusszuordnungen.

Es liegt in Ihrer Verantwortung, Lösungen zu entwerfen, die den Compliance-Status der Plattform beibehalten.

Diese Anleitung ist richtungsweisend. Regulatorische Anforderungen variieren je nach Zuständigkeit und ändern sich im Laufe der Zeit. Sie müssen für Ihre Bereitstellung immer bestimmte Verpflichtungen anhand der geltenden Verordnung (z. B. der geltenden Satzung, der Aufsichtsbehörde oder der Salesforce-Compliance-Dokumentation) überprüfen.

Salesforce unterhält umfangreiche Compliance-Zertifizierungen (verfügbar unter Trust.salesforce.com und compliance.salesforce.com): SOC 2 Typ II, ISO 27001, FedRAMP (für Government Cloud-Angebote), HIPAA, PCI DSS und regionale Zertifizierungen. Diese Zertifizierungen decken die Salesforce-Verantwortlichkeiten für die Plattforminfrastruktur und freigegebene Services ab.

Plattformzertifizierungen reduzieren Ihre Compliance-Belastung, beseitigen jedoch nicht Ihre architektonische Verantwortung. Ihre benutzerdefinierten Objekte, Apex-Code, Integrationen und Konfigurationen müssen den von der Plattform bereitgestellten Compliance-Status beibehalten.

Ihre Verantwortung: Entwerfen Sie Lösungen, die den Compliance-Status beibehalten, und dokumentieren Sie, wie die Architektur die gesetzlichen Anforderungen erfüllt.

• Aktivieren Sie Shield Platform Encryption für alle Felder, die geschützte Gesundheitsinformationen enthalten.
• Aktivieren Sie das Feld-Aktivierungsprotokoll mit Aufbewahrungsrichtlinien, um die HIPAA-Aufzeichnungsanforderungen zu erfüllen. Bestätigen Sie den aktuellen Zeitraum anhand der geltenden Verordnung.
• Konfigurieren Sie die Ereignisüberwachung, um nicht autorisierte PHI-Zugriffsmuster zu erkennen.
• Implementieren Sie alle technischen Schutzmaßnahmen, die gemäß der HIPAA-Sicherheitsregel erforderlich sind, einschließlich Zugriffssteuerungen, Prüfungsprotokollierung und Übertragungssicherheit.

• Implementieren Sie die Aufgabentrennung über Berechtigungssatz-Designs, um zu verhindern, dass einzelne Benutzer Finanztransaktionen erstellen und genehmigen.
• Vermeiden Sie es in PCI-Umgebungen, vollständige primäre Accountnummern (Primary Account Numbers, PAN) in Salesforce zu speichern, um den PCI DSS-Compliance-Umfang zu minimieren.
• Verwenden Sie nach Möglichkeit die Tokenisierung des Zahlungs-Gateways.

• Entwerfen Sie für DSGVO und LGPD eine Einwilligungsverwaltung, die eine detaillierte, zweckspezifische Einwilligung erfasst.
• CCPA/CPRA folgt einem Abmeldemodell. Stellen Sie klare Mechanismen bereit, um sich vom Verkauf oder der Weitergabe personenbezogener Daten abzumelden, statt eine granulare zweckbasierte Einwilligung zu erhalten.
• Erstellen Sie Workflows für die Rechte betroffener Personen, die innerhalb der Antwortfrist der einzelnen Frameworks abgeschlossen sind und anhand der geltenden Verordnung bestätigt werden.
• Implementieren Sie die Datenaufbewahrungsautomatisierung, die Daten bereinigt, wenn die Einwilligung abläuft.

• Verwenden Sie die Salesforce Government Cloud für regulierte behördliche Arbeitslasten.
• Implementieren Sie NIST 800-53-Steuerelemente, die der Salesforce-Konfiguration zugeordnet sind.
• Aktivieren Sie die kontinuierliche Überwachung über die Ereignisüberwachung, die an die staatliche SIEM-Infrastruktur weitergeleitet wird.

Ihre Verantwortung: Konfigurieren von Shield, Feld-Aktivierungsprotokoll, Aufgabentrennung, Einwilligungsverwaltung, Datenaufbewahrung anhand gesetzlicher Anforderungen.

Die Verordnungen zum Datenschutz und zur Privatsphäre variieren erheblich je nach Rechtsordnung – und bestimmte Verpflichtungen ändern sich schnell. Daher muss auf dieser Ebene eine Entscheidungsfindung und keine Tabelle nach Land getroffen werden.

Die beiden architektonischen Hebel sind Residenz und grenzüberschreitender Transfer, die unter Datenschutz und Privatsphäre fallen.

Um diese Vorschriften einzuhalten, müssen Sie:

• Klassifizieren, wo sich die einzelnen Datenkategorien befinden müssen
• Überprüfen, ob vor der Bereitstellung eine geeignete Region vorhanden ist
• Entwerfen Sie einen legalen Übertragungsmechanismus für Daten, die eine Grenze überschreiten.

Weitere Informationen finden Sie unter Datenresidenz und Souveränität, um weitere Details zum Entscheidungs-Framework zu erhalten.

Alles, was davon abweicht, wird als Zeitpunkt betrachtet (z. B. welches Einwilligungsmodell eine Gerichtsbarkeit verwendet, die Frist für eine Anfrage betroffener Personen, das Zeitfenster für die Benachrichtigung von Regulierungsbehörden oder betroffenen Personen nach einem Verstoß und die Mindestaufbewahrungsfrist für Prüfungsdatensätze). Diese Zahlen werden durch Verordnungen festgelegt, unterscheiden sich je nach Rahmen und werden in den Plänen der Regulierungsbehörden geändert.

Coden Sie sie hier nicht hart. Sie müssen die nächsten Schritte auf der Grundlage der geltenden Vorschriften für Ihre Bereitstellung oder einer verwalteten Compliance-Quelle, die eine anführt, festlegen und Ihr Design auf das engste Fenster in Ihrer Betriebsbilanz ausweiten.

Hier sind die dauerhaften architektonischen Konsequenzen, die in den Entwurf gehören.

• Eine in einstelligen Tagen gemessene Frist für die Anfrage betroffener Personen kann durch einen manuellen Ad-hoc-Prozess nicht eingehalten werden. Daher müssen Sie die Abwicklung von Datenverarbeitungsmodulen automatisieren, wenn Sie in einer beliebigen kurzen Frist tätig sind. Verwenden Sie Experience Cloud für die Aufnahme, Service Cloud für die Kundenvorgangsverfolgung, Datenschutzcenter für die Entdeckung und Flow für die Abwicklung.
• Ein Fenster mit Benachrichtigungen zu Verstößen ist zu eng, um zu improvisieren. Daher müssen Sie den Workflow für die Reaktion auf Verstöße im Voraus erstellen. Bestimmen Sie Regeln für die Ereignisüberwachungsanomalie, vorab zugewiesene Rollen, vorab entworfene Benachrichtigungen von Regulierungsbehörden und betroffenen Personen und einen Eskalationspfad, der den engsten Termin innerhalb Ihrer Bilanz annimmt. Einzelne Benachrichtigungen werden in der Regel durch eine Bestimmung mit hohem Risiko ausgelöst. Daher müssen Sie eine Risikobewertung in den Workflow aufnehmen.
• In einigen Rechtsordnungen ist die Aufbewahrung von Prüfprotokollen im Land – mit Mindestanforderungen für mehrere Jahre – erforderlich oder wird empfohlen. Daher müssen Sie die SIEM-Aufbewahrung auf das längste Minimum in Ihrer Bilanz festlegen und bestätigen, ob Protokolle die Rechtsordnung verlassen können.

Ihre Verantwortung: Entwerfen Sie die Residenz und Übertragung pro Datenschutz und Datenschutz, automatisieren Sie Workflows für die Datenverarbeitung und die Reaktion auf Verstöße bis zum engsten Termin in Ihrer Bilanz und bestätigen Sie jede gebietsspezifische Zahl, die mit der geltenden Verordnung übereinstimmt, statt einen Wert in diesem Leitfaden anzugeben.

Design für die kontinuierliche Konformitätsvalidierung anstelle der Vorbereitung auf die Überprüfung zum Zeitpunkt der Prüfung.

• Die Sicherheitsintegritätsprüfung bewertet die Konfiguration anhand der Salesforce-Sicherheitsgrundlagen und bietet Risikobewertungen. Führen Sie regelmäßig Überprüfungen aus, um die Einhaltung der Salesforce-Sicherheitsgrundlagenempfehlungen zu überwachen. Beibehalten von Werten von 80 % oder höher (Sehr gute oder ausgezeichnete Werte).
• Die Ereignisüberwachung erfasst detaillierte Protokolle für Benutzeraktivitäten, API-Aufrufe, Authentifizierungsereignisse und Datenzugriffsmuster. Leiten Sie Ereignisprotokolldateien zur langfristigen Aufbewahrung an externes SIEM weiter, das die nativen Aufbewahrungsobergrenzen überschreitet.
• Die Transaktionssicherheit wertet Ereignisse in Echtzeit anhand von Policen aus und kann Ereignisse blockieren, eine Erhöhung der MFA erforderlich machen oder Sie über Richtlinienverstöße benachrichtigen.

Es ist wichtig, die Konformitätsprüfungen in Bereitstellungspipelines zu automatisieren, um zu überprüfen, ob Bereitstellungen Berechtigungsmodelle nicht schwächen, Überprüfungseinstellungen deaktivieren oder nicht konforme Konfigurationen einführen.

Ihre Verantwortung: Führen Sie die Integritätsprüfung vierteljährlich aus, leiten Sie die Ereignisüberwachung an SIEM weiter, konfigurieren Sie Transaktionssicherheitsrichtlinien und automatisieren Sie die Compliance-Validierung in CI/CD.

Entwerfen Sie Audit Trail-Strategien, die auf Compliance-Anforderungen, Untersuchungsanforderungen und Aufbewahrungspflichten basieren.

Implementieren Sie für regulierte Umgebungen die Ereignisüberwachung mit externer SIEM-Integration für die langfristige Protokollaufbewahrung und systemübergreifende Korrelation. Entwerfen Sie Field Audit Trail-Richtlinien, die alle eingeschränkten und vertraulichen Felder abdecken, die den gesetzlichen Aufbewahrungsanforderungen unterliegen.

Ihre Verantwortung: Aktivieren Sie das Feld-Aktivierungsprotokoll für sensible Felder, leiten Sie die Ereignisüberwachung an SIEM weiter und konfigurieren Sie Transaktionssicherheitsrichtlinien.

Es liegt in Ihrer Verantwortung, die Sicherheit während der gesamten Entwicklung zu integrieren, und nicht erst später.

Integrieren Sie Sicherheitspraktiken in der frühestmöglichen Entwicklungsphase. Die Bedrohungsmodellierung während der Architekturphase verhindert Sicherheitslücken auf Designebene. Sicherheitsanforderungen, die zusammen mit funktionalen Anforderungen erfasst werden, verhindern, dass Sie die Sicherheit wie einen Gedanken behandeln.

Die Behebung von Sicherheitsmängeln kostet wesentlich mehr, wenn sie in der Produktion und nicht in der Design- oder Entwicklungsphase entdeckt werden. Ein Sicherheitsfehler auf Designebene, der während der Architekturüberprüfung festgestellt wird, kann nur eine Unterhaltung dauern, bis er behoben ist. Wenn derselbe Fehler jedoch in der Produktion gefunden wird, sind Rückarchitektur, Datenmigration, Konformitätsbehebung und Benachrichtigung über potenzielle Verstöße erforderlich.

Deshalb praktizieren wir die Sicherheit von Schichten nach links, die sich auf Folgendes konzentriert:

• Bedrohungsmodellierung vor der Fertigstellung des Designs
• Sicherheitsanforderungen in Benutzerartikeln
• Sichere Codierungsschulung für Entwickler
• Statische Analyse, die in IDEs integriert ist
• Sicherheitsorientierte Codeüberprüfungen
• Automatisierte Sicherheitstests in CI/CD
• Sicherheitsvalidierung vor der Produktionsbereitstellung

Ihre Verantwortung: Führen Sie Bedrohungsmodellierungen durch, schulen Sie Entwickler, integrieren Sie Code Analyzer in CI/CD und fordern Sie Codeüberprüfungen mit Sicherheitsbewusstsein an.

Es ist wichtig, Abwehrmaßnahmen gegen allgemeine Schwachstellen in einem Salesforce-Kontext zu entwerfen. Sehen wir uns einmal genauer an, wie wir die Top 10 der OWASP 2025 bei Salesforce zuordnen.

• A01:2025 - Fehlerhafte Zugriffssteuerung: Erzwingen Sie CRUD und Feldebenensicherheit (FLS) programmgesteuert bei allen Apex Datenzugriffen.
  • In API-Version 67.0 oder höher wird Apex standardmäßig im Benutzerkontext ausgeführt, d. h., die Berechtigungen des aktuellen Benutzers und die Sprachausgabe werden während der Codeausführung erzwungen.
    • WITH SECURITYENFORCED wurde entfernt, was zu einem Kompilierungsfehler führt. Ersetzen Sie alle vorhandenen Verwendungen durch WITH USER_MODE. Die Plattform erzwingt den Zugriff auf der Standardbenutzeroberfläche.
  • In API-Version 66.0 oder früher ist der Systemmodus der Standardmodus. Verwenden Sie WITH USERMODE in SOQL-Abfragen oder Security.stripInaccessible() für DML-Vorgänge.
• A01:2025 - Clientseitige Daten-APIs: Der Lightning Data Service und die Benutzeroberflächen-API erzwingen automatisch die FLS, CRUD und Freigabe des aktuellen Benutzers. Daher übernimmt eine auf ihnen basierende Komponente standardmäßig die geringste Berechtigung.
  • Dieser Schutz geht verloren, wenn eine Komponente einen benutzerdefinierten Apex aufruft. Imperativer Apex erzwingt den Zugriff nur, wenn er im Benutzermodus ausgeführt wird. Daher fungiert eine Klasse, die ohne Freigabe deklariert wurde, als Fluchtschraffur, die das Modell stillschweigend umgeht.
  • Verwenden Sie den Lightning Data Service und die Benutzeroberflächen-API für den Datenzugriff.
  • Sie müssen CRUD, FLS und sharing für jeden zwingenden Apex Aufruf einer Komponente erneut bestätigen.
• A02:2025 - Sicherheitsfehlkonfiguration: Überwachen Sie die Abweichung der Konfiguration von den Sicherheitsgrundlagen mithilfe der Integritätsprüfung.
  • Deaktivieren Sie den Gastbenutzerzugriff auf Experience Cloud-Sites (es sei denn, dies ist in einer dokumentierten geschäftlichen Begründung ausdrücklich erforderlich).
• A05:2025 - Einspritzung: Die Kategorie 2025 Injection deckt SOQL/SOSL-Injection und Cross-Site-Scripting (XSS) ab.
  • Verwenden Sie für die Abfrageinjektion Bindungsvariablen für alle dynamischen Abfragen. Verketten Sie Benutzereingaben niemals direkt in Abfragezeichenfolgen. Die parametrisierten Abfragemechanismen der Plattform eliminieren das Injektionsrisiko, wenn sie richtig verwendet werden.
  • SOQL- oder SOSL-Injektionen sind auf einen Messwert beschränkt, der Datensätze oder Felder offenlegt, die der Anrufer durch Erweitern der Abfragebedingungen nicht erreichen kann. Da diese Sprachen Daten lesen, während Schreibvorgänge separate DML-Vorgänge durchlaufen, besteht ein Risiko für Zugriffssteuerung und Vertraulichkeit, da es sich verschlimmert, wenn Objekt- und Feldberechtigungen für die Abfrage nicht erzwungen werden.
  • Bei XSS bieten Lightning Web Components automatischen Schutz über das LWC-Renderingmodul.
  • Bei Aura-Komponenten und Visualforce müssen Sie beim Rendern dynamischer Inhalte Plattformcodierungsfunktionen (z. B. HTMLENCODE, JSENCODE und URLENCODE) anwenden.

Ihre Verantwortung: Erzwingen Sie CRUD/FLS in benutzerdefiniertem Code, wenden Sie Codierungsfunktionen an, verwenden Sie Bindungsvariablen und überwachen Sie die Konfigurationsabweichung.

Entwerfen Sie CI/CD-Pipelines mit Sicherheits-Gates in jeder Phase. Die Sicherheit muss mit der Entwicklungsgeschwindigkeit skaliert werden.

Sehen wir uns die Pipeline-Sicherheitsphasen genauer an.

• Die Quellcodeverwaltung verwendet Verzweigungsschutzregeln mit erforderlichen Codeüberprüfungen. Es gibt keine direkten Commits an Hauptverzweigungen oder signierte Commits.
• Die statische Analyse verwendet den Salesforce Code Analyzer, der PMD, ESLint und RetireJS zur Erkennung von Injektions-, XSS- und unsicheren Mustern enthält.
• Beim Sicherheitsscan werden SAST-Tools und -Geheimnisse verwendet, um Commits von Anmeldeinformationen und das Scannen von Abhängigkeitsschwachstellen zu verhindern.
• Bei der Berechtigungsvalidierung werden automatisierte Vergleichstechniken verwendet, um Berechtigungsänderungen anhand von Sicherheitsgrundlagen zu überprüfen, wodurch Warnungen hinsichtlich der Berechtigungserweiterung gesendet werden.
• Bereitstellungs-Gates unterbrechen die Bereitstellung bei wichtigen Sicherheitsergebnissen, die die Genehmigung des Sicherheitsteams für Änderungen zur Erweiterung der Berechtigungen erfordern.
• Bei der Überwachung nach der Bereitstellung werden Warnungen zur Ereignisüberwachung für anomales Verhalten nach Bereitstellungen verwendet.

Ihre Verantwortung: Integrieren Sie Code Analyzer in CI/CD, konfigurieren Sie den Verzweigungsschutz, implementieren Sie Bereitstellungs-Gates und validieren Sie Berechtigungen automatisch.

Umfassende Sicherheitstests umfassen mehrere Techniken, die unterschiedliche Schwachstellenklassen beheben. Sehen wir uns die einzelnen Strategien genauer an.

• Die statische Analyse führt Salesforce Code Analyzer in Entwickler-IDEs für sofortiges Feedback und in CI/CD-Pipelines als automatisierte Gates aus. Die statische Analyse identifiziert Schwachstellen im Quellcode, ohne die Anwendung auszuführen.
• Penetrationstests führen Penetrationstests für benutzerdefinierte Anwendungen durch, die nicht vertrauenswürdigen Benutzern angezeigt werden, insbesondere Experience Cloud-Sites und öffentlich zugänglichen APIs.
  • Für AppExchange und die AgentExchange-Sicherheitsüberprüfung sind immer statische Analyseberichte erforderlich.
  • Ein dynamischer Scanbericht (Penetrationstest) ist erforderlich, wenn die Lösung eine Webanwendung oder einen Drittanbieterservice integriert.
  • Penetrationstests simulieren Angreifertechniken mit Live-Anwendungen.
• Sicherheitsorientierte Einheitentests schreiben Apex-Tests, die die Durchsetzung der Zugriffssteuerung validieren, indem sie als Benutzer mit unterschiedlichen Berechtigungsprofilen ausgeführt werden. Es ist wichtig, zu überprüfen, ob die CRUD/FLS-Erzwingung nicht autorisierten Zugriff blockiert.
• Bei der Abhängigkeitsüberprüfung werden AgentExchange-Pakete und JavaScript-Bibliotheken auf bekannte Schwachstellen überwacht. Es ist wichtig, Sicherheitshinweise für installierte Pakete zu abonnieren.

Ihre Verantwortung: Führen Sie Code Analyzer aus, führen Sie Penetrationstests aus, schreiben Sie Tests für Sicherheitseinheiten und scannen Sie Abhängigkeiten.

Bei Salesforce konzentriert sich die Reaktion auf Sicherheits- und Datenvorfälle auf die Erkennung, Eindämmung und Wiederherstellung von Verstößen, unbefugtem Zugriff und böswilliger Datenvernichtung. Vorfallsreaktionsteams arbeiten zusammen mit zwei benachbarten Säulen, die über benachbarte Zuständigkeiten verfügen:

• Operational Excellence deckt die operativen Mechanismen des Vorfallsmanagements ab (z. B. Schweregrade, Bereitschaftsrotation, Eskalation und Überprüfung nach einem Vorfall)
• Zuverlässigkeit umfasst die Wiederherstellung der Verfügbarkeit in Bezug auf RTO- und RPO-Ziele, einschließlich Sicherung und Notfallwiederherstellungsstrategie.

Als Architekt sind Sie dafür verantwortlich, die Erkennung, Reaktion und Wiederherstellung von Sicherheitsvorfällen zu planen.

Bei der Erkennbarkeit handelt es sich um eine architektonische Eigenschaft, die Sie explizit entwerfen müssen. Ohne umfassende Überwachung bleiben Sicherheitsvorfälle möglicherweise über einen längeren Zeitraum unentdeckt.

Es ist wichtig, die Erkennung über mehrere Kanäle zu implementieren.

• Die Ereignisüberwachung erfasst Rohereignisprotokolle, die Anmeldungen, Berichts- und Datenexporte, Berechtigungsänderungen und API-Aufrufe abdecken. Sie müssen ermitteln, welche Ereignisse anormal sind, was Transaktionssicherheitsrichtlinien oder SIEM-Korrelation zusätzlich zu den Protokollen erfordert, die Sie zum Bestimmen der Erkennungslogik konfigurieren.
• Transaktionssicherheitsrichtlinien werten Ereignisse in Echtzeit aus und blockieren verdächtige Aktionen. Sie müssen diese Richtlinien konfigurieren.
• Mit dem Setup-Aktivierungsprotokoll werden die administrativen Änderungen verfolgt, die die Plattform bereitstellt. Sie müssen sie jedoch überwachen.
• Die benutzerdefinierte Anwendungsprotokollierung erfasst sicherheitsrelevante Ereignisse in Apex, die Sie implementieren müssen.

Leiten Sie Ereignisüberwachungsprotokolle zur Korrelation mit der Unternehmenssicherheitstelemetrie an SIEM-Plattformen weiter. Entwerfen Sie Benachrichtigungsregeln, die verdächtige Muster erkennen und gleichzeitig falsch positive Werte durch verhaltensbasierte Grundlagen minimieren.

Ihre Verantwortung: Leiten Sie die Ereignisüberwachung an SIEM weiter, konfigurieren Sie Transaktionssicherheitsrichtlinien, implementieren Sie eine benutzerdefinierte Protokollierung und richten Sie Verhaltensgrundlagen ein.

Es ist wichtig, Architekturentscheidungen zu dokumentieren, die die Reaktion auf Vorfälle unterstützen, bevor Vorfälle auftreten.

• Isolationsgrenzen entwerfen Lösungen, um kompromittierte Komponenten zu isolieren, ohne wichtige Geschäftsfunktionen zu unterbrechen. Sie müssen den Widerruf von Berechtigungssätzen, Änderungen an der IP-Einschränkung und die Sitzungsbeendigung konfigurieren, um schnelle Isolationsfunktionen bereitzustellen.
• Die forensische Aufbewahrung verwendet die Ereignisüberwachung, um detaillierte Aktivitätsprotokolle bereitzustellen (Plattformfunktion). Das Feld-Aktivierungsprotokoll behält den Datenänderungsverlauf basierend auf Ihrer Konfiguration bei. Designprotokolle werden an unveränderlichen Speicher weitergeleitet, sodass Angreifer Ihre Architektur nicht ändern können.
• Wiederherstellungsverfahren dokumentieren getestete Wiederherstellungsprozesse für allgemeine Vorfallstypen. Es ist wichtig, die Sicherungsintegrität regelmäßig zu validieren. Sie müssen Ihr Wiederherstellungszeitziel und Ihr Wiederherstellungspunktziel für Sicherheitsvorfallsszenarien kennen.
• Kommunikationsworkflows entwerfen Benachrichtigungsmechanismen, die bei Vorfällen funktionieren (z. B. außerhalb des Bands liegende Kommunikationskanäle, vordefinierte Vorlagen und Eskalationsverfahren, die nicht von potenziell kompromittierten Systemen abhängen).
• Der Offenlegungskanal für Schwachstellen ist für öffentlich zugängliche Experience Cloud-Sites vorgesehen. Sie bietet externen Forschern eine dokumentierte, überwachte Möglichkeit, Sicherheitsprobleme über eine Offenlegungsrichtlinie zu melden, die im RFC 9116 security.txt-Standard veröffentlicht ist. Ein externer Bericht ist oft das erste Signal eines Vorfalls. Daher ist es wichtig, diesen Aufnahmepfad als Teil der Architektur einzurichten, für die Sie verantwortlich sind.

Ihre Verantwortung: Dokumentieren Sie Isolationsverfahren, leiten Sie Protokolle an unveränderlichen externen Speicher weiter, testen Sie Wiederherstellungsverfahren vierteljährlich, richten Sie eine Kommunikation außerhalb des Bands ein und veröffentlichen Sie einen Kanal zur Offenlegung von Schwachstellen für öffentlich zugängliche Sites.

Bei Salesforce ist es wichtig, Antwortfunktionen für plattformspezifische Szenarien vorzubereiten.

• Kompromierte Benutzeraccounts werden über Anmeldeanomalien der Ereignisüberwachung erkannt (z. B. unerwartete geografische Gegebenheiten, ungewöhnliche Zeiten und neue Geräte). Wenn Accounts kompromittiert werden, fixieren Sie den Benutzer, erzwingen Sie die Zurücksetzung von Anmeldeinformationen, überprüfen Sie das Setup-Aktivierungsprotokoll und die Datenzugriffsprotokolle, um den Kompromittierungszeitraum zu bestimmen.
• Die Massendatenexfiltration wird über Berichtexporte der Ereignisüberwachung und API-Datenzugriffsvolumen-Anomalien erkannt. Wenn die Datenexfiltration erfolgt, widerrufen Sie Sitzungen sofort, schränken Sie Berechtigungen ein und identifizieren Sie betroffene Datensätze und Klassifizierungsebenen.
• Die Bereitstellung nicht autorisierten Codes wird über die Bereitstellungsüberwachung und die Konfigurationsänderungen des Setup-Aktivierungsprotokolls erkannt. Wenn nicht autorisierter Code bereitgestellt wird, setzen Sie die Bereitstellung sofort wieder her und überprüfen Sie alle Änderungen über die kompromittierten Bereitstellungsanmeldeinformationen.
• Die Privilegieneskalation wird über die Setup-Aktivierungsprotokollüberwachung auf Berechtigungsänderungen erkannt, die sich außerhalb genehmigter Änderungsfenster befinden. Widerrufen Sie bei einer Berechtigungseskalation sofort eskalierte Berechtigungen und Überprüfungsaktivitäten, die mit erhöhtem Zugriff ausgeführt wurden.

Ihre Verantwortung: Dokumentieren Sie Antwortverfahren für plattformspezifische Szenarien, konfigurieren Sie die Überwachung, um jedes Szenario zu erkennen, und testen Sie Verfahren durch Tabletop-Übungen.

Nach einem Vorfall ist es wichtig, eine urteilsfreie Überprüfung nach einem Vorfall durchzuführen, die sich auf architektonische Verbesserungen konzentriert. Sie müssen dokumentieren, was passiert ist, warum die vorhandenen Steuerelemente den Vorfall nicht verhindern oder erkennen konnten und welche architektonischen Änderungen erforderlich sind, um zukünftige Risiken zu reduzieren.

Ziele der Überprüfung nach einem Vorfall:

• Bestimmen Sie die Vorfallszeitachse und die Angreifertechniken.
• Identifizieren Sie die Steuerfehler, die den Vorfall aktiviert haben.
• Dokumentieren Sie alle architektonischen Schwächen, die der Vorfall aufgedeckt hat.
• Priorisieren Sie die auf Risikoreduzierung basierende Sanierung.
• Geben Sie die gewonnenen Erkenntnisse teamübergreifend frei.
• Aktualisieren Sie Erkennungsregeln und Antwortverfahren.

Es ist wichtig, Vorfallskennzahlen über die Zeit zu verfolgen, um die mittlere Zeit bis zur Erkennung, die mittlere Zeit bis zur Antwort und den Auswirkungsumfang zu bestimmen.

Ihre Verantwortung: Führen Sie eine zeitnahe Überprüfung nach einem Vorfall durch, dokumentieren Sie Verbesserungen bei ADRs, verfolgen Sie MTTD- und MTTR-Trends und geben Sie gewonnene Erkenntnisse weiter.

Verwenden Sie diese Checkliste bei Architekturüberprüfungen, vor der Produktionsbereitstellung und regelmäßig für die fortlaufende Bewertung. Jedes Element stellt Ihre Verantwortung als Salesforce-Architekt dar.

Gemeinsame Verantwortung

• Dokumentieren Sie alles, was Salesforce schützt (z. B. Infrastruktur-, Plattform- und Compliance-Zertifizierungen).
• Dokumentieren Sie alles, was Sie schützen müssen (z. B. Konfiguration, Zugriff, benutzerdefinierter Code und Datenverwaltung).
• Identifizieren Sie Bereiche mit gemeinsamer Verantwortung (z. B. Reaktion auf Vorfälle, Schwachstellenverwaltung und Überwachung).
• Kommunizieren Sie Verantwortlichkeiten gegenüber Beteiligten und Implementierungsteams so klar und prägnant wie möglich.

Sicherheitsarchitektur

• Schließen Sie die Bedrohungsmodellierung mit der STRIDE-Methodik ab, bevor Sie mit der Erstellung beginnen.
• Wenden Sie detaillierte Kontrollen zur Verteidigung auf Daten-, Anwendungs-, Identitäts- und Integrationsebenen an.
• Implementieren Sie Zero Trust Prinzipien, die für jede Zugriffsanforderung eine explizite Überprüfung erfordern.
• Verwalten Sie das aktuelle Inventar von Sicherheitsdatenbeständen, das sensible Daten, Integrationen, APIs und berechtigte Accounts abdeckt.
• Dokumentsicherheitsarchitektur-Entscheidungen in ASRs, einschließlich Bedrohungsanalyse und Kontrollberechtigung.
• Schützen Sie Clients ohne Kopf und im Namen von Kunden an der Salesforce Trust Grenze, indem Sie Identitäten pro Benutzer anstelle von Pool-Token übertragen.
• Speichern, rotieren und OAuth-Anmeldeinformationen mit den geringsten Berechtigungen über externe Client-Anwendungen.
• Erzwingen der Containerisolierung als Sicherheitsgrenze bei containerisierten Integrationen, Verschlüsseln des Datenverkehrs zwischen Containern und hybridem VPN mit mTLS (sofern das Framework dies erfordert) und Angleichen der Bereitstellungsregionen an Datenresidenz- und Compliance-Zertifizierungen

Identitäts- und Zugriffsverwaltung

• Legen Sie OWDs für Objekte mit sensiblen Daten auf Privat fest.
• Reservieren Sie "Öffentlicher Lesezugriff" für Objekte, bei denen ein breiter Lesezugriff erforderlich ist.
• Erzwingen Sie die Multi-Faktor-Authentifizierung für den gesamten Zugriff auf die Produktionsbenutzeroberfläche und Hardware-Sicherheitsschlüssel für berechtigte Accounts. Nur API-Integrationen, die JWT Bearer- oder Client-Anmeldeinformationen verwenden, sind ausgenommen.
• Implementieren Sie SSO mit SAML 2.0 oder OpenID Connect mit starker IdP-Authentifizierung.
• Verwenden Sie OAuth 2.0 (bevorzugt JWT Bearer) für die gesamte API-Authentifizierung. Verwenden Sie niemals OAuth 2.0 für eingebettete Anmeldeinformationen.
• Gewähren Sie Zugriff über Berechtigungssätze, die auf dokumentierten Anforderungen mit den geringsten Berechtigungen basieren.
• Wenden Sie erweiterte Steuerelemente auf Accounts mit kritischen Auswirkungen an (z. B. IP-Einschränkungen, Anmeldebenachrichtigungen und regelmäßige Zugriffsüberprüfungen).
• Führen Sie regelmäßige Zugriffsüberprüfungen mit dokumentierter Bescheinigung für Accounts mit hohem Recht durch, bei denen die Häufigkeit durch die Organisationsrisikotoleranz und die Compliance-Anforderungen bestimmt wird.
• Automatisieren Sie den Identitätslebenszyklus über die SCIM-Bereitstellung und die Erkennung von ruhenden Accounts für 90 Tage.
• Führen Sie Mitarbeiteragenten im Kontext des angemeldeten Benutzers aus und stellen Sie dedizierte Agentenbenutzer mit den geringsten Berechtigungen für Kundenagenten bereit. Führen Sie dies niemals für einen Gastbenutzer einer öffentlichen Site aus.
• Implementieren Sie JWT für die Agentenauthentifizierung mithilfe von Agenteninstanz- und Bot-Definitionskennzeichnern.
• Definieren Sie ABAC-Richtlinien, die mit der Datenklassifizierung und konsistenten Metadaten-Tagging-Standards übereinstimmen.

Datenschutz und Privatsphäre

• Klassifizieren Sie alle Daten und wenden Sie Schutzsteuerungen an, die für jede Klassifizierungsebene geeignet sind.
• Aktivieren Sie Shield Platform Encryption für eingeschränkte Daten mithilfe der dokumentierten Schlüsselverwaltung.
• Für alle Integrationen mit zertifikatsbasierter Authentifizierung für eingeschränkte Daten ist TLS 1.2+ erforderlich.
• Verhindern Sie, dass eingeschränkte Daten durch Maskierung oder Ausschluss in Nicht-Produktionsumgebungen gelangen.
• Implementieren Sie die Einwilligungsverwaltung mit detaillierten Workflows zur Verfolgung und Widerrufung pro Zweck.
• Erstellen Sie Workflows für die Rechte betroffener Personen, die innerhalb der Antwortfrist der einzelnen Regelwerke abgeschlossen werden. Diese sollten auf das engste Fenster in Ihrer Betriebsbilanz angepasst und pro Jurisdiktion aus einer verwalteten Compliance-Quelle parametriert werden, in der jede Zahl anhand der geltenden Vorschriften bestätigt wird.
• Dokumentieren Sie die Anforderungen an die Datenresidenz und validieren Sie die Hyperforce Regionsausrichtung.

Compliance und Einhaltung gesetzlicher Vorschriften

• Validieren Sie Plattformzertifizierungen, die die gesetzlichen Anforderungen für Ihre Branche erfüllen.
• Aktivieren Sie die Ereignisüberwachung mit SIEM-Weiterleitung für die Aufbewahrung, die die nativen Aufbewahrungsobergrenzen überschreitet.
• Konfigurieren Sie das Feld-Aktivierungsprotokoll so, dass es eingeschränkte Felder abdeckt, um sicherzustellen, dass die Aufbewahrung gesetzliche Mindestanforderungen erfüllt.
• Behalten Sie die Sicherheitsintegritätsprüfungsbewertungen von 80 % oder höher (Sehr gut oder Ausgezeichnet) bei und dokumentieren Sie alle Ausnahmen.
• Automatisieren Sie die Compliance-Validierung für CI/CD-Pipelines, die bei wichtigen Verstößen unterbrochen werden.
• Implementieren Sie Transaktionssicherheitsrichtlinien für die Erkennung und Reaktion von Anomalien in Echtzeit.

Sicherer Entwicklungslebenszyklus

• Führen Sie die Bedrohungsmodellierung während der Entwurfsphase durch (bevor Sie erhebliche Investitionen in die Erstellung tätigen).
• Erzwingen Sie CRUD/FLS in allen Apex Umgebungen.
• Verwenden Sie die automatische Erzwingung des Benutzermodus für API-Version 67.0 oder höher oder verwenden Sie WITH USERMODE oder stripInaccessible() für API-Version 66.0 oder früher.
• Verwenden Sie nicht WITH SECURITYENFORCED, das in API-Version 67.0 entfernt wurde.
• Führen Sie Salesforce Code Analyzer in CI/CD aus, wenn wichtige Ergebnisse die Bereitstellung blockieren.
• Fordern Sie Codeüberprüfungen durch sicherheitsbewusste Überprüfer für alle Produktionsänderungen an.
• Führen Sie Penetrationstests für alle öffentlichen Anwendungen und Experience Cloud-Sites aus.
• Validieren und bereinigen Sie alle Benutzereingaben, die die Injektion in SOQL-, SOSL- und HTML-Kontexte verhindern.

Sicherheitsvorfallsreaktion

• Entwerfen Sie Warnregeln für die Ereignisüberwachung, um verdächtige Muster anhand von Verhaltensgrundlagen zu erkennen.
• Leiten Sie Protokolle zur forensischen Aufbewahrung an unveränderlichen externen Speicher weiter.
• Dokumentieren und testen Sie Vorfallsreaktionsverfahren für plattformspezifische Szenarien.
• Führen Sie fehlerfreie Überprüfungen nach einem Vorfall mit ADRs aus, um architektonische Verbesserungen zu erfassen.
• Verfolgen Sie MTTD- und MTTR-Kennzahlen, um Erkennungs- und Antwortlücken zu identifizieren.

Teilen Sie uns Ihr Feedback zum Well-Architected Framework mit.