Opérations Pratique
Modélisation des menaces pour une petite plateforme
Qui pourrait réellement s’en prendre à votre service, dans quel ordre, et lesquels un choix d’hébergement affecte réellement. La plupart, non — et le savoir est tout l’intérêt de l’exercice.
13 min de lecture Publié le 2 mai 2026 Vérifié il y a 1 mois
La modélisation des menaces a la réputation d’être un rituel d’entreprise avec des schémas que personne ne lit. Cela n’a pas à être le cas. Pour une petite plateforme, la version utile prend une heure, produit une liste classée, et son principal résultat est de savoir quels risques vos choix d’infrastructure affectent réellement — car pour la plupart d’entre eux, la réponse honnête est : aucun.
L’ordre compte plus que l’exhaustivité
L’erreur classique consiste à dresser une longue liste de tout ce qui pourrait mal tourner, en traitant chaque point comme également urgent. Cela produit de la paralysie, puis une décision prise au feeling de toute façon. Une liste classée de sept éléments vaut mieux qu’une liste exhaustive de quarante, parce que vous agirez de toute façon sur les trois premiers et n’atteindrez jamais les autres.
Classez par probabilité × coût pour vous, et non selon le caractère alarmant du scénario. Un adversaire étatique est l’élément le plus effrayant de n’importe quelle liste et, pour presque toutes les petites plateformes, le moins probable — alors qu’une fuite d’identifiants venant d’un ancien prestataire est terne, extrêmement courante, et généralement catastrophique.
Sept adversaires, classés par probabilité
| Adversaire | Probabilité | L’hébergement aide | Ce qui l’atténue réellement |
|---|---|---|---|
| Vous, un mauvais jour | Certaine | Non | Des sauvegardes que vous avez réellement testées en restauration, et un processus de changement pour tout ce qui touche à l’authentification ou au DNS. La cause la plus probable de votre pire panne, c’est vous. |
| Scan automatisé | Constante | Non | Des correctifs appliqués, pas d’authentification par mot de passe, pas d’identifiants par défaut. C’est du bruit de fond ; ce n’est pas dirigé contre vous et cela ne s’arrête jamais. |
| Compromission d’identifiants | Élevée | Non | Une double authentification matérielle, des jetons API à portée limitée, et la révocation des accès le jour du départ de quelqu’un plutôt que le trimestre suivant. |
| Un plaignant muni d’un formulaire | Élevée | Oui | C’est le seul cas que la juridiction d’hébergement affecte réellement : si une simple correspondance suffit à faire tomber votre service. |
| Attaque volumétrique | Moyenne | Partiellement | Un filtrage en amont, et plus précisément un fournisseur qui filtre plutôt que de vous mettre en null-route pour se protéger lui-même. |
| Un intrus ciblé | Faible | Non | La segmentation, le moindre privilège, le chiffrement des données au repos, et des journaux stockés là où l’intrus ne peut pas les modifier. |
| Un acteur étatique | Très faible | Partiellement | La juridiction détermine la voie légale, pas la voie technique. Si ce scénario fait vraiment partie de votre modèle, cherchez un conseil juridique plutôt qu’une offre d’hébergement. |
Lesquels un choix d’hébergement affecte
Deux sur sept, et partiellement un troisième. Ce ratio est à lui seul le résultat le plus utile de l’exercice, et c’est pourquoi le faire avant de choisir un fournisseur permet d’économiser plus d’argent que n’importe quel tableau comparatif.
Ce que l’hébergement change réellement : si une plainte peut faire tomber votre service sans passer par un tribunal, et combien de parties distinctes sont en mesure de vous résilier pour des raisons que vous ne verrez jamais.
Ce que l’hébergement change partiellement : la façon dont une attaque volumétrique est gérée — filtrée en amont, ou mise en null-route pour protéger les autres clients du fournisseur. Demandez lequel des deux, par écrit, car ces deux mots sont souvent employés l’un pour l’autre alors qu’ils signifient l’exact inverse pour vous.
Ce que l’hébergement ne change en rien : vos propres erreurs, le scan, la compromission d’identifiants, ou un intrus déjà présent à l’intérieur. Quatre des sept, dont les trois premiers.
La version en une heure
- Listez ce que vous détenez réellement (10 min). Pas des systèmes — des données. Adresses e-mail des utilisateurs, données de paiement, messages privés, fichiers déposés, identifiants d’accès à d’autres services. Notez ce qui serait le pire à perdre et ce qui serait le pire à voir fuiter ; ce n’est rarement la même chose.
- Listez qui voudrait chaque chose (10 min). Soyez précis. « Des hackers » n’est pas un adversaire ; « quelqu’un qui achète des lots d’identifiants pour revendre des comptes » en est un, et cela implique des défenses différentes.
- Classez par probabilité × coût (10 min). Ignorez le caractère dramatique de chaque scénario. Ce sont les plus ternes qui dominent.
- Pour les trois premiers, écrivez la première heure (20 min). Ce que vous feriez durant les soixante premières minutes de chacun. Si vous ne pouvez pas répondre, voilà le vrai résultat — et il vaut plus que le classement lui-même.
- Repérez lesquels sont affectés par les choix d’infrastructure (10 min). En général deux des cinq premiers. Vous savez maintenant ce que votre choix d’hébergement achète réellement.
Recommencez lorsque quelque chose de structurel change — un nouveau type de donnée, une nouvelle intégration, un départ — plutôt qu’à échéance fixe. Les révisions programmées au calendrier finissent sautées ; celles déclenchées par un événement se font, parce qu’il y a une raison concrète devant vous.
Trois erreurs qui rendent tout l’exercice inutile
Modéliser l’adversaire qui vous intéresse. Les capacités d’un État sont plus amusantes à imaginer qu’un jeton API qui a fuité dans un dépôt public. L’un des deux est arrivé à presque tous ceux que vous connaissez. Classez honnêtement et ce sont les éléments les plus ennuyeux qui l’emportent — c’est bien tout l’intérêt.
Confondre une mesure avec un résultat. « Nous utilisons le chiffrement » n’est pas une atténuation tant que vous ne pouvez pas dire ce que cela bloque et ce que cela ne bloque pas. Le chiffrement intégral du disque sur un serveur en fonctionnement protège contre un disque qui quitte le bâtiment ; il ne fait rien contre un intrus disposant d’un shell sur la machine en cours d’exécution, parce que le volume est déjà déverrouillé.
Produire un document plutôt qu’une décision. Si rien n’a changé après l’exercice — aucune permission révoquée, aucune sauvegarde testée, aucune question posée au fournisseur —, ce n’était pas une modélisation des menaces, c’était un après-midi. Le résultat attendu, ce sont trois actions, chacune assignée à un nom.
Si la ligne du plaignant est celle qui domine votre tableau, la question suivante est celle de la juridiction et de la façon de vérifier ce qu’un fournisseur en affirme — six questions, à répondre en un après-midi. Si elle n’apparaît même pas parmi vos cinq premiers, vous n’avez probablement pas besoin de nous, et c’est un excellent résultat pour une heure de travail.
Rédigé par les ingénieurs qui exploitent la plateforme, et relu il y a 1 mois. Si quelque chose ici est faux ou obsolète, dites-le depuis le panel — c’est de là que vient environ la moitié de ces pages.
