Cadre légal : ce qui est permis et ce qui est interdit

Tout ce que vous avez appris dans ce cours, de l'analyse de paquets à la ligne de commande Linux, peut servir à protéger un système ou à lui nuire. Ce qui sépare un professionnel de la sécurité d'un délinquant n'est pas la technique : c'est l'autorisation. Cette leçon pose le cadre juridique avant d'aborder la méthode, car un test d'intrusion sans autorisation n'est pas un test, c'est une infraction.

Cette leçon présente des repères généraux en droit français et international, à but pédagogique. Elle ne remplace ni un conseil juridique ni la lecture des textes eux-mêmes, que vous trouverez sur Légifrance. Les textes évoluent, vérifiez toujours la version en vigueur, notamment pour les peines encourues, que nous ne détaillerons volontairement pas ici.

Le principe : sans autorisation, c'est interdit

La règle est simple et sans exception pour un débutant : vous ne testez que ce qui vous appartient ou ce pour quoi vous avez une autorisation écrite, claire et préalable. « Je voulais seulement voir si c'était possible », « je n'ai rien cassé », « j'allais prévenir le propriétaire » ne sont pas des justifications recevables. Vous l'avez déjà rencontré dans le laboratoire : on travaille sur ses propres machines virtuelles, dans un réseau isolé, ou sur des plateformes conçues pour cela.

Les infractions du Code pénal (articles 323-1 et suivants)

En France, les atteintes aux systèmes de traitement automatisé de données (STAD) sont regroupées dans le chapitre III du titre II du livre III du Code pénal. Un « STAD » désigne très largement un ordinateur, un serveur, un site web, un réseau, un téléphone ou un objet connecté. Les principaux articles à connaître :

Deux points méritent votre attention. D'abord, la tentative est punie : il n'est pas nécessaire d'avoir réussi à entrer. Ensuite, l'article 323-1 ne suppose pas un « piratage sophistiqué » : utiliser un mot de passe trouvé, deviner un identifiant ou explorer une partie d'un site qu'on sait non destinée au public peut suffire, si l'on sait que l'accès n'est pas autorisé. Le caractère frauduleux tient à l'absence d'autorisation et à la conscience de cette absence.

Le « motif légitime » de l'article 323-3-1

L'article 323-3-1 pourrait sembler interdire de détenir des outils de sécurité courants. Il prévoit justement une exception pour le motif légitime, notamment de recherche ou de sécurité informatique. Ce motif est apprécié au cas par cas : un étudiant qui installe Kali Linux dans un laboratoire personnel, un auditeur mandaté, un chercheur travaillant sur ses propres systèmes ont un motif légitime. Cela ne vaut pas blanc-seing pour utiliser ces outils contre des tiers. D'où l'importance de pouvoir documenter ce que vous faites : votre carnet de laboratoire, dont nous avons parlé au chapitre 3, est aussi un élément de preuve de votre bonne foi.

Ce que signifie « avoir l'autorisation »

Dans la pratique professionnelle, une autorisation valable est :

