Principes de sécurité, identité et cryptographie utile au réseau

Avant de configurer un pare-feu ou de déployer un tunnel chiffré, il faut savoir ce que l’on protège, contre quoi, et au nom de qui. Ce chapitre pose le vocabulaire commun : les propriétés de sécurité, les dangers rangés par couche, la chaîne qui va de l’identification à l’habilitation, et les briques cryptographiques que les protocoles réseau assemblent. Le tout sans perdre de vue une vérité peu populaire : la plupart des incidents ne cassent aucun algorithme, ils passent par quelqu’un qui avait le droit d’entrer.

→ Lire l’explication complète de la marmotte

Les propriétés de sécurité

Le besoin de sécurité s’exprime en propriétés, pas en produits. Les trois premières forment le triptyque CIA (Confidentiality, Integrity, Availability), en français DIC (disponibilité, intégrité, confidentialité).

La confidentialité garantit que seules les personnes autorisées lisent une information. Exemple réseau : un mot de passe envoyé par Telnet ou par FTP (File Transfer Protocol) circule en clair, et toute capture sur le segment le révèle. Le chiffrement du transport répond à ce risque.

L’intégrité garantit qu’une donnée n’a pas été modifiée, accidentellement ou volontairement. Exemple : un intermédiaire qui réécrit une réponse HTTP (HyperText Transfer Protocol) non chiffrée pour y injecter un script. La réponse est un code d’authentification de message ou une signature.

La disponibilité garantit que le service répond quand on en a besoin. Un déni de service, un DNS (Domain Name System) en panne ou un rançongiciel qui chiffre les serveurs n’ont rien volé, et pourtant l’activité s’arrête. L’oublier dans la liste des objectifs de sécurité est une erreur fréquente : c’est celle que les attaquants exploitent le plus volontiers quand ils veulent être payés.

Deux propriétés s’y ajoutent. L’authenticité garantit l’origine d’un message : le serveur qui répond est bien celui qu’il prétend être, le paquet de routage vient bien du voisin attendu. La non-répudiation empêche l’auteur d’une action de la nier ensuite. Elle suppose une preuve que seul l’auteur pouvait produire, typiquement une signature avec une clé privée qu’il est seul à détenir. Un secret partagé, comme un mot de passe commun à une équipe ou une clé symétrique, ne donne jamais de non-répudiation : chacun des détenteurs aurait pu produire la preuve.

Ces propriétés se recouvrent entre réseau et système. Un tunnel chiffré protège la confidentialité pendant le transport, mais pas sur le serveur, où les données arrivent en clair. Une authentification réseau forte n’empêche pas un compte applicatif trop puissant. La sécurité réseau protège les chemins, la sécurité système protège les extrémités, et l’attaquant choisit le maillon le moins surveillé.

Atelier : associer menace et propriété

Menace	Propriété atteinte	Contre-mesure typique
Écoute d’un mot de passe Telnet	confidentialité	SSH (Secure Shell), chiffrement du transport
Réécriture d’une page HTTP en transit	intégrité	HTTPS (HTTP Secure) avec validation du certificat
Saturation d’un lien par déni de service	disponibilité	filtrage en amont, capacité, protection opérateur
Faux point d’accès Wi-Fi au bon nom	authenticité	authentification mutuelle, 802.1X
Ordre de virement contesté	non-répudiation	signature avec clé personnelle, journal horodaté
Rançongiciel sur les partages	disponibilité, intégrité	segmentation, sauvegardes hors ligne

Les dangers, couche par couche

Ranger les menaces par couche aide à ne rien oublier. En couche physique, on écoute un câble, on brouille une fréquence radio, on branche un équipement sur une prise libre. En couche liaison, l’usurpation ARP (Address Resolution Protocol) détourne le trafic d’un segment, un faux serveur DHCP (Dynamic Host Configuration Protocol) impose une passerelle. En couche réseau, on usurpe une adresse source, on injecte de fausses routes. En couche transport, l’inondation de demandes de connexion TCP (Transmission Control Protocol) épuise les ressources d’un serveur. En couche application, l’injection, la faille d’authentification ou le service mal configuré dominent les statistiques. Le détail figure dans Menaces réseau et détection.

