Politique Sécurité Réseau ISO 27001 : Word [A.8.20-22]

La politique de sécurité réseau ISO 27001 est l'un des documents techniques les plus attendus par les auditeurs de certification. Elle répond aux exigences des contrôles A.8.20 — Sécurité des réseaux, A.8.21 — Sécurité des services réseau et A.8.22 — Filtrage du Web de l'Annexe A ISO/IEC 27001:2022. Ces trois contrôles du thème Technologique couvrent l'intégralité de la protection du périmètre réseau : segmentation des zones de confiance, contrôle des flux entrants et sortants, gestion sécurisée des services réseau (DNS, DHCP, NTP, SNMP), surveillance des communications, et filtrage des accès Internet. Dans le contexte actuel où les attaques par mouvement latéral, ransomware et exfiltration de données via le réseau constituent la majorité des compromissions réussies, une politique réseau rigoureuse n'est pas un simple exercice de conformité — c'est une nécessité opérationnelle. Ce modèle Word, développé par Ayi NEDJIMI, consultant cybersécurité et Lead Implementer ISO 27001, couvre la segmentation réseau selon le modèle Tier 0/1/2 (Active Directory), l'architecture Zero Trust et micro-segmentation, les règles de gestion des accès distants (VPN, ZTNA, SASE), la politique de gestion des règles firewall (changement, révision, décommissionnement), la surveillance réseau et la détection d'anomalies (NDR), et les exigences de sécurité pour les services réseau tiers et cloud. Il s'adresse aux RSSI qui formalisent l'architecture de sécurité réseau, aux équipes Infrastructure/Network qui implémentent les contrôles, aux administrateurs système qui gèrent les règles firewall au quotidien, et aux auditeurs internes qui vérifient la conformité des configurations réseau. La politique réseau doit être lue en parallèle avec la politique de logging et monitoring (A.8.15-16) et la politique de sécurité physique (A.7) pour couvrir l'ensemble du périmètre de sécurité infrastructure.

Contexte réglementaire et normatif

Les contrôles A.8.20, A.8.21 et A.8.22 d'ISO 27001:2022 appartiennent au thème Technologique et remplacent les anciens contrôles A.13.1 (gestion de la sécurité des réseaux) et A.13.2 (transfert de l'information) de la version 2013, en les enrichissant avec des exigences relatives aux architectures modernes (cloud, zero trust, SD-WAN).

Le contrôle A.8.20 exige que les réseaux soient gérés et contrôlés pour protéger les systèmes et applications. A.8.21 exige que les caractéristiques de sécurité, les niveaux de service et les exigences de gestion de tous les services réseau soient identifiés et intégrés. A.8.22 exige que l'accès aux sites Web externes soit géré pour réduire l'exposition aux contenus malveillants.

Plusieurs référentiels complètent ou renforcent ces exigences :

• Guide ANSSI "Recommandations pour la mise en place de cloisonnement réseau" : référence française pour la segmentation des réseaux d'entreprise. Les modèles de segmentation par niveaux de confiance sont directement intégrés dans ce template.
• NIST SP 800-41 (Guidelines on Firewalls and Firewall Policy) : guide de référence pour la définition et la gestion des politiques firewall, compatible avec les exigences A.8.20.
• Zero Trust Architecture (NIST SP 800-207) : cadre architectural que le contrôle A.8.20 encourage implicitement en demandant que la confiance dans le réseau ne soit jamais présumée. Ce template intègre les principes Zero Trust.
• Directive NIS 2 (Article 21.2) : impose des mesures de sécurité réseau spécifiques pour les entités importantes et essentielles, alignées avec les contrôles A.8.20-22.
• Référentiel ANSSI EBIOS RM : les scénarios d'attaque via le réseau (mouvement latéral, exfiltration, C2) sont des menaces types à traiter dans le registre des risques avec les contrôles A.8.20-22 comme mesures de réduction.

