Sécurité DNS et résolution de noms privés

Cet article explique comment concevoir le DNS pour les réseaux Azure à l’aide de zones DNS privées, Azure DNS programme de résolution privé et de contrôles de sécurité DNS. Il couvre les modèles de résolution de noms privés, le transfert DNS hybride, l’intégration DNS de point de terminaison privé et la protection contre les menaces de couche DNS.

Présentation de cet article

DNS est la base de la connectivité réseau : chaque connexion commence par une requête de résolution de noms. Dans Azure, la conception du DNS détermine comment les charges de travail se découvrent mutuellement sur plusieurs réseaux virtuels, comment les systèmes sur site résolvent les noms hébergés dans Azure et comment les points de terminaison privés deviennent joignables via leur nom de domaine complet (FQDN). Au-delà de la résolution, DNS est également une surface d’attaque. Le tunneling DNS, l’exfiltration et les requêtes vers des domaines malveillants représentent des menaces réelles qui nécessitent des contrôles de sécurité de la couche DNS.

Cet article traite de trois problèmes DNS :

  • Résolution de noms privés : Comment les machines virtuelles, les conteneurs et les services de plateforme résolvent les noms dans Azure sans exposer les requêtes DNS à l’Internet public.
  • Transfert DNS hybride : mode de résolution des noms privés Azure par les réseaux locaux et de résolution des noms locaux par les charges de travail Azure.
  • Sécurité DNS : Comment bloquer les requêtes DNS malveillantes, empêcher l’exfiltration DNS et activer le filtrage réseau basé sur un nom de domaine complet.

Qui a besoin de cet article

