Cisco 300-415: Sécurité, segmentation et chaînage de services — Guide d'étude

By Laurynas Brazys · 13 August 2026 · #cisco #300-415 #certification #exam-prep #study-guide

Fait partie du Cisco SD-WAN 300-415 ENSDWI — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Cisco, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

Cisco SD-WAN fournit un cadre complet de sécurité et de segmentation qui s’aligne sur les principes du Zero Trust tout en permettant l’insertion de services évolutive et un accès Internet sécurisé. Les politiques de sécurité et la segmentation sont définies de manière centralisée, distribuées via le plan de contrôle (OMP) et appliquées de manière cohérente sur les routeurs WAN Edge. Cette section explique comment concevoir et exploiter la segmentation basée sur les VPN, placer et chaîner les services de sécurité, protéger le plan de contrôle et l’accès administratif, et collecter une télémétrie de sécurité pertinente sans dégrader les performances des applications critiques.

Fondations de la segmentation et des politiques

Segmentation basée sur les VPN

• Chaque locataire (tenant) ou domaine de sécurité est isolé dans son propre VPN SD-WAN (VRF). La joignabilité du plan de contrôle vers les contrôleurs utilise le VPN 0, tandis que la gestion utilise le VPN 512 ; les VPN côté service (pour les utilisateurs, la voix, l’OT, le PCI, les invités) transportent le trafic du plan de données.
• Le chevauchement d’espaces d’adressage est entièrement pris en charge par des tables de routage par VPN. Des agences ou des locataires avec 10.0.0.0/8 peuvent coexister, car OMP transporte distinctement les routes spécifiques au VPN, les TLOC et les routes de service.
• La communication inter-VPN ne se produit que via une fuite de routes (route leaking) explicite ou une politique ; cela applique le principe du moindre privilège.

Conception avec chevauchement d’espaces d’adressage

• Préférez éviter le NAT à l’intérieur du WAN lorsque la segmentation est suffisante. Si deux VPN qui se chevauchent doivent interopérer, utilisez :
  • Une politique de contrôle centralisée pour faire fuiter des préfixes spécifiques entre les VPN avec des listes de préfixes (prefix-lists) et des route-maps précises.
  • Le NAT sur un site de rendez-vous si une traduction est nécessaire (par exemple, pour migrer une IP héritée vers un service consolidé).
• Modes de défaillance et compromis :
  • Une fuite de routes incorrecte ou trop large compromet la segmentation et peut créer des trous noirs ; testez toujours la politique de routage avec l’aperçu des routes OMP (vérification des routes OMP, TLOC et de service).
  • Le NAT à l’intérieur de l’overlay peut perturber les attentes des applications et compliquer le dépannage ; utilisez-le en dernier recours.

Hiérarchie et application des politiques

• Les contrôleurs vSmart distribuent les informations de routage et de politique à l’aide d’OMP et distribuent également les informations de clés cryptographiques aux WAN Edges pour former des tunnels IPsec sécurisés. Les politiques centralisées définissent le routage sensible aux applications, l’appartenance aux VPN et l’insertion de services à travers la fabrique.
• Les politiques locales (par exemple, une ACL par équipement pour un circuit spécifique) sont appliquées sur le WAN Edge. Utilisez une politique de données locale lorsqu’une classification spécifique à un équipement ou à un circuit est requise.
• Les politiques de données sont utilisées pour orienter, accepter ou rejeter le trafic de données entre les VPN et pour le rediriger des réseaux privés vers les réseaux des FAI si nécessaire.
• Alignement Zero Trust :
  • Refus par défaut entre les VPN ; autorisation explicite uniquement pour les flux requis.
  • Contrôles basés sur l’identité et l’application pour la segmentation est-ouest à l’aide des zones et des politiques décrites ci-dessous.

Contrôles de sécurité et placement de l’inspection

Pare-feu basé sur les zones (ZBFW)

• Construisez des zones de sécurité par VPN ; un VPN ne peut appartenir qu’à une seule zone pour éviter l’application de politiques ambiguës.
• Créez des paires de zones et des politiques pour autoriser, inspecter ou rejeter le trafic. Utilisez la correspondance L3/L4/L7 pour appliquer le moindre privilège sur les flux inter-zones.
• Placement de l’inspection :
  • Agence : Appliquez la segmentation et l’inspection avec état (stateful) près de l’utilisateur ; idéal pour le « local breakout » et la prévention des mouvements latéraux contenus dans le site.
  • Hub/Colocation : Utilisez pour le trafic qui transite entre les domaines ou qui nécessite des services avancés ; minimisez la latence en épingle à cheveux (hairpin) en régionalisant les hubs.
