Toutes les plateformes de sécurité sont confrontées à la même question fondamentale :
Comment les règles de sécurité doivent-elles être organisées ?
À première vue, il s’agit d’un simple choix de modélisation des données. En pratique, il définit la réalité quotidienne des opérations de sécurité : la rapidité avec laquelle les incidents peuvent être débogués, la sécurité avec laquelle les politiques peuvent évoluer, la facilité avec laquelle de nouveaux bureaux ou de nouvelles communautés d’utilisateurs peuvent être intégrés, et si la croissance mène à la clarté ou au chaos.
Au cours de la dernière décennie, les plates-formes SASE et SSE ont convergé vers un petit ensemble de modèles architecturaux. Ces modèles sont souvent combinés dans des produits réels, mais chacun représente une philosophie de conception distincte avec ses propres forces et modes d’échec.
La compréhension de ces modèles – et des dimensions sur lesquelles ils diffèrent – explique pourquoi les plateformes modernes s’éloignent de la pensée centrée sur le moteur et adoptent des approches plus structurées et plus évolutives.
Dimension 1 : Comment les règles sont-elles regroupées ?
(L’axe principal de l’élaboration des politiques)
1. Base de règles par moteur de sécurité
(Le modèle fragmenté)
Il s’agit de l’approche la plus ancienne et encore largement déployée.
Chaque capacité de sécurité possède sa propre base de règles indépendante :
- Pare-feu
- IDS / IPS
- DLP
- Analyse des logiciels malveillants
- Filtrage des URL et des catégories
- Contrôles SaaS
- Plusieurs garde-fous GenAI / LLM
Dans les environnements modernes, il ne s’agit plus seulement d’une poignée de moteurs. La « sécurité GenAI » à elle seule s’étend à de multiples sous-moteurs spécialisés, tels que :
- détection rapide des injections,
- validation des entrées/sorties de l’outil
- détection du code
- Sécurité du contenu
- Catégorisation et filtrage du contenu
- Sécurité des URL intégrés
- DLP sémantique
Chaque moteur possède sa propre logique de correspondance, ses propres actions, son propre cycle de vie et son propre propriétaire opérationnel.
Points forts
- Un contrôle approfondi et spécialisé
- Une appropriation claire par les experts du domaine
- Évolution indépendante des moteurs de sécurité
Limites structurelles
- Visibilité fragmentée des flux de trafic
- Décisions contradictoires entre les moteurs
- Frais généraux opérationnels élevés
- Faible évolutivité en cas de multiplication des moteurs
Ce modèle reflète les équipes de sécurité cloisonnées et hérite des mêmes défis en matière de coordination et d’opérabilité.
2. Base de règles unique et unifiée
(Le modèle consolidé)
Au fur et à mesure que les plateformes s’unifiaient, nombre d’entre elles ont basculé vers l’extrême opposé : placer toutes les décisions dans un tableau de règles global.
Chaque règle définit
- Conditions de correspondance (utilisateur, application, destination, contexte)
- Références aux profils d’inspection pour les moteurs DLP, malware, GenAI, etc.
Points forts
- Une règle explique une décision
- Faciliter l’audit et le dépannage
- S’inscrit dans la logique de la confiance zéro (« une intention = une règle »)
Limites structurelles
- Les tables de règles deviennent très volumineuses dans les environnements complexes
- Les changements de profil peuvent avoir un large rayon d’action
- Les spécialistes perdent leur autonomie
- La gouvernance devient un goulot d’étranglement
Ce modèle optimise la visibilité et la simplicité, mais il a souvent du mal à s’adapter en toute sécurité aux organisations de grande taille ou à celles qui évoluent rapidement.
3. Base de règles par type de destination
(Le modèle de la destination d’abord)
Une évolution plus récente organise les règles en fonction de la destination du trafic, plutôt que du moteur qui l’inspecte.
Les catégories de destinations typiques sont les suivantes
- Internet
- Applications SaaS
- Applications privées
Chaque type de destination dispose de sa propre base de règles de contrôle d’accès, reflétant différents modèles de confiance, risques et sémantiques. Les règles évaluent toujours des conditions de correspondance riches et produisent une décision d’autorisation ou de refus au niveau de la session, mais le regroupement s’aligne naturellement sur l’intention du trafic.
Points forts
- Séparation claire des intentions d’accès
- Modèle mental plus intuitif pour les administrateurs
- Caractéristiques de performance prévisibles
- Réduction du mélange de logiques politiques sans rapport les unes avec les autres
Limites structurelles
- Ne résout pas, à lui seul, le problème de l’étalement des politiques
- Nécessite une structure supplémentaire pour s’adapter proprement à de grandes organisations
L’organisation basée sur la destination améliore la clarté, mais une autre dimension est nécessaire pour gérer la portée et la réutilisation.
Dimension 2 : Comment les politiques sont-elles définies et réutilisées ?
(Orthogonal au regroupement des règles)
Les modèles suivants répondent à une autre question :
Comment les politiques sont-elles élaborées, réutilisées et appliquées dans différents lieux, utilisateurs ou environnements ?
Ils peuvent être combinés avec n’importe laquelle des approches de regroupement de règles ci-dessus.
4. Profils de configuration
(La politique en tant qu’objet de première classe)
Les profils de configuration introduisent une abstraction de niveau supérieur qui contient la politique, plutôt que d’être la politique elle-même.
Un profil de configuration regroupe généralement les éléments suivants
-
- Une ou plusieurs bases de règles de contrôle d’accès
- Profils d’inspection (logique « autoriser mais scanner »)
Objets de sécurité spécifiques au moteur (objets DLP, contrôles GenAI, signatures IDS, etc.)
Le profil devient une posture de sécurité portable qui peut être appliquée :
- Bureaux physiques
- Régions
- Sites logiques
- Communautés d’utilisateurs
Au lieu d’intégrer une logique d’étendue (comme le site ou la région) dans chaque règle, la politique est étendue en appliquant le profil de configuration approprié.
Pourquoi c’est important
- Réduit l’explosion des règles
- Améliore la lisibilité et la maintenabilité
- Permet des limites RBAC plus claires
- Les changements de politique sont plus sûrs et plus prévisibles
Cette approche est de plus en plus courante dans les plates-formes SASE et SSE modernes, même lorsqu’elles ne sont pas explicitement désignées comme telles.
5. Héritage des politiques
(Modèles de contrôle en couches)
Un autre modèle très répandu, mais souvent implicite, est l’héritage .
Les politiques sont structurées de manière hiérarchique :
- Une base de référence mondiale
- Superpositions régionales ou fonctionnelles
- Priorités spécifiques à un site ou à un groupe
L’héritage permet aux organisations de partager des valeurs par défaut tout en permettant une spécialisation contrôlée.
Compromis
- Puissant mais complexe
- Le débogage nécessite de comprendre l’ordre de résolution
- Un héritage mal conçu peut masquer une politique efficace
L’héritage est souvent combiné avec des profils de configuration pour équilibrer la réutilisation et la clarté.
Réunir les dimensions
Les plateformes de sécurité modernes s’appuient rarement sur un modèle unique.
Au lieu de cela, ils se combinent :
- Organisation des règles en fonction de la destination (clarté de l’intention)
- Profils de configuration (définition et réutilisation des politiques)
- Héritage (spécialisation contrôlée)
- Inspection basée sur le profil (modularité du moteur)
Cette approche stratifiée est le reflet d’une prise de conscience fondamentale :
La complexité de la sécurité ne peut être éliminée, mais seulement structurée.
Où se situe l’IA>Secure
AI>Secure from Aryaka explicite ses choix architecturaux à travers ces deux dimensions :
- Dimension 1 – Organisation des règles : modèle de règles basé sur la destination, organisant le contrôle d’accès autour d’Internet, de SaaS et d’applications privées.
- Dimension 2 – Périmètre et réutilisation des politiques : Approche basée sur les profils de configuration, où les bases de règles d’accès, les profils d’inspection et les objets de sécurité spécifiques au moteur sont regroupés en unités de politique réutilisables et appliqués aux sites logiques.
Au sein de cette structure :
- Chaque règle évalue de nombreuses conditions de correspondance (attributs du réseau, URL et contexte de l’application, identité de l’utilisateur, signaux de réputation).
- Une décision d’autorisation ou de refus au niveau de la session est d’abord prise.
- L‘inspection au niveau des données n’est effectuée que si la session est autorisée, ce qui garantit une application prévisible et une utilisation efficace des moteurs d’inspection approfondie.
- L’intention d’inspection est explicite, par le biais de profils d’inspection attachés à des règles, et non pas implicite par des chaînes de règles cachées.
En combinant l’organisation des règles selon la destination d’abord et le cadrage basé sur le profil de configuration, AI>Secure évite les deux extrêmes :
Fragmentation des bases de règles spécifiques aux moteurs
Extension et rayon d’action d’un tableau de règles unique et global
Pourquoi cette architecture est importante aujourd’hui
L’essor du SaaS, des applications privées et des flux de travail pilotés par la GenAI a fondamentalement modifié les exigences en matière de sécurité :
- Les décisions dépendent d’un contexte plus riche
- L’inspection est coûteuse et doit être intentionnelle
- De nombreux moteurs de sécurité
- La politique doit être modulable en fonction des sites, des utilisateurs et des charges de travail.
L’architecture des règles a dû évoluer en conséquence.
L’avenir de la conception des politiques de sécurité ne réside pas dans la multiplication des règles ou l’utilisation de moteurs plus intelligents. Il s’agit d’une séparation claire des préoccupations, d’une intention explicite et d’architectures qui évoluent sans s’effondrer sous leur propre complexité.
C’est la direction que prend le secteur et la base architecturale sur laquelle repose AI>Secure.