Simplifiez la sécurité : Rationalisez les politiques dans Unified SASE

Le service Secure Access Service Edge (SASE), ainsi que l’architecture qui lui est associée, est un puissant amalgame de multiples composants de sécurité.
Il s’agit notamment d’un pare-feu à inspection dynamique, d’un système de détection et de prévention des intrusions (IDPS), d’une sécurité DNS, d’une protection DoS/DDoS, d’une passerelle Web sécurisée (SWG), d’une architecture de réseau de confiance zéro (ZTNA), d’un courtier de sécurité d’accès au nuage (CASB), et bien d’autres encore.
Ces composants permettent aux administrateurs de les configurer par le biais de politiques, offrant ainsi un bouclier solide pour protéger les actifs d’une organisation contre les menaces tout en adhérant à des exigences d’accès spécifiques.

Le rôle de la configuration des politiques

La configuration des politiques joue un rôle indispensable dans l’application de la sécurité dans le cadre de SASE.
Les répercussions de politiques mal configurées peuvent aller des menaces sur les ressources et des fuites de données à un accès involontaire et trop permissif.
Dans le paysage industriel actuel, les organisations sont confrontées à deux approches prédominantes de la gestion des politiques de sécurité :

1. L’approche du tableau unique : Une table de politiques consolidée contenant une myriade de politiques qui couvrent la gestion des menaces et divers scénarios de contrôle d’accès à travers tous les composants SASE.
2. L’approche multi-tables : Plusieurs tables de politiques, chacune traitant d’aspects spécifiques tels que la protection contre les menaces, le contrôle d’accès, les différentes applications et les groupes d’utilisateurs.

Trouver un équilibre dans la gestion des politiques

Les attentes à l’égard du SASE sont claires : il doit offrir des politiques de sécurité faciles à gérer et des procédures de dépannage simplifiées.
Pour y parvenir, il est nécessaire d’adopter une approche équilibrée.
Une stratégie efficace pour atténuer la complexité de la politique est basée sur les exigences de l’organisation.
Les grandes organisations peuvent exiger une compartimentation avec une approche multi-table où la granularité de la table de politique est définie sur la base des fonctions de sécurité, des ressources d’application et du sujet (utilisateurs/groupes).
Les organisations plus petites peuvent préférer une compartimentation avec un nombre inférieur de tables de règles combinant plusieurs types de contrôles d’accès ou même combinant la protection contre les menaces avec le contrôle d’accès.
Cette approche flexible minimise le nombre de politiques nécessitant une gestion simultanée, ce qui les rend plus faciles à gérer.
Cependant, il est important de faire preuve de prudence afin d’éviter un cloisonnement excessif, qui peut engendrer son propre lot de difficultés.
Les administrateurs peuvent être amenés à naviguer dans plusieurs tables de politiques pour identifier et traiter les problèmes, ce qui peut entraîner des retards dans la résolution des problèmes.

Comprendre les principales exigences

Avant d’entrer dans les détails de la gestion des politiques, il est essentiel de comprendre les exigences spécifiques auxquelles les organisations doivent répondre dans le cadre de SASE.
Les domaines clés sont les suivants :

Nécessité d’une gestion de la configuration de la sécurité basée sur les rôles dans les environnements SASE

Les composants Secure Access Service Edge (SASE) offrent une sécurité complète, englobant la protection contre les menaces et le contrôle d’accès pour un large éventail de ressources au sein de diverses organisations, y compris leur personnel, leurs partenaires et leurs invités.
Dans ce cadre de sécurité, les organisations ont souvent des catégories distinctes d’administrateurs responsables de différents aspects de la sécurité.
Par exemple, une organisation peut avoir un groupe d’administrateurs dédié à la gestion de la protection contre les menaces tandis qu’un autre groupe se concentre sur les contrôles d’accès.
Au sein de ces grandes catégories, il est courant que les organisations établissent divers rôles administratifs adaptés à des types spécifiques de protection contre les menaces et de contrôle d’accès.
Voyons quelques exemples pratiques :

