Proteggere l'applicazione e il suo accesso amministrativo, limitare il listener del backend, proteggere le chiavi del servizio onion e testare la pubblicazione tramite un client compatibile. Il routing onion è uno strato del design. Non elimina vulnerabilità dell'applicazione, errori nei contenuti pubblicati o la necessità di definire chi dovrebbe avere accesso.
Definire la pubblicazione e il suo pubblico
Iniziare con uno scopo di pubblicazione legittimo e una descrizione del pubblico. Una pubblicazione di ricerca pubblica e un portale di progetto ad accesso limitato hanno requisiti di accesso diversi. Decidere quali contenuti sono destinati a essere pubblici, quali necessitano di autenticazione applicativa e quali non dovrebbero mai raggiungere la web root. Mantenere tali decisioni separate dal trasporto utilizzato per raggiungere il sito.
Scrivere un piccolo inventario dei dati prima del deployment: pagine, upload, contenuti del database, account amministratore e configurazione del servizio. Assegnare un proprietario per gli aggiornamenti e la gestione degli incidenti. Il fatto che un sito utilizzi un indirizzo onion non risolve le questioni di conservazione, diritti sui contenuti o responsabilità di sicurezza. Queste rimangono decisioni applicative pratiche che necessitano di un piano operativo esplicito.
Mantenere deliberato il listener del backend
Un servizio onion mappa una connessione su un endpoint applicativo locale. Esaminare dove ascolta tale endpoint e quali altre reti possono raggiungerlo. La guida di configurazione del Tor Project descrive i socket Unix come un modo utile per evitare di esporre il backend a una rete locale. Scegliere un approccio supportato dal proprio server e verificarne la raggiungibilità effettiva.
Una connessione che funziona tramite Tor può coesistere con un listener pubblico non intenzionale. Testare sia il percorso di accesso previsto che i confini attorno al backend. Evitare ipotesi di configurazione generiche; leggere le impostazioni di ascolto dell'applicazione e il routing virtual-host del web server. Mantenere le interfacce di gestione distinte dal servizio destinato al pubblico e limitare chi può modificare tali impostazioni.
Esaminare cosa pubblica l'applicazione
Ispezionare pagine, file caricati, output di errore e risorse incorporate come li incontrerebbe un lettore. Un'applicazione può rivelare dettagli operativi tramite messaggi di debug o collegarsi a risorse esterne senza che ciò sia evidente nel suo design principale. Esaminare gli URL generati e i metadati dei contenuti. Servire solo le risorse richieste dalla pubblicazione e comprendere qualsiasi richiesta di terze parti che avvia.
Per un sito di ricerca illustrativo, esaminare un articolo di esempio, un allegato e una pagina di contatto prima del lancio. Verificare che un documento editoriale privato e un file di ambiente siano al di fuori della directory pubblica. Usare materiale di test non sensibile quando si verificano gli upload. Una connessione onion riuscita prova la raggiungibilità; questa revisione dei contenuti verifica cosa il servizio divulga effettivamente al suo pubblico.
Trattare l'identità del servizio come materiale protetto
La configurazione del servizio onion include materiale chiave che deve rimanere privato. Conservarlo al di fuori dei file pubblici del sito web e limitare l'accesso agli operatori che ne hanno bisogno. Pianificare come un ripristino legittimo preservi l'identità del servizio prevista e come verrebbe gestita una compromissione. Non inserire le chiavi del servizio in un archivio pubblico, in un messaggio di supporto o in un repository di progetto condiviso.
Includere l'applicazione, i dati e la configurazione del servizio richiesta nel design di ripristino, con protezione adeguata per ciascuno. Un backup dei soli contenuti del sito potrebbe non ripristinare l'indirizzo previsto, mentre una copia contenente chiavi private crea un backup sensibile. Documentare chi può decifrarlo e ripristinarlo e testare tale accesso senza esporre le chiavi nei report degli esercizi.
Scegliere esplicitamente accesso pubblico o limitato
Il login dell'applicazione e l'autorizzazione del client Tor sono livelli diversi. Il Tor Project documenta l'autorizzazione client per rendere l'accesso a un servizio onion v3 dipendente da una credenziale client. Decidere se tale modello si adatta al pubblico e al processo operativo. Non è automaticamente necessario per una pubblicazione pubblica e non sostituisce i permessi dell'applicazione una volta che un client si connette.
Considerare un portale di progetto con un piccolo gruppo approvato. Serve un modo per distribuire, sostituire e revocare il materiale di accesso in modo privato, oltre a gestire gli account applicativi. Testare separatamente la rimozione di un client autorizzato e di un utente applicativo. La tabella seguente mantiene distinti questi controlli anziché promettere che un'unica impostazione risolva ogni problema di accesso.
| Controllo | Domanda a cui risponde | Responsabilità separata |
|---|---|---|
| Listener del backend | Chi può raggiungere l'endpoint applicativo locale? | Configurazione del web server e della rete |
| Autorizzazione client | Quali client possono connettersi al servizio onion? | Distribuzione e revoca di credenziali private |
| Permessi dell'applicazione | Cosa può fare un utente connesso? | Ruoli degli account e accesso ai dati |
| Revisione della pubblicazione | Cosa divulga il sito? | Contenuti, upload e gestione degli errori |
Testare attraverso la connessione del lettore
Utilizza un client compatibile per testare pagine, navigazione, moduli e download attraverso il percorso di accesso onion previsto. Osserva gli errori e l'uso delle risorse dell'applicazione con traffico di test innocuo. Evita di misurare solo una richiesta al backend locale, perché non esercita la connessione completa del lettore. Mantieni privati gli account di test e qualsiasi credenziale ad accesso limitato.
Verifica anche le procedure di ripristino e manutenzione. Un aggiornamento dell'applicazione dovrebbe avere un punto di rollback e un modo per convalidare il percorso onion in seguito. Definisci log operativi utili e la loro conservazione senza presumere che un'etichetta di distribuzione o trasporto crei una politica di zero log. Conserva prove sufficienti per diagnosticare i guasti evitando raccolte non necessarie.
Leggere le opzioni di hosting come parti del design
SwissOctet Veil elenca le scelte relative allo stack applicativo, all'indirizzo onion e al backup. Seleziona lo stack che il tuo software si aspetta e risorse sufficienti in termini di CPU, memoria e archiviazione per il carico di lavoro. Verifica come il servizio effettivo gestisce il deployment, l'identità del servizio e il ripristino prima di farvi affidamento. La sede svizzera del catalogo è separata dal comportamento in materia di privacy della tua applicazione.
Mantieni il servizio destinato alla pubblicazione legittima e agli utenti autorizzati. Pianifica gli aggiornamenti dell'amministratore, le revisioni degli accessi e una risposta alle credenziali dell'applicazione compromesse. Una pubblicazione onion funziona al meglio quando contenuto, esposizione del backend e ripristino sono comprensibili; il trasporto dovrebbe supportare tale piano anziché diventare un pretesto per saltare la normale sicurezza del software.
La tua checklist pratica.
- Definisci il contenuto pubblico e quello riservato prima del deployment.
- Verifica l'effettiva esposizione del listener del backend.
- Esamina pagine, caricamenti e richieste di risorse esterne.
- Proteggi e testa il ripristino del materiale delle chiavi di servizio.
- Separa l'autorizzazione del client dai ruoli dell'applicazione.
- Testa la manutenzione e i percorsi dei lettori attraverso il percorso onion.
I dettagli che contano.
L'hosting onion rende un'applicazione anonima di per sé?+
No. Contenuti pubblicati, configurazione, account e pratiche operative possono rivelare informazioni. Esamina l'intero servizio anziché affidarti al metodo di connessione.
Ogni sito onion dovrebbe usare l'autorizzazione del client?+
No. Decidi in base al pubblico previsto. L'autorizzazione del client limita l'accesso alla connessione e aggiunge un ciclo di vita delle credenziali; i permessi dell'applicazione restano separati.
Cosa devo proteggere in una copia di ripristino?+
I dati del sito e la configurazione richiedono controlli di accesso adeguati. Qualsiasi materiale di chiavi di servizio incluso è particolarmente sensibile e deve rimanere privato durante l'archiviazione e il ripristino.
Vai alla fonte.
Questi riferimenti supportano i concetti tecnici di questa guida. Segui la documentazione corrente prima di modificare un sistema di produzione.
- Tor Project: Configura il tuo servizio onion community.torproject.org
- Tor Project: Impostazioni avanzate del servizio onion community.torproject.org
- Tor Project: Autorizzazione del client community.torproject.org
Guida editoriale di SwissOctet. Gli esempi sono illustrativi. Le specifiche di servizio, le opzioni disponibili e le condizioni contrattuali devono essere verificate separatamente.