Comprendre les moteurs de règles d'Olfeo on-premise
La page → contient les moteurs de règles qui pilotent l'ensemble des règles d'actions à appliquer au trafic de vos utilisateurs tout au long du cycle de vie du trafic, depuis l'autorisation de connexion jusqu'à l'analyse de la réponse avant son service à l'utilisateur.
Bien comprendre leur logique et leurs interactions vous permettra de tirer le meilleur parti de votre Olfeo on-premise et de gérer très finement vos politiques de filtrage et de sécurité !
Les moteurs de règles d'Olfeo on-premise sont pilotables depuis la page → et sont composés de deux parties distinctes : un moteur de règles de filtrage "global" et un moteur de politique pour vos utilisateurs.
 |
1. Le moteur de règles global
La partie globale du moteur de règles qui permet d'appliquer des règles générales applicables aux différents moments du cycle de vie d'une requête : accès à la ressource (Accès) > analyse de la réponse (Contenu).
 |
L'onglet Accès permet de traiter les requêtes. Il pilote les actions à appliquer (ou non) et les modalités de filtrage pour accéder aux destinations.
L'onglet Contenu permet de traiter les réponses reçues. Il pilote les règles d'analyse une fois la réponse reçue totalement.
Il permet ainsi de définir des règles d'authentification spécifiques (via un portail captif par ex.), pour des plages 'IP données par ex. ou encore de présenter votre charte internet interne avant l'application des politiques de filtrage par utilisateur.
Il permet également de définir le comportement de l'antivirus sur la réponse reçue du serveur distant (nécessite la licence Antivirus).
2. Le moteur d'application de politiques utilisateurs.
Situé dans la partie "basse" de la page → et adossé à la liste des utilisateurs, ce moteur permet d'appliquer des politiques de filtrage d'URL ou de filtrage applicatif à une unité organisationnelle, un groupe d'utilisateurs, un utilisateur particulier ou même à une adresse ou plage d'IP,
 |
