Politique de filtrage des requêtes HTTP

HTTP Protocol Filter applique une action selon la méthode et les conditions d’en-tête. Il se configure séparément de l’audit des visites et de la prévention des pertes de données Web. Allow signifie seulement que cette fonction ne bloque pas la correspondance ; d’autres stratégies ou le réseau peuvent empêcher l’accès. Ce guide utilise un pilote Windows ; vérifiez séparément les autres plateformes, navigateurs et connexions chiffrées.

Préparatifs

Utilisez un compte autorisé à configurer les stratégies UEM et vérifiez l’inscription, l’autorisation et la réception sur le pilote. Définissez avec les responsables métier et réseau l’application, les requêtes, la fenêtre de maintenance et la restauration sur place. Le filtrage peut affecter sites, téléversements et interfaces métier. Ne déployez pas immédiatement des règles de refus partout et n’utilisez pas de données sensibles réelles pour les essais.

Configurer et vérifier les règles

1. Dans UEM > Policy, créez ou modifiez une stratégie pilote et vérifiez nom, période et cibles. Activez HTTP Protocol Filter, puis choisissez Settings. Avant modification, vérifiez l’état et l’ordre des règles existantes.
2. Dans Filtering Rules, choisissez Add Rule, renseignez nom, état et Method. Dans Header Conditions, ajoutez les champs, comparaisons et valeurs adaptés. Une valeur de comparaison numérique ne doit contenir que des chiffres, sans signe moins ni séparateur décimal ; un motif générique doit contenir *. Les noms de champ doivent être uniques dans une règle, sans distinction de casse. Pour une requête de test approuvée, sélectionnez par exemple POST, ajoutez une condition Content-Type, choisissez Pattern et saisissez multipart/*, puis enregistrez et vérifiez selon ce chapitre. Content-Length utilise les comparaisons numériques et Content-Type celles de chaînes ; le champ correspondant doit être reconnaissable dans la requête. L’interface propose les méthodes GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT, OPTIONS.
3. Choisissez Action. Privilégiez Allow au premier essai ; testez Block séparément après analyse de l’impact et préparation de la restauration. Les règles sont évaluées dans l’ordre ; la première dont la méthode et toutes les conditions correspondent détermine l’action. Sans condition d’en-tête, une règle peut viser toutes les requêtes reconnaissables de cette méthode et avoir un effet étendu.
4. Enregistrez les réglages et toute la stratégie, contrôlez état, ordre et cibles, puis attendez la réception. Vérifiez les résultats réels avec des requêtes contrôlées correspondantes et non correspondantes. Protégez les connexions métier et d’administration avant un test de refus.

Limites et dépannage

• Cette fonction ne fournit pas de journal d’audit d’en-tête distinct. Analysez le résultat de l’application test, les autres journaux applicables et le réseau ; une absence de journal ne prouve pas une absence de correspondance.
• En cas d’écart, vérifiez autorisation, réception, état, ordre, méthode, champs et valeurs, puis les autres stratégies, le terminal et le réseau. L’enregistrement ne prouve pas l’exécution ni la reconnaissance de tout trafic chiffré ou autre.
• Avant modification ou désactivation, évaluez les dépendances et préparez le retour arrière. En cas d’anomalie, arrêtez le déploiement, restaurez selon les procédures et vérifiez à nouveau.