Rôles de protection contre les menaces :

• Configuration de la détection d’intrusion et du pare-feu : Les administrateurs ayant le rôle « threat-protection-ngfw-role » ont accès à la configuration de la détection d’intrusion et des paramètres du pare-feu dans l’environnement SASE.
• Contrôles de réputation : Les administrateurs ayant le rôle « threat-protection-reputation-role » peuvent gérer les paramètres liés aux contrôles de réputation IP, aux contrôles de réputation basés sur les URL, aux contrôles de réputation basés sur les domaines, aux contrôles de réputation des fichiers, ainsi qu’aux contrôles de réputation des services en nuage et des organisations en nuage.
• Protection contre les logiciels malveillants : Les administrateurs ayant le rôle « threat-protection-malware-protection-role » sont habilités à configurer les paramètres concernant spécifiquement les contrôles de protection contre les logiciels malveillants.

Rôles de contrôle d’accès :

• Configuration SWG : Les administrateurs désignés comme « access-control-Internet-role » sont responsables de la gestion des configurations de la passerelle Web sécurisée (SWG).
• Contrôle d’accès spécifique aux applications SaaS : Les rôles tels que « access-control-saas1app-role » et « access-control-saasNapp-role » se concentrent sur la configuration des politiques de contrôle d’accès pour des applications spécifiques (SaaS Service 1 et SaaS Service N), garantissant un contrôle fin.
• Gestion des applications d’entreprise : Les rôles tels que « access-control-hostedapp1-role » et « access-control-hostedappM-role » sont dédiés à la gestion des configurations de contrôle d’accès pour les applications d’entreprise, app1 et appM.

Dans les cas où une organisation utilise des applications multi-locataires, des rôles supplémentaires peuvent être introduits pour gérer efficacement les configurations de sécurité.
Par exemple, des rôles peuvent être établis pour configurer des politiques pour le personnel de l’organisation, le personnel par locataire et même les invités.
Prenons l’exemple d’une application « X » dont les configurations de sécurité sont gérées par différents groupes d’administrateurs :

• Sécurité du personnel du propriétaire : Les administrateurs ayant le rôle « access-control-hostedappX » et le rôle « access-control-owner-workforce-role » collaborent pour gérer les configurations de contrôle d’accès à l’application « X » pour le personnel du propriétaire.
• Effectif spécifique au locataire de l’application pour le locataire : Des rôles tels que « access-control-hostedAppX-role » et « access-control-owner-tenantA-workforce-role » permettent aux administrateurs de configurer les paramètres de contrôle d’accès pour le personnel du locataire A.
• Application Effectif spécifique au locataire B : Pour une application multi-locataire « X », divers rôles, tels que « access-control-hostedAppX-role » et « access-control-owner-tenantB-workforce-role », facilitent la gestion des configurations de contrôle d’accès pour le personnel du locataire B.

En outre, même les applications d’entreprise non multi-locataires peuvent nécessiter des administrateurs distincts pour les différents segments du personnel.
Par exemple :

• Service d’ingénierie : Les administrateurs ayant le rôle « access-control-hostedappY » et « access-control-eng-role » se concentrent sur la gestion des configurations de contrôle d’accès pour l’application « Y » au sein du département d’ingénierie.
• Ventes et marketing : Les rôles tels que « access-control-hostedappY-role » et « access-control-sales-role » sont destinés à configurer les paramètres de contrôle d’accès pour les équipes de vente et de marketing.
• Département informatique : Les administrateurs ayant le rôle « access-control-hostedappY » et « access-control-it-role » sont responsables des configurations de contrôle d’accès relatives au département informatique.

L’un des principaux avantages de la gestion de la configuration de la sécurité basée sur les rôles est sa capacité à fournir un contrôle granulaire adapté à des responsabilités spécifiques.
Comparez cette approche aux problèmes qui peuvent survenir lors de l’utilisation d’une table de politiques unique et globale :

