Checklist Salesforce Security Review : réussir

Les 2GP managés créés depuis des TRIAL Dev Hubs ne sont pas autorisés

Les 2GP managés créés depuis des TRIAL Dev Hubs ne peuvent pas être examinés par l’équipe Security Review.

Assurez-vous que votre 2GP managé a été créé avec le Dev Hub de votre Partner Business Org (PBO).

Assurez-vous ensuite d’avoir demandé l’activation de votre PBO afin qu’il puisse passer de l’état TRIAL à l’état ACTIVE.

Vous devez ouvrir un case, sélectionner "Partner Community & AppExchange" comme produit et "Security Review", puis demander l’activation.

Inclure les résultats de scan d’application web pour les domaines tiers 

Votre soumission doit inclure les résultats de scan d’application web pour les domaines tiers non Salesforce intégrés à votre app.

Ajoutez tous les endpoints non Salesforce dans votre soumission, inclus comme environnement(s) composite(s), et/ou dans les remote site settings de votre org de test Salesforce. Exemple https://testapi.net/

Les domaines/endpoints non Salesforce sont considérés dans le périmètre du Security Review s’ils sont intégrés à votre composant Salesforce d’une quelconque façon, par exemple si votre app effectue des callouts vers eux, s’ils stockent des données Salesforce ou s’ils sont utilisés à d’autres fins comme l’authentification.

Fournissez les résultats de scan de l’un des outils de scan d’application web approuvés pour tous les sites dans le périmètre de la revue.

• Les outils de scan approuvés incluent OWASP ZAP, Chimera ou Burp Suite.
• Vous devez corriger tout problème de sévérité élevée détecté par OWASP ZAP ou Burp Suite.
• Tous les problèmes labellisés autrement que “Informational/Other” dans Chimera doivent aussi être corrigés.
• Fournissez des résultats de scan propres, ou complétez les résultats par une documentation expliquant les faux positifs.
• À défaut, si aucun problème n’est détecté, fournissez une capture d’écran de l’endpoint scanné.

Fournissez toutes les informations d’authentification nécessaires, comme les identifiants ou clés API, dont l’équipe Security Review pourrait avoir besoin pour tester ces intégrations externes.

Identity challenge activé : solution de contournement

Identity challenge est activé sur votre org. Comme solution de contournement, vous devrez ajouter les plages IP Salesforce à une safelist.

Vous pouvez créer une nouvelle org avec les adresses IP autorisées et l’authentification multifacteur MFA désactivée en suivant les étapes dans ce lien.

Sinon, suivez les étapes ci-dessous dans votre org actuelle :

• Désactivez MFA avec les étapes suivantes :
  1. Connectez-vous à l’org et allez dans la section setup.
  2. Recherchez “Session Settings” dans la barre de recherche en haut à gauche.
  3. Allez dans session settings, puis “Session Security Levels”.
  4. Sélectionnez Two-Factor Authentication dans High Assurance et cliquez sur remove.
  5. Cliquez sur save en bas de la page.
• Ajoutez les plages IP Salesforce ainsi que les plages et adresses suivantes à la safelist :
  • 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 et 136.232.119.246

Appliquer les règles de sharing dans les classes

Appliquez le sharing dans vos classes qui accèdent ou modifient les objets Salesforce standard ou personnalisés.

Pour éviter cette vulnérabilité, vous devez déclarer ces classes avec "with sharing".

Remarque : le sharing est appliqué ou non dans la classe qui exécute les requêtes DML. Si une classe with sharing appelle une autre classe "without sharing" qui exécute les requêtes, les objets récupérés ou modifiés le seront sans application du sharing.

La sécurité des objets (CRUD) et la Field Level Security (FLS) sont configurées sur les profils et permission sets, et peuvent limiter l’accès aux objets standard et personnalisés ainsi qu’aux champs individuels. Les développeurs Force.com doivent concevoir leurs applications pour appliquer les paramètres CRUD et FLS de l’organisation sur les objets standard et personnalisés, et dégrader proprement l’expérience si l’accès d’un utilisateur est restreint.

Voici des cas où il peut être acceptable de contourner CRUD/FLS :

• Créer des roll up summaries ou agrégats qui n’exposent pas directement les données.
• Modifier des objets ou champs personnalisés comme des logs ou des métadonnées système qui ne devraient pas être directement accessibles à l’utilisateur via CRUD/FLS.
• Cas où accorder un accès direct à l’objet personnalisé crée un modèle de sécurité moins sûr.

Veillez à documenter ces cas d’usage dans votre soumission.

Informations sensibles dans Debug

Révéler des informations dans les instructions debug peut aider un attaquant à identifier des vecteurs d’attaque. Les instructions debug sont précieuses pour diagnostiquer les problèmes de fonctionnement d’une application, mais elles ne doivent pas exposer publiquement des informations sensibles ou trop détaillées, notamment PII, mots de passe, clés et stack traces comme messages d’erreur.

