NET / NET-07
Sécurité DNS et filtrage par résolution protectrice
Protégez le service qui résout les noms de domaine et contrôlez les destinations résolues par les appareils. Le service répond aux enjeux de disponibilité du DNS interne et de détection ou de blocage des domaines jugés dangereux.
QUAND C'EST UTILE
Une réponse ciblée
à un besoin défini.
Un contrôle inadéquat du DNS, des terminaux utilisant des résolveurs externes, des alertes concernant des communications suspectes ou une dépendance critique à un DNS interne mal documenté.
PORTÉE ET RÉSULTATS
Ce que couvre la mission.
Portée
- Architecture du système de résolution des conflits
- Séparation interne/externe
- Contrôle des modifications
- filtrage
- Déboisement proportionné
- accès administratif
- continuité
- Traitement de l'utilisation de DNS chiffrée
Livrables
- Architecture du DNS
- politiques de résolution
- configurations
- Liste des exceptions
- Procédures en cas d’incident
- tests de résolution et de failover
- Documentation de la zone sensible
Preuve de réception
La résolution de l’affaire est validée ; un domaine d’essai convenu est bloqué ; l’administration est protégée ; la continuité est testée ; les contournements connus sont documentés avec des mesures convenues.
LIVRAISON
Comment le travail est structuré.
Approche
Cartographier le trafic ; concevoir et dimensionner ; piloter ; migrer progressivement avec possibilité de retour arrière ; tester et documenter les opérations.
Prérequis et responsabilités
Client : réseau, applications, opérateurs, fenêtres de changement et acceptation métier. Fournisseur : conception, migration et tests. L'accès des tiers et l'inspection TLS nécessitent des approbations appropriées.
Facteurs de portée
Sites, débit réel inspecté, trafic, règles, utilisateurs distants, disponibilité et intégrations. Le matériel, les abonnements de sécurité et les opérations récurrentes sont distincts.
Questions à clarifier
Qui administre les zones et les domaines ? Les terminaux peuvent-ils contourner les resolvers ? Quels services échouent lors d’une panne du DNS ?
LIMITES IMPORTANTES
Le filtrage DNS ne détecte pas toutes les échanges et ne remplace pas les EDR ou les pare-feu. Le DNS chiffré et l’accès direct à l’IP peuvent modifier sa portée.
Les modifications préservent les services essentiels et les parcours de rétablissement. Le dimensionnement, les licences et les tests de recette reflètent les fonctionnalités qui seront réellement activées.
EN PRATIQUE
Situations illustratives.
Ces exemples décrivent des engagements possibles et des résultats cibles. Il ne s'agit pas de références clients ni de résultats obtenus.
Scénario 01
Une entreprise dispose de configurations DNS différentes pour ses sites. Problème : standardiser les répondeurs et appliquer un filtrage commun. Objectif : un comportement cohérent et la résolution des incidents qui permettent un diagnostic précis.
Scénario 02
Une organisation perd ses services lorsque son DNS principal tombe en panne. Projet : réexamen de la redondance, des sauvegardes et des contrôles de changement. Résultats escomptés : récupération vérifiée ; les dépendances non redondantes restent identifiées comme des risques nécessitant une intervention.
Contexte technologique et de référence
Exemples : resolvers internes sécurisés et services de protection DNS ; l’intégration du pare-feu dépend des abonnements et de l’architecture.
L'ensemble final des technologies est convenu lors du cadrage, sur la base de l'interopérabilité, des licences, des droits d'accès et des exigences opérationnelles.
SERVICES CONNECTÉS
Construisez l'étape suivante.
Ces services peuvent compléter la mission. Ils ne sont pas inclus automatiquement.
Commencer une conversation
Clarifiez la portée.
Nous clarifierons l'objectif, les dépendances et les responsabilités de ce service avant de proposer la livraison.