DNS protecteur : déploiement dans le secteur public

Un DNS protecteur dans le secteur public est utile lorsque les équipements prévus appliquent sa politique et que les équipes peuvent examiner ses décisions sans interrompre les services essentiels. Configurer le résolveur du siège ne répond pas à toutes les questions : que se passe-t-il dans une bibliothèque, sur le portable d’un agent en déplacement ou dans une application exploitée par un prestataire ?

Pour une collectivité ou un établissement public britannique ou européen, le travail consiste à établir une couverture, des responsabilités et une procédure de continuité. L’achat d’un service DNS ne suffit pas à les démontrer. Ce guide propose un dossier de déploiement et une recette technique à adapter avec l’exploitant réseau. Le cas pratique est fictif et les étapes proposées ne constituent pas une liste d’obligations réglementaires.

Définir les services publics et les connexions concernés

Commencez par les services dont l’interruption a une conséquence identifiable pour les usagers ou les agents : rendez-vous logement, encaissement, prêt en bibliothèque, authentification des équipes. Désignez un responsable métier capable d’expliquer les dépendances et de valider la période du pilote. « Tous les équipements de la collectivité » est un périmètre trop flou pour une recette.

Pour chaque service, identifiez les postes administrés, les lieux de connexion, le propriétaire de l’application et les modalités de support. Distinguez l’accès des agents à une application hébergée du trafic propre aux serveurs du fournisseur. Le DNS utilisé par les agents ne démontre pas la protection de l’infrastructure SaaS distante.

Conservez une fiche courte :

Service : administration des rendez-vous logement
Responsable métier : gestionnaire identifié
Population : portables administrés, au bureau et en déplacement
Chemins inclus : réseau local, VPN approuvé, connexion à domicile
Dépendances : identité, réservation, stockage documentaire
Exploitant réseau : équipe interne ou prestataire nommé
Preuves de recette : un résultat par chemin de connexion
Exclusions : infrastructure fournisseur non administrée

Traitez les postes en libre accès séparément des équipements des agents. Les utilisateurs, les procédures de remise en état et les attentes de confidentialité diffèrent. Plusieurs politiques adaptées peuvent coexister. Conservez cette distinction dans le bilan de couverture et les consignes du support, plutôt que de les fondre dans une déclaration générale de protection.

Vérifier l’éligibilité avant de choisir le service

Le Protective DNS du NCSC est un programme britannique de protection DNS récursive soumis à des critères d’éligibilité. Vérifiez ses modalités d’inscription pour votre organisme.

Au Royaume-Uni, recherchez également le circuit prévu pour votre secteur ou votre organisme de rattachement. Une école, une collectivité et un ministère peuvent relever de modalités différentes. Lorsque la connectivité est externalisée, convenez de qui réalise l’inscription, configure la transmission des requêtes et reçoit les notifications d’exploitation.

Ailleurs en Europe, notez l’autorité nationale consultée et les dispositifs sectoriels éventuellement disponibles. Examinez ensuite les autres offres à partir du réseau réel et des exigences d’achat de l’établissement. Un nom commercial évoquant une région ne démontre pas où se trouvent les journaux, les sauvegardes ou les accès du support.

Demandez une description écrite de ces flux. Le guide d’achat de threat intelligence pour le secteur public aide à convertir les déclarations du fournisseur en preuves attendues. Ces éléments alimentent la revue propre à l’établissement, notamment celle des responsables de la gouvernance des données et des contrats.

Mesurer la couverture du DNS protecteur par chemin

L’inventaire des équipements fournit un dénominateur, mais la protection dépend du chemin de connexion. Un même portable peut appliquer la politique au bureau puis la contourner involontairement en déplacement. Une résolution réussie sur un poste fixe ne suffit donc pas comme preuve de recette.

Préparez un résultat pour chaque combinaison pertinente entre politique du poste et réseau : filaire, Wi-Fi administré, site distant, VPN, accès direct à Internet autorisé. Pour les usages nomades, testez les transitions entre ces chemins. Le démarrage d’un appareil dans une configuration connue ne vérifie pas son comportement après changement de réseau.

Relevez le chemin effectivement utilisé, la politique appliquée et l’événement correspondant dans la supervision. Employez des destinations inoffensives fournies ou approuvées pour les tests. Il n’est pas nécessaire de visiter une infrastructure malveillante réelle pour démontrer un blocage. Conservez l’heure et le résultat attendu afin qu’un autre technicien puisse répéter la vérification.

Distinguez trois populations dans le bilan : couverture testée, configuration présente mais non vérifiée, équipements hors périmètre. Un portable absent durant le pilote reste dans la deuxième catégorie jusqu’à obtention d’une preuve. N’améliorez pas artificiellement le taux de couverture en excluant discrètement les agents de terrain de l’inventaire.

