Glossaire DevSecOps & durcissement

Une ACL (Access Control List) est une liste de règles qui définit précisément qui peut accéder à une ressource et quelles actions sont autorisées (lecture, écriture, exécution, suppression). En réseau : les ACLs filtrent le trafic : elles autorisent ou bloquent des paquets selon l'IP source, la destination ou le port. En stockage : elles définissent les permissions fichiers (qui peut lire/modifier ce fichier). Exemples : ACL réseau (pare-feu), ACL fichiers Linux, Network ACL AWS (filtrage au niveau subnet), ACL Kubernetes (contrôle d'accès aux ressources).

ANSSI BP-028 prescrit des recommandations de configuration concrètes, chacune référencée R<n> (ex. R33 pour le SSH root) et classée par niveau (minimal, intermédiaire, renforcé, élevé). Pavois porte le tag bp28: sur chaque contrôle concerné.

Mapping direct comme CIS/STIG, par opposition aux familles abstraites du NIST.

Une API key est un token d'authentification (chaîne unique) identifiant et autorisant un client à accéder à une API. Transmis via header HTTP (Authorization: Bearer <KEY>) ou query param.

Avantages : simple (pas de flux OAuth), stateless, traçabilité par client.

Limitations : sécurité faible (accès total si volée), pas d'expiration automatique, pas de scope granulaire.

Bonnes pratiques : ne jamais commit dans Git, rotation régulière, rate limiting, scoping (permissions limitées). Alternatives : OAuth 2.0, JWT, mTLS.

AppArmor attache à un exécutable un profil listant les fichiers, capacités et réseaux autorisés ; le reste est refusé par le noyau. Un profil est en mode enforce (bloque) ou complain (journalise seulement).

aa-status donne l'état réel : un profil en complain ou non chargé ne protège pas. C'est l'équivalent Debian de SELinux.

L'artifact scanning analyse automatiquement les artefacts (images Docker, packages, binaires) pour détecter les vulnérabilités avant déploiement. Scanner compare composants avec bases CVE, vérifie malwares, analyse dépendances, détecte secrets exposés. Intégration : pipeline CI/CD (blocage si critique), repository (scan upload), scan régulier production. Outils : Trivy, Grype, Snyk, Clair.

L'ASLR place pile, tas et bibliothèques à des adresses imprévisibles, donc un attaquant ne peut plus prédire où sauter après un débordement. Réglé par kernel.randomize_va_space (valeur 2 = complet).

C'est une valeur sysctl à vérifier en effectif : un fichier qui la pose mais jamais appliqué ne protège pas.

La surface d'attaque (attack surface) représente tous les vecteurs d'entrée qu'un attaquant peut exploiter pour compromettre un système.

Composantes : endpoints API, ports ouverts, formulaires web, interfaces admin, dépendances tierces, comptes users, services internet, APIs non auth, buckets S3 publics.

Réduction : moindre exposition, fermer ports inutiles, auth forte, désactiver services non utilisés, segmentation réseau, WAF, API gateway. Cartographie : scan infra (nmap), inventaire assets, pentest.

Une attestation est une preuve cryptographique qui certifie l'origine, l'intégrité et les métadonnées d'un artefact logiciel (qui l'a construit, quand, avec quels outils, quels tests ont été passés). En pratique, c'est un fichier signé numériquement qui accompagne l'artifact. Il permet de vérifier que l'artifact n'a pas été modifié et provient bien d'une source de confiance. Standards : SLSA (Supply Chain Levels for Software Artifacts), in-toto, Sigstore. Essentiel pour la supply chain security : vérifier qu'une image Docker provient bien de votre CI/CD et non d'une source compromise.

ABAC (Attribute-Based Access Control) est un modèle de contrôle d'accès qui autorise/refuse les actions selon les attributs de l'utilisateur, ressource et contexte.

Contrairement à RBAC (rôles fixes), ABAC évalue des politiques dynamiques :

Attributs utilisateur : département, niveau Attributs ressource : classification, propriétaire Attributs contexte : heure, IP, device

Exemple : "Autoriser SI département='Finance' ET classification='Confidentiel'"

Outils : OPA, AWS IAM, XACML.

Les attributs sont des métadonnées attachées à une ressource (utilisateur, fichier, service) pour la décrire, la catégoriser ou contrôler ses permissions.

Contextes : IAM/ABAC (politiques d'accès dynamiques), Kubernetes (labels/annotations), Cloud tagging (organisation, billing), HTML/XML, POO.

Avantages : flexibilité (politiques dynamiques), granularité (contrôle fin), organisation (catégorisation), automation (actions selon attributs), cost allocation.

Best practices : standardisation du nommage, tags obligatoires, tagging automatique via IaC.

Un audit est l'enregistrement et l'examen systématique des actions effectuées sur un système pour garantir la conformité, détecter les anomalies et assurer la traçabilité. Les logs d'audit capturent qui a fait quoi, quand et depuis où : connexions, modifications de configuration, accès aux données sensibles, changements de permissions. Ces logs sont immuables et stockés de manière sécurisée. En cloud, les services d'audit (AWS CloudTrail, Azure Monitor, GCP Cloud Audit Logs) enregistrent toutes les actions API. Essentiel pour la sécurité, la conformité réglementaire (RGPD, SOC2) et les investigations post-incident.

auditd consigne une piste d'audit inviolable des actions privilégiées (accès à /etc/shadow, changements d'identité, montages). Les règles sont chargées dans le noyau (auditctl -l), idéalement en mode immuable (-e 2) pour qu'un attaquant ne puisse les désactiver sans redémarrage.

L'état effectif se lit via auditctl -l/-s, pas seulement audit.rules sur disque.

L'authentification est le processus de vérification de l'identité d'un utilisateur ou d'un système avant d'accorder l'accès à des ressources. Méthodes : mot de passe, authentification multi-facteurs (MFA), certificats, biométrie, tokens. En DevOps : clés SSH pour les serveurs, tokens pour les APIs, identités de service (service accounts) pour les applications. Standards : OIDC (OpenID Connect), SAML, OAuth 2.0. Important : l'authentification vérifie "qui tu es", l'autorisation vérifie "ce que tu peux faire".

L'autorisation est le processus qui détermine les actions qu'un utilisateur authentifié est autorisé à effectuer sur des ressources. Une fois l'identité vérifiée (authentification), le système vérifie les permissions : peut-il lire ce fichier ? Modifier cette configuration ? Supprimer cette ressource ? Modèles : RBAC (rôles), ABAC (attributs), ACL (listes). En Kubernetes : RBAC définit qui peut faire quoi sur quelles ressources (pods, services, secrets). En cloud : IAM policies définissent les permissions.

Un bastion host (jump box) est un serveur durci et surveillé servant de point d'accès unique pour administrer des ressources dans un réseau privé.

Sécurité : OS minimal, MFA obligatoire, whitelist d'IPs, session recording, logs complets.

Alternatives modernes : AWS Session Manager (sans bastion), Teleport, BeyondCorp/Zero Trust, Tailscale.

En DevOps : SPOF pour l'administration, prévoir haute disponibilité et monitoring robuste. Appliquer le principe du moindre privilège.

Un bearer token est un jeton d'authentification transmis dans les en-têtes HTTP (Authorization: Bearer xxx) pour prouver l'identité sans renvoyer les credentials.

Fonctionnement : après authentification, le serveur génère un token (JWT, OAuth) que le client stocke et inclut dans chaque requête. Le serveur valide le token.

Sécurité : durée limitée, HTTPS uniquement, stockage sécurisé, révocables si compromis.

Une breach (brèche) est un incident de sécurité où des données confidentielles sont accédées, volées ou exposées sans autorisation.

Types : data breach (fuite de données), credential breach (identifiants compromis), network breach (intrusion réseau).

Causes : vulnérabilités non patchées, phishing, credentials faibles, mauvaise configuration, insider threat.

Réponse : détection rapide (SIEM), containment, notification (RGPD : 72h), forensics, remediation. Prévention : defense in depth, monitoring, tests de sécurité.

Un buffer overflow survient quand un programme écrit plus de données qu'un buffer ne peut contenir, corrompant la mémoire adjacente.

Risques : crash applicatif, exécution de code arbitraire (RCE), élévation de privilèges. Exploité pour prendre le contrôle d'un système.

