Pourquoi la version A.8.20 est si importante pour les fournisseurs de services gérés
L'annexe A.8.20 est cruciale pour les fournisseurs de services gérés (MSP) car elle détermine si leur réseau peut héberger en toute sécurité de nombreux clients sans qu'une faille de sécurité ne se propage. Les grandes entreprises, les auditeurs et les assureurs utilisent ce contrôle pour évaluer l'isolation des locataires, la protection des outils de gestion et la gouvernance des pare-feu, reflétant ainsi l'importance accordée aux contrôles réseau de l'annexe A de la norme ISO 27001:2022 comme preuve essentielle que les réseaux sont gérés en fonction des risques. En étant en mesure d'expliquer clairement ces éléments et de fournir des preuves crédibles, vous réduisez l'impact des incidents, renforcez la confiance des acheteurs et consolidez votre position auprès des assureurs.
Des réseaux performants protègent discrètement chacun de vos clients, même en l'absence de témoins.
Si vous gérez un fournisseur de services gérés, votre réseau fait désormais partie intégrante de la surface d'attaque de chaque client. Une plateforme de gestion mal segmentée ou un cœur de réseau « plat » peuvent transformer un client compromis en vingt clients compromis.
La majorité des organisations interrogées dans le cadre de l'enquête 2025 d'ISMS.online déclarent avoir été touchées par au moins un incident de sécurité lié à un tiers ou à un fournisseur au cours de l'année écoulée.
L'annexe A.8.20 de la norme ISO 27001:2022, relative au contrôle « Sécurité du réseau », est désormais examinée par les auditeurs et les grands clients afin de vérifier si votre couche réseau est réellement maîtrisée. Concrètement, lors de la certification ISO 27001, les auditeurs se concentrent systématiquement sur ce contrôle et les contrôles réseau associés pour comprendre comment l'isolation des locataires, la gouvernance des pare-feu et la surveillance sont gérées dans les environnements mutualisés. Les assureurs et les organismes de réglementation attendent également des réponses concernant l'isolation des locataires, la gouvernance des pare-feu et la surveillance, notamment dans les environnements mutualisés.
Pour les MSP, le fait de considérer la norme A.8.20 comme une norme de conception et d'exploitation – et non pas simplement comme une ligne dans une politique – est ce qui distingue « nous pensons être en sécurité » de « nous pouvons expliquer et prouver comment chaque locataire est protégé ».
Ce que l'article A.8.20 exige réellement (en langage clair)
La norme A.8.20 exige que vous conceviez et exploitiez les réseaux de manière à protéger activement les informations plutôt que de simplement acheminer le trafic, et que vous les conceviez, les segmentiez et les gériez de façon à assurer une protection adéquate des informations qui y transitent. Le texte officiel de la norme ISO est protégé par le droit d'auteur, mais les commentaires publics sur cette norme – ainsi que les recommandations largement diffusées en matière de sécurité des réseaux et des pare-feu – s'accordent à dire que les réseaux et les périphériques réseau doivent être sécurisés, gérés et contrôlés en fonction des risques afin de garantir une protection adéquate des informations qui y circulent.
Concrètement, pour un fournisseur de services gérés, cela signifie que vous êtes censé :
- Concevoir des architectures de réseau délibérément basées sur les risques et la sensibilité de l'information.
- Segmenter les réseaux afin de séparer les locataires, les systèmes internes et les interfaces de gestion.
- Contrôlez l'accès entre les segments à l'aide de pare-feu, de VPN, de SD-WAN et de listes de contrôle d'accès.
- Mettez en œuvre ces contrôles conformément à des politiques, des normes et des processus clairs.
- La preuve que les contrôles fonctionnent dans le temps, et pas seulement sur le papier.
Le point A.8.20 n'est pas isolé. Il est étroitement lié à :
- A.8.22 – Ségrégation des réseaux : (comment les segments et les zones sont séparés).
- A.8.31 – Séparation du développement, des tests et de la production : (limites de l'environnement).
- A.8.15 / A.8.16 – Journalisation et surveillance : (en observant ce qui se passe sur le réseau).
- A.8.32 – Gestion du changement : (contrôle des modifications apportées aux pare-feu et aux périphériques réseau).
Ces liens reflètent la manière dont l'annexe A regroupe les contrôles réseau, de journalisation et de gestion des modifications connexes dans un catalogue unique. Il est donc naturel que les auditeurs et les responsables de la mise en œuvre les considèrent comme un programme de sécurité réseau intégré plutôt que comme un ensemble de contrôles isolés. En adoptant cette approche, vous constaterez que l'annexe A est beaucoup plus facile à mettre en œuvre et à expliquer, et vous présenterez aux clients et aux auditeurs une explication plus convaincante.
La norme ISO 27001 simplifiée
Une avance de 81 % dès le premier jour
Nous avons fait le plus gros du travail pour vous, en vous offrant une avance de 81 % dès votre connexion. Il ne vous reste plus qu'à remplir les champs.
Un modèle simple à 3 plans pour la sécurité des réseaux MSP
La conception et l'explication de la norme A.8.20 sont grandement facilitées si vous divisez votre infrastructure en trois plans logiques et sécurisez chacun d'eux de manière systématique. Une approche pertinente pour appréhender la sécurité réseau chez un fournisseur de services gérés (MSP) consiste à segmenter l'ensemble du réseau en trois « plans » logiques : entreprise, locataire et administration. Vous pouvez ainsi visualiser le flux de trafic, identifier les zones de restriction et démontrer comment prévenir qu'une compromission locale ne se propage à l'ensemble des locataires.
Dans ce modèle, on divise tout en trois « plans » logiques :
- Informatique d'entreprise / interne.
- Données locataire/client.
- Gestion / contrôle hors bande.
Chaque avion a des objectifs, des risques et des publics différents, mais tous trois doivent être sécurisés, gérés et contrôlés de manière à pouvoir être démontrés.
Plan informatique d'entreprise/interne
L'environnement réseau de l'entreprise doit protéger vos informations et éviter de devenir une porte d'entrée vers les environnements clients, car vos systèmes métiers y sont hébergés : messagerie, partage de fichiers, applications RH et financières, appareils du personnel, Wi-Fi d'entreprise et services similaires. En traitant cet environnement comme une zone distincte, avec des limites clairement définies et des accès contrôlés aux outils de gestion, vous réduisez le risque que des appareils du personnel ou des réseaux d'entreprise compromis ne se propagent discrètement aux environnements clients.
Dans ce domaine, on peut citer comme exemples typiques votre messagerie électronique, vos outils de collaboration, vos systèmes RH et financiers, le Wi-Fi d'entreprise et les terminaux du personnel.
Objectifs :
- Protégez les informations de votre entreprise.
- Empêcher les terminaux compromis d'accéder directement aux réseaux des locataires.
- Fournir au personnel des voies d'accès sécurisées et auditées aux outils de gestion.
Plan de données locataire/client
L'infrastructure mutualisée nécessite une isolation stricte entre les clients et une segmentation pertinente au sein de chaque client. En attribuant à chaque client son propre espace logique et en limitant les déplacements internes entre les zones, vous réduisez considérablement l'impact d'une éventuelle faille de sécurité et renforcez la crédibilité de votre infrastructure mutualisée auprès des entreprises clientes. Les recommandations du secteur public et de l'industrie destinées aux fournisseurs de services gérés (MSP) insistent également sur une isolation client renforcée et des processus d'administration rigoureusement contrôlés. Par conséquent, une séparation stricte des clients est une pratique courante et conforme aux attentes.
Tous les réseaux, sites et charges de travail que vous gérez pour vos clients se trouvent ici : réseaux locaux sur site, centres de données, VPC/VNET cloud et succursales.
Objectifs :
- Isolation stricte entre locataires.
- Segmentation interne appropriée au sein de chaque locataire (utilisateur, serveur, DMZ, OT et zones similaires).
- Connexions contrôlées vers votre plan de gestion et, si nécessaire, vers d'autres locataires.
Plan de gestion / hors bande
Le plan de gestion doit être considéré comme votre atout réseau le plus précieux et bénéficier de l'isolation la plus poussée possible. En délimitant les interfaces de gestion sur des chemins dédiés, avec des contrôles d'accès stricts et une surveillance continue, vous réduisez considérablement le risque qu'un outil compromis puisse affecter discrètement et simultanément de nombreux environnements clients.
Il s’agit du « système nerveux » qui contrôle tout : outils de surveillance et de gestion à distance, hyperviseurs, contrôleurs de stockage, commutateurs, pare-feu, accès console et serveurs de rebond.
Objectifs :
- Accès extrêmement restreint (uniquement via des chemins d'administration sécurisés).
- Aucune diffusion sur les réseaux publics.
- Journalisation complète, authentification forte et surveillance robuste.
A.8.20 vous demande de démontrer que chaque plan est :
- Sécurisé: (endurcis, segmenté, soumis au moindre privilège).
- Géré: (possédé, documenté, gouverné).
- Contrôlé: (modifications autorisées, activité enregistrée et vérifiée).
Une fois que vous avez cette vue d'ensemble à trois plans, chaque décision de conception concernant les VLAN, les VRF, le SD-WAN et les pare-feu peut être ancrée dans des objectifs clairs plutôt que dans des choix ponctuels, et vous pouvez expliquer cette logique aux clients, aux auditeurs et aux assureurs.
À ce stade, il est judicieux de dessiner votre propre diagramme à trois plans et de marquer les endroits où les chemins existants ou les services partagés traversent les limites que vous souhaitez imposer.
Conception de la segmentation pour les environnements multi-locataires
Pour les fournisseurs de services gérés (MSP) multi-locataires, la segmentation consiste à définir les limites de l'infrastructure et à contrôler les rares chemins qui les traversent. En séparant délibérément les locataires, les environnements et les voies de gestion – en s'appuyant sur le modèle à trois plans – la segmentation se résume à déterminer comment découper et connecter chaque plan afin de minimiser le risque qu'une erreur ou une faille de sécurité se répercute sur l'ensemble des clients et de simplifier la présentation de l'architecture réseau aux acheteurs et auditeurs d'entreprise.
Environ 41 % des organisations interrogées dans le cadre de l’enquête 2025 d’ISMS.online ont cité la gestion des risques liés aux tiers et le suivi de la conformité des fournisseurs comme un défi majeur en matière de sécurité de l’information.
En gardant à l'esprit le modèle à trois plans, vous pouvez décider comment chaque plan doit être découpé et connecté.
Isolation des locataires et segmentation par locataire
L'isolation par client est essentielle pour éviter qu'un problème rencontré par un client ne devienne un incident général. En attribuant à chaque client son propre domaine de routage et des liens soigneusement contrôlés vers les services partagés, vous pouvez garantir que son trafic reste confiné aux limites que vous avez définies et que vous pouvez l'ajuster sans impacter les autres clients. De plus, pour le niveau client, une isolation forte est la norme.
Pour le plan locataire, une isolation forte est l'attente par défaut :
- Utilisez des VLAN ou des VRF par locataire dans votre cœur de réseau pour attribuer à chaque client un domaine de routage logique.
- Dans les environnements cloud, utilisez des VPC/VNET distincts par client ou application principale.
- Considérez les plateformes d'hébergement mutualisé comme des zones à haut risque avec des contrôles d'entrée et de sortie très stricts.
Le principe est simple : le trafic d'un locataire ne doit jamais atteindre les systèmes d'un autre locataire, sauf si vous avez conçu et documenté une connexion spécifique et justifiée, et que vous pouvez démontrer comment elle est contrôlée.
Séparation des environnements (production / test / développement)
La séparation des environnements empêche les systèmes de test et de développement à faible fiabilité de compromettre les systèmes de production à haute fiabilité. En séparant clairement les expériences, les laboratoires et les projets pilotes par des segments distincts et des connexions strictement contrôlées avec les environnements de production, vous réduisez le risque qu'un raccourci pratique expose accidentellement des données clients réelles.
Le point A.8.20, conjointement au point A.8.31, exige que vous empêchiez les systèmes de test et de développement de compromettre la production. Ces deux contrôles, tels que définis dans la norme ISO 27001:2022, soulignent que les environnements à faible assurance ne doivent pas créer de voies d'accès non maîtrisées aux systèmes en production.
- Maintenez des sous-réseaux ou VLAN distincts pour le développement, les tests et la production dans chaque locataire ou environnement partagé.
- Veillez à ce que la connectivité entre les phases de test et de développement et la production soit strictement contrôlée et justifiée, et non « ouverte par commodité ».
- Empêcher les réseaux de laboratoire génériques et les environnements de validation de concept d'accéder aux données réelles des clients.
Séparation du plan de gestion
La séparation du plan de gestion garantit que les interfaces d'administration ne servent pas de raccourcis entre les locataires ni vers votre réseau d'entreprise. Lorsque les interfaces de gestion résident sur des segments dédiés avec un accès forcé via des chemins sécurisés, vous pouvez démontrer que les modifications apportées aux pare-feu, aux hyperviseurs et aux autres composants partagés passent toujours par des points de contrôle connus.
Votre plan de gestion est la cible la plus précieuse de votre patrimoine, il mérite donc son propre modèle de segmentation :
- Placez les interfaces de gestion sur des réseaux de gestion dédiés.
- Évitez d'exposer les interfaces de gestion sur les réseaux locaux des clients ou sur Internet ; utilisez des serveurs de rebond, des VPN ou des services bastion.
- Utilisez des VRF ou des fonctionnalités équivalentes pour séparer logiquement le trafic de gestion des flux des locataires et de l'entreprise.
Enclaves de services partagés
Les espaces de services partagés sont souvent le théâtre de nombreuses architectures « plates », et méritent donc une attention particulière. En regroupant les services partagés en segments dédiés et en limitant l'accès des locataires à des points d'accès spécifiques et justifiés, vous évitez de transformer ces services en un pont caché entre les clients.
Les services partagés (tels que le DNS, la journalisation, la surveillance, les référentiels de sauvegarde et les serveurs de gestion à distance) sont souvent le point faible de la segmentation. Pour les maîtriser :
- Regrouper les services partagés en enclaves dotées de leurs propres segments de réseau et pare-feu.
- Autoriser les locataires à accéder à ces enclaves uniquement via des ports et protocoles spécifiques et requis.
- Veillez à ce qu'il n'existe aucun chemin implicite d'un locataire, via un service partagé, vers un autre locataire.
Chemins d'accès distants sécurisés
Les chemins d'accès distant sécurisés sont ceux que vos ingénieurs empruntent au quotidien ; ils doivent donc refléter votre architecture de segmentation. En alignant les serveurs de rebond, les postes de travail privilégiés et les VPN sur votre modèle à trois niveaux, il devient beaucoup plus facile de justifier l'accès distant auprès des clients et de répondre aux questions des assureurs concernant les accès privilégiés.
La manière dont vos ingénieurs accèdent aux environnements clients est une préoccupation majeure du point A.8.20 :
- Privilégiez les hôtes bastions ou les postes de travail à accès privilégié comme tremplins vers les zones locataires.
- Intégrez l'accès à distance avec une identité forte et enregistrez toutes les sessions.
- Évitez les connexions RDP ou SSH directes depuis les ordinateurs portables d'entreprise vers les réseaux des locataires, et évitez les architectures « VPN pour tout ».
Pris ensemble, ces modèles répondent aux questions fondamentales de l’annexe A.8.20 :
- Comment les locataires sont-ils séparés ?
- Comment les réseaux internes, les réseaux locataires et les réseaux de gestion sont-ils séparés ?
- Par quels mécanismes contrôlés interagissent-ils ?
Lors de l'examen de votre segmentation actuelle, il est utile de lister les croisements entre les plans et les locataires, puis de vérifier si chaque croisement est réellement nécessaire et correctement contrôlé.
Libérez-vous d'une montagne de feuilles de calcul
Intégrez, développez et faites évoluer votre conformité, sans complications. IO vous offre la résilience et la confiance nécessaires pour croître en toute sécurité.
Des lignes de base de pare-feu qui rendent la segmentation réelle
Les pare-feu sont le point d'application de vos règles de segmentation. C'est pourquoi la norme A.8.20 accorde autant d'importance aux règles que vous appliquez qu'aux schémas que vous élaborez. Les schémas de réseau, à eux seuls, ne peuvent protéger les clients. L'application de ces règles repose sur les pare-feu et les passerelles. La norme A.8.20 s'intéresse à la manière dont vous configurez, gérez et surveillez ces dispositifs à tous les niveaux, afin que des référentiels clairs, appliqués de manière cohérente et rigoureusement contrôlés, du réseau sur site au cloud et au SD-WAN, démontrent que le principe de refus par défaut et le principe du moindre privilège sont des principes opérationnels concrets et non de simples slogans.
Le point A.8.20 s'intéresse à la manière dont vous configurez, gérez et surveillez vos pare-feu et passerelles sur l'ensemble de vos réseaux. Une configuration de référence cohérente, appliquée de l'infrastructure sur site au cloud et au SD-WAN, facilite grandement la communication de votre posture de sécurité aux auditeurs et aux clients.
Une base de référence pour les pare-feu basée sur les risques
Une configuration de pare-feu basée sur les risques offre à vos ingénieurs un cadre de départ reflétant votre niveau de sécurité, leur évitant ainsi de réinventer la roue pour chaque site ou client. Lorsque cette configuration est harmonisée entre les environnements sur site, cloud et SD-WAN, il devient beaucoup plus simple de démontrer aux auditeurs et aux clients que vos règles sont définies par le risque, et non par la facilité d'utilisation. Pour un fournisseur de services gérés (MSP) conforme à la norme A.8.20, une configuration pertinente se présente comme suit.
Pour un MSP aligné sur A.8.20, une base de référence raisonnable ressemble à ceci :
- Refus par défaut sur toutes les interfaces avec des règles « d’autorisation » explicites uniquement pour les flux requis.
- Règles du moindre privilège avec un objectif clair, une portée minimale et un nombre minimal de ports.
- Contrôle strict des sorties afin que les réseaux n'atteignent que ce dont ils ont réellement besoin.
- Accès de gestion renforcé avec des interfaces dédiées, des sources contrôlées et une authentification forte.
Cette base de référence devrait s'appliquer à :
- Pare-feu périmétriques.
- Pare-feu de segmentation interne entre les VLAN et les zones clés.
- Groupes de sécurité cloud, pare-feu réseau et pare-feu applicatifs utilisés comme contrôles réseau.
Lorsque vous comparez les pare-feu actuels à cette configuration de référence, dressez une liste simple des principales lacunes afin de pouvoir prioriser les corrections là où c'est le plus important.
Gouvernance des règles et contrôle des changements
La gouvernance des règles et le contrôle des changements déterminent si la sécurité de votre pare-feu s'améliore au fil du temps ou si elle sombre progressivement dans le chaos. En confiant les règles aux responsables, en leur fournissant des justifications claires et en effectuant des revues régulières, vous vous assurez que les règles obsolètes et générales sont éliminées plutôt que de réapparaître insidieusement.
Le point A.8.20 concerne autant la manière dont vous gérez les pare-feu que leur emplacement. Les bonnes pratiques incluent :
- Une norme documentée de sécurité réseau ou de pare-feu qui définit la configuration de base et les conventions de règles.
- Un processus formel de modification des règles et de la configuration, comprenant une évaluation des risques et une procédure d'approbation.
- Tester ou au moins annuler les plans de changement non négligeables, en consignant les détails de mise en œuvre.
Journalisation, surveillance et IDS/IPS
La journalisation et la surveillance démontrent que vos contrôles réseau sont dynamiques et non de simples instantanés de configuration statiques. En expliquant comment les alertes des pare-feu et des capteurs s'intègrent à vos processus opérationnels, vous prouvez que vous détectez et traitez les activités suspectes aux points critiques.
Pour démontrer que les pare-feu et la segmentation sont « gérés et contrôlés » :
- Consignez les événements liés à la sécurité, tels que les autorisations, les refus et les connexions d'administrateur.
- Envoyer les journaux à une plateforme centrale où ils sont corrélés et conservés conformément à la politique en vigueur.
- Déployez des systèmes de détection d'intrusion ou de détection des menaces aux frontières critiques, telles que les points de présence d'Internet et les zones de services partagés.
- Définir comment les alertes sont triées, escaladées et clôturées, et comment les conclusions permettent d'apporter des améliorations.
Ce lien entre A.8.20 et les contrôles de journalisation et de surveillance (A.8.15, A.8.16) démontre que la sécurité de votre réseau est un contrôle actif et non statique. Dans l'ensemble de contrôles de l'annexe A, ces domaines sont délibérément regroupés afin que la défense et la surveillance du réseau soient perçues comme les éléments d'une boucle de rétroaction continue plutôt que comme des activités isolées.
Preuve de conformité : documentation et preuves attendues par les auditeurs
La conformité à l'annexe A.8.20 est évaluée en fonction de votre capacité à démontrer clairement l'intention, la mise en œuvre et l'exploitation dans le temps. Les auditeurs et les clients importants souhaitent observer à la fois l'intention de conception et des preuves d'exploitation. Par conséquent, en constituant un ensemble réutilisable de documents et d'enregistrements reliant la conception de votre réseau, vos normes de pare-feu et vos activités de surveillance à ce contrôle, vous facilitez les audits et renforcez la confiance de vos clients envers votre fournisseur de services gérés.
Le rapport « État de la sécurité de l'information 2025 » indique que les clients attendent de plus en plus des fournisseurs qu'ils s'alignent sur des cadres formels tels que l'ISO 27001, l'ISO 27701, le RGPD, Cyber Essentials, SOC 2 et les normes émergentes en matière d'IA.
Pour l’annexe A.8.20, les auditeurs et les clients plus importants veulent voir à la fois l’intention de conception et la preuve du fonctionnement.
artefacts de niveau conception
Les documents de conception expliquent la structure et le fonctionnement de vos réseaux. Lorsqu'ils sont à jour et référencés directement dans votre contrôle A.8.20, ils permettent aux ingénieurs, aux auditeurs et aux clients de se familiariser rapidement avec le système sans avoir à détailler chaque appareil. Voici quelques exemples d'éléments qui contribuent à fournir des explications crédibles :
Éléments typiques qui vous aident à raconter une histoire crédible :
- Une politique de sécurité réseau définissant les principes généraux de segmentation et d'accès à distance.
- Une norme de segmentation réseau et de pare-feu qui traduit les principes en modèles concrets.
- Diagrammes de réseau présentant des vues sur trois plans et des exemples d'agencement de locataires ou de sites.
- Une déclaration d’applicabilité pour A.8.20 et les contrôles associés qui font référence à ces documents.
Ensemble, ces éléments démontrent que la conception de la sécurité de votre réseau est intentionnelle, documentée et conforme à l'annexe A.8.20 plutôt qu'un résultat accidentel de la croissance.
Preuves au niveau opérationnel
Les données opérationnelles permettent de vérifier si vos réseaux fonctionnent comme prévu et si vous corrigez les dérives dès leur apparition. C'est à ce niveau que les auditeurs et les grands clients s'appuient pour confirmer que vos schémas et normes résistent aux changements et aux contraintes du monde réel.
Pour démontrer que les commandes sont utilisées et entretenues, il est utile de disposer de :
- Configurations de référence ou exportations de pare-feu, routeurs, commutateurs et contrôleurs SD-WAN représentatifs.
- Enregistrements des modifications apportées au pare-feu et au réseau principal, y compris les approbations et les notes de test.
- Examiner les enregistrements pour les révisions périodiques des règles de pare-feu et les contrôles de segmentation.
- Rapports de surveillance présentant les alertes, les réponses et les enseignements tirés des incidents liés au réseau.
Un système de gestion de la sécurité de l'information (SGSI) simplifie considérablement cette gestion en pratique. Les experts en conformité continue soulignent souvent que, sans système de gestion structuré, il devient rapidement ingérable de maintenir l'alignement des politiques, des preuves et des décisions relatives aux risques avec les contrôles spécifiques. En centralisant les politiques, les schémas, les configurations de pare-feu, les enregistrements de modifications et les rapports de surveillance et en les reliant directement à la norme A.8.20 et aux risques pertinents, une plateforme comme ISMS.online vous permet de constituer rapidement des dossiers d'audit et de répondre aux questionnaires clients sans avoir à rechercher des fichiers épars.
Dans ISMS.online, vous pouvez, par exemple, lier directement votre norme de pare-feu A.8.20, vos schémas de réseau et vos enregistrements de modifications à l'entrée de contrôle et aux risques associés, afin que vos ingénieurs, vos auditeurs et vos équipes de compte client puissent tous voir comment les preuves s'articulent.
Gérez toute votre conformité, en un seul endroit
ISMS.online prend en charge plus de 100 normes et réglementations, vous offrant une plate-forme unique pour tous vos besoins de conformité.
Faiblesses courantes et comment les corriger sans interrompre les services
La plupart des fournisseurs de services gérés (MSP) découvrent des faiblesses similaires lors de leur première analyse de conformité à la norme A.8.20. Nombre de ces faiblesses proviennent de phases de croissance antérieures plutôt que d'une mauvaise intention. Les articles spécialisés sur la segmentation des réseaux et l'hygiène des pare-feu soulignent régulièrement les erreurs récurrentes liées aux réseaux plats, aux chemins d'administration partagés et aux règles trop générales. Vous n'êtes donc probablement pas le seul à rencontrer ces problèmes. En abordant ces questions de manière progressive et basée sur les risques, vous pouvez renforcer la sécurité de votre réseau sans provoquer d'interruptions de service ni surcharger vos équipes.
Deux tiers des organisations interrogées dans le cadre de l'enquête 2025 d'ISMS.online affirment que la rapidité et l'ampleur des changements réglementaires rendent la conformité plus difficile à maintenir.
De nombreux fournisseurs de services gérés (MSP) rencontrent des problèmes similaires lorsqu'ils s'auto-évaluent pour la première fois par rapport au point A.8.20 :
- Un réseau interne largement plat avec une utilisation superficielle des VLAN.
- Interfaces de gestion partagées situées sur les réseaux de production ou exposées à Internet.
- Règles de pare-feu trop générales (« tout-tout »), vestiges de dépannages antérieurs ou de déploiements précipités.
- Réseaux de laboratoire, de test ou anciens réseaux non suivis qui contournent les normes actuelles.
- Journalisation et surveillance incohérentes entre les pare-feu et les zones clés.
Ces faiblesses augmentent le risque qu'une seule faille de sécurité se propage rapidement, que des changements passent inaperçus et que vous ne puissiez pas répondre de manière convaincante aux questions des clients concernant l'isolation et la gouvernance.
Une brève comparaison des faiblesses typiques, de leurs risques et des premières solutions peut vous aider à prioriser les tâches.
| Faiblesse commune | Risque associé | Premier correctif |
|---|---|---|
| réseau interne plat | Mouvement latéral à travers de nombreux systèmes | Introduire des VLAN de base et des zones simples |
| Interfaces de gestion exposées | Prise de contrôle directe des outils d'administration | Passer à des réseaux de gestion dédiés |
| Règles de pare-feu « Any-any » | Accès non contrôlé entre les zones clés | Consignez l'utilisation, puis remplacez-la par des règles plus restrictives. |
| Réseaux de laboratoire ou réseaux hérités non suivis | Chemins cachés vers la production ou les locataires | Découvrir, documenter et mettre aux normes |
| Journalisation et surveillance inégales | Les attaques ou les erreurs de configuration passent inaperçues. | Centraliser la journalisation des pare-feu et VPN clés |
Si vous ne devez corriger que deux choses ce trimestre, commencez par aplatir les réseaux internes en zones et déplacer les interfaces de gestion exposées sur des chemins dédiés et bien contrôlés.
Il n'est pas nécessaire de tout régler du jour au lendemain, et il convient d'éviter les modifications susceptibles de provoquer des pannes généralisées. Une approche pragmatique consiste à procéder par étapes et à veiller à ce que chaque modification soit réversible.
Étape 1 – Prioriser par risque
Privilégiez les locataires, les plateformes partagées et les passerelles pour lesquelles une compromission causerait le plus grand préjudice aux clients et à votre propre entreprise.
Commencez par les locataires des secteurs réglementés ou à haute sensibilité, les plateformes de gestion partagées et les passerelles connectées à Internet où une défaillance serait la plus préjudiciable.
Étape 2 – Stabiliser avant de segmenter
Stabilisez vos réseaux actuels en vous assurant de disposer d'informations de configuration fiables, d'une surveillance de base des périphériques clés et de plans de secours éprouvés.
Assurez-vous de disposer d'informations fiables sur vos actifs et leur configuration, d'une surveillance de base des appareils clés et de plans de repli testés pour les changements majeurs.
Étape 3 – Introduire la segmentation en couches
Introduisez la segmentation par couches gérables, en commençant par les réseaux de gestion, puis en séparant les zones utilisateurs et serveurs pour un petit ensemble de locataires.
Commencez par créer des VLAN ou des VRF de gestion, puis séparez les réseaux des utilisateurs et des serveurs dans les locataires pilotes, et enfin affinez les enclaves de services partagés et les règles de sortie.
Étape 4 – Utiliser des pilotes et des schémas standard
Utilisez des projets pilotes et des modèles convenus afin que vos équipes NOC et projet puissent tester les nouvelles conceptions auprès d'un petit groupe de locataires avant un déploiement plus large.
Tester les modèles auprès d'un petit groupe de clients avant de les déployer à grande échelle, et ajuster les conceptions en fonction des retours opérationnels réels des ingénieurs et des clients.
Étape 5 – Aborder progressivement les règles « n'importe quel type »
Réduisez progressivement les règles « tout-tout » en consignant leur utilisation, en les remplaçant par des autorisations spécifiques, puis en supprimant les règles générales une fois que vous êtes sûr de vous.
Consignez la manière dont les règles générales sont utilisées, remplacez-les par des autorisations spécifiques et des refus contrôlés, et examinez les résultats avant de supprimer les dérogations temporaires.
À chaque amélioration, mettez à jour vos schémas, normes et preuves. L'approche A.8.20 vise une gestion continue, et non une refonte ponctuelle. Envisager les correctifs comme un programme progressif facilite le maintien de la qualité de service tout en renforçant l'infrastructure.
Réservez une démo avec ISMS.online dès aujourd'hui
ISMS.online vous aide à transformer l'annexe A.8.20, souvent perçue comme un casse-tête technique, en une composante structurée et étayée de votre programme ISO 27001, compréhensible par vos ingénieurs, auditeurs et clients. En centralisant vos politiques réseau, normes, schémas, configurations de pare-feu et historiques de modifications dans un espace de travail unique, et en considérant l'annexe A.8.20 comme un programme reproductible plutôt qu'un projet ponctuel, vous pouvez suivre une feuille de route simple, de la compréhension à l'identification des modèles, puis à l'exploitation et à la justification. Vos réseaux deviennent ainsi plus sûrs, vos audits plus fluides et vos échanges commerciaux plus convaincants. En résumé, la mise en œuvre de l'annexe A.8.20 dans un MSP mutualisé peut se résumer à un parcours simple, bien que comportant plusieurs étapes, que vos responsables techniques et ingénieurs peuvent suivre ensemble.
Malgré la pression croissante, la quasi-totalité des répondants au rapport « État de la sécurité de l’information 2025 » citent l’obtention ou le maintien de certifications de sécurité telles que l’ISO 27001 ou le SOC 2 comme une priorité absolue.
Étape 1 – Voir la réalité
Visualisez la réalité de vos réseaux actuels en cartographiant les zones de chevauchement entre les locataires, les systèmes internes et les plans de gestion, ainsi que la circulation du trafic entre eux.
Cartographiez vos réseaux existants, identifiez les zones de chevauchement entre les locataires, les plans internes et de gestion, et quantifiez les risques liés à la sécurité et à l'activité.
Étape 2 – Définir ce à quoi ressemble un « bon »
Définissez ce à quoi ressemble un « bon » en traduisant A.8.20 et les contrôles associés en résultats spécifiques aux MSP et en documentant votre modèle à trois plans et vos bases de référence de pare-feu.
Interprétez A.8.20 et les contrôles associés en résultats spécifiques aux MSP, adoptez le modèle à trois plans et notez vos lignes de base de segmentation et de pare-feu.
Étape 3 – Concevoir des motifs répétitifs
Concevez des modèles reproductibles afin que votre centre d'opérations réseau, vos équipes de projet et vos architectes puissent mettre en œuvre les mêmes conceptions éprouvées chez de nombreux clients et sur de nombreuses plateformes.
Créer des architectures de référence pour la segmentation par locataire, les services partagés et l'accès administrateur, standardiser les règles de pare-feu et déterminer comment les environnements cloud et sur site s'adaptent aux mêmes modèles.
Étape 4 – Mise en œuvre et exploitation
Mettez en œuvre et exploitez vos modèles par phases, en commençant par les zones à haut risque et en veillant à ce que la surveillance et les examens garantissent l'intégrité de la conception au fil du temps.
Déployez les configurations de segmentation et de pare-feu par phases en fonction des risques, centralisez la journalisation et la surveillance aux points clés et effectuez des revues régulières pour affiner la conception.
Étape 5 – Constituer des preuves et améliorer
Constituez un ensemble de preuves A.8.20 réutilisable et améliorez-le chaque fois que votre entreprise, votre pile technologique ou votre environnement réglementaire change.
Constituez un ensemble de preuves A.8.20 réutilisable, reliez-le aux risques et à la déclaration d'applicabilité, et revoyez la conception après des changements importants dans les affaires, la technologie ou la réglementation.
En accompagnant cette démarche d'un système de gestion de la sécurité de l'information (SGSI) structuré, vous facilitez grandement la synchronisation de l'architecture, des opérations et de la documentation. Une plateforme SGSI telle que ISMS.online vous permet de lier directement vos politiques A.8.20, vos normes réseau, vos schémas, vos enregistrements de modifications et vos preuves de surveillance au système de contrôle, afin de démontrer la sécurité de manière à satisfaire les clients, les auditeurs et les organismes de réglementation.
Pour vos équipes NOC et de projet, cela signifie moins de temps passé à rechercher des documents, des modèles plus clairs à mettre en œuvre et moins de surprises lors des audits et des revues clients.
Au fil du temps, cette combinaison d'une conception claire, d'un fonctionnement rigoureux et de preuves bien organisées peut aider à transformer A.8.20 d'une simple case à cocher en un atout commercial, contribuant à réduire les incidents entre locataires, à faciliter les ventes aux entreprises et à fournir une explication plus convaincante aux assureurs et aux partenaires qui comptent sur votre réseau pour protéger leurs propres activités.
Si vous souhaitez voir à quoi cela ressemble en pratique, vous pouvez réserver une démonstration avec ISMS.online et découvrir comment votre référentiel de sécurité réseau A.8.20 peut être conçu, exploité et documenté en un seul endroit.
Demander demoFoire aux questions
Comment devez-vous traiter la norme ISO 27001 A.8.20 lors de la conception ou de l'examen d'un réseau MSP ?
Vous devez considérer la norme A.8.20 comme une norme de conception et d'exploitation pour l'ensemble de votre réseau MSP, et non pas comme une simple « case à cocher pour le pare-feu ». Elle exige que vous démontriez que la segmentation est intentionnelle, que les limites sont contrôlées et que les opérations quotidiennes protègent systématiquement les informations des clients et de l'entreprise.
À quoi ressemble une « bonne » version d'A.8.20 dans un environnement de services gérés ?
Une manière pratique d'appréhender le test A.8.20 est de considérer qu'il teste quatre éléments :
- Vous avez zones de réseau clairement définies avec un objectif (entreprise, locataire, gestion, services partagés).
- Ces zones sont séparées par limites imposées (pare-feu, ACL, routage, contrôles prenant en compte l'identité).
- Vous exploiter, surveiller et examiner ces limites, définies dans un calendrier et liées au risque.
- Voici à quoi vous expliquer et preuves Tout ce qui précède peut être fourni à un auditeur ou à un client entreprise en quelques minutes, et non en plusieurs semaines.
Un test simple permet de vérifier si une nouvelle recrue s'avère nécessaire : si elle intégrait votre organisation demain, pourriez-vous lui fournir un ou deux schémas, une brève présentation des normes de sécurité réseau et quelques exemples (tickets de modification, revues, alertes) lui permettant de comprendre le flux de trafic ? Si la réponse est oui, vous êtes déjà proche des exigences de la norme A.8.20 ; si la réponse est « c'est dans la tête des gens », la norme A.8.20 vous invite à formaliser ces connaissances et à les intégrer à votre système de gestion de la sécurité de l'information (SGSI).
Comment la clause A.8.20 interagit-elle avec les autres clauses de la norme ISO 27001 et les contrôles de l'annexe A ?
A.8.20 fait partie d'un ensemble d'exigences qui se renforcent mutuellement :
- Article 4.3 (champ d’application) : définit quels segments de réseau, plateformes et locataires font partie de votre SMSI.
- Article 6.1 (évaluation et traitement des risques) : explique pourquoi vous avez choisi des modèles de segmentation, des technologies ou des architectures cloud particuliers.
- Annexe A.8.21 et A.8.22 : traiter de la manière dont les services réseau et la ségrégation sont gérés dans les opérations quotidiennes.
- Annexe A.5.23 (services cloud) : explique comment les constructions de cloud public (VPC, VNets, peering) s'alignent sur votre modèle de segmentation.
- Annexe A.5.24–A.5.27 (gestion des incidents) : Cela devient pertinent lorsqu'une faiblesse du réseau entraîne un événement ou un incident.
Lorsque votre déclaration d'applicabilité, votre politique réseau, vos registres de risques et vos schémas convergent, le point A.8.20 cesse d'être un simple contrôle de pare-feu et devient la couche réseau visible de votre système de gestion de la sécurité de l'information (SGSI). L'utilisation d'une plateforme comme ISMS.online simplifie cette transition, car vos politiques, risques, schémas, configurations et revues peuvent tous être liés au contrôle depuis un seul et même endroit.
Comment un MSP peut-il concevoir un réseau à trois plans qui satisfait à la norme A.8.20 et fonctionne toujours sous pression ?
Concevoir un réseau à trois plans adapté aux ingénieurs implique d'isoler les environnements d'entreprise, locataires et de gestion tout en préservant la praticité des flux de travail. La norme A.8.20 n'impose pas de technologies spécifiques ; elle exige de démontrer que ces plans sont volontairement séparés et ne sont reliés que lorsque cela est justifié par les besoins de l'entreprise.
Quels sont les éléments essentiels d'une conception MSP à trois plans ?
Une conception robuste à trois plans comprend généralement :
- Avion d'affaires : – services d’identité, messagerie électronique, systèmes RH et financiers, outils de collaboration et vos propres applications métiers.
- Plan locataire : – des réseaux et des charges de travail par client, segmentés par VLAN, VRF, VPC/VNet ou constructions similaires, avec des limites de confiance claires entre les locataires.
- Plan de gestion : – outils de surveillance et de gestion à distance, consoles d'hyperviseur, interfaces d'administration de périphériques réseau, plateformes de sauvegarde et d'observabilité.
Le point crucial concernant A.8.20 est que le trafic entre ces plans est contraint de transiter par des passerelles bien définies, permettant l'application du principe du moindre privilège et la journalisation de l'activité. Par exemple, les ingénieurs peuvent se connecter depuis des terminaux sécurisés, via un VPN d'exploitation sécurisé, puis via un serveur de rebond vers le plan de gestion, au lieu d'accéder directement aux appareils depuis les réseaux locaux de l'entreprise ou Internet. Lorsque chaque nouvel utilisateur utilise un schéma reproductible et que chaque ingénieur emprunte le même chemin d'accès, l'architecture devient plus facile à sécuriser, à expliquer et à auditer.
Comment éviter que la segmentation ne se transforme en un labyrinthe inutilisable pour vos ingénieurs ?
La segmentation échoue lorsqu'elle est si complexe que les utilisateurs se sentent obligés de la contourner. Pour qu'elle reste fonctionnelle :
- Définir un petit ensemble de plans de locataires standard avec les schémas et les matrices de ports publiés, puis réutilisez-les.
- Créer zones de services partagés pour des fonctions telles que la surveillance, la sauvegarde, l'authentification et la journalisation, avec des règles claires sur qui peut y accéder.
- Fournir un nombre limité de « passerelles administratives » (par exemple, deux points d'accès sécurisés régionaux) plutôt que des chemins sur mesure pour chaque ingénieur.
- Automatisez les tâches de routine telles que le déploiement de profils VPN, l'accès aux serveurs de rebond et l'enregistrement des sessions privilégiées afin que le chemin sécurisé soit également le plus simple.
En documentant ces modèles au sein de votre SMSI et en les reliant à l'annexe A.8.20, vous offrez aux équipes une référence fiable. Sur ISMS.online, vous pouvez associer les diagrammes, les normes et les procédures d'accès au contrôle et les maintenir alignés sur la gestion des changements, permettant ainsi aux ingénieurs d'avoir une vision d'ensemble cohérente plutôt qu'une situation évolutive.
Quelles normes de pare-feu et de routage sont les plus importantes pour A.8.20 dans un MSP multi-locataire ?
Pour le point A.8.20, vos normes de pare-feu et de routage constituent l'expression concrète de la « ségrégation du réseau ». Le contrôle s'intéresse moins aux marques qu'à l'application d'une base de référence cohérente partout et à la possibilité de démontrer son respect.
Que doit contenir une configuration de base de pare-feu et de routage conforme à la norme A.8.20 ?
Un référentiel efficace pour un prestataire de services comprend généralement :
- A posture de refus par défaut, seuls les flux explicitement autorisés étant permis et chaque règle étant liée à un besoin documenté.
- Contrôles nord-sud : (trafic internet et inter-sites) : utilisation de l’inspection avec état, de la sécurité DNS, des contrôles DDoS, du blocage basé sur la réputation ou la géographie lorsque cela est proportionné.
- Ségrégation Est-Ouest : (à l'intérieur et entre locataires, entreprise et direction) : restrictions sur les déplacements latéraux, séparation des réseaux utilisateurs et serveurs, et isolation stricte des systèmes privilégiés.
- Contrôles d'accès administratif : où, comment et par qui les interfaces de gestion peuvent être atteintes, y compris l’authentification multifactorielle et les exigences en matière d’hygiène des appareils.
- Journalisation et surveillance : sources de journaux minimales et durée de conservation, corrélation dans les plateformes SIEM ou de journaux, seuils d'alerte et cadence de révision définie.
Les mêmes principes s'appliquent dans le cloud et sur site : les groupes de sécurité réseau et les pare-feu cloud doivent respecter les mêmes règles que les dispositifs physiques. En formalisant cette exigence dans votre système de gestion de la sécurité de l'information (SGSI) et en la reliant à l'annexe A.8.20, vous disposez d'éléments concrets à présenter aux auditeurs et aux clients qui vous interrogent sur la gouvernance des contrôles réseau sur différentes plateformes.
Comment maintenir le contrôle des politiques de pare-feu et de routage à mesure que votre entreprise se développe ?
Sans discipline, les règles s'accumuleront au point que personne ne pourra plus les modifier sans risque. Pour garder le contrôle :
- Exiger que chaque règle ait une propriétaire, un justification commerciale et date de révision ou d'expiration.
- Utilisez le objets, groupes et modèles pour les modèles récurrents (par exemple, un ensemble standard de ports vers un service de sauvegarde partagé) au lieu de créer des entrées ponctuelles par locataire.
- Horaires révisions régulières qui mettent en évidence les schémas à risque tels que de larges plages source/destination, des règles « tout-tout » ou des entrées longtemps inutilisées, et lient ces examens à des actions dans votre système de gestion de la sécurité de l'information (SGSI).
- Rendez-le facile à voir Quelles règles sont liées à quels risques et services ? afin que les utilisateurs puissent les modifier en toute confiance lorsque les besoins de l'entreprise évoluent.
En centralisant les normes, les enregistrements de modifications et les rapports d'audit sur une plateforme ISMS unique telle que ISMS.online, vous pouvez retracer l'ensemble du processus, de l'évaluation des risques à la configuration et inversement. Cette traçabilité rassure souvent les auditeurs quant à la mise en œuvre effective de vos contrôles A.8.20, au-delà des bonnes intentions.
De quelles preuves un MSP a-t-il besoin pour satisfaire les auditeurs et les clients concernant le point A.8.20 ?
Pour A.8.20, les preuves solides concernent montrer votre intention et votre pratique de manière concise mais convaincante. La plupart des auditeurs et des équipes de sécurité d'entreprise souhaitent comprendre rapidement votre modèle, puis examiner des exemples précis.
Quels artefacts donnent l'image la plus claire de la segmentation de votre réseau ?
Les dossiers de preuves qui sont bien accueillis par les auditeurs et les clients comprennent généralement :
- A politique de sécurité du réseau qui définit les attentes en matière de segmentation, de gestion des pare-feu et d'accès administrateur à l'ensemble du système.
- A norme de segmentation et de pare-feu qui décrit vos plans, vos zones et les types de contrôles à chaque limite.
- Un petit nombre de diagrammes principaux – par exemple, une vue d’architecture de haut niveau et un agencement représentatif des locataires, avec les limites de confiance et les flux de trafic indiqués.
- An inventaire des composants clés du réseau, notamment les pare-feu de périphérie, les commutateurs centraux, les passerelles VPN, les contrôles de sécurité du cloud et les infrastructures d'accès à distance.
- Historique des modifications récentes : pour les mises à jour des règles matérielles ou les modifications de topologie, en indiquant les approbations et les liens vers les décisions relatives aux risques ou les engagements des clients.
- Un ou plus examen des dossiers où vous avez analysé des journaux ou des ensembles de règles, identifié des problèmes, pris des mesures et consigné le résultat.
Si vous utilisez ISMS.online, chaque élément peut être directement lié à l'annexe A.8.20 et aux contrôles associés. Ainsi, lorsqu'une explication est demandée, vous pouvez exporter ou partager un dossier préétabli plutôt que de partir de zéro. Cela permet de gagner du temps et de réduire le risque de réponses incohérentes entre les différents questionnaires et audits.
Comment rendre les preuves A.8.20 réutilisables au lieu de les reconstruire chaque année ?
La manière la plus simple de rendre les preuves réutilisables est de les traiter comme un bibliothèque avec contrôle de version:
- Conservez les documents essentiels (politiques, normes, schémas de référence) comme éléments contrôlés de votre SMSI, avec des responsables clairement identifiés et des dates de révision.
- Associez les artefacts techniques (extraits de configuration, captures d'écran de pare-feu, historiques de tickets) aux contrôles qu'ils prennent en charge, afin de pouvoir les intégrer dans différents packs sans duplication.
- Définir un petit nombre de ensembles de preuves standard – par exemple, « pack réseau ISO 27001 », « pack de diligence raisonnable d’entreprise » – et les affiner après chaque audit ou évaluation majeur.
Travailler de cette manière signifie que chaque audit de surveillance ou questionnaire client d'envergure devient une occasion d'améliorer la bibliothèque, et non un exercice de réinvention. ISMS.online est conçu selon ce principe, vous permettant d'associer des éléments mis à jour au même contrôle et de maintenir votre référentiel A.8.20 à jour sans perdre le contexte précédent.
Quelles sont les faiblesses récurrentes de la version A.8.20 auxquelles les fournisseurs de services gérés sont confrontés, et comment peuvent-ils réduire les risques sans provoquer d'interruptions de service ?
La plupart des fournisseurs de services gérés (MSP) constatent que la norme A.8.20 révèle des faiblesses similaires : des réseaux internes développés de manière organique, des chemins d’administration partagés entre plusieurs locataires, des règles permissives ajoutées « à des fins de test », des environnements de laboratoire peu contrôlés et une surveillance incohérente des équipements critiques. Ces problèmes ont tendance à s’accumuler discrètement jusqu’à ce qu’un audit de sécurité ou un incident les mette en évidence.
Comment réduire le risque A.8.20 de manière à ce que les équipes opérationnelles puissent l'accepter ?
Un plan d'amélioration pragmatique tient compte du fait que vous exploitez un service en production :
- Commencez par la visibilité : Assurez-vous de disposer de schémas à jour, d'inventaires précis des appareils et de sauvegardes de configuration fonctionnelles avant de toucher à quoi que ce soit.
- Classez les faiblesses par ordre d'impact et de visibilité : privilégier les points d'accès internet, les plateformes partagées et les locataires à forte valeur ajoutée.
- Stabiliser l'accès administrateur : Déplacer les interfaces de gestion derrière des points d'accès contrôlés, renforcer l'authentification et réduire le nombre de chemins d'accès pour les ingénieurs.
- Resserrer progressivement les règles permissives : Ajouter la journalisation, observer l'utilisation réelle, convenir de règles plus précises avec les responsables du service et, seulement ensuite, supprimer les entrées générales.
- Gérer les laboratoires et les systèmes existants : soit les soumettre aux mêmes normes, soit les isoler en tant que zones non fiables dotées d'une connectivité limitée et bien documentée.
Chaque modification doit être consignée comme un traitement des risques et une modification formelle de votre SMSI, avec les normes et schémas mis à jour en annexe. La gestion de ces informations dans ISMS.online vous permet de présenter l'ensemble du processus – problème, décision, modification et justificatifs – lorsqu'on vous interroge sur les mesures prises pour renforcer l'annexe A.8.20 au cours de l'année écoulée.
Comment transformer les améliorations apportées à la version A.8.20 en un message positif pour les clients ?
Plutôt que d'attendre que les clients découvrent les faiblesses lors de leur audit préalable, vous pouvez intégrer votre démarche A.8.20 à une démarche d'amélioration continue. Expliquer, dans un langage clair et accessible, que vous avez identifié certains risques, mis en place de nouveaux contrôles et validé les résultats témoigne de votre maturité et de votre transparence. Le partage de documents pertinents – tels que des schémas mis à jour, de nouvelles procédures d'accès administrateur ou des synthèses des revues de règles – via un portail sécurisé rassure les acheteurs : vous n'êtes pas seulement conforme aujourd'hui, mais vous investissez activement dans une meilleure segmentation et une gouvernance réseau renforcée.
Comment un fournisseur de services gérés peut-il planifier et exécuter une migration sécurisée d'un réseau plat vers une architecture alignée sur la norme A.8.20 ?
La réussite d'une migration d'un réseau plat ou faiblement segmenté vers une architecture conforme à la norme A.8.20 repose davantage sur… séquence et gouvernance Il ne s'agit pas de se concentrer sur du matériel flambant neuf. Les programmes les plus pérennes privilégient les petites étapes bien définies et aux résultats clairs, plutôt que les refontes ambitieuses qui tentent de tout changer d'un coup.
Quelle approche progressive convient le mieux à la plupart des fournisseurs de services gérés ?
Une séquence logique ressemble souvent à ceci :
- Documenter et stabiliser le présent : Confirmer les sauvegardes de configuration, s'assurer que la surveillance est en place sur les périphériques clés et valider les plans de restauration.
- Créer ou renforcer le plan de gestion : Mettre en place des réseaux dédiés ou des VRF pour le trafic de gestion et réduire les points d'entrée d'administration à un petit ensemble contrôlé.
- Locataires prioritaires et services partagés : Choisissez un sous-ensemble gérable de clients critiques et de plateformes partagées, appliquez le modèle à trois plans et affinez les configurations de pare-feu et les enclaves de services autour d'eux.
- Étendre le modèle à l'ensemble du domaine : Déployez progressivement la conception éprouvée auprès d'un plus grand nombre de locataires et au sein des systèmes internes, en consolidant les règles et en désactivant la connectivité obsolète au fur et à mesure.
- Intégrez tout dans votre SMSI : mettre à jour les normes, les diagrammes, les entrées de risques et les preuves à mesure que chaque vague arrive afin que l'annexe A.8.20 reflète le réseau réel et non pas seulement une présentation PowerPoint.
En menant le programme de cette manière, vos équipes peuvent tirer des enseignements de chaque étape, mettre à jour les procédures et réduire le délai entre la conception et la mise en service. Cela vous offre également davantage d'occasions de vérifier le bon fonctionnement des nouveaux contrôles avant leur déploiement à plus grande échelle.
Comment une plateforme ISMS permet-elle de maintenir le cap sur une mise à niveau pluriannuelle A.8.20 ?
Au fil des années, les personnes et les plateformes évoluent ; votre système de gestion de la sécurité de l’information (SGSI) garantit la cohérence des intentions et des preuves. Grâce à une plateforme comme ISMS.online, vous pouvez :
- Maintenir un norme d'architecture cible et les plans associés en tant que documents contrôlés.
- Liez chaque changement, projet ou vague de migration directement à Annexe A.8.20 et contrôles connexes, avec des références aux risques traités.
- Attacher preuve – tels que les instantanés de configuration, les enregistrements de tests, les résultats d'examens et les leçons tirées des incidents – aux contrôles et risques pertinents.
- « Générer » rapports cohérents et dossiers de preuves pour les auditeurs, les clients et la gouvernance interne, en utilisant les mêmes données sous-jacentes.
En traitant le point A.8.20 de cette manière, vous ne vous contentez pas de satisfaire à une exigence de contrôle ; vous mettez en place une méthode visible et reproductible de gestion de la sécurité réseau au sein de votre système de gestion de la sécurité de l’information. Cela témoigne auprès de vos clients et partenaires de l’engagement de votre fournisseur de services gérés (MSP) envers la gestion à long terme de leurs environnements et de sa capacité à assurer une amélioration continue.
