KDDI Corporation a annoncé une offre SASE Gateway en partenariat avec Palo Alto Networks. KDDI est présenté comme un partenaire NextWave de longue date et comme un fournisseur de services de sécurité managés (MSSP) entretenant une relation établie avec l’éditeur de sécurité.
Au-delà de l’annonce, cette approche soulève une question importante pour l’infrastructure : que se passe-t-il lorsqu’une interconnexion opérateur fait partie du chemin entre les réseaux privés et les contrôles de sécurité Zero Trust ?
Le résumé de la source ne fournit pas de précisions sur la topologie, les protocoles, les versions ou les politiques. Les équipes réseau doivent donc évaluer la mise en œuvre à partir de leurs propres exigences d’architecture et d’exploitation, sans présumer de capacités techniques particulières.
Pourquoi l’interconnexion est déterminante
Un réseau fermé ou privé ne devient pas Zero Trust simplement parce qu’il évite l’Internet public. L’interconnexion détermine où le trafic rejoint le service de sécurité, où les politiques peuvent être appliquées et quelle organisation est responsable de chaque partie du chemin.
Une architecture opérateur peut simplifier la connectivité en créant un point de démarcation défini entre le réseau de l’entreprise, l’environnement du fournisseur de services et la couche de sécurité SASE. Elle peut ainsi limiter le nombre de chemins conçus individuellement, tout en faisant de cette démarcation une frontière opérationnelle critique.
Les équipes réseau doivent documenter :
Les sites, centres de données et segments qui utilisent l’interconnexion.
Les points d’échange des routes et les préfixes autorisés.
Le début et la fin de l’inspection de sécurité.
Les contrôles qui restent assurés par les pare-feu, routeurs ou autres équipements de l’entreprise.
L’effet de la redondance et du basculement sur le chemin d’inspection.
Les responsabilités relatives aux changements de configuration et à l’escalade des incidents.
Préserver la segmentation de bout en bout
La segmentation ne se résume pas aux règles de pare-feu. Elle dépend également du routage, de l’adressage, de l’association des politiques et de la manière dont le trafic passe d’un domaine administratif à un autre.
Une architecture SASE Gateway doit donc être évaluée de bout en bout. Si deux zones de l’entreprise doivent rester isolées, cette séparation doit encore pouvoir être appliquée une fois le trafic entré dans l’interconnexion opérateur. La propagation des routes, les espaces d’adressage qui se chevauchent, les routes par défaut et le comportement en cas de basculement peuvent modifier le résultat.
Une revue pratique peut commencer par trois questions :
Quel est le segment source ? Consignez le site, le sous-réseau, le groupe d’actifs et la fonction métier.
Quels chemins peut-il emprunter ? Incluez le fonctionnement nominal, les chemins de secours et ceux utilisés en cas d’incident.
Où les accès sont-ils autorisés ou refusés ? Identifiez le point d’application et le responsable de la politique.
Cette méthode aide à distinguer l’intention architecturale de la configuration qui la met réellement en œuvre.
Le Zero Trust ne se limite pas à un chemin privé
Une connexion privée fournie par un opérateur peut offrir un chemin de transport maîtrisé, mais le transport et la confiance sont deux sujets distincts. Les équipes réseau ont toujours besoin de politiques explicites définissant quels actifs et quels segments peuvent communiquer.
Sur le plan opérationnel, le SASE Gateway doit donc être considéré comme un point d’application au sein d’un ensemble de contrôles plus large, et non comme la preuve que tous les réseaux raccordés sont intrinsèquement fiables ou conformes.
Les équipes doivent conserver des preuves portant sur :
L’architecture de connectivité et de segmentation approuvée.
Les configurations actuelles de routage et de pare-feu autour de l’interconnexion.
L’historique des changements ayant affecté les chemins autorisés.
Les revues périodiques des règles, objets et frontières réseau.
Les exceptions, leurs responsables et leurs dates d’expiration ou de révision.
Les vulnérabilités connues et le statut de fin de vie des équipements associés.
Les preuves opérationnelles font partie de l’architecture
Les interconnexions opérateur créent une frontière de responsabilité partagée. Lors d’un audit ou d’un incident, un schéma ne suffit pas pour démontrer que l’environnement correspond toujours à l’architecture approuvée.
Les preuves utiles comprennent les sauvegardes de configuration, l’historique des changements, la propriété des actifs, les affectations d’adresses IP, les revues de règles de pare-feu, les relevés de topologie et le suivi des mesures correctives. Leur synchronisation est particulièrement importante dans un environnement multifournisseur, où routeurs, pare-feu, commutateurs et services de sécurité peuvent suivre des processus d’exploitation différents.
Un chemin simplifié ne facilite réellement l’exploitation que si les équipes peuvent identifier ses actifs, reconstituer ses changements et vérifier ses contrôles.
La place de ConnectMyAssets
ConnectMyAssets ne remplace pas le service SASE. La plateforme sert à gérer et à documenter, sur site, l’infrastructure réseau multifournisseur qui entoure ce service.
Les modules pertinents comprennent :
CMDB dynamique et Topologie : Inventorier les routeurs, pare-feu, commutateurs, interfaces et relations réseau autour du point de démarcation opérateur.
Backup & History : Conserver les versions des configurations, comparer les changements et permettre une restauration en un clic sur l’infrastructure administrée compatible.
Firewall Management : Maintenir une visibilité sur les politiques et objets de pare-feu qui complètent les contrôles de la passerelle.
IPAM : Documenter les sous-réseaux et les affectations d’adresses concernés par la segmentation et les échanges de routes.
Compliance Engine : Rassembler les preuves opérationnelles et évaluer les contrôles d’infrastructure au regard de référentiels tels que NIS2, ISO 27001, PCI, CISA et NIST.
Suivi des CVE par actif et suivi des fins de vie : Identifier les risques de vulnérabilité et de cycle de vie des équipements qui prennent en charge l’interconnexion.
Automation & ZTP : Appliquer des processus de configuration reproductibles afin de limiter la dérive entre les sites raccordés.
Credential Vault et SSH Bastion : Encadrer les accès administratifs à l’infrastructure placée sous la responsabilité de l’équipe réseau.
Grâce à son approche multifournisseur et à son déploiement sur site, ConnectMyAssets peut constituer un référentiel cohérent de l’infrastructure sans transformer l’interface propre au service de l’opérateur en système de référence pour l’équipe réseau.
Questions à poser avant le déploiement
Avant d’adopter ou d’étendre une architecture SASE interconnectée par un opérateur, vérifiez les points suivants :
Chaque segment participant est-il représenté dans la CMDB ?
L’équipe peut-elle reconstituer la configuration avant et après un changement ?
Les chemins nominaux et de secours sont-ils tous documentés ?
Les responsabilités sont-elles claires aux frontières entre l’entreprise, l’opérateur et le service de sécurité ?
Les auditeurs peuvent-ils consulter des preuves montrant que les politiques de segmentation sont revues et maintenues ?
Les équipements associés font-ils l’objet d’un suivi des CVE et des échéances de fin de vie ?
L’annonce de KDDI illustre la place que peut prendre une interconnexion opérateur dans une stratégie Zero Trust destinée aux réseaux fermés. La valeur opérationnelle durable dépend toutefois de la qualité de l’inventaire, de la maîtrise des configurations, de la résilience de la segmentation et de la disponibilité de preuves vérifiables autour de cette interconnexion.
Source : Palo Alto Networks