• Modes de défaillance et compromis :
  • L’inspection avec état (stateful) nécessite des flux symétriques ; un routage asymétrique ou des différences ECMP entre les chemins peuvent provoquer des interruptions de session. Utilisez une politique centralisée pour garantir la symétrie des chemins pour les flux inspectés.
  • Le débit et la latence sont affectés par l’inspection approfondie ; classez le trafic d’exception (par exemple, voix/vidéo) pour contourner l’inspection approfondie tout en continuant d’appliquer les ACL.

Prévention d’intrusion, filtrage d’URL et sécurité avancée

• Sur les WAN Edges IOS XE SD-WAN, les fonctionnalités de « Unified Threat Defense » fournissent l’IPS, le filtrage d’URL et la réputation des logiciels malveillants. Maintenez les signatures à jour et configurez le mode « fail-open » (ouvert en cas de panne) ou « fail-closed » (fermé en cas de panne) en fonction de la tolérance au risque de l’entreprise.
• Pour le trafic à forte charge TLS, envisagez le déchargement du déchiffrement sur un hub ou une passerelle web sécurisée. Si le déchiffrement n’est pas possible, fiez-vous au SNI, à JA3, à la réputation des IP et à l’analyse comportementale.
• Compromis :
  • Le filtrage IPS/URL introduit de la latence et une consommation CPU ; utilisez une politique sensible aux applications pour n’inspecter que les catégories à haut risque tout en autorisant les applications professionnelles de confiance sur des chemins rapides.
  • Assurez-vous d’avoir une politique de contournement claire pour les applications critiques si un moteur IPS n’est pas disponible afin d’éviter une panne (documentez si le mode « fail-open » est acceptable).

Orchestration de la politique d’inspection sécurisée

• vSmart distribue des politiques de sécurité centralisées qui redirigent le trafic d’agence à agence ou d’agence à centre de données à travers un service réseau (pare-feu, IPS). C’est l’insertion de service : faites correspondre les flux, définissez l’action pour les faire passer par un service nommé, et appliquez-la aux VPN/sites cibles.
• Validez la disponibilité des routes de service via les routes de service OMP et surveillez leur état ; définissez le comportement de repli (passer/rejeter) en cas de défaillance du service.

Chaînage de services, accès Internet direct et sortie avancée

Modèles de chaînage de services

• Des pare-feu/IDS/IPS physiques ou virtuels en ligne peuvent être chaînés au niveau du hub ou de la succursale. Au niveau du hub, configurez l’adresse du pare-feu de service sur le vEdge/WAN Edge qui fait face au service pour l’enregistrer en tant que nœud de service.
• Pour la mise à l’échelle et l’agilité, utilisez Cloud onRamp for Colocation pour diriger le trafic des succursales vers des hubs de services régionalisés qui hébergent des fonctions de réseau et de sécurité chaînées avec un accès à faible latence. Les routeurs de succursale analysent et dirigent localement le trafic éligible vers ces fonctions à proximité pour optimiser les coûts et l’expérience utilisateur.
• En option, insérez des fonctions supplémentaires telles que DLP ou CASB en série. Définissez des contrôles de santé (health-checks) et des SLA afin que le routage sensible aux applications ne sélectionne que les chemins et les chaînes qui répondent aux exigences de performance.

Considérations de conception

• Choisissez le chaînage de services central lorsqu’une posture de sécurité et une inspection de contenu cohérentes sont nécessaires, mais acceptez la latence supplémentaire/le trafic en épingle à cheveux (hairpin).
• Choisissez le chaînage de services en succursale lorsqu’une latence ultra-faible est nécessaire ou pour garantir l’application des politiques lors des baisses de performance du WAN (brownouts).
• Planifiez la redondance : annoncez plusieurs nœuds de service en tant que routes de service OMP et utilisez une politique pour préférer un service principal régional avec un basculement (failover) secondaire.

Sortie Internet sécurisée et DIA

• La sortie Internet locale réduit le trafic de retour (backhaul) et améliore les performances des applications SaaS. Utilisez une politique de données (data policy) pour diriger les flux à destination d’Internet vers le chemin DIA.
• Le NAT est configuré sur l’interface sortante dans le VPN 0 pour l’accès Internet direct ; assurez-vous que les ACL autorisent les flux sortants et entrants.
• Combinez le DIA avec ZBFW, la sécurité au niveau DNS et le filtrage d’URL. Envisagez d’utiliser Cloud onRamp for SaaS pour mesurer la qualité du chemin vers des applications SaaS spécifiques et sélectionner un chemin optimal par application.
• Modes de défaillance et compromis :
  • Un NAT mal placé ou des routes par défaut qui se chevauchent dans le VPN 0 peuvent perturber les connexions de contrôle (DTLS/TLS) vers les contrôleurs ; isolez les règles NAT du DIA du trafic des contrôleurs et validez les exigences PnP/ZTP (DHCP, DNS).
  • Le tunnelage fractionné (split tunneling) peut entrer en conflit avec les exigences de conformité ; appliquez une sortie par application avec audit et DLP lorsque cela est nécessaire.