Types : stack overflow (pile), heap overflow (tas), integer overflow (dépassement d'entier).

Prévention : langages memory-safe (Rust, Go), bounds checking, ASLR, stack canaries, compilation avec protections (-fstack-protector), analyse statique.

Un bypass est le contournement d'un mécanisme de sécurité, d'une validation ou d'une règle permettant d'accéder à des ressources normalement protégées ou d'exécuter des actions interdites.

Exemples : bypass d'authentification (accès sans login), bypass de WAF (Web Application Firewall) via crafting de requêtes, bypass de validation (injection SQL/XSS), bypass de rate limiting (API abuse).

Causes : erreurs de logique, configurations incorrectes, vulnérabilités non patchées, manque de défense en profondeur. Prévention : tests de sécurité (penetration testing), revue de code, principe du moindre privilège, defense in depth.

Un certificat SSL/TLS est émis par une CA (Certificate Authority) pour attester l'identité d'un serveur et permettre le chiffrement via clé publique.

HTTPS : serveur présente certificat → navigateur vérifie CA, domaine, expiration → communication chiffrée TLS. Types : SSL/TLS (HTTPS), client (mTLS), wildcard (*.example.com), Let's Encrypt (gratuit). Gestion : renouvellement auto (cert-manager), stockage sécurisé clés privées, surveillance expirations.

Les cgroups (control groups, v2 aujourd'hui) plafonnent ce qu'un service consomme, ce qui contient un déni de service (épuisement mémoire/CPU) à un seul service. systemd y adosse MemoryMax=, CPUQuota=.

Durcissement : ProtectControlGroups= empêche un service d'altérer la hiérarchie cgroup.

Un checksum est une empreinte calculée à partir de données permettant de vérifier leur intégrité après transmission ou stockage.

Algorithmes : MD5 (obsolète, collisions), SHA-256 (recommandé), SHA-512, CRC32 (détection erreurs).

Usage : vérifier téléchargements (sha256sum fichier), détecter corruption, valider intégrité backups.

Principe : recalculer le checksum après réception et comparer avec l'original. Si différent = données corrompues ou altérées.

chrony garde l'horloge exacte ; une dérive casse la corrélation forensique, la validité des certificats et les tickets Kerberos. Préférez une source authentifiée via NTS (Network Time Security, RFC 8915) pour qu'une source usurpée ne décale pas l'horloge.

Un seul démon doit discipliner l'horloge (masquer systemd-timesyncd/ntp concurrents).

CINC Auditor est la distribution libre (sans marque) de Chef InSpec. Un contrôle InSpec décrit, dans un langage lisible, l'état attendu d'une ressource :

describe command('sshd -T') do
  its('stdout') { should match(/^permitrootlogin no$/i) }
end

Pavois s'appuie 100 % sur CINC : il exécute ces contrôles contre la configuration effective, en natif (local://, ssh://) ou via conteneur, et en tire un rapport noté par norme. Le code de sortie reste exploitable en CI.

Les CIS Benchmarks sont des guides de configuration de sécurité publiés par le Center for Internet Security pour durcir systèmes et applications.

Couverture : OS (Linux, Windows), cloud (AWS, Azure, GCP), Kubernetes, Docker, bases de données, navigateurs.

Structure : recommandations numérotées, niveaux (L1 = baseline, L2 = renforcé), scripts d'audit automatisés.

Outils : CIS-CAT (audit), InSpec, OpenSCAP, Trivy (conteneurs). Référence pour audits de conformité et hardening.

Un contrôle CIS est rangé en L1 ou L2. Le L1 vise un durcissement sûr pour la plupart des hôtes ; le L2 ajoute des mesures strictes pour environnements à haute sécurité. Pavois étiquette chaque contrôle level_cis: '1'|'2', et le rapport recompose la vue par niveau côté client.

Voir le CIS Benchmark.

L'analyse de code examine le code source pour détecter bugs, vulnérabilités, code smells et violations de standards.

Types : statique (SAST - sans exécution), dynamique (DAST - runtime), composition (SCA - dépendances).

SAST : SonarQube, ESLint, Pylint, Semgrep, CodeQL. Détecte bugs, vulnérabilités, code smells avant exécution.

Métriques : complexité cyclomatique, duplication, dette technique, couverture, vulnérabilités.

Intégration : pre-commit hooks, CI pipeline (quality gates), IDE plugins (feedback immédiat).

Best practices : règles progressives, faux positifs gérés, baseline pour legacy code, métriques suivies dans le temps.

L'injection est une vulnérabilité critique (OWASP Top 10 #1) permettant à un attaquant d'insérer du code malveillant dans une application, entraînant l'exécution de commandes non autorisées.

Types : SQL injection (manipulation requêtes BDD : ' OR '1'='1), Command injection (exécution commandes OS), LDAP injection, XPath injection, NoSQL injection.

Exemple SQL : requête vulnérable SELECT * FROM users WHERE name='$input', input malveillant donne accès à tous les utilisateurs. Prévention : prepared statements, validation stricte, principe moindre privilège, ORM, WAF.

CWE (Common Weakness Enumeration) est un catalogue communautaire maintenu par MITRE, listant les types de faiblesses logicielles (bugs, défauts de conception) pouvant mener à des vulnérabilités.

Différence CVE/CWE : CVE = vulnérabilité spécifique dans un produit (ex: CVE-2021-44228 Log4Shell). CWE = catégorie de faiblesse générique (ex: CWE-89 SQL Injection).

Structure : identifiant (CWE-79), nom, description, exemples de code vulnérable, mitigations recommandées. Hiérarchie : classes → bases → variantes.

Top 25 CWE : faiblesses les plus dangereuses (injection, XSS, buffer overflow). Usage : classification SAST/DAST, formation développeurs, référentiel OWASP Top 10.

La compliance est le respect des exigences réglementaires, normes et politiques internes applicables à une organisation.

Réglementations : RGPD (données personnelles), PCI-DSS (paiements), HIPAA (santé), SOC2 (SaaS), ISO 27001.

DevOps : compliance as code, audits automatisés, traçabilité (logs immuables), contrôles d'accès, chiffrement.

Conséquences non-conformité : amendes, sanctions, perte de confiance, interdiction d'opérer. Automatiser les vérifications en CI/CD.

UTC est le standard de temps de référence mondiale, sans décalage horaire, utilisé pour synchroniser les systèmes distribués.

Caractéristiques : pas de DST, référence universelle, notation ISO 8601 (2024-01-15T10:30:00Z).

Vs timezones : UTC = référence. Paris = UTC+1 (+2 en été), New York = UTC-5.

Bonnes pratiques : stocker/logger en UTC, convertir en local à l'affichage uniquement, synchroniser serveurs via NTP. Erreurs : mélanger timezones, oublier DST.

Les credentials (identifiants) sont les informations permettant de prouver l'identité d'un utilisateur ou service pour accéder à un système.

Types : username/password, clés SSH, tokens API, certificats clients, clés d'accès cloud (AWS access keys).

Gestion sécurisée : jamais en clair dans le code, rotation régulière, principe du moindre privilège, vault (HashiCorp Vault, AWS Secrets Manager).

Risques : fuite = compromission système. Scanner les repos pour détecter credentials exposés (git-secrets, truffleHog).

CORS (Cross-Origin Resource Sharing) contrôle les requêtes HTTP entre différents domaines pour protéger contre CSRF et XSS.

Fonctionnement : navigateur bloque par défaut requêtes cross-domain (same-origin policy). CORS permet au serveur d'autoriser explicitement certains domaines via headers HTTP (Access-Control-Allow-Origin, etc.). Configuration : définir domaines autorisés, méthodes HTTP, headers permis. Erreurs CORS : fréquentes en développement (localhost:3000 → localhost:8000). Solution : headers CORS ou proxy dev.

Le Cross-Site Scripting (XSS) est une vulnérabilité permettant d'injecter du code JavaScript malveillant dans des pages web consultées par d'autres utilisateurs.

Types de XSS :

• Reflected : code injecté via URL, exécuté immédiatement
• Stored : code persisté en base, exécuté à chaque affichage
• DOM-based : manipulation côté client du DOM

Impacts : vol de cookies/sessions, keylogging, defacement, phishing, propagation de malware.

Protections :

• Output encoding : échapper HTML/JS/URL selon contexte
• CSP (Content Security Policy) : restreindre sources de scripts
• HttpOnly cookies : empêcher accès JS aux cookies sensibles
• Input validation : filtrer les entrées utilisateur

Outils de détection : OWASP ZAP, Burp Suite, DOM Invader. Classé dans OWASP Top 10.

La cryptographie est la science de la protection des informations via des algorithmes mathématiques de chiffrement et d'authentification.

Primitives : chiffrement (confidentialité), hachage (intégrité), signature (authenticité/non-répudiation).

Algorithmes : AES (symétrique), RSA/ECDSA (asymétrique), SHA-256 (hash), HMAC (MAC).

Applications DevSecOps : TLS/HTTPS, chiffrement at rest, signatures de commits/images, gestion de secrets, PKI/certificats.

CVE (Common Vulnerabilities and Exposures) est un identifiant unique standardisé (CVE-ANNÉE-NUMÉRO) pour chaque vulnérabilité de sécurité découverte.

Informations : description, versions affectées, score CVSS (sévérité 0-10), correctifs disponibles.

Outils scan : Trivy, Grype, Snyk, Clair. Intégration CI/CD pour bloquer images vulnérables.

Processus : scan → détection → évaluation impact → priorisation → patching. Base MITRE/NVD référence mondiale.

CVSS (Common Vulnerability Scoring System) est un système standardisé de notation de la sévérité des vulnérabilités de 0 à 10.

Échelle : None (0), Low (0.1-3.9), Medium (4.0-6.9), High (7.0-8.9), Critical (9.0-10.0).

Facteurs : vecteur d'attaque (réseau/local), complexité, privilèges requis, impact (confidentialité/intégrité/disponibilité).

Usage : prioriser le patching (Critical d'abord), définir seuils CI/CD (bloquer si CVSS > 7), reporting sécurité.

La cybersécurité protège les systèmes informatiques, réseaux et données contre les cyberattaques et accès non autorisés.

Piliers CIA : Confidentialité, Intégrité, Disponibilité. Défense en profondeur : couches multiples de protection.

Domaines : sécurité réseau, applicative, IAM, chiffrement, gestion vulnérabilités, incident response.

Voir terme "Cybersecurity" (détaillé) pour informations complètes sur les pratiques et méthodologies.

La protection des données regroupe les pratiques sécurisant les données contre perte, corruption, vol ou accès non autorisé.

Piliers : confidentialité (chiffrement), intégrité (checksums), disponibilité (backups, réplication).

Réglementations : RGPD (Europe), CCPA (Californie), HIPAA (santé US), PCI-DSS (paiements).

Mesures : encryption at rest/in transit, access control (RBAC), audit logs, DLP (Data Loss Prevention), backups testés.

La défense en profondeur est une stratégie de sécurité empilant plusieurs couches de protection indépendantes.

Couches : périmètre (firewall, WAF), réseau (segmentation, IDS), hôte (antivirus, hardening), application (auth, validation), données (encryption).

Principe : si une couche est compromise, les autres continuent de protéger. Pas de single point of failure en sécurité.

Complémentaire : Zero Trust (ne faire confiance à personne), least privilege (accès minimal nécessaire).

DevSecOps étend DevOps intégrant sécurité comme responsabilité partagée du cycle logiciel, non plus étape finale validation.

Shift-Left : contrôles sécurité tôt dans pipeline (analyse code, scan dépendances, secrets, tests) pour réduire coûts correction.

Pratiques : SAST/DAST automatisé, gestion secrets, scanning images, policy as code, threat modeling. Objectif : livrer vite ET sécurisé.

Diffie-Hellman est un protocole permettant à deux parties d'établir une clé secrète partagée sur un canal non sécurisé.

Principe : échange de valeurs publiques basé sur mathématiques (problème du logarithme discret) sans révéler la clé finale.

Usage : négociation de clés pour TLS/HTTPS, VPN, SSH. Base de la cryptographie moderne pour établir canaux sécurisés.

Variantes : ECDH (Elliptic Curve Diffie-Hellman) plus efficace, DHE/ECDHE (ephemeral) pour forward secrecy.

En DAC, un processus root peut tout toucher : c'est puissant mais fragile, un compte compromis hérite de toute sa portée. Les bits de permission, ACL et la propriété des fichiers relèvent du DAC.

Le MAC vient le compléter : même si une permission DAC est trop ouverte, la politique noyau peut encore refuser l'accès.

Une attaque DDoS submerge un service de requêtes massives depuis multiples sources (botnet) pour le rendre indisponible.

Types : volumétrique (saturation bande passante), applicative (saturation ressources), protocole (faiblesses TCP/IP).

Protections : anti-DDoS (Cloudflare, AWS Shield), rate limiting, filtrage géo, CDN, scaling auto. Détection précoce essentielle.

Une distribution désigne un ensemble logiciel packagé pour une utilisation spécifique (distributions Linux) ou le processus de livraison logicielle.

Linux : Ubuntu, Debian, RHEL, CentOS, Alpine. Chacune avec son package manager (apt, yum, apk) et philosophie.

Conteneurs : base images (alpine:3.18, ubuntu:22.04). Alpine populaire pour sa légèreté (~5MB).

Livraison : mécanisme de distribution (npm registry, Docker Hub, Maven Central). Canaux : stable, beta, nightly.

Une DMZ (Zone Démilitarisée) est un sous-réseau isolé entre le réseau interne et Internet, exposant les services publics tout en protégeant le LAN.

Architecture : firewall externe → DMZ → firewall interne → LAN. Double barrière de sécurité.

Services en DMZ : serveurs web, reverse proxies, bastion hosts, load balancers. Jamais de BDD ou secrets.

Cloud : subnets publics (équivalent DMZ), security groups, NACLs. Defense in depth par segmentation réseau.

Un drop-in est un fragment de configuration placé dans un répertoire dédié (*.d/), lu en plus du fichier principal, généralement dans l'ordre lexicographique des noms. systemd, sshd, sysctl, sudo, logind... s'appuient tous sur ce mécanisme pour permettre des surcharges propres, sans éditer le fichier d'origine.

Conséquence pour l'audit : un scanner qui lit uniquement le fichier principal rate les drop-ins → faux négatif. Pavois interroge l'état effectif, qui les intègre déjà.

Le DAST analyse une application en exécution (boîte noire) en simulant attaques réelles pour identifier vulnérabilités exploitables.

Contrairement au SAST, ne nécessite pas accès au code : teste comme un attaquant.

Détecte : injections SQL/XSS, auth faible, CORS/headers, CSRF. Outils : OWASP ZAP, Burp Suite, Nuclei. Complémentaire au SAST.

La configuration effective est ce qu'un service applique réellement une fois démarré, et non ce qu'un fichier déclare.

Exemple : sshd charge /etc/ssh/sshd_config, ses directives Include, puis les drop-ins de /etc/ssh/sshd_config.d/. Seule la commande sshd -T révèle la valeur résolue de chaque option.

C'est l'angle de Pavois : auditer l'état effectif (sshd -T, sysctl -a, systemctl show, auditctl -l) plutôt que de lire les fichiers, comme le font les sondes fichier d'OVAL/oscap, ce qui peut manquer la valeur résolue dès qu'un Include ou un drop-in entre en jeu.

L'encryption (chiffrement) transforme mathématiquement des données en format illisible sans la clé cryptographique appropriée.

Types : symmetric (clé unique : AES), asymmetric (paire publique/privée : RSA), hybrid (combine les deux : TLS).

Contextes : at rest (données stockées), in transit (données transmises : TLS), end-to-end (seuls émetteur/destinataire déchiffrent).

Gestion clés : KMS (AWS KMS, Azure Key Vault), rotation régulière. Obligatoire RGPD, HIPAA, PCI-DSS.

L'encryption at rest protège données stockées (BDD, fichiers, backups) par chiffrement, illisibles si accès physique non autorisé.

Fonctionnement : chiffrement avant écriture, déchiffrement lecture. Transparent pour application. Clé stockée séparément (KMS).

Technologies : disque complet (LUKS, BitLocker), BDD (TDE Oracle/SQL Server), objet (S3 SSE). Défense : at rest + in transit (TLS) + IAM. Réglementations : obligatoire RGPD, HIPAA, PCI-DSS.

L'encryption in transit protège données en transmission par chiffrement, empêchant interception/modification (man-in-the-middle).

Protocoles : TLS/SSL (HTTPS), SSH (admin distance), IPsec (VPN), WireGuard (VPN moderne). TLS 1.3 actuel (1.0/1.1 obsolètes).

Mise en œuvre : certificats SSL/TLS (Let's Encrypt), auto-renewal (cert-manager), force HTTPS (301, HSTS), mTLS service mesh. mTLS : auth bidirectionnelle critique microservices. Validation : SSL Labs, testssl.sh.

Un exploit est un code, script ou technique tirant parti d'une vulnérabilité spécifique pour compromettre un système.

Types : remote (exécution à distance), local (escalade privilèges), zero-day (vulnérabilité non patchée/connue).

Cycle de vie : vulnérabilité découverte → PoC (Proof of Concept) → exploit weaponisé → correctif publié → patch appliqué.

Défense : patching rapide, monitoring EPSS/CVE, WAF, EDR, segmentation réseau.

L'EPSS (Exploit Prediction Scoring System) prédit la probabilité (0-100%) qu'une CVE soit exploitée dans les 30 prochains jours via machine learning.

Vs CVSS : CVSS mesure gravité technique, EPSS mesure risque réel d'exploitation basé sur comportement attaquants. CVE CVSS 9.8 peut avoir EPSS 2% si complexe.

Priorisation : CVSS 7.0 + EPSS 85% = critique. CVSS 9.5 + EPSS 0.5% = moyenne. Sources : tentatives exploitation, forums, PoC, darkweb. MAJ quotidienne FIRST.org.

XDR (Extended Detection and Response) est une plateforme de sécurité intégrant détection, analyse et réponse aux menaces multi-couches : endpoints (EDR), réseau, cloud, email, identités.

Évolution : EDR (endpoints uniquement) → XDR (vision holistique corrélant données multiples sources).

Capacités : collecte télémétrie unifiée, corrélation automatique (kill chain complète), threat hunting avancé, réponse orchestrée (isolation endpoint, blocage IP, révocation session).

Avantages : réduit temps détection (MTTD) et réponse (MTTR), élimine silos, détection attaques sophistiquées (lateral movement).

vs SIEM : XDR axé réponse automatique et corrélation native, SIEM = agrégation logs + analytics manuels.

Vendors : Palo Alto Cortex XDR, Microsoft Defender XDR, CrowdStrike Falcon, SentinelOne.

External Secrets Operator (ESO) synchronise automatiquement secrets depuis gestionnaires externes (Vault, AWS Secrets Manager) vers Secrets K8s natifs.

Problème : éviter secrets dans YAML/etcd, centraliser gestion avec audit/rotation/contrôle accès. Injection dynamique sans Git.

Fonctionnement : ressource ExternalSecret référence secret Vault. Operator récupère, crée/MAJ Secret K8s. Auto-resync si changement. Avantages : source unique, rotation auto, audit, jamais dans Git. Alternative : Sealed Secrets.

faillock compte les échecs et bloque temporairement le compte (deny, unlock_time), ce qui rend le bruteforce SSH ou console impraticable. Il se règle dans la pile PAM et/ou faillock.conf.

À doser : un verrouillage trop agressif devient un déni de service contre vos propres utilisateurs.

Un fingerprint (empreinte) est un identifiant unique court généré à partir des caractéristiques complètes d'une entité, facilitant sa vérification et son identification.

Cas d'usage :

Clés SSH : hash de la clé publique pour vérifier l'identité du serveur Certificats TLS : signature pour valider le certificat Browser fingerprinting : tracking utilisateurs via config navigateur/OS Container images : digest SHA256 pour vérifier l'intégrité

Génération typique : hash cryptographique (SHA256, MD5). Permet de comparer rapidement deux entités.

Le fingerprinting identifie un système/appareil/navigateur en combinant caractéristiques techniques distinctives, sans cookies.

Navigateur : user-agent, résolution, plugins, fonts, canvas → hash unique. Usage : tracking, détection fraude.

Réseau : identification services par analyse réponses (nmap, p0f). TLS : analyse ClientHello.

Défense : uniformisation réponses, VPN/Tor, browsers anti-fingerprinting (Brave, Tor Browser).

Un firewall (pare-feu) est un dispositif de sécurité réseau qui filtre le trafic entrant et sortant selon des règles prédéfinies. Il constitue la première ligne de défense.

Types de firewalls :

Pare-feu réseau : filtrage par IP/port (iptables, nftables) Pare-feu applicatif (WAF) : analyse HTTP, protection contre OWASP Top 10 Pare-feu hôte : protection au niveau système (firewalld, ufw) Next-Gen Firewall (NGFW) : inspection applicative, IDS/IPS

Examine chaque paquet et applique des règles allow/deny basées sur IP, ports, protocoles.

Le FSS ne empêche pas l'édition des logs par un root local, mais la rend visible : journalctl --verify signale la première entrée altérée. Clés générées via journalctl --setup-keys, sceau activé par Seal=yes.

À coupler à l'envoi des logs hors machine : le FSS détecte, l'export distant préserve une copie intacte.

Le fuzz testing (fuzzing) consiste à fournir des données aléatoires, malformées ou inattendues à une application pour détecter des bugs, crashes et vulnérabilités.

Types de fuzzing :

Mutation-based : modifier des entrées valides Generation-based : générer des entrées selon une grammaire Coverage-guided : utiliser la couverture de code pour cibler les zones non testées

Outils populaires : AFL, libFuzzer, OSS-Fuzz (Google), Peach Fuzzer. Découvre des vulnérabilités critiques (buffer overflow, injection, crash) que les tests classiques manquent.

Le RGPD (GDPR) est le règlement européen encadrant la collecte, le traitement et le stockage des données personnelles des citoyens UE.

Principes : consentement explicite, droit d'accès/rectification/suppression, minimisation des données, notification des violations sous 72h.

Sanctions : jusqu'à 4% du CA mondial ou 20M€.

En DevOps : chiffrement données, logs anonymisés, gestion du consentement, audit trail, data retention policies.

GRUB précède toute défense de l'OS : qui peut éditer une entrée au démarrage peut ajouter init=/bin/bash et obtenir un root non authentifié. Durcissement : mot de passe superutilisateur (password_pbkdf2) avec --unrestricted, grub.cfg en 0600, options de durcissement sur la ligne de commande noyau.

Pavois lit le grub.cfg généré et /proc/cmdline, pas seulement /etc/default/grub.

Les guardrails sont des contraintes automatisées qui guident vers les bonnes pratiques tout en bloquant actions dangereuses.

Exemples : Policy as Code (OPA bloque pods sans limits), pre-commit hooks (empêche secrets), CI gates (tests coverage), branch protection.

Philosophie : rendre le bon choix facile et le mauvais difficile. Éduquent avec messages clairs.

Élément clé Platform Engineering et sécurité shift-left.

Le hardening (durcissement) réduit la surface d'attaque en désactivant les services inutiles, appliquant les correctifs de sécurité, configurant des permissions minimales et supprimant les composants superflus.

Actions : désactiver services non nécessaires, supprimer comptes par défaut, principe du moindre privilège, mots de passe forts, logs d'audit, chiffrement, firewall.

Référentiels : CIS Benchmarks, ANSSI-BP-028, STIG. Outils : Lynis, OpenSCAP, InSpec.

Un HSM est un dispositif matériel dédié à la génération, stockage sécurisé et gestion des clés cryptographiques, offrant protection maximale contre l'extraction.

Caractéristiques : résistance attaques physiques, isolation clés (ne sortent jamais), opérations crypto dans HSM, certifications (FIPS 140-2 Level 3/4).

Usages : signature certificats SSL/TLS, chiffrement BDD, transactions financières, protection master keys. Cloud : AWS CloudHSM, Azure Dedicated HSM, GCP Cloud HSM. Différence KMS : HSM = protection matérielle vs KMS logiciel.

Un hash (hachage) transforme des données variables en empreinte numérique fixe (digest), déterministe et unidirectionnelle.

Propriétés : déterministe, rapide, unidirectionnelle (impossible de retrouver l'input), résistance aux collisions, effet avalanche (petit changement → hash différent).

Algorithmes : SHA-256 (standard sécurisé), SHA-3 (nouvelle génération), MD5/SHA-1 (obsolètes). Usages : vérification d'intégrité, stockage mots de passe (avec salt), signatures numériques, blockchain.

Un honeypot (pot de miel) est un système leurre déployé volontairement pour attirer les attaquants, observer leurs techniques et collecter des informations sur les menaces.

Types : low-interaction (émule services basiques, facile, moins de risques), high-interaction (système complet, réaliste, collecte riche mais risqué).

Objectifs : early warning, threat intelligence, détournement attaquants, analyse forensique (malwares, exploits). Déploiement : isolé du réseau production, monitoring complet, aucune donnée sensible. Outils : Honeyd, Cowrie (SSH), Dionaea. Cloud : GuardDuty AWS inclut leurres.

HTTPS est la version sécurisée de HTTP, utilisant SSL/TLS pour chiffrer les communications client-serveur, garantissant confidentialité, intégrité et authentification.

Fonctionnement : établissement TLS (handshake, vérification certificat), chiffrement données, vérification intégrité (HMAC).

Protection : confidentialité, intégrité, authentification serveur. Configuration : certificat SSL/TLS (Let's Encrypt), installation serveur web, redirection HTTP vers HTTPS, HSTS. Port 443 (vs 80 HTTP). Obligatoire pour authentification, paiements, SEO.

HSTS force les navigateurs à communiquer uniquement en HTTPS avec un domaine, empêchant les attaques de downgrade vers HTTP non chiffré.

En-tête : Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. Paramètres : max-age (durée), includeSubDomains (sous-domaines), preload (liste navigateurs).

Fonctionnement : première visite HTTPS → serveur envoie HSTS → navigateur mémorise → visites suivantes automatiquement HTTPS. Protection contre man-in-the-middle, SSL stripping.

L'idempotence est la propriété d'une opération qui produit le même résultat qu'elle soit exécutée une ou plusieurs fois, sans effets de bord supplémentaires.

Exemples idempotents : HTTP PUT/DELETE, Ansible/Terraform (appliqués N fois = même résultat), SET x=5. Exemples non-idempotents : HTTP POST (crée nouvelle ressource), x++ (incrémenter).

Importance DevOps : automatisation sûre (réexécuter sans risque), retry automatique, convergence (systèmes auto-réparants). API REST : GET, PUT, DELETE idempotents. POST non-idempotent.

Un identifier (identifiant) est une chaîne de caractères unique permettant de référencer une ressource ou entité spécifique dans un système.

Types courants : ID numérique (auto-incrément BDD), UUID (identifiant universel 128 bits), slug (identifiant lisible), ARN, URI/URL.

Propriétés : unicité, persistance (ne change pas), non-recyclage (ID supprimé jamais réutilisé). Usages : clé primaire BDD, URLs d'API (/users/{id}), traçabilité logs, corrélation systèmes distribués.

Une identity (identité) est l'ensemble des attributs définissant de manière unique une entité (utilisateur, service, application) dans un système informatique.

Composants : identifiants (username, email), attributs (nom, rôle), credentials (mot de passe, certificat, clé API), permissions associées.

Types : utilisateur humain, service account (applications), workload identity (pods Kubernetes), machine identity (certificats serveurs). Gestion : IAM, provisioning/deprovisioning, fédération, SSO.

IAM (Identity and Access Management) gère les identités numériques et contrôle l'accès aux ressources.

Composants : identity (user, service account), authentication (MFA, certificats), authorization (RBAC, policies), audit.

Cloud : AWS IAM, Azure AD, GCP IAM. Patterns : service accounts, federated identities, temporary credentials.

Best practices : MFA obligatoire, least privilege, rotation credentials, audit logs, centralisation IAM.

Un Identity Provider (IdP) est un service centralisé gérant les identités et authentifications des utilisateurs pour plusieurs applications, permettant le Single Sign-On (SSO).

Fonctionnement SSO : utilisateur s'authentifie auprès de l'IdP (une fois), IdP délivre un token, applications consomment ce token pour autoriser l'accès.

Protocoles : SAML 2.0, OAuth 2.0, OpenID Connect, LDAP/Active Directory. Exemples : Okta, Azure AD, Keycloak, Auth0. Avantages : expérience utilisateur simplifiée, sécurité centralisée, MFA unifié.

L'immutability (immuabilité) est la propriété d'un objet qui ne peut pas être modifié après sa création. Toute modification crée une nouvelle version.

Applications : images de conteneurs (read-only), immutable infrastructure (serveurs remplacés, jamais modifiés), structures de données immuables, backups WORM.

Avantages : prédictibilité, sécurité (pas de modification malveillante), simplicité debugging, concurrence (pas de race conditions). En infrastructure : élimine le drift, facilite rollback, garantit reproductibilité.

L'incident response (réponse aux incidents de sécurité) désigne les actions coordonnées pour détecter, contenir, éradiquer et récupérer après un incident de sécurité (intrusion, fuite de données, ransomware).

Phases NIST : préparation (plans, outils, équipe), détection et analyse, containment (limiter propagation), éradication (supprimer menace), recovery (restaurer services), lessons learned (amélioration).

Équipe : CSIRT/CERT, SOC, forensics, legal. Outils : SIEM (détection), EDR (containment), forensics (Volatility, FTK), communication sécurisée.

Une directive Include indique à un service de charger d'autres fichiers : Include /etc/ssh/sshd_config.d/*.conf pour sshd, @includedir /etc/sudoers.d pour sudo, etc.

La configuration réelle est donc dispersée sur plusieurs fichiers, parfois avec des règles de priorité subtiles. Lire le seul fichier racine donne une vision fausse : c'est tout l'intérêt d'auditer la configuration effective plutôt que les fichiers.

L'input validation (validation des entrées) consiste à vérifier et assainir toutes les données provenant d'utilisateurs ou sources externes avant traitement, pour prévenir injections, erreurs et comportements inattendus.

Types de validation : syntaxique (format correct : email, date), sémantique (valeur sensée : âge > 0), whitelist (valeurs autorisées uniquement), blacklist (valeurs interdites, moins sûr).

Techniques : validation côté serveur (obligatoire), sanitization (échapper caractères spéciaux), encoding (HTML entities), parameterized queries. Règle d'or : ne jamais faire confiance aux données entrantes.

IAST (Interactive Application Security Testing) combine les approches SAST (analyse statique) et DAST (analyse dynamique) en instrumentant l'application pendant son exécution.

Fonctionnement : un agent intégré à l'application observe le comportement en temps réel (requêtes, flux de données, appels système) et corrèle avec le code source pour détecter les vulnérabilités.

Avantages : moins de faux positifs que SAST, localisation précise dans le code, détection en contexte réel, feedback immédiat aux développeurs.

Limites : nécessite l'exécution de l'application, overhead de performance, couverture dépend des tests exécutés.

Outils : Contrast Security, Synopsys Seeker, Checkmarx IAST. Usage : environnements de test/QA, complémentaire à SAST et DAST en pipeline DevSecOps.

Un IDS (Intrusion Detection System) surveille trafic réseau ou activités système pour détecter comportements suspects et tentatives d'intrusion.

Types : NIDS (Network - surveille trafic réseau), HIDS (Host - surveille serveur spécifique).

Méthodes : signature-based (attaques connues, rapide), anomaly-based (déviations comportement, détecte zero-day mais faux positifs).

IDS vs IPS : IDS = détection passive/alerte. IPS = bloque actif. Outils : Snort, Suricata, OSSEC, Wazuh, AWS GuardDuty.

Un IPS (Intrusion Prevention System) détecte ET bloque automatiquement les intrusions et trafic malveillant en temps réel (vs IDS : détection passive).

Positionnement : inline sur le réseau, analyse temps réel. Types : NIPS (réseau), HIPS (host), WIPS (Wi-Fi).

Actions : drop packets, reset connection, blocage IP. Méthodes : signature-based, anomaly-based, protocol analysis.

IPS vs IDS : IPS = proactif/bloquant, IDS = passif/alertes. Outils : Suricata, Snort inline, next-gen firewalls.

Un ISMS (Information Security Management System, SMSI) est un framework pour gérer systématiquement la sécurité de l'information.

Composants : politique sécurité, analyse risques, contrôles techniques/organisationnels, gestion incidents, amélioration continue (PDCA).

Standards : ISO 27001 (certifiable), ISO 27002 (guide), NIST CSF, SOC 2.

Bénéfices : approche structurée, conformité RGPD/NIS2, réduction risques, confiance parties prenantes.

ISO 27001 définit les exigences pour établir et maintenir un système de management de la sécurité de l'information (SMSI/ISMS).

Structure : approche risques, cycle PDCA, 114 contrôles en 14 domaines (politique, accès, crypto, sécurité physique...).

Certification : définir périmètre SMSI, analyse risques, implémentation contrôles, audit externe, valide 3 ans.

Bénéfices : conformité RGPD/NIS2, confiance clients, réduction risques, amélioration continue.

L'isolation est la séparation entre composants pour limiter l'impact des défaillances ou vulnérabilités.

Niveaux : physique (serveurs séparés), virtualisation (VMs), conteneurs (namespaces, cgroups), réseau (VLANs, VPCs).

Kubernetes : namespaces, network policies, resource quotas, Pod Security Standards.

Bénéfices : "blast radius" limité, défense en profondeur, breach containment.

journald doit écrire dans /var/log/journal (Storage=persistent) pour survivre aux redémarrages, plafonner sa taille (anti-saturation), et idéalement sceller ses journaux (FSS). Pavois lit la config effective (base + drop-ins fusionnés).

L'export vers un collecteur distant met les preuves hors de portée du root local.

JWT (JSON Web Token) est un format standardisé (RFC 7519) de jeton compact pour transmettre des informations sécurisées, typiquement pour l'authentification.

Structure : header.payload.signature (Base64). Header (alg HS256), Payload (claims : sub, exp, iat), Signature (HMAC du header+payload).

Workflow : authentification → JWT signé → client stocke → Authorization Bearer → serveur vérifie signature. Avantages : stateless, scalable, auto-portant. Sécurité : payload visible, HTTPS obligatoire, expiration courte, refresh tokens.

Un jumphost (bastion) est un serveur sécurisé servant de point d'accès unique vers un réseau privé non accessible depuis Internet.

Architecture : Internet → Bastion (DMZ) → Réseau privé. Sécurité : hardening, MFA, clés SSH, audit, whitelist IPs.

Connexion : ssh -J user@bastion user@private-server ou SSH config ProxyJump.

Alternatives cloud : AWS Session Manager, Azure Bastion, GCP IAP. Moderne : zero-trust (Tailscale, Cloudflare Tunnel).

Un module s'exécute avec tous les privilèges noyau ; un bug dans un pilote jamais utilisé reste exploitable. Le désactiver vraiment exige install <mod> /bin/false et blacklist dans /etc/modprobe.d/, pas la seule blacklist.

Pavois lit l'état effectif (chargé ? lsmod ; désactivé ? modprobe --showconfig), pas un seul fichier .conf.

KMS (Key Management Service) est un service de gestion centralisée des clés cryptographiques pour créer, stocker, faire tourner et auditer les clés de chiffrement.

Fonctions : création/stockage sécurisé, rotation automatique, contrôle d'accès IAM, audit complet.

Architecture : Master Key (racine), Data Encryption Key (DEK), envelope encryption (DEK chiffre données, Master Key chiffre DEK).

Providers : AWS KMS, Azure Key Vault, GCP Cloud KMS, HashiCorp Vault.

Cas d'usage : chiffrement données au repos, secrets application, conformité RGPD/PCI-DSS.

Une key pair (paire de clés) est un ensemble de deux clés cryptographiques liées : une clé publique (partageable) et une clé privée (secrète).

Usages : chiffrement, signature numérique, authentification SSH sans mot de passe.

SSH : génération avec ssh-keygen, clé publique sur serveur (~/.ssh/authorized_keys), connexion automatique avec clé privée.

Algorithmes : RSA (2048-4096 bits), Ed25519 (moderne, recommandé), ECDSA.

Bonnes pratiques : protéger clé privée (permissions 600), passphrase, rotation régulière.

La Kill Chain (chaîne d'attaque) est un modèle décrivant les étapes séquentielles d'une cyberattaque ciblée.

Phases classiques (Lockheed Martin) : 1) Reconnaissance (identifier cibles), 2) Weaponization (créer exploit), 3) Delivery (livrer malware), 4) Exploitation (exécuter code), 5) Installation (implanter backdoor), 6) Command & Control (C2 - communiquer avec attaquant), 7) Actions on Objectives (exfiltrer données, sabotage).