Le guide des listes de blocage DNS présente les mécanismes du résolveur. Ici, la question de recette est différente : l’établissement peut-il montrer que les populations convenues passent réellement par le contrôle attendu ?

Préserver la résolution interne et les dépendances applicatives

Un organisme public dépend souvent de noms internes, d’un annuaire et d’applications partagées entre plusieurs structures. Documentez les requêtes destinées aux résolveurs internes et celles transmises à l’extérieur. Testez cette séparation avant de modifier les réglages par défaut de tout le parc.

N’envoyez pas les espaces de noms internes à un service externe simplement parce que les sites publics fonctionnent sur un poste témoin. Ne supposez pas non plus que chaque application utilise les réglages DNS du système. Un navigateur administré, un conteneur ou un client de sécurité peut introduire un autre chemin.

Construisez une recette applicative avec le responsable métier. Elle doit inclure l’authentification, une opération habituelle, l’accès aux documents et les échanges nécessaires en arrière-plan. L’ouverture de la page d’accueil ne prouve pas que le paiement, la prise de rendez-vous ou l’identité fonctionnent jusqu’au bout.

Tenez compte des caches et du délai d’application des politiques. Une réponse mémorisée ou une connexion existante peut survivre à un changement et fausser l’interprétation. Utilisez la procédure de vérification prise en charge par le fournisseur, sans vider les caches de tout le parc dans l’urgence.

Le guide de durcissement DNS couvre les contrôles d’infrastructure associés. La résolution protectrice ne remplace pas l’administration sécurisée du DNS faisant autorité pour les domaines publiés par l’organisme.

Maîtriser les autres résolveurs et les chemins chiffrés

Le chiffrement DNS protège le transport. Il ne précise pas, à lui seul, la politique appliquée par le résolveur. Un poste administré peut utiliser correctement du DNS chiffré ; un autre résolveur non prévu peut sortir les requêtes de la visibilité attendue.

Examinez ensemble les politiques du système, du navigateur, du VPN et du client de sécurité. Définissez les chemins autorisés puis vérifiez leur comportement réel. Encadrez les alternatives non autorisées avec les contrôles disponibles, et documentez les exceptions lorsqu’une application présente une dépendance justifiée.

Les recommandations du NCSC pour choisir un DNS protecteur abordent le déploiement et l’assurance fournisseur pour les organismes non éligibles à son propre service. Elles aident à formuler les questions ; la démonstration de couverture locale reste un travail distinct.

Une règle pare-feu visant le DNS classique ne démontre pas une maîtrise complète des connexions. Certaines applications possèdent leur propre comportement de résolution ou de connexion. Le guide de surveillance du DNS-over-HTTPS explique pourquoi il faut rapprocher les observations du poste et du réseau. Décrivez les écarts résiduels plutôt que de présenter un réglage théorique comme une protection universelle.

Organiser le pilote autour des usages du service public

Prenons une commune fictive disposant d’un site administratif, de deux bibliothèques et d’agents qui se déplacent chez les habitants. Le pilote inclut quelques postes administrés dans chaque lieu ainsi que plusieurs utilisateurs nomades. Les protections existantes restent actives pendant la validation du nouveau chemin de résolution.

La recette suit une séquence de travail : connexion, ouverture d’un rendez-vous autorisé, consultation d’un document nécessaire, puis transaction de test permise. Utilisez des comptes et données de test lorsque c’est possible. Associez le centre de support, qui recevra les premiers signalements de blocage inattendu.

Une bibliothèque réussit la recette initiale, mais échoue après bascule sur son accès réseau de secours. L’analyse montre que cette liaison annonce un autre résolveur. C’est un défaut de couverture, même si le tableau de bord du siège reste rassurant. L’équipe corrige ce chemin avant d’étendre le pilote.

Un portable nomade doit aussi être vérifié après déconnexion du VPN. La réponse dépend de l’architecture approuvée : composant nomade administré, autre politique de connexion ou modification du périmètre. Documentez la décision puis rejouez les tests concernés. Le réglage du bureau ne suit pas nécessairement l’agent.

Étendez ensuite le déploiement par population prise en charge, après acceptation des preuves par son responsable. Une dépendance essentielle dépourvue de support ou de procédure de reprise doit suspendre cette extension jusqu’à résolution du problème.

Transformer les blocages en éléments utilisables par le support

Une requête bloquée montre qu’une politique a pris une décision. Elle ne prouve pas, à elle seule, qu’une personne a cliqué, qu’un programme malveillant s’est exécuté ou qu’une attaque a été empêchée. Une tâche de fond ou les nouvelles tentatives d’une application peuvent multiplier les événements.