• Propice aux erreurs : Plusieurs administrateurs travaillant avec la même table de politiques et des autorisations qui se chevauchent peuvent introduire par inadvertance des erreurs lors de l’ajout, de la suppression ou de la modification de politiques.
• Complexité du dépannage : La résolution des problèmes au sein d’une table de politiques monolithique peut prendre du temps et s’avérer difficile.
• Surcharge de politiques : La consolidation de toutes les politiques dans un tableau unique, couvrant diverses applications et scénarios de protection contre les menaces, peut entraîner une gestion lourde et peu pratique des politiques, ainsi que des problèmes de performance potentiels lors de l’évaluation des politiques.

En conclusion, l’adoption d’une gestion de la configuration de la sécurité basée sur les rôles dans les environnements SASE permet aux organisations de déléguer efficacement les responsabilités, de renforcer la sécurité et de rationaliser la gestion des politiques tout en évitant les complexités associées aux approches à table unique.

Collaboration avec la gestion du contrôle des changements de configuration

Les organisations adoptent de plus en plus la gestion du contrôle des changements pour toutes les configurations, y compris les configurations SASE, afin de détecter et de rectifier de manière proactive les erreurs de configuration avant qu’elles ne soient mises en œuvre.
Cette pratique sert non seulement de garde-fou, mais elle introduit également une deuxième couche de contrôle, permettant à une deuxième paire d’yeux d’examiner et d’approuver les configurations avant qu’elles n’entrent en vigueur.
Les configurations de la politique de sécurité sont appliquées directement dans le flux de trafic, ce qui fait que toute erreur dans les politiques peut perturber les services et avoir des conséquences financières directes.
Pour faire face à la complexité inhérente à la configuration de la politique de sécurité, il est courant de sérialiser les changements.
Cela signifie que lorsque l’on modifie un type de configuration, aucune autre session de configuration du même type n’est lancée tant que la précédente n’a pas été appliquée ou révoquée.
Toutefois, lorsqu’on utilise une seule table de stratégies qui englobe toutes les fonctions de contrôle des menaces et des accès, la sérialisation des modifications peut entraîner des retards dans les ajustements de configuration effectués par d’autres administrateurs.
En revanche, une approche multi-tables peut répondre efficacement à ce scénario, en permettant à différents administrateurs de travailler simultanément sur des tables distinctes, ce qui rationalise le processus de modification de la configuration.

Toutes les organisations n’ont pas les mêmes exigences:

Le SASE est généralement proposé en tant que service, et les fournisseurs de SASE peuvent servir plusieurs organisations en tant que clients.
Ces organisations peuvent varier considérablement en termes de taille, d’exigences réglementaires et de diversité des rôles au sein de leurs structures.
Certaines organisations peuvent héberger plusieurs applications, sur site ou dans le nuage, tandis que d’autres peuvent s’appuyer exclusivement sur les services des fournisseurs de SaaS, et d’autres encore peuvent combiner les deux.
En outre, certaines organisations peuvent ne pas avoir besoin de divers rôles administratifs ou de plusieurs utilisateurs administratifs.
Dans les scénarios où les organisations n’ont qu’un nombre limité d’applications et n’ont pas la complexité de rôles administratifs multiples, elles peuvent trouver de la valeur dans l’utilisation d’un nombre réduit de tables de politiques.
SASE devrait être conçu pour offrir la flexibilité nécessaire pour répondre à ces divers besoins, y compris l’option d’utiliser des tableaux de politiques consolidés pour de multiples fonctions et applications de sécurité pertinentes.

Éviter les configurations confuses :