Défense : briser la chaîne le plus tôt possible. Chaque phase = opportunité détection/blocage.

Variantes : MITRE ATT&CK (détails tactiques/techniques), Unified Kill Chain (étendu).

Pratique DevSecOps : shift-left security (prévention reconnaissance), EDR (détection exploitation), network segmentation (bloquer C2).

Le lateral movement (mouvement latéral) est une technique post-intrusion où un adversaire se déplace vers d'autres machines du réseau pour étendre son accès.

Méthodes : vol credentials (pass-the-hash), exploitation services (RDP, SSH, SMB), abus confiance domaines, outils légitimes (PsExec, PowerShell).

Objectifs : escalade privilèges, persistance, accès données sensibles, préparation attaque finale.

Détection : monitoring authentifications anormales, UEBA, segmentation réseau, honeypots.

Prévention : segmentation stricte, moindre privilège, MFA, PAM, Zero Trust.

Le principe du moindre privilège consiste à accorder uniquement les permissions minimales nécessaires pour accomplir une tâche.

Application : utilisateurs (accès lecture sauf si écriture nécessaire), processus (pas root), services (IAM minimal), conteneurs (capabilities limitées), API (scopes restreints).

Bénéfices : réduction surface attaque, limitation dégâts, conformité, audit facilité.

