Restrictions IP et plages de confiance

Salesforce propose deux mécanismes distincts, souvent confondus, pour contrôler l'accès selon l'adresse IP d'origine : les plages IP de confiance au niveau de l'organisation, et les restrictions IP au niveau du profil. Comprendre leur différence de comportement est essentiel car ils ne produisent pas le même effet en cas de connexion hors plage.

1. Plages IP de confiance (Organization-Wide Trusted IP Ranges)

Configurées dans Configuration > Sécurité > Réseau > Plages IP de confiance, elles définissent les IP considérées comme sûres pour toute l'organisation. Leur effet : une connexion depuis une IP dans cette plage ne déclenche pas de vérification d'identité supplémentaire (challenge de sécurité, code d'activation d'appareil), même sans MFA préalablement enregistré sur cet appareil. Une connexion depuis une IP hors de ces plages déclenchera systématiquement une vérification (mais n'est pas bloquée) — c'est un réglage de confort/friction, pas un mécanisme de blocage.

2. Restrictions IP au niveau du profil (Login IP Ranges)

Configurées dans Configuration > Utilisateurs > Profils > sélectionner un profil > Plages d'adresses IP de connexion, elles sont beaucoup plus strictes : toute tentative de connexion en dehors de la plage définie pour ce profil est purement et simplement bloquée, avec un message d'erreur de connexion refusée. Aucun contournement par MFA ou vérification supplémentaire n'est possible — c'est un mécanisme de blocage dur, pas de friction ajustable.

Erreur classique en production : restreindre l'IP sur le profil "Administrateur système" sans prévoir d'accès de secours (VPN de repli, plage bureau + domicile) — un changement de FAI ou une panne réseau peut alors bloquer tous les administrateurs simultanément. Prévoyez toujours un deuxième profil admin sans restriction IP, verrouillé par ailleurs (MFA obligatoire + clé de sécurité physique), pour les scénarios de reprise d'urgence.

3. Login Hours : la troisième dimension

En complément, les Plages horaires de connexion (même écran de profil, "Heures de connexion") restreignent les créneaux temporels autorisés par jour de la semaine. Contrairement aux restrictions IP, une session déjà ouverte au moment où l'heure limite est atteinte devient en lecture seule plutôt que d'être coupée brutalement — l'utilisateur peut terminer de consulter mais plus modifier tant qu'il n'est pas revenu dans une plage autorisée.

4. Cas d'usage typiques

• Sièges sociaux avec IP sortante fixe : restreindre le profil des employés au(x) plage(s) IP du siège et du VPN d'entreprise, bloquant toute connexion depuis un domicile non VPNé pour les profils les plus sensibles (finance, RH).
• Comptes de service/intégration : restreindre l'IP à l'adresse sortante fixe du serveur ou middleware qui consomme l'API, empêchant toute réutilisation du token si les identifiants fuitent.
• Portails externes (Experience Cloud) : les plages IP de confiance s'appliquent aussi aux utilisateurs externes/communauté, utile pour un extranet partenaire avec IP sortante connue.

5. Interaction avec les Connected Apps

Les Connected Apps disposent de leur propre couche de restriction IP, indépendante du profil : dans Gérer les stratégies d'une Connected App, l'option "Relaxer les restrictions IP" peut être réglée sur "Appliquer les restrictions IP à cette connected app" ou "Contourner les restrictions IP configurées sur le profil". C'est un point de contrôle distinct souvent oublié : une restriction IP posée sur le profil peut être invalidée pour une Connected App spécifique si elle est configurée pour contourner ces restrictions — vérifiez cette case en priorité lors d'un audit.

Recommandations de mise en œuvre

1. Commencez par les plages IP de confiance au niveau org pour réduire la friction MFA depuis les bureaux connus.
2. N'appliquez les restrictions IP de profil (blocage dur) qu'aux populations à haut risque, avec un plan de secours documenté.
3. Auditez systématiquement les stratégies IP des Connected Apps lors d'une revue de sécurité — c'est le contournement le plus fréquent.
4. Testez toujours en Sandbox avec un utilisateur hors plage avant de déployer en production, pour valider le comportement (blocage vs vérification) attendu.