Un serveur de base de données tombe un vendredi à 17 h, pile au moment où l’équipe commerciale boucle ses propositions. Le backup existe, mais personne ne sait en combien de temps il peut être restauré.
Ce scénario illustre un problème précis : le triptyque sécurité n’est pas un poster mural, c’est un outil de décision. Disponibilité, intégrité, confidentialité forment le socle du Sec Model, et leur mise en pratique au quotidien reste le point faible de la plupart des organisations.
Sec Model et rayon d’impact : limiter la casse avant de protéger
Les concurrents sur ce sujet déroulent la définition de chaque pilier. On prend un autre angle : dans un Sec Model opérationnel, la priorité n’est pas de tout sécuriser, mais de contenir ce qui va casser.
Dans les environnements cloud multi-tenant, le Sec Model sert de cadre d’architecture pour qu’un composant compromis ne puisse affecter que son propre périmètre, même si l’infrastructure sous-jacente est mutualisée. Concrètement, on segmente par couches (tenants, comptes, VPC, namespaces) et on place des contrôles qui visent à limiter le rayon d’impact d’un incident plutôt qu’à empiler de la redondance.
Cette logique change la façon dont on arbitre entre disponibilité, intégrité et confidentialité. Au lieu de traiter chaque pilier en silo, on raisonne par scénario de défaillance : si ce namespace tombe, que perd-on ? Si cette clé de chiffrement fuite, quel périmètre de données est exposé ?
Confidentialité au quotidien : le chiffrement ne suffit pas
La confidentialité, dans la triade CID, ne se résume pas à activer le chiffrement sur un disque ou une connexion TLS. On voit encore des entreprises où les données sont chiffrées au repos, mais où n’importe quel développeur accède à la base de production avec un compte partagé.
Contrôle d’accès et principe du moindre privilège
Le chiffrement protège contre l’interception externe. Le contrôle d’accès protège contre l’usage interne abusif. Les deux sont nécessaires, mais c’est le second qui fait défaut le plus souvent.
- Chaque compte utilisateur dispose de permissions alignées sur son rôle exact, pas sur son département ou son ancienneté
- Les accès privilégiés (admin, root, DBA) passent par un bastion avec journalisation, et sont révoqués automatiquement après une durée définie
- Les fichiers sensibles sont classifiés par niveau de confidentialité, et les droits de lecture suivent cette classification, pas l’arborescence du serveur
Un fichier chiffré accessible à tout le monde reste un risque de confidentialité. C’est un point que beaucoup de RSSI rappellent lors des audits, mais qui peine à se traduire en politique d’accès granulaire.
Intégrité des données : détecter la modification, pas seulement l’empêcher
L’intégrité garantit que les données n’ont pas été altérées, ni par une attaque, ni par un bug, ni par une erreur humaine. En pratique, on se concentre trop sur la prévention (droits en écriture, validation des formulaires) et pas assez sur la détection.
Hachage et journaux d’audit
Un mécanisme de hachage sur les fichiers critiques permet de vérifier qu’un document n’a pas changé depuis sa dernière version validée. Les journaux d’audit, eux, tracent qui a modifié quoi et quand.
Sans ces deux outils, on découvre les problèmes d’intégrité au moment où un client signale une incohérence dans un rapport ou une facture. À ce stade, la remédiation coûte beaucoup plus cher que la mise en place initiale du contrôle.
L’intégrité se vérifie en continu, pas uniquement lors des sauvegardes. Un système de détection de modification (type HIDS) sur les fichiers de configuration et les bases de données critiques constitue un minimum opérationnel.
Disponibilité et sauvegardes : tester la restauration, pas le backup
La disponibilité est souvent le pilier le mieux compris, parce que ses conséquences sont immédiatement visibles : si le système est en panne, personne ne travaille. Les retours varient sur ce point, mais on observe que la majorité des plans de continuité se concentrent sur la sauvegarde sans jamais tester la restauration.
Le vrai test : le délai de reprise
Avoir des sauvegardes quotidiennes ne sert à rien si personne n’a vérifié qu’on peut restaurer un environnement complet en moins de quatre heures. Le Sec Model impose de documenter un objectif de temps de reprise (RTO) et un objectif de point de reprise (RPO) pour chaque système classé comme critique.
- Le RTO définit le délai maximal acceptable avant remise en service
- Le RPO définit la quantité maximale de données qu’on accepte de perdre (la dernière heure, les dernières 24 heures)
- Un test de restauration trimestriel, sur un environnement isolé, valide que ces objectifs sont réellement atteignables
Sans test de restauration, une sauvegarde n’est qu’une promesse. C’est la différence entre un plan de continuité sur papier et une disponibilité réelle.
NIS2 et obligations de gestion des risques liés au triptyque sécurité
Depuis le 18 octobre 2024, la directive NIS2 (UE 2022/2555) est applicable dans les 27 États membres, y compris en l’absence de transposition nationale complète. Ses obligations portent directement sur les trois piliers du triptyque sécurité.
L’article 21 impose des mesures de gestion des risques couvrant la cybersécurité des systèmes d’information. L’article 23 exige une notification des incidents dans des délais stricts. L’article 34 prévoit des sanctions en cas de non-conformité.
Pour les entreprises concernées (opérateurs de services dans de nombreux secteurs), NIS2 rend le Sec Model non plus optionnel, mais réglementairement exigible. Un RSSI qui n’a pas formalisé ses politiques de confidentialité, d’intégrité et de disponibilité s’expose à des sanctions administratives.
Arbitrer entre disponibilité, intégrité et confidentialité
Les trois piliers entrent parfois en conflit. Renforcer la confidentialité par des couches de chiffrement et d’authentification peut ralentir l’accès et dégrader la disponibilité. Multiplier les répliques pour la disponibilité augmente la surface d’attaque et complique le maintien de l’intégrité.
Le Sec Model ne vise pas la perfection sur les trois axes simultanément. Il sert à documenter les arbitrages : pour chaque système, on définit quel pilier prime, en fonction de la criticité métier. Un système de paiement privilégie l’intégrité. Un portail client interne privilégie la disponibilité. Un dossier médical privilégie la confidentialité.
Formaliser ces arbitrages dans une matrice de classification des actifs, revue chaque année, transforme le triptyque sécurité en outil de pilotage concret pour les équipes techniques et la direction.
