Examen blanc 2 : architecture et infrastructure de sécurité

Bienvenue dans la partie 2 de l’examen blanc, consacrée au domaine 3 de Security+ : l’architecture de sécurité (18 % de l’examen). Ce domaine évalue votre capacité à appliquer des contrôles de sécurité aux conceptions d’infrastructures réseau et cloud, à comprendre les stratégies de segmentation et d’isolation, à évaluer la sécurité des protocoles et à recommander des architectures adaptées à des scénarios donnés. Les questions d’architecture présentent souvent un schéma réseau ou une description de système et vous demandent d’identifier le contrôle manquant, la configuration vulnérable ou le meilleur choix de conception. Lisez attentivement chaque scénario et identifiez l’élément architectural évalué avant de sélectionner votre réponse.

Question : Une entreprise héberge un serveur web public et un serveur de base de données interne. L’équipe de sécurité veut s’assurer que, si le serveur web est compromis, les attaquants ne puissent pas accéder directement à la base de données interne. Quelle conception réseau permet d’atteindre cet objectif ?

Réponse : placez le serveur web dans une DMZ (zone démilitarisée), séparée du réseau interne par un deuxième pare-feu. Une DMZ utilise deux pare-feu : le pare-feu externe sépare Internet de la DMZ et le pare-feu interne sépare la DMZ du réseau interne. Même si le serveur web est entièrement compromis, le pare-feu interne bloque l’accès direct à la base de données interne : l’attaquant doit franchir un deuxième pare-feu. Placer les deux serveurs dans le même segment réseau supprime cette protection. Un seul pare-feu avec des ports différents pour le trafic web et celui de la base de données est insuffisant : un serveur web compromis peut atteindre les ports de la base de données depuis le même segment.

Question : Une équipe de sécurité veut détecter les attaques réseau et bloquer automatiquement le trafic malveillant avant qu’il n’atteigne les serveurs internes. Quel type d’équipement répond le mieux à ces deux exigences ?

Réponse : système de prévention des intrusions (IPS). Un IPS est placé en ligne sur le chemin du trafic ; il peut détecter les attaques (comme un IDS) et aussi bloquer activement le trafic malveillant. Un IDS (système de détection des intrusions) est généralement déployé hors bande (le trafic lui est transmis en miroir) : il détecte les attaques et génère des alertes, mais ne peut pas bloquer le trafic puisqu’il ne se trouve pas sur son chemin. Les deux utilisent une détection fondée sur les signatures et les anomalies. Le risque d’un IPS est le blocage de trafic légitime à cause de faux positifs ; c’est pourquoi un IPS doit être réglé avec soin. NIDS (réseau) et HIDS (basé sur l’hôte) : le premier détecte le trafic selon son emplacement réseau ; le second analyse les événements système sur un hôte donné.

Question : Une organisation compte des télétravailleurs qui accèdent aux ressources de l’entreprise depuis des réseaux domestiques. Le VPN traditionnel permet à tout appareil connecté d’accéder entièrement au réseau interne. Quelle alternative d’architecture sans confiance implicite réduit le mieux le risque de déplacement latéral si un appareil distant est compromis ?

Réponse : remplacez le VPN par un accès réseau sans confiance implicite (ZTNA) qui accorde un accès par application en fonction de l’état de l’appareil, de l’identité de l’utilisateur et du contexte. Un VPN traditionnel accorde un accès étendu au réseau (une fois connecté, l’appareil peut atteindre la plupart des ressources internes). Le ZTNA applique le principe d’absence de confiance implicite : chaque demande d’accès à une ressource est évaluée individuellement selon l’identité de l’utilisateur, la conformité de l’appareil (correctifs, certificat) et le contexte de risque. Un appareil compromis n’a accès qu’aux applications précises auxquelles sa session a donné accès, et non à l’ensemble du réseau. Cela limite le déplacement latéral au périmètre d’impact de ces applications plutôt qu’à tout le réseau de l’entreprise.

Question : Une entreprise stocke des données clients dans des compartiments AWS S3. Qui doit s’assurer que le compartiment S3 n’autorise pas l’accès public ?

