Les fondamentaux de la sécurité de l'information pour les développeurs

L'essentiel de la sécurité logicielle relève du bon sens appliqué, mais le domaine possède un vocabulaire précis, et l'employer approximativement conduit à des contrôles qui ratent leur cible. « Rendez-le sécurisé » n'est pas une exigence ; « la piste d'audit doit rendre toute altération détectable et être conservée sept ans » en est une. Ce guide couvre les notions qu'un développeur rencontre dans les exigences de sécurité, les registres de risques, les rapports de tests d'intrusion et les revues d'incident — de quoi lire ces documents correctement et défendre le bon contrôle.

Il est volontairement fondamental. Quand un sujet dispose de son propre guide, celui-ci en donne les grandes lignes et renvoie plus loin : les faiblesses propres au web sont traitées dans le Top 10 de l'OWASP, la démarche de conception dans l'architecture de sécurité applicative, et tout ce qui concerne les comptes et les permissions dans la gestion des identités et des accès.

Les propriétés qu'il faut savoir nommer

La triade CIA (confidentialité, intégrité, disponibilité) désigne les trois propriétés de sécurité classiques.

Confidentialité — l'information n'est accessible qu'aux personnes autorisées à la consulter. On la perd avec un bucket de stockage exposé, un journal contenant des numéros de carte, une API qui renvoie l'enregistrement d'un autre client.

Intégrité — l'information et les systèmes ne peuvent pas être modifiés sans que cela se voie. On la perd avec un mécanisme de mise à jour non signé, un montant total que le client peut recalculer, un journal d'audit qu'un administrateur peut éditer.

Disponibilité — le service est utilisable quand on en a besoin. On la perd avec une attaque par épuisement des ressources, mais bien plus souvent à cause d'un certificat expiré ou d'un déploiement raté, ce qui explique que la disponibilité soit autant une propriété d'ingénierie qu'une propriété de sécurité.

Deux autres propriétés méritent d'être nommées à part. L'authenticité, c'est la certitude qu'un message ou un acteur est bien celui qu'il prétend être — ce que fournissent l'authentification et les signatures numériques. La non-répudiation, c'est la capacité de démontrer après coup qu'une partie donnée a effectué une action, de sorte qu'elle ne puisse pas le nier de façon crédible ; elle exige à la fois une authentification forte et un enregistrement immuable, et c'est pourquoi les systèmes financiers et juridiques tiennent à la signature et pas seulement à l'autorisation.

Formulez vos exigences dans ces termes. « Les enregistrements d'approbation doivent rendre toute altération détectable » est une exigence d'intégrité testable ; « le système doit être sécurisé » ne l'est pas.

Le risque en termes de sécurité

L'analyse de risque emploie cinq mots de manière cohérente, et les confondre produit des registres inexploitables.

• Un actif est quelque chose qui a de la valeur : un jeu de données, un service, une réputation, une clé.
• Une menace est une cause potentielle de dommage — un acteur animé d'un mobile, ou un événement comme une inondation.
• Une vulnérabilité est une faiblesse qu'une menace peut exploiter : une bibliothèque non corrigée, une vérification manquante, un utilisateur non formé.
• La vraisemblance mesure la probabilité de cette combinaison, éclairée par l'exposition et par les capacités de l'attaquant.
• L'impact est ce qu'il en coûte si cela se produit — sur le plan financier, réglementaire, opérationnel ou de la réputation.

Le risque combine la vraisemblance et l'impact d'une menace donnée exploitant une vulnérabilité donnée contre un actif donné. Une vulnérabilité sans menace plausible représente un risque faible ; une vulnérabilité modeste sur un système exposé à Internet qui détient des données réglementées, non.

