2026-07-15 · PRACTICE · L'équipe d'Offensive Technology

Pourquoi chaque mission commence par une signature

Il n'y a exactement qu'une chose qui sépare un test d'intrusion d'un crime informatique, et ce ne sont ni les compétences, ni les outils, ni l'intention. C'est l'autorisation. La même commande exécutée contre le même serveur est une prestation professionnelle le mardi et un délit pénal le mercredi, et la seule différence est un bout de papier.

Donc avant de toucher à quoi que ce soit, nous réglons cette question de papier. Voici ce que cela signifie réellement en pratique, et pourquoi nous ne faisons pas d'impasse, même lorsqu'un client est pressé.

Propriété avant accès

La première question n'est pas « que voulez-vous tester », c'est « pouvez-vous prouver que vous le contrôlez ». N'importe qui peut taper un domaine dans un formulaire. Cela ne signifie pas qu'il lui appartient, et si ce n'est pas le cas, le tester nous place tous les deux du mauvais côté de la loi.

Nous vérifions donc. En général, cela signifie que vous placez un jeton dans un enregistrement DNS que nous pouvons lire, ou que vous confirmez depuis une adresse e-mail du domaine lui-même. Cela prend quelques minutes et ce n'est pas négociable. Si vous ne pouvez pas prouver le contrôle de la cible, il n'y a pas de mission possible.

Nous ne nous en remettons pas non plus à une simple signature. Nous exigeons une autorisation écrite d'une personne désignée et voulons toujours la preuve technique sous-jacente, car une signature sur le mauvais en-tête de lettre est précisément ce qui amène un auditeur à cibler le mauvais système.

Le périmètre est une clôture, pas une suggestion

Une fois la propriété établie, nous consignons exactement ce qui est inclus et ce qui ne l'est pas : quels hôtes, quelles applications, quelles techniques, et lesquelles sont explicitement exclues. Ce document constitue la clôture. Nous restons à l'intérieur, même si quelque chose d'intéressant est clairement accessible juste à côté.

• Les actifs que nous sommes autorisés à toucher, nommément listés.
• Les techniques que vous avez approuvées, et celles que vous avez exclues.
• Les plages horaires, pour que les tests ne surprennent jamais votre équipe ni vos clients.
• Un contact désigné capable de tout interrompre d'un seul message.

Ce même document tranche deux points que l'on oublie jusqu'à ce qu'ils deviennent critiques. Premièrement, l'environnement : testons-nous la production, où une requête lourde peut impacter de vrais clients, ou une copie de préproduction qui la reproduit ? Les deux choix sont valables, mais ce choix doit être délibéré et non découvert en plein test. Deuxièmement, la condition d'arrêt : qui peut ordonner une interruption, comment nous joindre, et qu'advient-il des accès déjà obtenus si c'est le cas. Il s'agit d'un accord préalable signé, pas d'une entente informelle. Quand c'est bien fait, personne n'a besoin d'improviser sous la pression.

Quand la cible ne vous appartient pas entièrement

Être propriétaire d'un nom de domaine ne revient pas à posséder tout ce vers quoi il pointe, et c'est là que les définitions de périmètre pourtant bien intentionnées dérapent. Un exemple classique : un client indique que app.clientco.com est dans le périmètre. Nous vérifions et constatons qu'il s'agit d'un CNAME vers une plateforme SaaS tierce à laquelle le client est abonné mais qu'il n'administre pas. Il contrôle le nom DNS ; il ne contrôle pas les serveurs sous-jacents. Tester cet hôte revient à tester le fournisseur, qui n'a rien accepté. L'hôte est donc exclu du périmètre, ou le client obtient au préalable une autorisation écrite du fournisseur.

La même prudence s'applique aux actifs sur hébergement mutualisé ou derrière un CDN partagé, où une seule adresse IP peut desservir des milliers de clients distincts, ainsi qu'à un domaine acquis lors d'une transaction dont les enregistrements pointent encore vers l'infrastructure du vendeur. Les grands fournisseurs cloud publient également leurs propres politiques de test autorisés, et certaines activités, comme le déni de service et les tests de charge en particulier, nécessitent toujours une notification ou une approbation préalable, même sur des ressources qui vous appartiennent. Démêler ce qui vous appartient réellement fait partie de la cartographie de la surface d'attaque externe, et cela se fait avant tout test, pas pendant.

