Salesforce Security Review: Checkliste zum Bestehen

Managed 2GPs aus TRIAL Dev Hubs sind nicht erlaubt

Managed 2GPs aus TRIAL Dev Hubs können vom Security-Review-Team nicht geprüft werden.

Stellen Sie sicher, dass Ihr Managed 2GP mit dem Dev Hub in Ihrer Partner Business Org (PBO) erstellt wurde.

Stellen Sie anschließend sicher, dass Sie die Aktivierung Ihrer PBO angefragt haben, damit sie vom Status TRIAL in den Status ACTIVE verschoben werden kann.

Sie müssen einen Case öffnen, "Partner Community & AppExchange" als Produkt und "Security Review" auswählen und die Aktivierung anfragen.

Scanergebnisse für Webanwendungen von Drittanbieter-Domains einreichen 

Ihre Einreichung sollte alle Scanergebnisse für Webanwendungen der Drittanbieter- Domains enthalten, die nicht zu Salesforce gehören und in Ihre App integriert sind.

Fügen Sie alle Nicht-Salesforce-Endpoints in Ihrer Einreichung hinzu, eingeschlossen als composite environment(s), und/oder in den remote site settings Ihrer Salesforce test org. Beispiel https://testapi.net/

Nicht-Salesforce-Domains oder Endpoints gelten als Teil des Security-Review-Scopes, wenn sie in irgendeiner Weise mit Ihrer Salesforce-Komponente integriert sind, etwa wenn Ihre App Callouts dorthin macht, sie Salesforce-Daten speichern oder für andere Zwecke wie Authentifizierung genutzt werden.

Stellen Sie Scanergebnisse eines der zugelassenen Web-Application-Scanning-Tools für alle im Review-Scope befindlichen Sites bereit.

• Zugelassene Scanning-Tools sind OWASP ZAP, Chimera oder Burp Suite.
• Sie müssen alle von OWASP ZAP oder Burp Suite erkannten High-Severity-Probleme beheben.
• Alle in Chimera anders als “Informational/Other” markierten Probleme müssen ebenfalls behoben werden.
• Stellen Sie saubere Scanergebnisse bereit oder ergänzen Sie die Ergebnisse mit Dokumentation, die False Positives erklärt.
• Falls keine Probleme erkannt werden, können Sie alternativ einen Screenshot des gescannten Endpoints bereitstellen.

Stellen Sie notwendige Authentifizierungsdaten bereit, etwa Benutzernamen/Passwörter oder API Keys, die das Security-Review-Team für das Testen dieser externen Integrationen benötigt.

Identity challenge ist aktiviert: Workaround

Identity challenge ist in Ihrer Org aktiviert. Als Workaround müssen Sie die Salesforce-IP-Bereiche safelisten.

Sie können eine neue Org mit zugelassenen IP-Adressen und deaktivierter Multi-Faktor-Authentifizierung (MFA) erstellen, indem Sie den Schritten in diesem Link folgen.

Alternativ folgen Sie den untenstehenden Schritten in Ihrer aktuellen Org:

• MFA mit den folgenden Schritten deaktivieren:
  1. Melden Sie sich in der Org an und gehen Sie zum Setup-Bereich.
  2. Suchen Sie nach “Session Settings” in der Suchleiste oben links.
  3. Gehen Sie zu session settings und dann zu “Session Security Levels”.
  4. Wählen Sie Two-Factor Authentication aus High Assurance und klicken Sie remove.
  5. Klicken Sie unten auf der Seite auf save.
• Safelisten Sie die Salesforce-IP-Bereiche sowie die folgenden Bereiche und Adressen:
  • 13.108.0.0 - 13.111.255.255
  • 62.17.146.0 - 62.17.146.255
  • 85.222.134.0 - 85.222.134.255
  • 104.161.246.0 - 104.161.246.255
  • 182.71.125.154 - 182.71.125.155
  • 182.72.29.238 und 136.232.119.246

