La série de webinaires Secure Networking Ecosystem Insights de Cisco est désormais disponible à la demande. Son thème central — construire une architecture réseau sécurisée et fondée sur un écosystème couvrant l’infrastructure, l’identité et les accès — concerne directement les équipes responsables de parcs hétérogènes.
L’enseignement pratique dépasse toutefois un produit ou un constructeur particulier. La sécurité du réseau dépend de la capacité de l’organisation à découvrir ses actifs, contrôler les accès administratifs, suivre les changements de configuration, traiter les vulnérabilités et conserver des preuves fiables.
Considérer la sécurité comme une architecture
L’infrastructure, l’identité et les accès sont trois domaines opérationnels étroitement liés :
L’infrastructure comprend les équipements réseau et les dispositifs de sécurité qui transportent, acheminent et inspectent les flux.
L’identité détermine qui, ou quel système, demande un accès.
Les accès traduisent l’identité et les politiques en actions autorisées.
Une faiblesse dans l’un de ces domaines peut compromettre les contrôles établis dans les autres. Un pare-feu correctement configuré ne compense pas des identifiants administrateurs mal maîtrisés ou une modification de configuration non documentée. À l’inverse, des contrôles d’identité robustes ne permettent pas de savoir si chaque équipement réseau est connu, encore maintenu et conforme aux politiques internes.
Dans un environnement multiconstructeur, la première question d’architecture devrait donc être la suivante : pouvons-nous conserver une visibilité et une gouvernance cohérentes sans supposer que tous les équipements appartiennent au même écosystème fournisseur ?
S’appuyer sur un référentiel d’actifs fiable
La sécurité opérationnelle commence par une connaissance précise de l’environnement. Les équipes doivent savoir quels actifs sont présents, comment ils sont reliés et quels éléments nécessitent une attention particulière.
Une démarche efficace de gestion des actifs doit notamment permettre de :
Découvrir et inventorier les infrastructures de plusieurs constructeurs.
Associer l’historique des configurations à chaque actif concerné.
Suivre les vulnérabilités connues actif par actif.
Identifier les équipements qui approchent ou ont atteint leur fin de vie.
Conserver le contexte topologique et les dépendances utiles aux décisions opérationnelles.
Ce référentiel doit rester dynamique. Un inventaire statique peut rapidement ne plus refléter le réseau réel à mesure que les équipements, les configurations et leurs relations évoluent.
Relier l’identité administrative à des accès maîtrisés
L’administration réseau est une activité privilégiée. Une revue d’architecture ne doit pas seulement vérifier l’authentification des utilisateurs, mais aussi la manière dont les identifiants et les sessions d’administration sont gérés.
Plusieurs questions permettent d’évaluer la situation :
Les identifiants des équipements sont-ils conservés dans un coffre contrôlé plutôt que dispersés dans des scripts ou des fichiers personnels ?
Les accès administratifs SSH passent-ils par un point de rebond clairement défini ?
L’organisation peut-elle déterminer quel actif a été consulté et gérer les identifiants utilisés pour cet accès ?
Les automatisations utilisent-elles des identifiants gouvernés plutôt que des secrets intégrés dans le code ?
Ces contrôles réduisent la fragmentation des accès privilégiés. Ils contribuent également à établir une trace opérationnelle plus claire lors de l’analyse d’un changement ou de la préparation de preuves d’audit.
Intégrer l’historique des configurations au modèle de sécurité
Une architecture sécurisée doit tenir compte des changements. La configuration actuelle ne suffit pas à expliquer comment un équipement est arrivé à cet état, ni à déterminer si une modification non autorisée ou infructueuse a eu lieu.
La gestion des versions de configuration répond à plusieurs besoins concrets :
Détecter et examiner les modifications.
Comparer la configuration actuelle avec des versions antérieures.
Conserver des preuves historiques.
Revenir à un état antérieur après une modification indésirable.
Vérifier que les exigences de politique restent respectées après une opération de maintenance.
Cette capacité est particulièrement importante dans les réseaux hétérogènes, où les pratiques de sauvegarde et de gestion des changements peuvent varier selon les plateformes et les familles d’équipements.
Produire les preuves de conformité au fil des opérations
Les preuves de conformité sont plus solides lorsqu’elles résultent des processus courants de gestion du réseau, plutôt que d’être reconstituées juste avant un audit. L’inventaire des actifs, les versions de configuration, les contrôles de conformité, l’état des vulnérabilités et les informations de fin de vie peuvent tous alimenter une piste de preuve.
Les équipes doivent définir :
Les contrôles pouvant être vérifiés dans les configurations des équipements.
La manière dont les écarts sont enregistrés et attribués pour remédiation.
La durée et les modalités de conservation des preuves.
La documentation des exceptions et des risques acceptés.
L’application d’un même processus à plusieurs constructeurs.
Les référentiels et les réglementations varient, mais la collecte reproductible des preuves reste une exigence opérationnelle commune.
Comment ConnectMyAssets peut aider
ConnectMyAssets est une plateforme sur site et indépendante des constructeurs, conçue pour gérer les infrastructures réseau hétérogènes. Plusieurs de ses modules répondent directement aux pratiques d’architecture et de preuve décrites ici :
La CMDB dynamique maintient un référentiel actualisé des actifs et de leur contexte.
Le module Backup & History assure la gestion des versions de configuration et le retour en arrière en un clic.
Le Compliance Engine contrôle les configurations réseau au regard d’exigences associées à NIS2, ISO 27001, PCI, CISA et NIST.
Le suivi des CVE par actif relie les vulnérabilités connues aux infrastructures concernées.
Le Credential Vault et le SSH Bastion encadrent la gestion des identifiants administratifs et des accès.
Le suivi de fin de vie aide à repérer les risques liés au cycle de vie du parc installé.
Le module Topology conserve les relations utiles lors de l’analyse des changements et des incidents.
Les fonctions Automation & ZTP facilitent l’application de processus opérationnels reproductibles.
Parce que ConnectMyAssets fonctionne sur site et avec plusieurs constructeurs, les équipes peuvent appliquer des pratiques communes de gestion et de production de preuves sans imposer que l’ensemble du réseau appartienne à un seul écosystème propriétaire.
Les questions à garder en tête pendant les webinaires
La série à la demande de Cisco peut servir de point de départ pour revoir votre propre architecture. Pendant le visionnage, posez-vous notamment les questions suivantes :
À quels endroits les décisions concernant l’infrastructure, l’identité et les accès sont-elles aujourd’hui dissociées ?
Quels actifs échappent encore à l’inventaire central et à l’historisation des configurations ?
Les accès administratifs peuvent-ils être reliés à des identifiants et des processus contrôlés ?
Les preuves de conformité sont-elles produites en continu ou assemblées manuellement ?
Les vulnérabilités et les risques de fin de vie sont-ils visibles au niveau de chaque actif ?
Les politiques communes peuvent-elles être appliquées à l’ensemble des constructeurs déjà déployés ?
L’objectif n’est pas simplement d’ajouter un outil de sécurité. Il consiste à mettre en place un modèle opérationnel dans lequel la connaissance de l’infrastructure, les accès privilégiés, la gouvernance des configurations et les preuves de conformité se renforcent mutuellement.
Source : Cisco