L'application de politiques utilisateur n'a bien sur de sens que si l'accès à la destination demandée est autorisé par le moteur global dans l'onglet Accès ("Pour le reste": "Appliquer la politique utilisateur").
Généralités
Tous les onglets proposent la même logique : un ensemble de règles et une règle terminale ("Pour le reste") qui s'applique par défaut si aucune règle n'a été satistfaite.
|
Une règle est définie par les critères suivants :
Active : Oui / Non -si la règle est inactive, elle est évidemment ignorée par le moteur
Priorité : les flèches permettent de modifier le niveau de priorité d'une règle dans le moteur. Plus elle est haute, plus elle est prioritaire.
Plages horaires : plage horaire pendant laquelle la règle s'applique - par défaut en permanence.
Sources : plages d'IP ou utilisateurs de vos annuaires - par défaut toutes
[spécifique à Accès] Flux : Protocole(s) de la requête (DNS, HTTP ou HTTPS) - par défaut tous.
Destinations: domaines/URLs concernés par la règle - par défaut toutes
[spécifique à Contenu] Contenu : Le contenu de la réponse
Action : l'action à appliquer - celle ci peut varier selon l'onglet, voir ci-dessous
Onglet "Accès"
L'onglet Accès correspond au droit d'accéder à des ressources distantes (pages html, fichiers téléchargés par FTP (via HTTP), vidéos, etc), une fois la connexion avec le serveur établie, et à certaines modalités d'accès à ces ressources.
Note
Pour le protocole HTTP, l'établissement de la connexion et l'authentification transparente (NTLM ou Kerberos) sont paramétrés par ailleurs (en savoir plus sur les modes d'authentification disponibles).
Dans cet onglet vous pouvez, décrire des actions possibles à appliquer selon la source (utilisateurs, IP) l'heure de la journée, le type de flux ou la destination demandée.
Par exemple, vous pourrez décrire ici des règles d'accès pour des machines "sans utilisateurs physiques" ou encore préciser des règles d'accès spécifiques pour les requêtes de mises à jour de postes pour l'ensemble de votre population.
Les actions possibles sont :
Autoriser : l'accès à la requête est permis pour la(les) source(s) désignée(s) et la(les) destinations ciblées par la règle.
Bloquer : l'accès à la requête est refusé pour la(les) source(s) désignée(s) et la(les) destinations ciblées par la règle - attention à la cohérence des règles avec les politiques par utilisateur !
Portail captif / surrogate NTLM : le portail captif sera présenté pour authentification.
Charte internet : la charte internet sera présentée, si elle n'a pas déjà été signée -nécessite d'avoir défini une charte par ailleurs (voir Chartes informatiques).
Attribuer une catégorie : les requêtes répondant à cette règle se verront attribuer un identifiant de catégorie de destination de votre choix, potentiellement différent de celui d'Olfeo.
Réécriture d'URL : tout ou partie de l'URL est réécrite à la volée.
Appliquer la politique : les requêtes répondant à cette règle se voient appliquer une politique précise, sans tenir compte de la logique d'héritage du moteur par utilisateurs - utile pour identifier des utilisateurs depuis un annuaire mais pour leur appliquer des règles localement différentes (par sous-réseau par ex.)
Une fois toutes les règles de l'onglet parcourues, si le champ "Pour le reste" a pour valeur Politique utilisateur, Olfeo passe la requête au moteur de politiques utilisateur et parcourt la liste des utilisateurs (le tableau du bas de la page) afin d'appliquer la politique de filtrage d'URL appropriée.
Onglet "Contenu"
L'onglet Contenu permet de définir des règles d'analyse de contenu à effectuer sur les contenus après qu'ils aient été reçus entièrement par le proxy HTTP (donc s'ils n'ont pas été bloqués par une règle de l'onglet Aperçu).
Les actions possibles
Autoriser
Bloquer
Antivirus
Adossée à la liste des utilisateurs, le moteur de politiques utilisateurs permet d'appliquer des politiques de filtrage d'URL à une unité organisationnelle, un groupe d'utilisateurs, un utilisateur particulier ou même à une adresse ou plage d'IP de vos annuaires.
A l'instar d'une pyramide organisationnelle, le moteur de règles se "lit" de bas en haut : depuis le niveau "utilisateur" (le scope le plus fin) jusqu'à la configuration par défaut (le scope le plus large).
|
Ainsi vous pourrez au sein d'un même service choisir d'appliquer une politique assez restrictive mais pour autant vous pourrez tout de même appliquer une politique particulière plus étendue à un utilisateur précis disposant de prérogatives spécifiques au sein de ce service (le correspondant SSI local de ce service par ex.).
Vous pouvez également visualiser rapidement si une politique est terminale ou dispose renvoie au niveau organisationnel supérieur.
Si vous faites du filtrage protocolaire, vous pouvez également définir des règles de filtrage spécifiques, indépendamment des politiques de filtrage d'URL.
Moteur global
Évaluation des règles
Lorsqu'une requête est reçue par votre Olfeo on-premise, un "contexte" est alors défini en prenant en compte les différents paramètres utilisés par le moteur : source (utilisateur identifié ou IP), type de requête, destination, heure courante, etc.
Chaque onglet du moteur de règles est alors appelé successivement (Connexion > Accès > Aperçu > Contenu) et pour chaque onglet du moteur, les règles sont évaluées successivement de "haut en bas" : dès qu'une règle est satisfaite par le contexte de la requête, elle applique alors les actions définies.
Si le contexte de la requête n'a satisfait aucune règle, c'est alors l'action par défaut qui s'applique.
Soyez donc vigilant dans l'ordonnancement de vos règles !
Cas particulier de sortie du moteur global d'accès : l'action "Appliquer la politique" et sortir
En dehors du cas de la règle terminale, un seul cas peut déclencher la sortie du moteur de règles d'accès, il s'agir de l'action "Appliquer la politique".Ainsi, pour une règle donnée dans le moteur d'Accès, si l'action définie est "Appliquer la politique [nom de la politique] et sortir", le moteur évalue alors directement les règles de la politique (voir ci-dessous) mais dans ce cas-là, aucune gestion d'héritage n'est possible - seules les politiques terminales sont utilisables.
Cette action est utile dans le cas où vous souhaiteriez qu'une politique s'applique arbitrairement dans un contexte donné, indépendamment de celles que vous auriez définies sur votre annuaire dans le moteur de politiques utilisateur. Et ce, tout en conservant vos mécanismes d'authentification et d'identification.
Un cas d'usage par exemple pourrait être l'application de politiques de filtrage "scolaires" que vous souhaiteriez voir appliquer à tout utilisateur naviguant (authentifié ou non) depuis le sous-réseau d'une école, indépendamment de ses propres prérogatives de navigation.
Avertissement
Dans ce cas, aucun héritage ne s'applique. Soyez très vigilant dans la construction de la politique appliquée pour qu'elle soit suffisamment couvrante.
Comment appliquer une politique utilisateur à une règle d'accès ?
Dans le moteur de règles d'accès, sur la règle de votre choix, cliquer sur l’icône d'action (
par défaut si vous créez une nouvelle règle).Sélectionnez "Appliquer la politique utilisateur" et sélectionner la politique de filtrage à appliquer (NB : seules les politiques terminales sont proposées) et validez.
L’icône d'action de la règle est modifiée. Vous pouvez visualiser la politique sélectionnée au survol.
Confirmez votre configuration du moteur de règles en cliquant sur Valider
Moteur de politiques utilisateur
Evaluation des politiques de filtrage d'URL
Les politiques de filtrage d'URL peuvent être appliquées à une requête dans deux cas de figure :
si l'action définie pour une règle dans l'onglet Accès est "Appliquer la politique" (voir ci-dessus).
ou si dans l'onglet Accès du moteur de règles général, le champ Pour le reste a pour valeur Appliquer la politique utilisateur et qu'aucune règle de connexion ou d'accès n'a bloqué le flux.
Dans ce dernier cas, le moteur analyse la pyramide organisationnelle de votre annuaire de "bas en haut" : il vérifie d'abord si une politique est définie au niveau de l'utilisateur. Si aucune politique n'est définie sur l'utilisateur, le moteur vérifie si une politique est définie sur le groupe, et ainsi de suite jusquà la Configuration par défaut tant qu'aucune évaluation n'est satisfaite.
Le moteur pourra potentiellement examiner tous les niveaux de l'arborescence, dans le sens Utilisateur > Groupe > UO/passerelle de l'UO (pour les politiques de filtrage d'URLs) > Configuration par défaut.
Lorsque le moteur a trouvé une politique à appliquer, il évalue les règles à l'intérieur de celle-ci (voir ci-dessous).
Note
Attention à la cohérence des règles du moteur global et celles des politiques utilisateur : vous ne pouvez pas bloquer un flux dans une politique si une règle du moteur global l'a déjà explicitement autorisé (action Autoriser).
Évaluation des règles dans une politique utilisateur
À l'intérieur d'une politique, le moteur parcourt les règles de haut en bas, de la même façon que dans le moteur de règles global. Si le flux ne correspond à aucune des règles, le moteur effectue l'action définie dans le champ "Pour le reste" :
Autoriser : les ressources commencent à être téléchargées : le moteur applique les règles définies dans l'onglet Aperçu.
Bloquer : une page de blocage (/messages.html) est envoyée à l'utilisateur.
Politique supérieure : le moteur évalue la politique appliquée à l'élément parent. Si de nouveau le flux ne correspond à aucune des règles et que le champ Pour le reste de cette politique contient Politique supérieure, le moteur passe à la politique de l'élément parent jusqu'à la "Configuration par défaut".