Sharing-Regeln in Klassen erzwingen

Erzwingen Sie Sharing in Ihren Klassen, die auf Salesforce-Standardobjekte oder benutzerdefinierte Objekte zugreifen oder diese ändern.

Um diese Schwachstelle zu vermeiden, müssen Sie diese Klassen mit "with sharing" deklarieren.

Hinweis: Sharing wird in der Klasse erzwungen oder nicht erzwungen, die die DML-Abfragen ausführt. Wenn eine Klasse mit sharing eine andere Klasse "without sharing" aufruft und diese die Abfragen ausführt, werden die abgerufenen oder geänderten Objekte ohne Sharing-Erzwingung verarbeitet.

Object (CRUD) und Field Level Security (FLS) werden auf Profilen und Permission Sets konfiguriert und können den Zugriff auf Standard- und benutzerdefinierte Objekte sowie einzelne Felder einschränken. Force.com-Entwickler sollten ihre Anwendungen so gestalten, dass die CRUD- und FLS-Einstellungen der Organisation auf Standard- und benutzerdefinierte Objekte angewendet werden und die Anwendung sauber reagiert, wenn der Zugriff eines Nutzers eingeschränkt ist.

Einige Fälle, in denen das Umgehen von CRUD/FLS akzeptabel sein kann:

• Erstellen von Roll-up-Summaries oder Aggregaten, die Daten nicht direkt offenlegen.
• Ändern benutzerdefinierter Objekte oder Felder wie Logs oder Systemmetadaten, die für Nutzer nicht direkt über CRUD/FLS zugänglich sein sollten.
• Fälle, in denen direkter Zugriff auf das benutzerdefinierte Objekt ein weniger sicheres Sicherheitsmodell erzeugt.

Dokumentieren Sie diese Fälle unbedingt als Teil Ihrer Einreichung.

Sensible Informationen in Debug

Informationen in Debug-Statements können Angreifern helfen, mögliche Angriffsvektoren zu erkennen. Debug-Statements sind wertvoll zur Diagnose von Problemen in der Anwendungsfunktion, dürfen aber keine sensiblen oder zu detaillierten Informationen öffentlich offenlegen, darunter PII, Passwörter, Keys und Stack Traces als Fehlermeldungen.

Sensible oder PII-Daten sollten nicht mit der Methode system.debug geloggt werden.

Sharing-Violation-Schwachstelle

Die Force.com-Plattform nutzt Daten-Sharing-Regeln intensiv. Jedes Objekt kann eigene Berechtigungen haben, die festlegen, welche Nutzer und Profile lesen, erstellen, bearbeiten und löschen können. Diese Einschränkungen werden bei allen Standard Controllers erzwungen. Bei einer benutzerdefinierten Apex-Klasse werden integrierte Profilberechtigungen und Field-Level-Security-Einschränkungen während der Ausführung nicht respektiert. Standardmäßig kann eine Apex-Klasse alle Daten in der Organisation lesen und aktualisieren. Weil diese Regeln nicht erzwungen werden, müssen Entwickler, die Apex verwenden, darauf achten, nicht versehentlich sensible Daten offenzulegen, die normalerweise durch profilbasierte Berechtigungen, Field-Level Security oder organization-wide defaults vor Nutzern verborgen wären. Das gilt besonders für Visualforce-Seiten. Klassen sollten wenn möglich explizit with sharing deklarieren.

Umfassenden Review durchführen

Führen Sie einen umfassenden Review Ihrer Anwendung durch und nutzen Sie die obigen Punkte als Leitfaden, um ähnliche Probleme zu identifizieren. 

In den meisten Fällen kann das Security-Review-Team beim Start der Prüfungen nicht jede einzelne Instanz jedes Schwachstellentyps finden. Daher enthält der Bericht üblicherweise ein Beispiel für jeden gefundenen Schwachstellentyp, und es liegt an Ihnen, Ihre Anwendung auf weitere ähnliche Fälle zu prüfen.

