Anti-DDoS

Anti-DDoS : Dispositif absorbant un afflux de requêtes destiné à rendre le service indisponible, généralement fourni en amont par l’hébergeur.

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.

À quoi sert Anti-DDoS

Sur un projet d’application, Anti-DDoS se traite pendant la conception. Ajouter la sécurité à la fin revient à réécrire des parties déjà recettées, donc à les recetter de nouveau.

Ce que le mot recouvre exactement dépend du projet. Ce qui suit vaut pour la plupart des applications mobiles françaises, et sert de point de départ à la discussion.

De la définition à la ligne de cahier des charges

Le cahier des charges doit prévoir qui teste « Anti-DDoS » et à quel moment. Une revue de sécurité programmée après la mise en ligne arrive trop tard pour changer quoi que ce soit.

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

• Le référentiel de sécurité appliqué, nommé dans le contrat.
• Le classement des données manipulées, de la plus banale à la plus sensible.
• La revue de sécurité prévue avant la mise en ligne, et qui la mène.
• La procédure de correction d’une faille signalée, avec son délai d’engagement.

Rien n’oblige à tout figer dès le premier jour. Ce qui reste ouvert doit alors être signalé comme tel, avec la date à laquelle la décision sera prise.

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.

Comment le vérifier à la recette

Anti-DDoS se recette avant la mise en ligne, puis se revérifie après les corrections. Un correctif non retesté n’est pas un correctif.

• Demander le rapport d’audit complet, pas la seule page de synthèse.
• Vérifier que les correctifs annoncés ont été retestés, et par qui.
• Vérifier que les contrôles d’accès sont bien refaits côté serveur.

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.

Les pièges à éviter

Les mêmes causes reviennent d’un projet à l’autre, quel que soit le prestataire et quelle que soit la taille du budget.

• Faire confiance aux contrôles réalisés dans l’application sans les refaire côté serveur.
• Journaliser des données sensibles pour faciliter le débogage, puis oublier de retirer les traces.
• Protéger l’application et négliger les interfaces qu’elle appelle.
• Considérer qu’une application sans données bancaires n’intéresse aucun attaquant.
• Reprendre la formulation d’un autre projet sans vérifier qu’elle décrit bien celui-ci.

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

Anti-DDoS : de quoi parle-t-on exactement ?

Dispositif absorbant un afflux de requêtes destiné à rendre le service indisponible, généralement fourni en amont par l’hébergeur. 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.

Est-ce que ça se retrouve dans le devis ?

Un devis lisible sépare conception, design, développement, tests, publication et suivi. La grille de lecture des devis détaille poste par poste ce qui doit y apparaître.

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