Lisez cet article si vous :

  • Déployez des points de terminaison privés (si cela s'applique à votre scénario) et assurez-vous que les charges de travail résolvent correctement les zones DNS privatelink.*.
  • Utiliser des environnements hybrides dans lesquels les systèmes locaux doivent résoudre les noms privés d’Azure (ou inversement).
  • Utilisez Pare-feu Azure et avez besoin d’un filtrage basé sur les FQDN pour les règles réseau.
  • Voulez bloquer les requêtes DNS sur des domaines malveillants connus au niveau de la couche de résolution.
  • Gérez les environnements à plusieurs réseaux virtuels où la résolution DNS centralisée simplifie les opérations.
  • Planifiez l’architecture DNS pour les topologies hub-spoke avec des services partagés.

Priorité au lift-and-shift : préservez le comportement existant de résolution des noms DNS pendant la migration. Utilisez le transfert bidirectionnel entre dns local et Azure, configurez des redirecteurs conditionnels pour la résolution à horizon fractionné et hébergez des noms privés Azure dans DNS privé zones afin que les applications conservent leur configuration DNS actuelle.

Priorité à la modernisation : centralisez la résolution des noms à mesure que vous reprojetez vos charges de travail. Utilisez Azure DNS Programme de résolution privé avec des ensembles de règles de transfert pour la résolution hybride, intégrez des zones DNS privé à des points de terminaison privés pour les services PaaS et activez le proxy DNS Pare-feu Azure afin que les règles basées sur un nom de domaine complet et la résolution DNS partagent un chemin mis en cache unique.

Priorité au multicloud : Planifiez le basculement DNS entre plusieurs clouds avant la migration de la charge de travail. Utilisez Azure DNS Private Resolver pour la résolution de noms inter-cloud, configurez le transfert conditionnel de requêtes avec AWS Route 53 Resolver ou Google Cloud DNS, et réduisez les valeurs de TTL avant le basculement afin de réduire le risque lié aux caches obsolètes.

Azure services et fonctionnalités

Le tableau suivant décrit les services et fonctionnalités Azure impliqués dans la sécurité DNS et la résolution de noms privés.

Service / Fonctionnalité Objectif Fonctionnalité clé Quand utiliser
Azure DNS (zones publiques) Hébergement faisant autorité pour les noms de domaine public Réseau Anycast mondial, intégration Azure RBAC, enregistrements d'alias pour les ressources Azure Vous êtes propriétaire d’un domaine public et souhaitez héberger des enregistrements DNS dans Azure avec une haute disponibilité.
Zones DNS privées Azure Résolution de noms dans des réseaux virtuels sans exposition publique Liaison de réseau virtuel, inscription automatique des noms d’hôte de machine virtuelle, hébergement de zone privatelink Résolution de noms interne pour les charges de travail Azure. Obligatoire pour l’intégration DNS de point de terminaison privé.
Programme de résolution privé Azure DNS Transfert DNS entre les réseaux Azure et externes Point de terminaison entrant (résolution locale → Azure), point de terminaison sortant (transfert Azure → local), ensembles de règles de transfert Les environnements hybrides nécessitant une résolution DNS bidirectionnelle sans déployer de machines virtuelles DNS personnalisées.
Proxy DNS Pare-feu Azure Interception DNS centralisée pour le filtrage FQDN Met en cache les réponses DNS, active les règles réseau basées sur les FQDN et fournit un point de terminaison DNS unique pour les réseaux virtuels spoke. Vous déployez Pare-feu Azure et avez besoin du filtrage FQDN dans les règles réseau. Nécessaire pour assurer une résolution cohérente des FQDN.
Stratégie de sécurité DNS Protection contre les menaces au niveau de la couche DNS Bloque la résolution des domaines connus comme malveillants à l'aide du flux Microsoft Threat Intelligence. Vous souhaitez empêcher les charges de travail de se connecter à des domaines de distribution de commande et de contrôle ou de programmes malveillants.

concepts de zone DNS privé

DNS privé zones fournissent une résolution de noms pour les réseaux virtuels liés sans exposer d’enregistrements à Internet. Comportements clés :

  • Liaison de réseau virtuel : Vous pouvez lier une zone DNS privée à plusieurs réseaux virtuels. Toutes les ressources des réseaux virtuels liés peuvent résoudre les enregistrements dans la zone.
  • Inscription automatique : Lorsqu’elle est activée sur un lien de réseau virtuel, Azure crée automatiquement des enregistrements A pour les machines virtuelles déployées dans ce réseau virtuel. Azure supprime les enregistrements lorsque vous libérez ou supprimez des machines virtuelles. L’inscription automatique fonctionne uniquement pour les machines virtuelles (carte réseau principale uniquement). Un réseau virtuel peut s’inscrire automatiquement à une seule zone DNS privée, mais vous pouvez lier plusieurs réseaux virtuels à la même zone.
  • DNS de point de terminaison privé : Azure services accessibles via des points de terminaison privés nécessitent des zones DNS de liaison privée spécifiques (par exemple, privatelink.blob.core.windows.net pour Stockage Blob Azure). En l’absence de la zone correcte, les clients résolvent l’adresse IP publique au lieu de l’adresse du point de terminaison privé.

Architecture du programme de résolution privé DNS

Azure DNS Private Resolver élimine le besoin de machines virtuelles DNS personnalisées dans les scénarios de transfert dans un environnement hybride. Le schéma suivant illustre le flux de résolution DNS hybride depuis l’environnement local, via Azure DNS Private Resolver, jusqu’à une adresse IP de point de terminaison privé.

Diagramme montrant le flux de résolution DNS hybride depuis l’environnement local via le point de terminaison entrant d’Azure DNS Private Resolver vers une zone DNS privée et une adresse IP de point de terminaison privé.

Le programme de résolution utilise deux types de points de terminaison :

  • Point de terminaison entrant : Fournit une adresse IP que les serveurs DNS locaux peuvent cibler en tant que redirecteur conditionnel. Azure DNS résout les requêtes envoyées à cette adresse IP (y compris les zones de DNS privé liées). Nécessite un sous-réseau dédié délégué à Microsoft.Network/dnsResolvers.
  • Point de terminaison sortant : Permet Azure charges de travail de transférer des requêtes DNS vers des serveurs DNS locaux, d’autres fournisseurs de cloud ou des résolveurs externes. Nécessite également un sous-réseau dédié. Les ensembles de règles de transfert attachés au point de terminaison sortant définissent les suffixes de domaine à transférer et les serveurs DNS cibles à utiliser.

Important

Les points de terminaison entrants et sortants nécessitent chacun leur propre sous-réseau dédié. Vous ne pouvez pas déployer d’autres ressources dans ces sous-réseaux. Un VNet lié à un ensemble de règles de transfert n’a pas besoin d’être pairé avec le VNet du résolveur. Les liaisons de jeux de règles fonctionnent indépendamment du peering de réseaux virtuels.

Comment choisir

Utilisez l’arbre de décision suivant pour sélectionner les composants DNS appropriés pour votre environnement.

Arbre de décision

  1. Utilisez-vous des points de terminaison privés ?

    • Oui → Déployer des zones DNS privé avec les noms de zone appropriésprivatelink.*. Liez les zones aux réseaux virtuels qui doivent résoudre les adresses des points de terminaison privés.

  2. Les systèmes locaux doivent-ils résoudre Azure noms privés ?

    • Oui → Déployer un programme de résolution privé DNS avec un point de terminaison entrant. Configurez des serveurs DNS locaux avec des redirecteurs conditionnels pointant vers l’adresse IP du point de terminaison entrant.

  3. Les charges de travail Azure doivent-elles résoudre les noms de l’infrastructure locale ?

    • Oui → Déployer un programme de résolution privé DNS avec un point de terminaison sortant. Créez des ensembles de règles de transfert pour les suffixes de domaine locaux (par exemple). corp.contoso.com

  4. Déployez-vous Pare-feu Azure et avez-vous besoin d’un filtrage FQDN dans les règles de réseau ?

    • Oui → Activer le proxy DNS du pare-feu. Configurez les machines virtuelles spoke pour utiliser l’adresse IP privée du pare-feu comme serveur DNS.

  5. Voulez-vous bloquer les requêtes DNS sur des domaines malveillants connus ?

    • Oui → Activer la stratégie de sécurité DNS avec le flux Microsoft Threat Intelligence sur les réseaux virtuels cibles.

Modèles courants

Modèle Components Cas d’utilisation
Résolution des points de terminaison privés uniquement DNS privé zones + liens de réseau virtuel Charges de travail cloud uniquement accédant aux services PaaS via des points de terminaison privés. Aucune connectivité hybride.
Résolution bidirectionnelle hybride zones DNS privées + résolveur DNS privé (entrant + sortant) L’environnement local résout les noms privés d’Azure ; Azure résout les noms d’Active Directory local.
DNS du hub centralisé Azure DNS Private Resolver dans le réseau virtuel hub avec des jeux de règles de transfert liés aux spokes Topologie hub-spoke dans laquelle tout le trafic de résolution DNS passe par le hub pour une journalisation et un contrôle centralisés.
DNS médiaté par le pare-feu Pare-feu Azure proxy DNS + zones DNS privées Environnements utilisant le pare-feu pour le filtrage FQDN. Le pare-feu intercepte le trafic DNS, ce qui garantit une résolution cohérente des FQDN en adresses IP pour les règles réseau.
Suite de sécurité complète Toutes les options précédentes, ainsi que la stratégie de sécurité DNS Les environnements d’entreprise nécessitant une résolution hybride, un filtrage FQDN et une protection contre les menaces de couche DNS.

Exemples de zone DNS de point de terminaison privé

Le tableau suivant répertorie les services Azure courants et leurs noms de zone de DNS privé obligatoires.

Service d'Azure Nom de zone DNS privée
Service de stockage Blob Azure privatelink.blob.core.windows.net
Azure SQL Database privatelink.database.windows.net
Azure Key Vault privatelink.vaultcore.azure.net
Azure Files privatelink.file.core.windows.net
Azure Container Registry (Service d'enregistrement de conteneurs Azure) privatelink.azurecr.io
Azure Cosmos DB (API SQL) privatelink.documents.azure.com

Note

Pour obtenir la liste complète des noms de zone DNS privé pour tous les services Azure, consultez Azure configuration DNS de point de terminaison privé.

Prerequisites

Avant d’implémenter la sécurité DNS et la résolution de noms privés, assurez-vous d’avoir :

  • Un réseau virtuel : Toutes les fonctionnalités DNS fonctionnent dans ou entre des réseaux virtuels. Consultez les réseaux virtuels et les sous-réseaux pour obtenir des conseils fondamentaux. (F1)
  • Connectivité réseau pour les scénarios hybrides : Les points de terminaison entrants du programme de résolution privé DNS nécessitent une accessibilité du réseau local (ExpressRoute ou VPN) vers le réseau virtuel du programme de résolution.
  • Sous-réseaux dédiés pour le programme de résolution privé DNS : Chaque point de terminaison (entrant et sortant) nécessite son propre sous-réseau délégué à Microsoft.Network/dnsResolvers. Prévoyez au minimum un /28 pour chaque sous-réseau de point de terminaison.
  • Points de terminaison privés déployés (si vous utilisez des zones Private Link) : Les zones DNS privées pour les noms privatelink.* n’ont d’utilité que lorsque des points de terminaison privés existent. Consultez l’accès PaaS privé avec des points de terminaison privés pour obtenir des conseils de déploiement. (C5)
  • Pare-feu Azure déployée (si vous utilisez un proxy DNS) : la fonctionnalité de proxy DNS nécessite une instance de Pare-feu Azure existante. Consultez Pare-feu Azure et l’inspection du trafic. (S1)
  • Autorisations: Rôle Contributeur de zone DNS pour la gestion des zones DNS privé. Contributeur réseau pour le déploiement du programme de résolution privé DNS.

Considérations relatives à la sécurité

DNS introduit des vecteurs d’attaque spécifiques qui nécessitent des contrôles dédiés. Les sections suivantes couvrent les risques d’exfiltration, le blocage basé sur les informations sur les menaces, le comportement du proxy DNS du pare-feu et les limitations DNSSEC.

Risques d’exfiltration DNS

Le tunneling DNS encode les données dans les requêtes DNS pour exfiltrer des informations via un protocole sans restriction. Étant donné que la plupart des réseaux autorisent le DNS sortant (UDP/TCP 53), les attaquants utilisent DNS comme canal couvert. Réduisez ce risque en procédant comme suit :

  • Activation Pare-feu Azure proxy DNS et le routage de tout le trafic DNS via le pare-feu. Le pare-feu enregistre toutes les requêtes DNS, ce qui rend le tunneling détectable via l’analytique.
  • Application d’une stratégie de sécurité DNS pour bloquer la résolution des domaines associés aux outils d’exfiltration connus et à l’infrastructure de commande et de contrôle.
  • Surveillance des modèles de requête DNS dans Azure Monitor pour les anomalies telles que les étiquettes de sous-domaine anormalement longues, les volumes de requêtes élevés vers un domaine unique ou les requêtes vers des domaines récemment inscrits.

Stratégie de sécurité DNS

La stratégie de sécurité DNS avec Microsoft Threat Intelligence bloque la résolution DNS pour les domaines malveillants connus au niveau du réseau virtuel. Lorsqu’une charge de travail tente de résoudre un domaine marqué par Centre d'intervention en matière de sécurité Microsoft (MSRC), la stratégie bloque la résolution avant toute connexion réseau. Ce contrôle fonctionne indépendamment de Pare-feu Azure et ne nécessite pas de modifications apportées aux configurations de charge de travail individuelles.

Principales caractéristiques :

  • Utilise le flux Microsoft Threat Intelligence provenant du MSRC.
  • Fonctionne au niveau de la couche de résolution DNS : bloque la requête, et non le trafic.
  • Appliqué par réseau virtuel : activez tous les réseaux virtuels contenant des charges de travail qui accèdent à Internet.
  • À la différence du filtrage FQDN du pare-feu : la stratégie de sécurité DNS bloque les domaines malveillants à l’échelle globale sans nécessiter le déploiement d’un pare-feu.

Proxy DNS et filtrage FQDN du pare-feu

Le proxy DNS d’Pare-feu Azure est requis pour le filtrage basé sur les noms de domaine complets (FQDN) dans les règles réseau. En l’absence de proxy DNS, les requêtes DNS des VM clientes peuvent être résolues à des moments différents de celles du pare-feu, ce qui entraîne une correspondance IP-FQDN incohérente et des non-correspondances de règles.

Lorsque vous activez le proxy DNS :

  • Configurez les machines virtuelles spoke pour utiliser l’adresse IP privée du pare-feu comme serveur DNS.
  • Le pare-feu résout les requêtes pour le compte des clients et met en cache les résultats (cache positif jusqu’à 1 heure, cache négatif jusqu’à 30 minutes).
  • Les correspondances entre noms de domaine pleinement qualifiés (FQDN) et adresses IP s’actualisent toutes les 15 secondes. Le pare-feu supprime les entrées obsolètes après 15 minutes.
  • Les règles d’application (L7) utilisent l’indication de nom de serveur (SNI) pour la correspondance de nom de domaine complet et ne nécessitent pas de proxy DNS. Les règles réseau (L4) nécessitent un proxy DNS pour la résolution des FQDN.
  • Le filtrage FQDN dans les règles de réseau prend uniquement en charge les correspondances de domaine exactes. Les modèles génériques ne sont pas pris en charge dans les FQDN des règles réseau. Utilisez des règles d'application pour la correspondance des FQDN avec des caractères génériques.

Note

Si tous les serveurs DNS en amont configurés sont indisponibles, le proxy DNS d’Pare-feu Azure ne bascule pas sur un résolveur alternatif. La résolution DNS échoue jusqu’à ce qu’au moins un serveur en amont récupère. Planifiez la redondance du serveur DNS dans votre configuration en amont.

Caution

Si vous activez le proxy DNS mais que vous ne configurez pas les machines virtuelles clientes pour utiliser le pare-feu comme serveur DNS, les règles de réseau basées sur le nom de domaine complet ne fonctionnent pas correctement. Les clients et le pare-feu peuvent résoudre des adresses IP différentes pour le même nom de domaine complet, ce qui entraîne des chutes de trafic inattendues.

Limitations de DNSSEC

Azure DNS ne prend actuellement pas en charge la validation DNSSEC pour les zones privées. Les zones publiques hébergées dans Azure DNS prennent en charge la signature DNSSEC pour les réponses autoritatives, mais la résolution récursive au sein des réseaux virtuels Azure n’effectue pas de validation DNSSEC. Si vos exigences de sécurité imposent la validation DNSSEC, évaluez à l’aide d’un programme de résolution DNS personnalisé qui prend en charge la validation ou implémente la vérification de la couche Application.

Considérations relatives à la conception

Priorité de conception DNS pour le lift-and-shift

  • Configurez le transfert DNS bidirectionnel entre les serveurs DNS locaux et Azure DNS Private Resolver.
  • Utilisez des redirecteurs conditionnels afin que les requêtes locales pour les noms hébergés dans Azure soient résolues dans Azure, et que les requêtes effectuées depuis Azure pour les noms de votre environnement local soient résolues via votre infrastructure DNS existante.
  • Créez des zones DNS privées pour chaque service Azure utilisé par les charges de travail migrées, en particulier les services s’appuyant sur des points de terminaison privés.
  • Conservez le comportement DNS de l’application lors de la migration à l’aide d’enregistrements d’alias ou de mappages CNAME au lieu de modifier les paramètres du programme de résolution du client.

Moderniser le focus de conception DNS

  • Centralisez la résolution DNS dans le hub à l'aide d'Azure DNS Private Resolver avec des jeux de règles de transfert partagés entre les réseaux virtuels spoke.
  • Associez des zones DNS privées à chaque service PaaS reposant sur un Private Endpoint afin que les charges de travail migrées vers la nouvelle plateforme résolvent automatiquement les noms privatelink.
  • Activez le proxy DNS Pare-feu Azure afin que les règles de réseau basées sur un nom de domaine complet et la résolution DNS de charge de travail utilisent un chemin de résolution cohérent et mis en cache.
  • Utilisez l’inscription automatique et Azure RBAC sur DNS privé zones pour réduire la gestion manuelle des enregistrements lorsque vous adoptez l’infrastructure en tant que code.

Priorité de conception DNS pour les environnements intercloud

  • Utilisez Azure DNS Private Resolver comme point de contrôle du transfert pour la résolution de noms entre différents clouds.
  • Configurez le transfert conditionnel entre Azure DNS privé, AWS Route 53 Resolver et Google Cloud DNS pour chaque espace de noms privé qui doit être résolu entre les environnements.
  • Planifiez le basculement DNS en plusieurs phases : réduire les valeurs TTL, vérifier les chemins de transfert, modifier les enregistrements CNAME ou A, et surveiller la latence des requêtes et le comportement du cache.
  • Activez DNSSEC sur les zones autoritatives lorsque les plateformes connectées le prennent en charge, et documentez les cas où les chemins de résolution privés ne valident pas DNSSEC.

Learn more

Étapes suivantes

Tip

Vous explorez vous-même ? Revenez au navigateur de vue d’ensemble pour trouver votre prochain article par fonctionnalité.

Étape suivante de votre parcours lift-and-shift :

Contrôler le trafic Internet sortant : centraliser toutes les communications sortantes via Pare-feu Azure et désactiver l’accès sortant par défaut.

Ensuite, dans votre parcours de modernisation :

Configurer la surveillance de la production : activez Network Watcher et le Analyseur de performances réseau pour la préparation de la production dès le premier jour.

Prochaine étape de votre parcours multi-cloud :

Sécuriser votre chemin de transit intercloud : déployez Pare-feu Azure dans votre hub virtuel sécurisé pour inspecter tout le trafic intercloud, branche et internet.

  • Last updated on