• Écrite : un contrat ou une lettre de mission, jamais un accord oral ni un message informel.
• Signée par une personne habilitée à engager l'organisation propriétaire du système.
• Précise sur le périmètre : quelles adresses IP, quels domaines, quelles applications, quels environnements (production ou préproduction).
• Précise sur les méthodes : ce qui est autorisé (analyse de vulnérabilités, tentatives d'exploitation, ingénierie sociale) et ce qui est exclu (déni de service, destruction de données, accès à des données personnelles réelles).
• Datée : avec une période de validité et des horaires d'intervention.
• Assortie de contacts d'urgence : qui prévenir si le test provoque un incident.

Cet ensemble forme les règles d'engagement (rules of engagement). Elles protègent les deux parties : le client sait ce qui va se passer, le testeur est couvert pour ce qu'il fait dans le cadre convenu et seulement dans ce cadre.

Responsabilité et données personnelles

Même avec une autorisation, une mission de sécurité touche souvent des données personnelles. Le RGPD s'applique : les données rencontrées doivent être traitées avec précaution, limitées au strict nécessaire, protégées et supprimées à la fin selon le contrat. Un professionnel signe en général un accord de confidentialité, et il ne copie pas de données réelles hors du périmètre convenu. Une preuve d'accès se démontre par une capture d'écran minimale, pas en emportant la base de clients.

Que faire quand on découvre une faille par hasard ?

Cela peut vous arriver : un lien qui affiche des documents qui ne devraient pas l'être, une erreur qui révèle une configuration. Ce qu'il faut savoir :

• Arrêtez-vous. Ne cherchez pas à voir « jusqu'où ça va », ne téléchargez rien, ne rédigez pas de test supplémentaire.
• Notez ce que vous avez constaté : l'adresse, l'heure, ce que vous faisiez.
• Signalez de façon responsable à l'organisation concernée par ses canaux officiels (page de contact sécurité, adresse dédiée, programme de divulgation).
• Vous pouvez aussi signaler une vulnérabilité à l'ANSSI ; la loi prévoit des dispositions protectrices pour le signalement de bonne foi d'une vulnérabilité qui a été découverte (article L2321-4 du code de la défense, à consulter sur Légifrance). Les ressources de cyber.gouv.fr expliquent les démarches.

La divulgation coordonnée consiste à informer l'éditeur ou le propriétaire en privé, lui laisser un délai raisonnable pour corriger, puis éventuellement publier. Certaines organisations publient une politique de divulgation, voire un programme de bug bounty qui autorise explicitement certains tests sous conditions ; dans ce cas, l'autorisation est celle du programme, et vous devez en respecter le périmètre à la lettre. Un signalement de bonne foi ne vous garantit pas l'absence de poursuites si vous avez dépassé les limites : d'où le conseil de ne rien faire de plus que constater.

Et en dehors de la France ?

Internet n'a pas de frontières, les lois si. Quelques repères :

• La Convention de Budapest du Conseil de l'Europe sur la cybercriminalité, signée par de nombreux pays, harmonise la définition des infractions informatiques.
• La directive européenne 2013/40/UE relative aux attaques contre les systèmes d'information rapproche les législations des États membres.
• Aux États-Unis, le Computer Fraud and Abuse Act (CFAA) ; au Royaume-Uni, le Computer Misuse Act. Tester un système situé à l'étranger depuis la France peut vous exposer à plusieurs droits à la fois.

La conséquence pratique est la même partout : un contrat clair, un périmètre précis, la preuve de l'autorisation.

Les règles de conduite d'un professionnel

1. Pas d'autorisation, pas de test.
2. Rester dans le périmètre et la fenêtre horaire convenus.
3. Réduire l'impact : éviter les actions destructrices, tester d'abord en préproduction quand c'est possible.
4. Protéger toute donnée rencontrée et ne rien conserver au-delà du nécessaire.
5. Signaler immédiatement tout incident ou toute découverte critique au client.
6. Garder une trace de chaque action, avec l'heure et la commande.
7. Ne jamais utiliser ce qu'on découvre à son propre avantage.

À vous de jouer

1. Classez chaque situation en « autorisé » ou « interdit » et justifiez : (a) lancer un scan sur votre machine virtuelle cible ; (b) scanner le site de votre établissement « pour voir » ; (c) tester une application sur une plateforme d'entraînement dont les règles l'autorisent ; (d) lancer un test sur le site d'un ami, qui est d'accord oralement ; (e) conserver un outil d'analyse réseau dans votre laboratoire personnel.
2. Rédigez, en cinq lignes, les éléments minimaux d'une lettre d'autorisation pour tester le site d'une association fictive.
3. Imaginez que vous trouvez, en navigant, un dossier de documents internes accessible sans mot de passe. Listez dans l'ordre les trois premières actions à mener.

Maintenant que le cadre est clair, voyons comment les professionnels structurent concrètement un test d'intrusion.