Bonnes pratiques pour les services de réseau résidentiel fondés sur le consentement

1. Objet

Les services de réseau résidentiel (parfois appelés proxys résidentiels, partage de bande passante ou réseaux d’accès web) acheminent le trafic des clients professionnels à travers des appareils grand public dont les propriétaires ont accepté de participer. Bien mis en œuvre, ce modèle repose sur le consentement éclairé du consommateur d’un côté et sur une vérification rigoureuse des clients de l’autre. Mal mis en œuvre, il expose les consommateurs à une utilisation cachée de leurs ressources et expose l’internet à du trafic abusif.

Le présent document recommande des normes de référence que tout opérateur de ce secteur devrait respecter, sous une forme adaptée à une adoption par les législateurs, les régulateurs et les organismes de normalisation. Il s’articule autour de quatre piliers :

• Consentement et information du consommateur
• Protection des données du consommateur
• Garde-fous techniques au niveau de l’appareil
• Vérification des clients et prévention des abus

Il se conclut par des recommandations sur la manière dont la conformité devrait être testée et gouvernée.

2. Consentement et information du consommateur

Un opérateur ne devrait pas enrôler un appareil sans une décision éclairée, affirmative et réversible de son propriétaire.

Exigences recommandées :

• Adhésion affirmative. L’enrôlement exige une action explicite de l’utilisateur. Aucune case pré-cochée. Aucune intégration silencieuse de la participation dans une installation, une mise à jour ou une fonctionnalité sans rapport.
• Égale visibilité. Les options d’acceptation et de refus sont présentées avec un poids visuel équivalent. Le refus ne doit pas dégrader les fonctionnalités essentielles de l’application hôte au-delà de la suppression d’une éventuelle contrepartie liée à la participation.
• Information au moment de la décision. Avant l’enrôlement, l’utilisateur voit, en langage clair : ce qu’implique la participation, le fait que du trafic tiers sortira par sa connexion, et quelles ressources de l’appareil sont utilisées (bande passante, CPU, électricité).
• Conditions accessibles par lien. Des liens directs vers les conditions de licence et la politique de confidentialité de l’opérateur figurent sur l’écran de consentement lui-même.
• Révocable à tout moment. Retrait en un clic depuis les paramètres de l’appareil ou de l’application, avec effet immédiat.
• Nouveau consentement en cas de changement substantiel. Si la nature de la participation change de manière substantielle, les utilisateurs existants doivent être sollicités à nouveau, et non migrés silencieusement.

Exigences applicables à l’application hôte. Lorsque le réseau est intégré via un SDK dans une application tierce, l’application hôte devrait être tenue de : divulguer l’intégration dans ses propres conditions d’utilisation et son avis de confidentialité, présenter le parcours de consentement complet sans modification, et identifier l’opérateur du réseau par son nom. L’opérateur devrait rester responsable de manière indépendante envers l’utilisateur final, quelle que soit la relation d’intégration, et devrait examiner chaque intégration au regard de ces exigences avant son lancement.

3. Protection des données du consommateur

Exigences recommandées :

• Minimisation des données. Ne collecter que ce que le fonctionnement exige. Éléments appropriés : IP de session, identifiant d’appareil anonyme, localisation approximative (au niveau de la ville), caractéristiques de l’appareil, statistiques de bande passante.
• Collecte interdite. Historique de navigation, utilisation des applications, contenu des fichiers, communications personnelles, localisation GPS précise.
• Plafond de conservation. Les données du côté participant sont purgées selon un calendrier fixe et court (60 jours constituent une référence sectorielle atteignable), les journaux opérationnels n’étant conservés que dans la mesure où les contrôles de sécurité et la loi l’exigent.
• Aucun usage secondaire. Les données des participants ne sont ni vendues ni utilisées à des fins autres que l’exploitation du réseau.

4. Garde-fous techniques au niveau de l’appareil

Une session client ne doit jamais permettre d’atteindre le réseau privé de l’appareil participant, son interface de bouclage ou les points de terminaison de métadonnées cloud. Sans cela, le trafic client pourrait sonder le réseau domestique du participant ou dérober des identifiants à une infrastructure colocalisée.

Exigences recommandées :

• Blocage de la sortie vers les plages privées. Bloquer le trafic client vers le bouclage, les plages privées RFC 1918, les adresses link-local et de métadonnées cloud, l’espace NAT de niveau opérateur, ainsi que leurs équivalents IPv6 (link-local, unique-local).
• Application tenant compte de la résolution. Bloquer une requête si l’une des adresses résolues par DNS relève d’une plage protégée. Valider directement les adresses IP littérales. Désencapsuler et valider les adresses IPv6 mappées en IPv4. Rejeter en cas d’échec de résolution.
• Application côté serveur comme socle. Parce que les logiciels clients déployés se mettent à jour lentement (les cycles des magasins d’applications pour téléviseurs et mobiles peuvent accuser des mois, voire des années de retard), une application côté serveur couvrant l’ensemble du trafic devrait être obligatoire. Le blocage côté client constitue une défense en profondeur précieuse, mais ne peut être le seul contrôle, puisque d’anciens clients restent en circulation.
• Restrictions de ports. Le trafic client est limité aux ports web standard. Les ports de messagerie (SMTP et apparentés) et les ports d’administration à distance (SSH, RDP, SMB, Telnet) sont bloqués au niveau du réseau, car ils permettent le spam, les attaques sur les identifiants et les déplacements latéraux.

