Commençons par la frontière du secteur public
Une exigence de courrier électronique du gouvernement britannique doit être attachée à une organisation, un domaine et un contexte de traitement des informations nommés. Il ne faut pas prétendre que chaque entreprise britannique doit déployer une politique DNS particulière. La page GOV.UK secure-government-email, mise à jour pour la dernière fois le 4 mars 2024 et révisée ici le 8 novembre 2026, couvre expressément les domaines de messagerie Internet exploités par des organisations du secteur public. Cela nécessite au moins TLS et DMARC, ainsi qu'une protection appropriée des informations échangées. Il s’agit là d’un contexte politique gouvernemental et non d’une preuve d’un statut universel du secteur commercial. Politique GOV.UK.
Commencez le dossier d'applicabilité par l'identité juridique de l'organisation et ses relations avec le secteur public. Ajoutez chaque domaine d'envoi et de réception, le propriétaire du service et la classification des informations traitées. L'implication d'un fournisseur nécessite sa propre analyse contractuelle : les clients gouvernementaux et un suffixe de domaine familier n'identifient pas, à eux seuls, toutes les obligations qui lient un fournisseur. Enregistrez la politique ou l’accord réel qui transpose l’exigence dans ce service.
Lire ensemble les instructions de politique et de configuration
Le guide de configuration complémentaire comprend les boîtes aux lettres, les relais, les services de filtrage et les expéditeurs transactionnels tiers. Ses instructions d'authentification couvrent le contrôle entrant et le contrôle sortant Application DMARC, avec SPF et DKIM configuration. Considérez une politique par étapes comme une étape de mise en œuvre avec un propriétaire et des critères de sortie, plutôt que comme une définition indéfinie de l'achèvement. La date de mars 2024 du guide est également importante lors de l'évaluation de ses dépendances opérationnelles. Configuration de la messagerie gouvernementale.
Pour le contexte de classification des informations, le Cabinet Office Guidance 1.5, version 2.0 du 5 août 2024, identifie l'authentification de domaine et les protections de transport dans ses contrôles de messagerie. La colonne de courrier électronique OFFICIELLE comprend DMARC , DKIM , SPF , MTA-STS et rapports TLS ; les niveaux plus sensibles ont des modalités de partage différentes. Ne détachez pas cette colonne du tableau de classification environnant et ne présentez pas une conception de courrier Internet adaptée à chaque classification. Conseils du conseiller en sécurité.
Résoudre la dépendance du service à la retraite
Il existe un problème de version concret dans l’ensemble source. L'ancienne page de configuration dirige toujours les administrateurs vers NCSC Mail Check, y compris des exemples de rapports et d'enregistrement. Le propre avis de retrait du NCSC confirme que Mail Check et Web Check ont pris fin le 31 mars 2026. Par conséquent, un plan de mise en œuvre actuel ne peut pas traiter ces anciennes instructions comme une preuve que le service reste disponible. Il s'agit d'un problème de réconciliation des dépendances, et non d'une raison pour ignorer les contrôles d'authentification sous-jacents. Avis de retraite NCSC.
Destinations des rapports d'inventaire, propriété des notifications et service utilisé pour enquêter sur les échecs. Identifiez quelles destinations appartiennent à l’organisation et lesquelles dépendent d’un traitement retiré ou fourni en externe. Proposez un remplacement uniquement après avoir évalué l’accès, la conservation, la confidentialité et le coût. Cet article n'autorise pas la modification des adresses de déclaration ni la souscription à un service. Conservez les anciens enregistrements et le plan de transition approuvé afin qu'un auditeur puisse distinguer une migration planifiée d'une lacune de surveillance inexpliquée.
Construire des preuves autour des flux de courrier réels
Un enregistrement de contrôle utile comporte des champs séparés pour l'exigence, le paramètre prévu et le résultat observé. La publication d'une politique DNS restrictive ne prouve ni que toutes les applications légitimes s'alignent ni que chaque destinataire la rejette. usurpation d'identité. DMARC évalue le domaine d'auteur par rapport à une identité authentifiée alignée ; la spécification de base actuelle est RFC 9989, publié en mai 2026. Sa publication ne prouve pas que chaque produit a adopté son traitement mis à jour. Spécification DMARC actuelle.
Préparez un plan de preuves couvrant le courrier du personnel, les notifications de gestion de cas, les messages d'abonnement public et les expéditeurs délégués. Pour chaque flux, identifiez le domaine From visible, l'équipe responsable, le service de signature, la destination du rapport et l'impact en cas d'échec de la livraison. Conservez les observations du récepteur uniquement lorsqu’un test autorisé a lieu réellement. Une cellule de feuille de calcul indiquant configuré ne devrait pas devenir silencieusement un test de livraison réussi. Conservez les rapports d'incident et le contenu des messages sensibles dans des référentiels approuvés plutôt que de les intégrer dans un article public.
Travaillez sur un exemple de conseil fictif
Imaginez un courrier fictif du personnel d'exploitation du conseil et un fournisseur de notification de rendez-vous distinct. Son projet enregistre initialement l'application DMARC comme terminée car le domaine du personnel a une politique restrictive. La révision proposée révèle une question sans réponse : le fournisseur utilise-t-il une identité alignée pour les messages de rendez-vous ? Aucun message n'a été inspecté dans cet exemple, le résultat est donc une lacune dans les preuves et non un échec du test.
Le responsable de la politique du conseil confirmerait d'abord la portée pertinente du secteur public. L'équipe de messagerie définirait ensuite des flux de rendez-vous représentatifs et un plan d'acceptation contrôlé. L’équipe de sécurité vérifierait séparément que les rapports atteignent une destination maintenue après le retrait de Mail Check. Un questionnaire fournisseur complété constituerait une préparation utile mais ne remplacerait pas les preuves réelles du message. L'approbation doit nommer à la fois le propriétaire de l'entreprise acceptant le risque de perturbation et l'opérateur autorisé à modifier DNS .
Rendre explicites les exceptions et les dates de révision
Un enregistrement d'exception doit indiquer quel domaine ou itinéraire est affecté, pourquoi le contrôle cible n'est pas encore atteint, quelles mesures compensatoires existent et qui peut accepter le risque résiduel. Ajoutez une date de révision et un déclencheur tel qu'une migration de fournisseur, un changement de classification ou un avis de retraite. Ne fixez pas de délai légal à partir de la date de dernière mise à jour d'une page Web et ne présumez pas que les modalités d'évaluation historique s'appliquent toujours car elles restent dans un journal des modifications.
Le catalogue nécessite : Un tableau d'autorité de contrôle examiné par le spécialiste réglementaire ou juridique approprié. La carte qui l'accompagne est une préparation non approuvée de ce tableau et non un examen spécialisé. Avant la publication, obtenez la confirmation de la politique britannique et du propriétaire légal, un examen technique par une PME de la transition du service et des preuves opérationnelles originales pour toute réclamation de mise en œuvre. Le lecteur complet laisse également ouvertes les portes visuelles, de production et de libération par le propriétaire. Aucun conseil, système gouvernemental ou destination de rapport n'a été consulté ou modifié pour cet article.