Structure détaillée du template

Section 1 — Objet, périmètre et principes directeurs

Cette section définit les objectifs de la politique (protéger la confidentialité, l'intégrité et la disponibilité des communications réseau), son périmètre d'application (tous les réseaux filaires, Wi-Fi, WAN, VPN, SD-WAN et connexions cloud de l'organisation), et les principes architecturaux fondamentaux : moindre privilège (aucun flux autorisé par défaut), défense en profondeur (multiples couches de protection), séparation des réseaux de confiance différente, et surveillance continue de toutes les communications.

Section 2 — Architecture de référence et segmentation

Présentation de l'architecture réseau de référence avec les zones de sécurité : Zone DMZ (serveurs exposés Internet), Zone IT (systèmes d'information internes), Zone OT/IoT (systèmes industriels et objets connectés le cas échéant), Zone Management (administration des équipements réseau), Zone Invités (Wi-Fi visiteurs, réseaux temporaires), Zone Cloud (connexions aux services SaaS, IaaS, PaaS). Pour chaque zone : niveau de confiance, actifs concernés, flux autorisés entrants et sortants, contrôles de sécurité spécifiques. La segmentation Active Directory selon le modèle Tier 0 (contrôleurs de domaine), Tier 1 (serveurs membres) et Tier 2 (postes de travail) est également détaillée.

Section 3 — Politique de gestion des règles firewall

Procédure de gestion du cycle de vie des règles firewall : demande de changement (via le processus de gestion des changements A.8.32), approbation par le RSSI et le responsable réseau, implémentation par un administrateur habilité, test de validation, documentation dans la base de règles, revue périodique (trimestrielle recommandée) et décommissionnement des règles obsolètes. Inclut le principe "deny all, permit by exception" et l'interdiction des règles "any-any".

Section 4 — Gestion des accès distants

Politique d'accès à distance sécurisé : exigences pour les VPN (chiffrement AES-256, authentification MFA obligatoire, split tunneling interdit pour les accès aux systèmes sensibles), ZTNA (Zero Trust Network Access) pour les accès cloud, SASE pour les architectures distribuées, règles applicables aux prestataires et sous-traitants en accès distant. Tableau de correspondance accès/profil utilisateur/technologie autorisée.

Section 5 — Filtrage Web et DNS

Politique de filtrage des accès Internet : catégories de sites bloqués (malwares, phishing, proxies anonymiseurs, P2P, contenus illicites), catégories soumises à autorisation spéciale (réseaux sociaux, streaming, jeux), journalisation des accès Web pour investigation, DNS sécurisé (DoH/DoT), surveillance DNS pour détection de C2 et exfiltration via DNS. Procédure de demande de débloquage pour sites professionnels nécessaires.

Section 6 — Surveillance réseau et NDR

Exigences de surveillance des communications réseau : collecte des flux NetFlow/IPFIX, analyse comportementale des flux (NDR — Network Detection and Response), détection des protocoles non autorisés, alertes sur les anomalies de volume (exfiltration potentielle), intégration avec le SIEM pour corrélation. Définition des indicateurs clés de surveillance (nombre d'alertes NDR, taux de faux positifs, délai de détection).

Guide d'utilisation étape par étape

Étape 1 — Cartographie de l'infrastructure réseau existante

Avant de rédiger ou d'adapter la politique, réalisez une cartographie exhaustive de votre infrastructure réseau actuelle : schémas topologiques (L2/L3), inventaire des équipements actifs (switches, routeurs, firewalls, load balancers, proxies), liste des zones réseau existantes et de leur périmètre, inventaire des flux réseau autorisés (entrants, sortants, internes), connexions cloud et VPN actives. Cette cartographie est à la fois un prérequis pour rédiger une politique réaliste et une evidence attendue par les auditeurs pour vérifier la conformité des contrôles réseau.

Étape 2 — Définition des zones de sécurité

Sur la base de la cartographie, définissez les zones de sécurité réseau adaptées à votre contexte. Le modèle de segmentation minimal pour une PME comprend : une zone interne (LAN), une DMZ pour les serveurs exposés, une zone Wi-Fi invités isolée, et des connexions sécurisées vers le cloud. Pour une grande organisation ou une entité NIS 2, une segmentation plus fine est nécessaire (OT séparé, zone de supervision, VLAN par département). Documentez les niveaux de confiance de chaque zone et les flux autorisés entre zones dans une matrice de flux.

Étape 3 — Audit des règles firewall existantes

Réalisez un audit complet des règles firewall existantes : identifiez les règles obsolètes (services décommissionnés), les règles trop permissives (any-any, plages IP trop larges), les règles sans commentaire ou propriétaire identifié, et les règles en double. Cet audit est souvent révélateur de dérives accumulées au fil des années. Documentez les résultats et créez un plan de remédiation pour nettoyer le ruleset avant l'audit de certification.

Étape 4 — Rédaction et validation de la politique

Adaptez ce template à votre contexte spécifique en personnalisant les sections : remplacez les plages IP génériques par vos adresses réelles (ou des alias documentés), adaptez les technologies mentionnées à celles effectivement déployées dans votre infrastructure, ajustez les procédures de gestion des changements à votre processus ITSM existant. Faites relire la politique par les équipes réseau et sécurité avant validation formelle par la direction.

Étape 5 — Formation et communication aux équipes

La politique réseau est avant tout destinée aux équipes IT et réseau qui l'appliquent au quotidien. Organisez une session de formation pour présenter les nouvelles règles, les procédures de demande de changement, et les responsabilités de chacun. Pour les utilisateurs finaux, une communication simplifiée sur les règles de filtrage Web et d'accès distant suffit — ils n'ont pas besoin de connaître les détails techniques de la segmentation réseau.

Étape 6 — Implémentation des mesures techniques

Déployez les mesures techniques décrites dans la politique : configurez les VLAN et ACL correspondant aux zones définies, mettez en place le filtrage DNS, déployez ou configurez le proxy Web et le filtrage de contenu, activez la collecte NetFlow sur les équipements réseau critiques, configurez les alertes de surveillance réseau dans le SIEM. Documentez chaque configuration comme preuve de mise en œuvre.

Étape 7 — Révision annuelle et tests de pénétration

La politique réseau doit être révisée annuellement et après tout changement majeur d'infrastructure (migration cloud, nouveau site, fusion-acquisition). Complétez la révision par un test de pénétration réseau annuel réalisé par un prestataire qualifié (PASSI pour les organisations soumises à NIS 2). Les résultats du pentest alimentent le registre des risques et le RTP.

Étape 8 — Vérification de conformité et audit interne

Lors des audits internes, vérifiez la conformité des configurations réseau par rapport aux exigences de la politique : samplering des règles firewall, vérification de la segmentation des zones, test des contrôles d'accès distant, revue des logs de filtrage Web. Les non-conformités identifiées sont documentées et traitées via le processus d'action corrective (clause 10.1).

Tableau des contrôles / checklist complète

Checklist de 30 points de contrôle pour valider la conformité réseau lors d'un audit ISO 27001 :

Points de vigilance pour l'audit de certification

Piège 1 — Politique réseau déconnectée de la réalité technique

Une politique qui décrit une architecture idéale mais différente de ce qui est effectivement déployé est pire qu'une absence de politique — elle démontre un manque de contrôle. L'auditeur comparera le document aux configurations réelles. Remédiation : basez la politique sur un audit technique préalable et documentez explicitement les écarts à traiter dans le RTP.

Piège 2 — Règles firewall non documentées ou non justifiées

Les auditeurs demandent parfois à consulter le ruleset firewall. Des dizaines de règles sans commentaire, sans propriétaire, ou avec des noms génériques ("test", "temporaire") créent une impression de désorganisation. Remédiation : nettoyez le ruleset avant l'audit, ajoutez des commentaires sur chaque règle, et supprimez ou désactivez les règles obsolètes.

Piège 3 — Absence de contrôle sur les appareils personnels en BYOD

Si votre organisation autorise le BYOD (Bring Your Own Device), la politique réseau doit définir les contrôles spécifiques : réseau Wi-Fi BYOD isolé, MDM obligatoire, contrôles NAC sur les appareils personnels. L'absence de contrôles BYOD est une source fréquente de non-conformité. Remédiation : définissez une politique BYOD claire et déployez les contrôles techniques correspondants.

Piège 4 — Protocoles non sécurisés encore actifs

Telnet, FTP, SNMPv1/v2c, HTTP sur des interfaces d'administration, SMBv1 — ces protocoles sont encore présents dans de nombreux environnements legacy. Leur présence est systématiquement signalée lors des audits de certification et des tests de pénétration. Remédiation : réalisez un audit des protocoles actifs et planifiez la migration vers les versions sécurisées dans le RTP.

Piège 5 — Wi-Fi d'entreprise non sécurisé

WPA2-Personal avec une clé partagée connue de tous les employés et prestataires est insuffisant. WPA2/3-Enterprise avec authentification 802.1X et certificats est requis pour les réseaux d'entreprise. Le Wi-Fi invités doit être totalement isolé du réseau interne. Remédiation : déployez WPA2/3-Enterprise avec un serveur RADIUS pour le Wi-Fi d'entreprise.

Intégration dans le SMSI

La politique de sécurité réseau s'articule avec plusieurs autres documents du SMSI :

• Politique Logging et Monitoring (A.8.15-16) : les logs réseau (firewall, proxy, NetFlow) sont des sources d'événements critiques pour le SIEM.
• Politique Anti-Malware et EDR (A.8.7) : le réseau est un vecteur de propagation des malwares — les deux politiques doivent être cohérentes.
• Politique de Sauvegarde (A.8.13) : les flux de sauvegarde réseau doivent être documentés et sécurisés dans la politique réseau.
• Politique Services Cloud (A.5.23) : les connexions cloud (Direct Connect, ExpressRoute, Internet) font partie de l'architecture réseau.

Bonnes pratiques terrain

Adoptez une approche Zero Trust progressive : l'implémentation complète du Zero Trust Network Access est un projet de plusieurs années. Commencez par les principes fondamentaux (vérification explicite, moindre privilège, présomption de violation) et progressez par étapes. La segmentation réseau et le MFA sont les premières victoires.

Automatisez la gestion des règles firewall : les outils de gestion de politique réseau (Tufin, AlgoSec, FireMon) permettent d'automatiser les revues de règles, d'identifier les doublons et les règles shadow, et de générer des rapports de conformité. Pour les petites organisations, un tableur bien tenu suffit mais demande plus de rigueur manuelle.

Documentez les exceptions systématiquement : chaque dérogation à la politique (règle firewall temporaire, port ouvert exceptionnel, accès sans MFA) doit être documentée avec une date d'expiration et une justification business. Les exceptions sans date d'expiration deviennent rapidement permanentes.

Intégrez la sécurité dans les projets réseau dès le début : toute modification d'architecture réseau (déménagement, nouveau site, migration cloud) doit inclure une revue de sécurité en amont. Il est beaucoup plus coûteux de corriger des problèmes de sécurité réseau après déploiement qu'en phase de conception.

FAQ

Quelle est la différence entre A.8.20, A.8.21 et A.8.22 ?

Ces trois contrôles ont des périmètres distincts mais complémentaires. A.8.20 (Sécurité des réseaux) couvre la gestion et la protection de l'infrastructure réseau elle-même : segmentation, contrôle des flux, surveillance, règles firewall, gestion des équipements réseau. C'est le contrôle le plus large des trois. A.8.21 (Sécurité des services réseau) se concentre sur les services qui circulent sur le réseau : DNS, DHCP, NTP, SNMP, messagerie, mais aussi les services réseau fournis par des tiers (opérateurs télécom, hébergeurs). Il exige que les caractéristiques de sécurité de ces services soient identifiées, documentées et intégrées dans les accords avec les fournisseurs. A.8.22 (Filtrage du Web) est le plus spécifique : il concerne uniquement le contrôle des accès aux sites Web externes pour réduire l'exposition aux contenus malveillants (phishing, malwares drive-by, exfiltration via DNS). Ces trois contrôles fonctionnent ensemble et sont généralement couverts par un unique document de politique réseau. Lors d'un audit, l'auditeur pourra questionner chacun séparément avec des preuves spécifiques.

Le Zero Trust est-il imposé par ISO 27001 ?

Non, ISO 27001 n'impose pas d'architecture Zero Trust. La norme est technologiquement neutre — elle définit des exigences (contrôle des flux réseau, gestion des accès, surveillance) mais pas les technologies pour y répondre. Cependant, l'architecture Zero Trust est particulièrement bien alignée avec les principes d'ISO 27001 : vérification explicite (chaque accès est authentifié et autorisé), moindre privilège (accès strictement nécessaire), présomption de violation (surveillance continue, segmentation fine). Dans le contexte des attaques modernes (mouvement latéral post-compromission, ransomware), le Zero Trust est clairement une bonne pratique qui renforce significativement l'efficacité des contrôles A.8.20. Si votre organisation est soumise à NIS 2 ou si votre profil de risque est élevé, envisager une migration vers le Zero Trust est une priorité. Pour les PME avec des contraintes de ressources, une segmentation réseau rigoureuse et le MFA sur tous les accès critiques sont des premières étapes essentielles.

Comment gérer la sécurité réseau pour le télétravail ?

Le télétravail est devenu la norme dans de nombreuses organisations, et sa sécurisation est explicitement couverte par A.8.20. Les exigences minimales pour le télétravail sécurisé : VPN obligatoire pour accéder aux systèmes internes (avec MFA), chiffrement du disque dur du poste de travail (A.7.10), politique d'utilisation des réseaux Wi-Fi publics (interdire les réseaux ouverts ou exiger un VPN actif), contrôles sur les appareils personnels si le BYOD est autorisé (MDM, VPN client). Pour les organisations avec des systèmes très sensibles, le ZTNA (Zero Trust Network Access) offre des garanties supérieures au VPN traditionnel car il n'octroie pas un accès réseau global mais un accès applicatif granulaire. La politique réseau doit couvrir explicitement le télétravail avec des règles adaptées aux différents profils d'utilisateurs (salariés, prestataires, dirigeants). Voir aussi la procédure onboarding/offboarding pour les règles d'attribution et de révocation des accès VPN.

Que couvrir pour les réseaux OT et IoT dans la politique réseau ?

Les réseaux OT (Operational Technology) et IoT présentent des défis spécifiques qui nécessitent des mesures adaptées dans la politique réseau. L'isolation des réseaux OT/IoT du réseau IT est une exigence fondamentale : la compromission d'un réseau OT peut avoir des conséquences physiques graves (arrêt de production, accidents). Les principes clés pour les réseaux OT/IoT : segmentation stricte avec firewall dédié entre IT et OT, flux autorisés limités au strict nécessaire (supervision unidirectionnelle de préférence), inventaire exhaustif de tous les équipements OT et IoT connectés, procédure de patch management adaptée aux contraintes OT (indisponibilité pour maintenance difficile), surveillance réseau spécialisée (solutions type Claroty, Nozomi Networks). ISO 27001 s'applique à la sécurité de l'information — si votre périmètre SMSI inclut des systèmes OT, vous devez intégrer leur sécurité réseau dans la politique. Pour les systèmes industriels critiques, complétez par les standards IEC 62443.