Implémentation : RBAC (rôles), ABAC (contexte), JIT (élévation temporaire), PAM (accès élevés).

Exemple : app web pas root, BDD read-only, CI/CD permissions limitées.

Le lifecycle est l'ensemble des phases d'une entité depuis sa création jusqu'à sa suppression.

Application : développement, build, déploiement, exploitation, décommissionnement.

Conteneur : création, démarrage, pause, arrêt, suppression. Hooks lifecycle (postStart, preStop).

Gestion : automatisation IaC/CI/CD, politiques rétention, hooks, monitoring.

LDAP est un protocole pour accéder aux services d'annuaire distribués contenant informations hiérarchiques, utilisé pour authentification centralisée.

Structure : arbre hiérarchique (DIT), entrées (DN unique : cn=alice,ou=users,dc=example,dc=com), attributs (cn, ou, dc).

Usages : authentification centralisée (SSO entreprise), annuaire employés, gestion accès (groupes), configuration.

Opérations : bind (auth), search, add/modify/delete, compare.

Évolution : remplacé par OAuth/OIDC, SAML, mais reste présent legacy.

Les capabilities permettent le moindre privilège : un service qui doit juste écouter sur le port 80 reçoit CAP_NET_BIND_SERVICE, pas l'UID 0. systemd les borne via CapabilityBoundingSet=.

