← B3 — Sécurité des SI

Principes de la sécurité

Sommaire

Bloc B3.1 — le socle de tout le programme de sécurité : trois critères pour qualifier un besoin de sécurité, et trois briques pour prouver qui a fait quoi.

1. Le triptyque DIC

Tout besoin de sécurité s'exprime en combinant trois critères. En épreuve, on attend systématiquement que tu relies une mesure technique à l'un d'eux.

CritèreDéfinitionExemple de mesure
Confidentialité Les données ne sont accessibles qu'aux seules personnes autorisées. Authentification par identifiant / mot de passe personnel, droits d'accès, chiffrement.
Disponibilité Les données restent accessibles et utilisables par les personnes autorisées, sans interruption. Redondance des liens réseau, cluster, sauvegardes, PRA / PCA.
Intégrité Les données ne peuvent pas être modifiées pendant leur transfert, leur traitement ou leur stockage. Hachage, signature électronique, TLS / SSL pendant le transport.

Moyen mnémotechnique : DIC. Une même attaque touche souvent plusieurs critères — un ransomware casse la disponibilité (fichiers chiffrés), l'intégrité (données altérées) et souvent la confidentialité (double extorsion avec exfiltration).

2. La preuve et la non-répudiation

La non-répudiation consiste à apporter la preuve irréfutable d'un acte : l'auteur ne peut pas nier l'avoir commis. Elle n'existe pas toute seule, elle est la combinaison de trois éléments.

ÉlémentQuestion à laquelle il répondDéfinition
Authentification Es-tu bien celui que tu prétends être ? Vérifier la légitimité de la demande d'accès et accorder les droits associés (login + mot de passe, clé, biométrie).
Imputabilité À qui attribue-t-on cet acte ? Possibilité d'attribuer la responsabilité d'un acte à une personne clairement identifiée — d'où l'interdiction des comptes génériques partagés.
Traçabilité Que s'est-il passé, et quand ? Historique de l'utilisation du SI, qui fournit la preuve des actions menées sur les données (journaux, logs).

C'est pour cette raison qu'un compte partagé du type admin / admin est une faute : l'authentification fonctionne, mais l'imputabilité disparaît, donc la non-répudiation aussi.

3. Raisonner en DIC sur un incident

Méthode de réponse attendue en étude de cas : pour chaque incident, on qualifie l'impact sur D, I et C, puis on propose une contre-mesure rattachée au critère touché.

IncidentImpact DICContre-mesure
Fuite de la base clientsCChiffrement au repos, cloisonnement réseau, moindre privilège
Site web injoignable (DDoS)DFiltrage amont, anti-DDoS, répartition de charge
Modification d'un log par un attaquantIEmpreinte cryptographique du fichier stockée sur un autre serveur
RansomwareD + I (+ C)Sauvegarde immuable hors-ligne, règle 3-2-1, PRA testé