Le risque logiciel traverse toutes les couches : tout code qui écoute sur le réseau peut contenir une vulnérabilité exploitable à distance. S’y ajoutent les familles de menaces qui ne demandent aucune faille technique. L’ingénierie sociale obtient d’une personne ce qu’aucune attaque ne pourrait arracher à une machine : un mot de passe, une validation de second facteur, l’ouverture d’une pièce jointe (Ingénierie sociale et accès initial). Le malware (logiciel malveillant) est le terme générique ; le rootkit est un programme qui se dissimule au cœur du système, parfois dans le noyau ou le micrologiciel, pour survivre aux contrôles ; le ransomware (rançongiciel) chiffre les données et exige une rançon, et vole désormais souvent les données avant de les chiffrer, pour faire payer deux fois.

L’investigation d’une URL (Uniform Resource Locator) ou d’une pièce jointe suspecte suit une méthode simple : ne jamais l’ouvrir sur un poste de production, l’analyser dans un environnement isolé, puis enrichir les indicateurs observés (nom de domaine, adresse IP (Internet Protocol), empreinte du fichier) en les confrontant à des sources de réputation et à ses propres journaux. La question utile devient vite : qui d’autre l’a reçu, et qui l’a ouvert ?

Identité et authentification

Quatre étapes se succèdent, et les confondre est la source d’une grande partie des failles d’accès. L’identification consiste à annoncer qui l’on est : saisir un identifiant, présenter un certificat. L’authentification consiste à le prouver. L’autorisation décide, pour une identité authentifiée, si une action précise est permise. L’habilitation est l’attribution préalable et administrative de ces droits, idéalement décidée par un responsable métier, revue périodiquement et retirée au départ de la personne. Un employé parfaitement authentifié qui lit le dossier de paie sans y être habilité illustre un défaut d’autorisation, pas d’authentification.

Les preuves se rangent en trois facteurs : ce que l’on sait (mot de passe, code), ce que l’on possède (carte à puce, clé de sécurité, téléphone), ce que l’on est (biométrie). Le mot de passe est universel et faible : réutilisé, deviné, hameçonné. Le support physique est plus robuste, surtout s’il est lié au site légitime : une clé de sécurité FIDO2 (Fast IDentity Online 2) refuse de signer pour un faux domaine, ce qui neutralise l’hameçonnage classique. La carte à puce stocke une clé privée qui ne quitte jamais la puce. La biométrie est commode mais ne se révoque pas : on change un mot de passe compromis, pas une empreinte digitale ; elle sert donc surtout à déverrouiller localement un secret stocké sur l’appareil.

La MFA (Multi-Factor Authentication, authentification multifacteur) combine au moins deux facteurs de natures différentes. Deux mots de passe ne font pas une MFA. Toutes les MFA ne se valent pas : un code reçu par SMS ou une notification à valider se fait intercepter ou extorquer par un attaquant patient qui envoie des demandes jusqu’à lassitude de la victime, alors qu’une clé FIDO2 résiste à l’hameçonnage.

Il faut aussi distinguer identité utilisateur et identité machine. Un poste, un serveur, un service ou un conteneur possède sa propre identité, souvent un certificat ou un compte de service. Le réseau peut authentifier la machine (le poste est-il un poste de l’entreprise ?) indépendamment de l’utilisateur (qui est assis devant ?). Les deux réponses sont nécessaires, et un compte de service dont le mot de passe n’a pas changé depuis dix ans est une identité comme une autre, en plus pratique pour l’attaquant.

Quatre protocoles d’authentification reviennent partout. NTLM (NT LAN Manager) est le mécanisme historique de Windows, par défi-réponse, vulnérable au relais (Attaque par relais NTLM). Kerberos est le protocole d’authentification par tickets des domaines Active Directory, qui repose sur un tiers de confiance et sur des horloges synchronisées. SAML 2.0 (Security Assertion Markup Language) et OIDC (OpenID Connect) sont des protocoles de fédération web : un fournisseur d’identité authentifie l’utilisateur et émet une assertion signée (SAML, en XML, eXtensible Markup Language) ou un jeton d’identité (OIDC, en JSON, JavaScript Object Notation, au-dessus d’OAuth 2.0) que l’application accepte. Les deux premiers vivent sur le réseau interne, les deux derniers dans le navigateur. Leur place parmi les services est décrite dans Services applicatifs, partage et protocoles hérités, et la discipline d’ensemble dans Authentification.

Cryptographie utile aux réseaux

Le chiffrement symétrique utilise une même clé pour chiffrer et déchiffrer. AES (Advanced Encryption Standard), normalisé en 2001, et ChaCha20 sont les algorithmes de référence. Il est rapide, souvent accéléré par le processeur. Son problème est la distribution de la clé : comment deux parties qui ne se sont jamais rencontrées partagent-elles un secret ?