Retirer les capacités inutiles d'un démon réduit ce qu'un attaquant gagne en le compromettant.

L'attaque Man-in-the-Middle (MitM) intercepte secrètement communications entre deux parties pour voler ou modifier données.

Techniques : ARP/DNS spoofing, rogue Wi-Fi, SSL stripping (downgrade HTTPS).

Impact : vol credentials/données, injection malveillante, usurpation identité.

Protections : HTTPS/TLS, HSTS, certificate pinning, VPN, mTLS. Détection : alertes certificat invalide, monitoring réseau anormal.

En MAC, l'autorisation ne dépend pas du propriétaire du fichier (contrairement au DAC) mais d'une politique centrale appliquée par le noyau. SELinux et AppArmor en sont les implémentations Linux.

Intérêt : un service compromis reste confiné à son domaine, même s'il tourne en root, ce qui plafonne le rayon d'impact.

Les metadata (métadonnées) décrivent d'autres données, fournissant contexte et informations structurées sur ressources.

Types : descriptives (titre, auteur), structurelles (format, taille), administratives (création, permissions), techniques (résolution, checksums).

Usages : tagging (env=prod pour filtrage), labels (sélection Kubernetes), annotations (doc, non-identifiantes), attributs cloud (cost center, owner).

Formats : key-value, JSON, YAML, headers HTTP.

Bonnes pratiques : conventions nommage, tags obligatoires (owner, env), immutabilité, indexation. Exemples : labels conteneurs, metadata S3, EXIF photos.

La micro-segmentation divise le réseau en segments fins (workload/pod level) avec contrôles granulaires.

Vs traditionnelle : VLANs larges vs politiques par workload, zero-trust interne, mouvement latéral bloqué.

Implémentations : Network Policies Kubernetes, NSX VMware, service mesh (mTLS), firewalls distribués.

Avantages : limiter blast radius, conformité. Défis : complexité règles, troubleshooting.

Sur /tmp, /dev/shm, /var..., ces options coupent les abus classiques : noexec retire le terrain de jeu d'un payload déposé, nosuid neutralise un setuid planté, nodev bloque un faux nœud disque.

Pavois lit le montage effectif (/proc/self/mountinfo, findmnt), pas /etc/fstab : une option jamais remontée n'est pas effective.

mTLS (mutual TLS) authentifie client ET serveur par certificats, contrairement au TLS classique (serveur seul).

Fonctionnement : connexion TLS → serveur présente certificat → serveur demande certificat client → vérification bilatérale.

Avantages : auth forte bidirectionnelle, base zero-trust, chiffrement E2E, pas de passwords.

Usages : service mesh (Istio, Linkerd), APIs machine-to-machine, microservices. Complexité : gestion PKI, rotation certificats.

Le MFA (Multi-Factor Authentication) exige plusieurs preuves d'identité distinctes, réduisant drastiquement les accès non autorisés.

Facteurs : connaissance (mot de passe), possession (smartphone, token), inhérence (biométrie).

Types : authenticator app (TOTP), hardware token (YubiKey), push notification, SMS (déprécié car vulnérable SIM swap).

Implémentation : MFA obligatoire pour admins et accès sensibles, conditional access policies, backup codes.

Bloque >99% des attaques par credentials volés. Pilier du Zero Trust.

Un mutable tag (tag mutable) est une référence de version (v1, latest) qui peut être déplacée vers un commit/artefact différent, contrairement aux SHA immuables.

Risques sécurité : attaquant peut rediriger tag mutable vers code malveillant, affectant tous les utilisateurs référençant ce tag.

Exemples : GitHub Actions @v4 (mutable) vs @sha, Docker nginx:latest vs nginx@sha256:..., npm ^1.0.0 vs lockfile.

Bonnes pratiques : épingler par SHA/digest pour dépendances critiques, lockfiles, Dependabot pour mises à jour contrôlées.

Les namespaces donnent à un groupe de processus sa propre vue d'une ressource : un user namespace peut faire qu'un root dans le namespace ne soit personne dehors. systemd les utilise pour le sandboxing (PrivateTmp, RestrictNamespaces).

Ils isolent, mais ne remplacent pas le MAC : un namespace mal configuré reste une surface.

Le NIST (National Institute of Standards and Technology) est l'agence fédérale américaine établissant les normes et standards technologiques.

Domaines clés : Cybersécurité (NIST Cybersecurity Framework, SP 800-53), cryptographie, cloud computing (définition officielle des 5 caractéristiques du cloud).

Référence DevSecOps : NIST SP 800-190 (sécurité conteneurs), NIST CSF (gestion risques cyber), NIST 800-61 (réponse aux incidents).

Impact : Standards adoptés mondialement, base des certifications (FedRAMP, ISO 27001). Gratuit et public, contrairement aux normes ISO payantes.

La NVD (National Vulnerability Database) est la base de données du NIST (USA) référençant toutes les vulnérabilités publiées avec leurs identifiants CVE.

Contenu : CVE enrichis avec scores CVSS, CWE (type de faiblesse), CPE (produits affectés), références, correctifs.

Usage DevSecOps : source de données pour scanners (Trivy, Grype), SCA tools, enrichissement alertes sécurité.

API : NVD API 2.0 permet requêtes programmatiques. Complémentaire : CVE (identifiants), CVSS (scoring), CWE (classification).

Les network policies sont des règles de filtrage réseau définissant quelles communications sont autorisées entre pods/services.

Fonctionnement : sélection pods (labels), règles ingress/egress, deny by default.

Cas d'usage : isolation namespaces, segmentation tiers, compliance, zero-trust.

Implémentation : CNI doit supporter (Calico, Cilium), iptables/eBPF. Limites : Layer 4 uniquement, troubleshooting difficile.

La network security (sécurité réseau) englobe les politiques, pratiques et technologies protégeant l'infrastructure réseau contre accès non autorisés et attaques.

Couches de défense : périmètre (firewall, WAF), transport (TLS/SSL, VPN), réseau (segmentation, VLANs), endpoint (agents EDR).

Technologies : firewall, IDS/IPS (détection intrusions), VPN (tunnels chiffrés), NAC (authentification devices).

Pratiques : defense in depth, zero-trust, least privilege, segmentation, monitoring.

Menaces : DDoS, man-in-the-middle, port scanning, lateral movement.

Compliance : PCI-DSS, SOC2, ISO 27001 exigent contrôles réseau.

La network segmentation divise un réseau en sous-réseaux isolés pour limiter la propagation des attaques et contrôler les flux de données.

Types : physique (VLANs, switches dédiés), logique (subnets, firewall rules), micro-segmentation (niveau workload).

Architecture classique : DMZ (services exposés), application tier, data tier, management network isolé.

Bénéfices : blast radius limité, mouvement latéral difficile pour attaquants, conformité (PCI-DSS, HIPAA).

Cloud : VPC subnets (public/private/isolated), security groups, NACLs, PrivateLink.

Évolution : micro-segmentation (Cilium, Calico) + Zero Trust = segmentation au niveau application, pas seulement réseau.

OAuth 2.0 est un protocole d'autorisation permettant aux applications d'accéder aux ressources utilisateur sans exposer ses credentials.

Flows : authorization code (web apps), PKCE (SPAs, mobile), client credentials (M2M), refresh token.

Acteurs : resource owner, client, authorization server, resource server.

Scopes : permissions granulaires (read:profile). Sécurité : PKCE, state parameter, HTTPS. OAuth = autorisation, OIDC = authentification.

OPA est un moteur de politiques open source pour définir et appliquer des règles de contrôle d'accès et compliance via le langage Rego.

Principe : policy as code (versionnées, testées), decoupled (logique séparée du code), unified (mêmes politiques pour infra, apps, APIs).

Cas d'usage : admission control Kubernetes, API authorization, infrastructure compliance (Terraform), data filtering.

Integration : webhooks, sidecars, gateways, CI/CD. Workflow : requête → OPA évalue (policy + data + Rego) → décision allow/deny.

OpenID Connect (OIDC) est une couche d'authentification sur OAuth 2.0 permettant de vérifier l'identité utilisateur via tokens standardisés.