5. Contrôles anti-abus en cours d’exécution

La vérification a lieu une fois ; les contrôles anti-abus s’exécutent en continu. Un client approuvé peut néanmoins mal se comporter, être compromis ou se faire dérober ses identifiants. Les opérateurs devraient appliquer des limites en cours d’exécution qui rendent le réseau structurellement résistant aux abus, quel qu’en soit l’utilisateur.

Exigences recommandées :

• Plafonds de débit de bande passante par appareil. Limiter le trafic transporté par tout appareil participant, ce qui protège la connexion du participant et empêche qu’un appareil isolé ne soit transformé en arme.
• Limitation du débit. Des limites de débit de requêtes par client et par session qui rendent les abus volumétriques (participation à un DDoS, bourrage d’identifiants, salves agressives de scraping) irréalisables au niveau du réseau, plutôt que simplement interdits sur le papier.
• Détection des anomalies de trafic. Surveiller les schémas compatibles avec un abus : pics de volume soudains, salves à taux d’erreur élevé contre une cible unique, schémas de requêtes distribuées correspondant à des signatures d’attaque connues.
• Réponse automatisée. Limiter ou suspendre automatiquement la session du client fautif en cas d’anomalie, sans préjudice pour l’appareil participant.
• Coupe-circuit. L’opérateur doit être en mesure d’interrompre immédiatement le trafic par client et par appareil.

6. Vérification des clients et réponse aux abus

Les protections côté consommateur ont peu de valeur si n’importe qui peut acheter un accès de manière anonyme.

Exigences recommandées :

• Connaître son client avant tout accès en production. Une intégration par étapes où l’accès complet au réseau n’est accordé qu’après : vérification de l’identité de la personne physique ou de l’entreprise, examen du cas d’usage au regard d’une politique d’utilisation acceptable publiée, examen des bénéficiaires effectifs pour les profils à risque plus élevé, validation du paiement et contrôle des sanctions (OFAC, EU, UK, UN).
• Niveaux de contrôle renforcé. Examen supplémentaire pour les revendeurs, les secteurs sensibles (services financiers, santé, administration), les expositions juridictionnelles à haut risque et les cas d’usage proches des limites de la politique.
• Utilisations interdites publiées. Au minimum : déni de service, distribution de logiciels malveillants, CSAM (avec signalement obligatoire au NCMEC ou à l’autorité nationale compétente), spam, bourrage d’identifiants, balayage non autorisé et toute activité illicite.
• Application graduée et documentée. Réponse échelonnée selon la gravité, de l’avertissement jusqu’à la résiliation immédiate sans délai de régularisation, avec conservation des preuves et signalement aux forces de l’ordre le cas échéant.
• Responsabilité tout au long de la chaîne contractuelle. Les clients sont contractuellement responsables du comportement de leurs propres utilisateurs en aval, de sorte que la responsabilité subsiste en cas de revente.
• Procédure applicable aux forces de l’ordre. Réception documentée avec examen de la validité, de la compétence et de la portée ; production strictement circonscrite ; notification du participant et du client lorsque la loi le permet.

7. Comment la conformité devrait être testée et gouvernée

Pour les organismes de normalisation et les schémas de certification, la manière dont une norme est testée importe autant que ce qu’elle exige. Principes recommandés :

• Tests fondés sur les résultats et neutres quant à la mise en œuvre. Apprécier la conformité selon que le résultat interdit peut effectivement se produire (par exemple : une requête vers une plage privée bloquée peut-elle réellement sortir d’un appareil participant), et non selon le mécanisme qui l’empêche. Des critères imposant un mécanisme précis permettent à l’architecture d’un opérateur de devenir la norme.
• Tests reproductibles, et non listes commerciales. La conformité est mesurée au moyen du test documenté et reproductible propre au schéma. Jamais par l’inscription sur une liste de blocage ou un flux de réputation contrôlé par un acteur du marché.
• Procédure contradictoire avant toute conclusion défavorable. Notification préalable à la publication, fenêtre de commentaires et droit à un nouveau test. Aucune inscription défavorable sur la base d’un résultat contesté avant l’épuisement des voies de recours.
• Gouvernance neutre des listes. Tout critère ou toute liste de blocage est détenu de manière neutre, versionné, et assorti d’un processus documenté de contestation par les opérateurs. Aucun acteur unique ni fournisseur de détection ne l’administre.
• Divulgation des conflits et récusation. Tout acteur qui vend des services concurrents de détection ou de notation, ou qui est en litige actif avec un autre acteur, divulgue le conflit et se récuse de tout jugement portant sur cette partie.

8. Liste de contrôle récapitulative