CompTIA SY0-701: Sécurité des données, confidentialité et cryptographie — Guide d'étude

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Fait partie du CompTIA Security+ SY0-701 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens CompTIA, ou passez des tests chronométrés sur ExamRoll.io.

Les données sont la cible ultime de la plupart des attaques, et la cryptographie est le principal mécanisme technique pour les protéger en transit, au repos et en cours d’utilisation. Comprendre les propriétés, les limites et l’application correcte des primitives cryptographiques est fondamental, non seulement pour l’examen, mais aussi pour concevoir des systèmes qui restent sécurisés lorsque les contrôles individuels échouent.

Classification et Traitement des Données

La classification des données attribue des étiquettes de sensibilité qui déterminent les exigences de traitement. Les cadres gouvernementaux utilisent les niveaux Non classifié, Confidentiel, Secret et Très secret. Les cadres commerciaux utilisent généralement les niveaux Public, Interne, Confidentiel et Restreint (ou des équivalents). La classification doit être guidée par la sensibilité des données et les obligations réglementaires, et non par la commodité.

Les systèmes de Prévention de la Perte de Données (DLP) appliquent les politiques de traitement en inspectant le contenu au niveau des points de terminaison, des points de sortie du réseau et du stockage cloud. Une règle DLP peut bloquer les pièces jointes d’e-mails contenant des chaînes de 16 chiffres correspondant à des numéros de carte de crédit, ou alerter lorsqu’un utilisateur télécharge un fichier contenant l’expression « cible d’acquisition » vers un service de stockage cloud personnel. L’efficacité du DLP dépend d’une classification précise : si les données sensibles ne sont pas étiquetées, le DLP ne peut pas les protéger.

La souveraineté des données concerne l’endroit où les données résident physiquement et les lois de quelle juridiction s’appliquent. Le RGPD exige que les données personnelles de l’UE transférées en dehors de l’UE soient protégées par des décisions d’adéquation, des Clauses Contractuelles Types (Standard Contractual Clauses) ou des Règles d’Entreprise Contraignantes (Binding Corporate Rules). Les organisations opérant à l’échelle mondiale doivent cartographier les flux de données et s’assurer que les lieux de stockage et de traitement sont conformes aux réglementations applicables.

Chiffrement en Transit et au Repos

TLS 1.3 est la norme actuelle pour le chiffrement des données en transit. Il élimine les suites de chiffrement faibles, impose le secret de transmission (forward secrecy) via un échange de clés Diffie-Hellman éphémère, et réduit la poignée de main (handshake) à un seul aller-retour. TLS 1.0 et 1.1 sont obsolètes ; TLS 1.2 reste acceptable mais doit être configuré avec des suites de chiffrement robustes. Une configuration Nginx appliquant les normes actuelles :

# Enforcing TLS 1.2+ in an Nginx server block
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers on;

Le chiffrement au repos protège les données sur les supports de stockage. Le chiffrement de disque complet (BitLocker, FileVault, LUKS) chiffre l’intégralité du volume ; le chiffrement au niveau des fichiers (EFS, conteneurs VeraCrypt) chiffre les fichiers individuels. Le chiffrement au niveau de la base de données (Transparent Data Encryption dans SQL Server et Oracle) chiffre les fichiers de données et les sauvegardes. La nuance essentielle : le chiffrement au repos protège contre le vol de supports physiques mais ne protège pas contre une application compromise qui a déjà déchiffré les données pour les traiter.

Primitives Cryptographiques

Les algorithmes symétriques (AES-128, AES-256, ChaCha20) utilisent une seule clé partagée et sont rapides, adaptés aux données en vrac. Les algorithmes asymétriques (RSA, ECDSA, Ed25519, ECDH) utilisent des paires de clés et permettent l’échange de clés, les signatures numériques et la liaison d’identité, mais sont coûteux en termes de calcul. Les systèmes hybrides — comme TLS — utilisent la cryptographie asymétrique pour négocier une clé de session symétrique, puis chiffrent le trafic de masse de manière symétrique.

Le hachage (SHA-256, SHA-3) est une fonction à sens unique produisant une empreinte (digest) de longueur fixe. Le hachage n’est pas du chiffrement : il ne peut pas être inversé avec une clé car il n’y a pas de clé. Les hachages de mots de passe salés (utilisant bcrypt, scrypt, Argon2 ou PBKDF2) ajoutent une valeur aléatoire par utilisateur pour contrer les tables arc-en-ciel (rainbow tables). Les hachages assurent la vérification de l’intégrité ; HMAC combine un hachage avec une clé secrète pour fournir à la fois l’intégrité et l’authenticité.

Les modes de chiffrement sont aussi importants que l’algorithme. AES en mode ECB chiffre chaque bloc indépendamment, produisant un texte chiffré identique pour des blocs de texte en clair identiques — une propriété catastrophique qui révèle des motifs dans les données. AES-GCM (Galois/Counter Mode) fournit à la fois la confidentialité et l’intégrité en une seule passe et constitue la norme pour les protocoles modernes. Le mode CBC avec un remplissage (padding) approprié et un HMAC est acceptable mais plus complexe à mettre en œuvre correctement.

Gestion et Stockage des Clés