Différence OAuth : OAuth = autorisation, OIDC = authentification + autorisation.

Tokens : ID token (JWT avec sub, email, name), access token, refresh token.

Cas d'usage : SSO, federation (Google, Azure AD), identity management. Sécurité : validation JWT, PKCE, nonce (replay protection).

OSCAL standardise la conformité-comme-données : un outil GRC peut importer un catalogue de contrôles et des profils sans parsing maison. Pavois publie sa baseline en catalogue + profils par OS OSCAL ; le paquet assessment-results (un scan en OSCAL) est en roadmap.

C'est le successeur structuré des datastreams SCAP/XCCDF.

L'overhead désigne les ressources supplémentaires (CPU, RAM, réseau) consommées par l'infrastructure ou les abstractions, au-delà du travail utile.

Types : performance (latence réseau), memory (runtime, GC), operational (complexité gestion), network (headers, TLS).

Exemples : conteneurs (~MB RAM), service mesh (sidecar proxy), observability, encryption.

Tradeoff : overhead acceptable si bénéfices > coût. Optimisation : right-sizing, simplification, caching, profiling. Décision archi : évaluer overhead vs bénéfices.

OWASP (Open Web Application Security Project) est une organisation fournissant ressources et standards pour la sécurité applicative web.

Ressources : Top 10 (vulnérabilités critiques), ASVS (verification standard), Testing Guide.

Outils : ZAP (scanner), Dependency-Check, Cheat Sheets.

Top 10 2021 : Broken Access Control, Injection, Security Misconfiguration, Vulnerable Components... Référence pour audits sécurité.

PAM sépare comment on s'authentifie de quel service le demande : un module impose la qualité des mots de passe (pwquality), un autre le verrouillage après échecs (faillock). L'ordre des modules dans la pile compte.

Les piles diffèrent entre Debian (common-*) et RHEL (system-auth/authselect).

Les parameters sont des valeurs configurables passées à fonctions, scripts ou templates pour personnaliser leur comportement sans modifier le code.

Contextes : fonctions, CLI (flags : --verbose), IaC (variables Terraform), CI/CD, templates.

Types : required, optional (défaut), positional, named (clé=valeur).

Bonnes pratiques : valeurs par défaut sensées, validation, documentation, secrets séparés. Différence variables : paramètres = entrées externes, variables = internes.

Le penetration testing est une simulation d'attaque autorisée pour identifier les vulnérabilités exploitables avant qu'un attaquant réel ne les découvre.

Types : black box (aucune info), white box (accès complet), grey box (infos partielles).

Phases : reconnaissance, scanning, exploitation, post-exploitation, reporting.

Cibles : apps web (OWASP Top 10), infrastructure, APIs, cloud. Outils : Burp Suite, Metasploit, Nmap, OWASP ZAP.

Perfect Forward Secrecy (PFS) garantit que la compromission d'une clé privée long-terme ne permet pas de déchiffrer les communications passées.

Principe : chaque session utilise une clé éphémère unique, détruite après usage.

Mécanisme : échange Diffie-Hellman éphémère (DHE, ECDHE) pour chaque session.

Sans PFS : clé compromise = trafic historique déchiffrable. Avec PFS : trafic passé reste protégé. Config TLS : cipher suites DHE/ECDHE.

Les permissions sont des autorisations granulaires définissant quelles actions (read, write, delete) une identité peut effectuer sur des ressources spécifiques. Modèles : DAC (owner defines), MAC (centralized), RBAC (role-based), ABAC (attribute-based). Principes : least privilege, separation of duties, deny by default, time-bound. Cloud IAM : policies (JSON allow/deny), principals, actions, resources, conditions. Problèmes : permission creep, over-permissive. Audit : periodic reviews.

La persistence est la capacité de conserver des données au-delà de la durée de vie d'un processus ou conteneur.

Types : éphémère (RAM, emptyDir), persistant (disques, BDD, object storage).

Solutions conteneurs : volumes Docker, PersistentVolumes Kubernetes, montages NFS/EBS.

Patterns : externalized state, shared storage. Considérations : backup, replication, performance, coût. Stateless vs Stateful : stateless = scalable facilement.

La PKI est un système gérant le cycle de vie des certificats numériques : création, distribution, révocation.

Composants : CA (Certificate Authority), RA (Registration Authority), certificats, CRL/OCSP.

Hiérarchie : Root CA (offline), Intermediate CA, end-entity certificates.