Sicherheitsressourcen erneut prüfen. 

Besuchen Sie die Salesforce Security Resources mit Secure-Coding-Richtlinien, Tools und Trainings sowie die ISV Security Review Resources zur Vorbereitung auf den AppExchange Security Review.

Führen Sie zusätzlich zu manuellen Tests automatisierte Scans mit Tools wie Salesforce Code Analyzer, OWASP ZAP und Checkmarx aus.
Salesforce Code Analyzer - Overview & Guide
Web Application Scanner (ZAP)
Checkmarx - Security Code Scanner

Zusätzliche Ressourcen:

Weitere Informationen finden Sie hier Security Guidelines for Apex and Visualforce Development

Für ausführlichere, interaktive Trainingsmaterialien sehen Sie sich den neuen Trailhead zu ISV Security Review an.

Sie können Warnungen verfolgen, an Diskussionen teilnehmen und Kommentare sowie Fragen in der Security Review Collaboration Group der Partner Community posten.

Erstellen Sie eine an Ihre Lösung angepasste Submission Checklist mit dem Security Review Submission Requirements Checklist Builder.

Wenn Sie eine Package-Version zur Prüfung eingereicht haben und mit Feedback des Security-Teams nicht bestanden haben, beachten Sie vor der Planung eines Follow-up Security Review diese zwei wichtigen Punkte.

1.  Wenn Sie Code geändert haben, der auf der Salesforce-Plattform läuft, müssen Sie eine neue Version Ihres Managed Package hochladen.
   • Klicken Sie in der Publishing Console auf den Tab 'Listings'.
   • Klicken Sie auf Ihr Listing.
   • Verknüpfen Sie Ihre neu hochgeladene Managed-Package-Version mit Ihrem Listing, indem Sie auf den grünen Button 'Select Package' klicken.
   • Gehen Sie zum Tab 'Packages' und klicken Sie auf den Link 'Start Review' neben dem Feld Security Review auf Ihrer neuesten Version.
   • Gehen Sie durch den Security-Review-Wizard und folgen Sie dem normalen Einreichungsprozess.
     
     
2.  Wenn Sie nur Code korrigiert haben, der außerhalb von Salesforce läuft, bearbeiten Sie Ihre vorhandenen Security-Review-Einreichungsinformationen:
   • Klicken Sie in der Publishing Console auf den Tab 'Listings', wenn Ihre App kein Salesforce Package hat, andernfalls auf den Tab 'Packages'.
   • Klicken Sie im Tab 'Listings' auf Ihr Listing oder scrollen Sie im Tab 'Packages' zu Ihrer zuletzt eingereichten Package-Version.
   • Klicken Sie auf den Link "Edit Review", entweder im Tab 'APP' des Listings oder neben der Package-Version im Tab 'Packages'. Der Link kann auch "Submitted" statt "Edit Review" anzeigen.
   • Gehen Sie durch den Security-Review-Wizard und aktualisieren Sie alle geänderten Informationen.
   • Es ist erforderlich, einen Case zu öffnen und "Partner Community & AppExchange" als Product sowie "Security Review" als Topic auszuwählen, damit das Security Review Operations Team weiß, dass Sie Ihr Produkt erneut zur Prüfung einreichen. Fügen Sie Package-Name, ID und Version oder den Listing-Link in die Case-Beschreibung ein.

Wir teilen gern hilfreiche Informationen und empfehlen Ihnen, mehr über unseren Einfluss auf den Salesforce-Release-Zyklus zu erfahren

Demo planen, um mehr darüber zu erfahren, wie Serpent Ihre Salesforce-DevOps-Strategie schon heute stärken kann. Serpent von Tekunda bietet starke Tools für Ihre DevOps-Teams, darunter integrierte Versionskontrolle, Continuous-Deployment- und Release-Systeme, Merge-Tools und viele verschiedene Testing-Tools.