Le cadre légal derrière la frontière

La raison pour laquelle nous sommes inflexibles à ce sujet ne relève pas d'une simple politique interne. La plupart des pays considèrent l'accès non autorisé à un système informatique comme une infraction pénale en soi. Aux États-Unis, il s'agit du Computer Fraud and Abuse Act ; au Royaume-Uni, du Computer Misuse Act 1990 ; dans l'Union européenne, les États membres incriminent l'accès illégal en vertu de lois nationales transposant la directive européenne relative aux attaques contre les systèmes d'information. Les détails varient selon la juridiction, mais le fil conducteur reste le même : l'accès sans l'autorisation du propriétaire constitue l'infraction, et une intention bienveillante ne constitue pas un moyen de défense. Il ne s'agit pas d'un conseil juridique, et votre propre conseil juridique est la personne compétente pour examiner le texte de loi qui s'applique à votre situation. C'est simplement la raison pour laquelle aucune requête n'est envoyée tant que l'autorisation et la propriété ne sont pas établies.

Pourquoi nous sommes stricts sur la partie rébarbative

Les clients perçoivent parfois cela comme de la bureaucratie. C'est tout l'inverse. Une autorisation rigoureuse est précisément ce qui nous permet d'être incisifs à l'intérieur du périmètre sans que quiconque n'ait à s'inquiéter. Lorsque les limites sont rédigées et signées, nous pouvons enchaîner les attaques de manière offensive et prouver un impact réel, parce que tout le monde s'est déjà mis d'accord sur le tracé du périmètre.

Les équipes qui se font piéger sont celles qui ont traité le périmètre comme une simple formalité. Nous le traitons comme la fondation, parce que c'en est une.

Autorisation d'abord : réponses rapides

Ai-je besoin d'une autorisation écrite pour tester des systèmes qui m'appartiennent déjà ?

En pratique, oui. L'autorisation écrite prouve que votre propre équipe a approuvé le test, ce qui vous protège en interne, tout en protégeant l'opérateur qui l'exécute. Si une partie de l'environnement repose sur une infrastructure que vous ne contrôlez pas totalement, comme une plateforme cloud ou un produit SaaS hébergé, vous aurez peut-être également besoin de l'autorisation de ce fournisseur. Obtenez tout par écrit avant que le moindre test ne soit lancé.

Qu'est-ce qu'un document de règles d'engagement ?

C'est l'accord écrit qui définit le test : les cibles exactes dans le périmètre, les techniques autorisées et interdites, la plage horaire des tests, les contacts désignés des deux côtés, et les conditions d'interruption des tests. Il transforme un vague « testez-nous » en un cadre engageant pour les deux parties.

Est-il illégal de scanner un site web qui ne m'appartient pas ?

Cela peut l'être. De nombreuses juridictions incriminent l'accès non autorisé aux systèmes informatiques, et la limite entre un simple scan et un accès n'est pas toujours celle que l'on croit. Sans autorisation et sans preuve que vous contrôlez la cible, ne lancez rien contre elle. Il ne s'agit pas d'un conseil juridique ; consultez un avocat qualifié pour votre juridiction.

Comment confirmez-vous que je suis propriétaire d'une cible avant de la tester ?

Généralement via un enregistrement que nous vous demandons de publier dans le DNS de la cible, ou une réponse depuis une boîte mail du domaine lui-même. Les deux prouvent le contrôle d'une manière qu'un formulaire web ne permet pas. Tant que cette vérification n'est pas validée, aucune mission n'est engagée.

Sur le même sujet

• Contrôle, scan ou pentest complet ?
• Comment préparer votre premier test d'intrusion
• Ce que prouvent réellement les certifications OSCP, OSEP et CRTO