Certaines solutions SASE, dans leur quête de simplification, optent pour une table de politiques unique et globale où les politiques peuvent être configurées avec des valeurs pour divers attributs correspondants.
Pendant le traitement du trafic, la sélection de la politique est basée sur la comparaison des valeurs du trafic entrant et d’autres informations contextuelles avec les valeurs d’attributs spécifiées dans les politiques.
Cependant, il est essentiel de reconnaître qu’au cours du traitement du trafic, tous les attributs du trafic ne sont pas connus d’emblée.
Par exemple, dans le cas des pare-feu à inspection dynamique, seul un ensemble limité de valeurs de trafic peut être extrait, comme les informations du 5-tuple (IP source, IP destination, port source, port destination et protocole IP).
En revanche, pour les composants de sécurité basés sur un proxy tels que SWG, ZTNA et CASB, l’extraction des valeurs d’attribut peut varier et impliquer des étapes distinctes, notamment les phases d’inspection pré-TLS et d’inspection post-TLS.
Avant l’inspection/décryptage TLS, de nombreux attributs HTTP restent inconnus.
Ce n’est qu’après le décryptage TLS que des attributs supplémentaires, tels que le chemin d’accès URI, la méthode HTTP et les en-têtes de requête, deviennent disponibles pour l’évaluation.
En tant qu’administrateurs responsables de la configuration des politiques de sécurité, il n’est pas pratique d’attendre des administrateurs qu’ils gardent la trace des attributs valides aux différentes étapes du traitement des paquets lors de la définition des politiques.
Bien que certaines solutions de sécurité affirment que les attributs non pertinents ne sont pas pris en compte dans l’évaluation de la politique, déterminer quels attributs sont pertinents et lesquels ne le sont pas peut s’avérer difficile lors de l’inspection de politiques complexes.
Nous croyons fermement que l’amalgame des tables de politiques de plusieurs étapes en une seule table crée de la complexité et de la confusion pour les administrateurs.
Une telle approche peut être difficile à comprendre et conduire à des configurations potentiellement déroutantes.
Dans un souci de clarté, il est conseillé de créer des politiques au sein d’une table donnée qui n’incluent que les attributs pertinents pour des évaluations cohérentes et directes.

Optimisation des tables de politiques de refus et d’autorisation :

Certaines solutions de sécurité adoptent une structure dans laquelle elles maintiennent des tables de règles « Deny » et « Allow » séparées.
Dans cette configuration, les règles définies dans la liste « Deny » sont prioritaires et sont évaluées en premier.
Si aucune politique correspondante n’est trouvée dans la table « Deny », l’évaluation passe à la table de politiques « Allow ».
Cependant, cette division des politiques en deux tables distinctes peut poser des problèmes aux administrateurs.
Nous plaidons fermement en faveur d’une approche plus rationnelle, dans laquelle un tableau de politiques donné est présenté sous la forme d’une liste ordonnée de politiques.
Dans cette configuration, chaque politique spécifie explicitement son action, qu’il s’agisse de « Refuser », « Autoriser » ou de toute autre action souhaitée.
Pendant le traitement du trafic, l’évaluation des règles suit une progression logique, de la règle la plus prioritaire à la règle la moins prioritaire, jusqu’à ce qu’une correspondance soit trouvée.
Lorsqu’une politique correspondante est identifiée, l’action correspondante est appliquée au trafic.
Dans les cas où aucune politique correspondante n’est trouvée, une action par défaut, telle que « fail open » ou « fail close », est déclenchée conformément à la politique de sécurité de l’organisation.
Cette approche simplifie la gestion des politiques et améliore la clarté pour les administrateurs en consolidant les politiques dans une liste unique et ordonnée indépendamment des valeurs d’action de la politique, minimisant ainsi la complexité et rationalisant le processus d’évaluation de la politique.
Le fait de ne pas séparer les tableaux de politiques en fonction des valeurs d’action a également permis aux fournisseurs de solutions SASE d’introduire relativement facilement de nouvelles valeurs d’action à l’avenir.

Créer des politiques flexibles et expressives:

