# Politique de filtrage des requêtes HTTP

Canonical: https://www.nsecsoft.com/fr/docs/ping64-endpoint-management/uem/network/http-filter/

Language: fr-FR

Updated: 2026-11-15T03:27:25.702007Z

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.