Il existe quatre réponses, et tout l'intérêt de l'exercice est de choisir en connaissance de cause : atténuer en ajoutant un contrôle, transférer par une assurance ou un contrat, éviter en renonçant à l'activité risquée, ou accepter avec un responsable nommé et une date de réexamen. Accepter un risque délibérément est légitime ; découvrir, lors d'une revue post-incident, un risque accepté que personne ne se souvient d'avoir accepté ne l'est pas.

La cryptographie dont un développeur a vraiment besoin

Dans le code applicatif, la cryptographie échoue surtout par erreur de catégorie — on emploie une primitive qui n'apporte pas la propriété requise. Quatre catégories, quatre garanties.

L'encodage convertit des données d'une représentation à une autre. Base64, l'encodage d'URL et l'hexadécimal n'ont ni clé ni secret ; ils existent pour que du binaire survive à un canal textuel. Un encodeur et décodeur base64 inverse tout cela instantanément, et c'est précisément le but.

Le hachage fait correspondre à une entrée une empreinte de taille fixe, de façon déterministe et irréversible. Il garantit l'intégrité et l'identité d'un contenu, pas sa confidentialité. Utilisez SHA-256 ou SHA-3 pour les sommes de contrôle et les empreintes ; MD5 et SHA-1 sont cassés pour tout usage lié à la sécurité, car on sait construire des collisions. Vérifier un artefact téléchargé par rapport à une empreinte publiée est un usage légitime d'un générateur de hash ; stocker des mots de passe ne l'est pas — il faut pour cela une fonction lente et gourmande en mémoire.

Le chiffrement symétrique utilise une seule clé partagée pour chiffrer et déchiffrer. AES dans un mode authentifié comme GCM est le choix standard ; il est rapide, adapté aux gros volumes, et tout le problème se ramène à la façon dont les deux parties ont obtenu la clé. Ne réutilisez jamais un nonce avec la même clé, et n'utilisez jamais le mode ECB brut, qui laisse fuir la structure des données.

Le chiffrement asymétrique repose sur une paire de clés : la clé publique chiffre et seule la clé privée déchiffre. RSA et les algorithmes à courbes elliptiques sont lents comparés aux chiffrements symétriques ; les systèmes réels s'en servent donc pour établir ou envelopper une clé symétrique, puis basculent sur celle-ci — le schéma hybride qu'utilise TLS.

Les signatures numériques inversent l'usage de la paire asymétrique : la clé privée signe une empreinte, et quiconque possède la clé publique peut la vérifier. On obtient ainsi à la fois intégrité, authenticité et non-répudiation ; c'est le mécanisme qui sous-tend les certificats, les jetons signés et les artefacts de release signés. Un code d'authentification de message comme HMAC apporte lui aussi intégrité et authenticité, mais avec un secret partagé : il ne peut donc pas prouver laquelle des parties l'a produit.

Une règle sous-tend l'ensemble : utilisez une bibliothèque éprouvée et une construction standard. Les protocoles faits maison et les « on fait un XOR avec un secret » échouent d'une manière évidente pour les spécialistes et invisible pour leurs auteurs.

TLS et la chaîne de certificats

TLS apporte à une connexion la confidentialité, l'intégrité et l'authenticité du serveur, et c'est le contrôle que le reste de la pile tient discrètement pour acquis. TLS 1.3 (RFC 8446) a ramené le handshake à un seul aller-retour et supprimé les anciens algorithmes et options à l'origine de la plupart des défaillances passées.

Client                                          Server
  |-- ClientHello -------------------------------->|   supported groups, key share, cipher suites
  |<------------------------------- ServerHello ---|   chosen suite, key share
  |<------------- {EncryptedExtensions, Certificate,|
  |                CertificateVerify, Finished} ----|   everything after ServerHello is encrypted
  |-- {Finished} --------------------------------->|
  |<========== application data (AEAD) ===========>|

