DNS Client Query FilteringAméliorer le contrôle d’accès aux applications

Segmentation réseau jusqu’à l’utilisateur individuel

Le filtrage au niveau du DNS, à l’aide d’une solution DNS Firewall, est utilisé essentiellement pour offrir une première ligne de défense aux utilisateurs, appareils et applications de tout type. S’appuyant sur une liste (gérée manuellement ou dynamiquement) de domaines de destination auxquels il convient d’autoriser ou de refuser l’accès, cette approche constitue un moyen très simple et rapide de protéger le système client lorsqu’il se connecte à des applications ou à des services, sur la base de leur nom ou de leur adresse IP.

Cependant, le filtrage DNS doit être plus spécifique. Appliquer le même filtre à tout appareil ou utilisateur du réseau tend à réduire le niveau de sécurité aux règles les plus courantes à appliquer. Or, certains groupes d’utilisateurs nécessitent un niveau de sécurité plus élevé, tandis que d’autres ont besoin de permissions plus étendues pour travailler efficacement. En outre, les objets de l’IoT gagneraient à accéder uniquement aux applications et ressources autorisées, sur la base d’une liste approuvée (allow list). La plupart des autres appareils se voient généralement appliquer des restrictions, sur la base d’une liste refusée (deny list). Mais comment effectuer un tel filtrage DNS sans la possibilité de différencier la partie importante de la transaction, à savoir le client lui-même ?

Des options existent déjà dans les moteurs DNS, telles que des vues permettant de distinguer le client en fonction de son adresse IP, mais est-ce suffisant ? Est-ce pratique ? Êtes-vous sûr de pouvoir encore utiliser cette approche pour des appareils que l’on déplace d’un site à l’autre, tandis que de nouveaux appareils s’ajoutent chaque jour au réseau, installés parfois directement par d’autres entités de l’organisation ?

Afin d’appliquer le niveau de filtrage (et donc de sécurité) approprié, davantage de granularité, ainsi qu’un moyen plus efficace de distinguer les clients, sont nécessaires. Cela constitue la base du filtrage au niveau des applications, de la segmentation requise par l’approche Zero Trust, du contrôle parental proposé par les fournisseurs de services, mais également du filtrage pratiqué dans les administrations ou exigé par la réglementation.

Avantages clés

1

Filtrage plus granulaire

Améliorer la segmentation réseau jusqu’au client individuel

2

Contrôle d’accès aux applications renforcé

Permettre un contrôle d’accès basé sur le DNS aux applications et infrastructures vitales

3

Barrière de sécurité précoce

Détecter les anomalies au plus tôt dans le flux afin de réduire les risques d’exposition

4

Nouvelles opportunités commerciales

Développer de nouvelles offres B2B2C (par ex. le contrôle parental pour les fournisseurs de services)

5

Écosystème de sécurité plus robuste

Permettre des modifications immédiates via l’API ou des manipulations de la zone DNS standard

Processus de filtrage des requêtes clients (CQF)

Le CQF apporte une nouvelle facette au filtrage DNS, avec une sécurité basée sur les informations du client source en relation au domaine demandé, au lieu d’un filtrage basé uniquement sur le domaine. Une stratégie de filtrage spécifique peut ainsi être appliquée à des clients particuliers requérant un accès à des applications spécifiques. Cela élève la sécurité DNS à un niveau supérieur, en combinant les informations sur le client et la destination avec des listes approuvées et refusées, renforçant ainsi la sécurité des applications.

Les principaux composants requis par le CQF pour effectuer un filtrage DNS riche sont : 1) une liste d’identifiants de clients 2) une liste de domaines à analyser et 3) l’opération à effectuer (autoriser, refuser ou appliquer une contre-mesure).

Chaque requête DNS est comparée au contenu de la liste des applications et des domaines afin d’appliquer la stratégie correspondante. Les listes sont soit locales à chaque serveur DNS Guardian et gérées manuellement (ce qui est utile à des fins de test), soit centralisées et gérées au niveau global, ce qui est idéal pour appliquer la stratégie de sécurité. La liste de domaines est une zone RPZ standard administrable au niveau du SOLIDserver (au moyen d’actions déclenchées via l’interface graphique et d’appels API), mais qui peut également être souscrite auprès d’un fournisseur de veille en matière de menaces.

DNS Client Query Filtering principles

La distribution de chaque liste à tous les serveurs DNS Guardian s’effectue via des mécanismes de réplication standard, évolutifs et en temps réel, autorisant des scénarios d’automatisation avec l’écosystème de sécurité et des solutions OSS/BSS.

Le processus de filtrage constitue le cœur de la fonction CQF et permet une grande richesse d’utilisation en termes de sécurité. La possibilité d’utiliser et de manipuler de grandes quantités d’informations dans les listes offre un réel avantage lorsqu’il s’agit d’appliquer les stratégies de sécurité à de multiples groupes de clients complexes à identifier. Ce mode de gestion est rendu possible par les hautes performances du moteur DNS Guardian et son intégration dans l’ensemble de l’écosystème DDI du SOLIDserver.

Riche identification des clients dans le CQF