Réponse : le client (l’entreprise). Selon le modèle de responsabilité partagée d’AWS, AWS sécurise l’infrastructure physique, l’hyperviseur et le matériel de stockage. Le client est responsable de la classification et de la protection des données, des politiques et ACL des compartiments S3, du contrôle des accès et de la conformité. Des compartiments S3 mal configurés (lecture publique ou écriture publique) ont causé certaines des plus importantes fuites de données de l’histoire ; leur configuration correcte relevait dans tous les cas de la responsabilité du client. AWS fournit des outils (S3 Block Public Access, règles AWS Config, Amazon Macie) pour aider les clients à respecter leurs responsabilités, mais leur utilisation relève du choix du client.

Question : Un administrateur réseau segmente le réseau de l’entreprise en VLAN : un pour les postes de travail des employés, un pour les serveurs, un pour les caméras IP et un pour le Wi-Fi invité. Quel avantage de sécurité cela apporte-t-il ?

Réponse : cela limite le déplacement latéral : la compromission d’un VLAN ne donne pas automatiquement accès aux autres VLAN. Les VLAN assurent une séparation logique du réseau, même sur des commutateurs physiques partagés. Le trafic entre les VLAN doit passer par un routeur ou un commutateur de couche 3, où des ACL peuvent être appliquées pour restreindre les communications. Si les caméras IoT (cibles fréquentes en raison de leur sécurité faible) se trouvent sur un VLAN distinct, une caméra compromise ne peut pas attaquer directement les postes de travail ou les serveurs. L’isolation du VLAN Wi-Fi invité empêche les utilisateurs invités d’accéder aux ressources de l’entreprise. Remarque : les VLAN ne constituent pas une frontière de sécurité complète ; les attaques par saut de VLAN existent. Ils doivent donc être associés à une segmentation physique pour les zones à haute sécurité.

Question : Un ingénieur réseau doit administrer à distance des routeurs et des commutateurs depuis un poste d’administration. Quel protocole doit-il utiliser pour s’assurer que tout le trafic d’administration est chiffré ?

Réponse : SSH (Secure Shell) sur le port 22. SSH chiffre tout le trafic, y compris les identifiants et les commandes. L’alternative non sécurisée, Telnet (port 23), transmet toutes les données en clair : un observateur du réseau peut intercepter les identifiants de connexion. Pour les interfaces d’administration web, HTTPS (port 443) doit remplacer HTTP. Pour la surveillance SNMP, SNMPv3, avec authentification et confidentialité (chiffrement AES), remplace SNMPv1/v2c en clair. L’examen Security+ présente souvent des tableaux comparant des paires de protocoles sécurisés et non sécurisés : choisissez toujours SSH plutôt que Telnet, SFTP plutôt que FTP, LDAPS plutôt que LDAP, HTTPS plutôt que HTTP et SNMPv3 plutôt que SNMPv1/v2.

Question : Une organisation souhaite déployer un pare-feu capable d’inspecter le trafic HTTPS chiffré à la recherche de logiciels malveillants, d’appliquer des contrôles au niveau des applications (bloquer les réseaux sociaux tout en autorisant les applications professionnelles) et de s’intégrer à un flux de renseignement sur les menaces. Quel type de pare-feu doit-elle déployer ?

Réponse : pare-feu de nouvelle génération (NGFW). Un NGFW fonctionne aux couches 3 à 7 et comprend : l’inspection approfondie des paquets (DPI) du trafic applicatif, l’inspection SSL/TLS (déchiffrement, inspection puis rechiffrement), la reconnaissance des applications (identification et contrôle d’applications précises quel que soit le port), un IPS intégré et l’intégration du renseignement sur les menaces. Les pare-feu à états traditionnels fonctionnent aux couches 3 et 4 (IP et TCP/UDP) : ils peuvent autoriser ou bloquer selon l’IP, le port et le protocole, mais ne peuvent pas distinguer un trafic HTTPS légitime d’un logiciel malveillant transmis par HTTPS. Les pare-feu filtrant les paquets sont encore plus limités : ils sont sans état et n’assurent aucun suivi des connexions.