La cryptographie asymétrique répond à cette question avec une paire de clés : une publique, diffusable, et une privée, gardée secrète. Elle sert à deux usages distincts. L’échange de clés (Diffie-Hellman sur courbe elliptique, par exemple X25519) permet à deux parties de calculer un secret commun en ne s’échangeant que des valeurs publiques. La signature (RSA, du nom de ses inventeurs Rivest, Shamir et Adleman ; ECDSA, Elliptic Curve Digital Signature Algorithm ; Ed25519) permet de prouver qu’un message vient du détenteur de la clé privée et n’a pas été modifié. Ces opérations sont de plusieurs ordres de grandeur plus lentes que le chiffrement symétrique ; tous les protocoles réseau sont donc hybrides : l’asymétrique authentifie et établit une clé de session, le symétrique chiffre le volume.

Chiffrement et signature ne font pas la même chose. Le chiffrement protège la confidentialité : seul le destinataire lit. La signature protège l’intégrité et l’authenticité : tout le monde peut lire et vérifier, seul l’auteur a pu signer. Un message signé n’est pas secret ; un message chiffré n’est pas forcément authentifié.

Reste à savoir à qui appartient une clé publique. Le certificat X.509 lie une clé publique à une identité (un nom de domaine, une personne, une machine), avec une période de validité, et le tout est signé par une autorité de certification. La PKI (Public Key Infrastructure, infrastructure de gestion de clés) organise ces autorités, leurs chaînes de confiance, l’émission et la révocation (PKI expliquée). Le certificat n’est pas la clé privée : le certificat est public, il est envoyé à chaque connexion ; la clé privée correspondante reste sur le serveur, et c’est elle qu’il faut protéger. Perdre un certificat ne coûte rien, perdre la clé privée oblige à révoquer.

Côté protocoles, TLS (Transport Layer Security) protège les connexions applicatives : TLS 1.3 (RFC 8446, 2018) est la version recommandée, TLS 1.2 reste acceptable correctement configuré, TLS 1.0 et 1.1 sont dépréciés par la RFC 8996 (2021). SSL (Secure Sockets Layer) est son ancêtre, historique : SSL 2.0 est interdit depuis 2011 et SSL 3.0 depuis 2015 (RFC 7568). Dire « certificat SSL » est un abus de langage toléré ; dire « on utilise SSL » pour une configuration moderne est une erreur, ou un aveu. Le mTLS (mutual TLS) ajoute l’authentification du client par certificat, utile entre services (mTLS). IPsec (Internet Protocol Security) protège les paquets IP eux-mêmes, en couche réseau, et sert surtout aux VPN (Virtual Private Network) site à site. Le fonctionnement de ces protocoles est détaillé dans TLS, VPN et IPsec.

Pour les choix d’algorithmes, les guides de l’ANSSI (Agence nationale de la sécurité des systèmes d’information) font référence en France. Les choix courants aujourd’hui : AES-GCM ou ChaCha20-Poly1305 pour le chiffrement, SHA-256 (Secure Hash Algorithm) ou plus pour le hachage, échange de clés éphémère sur courbe elliptique, RSA d’au moins 2048 bits et davantage pour les durées de vie longues. La transition post-quantique est engagée, avec l’algorithme ML-KEM normalisé par le NIST (National Institute of Standards and Technology) en 2024 et déjà proposé en mode hybride dans TLS. MD5, SHA-1, RC4, DES et 3DES n’ont plus leur place nulle part, sauf dans les musées et quelques équipements industriels.

Atelier : lire un certificat simple

openssl s_client -connect tortuetech.com:443 -servername tortuetech.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

La sortie donne quatre informations. Le sujet (subject) désigne le titulaire. L’émetteur (issuer) indique l’autorité qui a signé. Les dates (notBefore, notAfter) bornent la validité : une horloge locale fausse suffit à faire échouer la vérification. L’extension SAN (Subject Alternative Name) liste les noms pour lesquels le certificat est valable ; c’est elle, et non le champ CN (Common Name) du sujet, que les navigateurs vérifient. Aucune ligne ne montre la clé privée, et c’est heureux.

Protéger le poste et l’administration

La sécurité réseau s’arrête là où un poste compromis commence. Le chiffrement intégral du disque (BitLocker sous Windows, LUKS, Linux Unified Key Setup, sous Linux) protège les données d’un portable volé, à condition que la clé ne soit pas délivrée sans condition au démarrage. Le démarrage sécurisé (Secure Boot de l’UEFI, Unified Extensible Firmware Interface) vérifie la signature du chargeur et du noyau, et le TPM (Trusted Platform Module) scelle les clés à un état de démarrage mesuré. Le contrôle des ports USB (Universal Serial Bus) limite l’introduction de supports inconnus et l’exfiltration.