Les clients DNS sont généralement identifiés par leur adresse IP, mais dans certains scénarios plus complexes, il est possible d’utiliser pour cette identification un autre champ ou une combinaison de champs extraits de chaque requête. Par exemple, nous pouvons utiliser le champ DNS Client Subnet étendu pour identifier soit des groupes de clients situés sur le même sous-réseau, soit chaque client individuel lorsqu’il est exploité avec un masque de sous-réseau complet. Nous pouvons également utiliser une combinaison de l’identification du CPE (Customer Premise Equipment) sur le réseau de l’opérateur télécom et l’adresse MAC de l’appareil sur le réseau du consommateur comme clé d’identification unique. Cette variété de méthodes d’identification permet au CQF d’être utilisé en conjonction avec des serveurs DNS en cascade, des moteurs externes DNS sur HTTPS, ou encore un relais DNS ISP intégré au CPE. Le CQF peut donc être exploité aussi bien par une organisation disposant d’un simple réseau local, que par un réseau de télécommunications plus complexe ou un fournisseur de services.

CQF et contrôle d’accès aux applications

Le contrôle d’accès aux applications peut s’effectuer à différents niveaux, en fonction des stratégies de sécurité en place au sein de l’organisation. Généralement, cela implique l’authentification et l’autorisation au niveau des applications, au moyen d’informations d’identification. Ainsi, sur le papier, aucune application n’est accessible sans contrôle de l’utilisateur.

Mais est-ce vraiment suffisant ? Un utilisateur ne pouvant accéder à une application peut-il malgré tout accéder à la page de connexion ? Si l’auto-enregistrement n’est pas disponible pour cette application, ce qui est généralement le cas dans les organisations, pourquoi exposer l’accès à son infrastructure depuis le réseau ?

Certaines applications critiques nécessitent un accès spécifique et fonctionnent sur une infrastructure dédiée, sans partage de leurs principaux composants. Dès lors, le filtrage au niveau du réseau, impliquant des listes d’accès de routage et des règles de pare-feu, est à envisager. Cependant, l’ajout d’un filtrage au niveau du DNS permet d’augmenter encore le niveau de sécurité. Cette solution ne laisse aucune possibilité de résoudre les adresses IP techniques des applications, ni de visualiser aucune information réseau ou autorisation d’accès, et par conséquent constitue une bien meilleure approche de la sécurité dans un environnement Zero Trust.

La possibilité de mettre à jour dynamiquement les listes CQF, avec des entrées pour les applications ou les clients, permet d’élever automatiquement le niveau de sécurité, interdisant aux utilisateurs inconnus ou non autorisés toute visibilité sur l’application et les données.

Gestion simple et évolutive des listes CQF

Le filtrage au niveau du DNS n’est envisageable que si les listes de domaines et d’identifiants clients sont faciles à gérer et peuvent évoluer de façon quasi illimitée. La solution de pare-feu DNS s’appuie sur le transfert de zone RPZ standard pour sa gestion des listes, permettant ainsi de charger de grands volumes de domaines filtrés au moyen du transfert de zone DNS, ce qui est vraiment efficace. Ce principe a été étendu à l’utilisation du filtrage des requêtes clients : les listes de domaines et d’identifiants clients peuvent être gérées soit localement, soit en utilisant le mécanisme de transfert de zone DNS.

Ainsi, le contenu des deux listes peut être géré dans un serveur DNS, permettant la mise à jour centralisée et automatique du contenu sur les moteurs Guardian, et constituant un moyen efficace d’adapter les mesures de sécurité aux stratégies globales. En exploitant le service DNS SOLIDserver en tant que backend pour la gestion du contenu des listes, vous pouvez profiter de toutes les fonctionnalités disponibles et éprouvées, notamment l’interface graphique web et le riche ensemble d’API. L’ensemble de l’écosystème de sécurité et d’automatisation peut alors ajouter et supprimer des enregistrements des zones DNS de sécurité, qui sont poussés vers les moteurs Guardian et immédiatement appliqués au trafic entrant, renforçant ainsi la sécurité de toutes les solutions critiques au sein de l’écosystème.

Contenu en lien avec le sujet

 

Brochure produit DNS Guardian

DNS Guardian propose une méthode brevetée d’inspection des transactions DNS, des analyses avancées pour la détection des menaces comportementales en temps réel, ainsi que des contre-mesures adaptatives, afin de protéger les utilisateurs, les applications et les données.

 

IDC 2021 GLOBAL DNS THREAT REPORT

Résultats d’une enquête menée auprès de 1114 professionnels de l’IT et des réseaux, détaillant les coûts et les dommages liés aux attaques DNS, l’impact sur les entreprises ainsi que l’état actuel des défenses, et fournissant de précieux conseils pour protéger votre infrastructure.

 

SOLIDserver DDI for ZERO TRUST SECURITY

La visibilité granulaire de DNS sur le trafic internet procure des informations contextuelles précieuses pour la détection des menaces comportementales. Combinée à des fonctions de sécurité DNS améliorées et à un filtrage DNS intelligent, cette visibilité permet d’implémenter une sécurité Zero Trust.