Chaque partie fournit une part de clé Diffie-Hellman éphémère, et toutes deux en dérivent le même secret de session sans qu'il transite jamais sur le réseau. La clé étant éphémère, enregistrer le trafic aujourd'hui puis voler la clé privée du serveur demain ne permet pas de le déchiffrer — c'est la propriété appelée confidentialité persistante (forward secrecy), désormais obligatoire. Le serveur prouve qu'il détient la clé privée de son certificat en signant la transcription du handshake dans CertificateVerify, ce qui empêche un attaquant de rejouer un certificat qu'il n'aurait fait que copier.

La confiance vient de l'infrastructure à clé publique (PKI). Une autorité de certification vérifie le contrôle d'un domaine et émet un certificat qui lie ce nom à une clé publique ; ce certificat est signé par une autorité intermédiaire, dont le propre certificat est signé par une racine à laquelle votre système d'exploitation ou votre navigateur fait déjà confiance. La validation remonte cette chaîne, vérifie la signature à chaque étape, contrôle les dates de validité, la correspondance du nom et la révocation. Ce qu'elle prouve est étroit, et mérite d'être dit clairement : vous dialoguez avec le détenteur de la clé privée correspondant à ce nom, et personne entre vous ne peut lire ni modifier le trafic. Elle ne se porte pas garante de l'exploitant.

Conséquences pratiques pour un développeur : servez TLS 1.3 ou 1.2 avec des suites modernes, et rien de plus ancien ; activez HSTS pour que les navigateurs refusent toute rétrogradation ; automatisez le renouvellement, car l'expiration est la première cause d'incidents TLS ; utilisez TLS à l'intérieur du réseau aussi, puisque la position sur le réseau ne constitue pas une frontière de confiance ; et ne désactivez jamais la validation des certificats pour faire passer un test — cette habitude finit immanquablement par atteindre la production. Quand les deux parties doivent s'authentifier, le TLS mutuel (mTLS) demande au client de présenter lui aussi un certificat : c'est le choix habituel pour les appels de service à service.

Gouvernance, normes et politiques

Les organisations pilotent la sécurité à l'aide de référentiels, et les exigences qui parviennent à une équipe de développement en découlent presque toujours.

ISO/IEC 27001 spécifie un système de management de la sécurité de l'information : définir le périmètre, évaluer les risques, choisir les contrôles, les documenter, mesurer et améliorer, puis être audité sur cette base. La certification est un atout commercial parce que les clients la réclament, et ses contrôles deviennent les attentes au niveau de l'équipe — gestion des changements, revue des accès, journalisation, évaluation des fournisseurs, développement sécurisé.

Le NIST Cybersecurity Framework 2.0 organise l'activité en six fonctions : Govern, Identify, Protect, Detect, Respond et Recover. C'est un vocabulaire structurant plutôt qu'une certification, et il est particulièrement utile pour repérer les déséquilibres — beaucoup d'équipes investissent massivement dans Protect et presque rien dans Detect et Recover.

D'autres référentiels apparaissent dans des contextes particuliers : PCI DSS pour les données de carte, SOC 2 pour les prestataires de services, et les réglementations sectorielles de la finance et de la santé.

Une politique de sécurité est l'énoncé écrit de ce que l'organisation exige ; en dessous, des standards et des procédures en précisent les détails. Les politiques que les développeurs peuvent suivre sont courtes, précises et vérifiables ; celles rédigées pour satisfaire un auditeur ne sont en général ni lues ni appliquées, ce qui est pire que de ne pas en avoir, car cela crée une non-conformité documentée.

La réponse aux incidents

Les incidents arrivent aussi aux organisations compétentes. Ce qui sépare une mauvaise semaine d'une catastrophe, c'est la préparation, et les phases décrites dans NIST SP 800-61 valent la peine d'être connues avant d'en avoir besoin.

Préparation. Des contacts, des rôles, un circuit d'escalade, un accès aux journaux, des sauvegardes testées et un plan répété. Tout ce qui coûte cher à organiser sous pression s'organise maintenant.