Confiance du plan de contrôle, AAA/RBAC, protections QoS et télémétrie

Protection du plan de contrôle et confiance basée sur les certificats

• Les WAN Edges établissent des connexions de contrôle DTLS/TLS sécurisées dans le VPN 0 vers vBond, vSmart et vManage. Le contrôleur vSmart utilise OMP pour transporter les routes et les politiques du plan de contrôle ; les WAN Edges n’échangent jamais de contrôle directement entre eux.
• L’authentification mutuelle est basée sur des certificats. Utilisez une PKI Cisco ou une autorité de certification d’entreprise (Enterprise CA) ; assurez-vous que NTP est correct pour éviter les échecs de validation des certificats. Effectuez une rotation périodique des clés et révoquez rapidement les identités compromises.
• Renforcez la sécurité des contrôleurs : limitez les adresses IP de gestion, imposez des suites de chiffrement TLS, segmentez la gestion dans le VPN 512 et surveillez le nombre et le rythme des sessions du plan de contrôle. Limitez le débit et filtrez la gestion entrante et les accès SSH/HTTPS via des ACL.

AAA, RBAC et accès administratif

• Appliquez un AAA centralisé via TACACS+ ou RADIUS avec un contrôle d’accès basé sur les rôles (RBAC) pour vManage et les CLI des équipements. Séparez les rôles de lecture seule, d’opérateur et d’architecte ; appliquez l’authentification multifacteur (MFA) lorsque c’est possible.
• Utilisez des clés d’API pour l’automatisation avec des portées de moindre privilège ; auditez les appels d’API.
• Journalisez toutes les modifications administratives avec horodatage ; transférez-les vers un SIEM.

Implications de la QoS et protection des flux critiques

• Préservez et respectez le DSCP à travers IPsec avec copy-dscp ; classifiez et marquez le trafic à l’entrée, puis mappez-le à des files d’attente par tunnel. Réservez des files d’attente prioritaires pour les flux de voix en temps réel ou les flux transactionnels (par exemple, l’autorisation de paiement).
• Coordonnez la sécurité avec la QoS :
  • Placez les flux à faible latence et sensibles à la gigue sur des chemins rapides et des politiques d’inspection minimales.
  • Contrôlez (police) et limitez le débit du trafic inconnu ou en vrac pour éviter la privation de ressources (starvation) et réduire l’impact des attaques DDoS.
• Compromis : une inspection de sécurité agressive peut augmenter la latence et la gigue ; quantifiez l’impact et définissez des classes d’exception lorsque cela est justifié.

Journalisation, NetFlow, cflowd et télémétrie de sécurité

• Activez les journaux de ZBFW, IPS et du filtrage d’URL avec des seuils de gravité ; exportez-les via syslog sur des canaux sécurisés.
• Utilisez cflowd (télémétrie de flux SD-WAN) et/ou des exportateurs NetFlow/IPFIX pour fournir une visibilité au niveau des flux par application, site, VPN et chemin. Alimentez vAnalytics pour l’établissement de lignes de base et le SIEM pour la corrélation.
• Collectez les événements de changement de route OMP et de TLOC pour détecter les anomalies potentielles du plan de contrôle. Limitez le débit de la journalisation pour éviter les tempêtes de logs lors d’événements.
• Surveillez les performances des applications chiffrées avec des sondes SLA ; déclenchez des mesures correctives via une politique centralisée lorsqu’une dégradation est détectée.

Application du Zero Trust sur le WAN

• Traitez chaque site et chaque chemin comme non fiable. Appliquez la segmentation par VPN, vérifiez l’identité via des certificats et autorisez le trafic par classe à l’aide de ZBFW et de la politique de données.
• Validez en continu la posture des équipements et la santé des chemins ; réévaluez dynamiquement les politiques avec le routage sensible aux applications (configuré comme une politique centralisée).
• Refus par défaut (default-deny) entre les zones et les VPN ; fuite de routes minimale nécessaire et insertion de services explicite pour l’inspection.

Scénario de problème pratique

Le groupe Acme Retail doit segmenter le trafic PCI, d’entreprise et invité, fournir une sortie Internet locale (local internet breakout) sécurisée dans les succursales, et insérer une inspection avancée IDS/IPS et DLP dans les hubs de colocation régionaux sans dégrader la latence des autorisations de paiement.

Approche