Aucune donnée sensible ou PII ne doit être journalisée avec la méthode system.debug.

Vulnérabilité de violation du sharing

La plateforme Force.com utilise largement les règles de partage des données. Chaque objet peut avoir des permissions propres indiquant quels utilisateurs et profils peuvent lire, créer, modifier et supprimer. Ces restrictions sont appliquées lors de l’utilisation de tous les contrôleurs standard. Lorsqu’une classe Apex personnalisée est utilisée, les permissions de profil intégrées et les restrictions de sécurité au niveau champ ne sont pas respectées pendant l’exécution. Par défaut, une classe Apex peut lire et mettre à jour toutes les données de l’organisation. Comme ces règles ne sont pas appliquées, les développeurs utilisant Apex doivent veiller à ne pas exposer par erreur des données sensibles normalement cachées par les permissions de profil, la sécurité au niveau champ ou les valeurs par défaut de l’organisation. C’est particulièrement vrai pour les pages Visualforce. Les classes doivent déclarer explicitement with sharing lorsque c’est possible.

Mener une revue complète

Effectuez une revue complète de votre application en utilisant ce guide pour identifier des problèmes similaires. 

Dans la plupart des cas, lorsque l’équipe Security Review commence ses vérifications, elle ne peut pas identifier chaque occurrence de chaque type de vulnérabilité. Son rapport contient donc généralement un exemple de chaque type de vulnérabilité trouvé, et il vous revient de rechercher d’autres occurrences similaires dans votre application.

Revenir aux ressources de sécurité. 

Consultez les ressources de sécurité Salesforce sur les règles de codage sécurisé, les outils et les formations, ainsi que les ressources ISV Security Review pour préparer le processus de Security Review AppExchange.

En plus des tests manuels, exécutez des scans automatisés avec des outils comme Salesforce Code Analyzer, OWASP ZAP et Checkmarx.
Salesforce Code Analyzer - Overview & Guide
Web Application Scanner (ZAP)
Checkmarx - Security Code Scanner

Ressources supplémentaires :

Plus d’informations ici Security Guidelines for Apex and Visualforce Development

Pour des supports de formation plus approfondis et interactifs, consultez le nouveau trailhead ISV Security Review

Vous pouvez rester informé des alertes, participer aux discussions et publier des commentaires et questions dans le Security Review Collaboration Group de la Partner Community.

Générez une checklist de soumission personnalisée à votre solution avec le Security Review Submission Requirements Checklist Builder.

Si vous avez soumis une version de package à la revue et qu’elle a échoué avec des retours de l’équipe sécurité, tenez compte de ces deux points importants lorsque vous êtes prêt à planifier le suivi du Security Review.

1.  Si vous avez changé du code qui s’exécute sur la plateforme Salesforce, vous devez téléverser une nouvelle version de votre package managé.
   • Depuis la Publishing Console, cliquez sur l’onglet 'Listings'.
   • Cliquez sur votre listing.
   • Liez la nouvelle version téléversée de votre package managé à votre listing en cliquant sur le bouton vert 'Select Package'.
   • Allez dans l’onglet 'Packages' et cliquez sur le lien 'Start Review' à côté du champ Security Review sur votre version la plus récente.
   • Parcourez l’assistant security review et suivez le processus normal de soumission.
     
     
2.  Si vous avez corrigé uniquement du code qui s’exécute en dehors de Salesforce, modifiez les informations de votre soumission security review existante :
   • Depuis la Publishing Console, cliquez sur l’onglet 'Listings' si votre app n’a aucun package Salesforce, sinon cliquez sur l’onglet 'Packages'.
   • Cliquez sur votre listing dans l’onglet 'Listings' ou, si vous êtes dans l’onglet 'Packages', faites défiler jusqu’à la version de package la plus récemment soumise.
   • Cliquez sur le lien "Edit Review", soit dans l’onglet 'APP' du listing, soit à côté de la version du package dans l’onglet 'Packages'. Le lien peut aussi indiquer "Submitted" au lieu de "Edit Review".
   • Parcourez l’assistant security review et mettez à jour les informations modifiées.
   • Il est obligatoire de log a case et de sélectionner "Partner Community & AppExchange" comme Product et "Security Review" comme Topic pour informer l’équipe Security Review Operations que vous soumettez à nouveau votre produit. Incluez le nom, l’ID et la version de votre package, ou le lien du listing, dans la description du case.

Nous sommes heureux de partager toute information utile et vous recommandons d’en savoir plus sur notre impact sur le cycle de release Salesforce

Planifier une démo pour découvrir comment Serpent peut renforcer votre stratégie Salesforce DevOps dès aujourd’hui. Serpent de Tekunda propose d’excellents outils pour aider vos équipes DevOps, notamment le contrôle de version intégré, les systèmes de déploiement continu et de release, les outils de merge et de nombreux outils de test.