La robustesse de la cryptographie dépend de la gestion de ses clés. Les clés doivent être générées avec une forte entropie, stockées séparément des données qu’elles protègent, renouvelées selon un calendrier et détruites lorsqu’elles ne sont plus utilisées. Les Modules Matériels de Sécurité (HSM) offrent un stockage de clés inviolable et une accélération cryptographique. Un Module de Plateforme Sécurisée (TPM) est une puce sur les points de terminaison qui stocke les clés utilisées par BitLocker et le démarrage mesuré (measured boot). La mise sous séquestre de clés (key escrow) consiste à déposer une copie des clés auprès d’un tiers de confiance pour une récupération légale, tandis que les agents de récupération de clés (key recovery agents) permettent aux entreprises de déchiffrer les données des employés lorsque cela est nécessaire. Les services KMS cloud (AWS KMS, Azure Key Vault, Google Cloud KMS) proposent le chiffrement d’enveloppe (envelope encryption), où une clé de chiffrement de données (DEK) protège les données et est elle-même chiffrée par une clé de chiffrement de clé (KEK) conservée dans le HSM.

Infrastructure à Clé Publique (PKI)

Une PKI lie les identités aux clés publiques par le biais de certificats émis par une Autorité de Certification (CA). Une CA subordonnée est rattachée à une CA racine dont le certificat doit être pré-approuvé. Le cycle de vie d’un certificat commence par une Demande de Signature de Certificat (CSR) générée en même temps qu’une clé privée :

openssl req -new -newkey rsa:2048 -nodes \
  -keyout server.key -out server.csr \
  -subj "/CN=www.example.com/O=Example Corp/C=US"

La CA valide le demandeur, signe la CSR et émet un certificat X.509. La révocation est publiée via des Listes de Révocation de Certificats (CRL) — des listes de numéros de série révoqués téléchargées périodiquement — ou des répondeurs Online Certificate Status Protocol (OCSP) qui répondent en temps réel à des requêtes par certificat. L’agrafage OCSP (OCSP stapling) permet au serveur de présenter un statut récent et signé pendant la poignée de main TLS, évitant ainsi les consultations du client vers la CA. Les certificats expirent et doivent être renouvelés ; l’automatisation via ACME (Let’s Encrypt, serveurs ACME internes) prévient les interruptions de service dues à des certificats expirés.

Signature de code et validation de l’intégrité

La signature de code (Code signing) utilise la clé privée d’un développeur pour signer un artefact logiciel ; les destinataires vérifient la signature avec le certificat du développeur, confirmant ainsi à la fois l’intégrité et l’origine. Cela protège contre la falsification de la chaîne d’approvisionnement (supply-chain). Les outils de surveillance de l’intégrité des fichiers (Tripwire, AIDE) et la publication de hachages (valeurs sha256sum à côté des téléchargements) détectent de la même manière les modifications non autorisées, mais le hachage seul ne prouve que la correspondance du fichier avec une valeur — il n’authentifie pas qui a produit cette valeur. Seule une signature numérique, soutenue par une PKI, fournit à la fois l’intégrité et la non-répudiation.

Rétention, sanitisation et mise au rebut sécurisée

Les politiques de rétention définissent la durée pendant laquelle chaque classe de données doit être conservée et quand elle doit être supprimée. Les réglementations imposent souvent à la fois des durées minimales (dossiers financiers pendant sept ans) et maximales (données personnelles conservées pas plus longtemps que nécessaire). Les sauvegardes ne sont pas exemptées : si une personne concernée exerce un droit à l’effacement, l’organisation doit disposer d’un processus défendable pour supprimer ces données des sauvegardes ou pour documenter les contraintes techniques et les contrôles compensatoires. Les conservations à des fins légales (Legal holds) prévalent sur la rétention normale et gèlent les données pendant un litige.

Lorsque les supports atteignent leur fin de vie, la sanitisation doit correspondre à la sensibilité des données et à la destination du support. La norme NIST SP 800-88 définit trois niveaux : Clear (effacement logique, suffisant pour une réutilisation au sein de l’organisation), Purge (effacement cryptographique, effacement de bloc ou démagnétisation, suffisant pour une réutilisation à l’extérieur), et Destroy (broyage, désintégration, incinération, pulvérisation). L’effacement cryptographique — la destruction de la clé de chiffrement pour que le texte chiffré devienne irrécupérable — est rapide et efficace pour les disques à auto-chiffrement (self-encrypting drives) qui sont réaffectés. La démagnétisation (degaussing) rend les supports magnétiques inutilisables et ne fonctionne pas sur les SSD. La destruction physique est la seule méthode garantie pour les supports endommagés ou pour les plus hauts niveaux de classification.

Scénario pratique : une faille de gestion des clés menant à une violation

Une entreprise SaaS a chiffré sa base de données clients en utilisant AES-256, mais a stocké la clé de chiffrement dans un fichier de configuration en texte clair dans le même dépôt que le code de l’application. Lorsqu’un développeur a accidentellement publié (push) le dépôt sur un compte GitHub public, un bot automatisé de scan de secrets (credential-scanning) a découvert la clé en 11 minutes. L’attaquant a utilisé la clé pour déchiffrer une sauvegarde de base de données qui avait été stockée dans un bucket S3 publiquement accessible (une autre erreur de configuration). Le chiffrement était techniquement correct — AES-256 est incassable par force brute — mais la gestion des clés était catastrophiquement défaillante. Une gestion des clés appropriée aurait consisté à stocker la clé dans un gestionnaire de secrets (AWS Secrets Manager, HashiCorp Vault) avec un accès contrôlé par des rôles IAM, jamais dans le code source ou les fichiers de configuration.

← Sécurité du Cloud · Tous les domaines · Continuité des activités et reprise après sinistre →

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