1. Définir la segmentation basée sur les VPN et la ligne de base Zero Trust

   • Créer le VPN 10 (PCI), le VPN 20 (Entreprise), le VPN 30 (Invité). Ne pas faire fuiter de routes entre les VPN par défaut.
   • Justification : Les RIB par VPN prennent en charge les sous-réseaux qui se chevauchent entre les magasins ; le refus par défaut du Zero Trust restreint les mouvements latéraux.

2. Construire des zones ZBFW mappées aux VPN et des politiques inter-zones

   • Attribuer chaque VPN à une zone de sécurité distincte ; créer des paires de zones qui n’autorisent que les flux requis (par exemple, du point de vente (POS) aux passerelles de paiement, de l’entreprise aux serveurs de mise à jour).
   • Justification : Applique le moindre privilège aux couches L3 à L7 ; un VPN appartient à une seule zone pour éviter toute ambiguïté de politique.

3. Activer la sortie Internet locale (DIA) sécurisée avec une répartition sensible aux applications

   • Dans chaque succursale, configurer la DIA sur le VPN 0 avec NAT sur l’interface orientée Internet. Utiliser une politique de données centralisée pour diriger le trafic SaaS et invité vers la DIA, tout en gardant le trafic PCI sur le WAN privé ou une sortie inspectée.
   • Justification : Améliore les performances SaaS ; la politique centrale permet des décisions par application. Une attention particulière est portée à l’isolement des sessions DTLS/TLS du contrôleur dans le VPN 0 par rapport aux règles NAT de la DIA.

4. Insérer l’IDS/IPS et le DLP régionaux via le chaînage de services

   • Dans chaque hub de colocation, enregistrer le service de pare-feu/IDS sur le WAN Edge en configurant l’adresse du pare-feu de service. Construire une politique centralisée sur vSmart pour rediriger le trafic d’entreprise et PCI destiné à Internet vers la chaîne de services ; le trafic invité reste en DIA avec ZBFW local et filtrage d’URL.
   • Justification : vSmart applique l’insertion de services de manière cohérente ; OMP annonce les routes de service pour la résilience. La régionalisation limite la latence en épingle à cheveux (hairpin) et permet de mettre à l’échelle l’inspection avancée.

5. Protéger le plan de contrôle et renforcer la sécurité des contrôleurs

   • S’assurer que NTP est précis ; utiliser une PKI d’entreprise pour toutes les identités du plan de contrôle. Restreindre l’accès de gestion à vManage, vSmart et vBond dans le VPN 512. Surveiller la santé des sessions OMP et les changements de TLOC.
   • Justification : La confiance basée sur les certificats empêche l’intégration d’équipements non autorisés ; une gestion renforcée réduit la surface d’attaque et le risque de perturbation du plan de contrôle.

6. Appliquer l’AAA/RBAC et le contrôle des changements

   • Intégrer l’accès à vManage et aux équipements avec TACACS+ ; créer des rôles pour le NOC (lecture seule), SecOps (modification des politiques) et NetOps (modèles d’équipement). Exiger la MFA et journaliser tous les changements dans le SIEM.
   • Justification : Limite le rayon d’impact d’une erreur d’opérateur ou d’un compromis d’identifiants ; crée une piste d’audit.

7. Aligner la QoS avec la sécurité pour le trafic de paiement

   • Marquer le trafic POS comme EF et l’épingler à des files d’attente haute priorité avec une inspection minimale ; classifier les mises à jour logicielles en vrac comme BE et autoriser une inspection approfondie. Activer copy-dscp sur IPsec.
   • Justification : Préserve les SLA de paiement à faible latence tout en inspectant les flux moins critiques ; évite la gigue due à une inspection intensive.

8. Activer la télémétrie et la vérification continue

   • Exporter les événements ZBFW/IPS via syslog, activer cflowd/IPFIX vers un collecteur, et intégrer tous les journaux dans le SIEM. Utiliser vAnalytics pour établir une ligne de base des performances par application et déclencher des mesures correctives via une politique centralisée si le SLA se dégrade.
   • Justification : Corrèle les détections de sécurité avec le contexte des flux, soutient le dépannage proactif et maintient la validation continue du Zero Trust.

9. Valider et mettre en place des mécanismes de sécurité (fail-safe)

   • Tester les chemins symétriques pour les flux inspectés, vérifier les routes de service OMP, et simuler une défaillance de nœud de service pour confirmer que le comportement de contournement/rejet est conforme à la politique. Limiter le débit des journaux pour éviter les tempêtes de logs.
   • Justification : Prévient les pannes inattendues dues au routage asymétrique ou aux défaillances de service et maintient l’observabilité pendant les incidents.

← Politique centralisée et ingénierie du trafic · Tous les domaines · Qualité de service et services de multidiffusion →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →