Sécurisez l'application et son accès administratif, limitez l'écouteur backend, protégez les clés du service onion et testez la publication via un client compatible. Le routage onion est une couche de la conception. Il n'élimine pas les vulnérabilités applicatives, les erreurs dans le contenu publié ni la nécessité de définir qui doit avoir accès.
Définissez la publication et son public
Commencez par un objectif de publication licite et une description du public. Une publication de recherche publique et un portail de projet restreint ont des exigences d'accès différentes. Décidez quel contenu est destiné à être public, lequel nécessite une authentification applicative et lequel ne doit jamais atteindre la racine web. Gardez ces décisions distinctes du transport utilisé pour atteindre le site.
Rédigez un petit inventaire des données avant le déploiement : pages, fichiers téléversés, contenu de la base de données, comptes administrateur et configuration des services. Désignez un responsable pour les mises à jour et la gestion des incidents. Le fait qu'un site utilise une adresse onion ne règle pas les questions de conservation, de droits sur le contenu ou de responsabilités en matière de sécurité. Ces décisions restent des choix pratiques d'application qui nécessitent un plan d'exploitation explicite.
Gardez un écouteur backend délibéré
Un service onion associe une connexion à un point de terminaison d'application local. Vérifiez où ce point de terminaison écoute et quels autres réseaux peuvent l'atteindre. Le guide d'installation du Tor Project décrit les sockets Unix comme un moyen utile d'éviter d'exposer le backend à un réseau local. Choisissez une approche prise en charge par votre serveur et vérifiez sa joignabilité réelle.
Une connexion qui fonctionne via Tor peut coexister avec un écouteur public non intentionnel. Testez à la fois le chemin d'accès prévu et les limites autour du backend. Évitez les hypothèses de configuration génériques ; lisez les paramètres d'écoute de l'application et le routage des hôtes virtuels du serveur web. Gardez les interfaces de gestion distinctes du service destiné au public et limitez qui peut modifier ces paramètres.
Examinez ce que l'application publie
Inspectez les pages, les fichiers téléversés, les sorties d'erreur et les ressources intégrées comme un lecteur les rencontrerait. Une application peut révéler des détails opérationnels via des messages de débogage ou des liens vers des ressources externes sans que cela soit évident dans sa conception principale. Examinez les URL générées et les métadonnées de contenu. Ne servez que les ressources nécessaires à la publication et comprenez toute requête tierce qu'elle initie.
Pour un site de recherche illustratif, examinez un exemple d'article, de pièce jointe et de page de contact avant le lancement. Vérifiez qu'un document éditorial privé et un fichier d'environnement se trouvent en dehors du répertoire public. Utilisez du matériel de test non sensible pour vérifier les téléversements. Une connexion onion réussie prouve la joignabilité ; cet examen du contenu vérifie ce que le service divulgue réellement à son audience.
Traitez l'identité du service comme un élément protégé
La configuration du service onion inclut du matériel de clé qui doit rester privé. Gardez-le en dehors des fichiers publics du site web et limitez l'accès aux opérateurs qui en ont besoin. Planifiez comment une récupération légitime préserve l'identité de service prévue et comment une compromission serait gérée. Ne placez pas les clés de service dans une archive publique, un message d'assistance ou un dépôt de projet partagé.
Incluez l'application, les données et la configuration de service requise dans la conception de la récupération, avec une protection appropriée pour chacun. Une sauvegarde du contenu du site seule peut ne pas restaurer l'adresse prévue, tandis qu'une copie contenant des clés privées crée une sauvegarde sensible. Documentez qui peut la déchiffrer et la restaurer, et testez cet accès sans exposer les clés dans les rapports d'exercice.
Choisissez explicitement un accès public ou restreint
L'authentification à l'application et l'autorisation du client Tor sont des couches différentes. Le Tor Project documente l'autorisation client pour faire dépendre l'accès à un service onion v3 d'un identifiant client. Décidez si ce modèle correspond à l'audience et au processus opérationnel. Il n'est pas automatiquement nécessaire pour une publication publique et ne remplace pas les permissions de l'application une fois qu'un client se connecte.
Considérez un portail de projet avec un petit groupe approuvé. Vous avez besoin d'un moyen de distribuer, remplacer et révoquer le matériel d'accès en privé, ainsi que de gérer les comptes d'application. Testez séparément la suppression d'un client autorisé et d'un utilisateur d'application. Le tableau suivant maintient ces contrôles distincts au lieu de promettre qu'un seul paramètre résout tous les problèmes d'accès.
| Contrôle | Question à laquelle il répond | Responsabilité distincte |
|---|---|---|
| Écouteur backend | Qui peut atteindre le point de terminaison de l'application locale ? | Configuration du serveur web et du réseau |
| Autorisation client | Quels clients peuvent se connecter au service onion ? | Distribution et révocation des identifiants privés |
| Permissions de l'application | Que peut faire un utilisateur connecté ? | Rôles de compte et accès aux données |
| Revue de publication | Que divulgue le site ? | Contenu, téléversements et gestion des erreurs |
Testez via la connexion du lecteur
Utilisez un client compatible pour tester les pages, la navigation, les formulaires et les téléchargements via le chemin d'accès onion prévu. Observez les erreurs et l'utilisation des ressources de l'application avec un trafic de test inoffensif. Évitez de mesurer uniquement une requête backend locale, car cela n'exerce pas la connexion complète du lecteur. Gardez les comptes de test et tout identifiant à accès restreint privés.
Vérifiez également les procédures de récupération et de maintenance. Une mise à jour d'application doit avoir un point de restauration et un moyen de valider la route onion par la suite. Définissez des journaux opérationnels utiles et une conservation sans supposer qu'une étiquette de distribution ou de transport crée une politique de zéro journal. Conservez suffisamment de preuves pour diagnostiquer les pannes tout en évitant une collecte inutile.
Lisez les options d'hébergement comme des parties de la conception
SwissOctet Veil liste les choix de pile applicative, d'adresse onion et de sauvegarde. Sélectionnez la pile attendue par votre logiciel et suffisamment de CPU, de mémoire et de stockage pour la charge de travail. Confirmez comment le service réel gère le déploiement, l'identité de service et la restauration avant de vous y fier. La localisation suisse du catalogue est distincte du comportement de confidentialité de votre application.
Gardez le service destiné à une publication légitime et à des utilisateurs autorisés. Planifiez les mises à jour des administrateurs, les revues d'accès et une réponse aux identifiants d'application compromis. Une publication onion fonctionne mieux lorsque le contenu, l'exposition du backend et la récupération sont compréhensibles ; le transport doit soutenir ce plan plutôt que devenir une excuse pour ignorer la sécurité logicielle ordinaire.
Votre liste de contrôle pratique.
- Définissez le contenu public et restreint avant le déploiement.
- Vérifiez l'exposition réelle de l'écouteur backend.
- Examinez les pages, les téléversements et les requêtes de ressources externes.
- Protégez et testez la récupération du matériel de clé de service.
- Séparez l'autorisation client des rôles d'application.
- Testez la maintenance et les parcours de lecteur via le chemin onion.
Les détails qui comptent.
L'hébergement onion rend-il une application anonyme à lui seul ?+
Non. Le contenu publié, la configuration, les comptes et les pratiques opérationnelles peuvent révéler des informations. Examinez l'ensemble du service plutôt que de vous fier à la méthode de connexion.
Chaque site onion doit-il utiliser l'autorisation client ?+
Non. Décidez en fonction de l'audience prévue. L'autorisation client restreint l'accès à la connexion et ajoute un cycle de vie des identifiants ; les permissions d'application restent distinctes.
Que dois-je protéger dans une copie de récupération ?+
Les données du site et la configuration nécessitent des contrôles d'accès appropriés. Tout matériel de clé de service inclus est particulièrement sensible et doit rester privé pendant le stockage et la restauration.
Allez à la source.
Ces références soutiennent les concepts techniques de ce guide. Suivez la documentation actuelle avant de modifier un système de production.
- Tor Project : Configurer votre service onion community.torproject.org
- Tor Project : Paramètres avancés du service onion community.torproject.org
- Tor Project : Autorisation client community.torproject.org
Conseils éditoriaux par SwissOctet. Les exemples sont illustratifs. Les spécifications de service, les options disponibles et les conditions contractuelles doivent être vérifiées séparément.