Atelier : checklist du poste d’administration

Un poste depuis lequel on administre le réseau mérite des règles plus strictes qu’un poste bureautique :

poste dédié, sans messagerie ni navigation Internet générale ;
comptes d’administration distincts des comptes quotidiens, avec MFA résistant à l’hameçonnage ;
disque chiffré, démarrage sécurisé, ports USB restreints ;
accès aux interfaces d’administration uniquement depuis ce poste ou un bastion, par SSH ou HTTPS, jamais par Telnet ;
correctifs appliqués rapidement, journaux centralisés, horloge synchronisée.

Le cloisonnement réseau qui rend cette checklist effective est traité dans Filtrage, segmentation et NAC et VPN, tunnels et bastions.

Pièges classiques

Appeler SSL tout chiffrement moderne entretient une confusion qui finit par masquer de vraies configurations obsolètes : quand tout s’appelle SSL, personne ne remarque le serveur qui accepte encore TLS 1.0.

Confondre authentification et autorisation conduit à accorder à toute identité prouvée l’ensemble de ce que le réseau laisse joindre. Le mot de passe correct devient un passe-partout.

Oublier la disponibilité comme propriété de sécurité laisse sans responsable le déni de service, la sauvegarde inexistante et le lien unique.

À ne pas confondre

Chiffrement et signature : le premier cache, le second prouve.

Identité utilisateur et identité machine : authentifier le poste ne dit rien de la personne qui l’utilise, et inversement.

Certificat et clé privée : le certificat se distribue à tout le monde, la clé privée à personne.

🐝 Ce qui arrive si on s’en passe

Sans distinction nette entre authentification et autorisation, une identité prouvée se voit accorder tout ce que le réseau laisse joindre : le mot de passe correct devient un passe-partout, et une seule identité volée ouvre l’ensemble des services. Sans second facteur, ce vol ne demande guère plus qu’un message bien tourné, l’ingénierie sociale se chargeant du reste. L’absence de non-répudiation a un coût plus discret : quand une action litigieuse survient, rien ne permet d’établir qui l’a réellement commise, et l’enquête s’arrête devant un compte partagé dont chacun jure ne jamais se servir.

🦫 Explication de la marmotte 🍫

La sécurité vise plusieurs propriétés. La confidentialité empêche les personnes non autorisées de lire une information. L’intégrité garantit qu’elle n’a pas été modifiée. La disponibilité assure que le service reste accessible. L’authenticité confirme l’origine d’un message, et la non-répudiation empêche son auteur de nier l’avoir envoyé. Pour accéder à un système, on passe par des étapes distinctes : l’identification, où l’on annonce qui l’on est ; l’authentification, où on le prouve avec un mot de passe, un objet comme une carte à puce ou une caractéristique du corps ; enfin l’autorisation, qui décide de ce que l’on a le droit de faire selon ses habilitations. Combiner plusieurs de ces preuves s’appelle l’authentification multifacteur. La cryptographie protège les échanges. Le chiffrement symétrique utilise une seule clé partagée et va vite ; le chiffrement asymétrique utilise une paire de clés, publique et privée, plus lente mais utile pour signer et pour échanger des clés. Un certificat relie une clé publique à une identité, et une infrastructure de clés publiques gère ces certificats. Des protocoles comme TLS, qui protège les connexions web, ou IPsec, qui protège les paquets entre réseaux, s’appuient sur ces briques ; l’ancien SSL est abandonné. Les menaces touchent toutes les couches : programmes malveillants, logiciels qui se cachent au cœur du système, rançongiciels qui chiffrent les données, et manipulation des personnes.

Pages voisines

La citent

Comprendre pourquoi les systèmes communiquent

Principes de sécurité, identité et cryptographie utile au réseau

Elle cite

: les deux pages se citent l’une l’autre.

Principes de sécurité, identité et cryptographie utile au réseau

Principes de sécurité, identité et cryptographie utile au réseau

Les propriétés de sécurité

Atelier : associer menace et propriété

Les dangers, couche par couche

Identité et authentification

Cryptographie utile aux réseaux

Atelier : lire un certificat simple

Protéger le poste et l’administration

Atelier : checklist du poste d’administration

Pièges classiques

À ne pas confondre

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines