--- schema_version: "1" id: 2b2d4bce29b6c2c272329353feca6d1cd96db92a319c82a1f66e77e55a8d4ac0 title: Gemeinsames Verantwortungsmodell – Muster collection: architect version: current locale: de-de portal_url: https://docs.salesforce.com/architect/current/de-de/well-architected/guides/trust-shared-responsibility-patterns.md canonical_url: https://architect.salesforce.com/docs/architect/de-de/well-architected/guide/trust-shared-responsibility-patterns.html source_site: architect.salesforce.com content_type: documentation content_hash: 6e82ccafdfb0a7e964c5c9b18cc9fd2e658d205a27efec9f40f323ce81906faa products: - Gut strukturiertes Framework - Architect Site Content Repo --- # Gemeinsames Verantwortungsmodell – Muster Weitere Informationen zu Well-Architected [Trust](/docs/architect/de-de/well-architected/guide/trust.html) → [Das Modell der gemeinsamen](/docs/architect/de-de/well-architected/guide/trust.html#the-shared-responsibility-model) Verantwortung ## Grundlegendes zu Plattformverantwortungen **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| Sicherheit | ✅ Architekturdesigns gehen davon aus, dass die Sicherheit, Überwachung und Umweltschutzmaßnahmen für physische Rechenzentren von Salesforce (oder AWS für Hyperforce) übernommen werden | | Plattform \| Sicherheit | ✅ Netzwerksicherheitsdesigns nutzen von der Plattform bereitgestellte DDoS-Abwehr- und Einbruchserkennungssysteme ohne doppelte Investitionen | | Plattform \| Sicherheit | ✅ Die gesamte Datenverkehrsverschlüsselung im Transit (TLS 1.2+) und im Leerlauf (AES-256) wird von der Plattforminfrastruktur bereitgestellt | | Plattform \| Sicherheit | ✅ Plattformhärtung, Schwachstellenverwaltung und Patch-Bereitstellung sind Salesforce-Verantwortlichkeiten; Architekten planen geplante Wartungszeitfenster | | Plattform \| Sicherheit | ✅ Mandantensicherheit und Mandantenisolationsarchitektur stellen sicher, dass die Datentrennung von der Plattform bereitgestellte Garantien sind | | Plattform \| Compliance | ✅ Plattformkonformitätszertifizierungen (SOC 1/2/3, ISO 27001/27017/27018, FedRAMP für Government Cloud-Angebote, HIPAA, PCI DSS, DSGVO) sind unter Trust.salesforce.com und compliance.salesforce.com verfügbar. | | Plattform \| Sicherheit | ✅ Plattformverschlüsselungsservices und Sicherungsinfrastruktur sind von der Plattform verwaltete Funktionen, die Architekten ohne Implementierungsverantwortung nutzen | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| Sicherheit | ⚠️ Architekturdesigns umfassen benutzerdefinierte physische Sicherheitssteuerungen, Schutzmaßnahmen für Netzwerkumfänge oder von der Plattform bereitgestellte Funktionen zur Härtung auf Betriebssystemebene | | Plattform \| Sicherheit | ⚠️ Sicherheitsüberprüfungen stellen die Plattformverschlüsselung im Leerlauf oder die Netzwerksicherheit in Frage, ohne Trust.salesforce.com-Dokumentation zu vorhandenen Steuerelementen zu konsultieren | | Plattform \| Compliance | ⚠️ Compliance-Bewertungen überprüfen Sicherheitskontrollen der Plattforminfrastruktur erneut, statt vorhandene SOC 2/ISO-Zertifizierungen zu nutzen | | Plattform \| Sicherheit | ⚠️ Architektur übernimmt Verantwortung für das Patchen der Plattforminfrastruktur oder die Verwaltung der mandantenübergreifenden Isolation | ## Grundlegendes zu Kundenverantwortungen **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| Identität | ✅ Identitäts- und Zugriffsverwaltung (Rollen, Profile, Berechtigungssätze, MFA, SSO, geringste Berechtigung) werden von Architekten entworfen und konfiguriert | | Plattform \| Identität | ✅ Benutzerlebenszyklus-Verwaltung und Rezertifizierungsprozesse für den Zugriff werden mit dokumentierten vierteljährlichen Überprüfungen implementiert | | Plattform \| Daten | ✅ Datenverwaltung einschließlich Klassifizierung, Maskierung, Objekt-/Feld-/Datensatzebenensicherheit, CRUD-Berechtigungen und Freigaberegeln sind Architektenaufgaben | | Plattform \| Integration | ✅ Integrationssicherheit (OAuth 2.0, JWT-Authentifizierung, Anmeldeinformationen mit Namen, sichere Endpunkte, Validierung des externen Systems) wird von Architekten entworfen und verwaltet | | Plattform \| Sicherheit | ✅ Überwachungs- und Reaktionsfunktionen (Ereignisüberwachung, Audit Trails, SIEM-Integration, Vorfallsreaktionsverfahren) werden von Architekten implementiert | | Plattform \| Entwicklung | ✅ Anwendungssicherheit, einschließlich sicherer benutzerdefinierter Codes (Apex, Lightning), Eingabevalidierung, Injektionsvermeidung und sicherer Entwicklungspraktiken sind Architekten- und Entwicklerverantwortung | | Plattform \| Compliance | ✅ Lösungen behalten den Compliance-Status durch Datenschutz-/Einwilligungsverwaltung, Datenaufbewahrungsrichtlinien und Compliance-Konfiguration bei, die an behördliche Anforderungen angepasst sind | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| Identität | ⚠️ Die Identitäts- und Zugriffsverwaltung wird als "Plattformsicherheit" behandelt, ohne Rollen, Profile, Berechtigungssätze oder MFA-Anforderungen zu entwerfen. | | Plattform \| Daten | ⚠️ Es wird davon ausgegangen, dass die Datenverwaltung von der Plattform bereitgestellt wird. Es ist keine Datenklassifizierung, Freigaberegeln oder Feldebenensicherheit konfiguriert. | | Plattform \| Integration | ⚠️ Integrationssicherheit basiert auf Kontrollen auf Netzwerkebene, ohne OAuth, Anmeldeinformationenverwaltung oder Endpunktvalidierung zu implementieren | | Plattform \| Sicherheit | ⚠️ Überwachung und Vorfallsreaktion werden als Salesforce-Verantwortlichkeiten behandelt. Es gibt keine Ereignisüberwachung, SIEM-Integration oder Antwortverfahren. | | Plattform \| Entwicklung | ⚠️ Die Sicherheit von benutzerdefiniertem Code wird nicht validiert. Es häufen sich Injektionsschwachstellen, fehlende CRUD/FLS-Erzwingung und unsichere Muster | | Plattform \| Compliance | ⚠️ Die Compliance-Konfiguration wird nie implementiert. Lösungen verstoßen trotz Plattformzertifizierungen gegen gesetzliche Anforderungen | ## Verwenden von Plattformzertifizierungen **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| Compliance | ✅ Plattformzertifizierungen (SOC 2 Typ II, ISO 27001, FedRAMP für Government Cloud-Angebote, HIPAA, PCI DSS, DSGVO) werden in der Compliance-Dokumentation als Abdeckung von Infrastrukturaufgaben bezeichnet | | Plattform \| Compliance | ✅ Die Dokumentation zu Trust.salesforce.com und Compliance.salesforce.com für die Plattforminfrastruktursteuerung wird für die Prüfungsvorbereitung verwendet | | Plattform \| Compliance | ✅ Die Konformitätsdokumentation unterscheidet die von der Plattform bereitgestellten Zertifizierungen klar von den vom Architekten implementierten Steuerelementen für benutzerdefinierte Lösungen. | | Plattform \| Architektur | ✅ Benutzerdefinierte Objekte, Apex-Code, Integrationen und Konfigurationen wurden entwickelt, um die Compliance-Position der Plattform beizubehalten | | Plattform \| Compliance | ✅ In der Architekturdokumentation wird explizit dargestellt, wie benutzerdefinierte Lösungen regulatorische Anforderungen erfüllen, während Plattformzertifizierungen genutzt werden | | Plattform \| Compliance | ✅ Regionale Zertifizierungen und Compliance-Anforderungen steuern die Auswahl von Hyperforce-Regionen während der Organisationsbereitstellung | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| Compliance | ⚠️ Es wird davon ausgegangen, dass Plattformzertifizierungen alle Compliance-Verpflichtungen abdecken. Es werden keine benutzerdefinierten Lösungskontrollen implementiert. | | Plattform \| Compliance | ⚠️ Versuche der Prüfungsvorbereitung, Plattforminfrastruktur-Steuerungen erneut zu überprüfen, statt auf vorhandene Zertifizierungen zu verweisen | | Plattform \| Architektur | ⚠️ Benutzerdefinierter Code, Konfigurationen und Integrationen verstoßen gegen die Compliance-Anforderungen, obwohl die Plattform über entsprechende Zertifizierungen verfügt | | Plattform \| Compliance | ⚠️ In der Konformitätsdokumentation werden Plattformzertifizierungen nicht klar von vom Architekten implementierten Kontrollen getrennt | | Plattform \| Compliance | ⚠️ Der Architektur fehlt eine dokumentierte Zuordnung dazu, wie benutzerdefinierte Lösungen den Compliance-Status beibehalten und gleichzeitig Plattformzertifizierungen nutzen | ## Verständnis der Grenzen der Verantwortung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| Sicherheit | ✅ Dokumentzusammenarbeit bei Vorfallsantwortverfahren: Salesforce bietet Plattformerkennung und -reaktion; Architekten bieten Erkennung und Reaktion auf Lösungsebene | | Plattform \| Sicherheit | ✅ Die Verantwortlichkeiten für die Schwachstellenverwaltung sind klar dokumentiert: Salesforce patcht die Plattform; Architekten patchen benutzerdefinierten Code und installierte Pakete | | Plattform \| Sicherheit | ✅ Die Sicherheitsüberwachung kombiniert plattformgenerierte Ereignisse (Ereignisüberwachung) mit vom Architekten konfigurierten Analyse-, Benachrichtigungs- und Antwort-Workflows | | Plattform \| Architektur | ✅ Jedes Designprinzip, jeder Themenabschnitt und jedes Checklistenelement in der Säule Trust wird im Modell für die gemeinsame Verantwortung als Architektenverantwortung behandelt | | Plattform \| Sicherheit | ✅ Designentscheidungen verweisen explizit auf die Grenzen des Modells für die gemeinsame Verantwortung und unterscheiden die von der Plattform bereitgestellten Steuerelemente von den vom Architekten konfigurierten Steuerelementen. | | Plattform \| Architektur | ✅ Architekturentscheidungsdatensätze dokumentieren Verantwortungsgrenzen für Sicherheitskontrollen, Compliance-Anforderungen und Vorfallsreaktionen | | Plattform \| Sicherheit | ✅ Sicherheitsüberprüfungen bestätigen, dass Architektenverantwortungen (Konfiguration, Zugriffssteuerungen, benutzerdefinierter Code) auf der von der Plattform bereitgestellten Grundlage ordnungsgemäß implementiert werden | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| Sicherheit | ⚠️ Bei Vorfallsreaktionsverfahren wird davon ausgegangen, dass Salesforce alle Aspekte verarbeitet. Es sind keine Erkennungs-, Antwort- oder Wiederherstellungsfunktionen auf Lösungsebene vorhanden | | Plattform \| Sicherheit | ⚠️ Die Schwachstellenverwaltung behebt keinen benutzerdefinierten Code. Es werden nur Plattformpatches berücksichtigt. | | Plattform \| Sicherheit | ⚠️ Die Sicherheitsüberwachung basiert vollständig auf plattformeigenen Tools ohne vom Architekten konfigurierte Analyse- oder Antwort-Workflows | | Plattform \| Architektur | ⚠️ Designentscheidungen verweisen nicht auf das Modell der gemeinsamen Verantwortung; es besteht Verwirrung darüber, wer was sichert | | Plattform \| Architektur | ⚠️ Datensätze für Architekturentscheidungen lassen Zuständigkeitsgrenzen aus; Sicherheitsannahmen sind implizit und nicht explizit | | Plattform \| Sicherheit | ⚠️ Bei Sicherheitsüberprüfungen wird davon ausgegangen, dass Plattformzertifizierungen die Sicherheitsverantwortung von Architekten eliminieren | ## Branchenspezifische Compliance-Verantwortung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Gesundheitswesen \| HIPAA | Shield Platform Encryption ist für alle Felder mit geschützten Gesundheitsinformationen aktiviert | | Gesundheitswesen \| HIPAA | ✅ Das Feld-Aktivierungsprotokoll ist so konfiguriert, dass es die Aufbewahrungspflicht von HIPAA für die Verfolgung des PHI-Zugriffs erfüllt (bestätigen Sie den aktuellen Zeitraum entgegen der geltenden Verordnung). | | Gesundheitswesen \| HIPAA | ✅ Die Ereignisüberwachung ist so konfiguriert, dass nicht autorisierte PHI-Zugriffsmuster mit an Sicherheitsteams weitergeleiteten Benachrichtigungen erkannt werden | | Gesundheitswesen \| HIPAA | ✅ Die gemäß der HIPAA-Sicherheitsregel erforderlichen technischen Sicherungen (Zugriffssteuerungen, Überwachungsprotokollierung, Übertragungssicherheit) werden durch die Architekturkonfiguration implementiert | | Finanzen \| SOX/PCI | ✅ Die Aufgabentrennung wird durch das Berechtigungssatzdesign implementiert, das verhindert, dass einzelne Benutzer Finanztransaktionen erstellen und genehmigen | | Finanzen \| PCI DSS | ✅ Vollständige primäre Accountnummern (PAN) werden nach Möglichkeit aus Salesforce herausgehalten und zur Reduzierung des Umfangs über Zahlungsabwickler tokenisiert. Wenn PAN gespeichert werden muss, verwendet es verschlüsselte benutzerdefinierte Felder unter PCI-DSS-Steuerelementen. | | Datenschutz \| DSGVO/CCPA | ✅ Die Einwilligungsverwaltung wird mit detaillierten Workflows zur Verfolgung und Widerrufung von Einwilligungen pro Zweck implementiert | | Datenschutz \| DSGVO/CCPA | ✅ Workflows für Rechte betroffener Personen (Zugriff, Berichtigung, Löschung, Übertragbarkeit) werden innerhalb des Antwortfensters abgeschlossen, das durch die für Ihre Bereitstellung geltenden Verordnungen festgelegt ist | | Datenschutz \| DSGVO/CCPA | ✅ Die Datenaufbewahrungsautomatisierung bereinigt Daten, wenn die Einwilligung abläuft oder Aufbewahrungszeiträume enden | | Regierung \| FedRAMP | ✅ Salesforce Government Cloud wird für regulierte behördliche Arbeitslasten verwendet, die die Einhaltung von FedRAMP erfordern | | Regierung \| FedRAMP | ✅ Steuerelemente vom Typ NIST 800-53 werden der Salesforce-Konfiguration mit dokumentierter Implementierung für jedes entsprechende Steuerelement zugeordnet | | Regierung \| FedRAMP | ✅ Kontinuierliche Überwachung mit Ereignisüberwachung wird an die SIEM-Infrastruktur der Regierung zur Echtzeiterkennung von Bedrohungen weitergeleitet | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Gesundheitswesen \| HIPAA | ⚠️ PHI wird in standardmäßig verschlüsselten Feldern ohne Shield Platform Encryption oder Field Audit Trail gespeichert | | Gesundheitswesen \| HIPAA | ⚠️ Die Ereignisüberwachung ist nicht so konfiguriert, dass nicht autorisierter PHI-Zugriff erkannt wird. Verstöße treten unerkannt auf | | Finanzen \| SOX/PCI | ⚠️ Einzelne Benutzer können Finanztransaktionen erstellen und genehmigen. Die Aufgabentrennung wird nicht erzwungen | | Finanzen \| PCI DSS | ⚠️ Vollständige primäre Accountnummern (PAN) werden in standardmäßigen Salesforce-Feldern ohne Verschlüsselung gespeichert, statt die Tokenisierung des Zahlungsabwicklers oder PCI DSS-konforme verschlüsselte Speicherung zu verwenden | | Datenschutz \| DSGVO/CCPA | ⚠️ Die Einwilligungsverwaltung wird nicht implementiert; Daten werden ohne granulare Einwilligungs- oder Widerrufsfunktionen verarbeitet | | Datenschutz \| DSGVO/CCPA | ⚠️ Anfragen zu Rechten betroffener Personen werden manuell über das Rechtsteam bearbeitet, statt dass die Automatisierung auf das Antwortfenster der Verordnung zugeschnitten ist | | Datenschutz \| DSGVO/CCPA | ⚠️ Die Datenaufbewahrung erfolgt manuell; die Daten werden auf unbestimmte Zeit gesammelt, obwohl die Einwilligung abgelaufen ist oder der Aufbewahrungszeitraum abgeschlossen ist | | Regierung \| FedRAMP | ⚠️ Regulierte Regierungsarbeitslasten werden in kommerziellen Salesforce-Instanzen statt in Government Cloud ausgeführt | | Regierung \| FedRAMP | ⚠️ Bei NIST 800-53-Steuerelementen fehlt die dokumentierte Zuordnung zur Salesforce-Konfiguration; es bestehen Konformitätslücken | | Regierung \| FedRAMP | ⚠️ Die Ereignisüberwachung wird nicht an das staatliche SIEM weitergeleitet. Die Anforderungen an die kontinuierliche Überwachung werden nicht erfüllt | ## Inventar des Sicherheitsvermögenswerts **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| Sicherheit | ✅ Benutzer mit wichtigen Systemberechtigungen (Alle Daten anzeigen, Alle Daten modifizieren, Benutzer verwalten) werden inventarisiert und als Vermögenswerte mit erhöhten Berechtigungen verfolgt | | Plattform \| Shield-Ereignisüberwachung | ✅ Die Ereignisüberwachung erfasst Ereignisprotokolle für Anmeldungen, Berichts- und Datenexporte, Berechtigungsänderungen und API-Aufrufe zur Sicherheitsanalyse | | Plattform \| Shield-Ereignisüberwachung | ✅ Ereignisüberwachungsprotokolle werden zur Korrelation mit Nicht-Salesforce-Sicherheitsereignissen an eine externe SIEM-Plattform weitergeleitet | | Integration \| SIEM | ✅ SIEM-Korrelationsregeln erkennen eine Berechtigungseskalation, beispielsweise Berechtigungsänderungen außerhalb genehmigter Änderungsfenster und API-Volumenanomalien oberhalb des Basiswerts | | Integration \| SIEM | ✅ SIEM-Dashboards bieten Einblicke in Änderungen an Sicherheitsdatenbeständen, beispielsweise Gewährungen für berechtigte Benutzer und Datenexporte | | Plattform \| Dokumentation | ✅ Das Inventar von Sicherheitsvermögenswerten wird mit Vermögenswertkategorien (Benutzern, Daten, Integrationen, Paketen, Konfigurationen), Inhabern und Überprüfungsrhythmus dokumentiert | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| Sicherheit | ⚠️ Das Inventar der Sicherheitsdatenbestände wird manuell in Tabellenblättern verwaltet, die sofort nach der Erstellung veraltet sind | | Plattform \| Sicherheit | ⚠️ Sicherheitsdatenbestände werden über Tribal Knowledge verfolgt, ohne dass dokumentiertes, abfragbares Inventar bei Vorfällen verfügbar ist | | Plattform \| Sicherheit | ⚠️ Sicherheitsüberprüfungen werden nur während jährlicher Compliance-Überprüfungen ohne kontinuierliche Überwachung zwischen Prüfungen durchgeführt | | Plattform \| Sicherheit | ⚠️ Das Inventar von Sicherheitsdatenbeständen wird erfasst, aber nie überprüft. Ruhende Accounts, verwaiste Integrationen und übermäßige Berechtigungen bleiben unbegrenzt bestehen | | Plattform \| Sicherheit | ⚠️ Offizielle Integrationsbenutzer werden verfolgt, Geschäftseinheiten erstellen jedoch verbundene Ad-hoc-Anwendungen, die Sicherheitsüberprüfungs- und Anmeldeinformationsrotationsrichtlinien umgehen | | Plattform \| Shield-Ereignisüberwachung | ⚠️ Die Ereignisüberwachung ist aktiviert, Ereignisse werden jedoch nicht an SIEM weitergeleitet. Sicherheitsereignisse bleiben in Salesforce ohne Korrelation isoliert | | Plattform \| Integration | ⚠️ Schatten-IT-Integrationen umgehen die Inventarverfolgung; nicht autorisierte API-Aktivitäten führen zu Datenexfiltrationsrisiken |