Usages : TLS/HTTPS, mTLS, code signing, email (S/MIME), VPN. Gestion : rotation, révocation, monitoring, automatisation (Let's Encrypt).

Une policy est une règle formelle définissant les comportements autorisés, interdits ou requis pour ressources, accès ou configurations.

Types : security policies, network policies, resource policies, compliance policies.

Implémentations : IAM policies (cloud), NetworkPolicies (K8s), OPA/Gatekeeper, Sentinel.

Policy-as-Code : Rego, Sentinel, versionnées Git, testées automatiquement. Bonnes pratiques : least privilege, deny by default, audit régulier.

Le policy as code est une approche de gouvernance codifiant les règles de sécurité et compliance dans des fichiers versionnés, testables et automatiquement appliqués. Principe : politiques en langage déclaratif (Rego, Sentinel), versionnées Git, testées, appliquées automatiquement. Cas d'usage : infrastructure compliance, admission control K8s, API authorization, data governance. Tools : OPA (Open Policy Agent), Sentinel (HashiCorp), Kyverno, Cloud Custodian. Lifecycle : define, test, deploy, enforce, audit.

Un prefix est le début commun d'une chaîne, d'un chemin ou d'un identifiant, utilisé pour l'organisation, le filtrage ou le routage. Cas d'usage : object storage (s3://bucket/env/prod/), logging, tagging (cost-center-), networking (CIDR 10.0.0.0/16). Patterns : hierarchical organization, date-based (logs/2026/01/), namespacing. Bénéfices : filtering, IAM granulaire, lifecycle policies, cost allocation. Network prefix : CIDR notation, subnetting, route aggregation.

Un principal est une entité identifiable qui peut effectuer des actions et recevoir des permissions : utilisateur, service account, rôle ou groupe. Types : user principals (humains), service principals (apps), group principals, role principals. IAM context : principal = who, policies = what, resources = where, conditions = when/how. Service accounts : principals non-humains, credentials (tokens), least privilege. Audit : tracking actions par principal, CloudTrail/logs.

La privacy est la protection des données personnelles contre les accès non autorisés et le respect du droit des individus à contrôler leurs informations.

Réglementations : GDPR (Europe), CCPA (Californie), LGPD (Brésil), PIPEDA (Canada).

Principes GDPR : minimisation, limitation finalité, exactitude, limitation conservation, intégrité.

Techniques : anonymisation, pseudonymisation, chiffrement, access controls, data masking. Privacy by Design : intégrer protection dès conception.

La provenance désigne les métadonnées documentant l'origine et l'historique complet d'un artefact logiciel : qui l'a construit, quand, comment, à partir de quel code source.

Contenu : commit source, builder identity, build parameters, timestamps, environment, signatures cryptographiques.

Standards : SLSA provenance (levels 1-4), in-toto attestations, Sigstore.

Usage DevSecOps : supply chain security, audit compliance, vérification intégrité, détection tampering. Essentiel pour la confiance dans les artefacts déployés.

pwquality refuse les mots de passe faibles au moment du passwd : longueur minimale, diversité de caractères, refus des mots du dictionnaire. Réglé via /etc/security/pwquality.conf et la pile PAM.

Couplé à faillock, il rend l'accès par mot de passe nettement plus coûteux à forcer.

La quarantine est l'isolation temporaire d'une ressource suspecte pour analyse de sécurité sans risque pour la production.

Cas d'usage : serveur compromis, malware détecté, code suspect, compliance violations.

Processus : détection → isolation auto → analyse forensics → remédiation → validation → réintégration ou destruction.

Network : VLAN isolation, firewall rules, EDR auto-quarantine. CI/CD : commits suspects, failed security scans, flaky tests.

Une quarantine zone est un segment réseau isolé pour analyser ressources suspectes sans contaminer l'environnement production.

Architecture : VLAN séparé, accès restreint (analystes sécu), egress bloqué, logging renforcé.

Workflow : détection → isolation auto → analyse forensics → remédiation → restauration ou destruction.

Automation : SOAR, EDR, SIEM triggers. Best practices : zero trust sortant, snapshots forensics, playbooks documentés.

Une lecture runtime prouve la valeur actuelle ; elle ne prouve pas la persistance. Pavois sépare les deux axes : un PASS runtime-only plafonne la note (un A net exige une persistance prouvée). harden apply --reboot --scan re-scanne après un vrai redémarrage, rendant un PASS reboot-proven.

Voir aussi configuration effective.

Une regex (regular expression) est un motif textuel décrivant un ensemble de chaînes correspondant à un pattern.

Syntaxe : . (tout), * (0+), + (1+), ? (0-1), ^$ (début/fin), [] (classe), () (groupe), | (ou), \d\w.

Usages DevOps : parsing logs, validation input, grep/sed/awk, routing, alerting rules.

Outils : regex101.com, grep -E, sed, awk. Attention : regex complexes lentes, préférer parsers dédiés pour JSON/XML.

Rego est le langage de requête et de politique d'Open Policy Agent. Déclaratif et orienté données, il décrit ce qui doit être vrai ; OPA se charge de l'évaluation.

Principe : une règle s'écrit une fois et s'applique partout où OPA est présent, pipeline CI/CD (Conftest), cluster Kubernetes (Gatekeeper), moteur d'autorisation d'API (OPA server).

Cas d'usage : validation de manifests Kubernetes et de plans Terraform en pre-deploy, admission control K8s, policy as code unifiée, tests unitaires de politiques avec opa test.

Alternatives : Kyverno (YAML natif K8s), CEL (expressions inline dans les CRDs), Sentinel (HashiCorp).

Le remote access est la capacité de se connecter et contrôler des systèmes à distance via réseau.

Méthodes : SSH (Linux), RDP (Windows), VPN, bastion host.

Sécurité : auth forte (clés SSH, MFA), chiffrement, least privilege, audit logs, IP allowlisting.

Zero Trust : vérifier identité à chaque accès. Outils : Teleport, Boundary, AWS SSM, Tailscale. Best practices : bastion, session recording, timeout.

RBAC (Role-Based Access Control) est un modèle attribuant permissions aux utilisateurs selon leurs rôles organisationnels.

Composants : users, roles (admin, developer, viewer), permissions (read, write, delete), resources.

Avantages : scalabilité, séparation des responsabilités, onboarding simplifié, audit facilité.

Implémentation : cloud IAM, Kubernetes RBAC, bases de données. Limites : granularité, explosion rôles, contexte limité (ABAC meilleur).

RASP (Runtime Application Self-Protection) est une technologie de sécurité intégrée directement dans l'application pour détecter et bloquer les attaques en temps réel pendant l'exécution.

Fonctionnement : un agent s'intègre au runtime (JVM, .NET, Node.js) et intercepte les appels critiques (requêtes HTTP, accès BDD, système de fichiers) pour analyser et bloquer les comportements malveillants.

Avantages vs WAF : contexte applicatif complet (pas juste trafic réseau), moins de faux positifs, protection contre attaques zero-day, fonctionne même si WAF contourné.

Capacités : blocage injections SQL/XSS, détection path traversal, protection contre désérialisation, monitoring comportemental.

Outils : Contrast Protect, Imperva RASP, Sqreen. Usage : complémentaire à WAF et IAST en défense en profondeur.

SCAP (Security Content Automation Protocol) et son langage OVAL décrivent des tests de conformité que des outils comme OpenSCAP (oscap) exécutent. La plupart des tests inspectent des fichiers (textfilecontent54) et des attributs système.

Limite : lire /etc/ssh/sshd_config ne voit ni les Include, ni les drop-ins, ni la config réellement appliquée → résultats trompeurs. Pavois garde la mise en page des rapports oscap comme référence visuelle, mais jamais son moteur : il audite la configuration effective via CINC/InSpec.

Un schema définit l'organisation, types et contraintes dans un système de données.

Database : tables, colonnes, types, contraintes (PK, FK). DDL pour créer/modifier.

API : OpenAPI (REST), GraphQL schema, JSON Schema.

Patterns : schema-on-write (SQL) vs schema-on-read (NoSQL).

Evolution : migrations, backward/forward compatibility. Validation : JSON Schema, Avro/Protobuf.

seccomp (secure computing) filtre les syscalls via une liste blanche/noire (seccomp-bpf) : un processus confiné ne peut appeler que ce dont il a besoin. systemd l'expose via SystemCallFilter=@system-service.

Moins de syscalls accessibles, moins de failles noyau exploitables depuis un service compromis.

Un secret est une information sensible (mot de passe, clé API, token, certificat) nécessitant protection stricte contre accès non-autorisé.

Types : credentials, API keys, tokens, certificates, encryption keys, connection strings.

Principes : confidentiality, encryption, rotation régulière, least privilege, audit.

Storage : secrets managers (Vault, AWS SM), encrypted volumes. Anti-patterns : hardcoded, commit Git, plaintext. Injection : env vars, mounted volumes, API fetch.

Les secrets sont des données sensibles (mots de passe, clés API, certificats) nécessitant protection spéciale.

Types : API keys, credentials BDD, SSH keys, TLS certs, OAuth tokens.

Risques : commit Git, logs, env vars visibles, backups non chiffrés.

Règles : jamais en clair dans code, rotation régulière, least privilege.

Détection : git-secrets, truffleHog, GitLeaks. Voir "Secrets Management".

La secrets management regroupe pratiques et outils pour stocker, distribuer et faire tourner les secrets de manière sécurisée.

Outils : HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Kubernetes Secrets, SOPS.

Fonctionnalités : stockage chiffré, RBAC, audit logs, rotation automatique, dynamic secrets.

Patterns : env vars, fichiers montés, sidecar agent, CSI driver.

Best practices : centraliser, least privilege, audit accès, zero trust.

Secure Boot établit une chaîne de confiance depuis le firmware : chaque maillon vérifie la signature du suivant. Il contre les bootkits et noyaux modifiés, en amont de GRUB et de l'OS.

Il complète le durcissement OS sans le remplacer : un Secure Boot actif n'empêche pas une mauvaise config une fois le système démarré.

SHA-256 est un algorithme de hachage produisant une empreinte fixe de 256 bits pour vérifier intégrité.

Propriétés : déterministe, unidirectionnel, collision-resistant.

Usages : intégrité fichiers, signatures, Git commits, image digests.

Comparaison : MD5 (cassé), SHA-1 (déprécié), SHA-256 (standard).

Outils : sha256sum, openssl. Note : pour mots de passe, utiliser bcrypt/argon2.

SSL (Secure Sockets Layer) était un protocole cryptographique pour HTTPS, remplacé par TLS mais terme encore utilisé.

Historique : SSL 2.0/3.0 (cassé par POODLE), remplacé par TLS 1.0→1.3.

Aujourd'hui : "SSL" = abus de langage pour TLS. SSLv2/v3 désactivés partout.

Migration : TLS 1.2+ minimum, préférer TLS 1.3, cipher suites modernes (AEAD).

Outils : Let's Encrypt, OpenSSL, cert-manager. Terminologie : dire "TLS certificate", pas "SSL certificate".

SSL/TLS sont des protocoles cryptographiques sécurisant les communications réseau via chiffrement et authentification.

Évolution : SSL deprecated, TLS 1.2 standard, TLS 1.3 latest (meilleure performance).

Handshake : client hello → server hello (certificat) → key exchange → communication chiffrée.

Use cases : HTTPS, email chiffré, VPN, mTLS pour APIs.

Certificates : issuance par CA, renewal (Let's Encrypt), revocation si compromis.

Best practices : TLS 1.2+ only, HSTS, forward secrecy (ECDHE), automated renewal.

La security est l'ensemble des pratiques et mesures protégeant systèmes et données contre accès non-autorisés et attaques.

CIA Triad : confidentiality, integrity, availability.

Couches : network, application (OWASP), infrastructure, data, identity security.

DevSecOps : shift-left, SAST/DAST, vulnerability scanning, security as code. Principes : defense in depth, least privilege, zero trust, fail secure.

SAML (Security Assertion Markup Language) est un standard XML pour l'échange sécurisé d'authentification entre Identity Provider (IdP) et Service Provider (SP).

Composants : IdP (Okta, Azure AD), SP (application), Assertion (jeton XML).

Flow SSO : accès SP → redirect IdP → auth → assertion signée → accès accordé.

SAML vs OAuth/OIDC : SAML = enterprise SSO (XML), OAuth/OIDC = moderne (JSON, APIs). Sécurité : assertions signées, chiffrées, timestamps.

Les security controls sont les mesures techniques, administratives et physiques protégeant systèmes et données.

Types : preventive (firewall, MFA), detective (IDS, monitoring), corrective (patching), compensating.

Frameworks : CIS Controls, NIST 800-53, ISO 27001, SOC 2.

Techniques : encryption, RBAC, network segmentation, vulnerability scanning, logging.

Best practices : defense in depth, proportionnel au risque, documented, tested, continuous improvement.

Un SIEM centralise les logs de sécurité, détecte les menaces et facilite l'investigation des incidents.

Fonctions : collecte logs, normalisation, corrélation, alerting, dashboards.

Sources : firewalls, IDS/IPS, EDR, cloud audit logs, applications.

Détection : règles, anomalies, threat intelligence, ML.

Solutions : Splunk, Microsoft Sentinel, Elastic Security, Wazuh. DevSecOps : logs CI/CD, audit trail, compliance.

Le security monitoring est l'observation continue des systèmes pour détecter menaces, intrusions et comportements anormaux.

Sources : logs, network traffic, endpoint telemetry, audit logs, auth events.

Détection : signature-based, anomaly-based, ML-based.

Outils : SIEM (Splunk, Elastic), IDS/IPS, EDR, cloud-native (GuardDuty).

SOC : équipe 24/7 analysant alertes. Best practices : log everything, corrélation, playbooks, threat intel.

Le security scanning est l'examen automatisé des systèmes, code ou configs pour identifier vulnérabilités et non-conformités.

Types : SAST, DAST, SCA, container scanning, infrastructure scanning.

Intégration CI/CD : scan à chaque commit, bloquer si critiques, shift-left.

Outils : Trivy, Snyk, Checkov/tfsec, Nessus, OWASP ZAP.

Output : rapport avec severity, CVE, remediation. Best practices : scan régulier, prioriser, track remediation.

Le security testing valide systématiquement que les systèmes résistent aux attaques et protègent les données.

Types : vulnerability assessment, penetration testing, security audit, red team, bug bounty.

Approches : black box, white box, grey box.

DevSecOps : SAST/DAST automatisés en CI, fuzzing, pentests périodiques.

Standards : OWASP Testing Guide, PTES, NIST 800-115. Best practices : test régulier, scope clair, retest.

La segmentation est la division d'un réseau en zones isolées pour limiter propagation d'attaques et appliquer politiques de sécurité différenciées.

Niveaux : network (VLANs), micro-segmentation (workload-level), application (tiers web/app/db).

Bénéfices : blast radius limité, lateral movement difficult, compliance.

Implémentations : VLANs, Security Groups, Network Policies, service mesh.

Zero Trust : segmentation fondamentale, "never trust, always verify".

SELinux étiquette processus et fichiers par type et applique une politique : un service compromis ne peut faire que ce que son domaine autorise. Trois modes : enforcing (bloque), permissive (journalise seulement), disabled.

Seul enforcing protège : getenforce/sestatus donnent l'état réel ; un refus se diagnostique via les AVC (ausearch -m avc, audit2why).

Le signing (signature cryptographique) garantit l'authenticité et l'intégrité d'un artifact via cryptographie asymétrique.

Principe : clé privée signe, clé publique vérifie.

Applications : code signing, container image signing (cosign), Git commit signing, packages.

Outils : GPG, cosign (Sigstore), AWS KMS, Vault.

Supply chain : vérifier signatures CI/CD, policy "signed images only", SLSA. Best practices : protéger clés (HSM), rotation.

Le SSO (Single Sign-On) permet de se connecter une fois pour accéder à plusieurs applications.

Fonctionnement : Identity Provider centralise auth, applications délèguent.

Protocoles : SAML (enterprise), OAuth 2.0/OIDC (moderne), Kerberos.

Solutions : Okta, Auth0, Azure AD, Keycloak.

Sécurité : MFA obligatoire, session timeouts, monitoring connexions, Single Logout.

Un SBOM (Software Bill of Materials) est un inventaire exhaustif des composants d'un logiciel : dépendances, versions, licences, provenance.

Formats standards : CycloneDX (OWASP), SPDX (Linux Foundation), SWID tags.

Contenu : nom composant, version, licence, hash, supplier, vulnérabilités connues.

Usage DevSecOps : compliance licences, détection vulnérabilités (CVE), supply chain security, audit.

Génération : Syft, Trivy, CycloneDX CLI. Réglementation : Executive Order US 14028, NIS2 EU.

SCA (Software Composition Analysis) analyse automatiquement les dépendances logicielles pour identifier vulnérabilités (CVE) et problèmes de licence.

Détecte : vulnérabilités dans dépendances, licences incompatibles, dépendances obsolètes.

Sources : NVD, GitHub Advisory, OSV.

Outils : Snyk, Dependabot, Trivy, OWASP Dependency-Check, Renovate.

Intégration : CI/CD, IDE, registry. Best practices : scans réguliers, à jour, policy licences, SBOM.

L'injection SQL permet d'insérer du code SQL malveillant via des entrées non validées.

Exemple : input "' OR 1=1 --" bypass authentification si query non paramétrée.

Impacts : vol données, bypass auth, modification/suppression.

Prévention : prepared statements, ORM, input validation, WAF.

Types : in-band, blind, out-of-band. Détection : SAST, sqlmap, DAST. OWASP Top 10.

L'état (state) représente les données décrivant la situation actuelle d'un système.

Types : application state (UI, session), server state (BDD), infrastructure state (config).

Stateful vs Stateless : stateful conserve état entre requêtes, stateless = indépendant.

Challenges : synchronisation, persistance, scalabilité.

Gestion : databases, caches, Terraform state, K8s etcd. Principe : minimiser où possible.

SAST (Static Application Security Testing) analyse le code source pour détecter vulnérabilités sans exécuter l'application.

Détecte : injections SQL/XSS, hardcoded secrets, cryptographie faible.

Outils : Semgrep, SonarQube, CodeQL, Snyk Code.

CI/CD : scan à chaque PR, bloquer si critique. Avantages : shift-left, couverture large. Limites : faux positifs, complémentaire avec DAST.

Un STIG détaille, règle par règle, la configuration sécurisée d'un produit (ex. Ubuntu 22.04), avec sévérité (CAT I/II/III). Largement exigé dans les marchés publics américains.

Pavois porte le tag stig: ; comme CIS, c'est un mapping direct (la règle prescrit le réglage exact).

sudo accorde une élévation ciblée et tracée au lieu d'un accès root partagé. Pièges : NOPASSWD: ALL (annule l'authentification), absence de use_pty (détournement de TTY), variables d'environnement conservées.

Durcissement : cadrer chaque règle à la commande exacte, exiger un mot de passe, poser Defaults use_pty et journaliser.

Un binaire SUID root (ex. passwd) s'exécute en root quel que soit l'utilisateur : indispensable pour quelques outils, mais un SUID parasite ou inscriptible est un chemin direct vers root.

Durcissement : inventorier (find / -perm -4000), comparer à la baseline de la distribution, retirer l'inattendu (chmod u-s).

La software supply chain englobe composants, dépendances, outils et processus pour construire un logiciel.

Composants : source code, dépendances, base images, CI/CD tools, registries.

Risques : dépendances vulnérables, typosquatting, dependency confusion.

Protection : SCA, SBOM, lock files, signatures, SLSA.

Pratiques : auditer dépendances, minimiser, pinning versions.

Une supply chain attack compromet un composant tiers (bibliothèque, action CI, image Docker) pour infecter les projets qui en dépendent.

Vecteurs : dépendance malveillante, action GitHub compromise, image infectée, typosquatting, dependency confusion.

Attaques notables : SolarWinds, Codecov, ua-parser-js, tj-actions.

Impact : propagation massive, détection difficile.

Prévention : pinning SHA/hash, lockfiles, SBOM, Sigstore, minimal dependencies, code review updates.

SLSA (prononce "salsa") définit des niveaux de sécurité pour protéger la supply chain logicielle.

Niveaux : L1 (documentation), L2 (build service signé), L3 (plateforme hardened).

Provenance : métadonnées attestant qui a build quoi, où, quand, signé cryptographiquement.

Implémentation : GitHub Actions attestations, Sigstore, in-toto.

Adoption : Google, npm, PyPI intègrent progressivement.

La supply chain security protège contre compromissions des dépendances et processus de build.

Menaces : dépendances malveillantes, build compromise, stolen credentials.

Défenses : SCA, SBOM, signatures (Sigstore), attestations SLSA.

Frameworks : SLSA, NIST SSDF, OpenSSF Scorecard.

CI/CD hardening : least privilege, audit logs, signed commits, protected branches.

sysctl règle des paramètres dynamiques du noyau (ex. net.ipv4.ip_forward, kernel.randomize_va_space). La valeur effective est celle du noyau en cours (sysctl -a, /proc/sys), résolue depuis une pile de fichiers (/usr/lib/sysctl.d/, /etc/sysctl.d/, /etc/sysctl.conf).

Durcissement : poser la valeur sûre et la rendre persistante dans /etc/sysctl.d/, car un sysctl -w runtime régresse au redémarrage.

La threat intelligence (CTI) est la collecte et analyse d'informations sur les menaces cyber pour une défense proactive.

Types : Strategic (trends), Tactical (TTPs), Operational (campagnes), Technical (IOCs : IPs, hashes).

Sources : feeds commerciaux, open source (MISP), ISACs, dark web monitoring.

Intégration : SIEM (enrichir alertes), SOAR, threat hunting. Frameworks : MITRE ATT&CK, Diamond Model, Kill Chain.

La threat prevention englobe les mesures proactives bloquant les attaques avant qu'elles ne compromettent les systèmes.

Niveaux : network (firewalls, IPS), endpoint (EDR), application (WAF, input validation), identity (MFA).

Technologies : Next-Gen Firewalls, IPS, WAF, sandboxing.

Approches : signature-based, behavior-based, reputation, ML. DevSecOps : prévention intégrée au pipeline, hardening, patching auto.

Le temps est une mesure fondamentale en systèmes distribués pour synchronisation et ordering d'événements.

Challenges : clock skew (horloges désynchronisées), network delays, ordering events.

Synchronisation : NTP (précision ms), PTP (µs). Représentation : Unix timestamp, ISO 8601, UTC.

Logical time : Lamport clocks, vector clocks. Best practices : UTC en interne, NTP sur serveurs, timezones à l'affichage.

Un timestamp est un marqueur temporel précis identifiant quand un événement s'est produit, essentiel pour logging et audit.

Formats : Unix epoch (secondes depuis 1970), ISO 8601 (2024-01-15T10:30:00Z), milliseconds.

Timezone : toujours stocker en UTC, convertir à l'affichage.

Usage : logs, audit, cache expiration, database records. Génération : Date.now(), time.time(), NOW().

Un token est un artefact numérique représentant identité ou autorisations, utilisé pour authentification sans transmettre credentials.

Types : access token (courte durée), refresh token (longue durée), ID token (identité), session token.

JWT : header.payload.signature, self-contained (claims), stateless, base64url encoded.

Security : HTTPS only, short expiration, signature verification, secure storage. Best practices : access tokens courts (1h max), rotate refresh tokens, validate issuer/audience.

TLS est le protocole cryptographique standard assurant confidentialité, intégrité et authentification des communications réseau.

Versions : TLS 1.2 (standard actuel), TLS 1.3 (latest, handshake plus rapide).

Composants : certificates (X.509), cipher suites (AES-256-GCM), key exchange (ECDHE), MAC.

mTLS : client et serveur s'authentifient mutuellement. Best practices : TLS 1.2+ minimum, strong ciphers, forward secrecy, HSTS, automated renewal.

Chaque fichier créé hérite d'un mode masqué par le umask. Le défaut permissif 022 rend les nouveaux fichiers lisibles par tous ; 027 retire tout accès aux autres.

C'est un filet de sécurité système (à poser dans /etc/login.defs + PAM pam_umask) : il corrige les fichiers qu'on oublie de chmod.

L'unauthorized access est l'accès à un système ou données par une entité sans permissions appropriées, représentant une violation de sécurité majeure.

Types : privilege escalation, credential theft, exploitation vulnérabilité, insider threat.

Vecteurs : brute-force, phishing, SQL injection, session hijacking.

Détection : failed logins, anomalous patterns, SIEM, audit logs. Prévention : strong auth (MFA), least privilege, segmentation, encryption. Response : revocation, investigation, rotation.

Le Unix timestamp est le nombre de secondes depuis le 1er janvier 1970 00:00:00 UTC, format standard de représentation du temps.

Format : entier (1705312200), parfois millisecondes. Simple, universel, pas d'ambiguïté timezone.

Conversion : date -d @timestamp (Linux), new Date(ts * 1000) (JS), datetime.fromtimestamp(ts) (Python).

Avantages : simple à stocker/comparer, universel. Limites : peu lisible, Year 2038 (résolu 64-bit). Usage : stockage BDD, APIs, logs.

Un user est une entité humaine ou service interagissant avec un système, possédant une identité unique et des permissions définies.

Types : end user, service account, admin user, guest user.

Identity : username, user ID, email, attributes. Authentication : password, SSH key, MFA, SSO.

Authorization : roles, permissions, RBAC, policies. Lifecycle : provisioning → active → suspension → deprovisioning. Session : login, session token, timeout, logout.

Vault (HashiCorp) gère secrets, clés de chiffrement et données sensibles avec contrôle d'accès fin.

Fonctionnalités : secrets storage chiffré, dynamic secrets (credentials éphémères), encryption as a service, PKI.

Accès : authentification (tokens, OIDC, K8s), policies, audit logs.

Alternatives : AWS Secrets Manager, Azure Key Vault, GCP Secret Manager. Intégration : CI/CD, Kubernetes sidecar/CSI.

Une vulnérabilité est une faiblesse dans un système, logiciel ou processus qui peut être exploitée par un attaquant pour compromettre la sécurité.

Types : code (injection, XSS, buffer overflow), configuration (defaults, ports ouverts), dépendances (CVE), humain (phishing).

Identification : CVE (identifiant unique), CVSS (score sévérité 0-10), NVD (base nationale US).

Cycle de vie : découverte → disclosure (responsable ou 0-day) → patch → déploiement.

DevSecOps : shift-left (scanner tôt), SCA (dépendances), SAST/DAST (code), patching automatisé.

Priorisation : CVSS + exploitabilité (EPSS) + contexte métier = risque réel.

Le vulnerability management identifie, évalue, priorise et remédie les vulnérabilités de manière continue.

Cycle : découvrir (scanners), évaluer (CVSS, EPSS), prioriser (risque réel), remédier, vérifier.

Outils : Nessus, Qualys, Trivy, Snyk, Dependabot. SLA : critical 24-48h, high 7j, medium 30j.

DevSecOps : scans CI/CD, shift-left, exceptions documentées, métriques MTTR.

Le vulnerability scanning examine automatiquement systèmes et applications pour identifier les failles connues.

Types : network, host-based, application (DAST), containers, dépendances (SCA).

Outils : Nessus, OpenVAS (infra), ZAP, Burp (web), Trivy, Grype (containers), Snyk (deps).

Fréquence : continu CI/CD, scheduled infra, ad-hoc. Limites : faux positifs, compléter avec pentests.

un WAF (Web Application Firewall) est un pare-feu applicatif filtrant le trafic HTTP/HTTPS pour protéger les applications web contre les attaques courantes (injection SQL, XSS, CSRF). Placé en amont du serveur, il analyse chaque requête et bloque celles qui correspondent à des signatures malveillantes ou violent les règles définies.

La web security englobe pratiques et technologies protégeant applications web contre attaques.

OWASP Top 10 : injection, broken auth, XSS, security misconfiguration, etc.

Headers : CSP, X-Frame-Options, HSTS. Protection : WAF, rate limiting, input validation, HTTPS.

Auth : MFA, OAuth/OIDC, password hashing. Testing : SAST, DAST (ZAP, Burp), pentests.

Modèle de sécurité fondé sur le principe "ne jamais faire confiance, toujours vérifier".

Contrairement aux approches traditionnelles (périmètre réseau), Zero Trust authentifie et autorise chaque requête indépendamment de sa provenance.

Piliers : identité forte (MFA), micro-segmentation, moindre privilège, chiffrement E2E, monitoring continu.

Implémentations : BeyondCorp (Google), Azure AD Conditional Access, Cloudflare Access, Zscaler.

En DevSecOps, Zero Trust s'applique aussi au CI/CD : workload identity, secrets éphémères, OIDC federation.

/etc/shadow doit être en 0000/0640, root seul : un shadow lisible par other permet le cassage hors-ligne de tous les comptes. Le format encode l'algorithme ($6$ = SHA-512, $y$ = yescrypt) et l'âge du mot de passe.

Durcissement : permissions strictes (DAC) + algorithme fort + pwquality.