Comme vous l’avez compris, les administrateurs élaborent des politiques en définissant des ensembles de valeurs pour les attributs correspondants.
Traditionnellement, il existe une compréhension commune de la manière dont la correspondance des politiques fonctionne lors des évaluations du trafic : une politique est considérée comme correspondante uniquement lorsque toutes les valeurs d’attribut spécifiées dans la politique s’alignent parfaitement sur les valeurs de la session de trafic entrant.
Ces valeurs peuvent être extraites directement du trafic ou déduites d’informations contextuelles, telles que le contexte de l’utilisateur authentifié et le contexte de l’appareil à l’origine du trafic.
Essentiellement, ce processus de mise en correspondance implique une opération « ET » sur tous les attributs de la politique.
Cependant, avec l’évolution des technologies de sécurité, de nombreux dispositifs de sécurité ont introduit une approche plus souple, permettant aux administrateurs d’attribuer plusieurs valeurs aux attributs.
Dans ce nouveau paradigme, une correspondance est établie si les informations sur le contexte d’exécution correspondent à l’une des valeurs spécifiées pour les attributs de la politique.
En substance, le processus de correspondance combine désormais une opération « ET » entre les attributs et une opération « OU » entre les valeurs associées à ces attributs.
Les entreprises bénéficieront grandement de cette flexibilité lors de la création de politiques globales.
Elle réduit le nombre total de politiques requises tout en préservant la lisibilité.
Cependant, ces attributs à valeurs multiples ne sont qu’un pas dans la bonne direction, et d’autres améliorations sont souvent nécessaires pour répondre aux besoins spécifiques des organisations : Prise en charge de la décoration « PAS » : Les administrateurs doivent pouvoir définir des valeurs d’attributs de politique avec une décoration « NOT ».
Par exemple, il devrait être possible de spécifier une valeur d’attribut « source IP » comme « NOT 10.1.5.0/24 », indiquant que la politique correspondra avec succès lorsque l’IP source de la session de trafic n’appartient pas au sous-réseau 10.1.5.0/24. Prise en charge de plusieurs instances d’un attribut : De nombreux dispositifs de sécurité traditionnels ne prennent en charge qu’une seule instance d’un attribut donné au sein d’une politique.
Pour créer des politiques complètes, il est essentiel de pouvoir inclure plusieurs instances d’un même attribut dans une seule politique.
Par exemple, un administrateur peut vouloir autoriser des sessions à partir de n’importe quelle adresse IP du sous-réseau 10.0.0.0/8 tout en refusant simultanément les sessions de trafic provenant du sous-réseau 10.1.5.0/24.
Cela devrait être possible dans le cadre d’une seule politique, peut-être en spécifiant deux fois les valeurs « source IP » : « source IP == 10.0.0.0/8 » et « source IP == NOT 10.1.5.0/24 ».
Cela évite de devoir créer deux politiques distinctes et permet une gestion plus intuitive des politiques. Prise en charge des décorations pour les valeurs de type chaîne : Les attributs qui acceptent des valeurs de type chaîne, tels que les chemins URI, les noms de domaine et de nombreux en-têtes de requête HTTP, bénéficient de décorations telles que « exact », « starts_with » et « ends_with ».
Ces décorations facilitent la création de politiques expressives. Prise en charge des motifs d’expression régulière : Dans certains cas, les politiques nécessitent une correspondance entre les valeurs de trafic et les motifs.
Par exemple, une politique peut stipuler qu’une session de trafic n’est autorisée que si un motif spécifique est présent n’importe où dans la valeur de l’en-tête de requête « user agent ».
La prise en charge des expressions régulières est essentielle dans de tels scénarios. Prise en charge des attributs dynamiques : Alors que les attributs traditionnels des politiques sont fixes et prédéfinis, les environnements SASE nécessitent parfois des attributs dynamiques. Considérez les en-têtes de demande et de réponse ou les revendications JWT, où les normes coexistent avec de nombreux en-têtes et revendications personnalisés.
SASE devrait permettre aux administrateurs de créer des politiques qui tiennent compte des en-têtes et des revendications personnalisés.
Par exemple, SASE devrait permettre la création de politiques avec l’en-tête de requête « X-custom-header » comme attribut et la valeur « matchme ». Au moment du trafic, toutes les sessions HTTP dont l’un des en-têtes de requête est « X-custom-header » et la valeur « matchme » devraient correspondre à la politique. Prise en charge des objets : Cette fonctionnalité permet de créer divers types d’objets dont les valeurs peuvent être utilisées comme valeurs d’attribut dans les politiques, plutôt que de spécifier des valeurs immédiates.
Les objets peuvent être référencés dans plusieurs politiques et tout changement de valeur futur peut être effectué au niveau de l’objet, ce qui simplifie la modification des politiques et garantit la cohérence.
Ces améliorations contribuent à la création de politiques de sécurité flexibles, expressives et efficaces, permettant aux organisations d’adapter efficacement leurs politiques à des besoins et scénarios de sécurité uniques.

