Comprendre et appliquer la norme ISO/IEC 27001:2022 : construire un SMSI, apprécier les risques, choisir les 93 mesures de l'annexe A, préparer les preuves et passer la certification.
Les mesures technologiques sont celles où l'équipe technique fait la différence, et celles où l'auditeur demande des preuves concrètes : une capture de configuration, un extrait de journal, un rapport de scan, une pull request. Bonne nouvelle : une équipe qui travaille proprement en fait déjà une bonne partie. Le travail consiste souvent à formaliser et à garder la trace.
Ce chapitre passe en revue les mesures qui concernent le plus une équipe produit, avec ce que Factura a mis en place.
L'auditeur vérifie trois choses : que chaque accès est justifié, qu'il est retiré au départ de la personne, et que les accès sensibles sont protégés par une authentification forte.
Factura a centralisé les identités sur son fournisseur d'identité, avec authentification unique vers GitHub, la console cloud, Slack et les outils de support. Un départ se traite en désactivant un seul compte. Si vous gérez vos propres services, un SSO auto-hébergé comme Authentik donne le même résultat.
Les règles retenues :
Politique de contrôle d'accès — extrait
- Moindre privilège : accès accordé par rôle, pas par personne.
- Authentification forte (clé FIDO2 ou application TOTP) obligatoire pour :
fournisseur d'identité, GitHub, console cloud, back-office d'administration.
- Accès production en lecture : développeurs seniors et ops.
- Accès production en écriture : ops uniquement, via bastion, sessions journalisées.
- Comptes de service : un par application, secrets dans le gestionnaire de secrets.
- Revue des accès : trimestrielle, tracée dans un ticket.
- Départ : désactivation le jour du départ, checklist signée par le manager.La revue des accès est la preuve la plus demandée. Elle peut être simple : un export des membres de l'organisation GitHub et des utilisateurs de la console cloud, comparé à la liste RH, avec les écarts corrigés et le tout archivé dans un ticket.
# Export des membres et de leur rôle dans l'organisation GitHub
gh api orgs/factura/members --paginate --jq '.[].login' > membres-github.txt
gh api "orgs/factura/members?role=admin" --paginate --jq '.[].login' > admins-github.txtLa mesure demande de se tenir informé des vulnérabilités techniques, d'évaluer son exposition et de prendre des mesures appropriées. Pour une application Node.js, ça se traduit par des délais de correction écrits et une détection automatisée.
| Criticité (CVSS) | Délai de correction en production |
|---|---|
| Critique (9.0+) | 7 jours |
| Élevée (7.0 à 8.9) | 30 jours |
| Moyenne | 90 jours |
| Faible | À la prochaine montée de version |
Un délai non tenu n'est pas grave en soi s'il est tracé avec une justification : correctif indisponible, dépendance non exploitable dans votre contexte. Ce qui pose problème, c'est l'alerte ignorée sans trace.
C'est le bloc le plus dense pour un éditeur de logiciel. Les mesures demandent un cycle de développement sécurisé, des exigences de sécurité définies, des principes d'architecture, des règles de codage, des tests de sécurité, la séparation des environnements et une gestion des changements.
La plupart de ces exigences peuvent être portées par le pipeline lui-même. Une règle de protection de branche plus une CI qui bloque, c'est une preuve qui se génère toute seule à chaque fusion. Le workflow de Factura, construit sur GitHub Actions :
name: securite
on:
pull_request:
schedule:
- cron: "0 6 * * 1" # scan hebdomadaire de la branche principale
permissions:
contents: read
security-events: write
jobs:
dependances:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
- run: npm ci
# 8.8 : échoue si une dépendance a une vulnérabilité critique connue
- run: npm audit --audit-level=critical --omit=dev
secrets:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
# 8.12 : bloque les secrets commités par erreur
- uses: gitleaks/gitleaks-action@v2
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
sast:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
# 8.28 / 8.29 : analyse statique du code
- uses: github/codeql-action/init@v3
with:
languages: javascript-typescript
- uses: github/codeql-action/analyze@v3Les autres éléments de preuve viennent des réglages de GitHub :
Branche main — règles de protection
✓ Pull request obligatoire, 1 approbation minimum → 8.32 gestion des changements
✓ Approbation invalidée si nouveau commit → 8.32
✓ Checks "securite" obligatoires → 8.8, 8.28, 8.29
✓ Pas de push direct, y compris pour les administrateurs → 8.32, 8.4 accès au code
✓ Commits signés → 8.4La mesure 8.28, codage sécurisé, demande aussi des règles écrites. Inutile de rédiger un manuel : une page qui renvoie aux standards reconnus (OWASP ASVS, OWASP Top 10), complétée par les règles propres à votre stack, suffit. Par exemple : requêtes SQL uniquement via le query builder paramétré, validation des entrées par schéma, pas de dangerouslySetInnerHTML sans assainissement, secrets uniquement par variables d'environnement.
La mesure 8.31 exige la séparation des environnements. Développement, préproduction et production dans des comptes cloud distincts, avec des identifiants distincts, c'est la façon la plus lisible de le prouver.
Nouvelle mesure de 2022 : les configurations, y compris de sécurité, doivent être définies, documentées, appliquées, surveillées et revues. L'infrastructure as code y répond naturellement : Terraform, Ansible ou des fichiers Docker Compose versionnés sont à la fois la documentation et la preuve. Toute modification passe par une pull request, donc par la gestion des changements.
Ce qui manque souvent : la détection de dérive. Une modification faite à la main dans la console cloud, hors du code, invalide la preuve. Un terraform plan planifié qui alerte en cas d'écart règle le problème.
La tentation est connue : copier la base de production en préproduction pour reproduire un bug. Avec des données de facturation réelles, c'est exactement ce que les mesures 8.11 et 8.33 cherchent à éviter, et c'est aussi un problème RGPD.
Factura a écrit un script de masquage appliqué à chaque copie :
-- Exécuté automatiquement après restauration d'un dump hors production
UPDATE clients SET
raison_sociale = 'Client ' || id,
email = 'client-' || id || '@exemple.invalid',
telephone = NULL,
iban = NULL;
UPDATE utilisateurs SET
email = 'user-' || id || '@exemple.invalid',
nom = 'Utilisateur ' || id,
mot_de_passe = '$argon2id$dev-only-hash';
-- Les montants restent réels : utiles pour reproduire les bugs de calculLa 8.15 demande de produire, conserver et protéger des journaux. La 8.16, nouvelle, demande de surveiller les comportements anormaux et d'agir. La différence est importante : des journaux que personne ne lit ne répondent qu'à la première mesure.
Chez Factura :
| Source | Événements | Conservation | Alerte |
|---|---|---|---|
| Fournisseur d'identité | Connexions, échecs, MFA | 1 an | 10 échecs en 5 min, connexion depuis un nouveau pays |
| Console cloud | Actions d'administration | 1 an | Création d'utilisateur, ouverture de port, désactivation des journaux |
| API | Authentification, accès aux exports | 6 mois | Volume d'export anormal |
| Bastion | Sessions production | 1 an | Toute session hors heures ouvrées |
Les journaux sont envoyés vers un stockage séparé, en écriture seule pour les applications : un attaquant qui compromet l'API ne doit pas pouvoir effacer ses traces. Les horloges sont synchronisées par NTP (8.17), sinon impossible de reconstituer une chronologie d'incident.
La mesure 8.13 contient un mot que beaucoup oublient : testées. Une sauvegarde jamais restaurée n'est pas une preuve. La politique de Factura :
Base PostgreSQL production
- Sauvegarde continue (PITR) chez l'hébergeur, rétention 14 jours
- Dump chiffré quotidien vers un autre fournisseur, rétention 90 jours,
stockage immuable (protection contre les rançongiciels)
- Test de restauration complète : mensuel, chronométré, consigné dans un ticket
- Objectifs : perte de données max (RPO) 1 h, remise en service (RTO) 4 hPour mettre en place des sauvegardes chiffrées et dédupliquées hors du fournisseur principal, Restic et sa stratégie de sauvegarde serveur est un bon point de départ.
La mesure demande des règles d'utilisation de la cryptographie et de gestion des clés. Une page suffit : TLS 1.2 minimum en transit, chiffrement au repos des bases et du stockage objet, mots de passe hachés en Argon2id ou bcrypt, clés gérées par le service de gestion de clés de l'hébergeur, rotation définie, accès aux clés restreint.
Nouvelle mesure, souvent surdimensionnée par peur. Pour une PME, pas besoin d'une solution DLP d'entreprise. Les mesures proportionnées : détection de secrets dans le code (gitleaks, ci-dessus), partage de fichiers externe désactivé par défaut dans la suite bureautique, alertes sur les exports massifs depuis le back-office, buckets privés par défaut avec alerte en cas de passage en public.
Aucune de ces mesures n'est exotique. Ce que la norme ajoute, c'est l'obligation de les écrire, de les appliquer à tout le périmètre, et de garder la trace qu'elles fonctionnent. Le chapitre suivant montre comment organiser ces preuves et faire vivre le SMSI au quotidien.