Gemeinsames Verantwortungsmodell – Muster
Weitere Informationen zu Well-Architected Trust → Das Modell der gemeinsamen Verantwortung
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 |
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 |
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 |
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 |
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 |
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 |