Renforcer l’intégration des politiques en modifiant le trafic

Certaines fonctions de sécurité nécessitent des modifications du trafic, les cas d’utilisation les plus courants impliquant l’ajout, la suppression ou la modification des en-têtes de requête/réponse HTTP et de leurs valeurs, des paramètres de requête et de leurs valeurs, voire du corps de la requête/réponse.
Ces modifications peuvent varier considérablement en fonction des configurations des administrateurs.
Souvent, les modifications spécifiques dépendent des valeurs du trafic, telles que l’application de destination/le service du site, ainsi que des informations contextuelles disponibles pendant l’exécution du trafic.
Plutôt que de maintenir une table de règles distincte pour les modifications du trafic, il est souvent plus efficace d’inclure ces objets de modification dans les règles d’accès elles-mêmes.
Cette approche rationalise la gestion des politiques et garantit que les modifications sont directement alignées sur les politiques régissant le comportement du trafic.
Un scénario important dans lequel la modification du trafic est essentielle se trouve dans le contexte des solutions CASB (Cloud Access Security Broker), en particulier lorsque les organisations exigent des restrictions de multi-location.
Ces restrictions impliquent souvent l’ajout d’en-têtes de requête et de valeurs spécifiques pour mettre en œuvre des politiques spécifiques à la collaboration.
En outre, dans d’autres cas, tels que l’ajout d’en-têtes personnalisés pour le dépannage de bout en bout et l’analyse des performances, les modifications du trafic jouent un rôle crucial.
Par conséquent, les entreprises attendent des solutions SASE qu’elles prennent en charge les politiques qui s’intègrent de manière transparente aux objets de modification.
Lors du traitement du trafic, les modifications du trafic sont exécutées lorsque la politique correspondante est associée aux objets de modification appropriés, ce qui permet une approche unifiée et efficace de la gestion du trafic et de l’application des politiques.

Améliorer l’observabilité :

Il est courant d’enregistrer chaque session de trafic à la fin de la session à des fins d’observation.
Dans les cas de sessions importantes ou « éléphantesques », il est également d’usage d’enregistrer périodiquement les informations relatives à l’accès.
Ces journaux de session contiennent généralement des données précieuses, notamment des métadonnées sur le trafic, les actions entreprises au cours de la session et des détails concernant les paquets et les octets transférés entre le client et le serveur.
L’une des avancées significatives offertes par SASE est la consolidation des fonctions de sécurité et l’adoption d’architectures à passage unique et à exécution simultanée, ce qui se traduit par un journal de session unifié.
Cela contraste avec les déploiements de sécurité non SASE où chaque composant de sécurité individuel génère son propre journal de session, qui contient souvent des informations sur la politique qui a été mise en correspondance et les valeurs d’attributs critiques utilisées dans le processus de mise en correspondance.
Il est important de noter que si SASE génère un seul journal, il est attendu qu’il ne compromette pas l’inclusion d’informations critiques.
Lorsqu’une session de trafic est autorisée en raison d’évaluations multiples de politiques dans diverses fonctions de sécurité et tables de politiques, le journal qui en résulte doit contenir des informations sur toutes les politiques qui ont été mises en correspondance.
En outre, si une politique correspond aux valeurs d’attributs spécifiques du trafic ou du contexte, le journal doit fournir des détails précis sur les valeurs d’attributs qui ont conduit à la correspondance de la politique.
Étant donné que les organisations s’appuient sur des journaux complets pour une observabilité efficace, les solutions SASE sont censées fournir des informations complètes dans les journaux, garantissant que les administrateurs ont accès aux données dont ils ont besoin pour surveiller et analyser efficacement le trafic du réseau.

