Sikre applikasjonen og dens administrative tilgang, begrens backend-lytteren, beskytt onion-tjenestenøkler og test publiseringen gjennom en kompatibel klient. Onion-ruting er ett lag av designet. Det fjerner ikke applikasjonssårbarheter, feil i publisert innhold eller behovet for å definere hvem som skal ha tilgang.
Definer publiseringen og målgruppen
Start med et lovlig publiseringsformål og en beskrivelse av målgruppen. En offentlig forskningspublikasjon og en begrenset prosjektportal har ulike tilgangskrav. Bestem hvilket innhold som skal være offentlig, hvilket som krever applikasjonsautentisering, og hvilket som aldri bør nå webroten. Hold disse beslutningene atskilt fra transporten som brukes for å nå nettstedet.
Skriv en liten datainventar før utrulling: sider, opplastinger, databaseinnhold, administrator-kontoer og tjenestekonfigurasjon. Tildel en eier for oppdateringer og hendelseshåndtering. At et nettsted bruker en onion-adresse, avgjør ikke oppbevaring, innholdsrettigheter eller sikkerhetsansvar. Dette forblir praktiske applikasjonsbeslutninger som krever en eksplisitt driftsplan.
Hold backend-lytteren bevisst
En onion-tjeneste kobler en tilkobling til et lokalt applikasjonsendepunkt. Gå gjennom hvor dette endepunktet lytter, og hvilke andre nettverk som kan nå det. Tor Projects oppsettsveiledning beskriver Unix-sockets som en nyttig måte å unngå å eksponere backend for et lokalt nettverk. Velg en tilnærming som støttes av serveren din, og verifiser den faktiske nåbarheten.
En tilkobling som fungerer gjennom Tor, kan eksistere samtidig med en utilsiktet offentlig lytter. Test både den tiltenkte tilgangsveien og grensene rundt backend. Unngå generiske konfigurasjonsantakelser; les applikasjonens lyttinnstillinger og webserverens virtuelle vertsruting. Hold administrasjonsgrensesnitt atskilt fra den offentlig tiltenkte tjenesten, og begrens hvem som kan endre disse innstillingene.
Gjennomgå hva applikasjonen publiserer
Inspiser sider, opplastede filer, feilutdata og innebygde ressurser slik en leser vil møte dem. En applikasjon kan avsløre driftsdetaljer gjennom feilsøkingsmeldinger eller lenke til eksterne ressurser uten at det er åpenbart i hoveddesignet. Gå gjennom genererte URL-er og innholdsmetadata. Tjen bare de ressursene publikasjonen krever, og forstå enhver tredjepartsforespørsel den starter.
For et illustrerende forskningsnettsted, gå gjennom en eksempelartikkel, et vedlegg og en kontaktside før lansering. Verifiser at et privat redaksjonelt dokument og en miljøfil ligger utenfor den offentlige katalogen. Bruk ikke-sensitive testmaterialer når du sjekker opplastinger. En vellykket onion-tilkobling beviser nåbarhet; denne innholdsgjennomgangen sjekker hva tjenesten faktisk avslører for målgruppen.
Behandle tjenesteidentiteten som beskyttet materiale
Onion-tjenestekonfigurasjonen inneholder nøkkelmateriale som må forbli privat. Hold det utenfor offentlige nettstedsfiler, og begrens tilgangen til operatørene som trenger det. Planlegg hvordan en legitim gjenoppretting bevarer den tiltenkte tjenesteidentiteten, og hvordan et kompromittering skal håndteres. Ikke plasser tjenestenøkler i et offentlig arkiv, en støttemelding eller et delt prosjektarkiv.
Inkluder applikasjonen, dataene og nødvendig tjenestekonfigurasjon i gjenopprettingsdesignet, med passende beskyttelse for hver. En sikkerhetskopi av bare nettstedsinnhold kan ikke gjenopprette den tiltenkte adressen, mens en kopi som inneholder private nøkler, skaper en sensitiv sikkerhetskopi. Dokumenter hvem som kan dekryptere og gjenopprette den, og test denne tilgangen uten å eksponere nøklene i øvelsesrapporter.
Velg offentlig eller begrenset tilgang eksplisitt
Applikasjonsinnlogging og Tor-klientautorisasjon er forskjellige lag. Tor Project dokumenterer klientautorisasjon for å gjøre tilgang til en v3 onion-tjeneste avhengig av en klientlegitimasjon. Bestem om denne modellen passer for målgruppen og driftsprosessen. Den er ikke automatisk nødvendig for en offentlig publikasjon og erstatter ikke applikasjonens tillatelser når en klient først har koblet til.
Vurder en prosjektportal med en liten godkjent gruppe. Du trenger en måte å distribuere, erstatte og tilbakekalle tilgangsmateriale privat, samt administrere applikasjonskontoer. Test fjerning av en autorisert klient og en applikasjonsbruker separat. Tabellen nedenfor holder disse kontrollene atskilt i stedet for å love at én innstilling løser alle tilgangsproblemer.
| Kontroll | Spørsmålet den svarer på | Separat ansvar |
|---|---|---|
| Backend-lytter | Hvem kan nå det lokale applikasjonsendepunktet? | Webserver- og nettverkskonfigurasjon |
| Klientautorisasjon | Hvilke klienter kan koble til onion-tjenesten? | Privat distribusjon og tilbakekalling av legitimasjon |
| Applikasjonstillatelser | Hva kan en tilkoblet bruker gjøre? | Konto roller og datatilgang |
| Publiseringsgjennomgang | Hva avslører nettstedet? | Innhold, opplastinger og feilhåndtering |
Test gjennom leserens tilkobling
Bruk en kompatibel klient til å teste sider, navigasjon, skjemaer og nedlastinger gjennom den tiltenkte onion-tilgangsveien. Observer feil og applikasjonens ressursbruk med ufarlig testtrafikk. Unngå å måle bare en lokal backend-forespørsel, fordi den ikke tester leserens fulle tilkobling. Hold testkontoer og eventuelle legitimasjoner for begrenset tilgang private.
Sjekk gjenopprettings- og vedlikeholdsprosedyrer også. En applikasjonsoppdatering bør ha et tilbakerullingspunkt og en måte å validere onion-ruten etterpå. Definer nyttige driftslogger og oppbevaring uten å anta at en distribusjons- eller transportetikett skaper en null-loggpolicy. Bevar nok bevis til å diagnostisere feil, samtidig som unødvendig innsamling unngås.
Les hostingalternativer som deler av designet
SwissOctet Veil viser valg for applikasjonsstakk, onion-adresse og sikkerhetskopi. Velg stakken programvaren din forventer, og nok CPU, minne og lagring for arbeidsbelastningen. Bekreft hvordan den faktiske tjenesten håndterer utrulling, tjenesteidentitet og gjenoppretting før du er avhengig av den. Katalogens sveitsiske lokasjon er atskilt fra personvernatferden til applikasjonen din.
Hold tjenesten beregnet på lovlig publisering og autoriserte brukere. Planlegg administratoroppdateringer, tilgangsvurderinger og en respons på kompromitterte applikasjonslegitimasjoner. En onion-publikasjon fungerer best når innhold, backend-eksponering og gjenoppretting er forståelig; transporten bør støtte denne planen i stedet for å bli en unnskyldning for å hoppe over vanlig programvaresikkerhet.
Din praktiske sjekkliste.
- Definer offentlig og begrenset innhold før utrulling.
- Verifiser backend-lytterens faktiske eksponering.
- Gå gjennom sider, opplastinger og eksterne ressursforespørsler.
- Beskytt og test gjenoppretting av tjenestenøkkelmateriale.
- Skill klientautorisasjon fra applikasjonsroller.
- Test vedlikehold og leserreiser gjennom onion-veien.
Detaljene som betyr noe.
Gjør onion-hosting en applikasjon anonym av seg selv?+
Nei. Publisert innhold, konfigurasjon, kontoer og driftsrutiner kan avsløre informasjon. Gå gjennom hele tjenesten i stedet for å stole på tilkoblingsmetoden.
Bør hvert onion-nettsted bruke klientautorisasjon?+
Nei. Bestem ut fra den tiltenkte målgruppen. Klientautorisasjon begrenser tilkoblingstilgang og legger til en livssyklus for legitimasjon; applikasjonstillatelser forblir separate.
Hva må jeg beskytte i en gjenopprettingskopi?+
Nettstedsdata og konfigurasjon trenger passende tilgangskontroller. Eventuelt inkludert tjenestenøkkelmateriale er spesielt sensitivt og må forbli privat under lagring og gjenoppretting.
Gå til kilden.
Disse referansene støtter de tekniske konseptene i denne veiledningen. Følg gjeldende dokumentasjon før du endrer et produksjonssystem.
- Tor Project: Sett opp onion-tjenesten din community.torproject.org
- Tor Project: Avanserte innstillinger for onion-tjenester community.torproject.org
- Tor Project: Klientautorisasjon community.torproject.org
Redaksjonell veiledning av SwissOctet. Eksempler er illustrerende. Tjenestespesifikasjoner, tilgjengelige alternativer og kontraktsvilkår må verifiseres separat.