Transaction Security Policies : détecter les comportements à risque

Les Transaction Security Policies, module de Salesforce Shield reposant sur le Real-Time Event Monitoring, permettent de définir des règles qui s'exécutent au moment même où un événement se produit (connexion, export de rapport, appel API) et de déclencher une action immédiate : notification, blocage, ou exigence de vérification MFA supplémentaire. Contrairement à l'analyse a posteriori des Event Log Files, l'action est prise en temps réel, avant que la conséquence ne soit irréversible.

1. Les événements pouvant déclencher une politique

• ReportEvent : export d'un rapport, avec le nombre de lignes exportées comme critère de seuil.
• LoginEvent : connexion, avec l'IP, la géolocalisation et le type d'appareil comme critères.
• SessionHijackingEvent : détection de changement suspect de contexte de session.
• ApiAnomalyEvent / ApiEvent : usage API anormal, y compris via l'intégration Einstein pour la détection d'anomalie basée sur le comportement historique de l'utilisateur.
• BulkApiResultEvent / ListViewEvent : extraction de données en masse via Bulk API ou vues de liste.

2. Configurer une politique

Deux approches selon la complexité :

1. Politiques simples (Configuration > Sécurité > Transaction Security Policies) : basées sur un type d'événement standard avec un seuil configurable directement dans l'UI (ex. "bloquer si un export de rapport dépasse 10 000 lignes").
2. Politiques Apex avancées : une classe Apex implémentant l'interface TxnSecurity.PolicyCondition évalue une logique métier complexe (croisement de plusieurs critères, appel à un service tiers de scoring de risque) et retourne vrai/faux pour déclencher l'action associée.

3. Les actions disponibles en réponse

• Bloquer : empêche l'action en cours (ex. empêcher l'export d'un rapport).
• Exiger une vérification à deux facteurs : force une étape MFA supplémentaire avant de laisser passer l'action, même en session déjà authentifiée.
• Notifier : envoie un email ou déclenche un Flow/Platform Event vers un système de SIEM ou de ticketing, sans bloquer l'utilisateur — utile en phase de calibrage avant de passer en mode bloquant.
• Forcer la déconnexion de la session en cas de détection de détournement.

Démarrez toujours en mode "Notifier seulement" pendant 2 à 4 semaines avant de passer une politique en mode bloquant. Un seuil mal calibré (ex. bloquer tout export de plus de 500 lignes) peut interrompre des processus métier légitimes et générer une vague de tickets support le jour du déploiement.

4. Exemple concret : contrer l'exfiltration de données

Scénario fréquent en audit de sécurité : un compte utilisateur compromis (phishing réussi malgré la MFA via un token volé) tente d'exporter l'intégralité de la base de contacts. Une politique combinant :

1. Seuil sur ReportEvent : plus de 5 000 lignes exportées en une seule opération.
2. Action : Bloquer + notification immédiate à l'équipe sécurité via email et Platform Event vers le SIEM.

permet de couper l'export avant qu'il ne se termine, alors qu'une détection uniquement basée sur l'analyse des Event Log Files (délai de plusieurs heures) aurait laissé le temps à l'attaquant de récupérer les données bien avant toute alerte humaine.

5. Limites et prérequis

• Nécessite une licence Salesforce Shield (ou certains événements inclus selon l'édition Enterprise/Unlimited avec add-on).
• Les politiques Apex avancées demandent une compétence de développement et des tests rigoureux : une exception non gérée dans la classe de condition peut faire échouer silencieusement la politique.
• Trop de politiques actives simultanément complexifient le diagnostic en cas de blocage inattendu — documentez chaque politique active avec son objectif et son seuil dans un registre partagé avec l'équipe support.