Approche SASE de la gestion des politiques :

Il est important de reconnaître que toutes les solutions SASE ne sont pas identiques.
Les organisations doivent évaluer soigneusement si une solution SASE particulière correspond à leurs exigences organisationnelles spécifiques sans sacrifier la convivialité.
Bien que les organisations puissent ne pas posséder initialement toutes les exigences énumérées ci-dessus, ce n’est qu’une question de temps avant que ces exigences ne deviennent de plus en plus pertinentes et essentielles à leurs opérations.
Les organisations qui possèdent toutes les exigences susmentionnées bénéficient d’une souplesse totale pour adapter leurs politiques de SASE à leurs besoins spécifiques.
D’autre part, les organisations qui n’ont pas encore toutes ces exigences recherchent souvent une expérience utilisateur plus simple tout en gardant à l’esprit l’introduction de fonctionnalités supplémentaires au fur et à mesure de l’évolution de leurs besoins.
Cette approche permet aux organisations de trouver un équilibre entre leurs besoins actuels et leur croissance future, en s’assurant que leur solution SASE reste adaptable et réactive aux circonstances changeantes. Si les solutions SASE n’offrent pas une flexibilité totale, la personnalisation devient un défi.
C’est pourquoi nous pensons que les solutions SASE devraient offrir les capacités de base suivantes :

1. Gestion modulaire des politiques : Les solutions SASE englobent de multiples fonctions de sécurité, chacune avec son propre ensemble de configurations de politiques.
   Ces configurations doivent inclure des options permettant d’activer/désactiver, de définir l’action par défaut en cas d’absence de correspondance entre les politiques, de gérer la collecte de plusieurs tables de politiques, de définir plusieurs politiques dans chaque table de politiques, d’établir une liste ordonnée de politiques et de définir des paramètres d’action, des objets de modification, des attributs de correspondance et des valeurs pour chaque politique.
2. Enchaînement de politiques : Pour permettre des politiques plus spécifiques et plus granulaires, les solutions SASE doivent supporter le chaînage des politiques.
   Cela signifie qu’il est possible d’organiser les politiques dans plusieurs tables de politiques au sein d’une collection.
   Par exemple, les organisations peuvent avoir des tables de politiques distinctes pour différentes applications, les politiques de la table principale utilisant les noms d’application/de domaine comme critères de correspondance pour sélectionner les tables de politiques appropriées.
   Pour ce faire, on utilise généralement des politiques comportant une action appelée « Jump », qui redirige l’évaluation de la politique vers la table de politiques référencée.
   Le concept de chaînage de politiques a gagné en popularité avec les tables IP de Linux, et de nombreuses solutions de sécurité ont par la suite intégré cette fonctionnalité.

L’étendue des fonctions de sécurité au sein de SASE peut être considérable et peut inclure :

• NGFW (pare-feu de nouvelle génération) : Contrôle d’accès L3/L4, protection DDoS, réputation IP, réputation de domaine et système de détection et de prévention des intrusions (IDPS).
• SWG (Secure Web Gateway) : Inspection TLS, contrôle d’accès web pré-TLS, contrôle d’accès web post-TLS, réputation des URL, réputation des fichiers et protection contre les logiciels malveillants.
• ZTNA (Zero Trust Network Access) : Similaire au SWG mais axé sur la sécurisation des applications hébergées.
• CASB (Cloud Access Security Broker) : Couvre la réputation des services en nuage et le contrôle d’accès aux services en nuage.
• DLP (prévention de la perte de données) : Mise en place d’un contrôle d’accès basé sur les informations personnelles identifiables (PII), les documents confidentiels standard et les documents sensibles spécifiques à l’entreprise.

