Salesforce Policy Deviation Checker

Publié en open source par NCC Group Plc - https://www.nccgroup.com/

Développé par Jerome Smith (@exploresecurity) Avec remerciements à Stephen Tomkinson (@neonbunny9)

https://www.github.com/nccgroup/SFPolDevChk

Publié sous licence AGPL - reportez-vous au fichier LICENSE pour plus d'informations.

Description

Dans Salesforce, les politiques de mot de passe et les paramètres de session définis au niveau de l'Organisation peuvent être remplacés par ceux définis au niveau du Profil. Bien que cela soit voulu, toute modification dans ces domaines au sein d'un Profil, même si elle est ensuite annulée pour correspondre aux paramètres de l'Organisation, fait que le Profil est désynchronisé par rapport à l'Organisation. En d'autres termes, les modifications ultérieures des politiques de mot de passe et des paramètres de session au niveau de l'Organisation ne se propageront plus à ces Profils. Avec le temps, à mesure que des Profils sont ajoutés et copiés, cela pourrait conduire à une mauvaise configuration accidentelle pour certains groupes d'utilisateurs. SFPolDevChk révèle quels Profils sont désynchronisés de cette manière, et examine les politiques de mot de passe et les paramètres de session de chacun afin de mettre en évidence tout écart par rapport à ceux définis au niveau de l'Organisation.

Utilisation

Prérequis :

• Python 3
• Le module Python requests (couvert par requirements.txt)
• Un compte utilisateur disposant des permissions minimales suivantes :
  • API Enabled
  • View Setup and Configuration
  • Modify Metadata Through Metadata API Functions (voir note ci-dessous)
• Le mot de passe de ce compte
• Le jeton de sécurité pour ce compte (si vous vous connectez depuis une adresse IP non comprise dans les plages d'accès réseau définies). Reportez-vous à https://help.salesforce.com/articleView?id=user_security_token.htm&type=5 pour plus d'informations.

Créez un fichier de configuration JSON (afin que les identifiants ne restent pas dans l'historique de la console) :

{
	"hostname": "somewhere.my.salesforce.com",
    "username": "",
	"password": "",
	"token": "<optional token>"
	"debug": <optional debug level (0, 1 or 2)>
}

Exécutez ensuite :

git clone https://github.com/nccgroup/SFPolDevChk
pip install -r requirements.txt
python3 sfpoldevchk.py <config_file>

Sortie

Dans l'exemple ci-dessus, la ligne du profil « Read Only » est par ailleurs vide. Cela vient du fait que la politique de mot de passe pour ce profil était, à ce moment-là, identique à celle définie pour l'Organisation. Toutefois, si les paramètres de l'Organisation venaient à changer, les utilisateurs affectés à ce profil ne recevraient pas automatiquement la politique de mot de passe révisée (relancer l'outil mettrait alors en évidence les différences).

Remarques

• Seuls les paramètres pouvant être contrôlés via l'interface utilisateur sont vérifiés.
• Aucun jugement n'est porté sur le fait que les écarts par rapport aux paramètres de l'Organisation soient plus ou moins sécurisés - toutes les différences sont signalées.

Permissions du compte

Cet outil effectue des opérations en lecture seule. Il peut donc être surprenant de voir « 'Modify Metadata Through Metadata API Functions' » comme exigence pour le compte utilisé pour exécuter l'outil. Cependant, au moment de la rédaction, il ne semble pas possible de configurer un compte avec des permissions en lecture seule pour l'API Metadata. Extrait de https://developer.salesforce.com/docs/atlas.en-us.226.0.api_meta.meta/api_meta/meta_quickstart_prereqs.htm :

Identifiez un utilisateur disposant de la permission « API Enabled » et de la permission « Modify Metadata Through Metadata API Functions » ou de la permission « Modify All Data ». Ces permissions sont requises pour accéder aux appels de l'API Metadata. Si un utilisateur a besoin d'accéder aux métadonnées mais pas aux données, activez la permission « Modify Metadata Through Metadata API Functions ». Sinon, activez la permission « Modify All Data ».

Il a donc semblé préférable d'utiliser « Modify Metadata Through Metadata API Functions » comme exigence minimale plutôt que « Modify All Data ». (À titre indicatif, un test a été exécuté avec 'View All Data' - il a échoué.)