Q8 — Haute disponibilité et tolérance aux pannes : Un hôpital exige une absence totale d’interruption si un serveur tombe en panne. Réponse : cluster tolérant aux pannes actif-actif — plusieurs serveurs traitent simultanément les demandes ; la défaillance de l’un d’eux n’interrompt pas le service. La haute disponibilité comporte une brève période de basculement ; une configuration actif-passif implique une interruption pendant l’attente. Aucune interruption = actif-actif.

Q9 — Microsegmentation : 50 microservices ; il faut empêcher le déplacement latéral si l’un d’eux est compromis. Réponse : NetworkPolicy Kubernetes ou maillage de services avec mTLS — des règles précises sont appliquées au niveau des charges de travail. Les VLAN sont trop généraux ; mTLS ajoute le chiffrement et l’authentification mutuelle entre les services.

Q10 — WPA3 : Passage de WPA2-Personal à WPA3-Personal. Réponse : SAE (Simultaneous Authentication of Equals) empêche les attaques par dictionnaire hors ligne (l’attaquant doit interagir avec le réseau pour chaque tentative) et assure la confidentialité persistante (des clés de session uniques, même si la PSK est compromise ultérieurement).

Réseau de pots de miel : réseau de pots de miel destiné à attirer et à étudier les attaquants tout en recueillant des renseignements sur les menaces. Isolation physique : isolement physique complet de tous les réseaux externes — pas d’Internet, de réseau sans fil ni de support amovible (en théorie). Proxy et proxy inverse : le proxy direct contrôle le trafic sortant des clients vers Internet ; le proxy inverse se trouve devant les serveurs, contrôle le trafic entrant et masque la topologie des serveurs. NAC (Network Access Control) : vérifie la présence de AV, l’installation des correctifs et la conformité aux politiques avant d’accorder l’accès au réseau. CASB : courtier de sécurité d’accès au cloud — point d’application des politiques entre les utilisateurs du cloud et les fournisseurs de services cloud. Risque du tunneling fractionné : seul le trafic de l’entreprise passe par le tunnel VPN ; le trafic Internet le contourne, ce qui crée simultanément un risque de pont entre le réseau de l’entreprise et Internet.

SASE : Secure Access Service Edge — associe ZTNA, CASB, SWG et FWaaS à SD-WAN en tant que service cloud unifié pour sécuriser l’accès à distance. Avantage de sécurité du SDN : sépare les plans de contrôle et de données, ce qui permet d’appliquer de manière centralisée et programmable les politiques de sécurité. Risque principal lié à la sécurité des conteneurs : le noyau partagé — une sortie de conteneur ou une vulnérabilité du noyau compromet l’hôte et tous les autres conteneurs. Serveur de rebond ou hôte bastion : voie d’accès unique et renforcée aux segments sensibles — toutes les sessions d’administration doivent y transiter et sont journalisées. Risque lié aux certificats TLS génériques : une seule clé privée compromise affecte tous les sous-domaines *.domain.com. Authentification 802.1X basée sur les ports : exige l’authentification de l’appareil avant d’autoriser le moindre trafic depuis un port de commutateur — cela empêche les appareils non autorisés d’accéder au réseau.

Vérifiez votre compréhension des concepts de CompTIA Security+ (SY0-701) abordés dans cette leçon.

Dans cette partie de l’examen blanc, vous avez révisé : l’architecture DMZ et la manière dont les conceptions à deux pare-feu empêchent les compromissions de serveurs web d’atteindre les réseaux internes, les distinctions entre les types de pare-feu (filtrage de paquets, pare-feu à états et NGFW avec inspection SSL), ainsi que les architectures cloud et Zero Trust — la limite de responsabilité partagée dans le cloud, le remplacement du VPN par ZTNA et la microsegmentation pour contrôler le trafic est-ouest. Ces concepts d’architecture représentent les 18 % du contenu du domaine 3. La suite est la partie 3 de l’examen blanc, consacrée aux opérations, à la réponse aux incidents et à l’informatique légale.