Déni de service

Déni de service : Attaque visant la disponibilité plutôt que les données, traitée par la répartition de charge et par un filtrage placé en amont.

Cette entrée du glossaire relève de la famille « Sécurité ». Elle donne la définition, sa traduction en exigences, et les erreurs vues le plus souvent sur des projets réels.

Où intervient Déni de service dans un projet

Déni de service figure dans les référentiels utilisés par les auditeurs. Un client grand compte le vérifiera avant de signer, un prestataire sérieux l’a déjà prévu.

Sur un projet réel, la question ne se pose jamais en théorie : elle arrive dans un devis, dans une réunion de cadrage ou dans un rapport de recette.

Comment l’écrire dans un cahier des charges

Dans un cahier des charges, Déni de service s’écrit en exigence vérifiable, avec le référentiel appliqué et le moment où le contrôle aura lieu.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Les modalités d’authentification, second facteur compris s’il est requis.
• Le stockage des secrets, côté application comme côté serveur.
• La gestion des accès de production, et leur revue périodique.
• Le test de restauration des sauvegardes, réellement exécuté au moins une fois.

Reste à désigner qui écrit cette ligne et qui la valide. Sans nom en face, la rubrique se remplit la veille de la signature, avec les mots du prestataire.

Pour le cadre général, le guide des prix donne les fourchettes constatées en France et le modèle de cahier des charges la structure qui les rend opposables.

Les contrôles à prévoir

Déni de service se recette avant la mise en ligne, puis se revérifie après les corrections. Un correctif non retesté n’est pas un correctif.

• Contrôler qu’aucun secret ne traîne dans le code livré.
• S’assurer que les journaux ne contiennent aucune donnée personnelle.
• Réclamer la preuve d’un test de restauration de sauvegarde.

Ce qui n’est pas vérifié à la recette ne sera pas vérifié du tout : le jour de la mise en ligne, plus personne n’a le temps.

Erreurs fréquentes

Sur ce point précis, voici ce qui coûte le plus cher aux porteurs de projet, dans l’ordre où on le rencontre.

• Traiter la sécurité en fin de projet, quand tout est déjà recetté.
• Stocker un secret dans le code de l’application, où il est lisible par qui veut le lire.
• Commander un audit sans budgéter les corrections qu’il va produire.
• Laisser les accès de production ouverts à d’anciens intervenants.
• Confier la décision au prestataire, puis la contester au moment de la recette.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• Conformité continue
• EBIOS Risk Manager
• Gestionnaire de mots de passe
• Tableau de bord sécurité
• OpenID Connect

Questions fréquentes

Déni de service : de quoi parle-t-on exactement ?

Attaque visant la disponibilité plutôt que les données, traitée par la répartition de charge et par un filtrage placé en amont. La définition tient en une phrase, son application dépend du projet. C’est pour cette raison qu’elle doit figurer dans le cahier des charges plutôt que dans un échange de courriels.

À quel moment traiter le sujet ?

Dès la conception, puis en contrôle avant la mise en ligne. Une faille corrigée sur plan coûte une discussion ; la même faille corrigée après le lancement coûte un correctif, une republication et parfois une notification.

Où placer ce point dans le cahier des charges ?

Dans le chapitre qui correspond à sa nature, jamais dans une ligne fourre-tout. Le modèle de cahier des charges propose les rubriques attendues et l’ordre dans lequel les remplir.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.