Conservez l’horodatage, le nom demandé, la raison indiquée, le chemin DNS et un moyen autorisé d’identifier l’équipement. Gardez le lien avec l’observation d’origine. Une synthèse sans motif technique peut masquer la différence entre une classification de menace et une panne ordinaire.

La RFC 8914 définit les Extended DNS Errors, qui peuvent apporter un contexte supplémentaire aux erreurs. Leur prise en charge varie. Vérifiez ce que le résolveur et le client exposent réellement, sans interpréter toute erreur de résolution comme un blocage de domaine malveillant.

Donnez au support une séquence courte : identifier le service affecté, déterminer si la politique explique l’échec, recueillir les preuves minimales puis transmettre au bon responsable. Pour l’analyse de menace, examinez la provenance et la fraîcheur des sources avant de transformer un résultat de réputation en restriction étendue.

Gardez les éléments de diagnostic dans les circuits approuvés. Les historiques de domaines et leur association à un poste peuvent révéler des habitudes de travail sensibles, même sans contenir de documents. Définissez qui y accède et pour quelle investigation.

Attribuer un périmètre et une échéance aux exceptions

Rétablir un service public nécessite parfois une décision rapide, mais pas une autorisation générale et permanente. Commencez par identifier la dépendance en échec et le caractère intentionnel du blocage. Un site fournisseur compromis peut également être une dépendance métier réelle.

Faites convenir au responsable du service et à l’intervenant sécurité l’action la plus limitée qui fonctionne. Lorsque l’outil le permet, bornez l’exception à la destination, aux utilisateurs et à la période nécessaires. N’autorisez pas tout un domaine d’hébergement partagé pour rétablir un seul composant.

Utilisez un registre :

Service affecté et dépendance exacte :
Preuves qui soutiennent l’action envisagée :
Incertitudes ou observations contradictoires :
Approbateur et responsable d’application :
Population et destinations autorisées :
Échéance et date de revue :
Surveillance complémentaire :
Test confirmant la suppression :

Si la plateforme ne sait pas imposer la granularité ou l’échéance souhaitée, précisez le processus compensatoire et la personne qui l’exécutera. Inscrire une date dans un ticket ne supprime pas automatiquement une règle.

Examinez les exceptions récurrentes avec le fournisseur et le responsable applicatif. Des prolongations répétées peuvent signaler une classification non corrigée, une intégration non prise en charge ou une dépendance qui exige une autre conception du service.

Décider du fonctionnement dégradé avant la panne

Convenez de ce qui se passe si le résolveur, la liaison ou le composant nomade devient indisponible. La disponibilité et la protection ne se dégradent pas toujours ensemble. Un autre résolveur peut rétablir Internet tout en supprimant la politique de sécurité. Une seconde instance peut encore dépendre du même accès en panne.

Testez le chemin de reprise approuvé avec un exercice délimité et une procédure de retour. Vérifiez la politique effective après bascule, la résolution des noms internes et l’alerte permettant aux équipes de reconnaître la situation dégradée. Deux adresses configurées ne prouvent pas une indépendance réelle.

Le responsable métier doit connaître les conséquences d’une mesure d’urgence qui réduit la protection, la personne habilitée à la décider et les conditions de retour au fonctionnement normal. Gardez les contacts d’urgence accessibles quand l’identité ou la messagerie habituelle sont indisponibles.

Intégrez l’essai de reprise à la passation avec l’exploitant. Un schéma d’architecture ne démontre pas qui répondra à l’heure concernée, ni si son contrat actuel inclut l’intervention attendue. Vérifiez aussi comment joindre le responsable d’une exception pendant cette période.

Examiner les écarts de couverture plutôt qu’un compteur

Organisez une revue d’exploitation courte : quelles populations disposent de preuves récentes, quels chemins restent non vérifiés, quelles exceptions ont expiré, quels incidents nécessitent une modification ? Associez ces questions à des responsables identifiés.

Un nombre élevé de blocages peut provenir des tentatives répétées d’un seul poste. Il appelle une analyse, sans justifier un chiffre d’attaques évitées. Le résultat utile est un contrôle qui fonctionne, dont les limites sont connues et dont la gestion préserve les services publics.

Pour un domaine public dont l’analyse est autorisée, le contrôle de réputation de domaine IsMalicious fournit un contexte externe daté. Conservez-le avec les preuves DNS et les observations locales du poste. IsMalicious apporte du renseignement ; le résolveur, la politique réseau et le processus d’incident de l’établissement assurent l’application du contrôle et la décision finale.