La flexibilité de la gestion des politiques pour chaque fonction de sécurité, ainsi que la capacité de gérer les politiques au sein de chaque fonction par le biais de plusieurs tables de politiques avec chaînage de politiques, est une caractéristique puissante.
Les organisations géo-distribuées ayant diverses exigences réglementaires peuvent particulièrement bénéficier de cette flexibilité.
Toutefois, les organisations plus petites peuvent préférer une certaine consolidation des tables de politiques.
Dans ce cas, il devrait être possible de personnaliser la configuration :

• Consolidation de toutes les configurations des fonctions de sécurité pré-TLS en une seule collection de tables de politiques à travers plusieurs composants SWG/ZTNA.
• Consolidation de toutes les configurations des fonctions de sécurité post-TLS dans une autre collection unique de tables de politiques à travers plusieurs composants SWG/ZTNA.
• Conserver les fonctions CASB, malware et DLP en tant qu’entités distinctes, car elles nécessitent des définitions de politiques complexes.
• Opter pour une table de politiques unique au sein de la collection de tables de politiques, ce qui permet d’éviter le chaînage de politiques.

Par conséquent, les organisations devraient rechercher des services SASE qui offrent une flexibilité totale tout en proposant des contrôles personnalisés afin de consolider les configurations pour les fonctions de sécurité pertinentes.
Cette approche garantit que les politiques de SASE sont adaptées aux besoins spécifiques d’une organisation tout en maintenant la facilité de gestion et l’évolutivité au fur et à mesure que les exigences évoluent.

Équilibrer l’expérience de l’utilisateur et la flexibilité à l’épreuve du temps

La gestion des politiques de sécurité a toujours été une entreprise complexe.
De nombreux produits se spécialisent dans la gestion des politiques pour des appareils de sécurité spécifiques, ce qui entraîne un paysage fragmenté.
SASE s’attaque à cette complexité en consolidant plusieurs appliances de sécurité en une solution unifiée.
Bien que cette consolidation offre des avantages, elle introduit également des complexités propres.
Les approches traditionnelles de la gestion des politiques, telles qu’une table de politiques unique, peuvent sembler attrayantes au départ.
Cependant, elles présentent de nombreux défis et ne répondent souvent pas aux exigences décrites dans cet article.
À l’inverse, un nombre excessif de moteurs de politiques peut également être source de complexité.
Il est essentiel de trouver un juste équilibre entre flexibilité et simplicité.
La prolifération des polices constitue un défi important pour le secteur.
Un nombre excessif de politiques ne dégrade pas seulement l’expérience de l’utilisateur et du dépannage, mais a également des répercussions sur les performances.
L’approche multi-tables et l’expressivité des politiques, telles que décrites précédemment, sont des stratégies essentielles pour réduire le volume de politiques dans les tables de politiques.
Les solutions SASE s’attaquent de plus en plus à ces complexités en offrant une plus grande sophistication dans la gestion des politiques.
Nous pensons que les solutions SASE continueront d’évoluer et qu’elles mettront en œuvre, dans un avenir très proche, un grand nombre des exigences décrites dans le présent article.
Cette évolution permettra aux organisations de trouver un équilibre optimal entre l’expérience utilisateur, la flexibilité et la performance, garantissant que leurs politiques de sécurité restent efficaces et adaptables dans un paysage de menaces en évolution rapide.

• Blog CTO Insights

  La série de blogs Aryaka CTO Insights fournit un leadership éclairé sur les thèmes du réseau, de la sécurité et de la SASE.
  Pour les spécifications des produits Aryaka, consultez les fiches techniques d’Aryaka.