Détection et analyse. Reconnaître qu'il se passe quelque chose, à partir d'une alerte, d'un signalement client ou d'une notification d'un tiers, et en établir l'étendue : ce qui a été atteint, quand cela a commencé, si c'est toujours en cours. Tout dépend ici de la journalisation et de la supervision mises en place auparavant.

Confinement, éradication et rétablissement. Stopper la propagation — isoler un hôte, révoquer des identifiants, désactiver un endpoint — tout en préservant les preuves, car une machine effacée ne peut plus être analysée. Ensuite, supprimer la cause, restaurer à partir d'un état sain connu et surveiller de près toute récidive.

Activités post-incident. Une revue sans recherche de coupable : ce qui s'est passé, la chronologie, ce qui a fonctionné, et les changements qui éviteront que cela se reproduise, avec des responsables et des échéances. Un incident qui ne débouche sur aucun changement durable est un incident gâché.

Deux choses que les développeurs doivent savoir à l'avance : qui appeler à trois heures du matin, et que la rotation des identifiants, la révocation des jetons et la réauthentification forcée doivent être des opérations réalisables rapidement. Entraînez-vous ; un runbook que personne n'a jamais exécuté n'est qu'une hypothèse.

Protéger les données personnelles

Les réglementations sur la protection des données comme le RGPD imposent des principes qui se traduisent directement en décisions de conception, quelle que soit votre juridiction.

• Base légale et limitation des finalités — collecter pour une finalité déclarée et ne pas réutiliser discrètement les données à une autre fin.
• Minimisation des données — ne collecter que ce que la finalité exige. La façon la moins coûteuse de protéger un champ, c'est de ne pas le stocker.
• Limitation de la conservation — définir une durée de conservation par catégorie de données et supprimer selon ce calendrier, ce qui suppose que la suppression soit réellement implémentée, et pas seulement envisagée.
• Intégrité et confidentialité — des mesures techniques appropriées : chiffrement, contrôle d'accès, journalisation.
• Responsabilité — être en mesure de démontrer la conformité, au moyen du registre des traitements et de la trace des décisions de conception.

Deux techniques sont souvent citées et souvent confondues. La pseudonymisation remplace les identifiants par des jetons tout en conservant une table de correspondance séparée : les données restent des données personnelles, toujours soumises à la réglementation, même si une fuite est moins grave. L'anonymisation supprime toute possibilité de réidentification, ce qui place les données hors du champ de la réglementation — et elle est réellement difficile, car des combinaisons d'attributs ordinaires sont souvent uniques. Intégrez dès le départ les droits que confère la réglementation — accès, rectification, effacement, portabilité — car ajouter après coup une suppression qui atteigne chaque réplique, sauvegarde, cache et export analytique est l'une des tâches d'ingénierie les plus ardues d'un système mature.

Points clés à retenir

• Confidentialité, intégrité et disponibilité, complétées par l'authenticité et la non-répudiation, vous donnent les mots pour rédiger une exigence testable.
• Un risque se décrit par un actif, une menace, une vulnérabilité, une vraisemblance et un impact ; chaque risque se conclut par une décision consciente : atténuer, transférer, éviter ou accepter.
• L'encodage n'est pas du chiffrement, le hachage n'est pas réversible, le symétrique est rapide, l'asymétrique résout la distribution des clés, et les signatures prouvent l'origine.
• TLS 1.3 offre la confidentialité persistante en un seul aller-retour ; un certificat prouve le contrôle d'un nom et rien sur l'exploitant : automatisez le renouvellement et ne désactivez jamais la validation.
• ISO 27001 et le référentiel du NIST sont la source des exigences au niveau de l'équipe ; une politique ne fonctionne que si elle est courte, précise et appliquée.
• Préparez-vous aux incidents avant qu'ils surviennent et faites en sorte que la revue débouche sur des changements ; pour les données personnelles, minimisez, définissez la conservation et concevez l'effacement dès le départ.