# Publicér en onion-tjeneste uden at overse applikationen | SwissOctet Insights https://swissoctet.com/da/insights/publish-onion-service-safely/ SwissOctet / Indsigter / Web og onion Web og onion Anvendt · 4 min læsning Udgiv en onion-tjeneste uden at overse applikationen Planlæg en legitim onion-udgivelse med kontrolleret backend-eksponering, omhyggelig indholdsgennemgang, gendannelse af tjenestenøgler og en eksplicit model for målgruppeadgang. Af SwissOctet Editorial Gem guide Kopiér link PÅ DENNE SIDE 01 Definér publikationen og dens målgruppe 02 Hold backend-lytteren bevidst 03 Gennemgå, hvad applikationen offentliggør 04 Behandl tjenesteidentiteten som beskyttet materiale 05 Vælg offentlig eller begrænset adgang eksplicit 06 Test gennem læserens forbindelse 07 Læs hostingmuligheder som dele af designet Din praktiske tjekliste Kilder og videre læsning Tilbage til biblioteket DET DIREKTE SVAR Sikr applikationen og dens administrative adgang, begræns backend-lytteren, beskyt onion-tjenestens nøgler og test publikationen gennem en kompatibel klient. Onion-routing er ét lag i designet. Det fjerner ikke applikationssårbarheder, fejl i offentliggjort indhold eller behovet for at definere, hvem der bør have adgang. 01 Definér publikationen og dens målgruppe Begynd med et lovligt publiceringsformål og en beskrivelse af målgruppen. En offentlig forskningspublikation og en begrænset projektportal har forskellige adgangskrav. Beslut, hvilket indhold der er beregnet til at være offentligt, hvilket der kræver applikationsgodkendelse, og hvilket der aldrig bør nå webroden. Hold disse beslutninger adskilt fra den transport, der bruges til at nå webstedet. Skriv en lille datainventering før implementering: sider, uploads, databaseindhold, administratorkonti og tjenestekonfiguration. Tildel en ejer til opdateringer og hændelseshåndtering. At et websted bruger en onion-adresse, afgør ikke opbevaring, indholdsrettigheder eller sikkerhedsansvar. Det forbliver praktiske applikationsbeslutninger, der kræver en eksplicit driftsplan. 02 Hold backend-lytteren bevidst En onion-tjeneste mapper en forbindelse til et lokalt applikationsendpoint. Gennemgå, hvor dette endpoint lytter, og hvilke andre netværk der kan nå det. Tor Projects opsætningsvejledning beskriver Unix-sockets som en nyttig måde at undgå at eksponere backenden for et lokalt netværk. Vælg en tilgang, som din server understøtter, og verificér dens faktiske tilgængelighed. En forbindelse, der fungerer gennem Tor, kan eksistere samtidig med en utilsigtet offentlig lytter. Test både den tilsigtede adgangsvej og grænserne omkring backenden. Undgå generiske konfigurationsantagelser; læs applikationens lytteindstillinger og webserverens virtual-host-routing. Hold administrationsgrænseflader adskilt fra den offentligt tilsigtede tjeneste, og begræns hvem der må ændre disse indstillinger. 03 Gennemgå, hvad applikationen offentliggør Inspicér sider, uploadede filer, fejloutput og indlejrede ressourcer, som en læser ville møde dem. En applikation kan afsløre operationelle detaljer gennem fejlretningsmeddelelser eller linke til eksterne aktiver, uden at det er tydeligt i dens overordnede design. Gennemgå genererede URL'er og indholdsmetadata. Servér kun de ressourcer, som publikationen kræver, og forstå enhver tredjepartsanmodning, den igangsætter. For et illustrativt forskningswebsted skal du gennemgå en prøveartikel, en vedhæftet fil og en kontaktside før lancering. Verificér, at et privat redaktionelt dokument og en miljøfil er uden for den offentlige mappe. Brug ikke-følsomt testmateriale, når du kontrollerer uploads. En vellykket onion-forbindelse beviser tilgængelighed; denne indholdsgennemgang kontrollerer, hvad tjenesten faktisk afslører for sin målgruppe. 04 Behandl tjenesteidentiteten som beskyttet materiale Onion-tjenestekonfigurationen indeholder nøglemateriale, som skal forblive privat. Hold det uden for offentlige webstedsfiler, og begræns adgangen til de operatører, der har brug for det. Planlæg, hvordan en legitim gendannelse bevarer den tilsigtede tjenesteidentitet, og hvordan et kompromittering ville blive håndteret. Læg ikke tjenestenøgler i et offentligt arkiv, en supportmeddelelse eller et delt projektarkiv. Medtag applikationen, data og den nødvendige tjenestekonfiguration i gendannelsesdesignet med passende beskyttelse for hver. En sikkerhedskopi af webstedsindhold alene gendanner måske ikke den tilsigtede adresse, mens en kopi med private nøgler skaber en følsom sikkerhedskopi. Dokumentér, hvem der kan dekryptere og gendanne den, og test den adgang uden at eksponere nøglerne i øvelsesrapporter. 05 Vælg offentlig eller begrænset adgang eksplicit Applikationslogin og Tor-klientgodkendelse er forskellige lag. Tor Project dokumenterer klientgodkendelse til at gøre adgangen til en v3 onion-tjeneste afhængig af en klientlegitimationsoplysning. Beslut, om denne model passer til målgruppen og den operationelle proces. Den er ikke automatisk nødvendig for en offentlig publikation og erstatter ikke applikationens tilladelser, når en klient først har forbindelse. Overvej en projektportal med en lille godkendt gruppe. Du har brug for en måde at distribuere, udskifte og tilbagekalde adgangsmateriale privat samt administrere applikationskonti. Test fjernelsen af en autoriseret klient og en applikationsbruger separat. Følgende tabel holder disse kontroller adskilt i stedet for at love, at én indstilling løser ethvert adgangsproblem. Kontrol Spørgsmål, den besvarer Adskilt ansvar Backend-lytter Hvem kan nå det lokale applikationsendpoint? Webserver- og netværkskonfiguration Klientgodkendelse Hvilke klienter må oprette forbindelse til onion-tjenesten? Privat distribution og tilbagekaldelse af legitimationsoplysninger Applikationstilladelser Hvad må en tilsluttet bruger gøre? Kontoroller og dataadgang Publiceringsgennemgang Hvad afslører webstedet? Indhold, uploads og fejlhåndtering 06 Test gennem læserens forbindelse Brug en kompatibel klient til at teste sider, navigation, formularer og downloads gennem den tilsigtede onion-adgangsvej. Observer fejl og applikationens ressourceforbrug med harmløs testtrafik. Undgå kun at måle en lokal backend-anmodning, fordi den ikke udøver læserens fulde forbindelse. Hold testkonti og eventuelle legitimationsoplysninger til begrænset adgang private. Kontrollér også gendannelses- og vedligeholdelsesprocedurer. En applikationsopdatering bør have et rollback-punkt og en måde at validere onion-ruten bagefter. Definer nyttige driftslogfiler og opbevaring uden at antage, at en distributions- eller transportbetegnelse skaber en nul-logpolitik. Bevar tilstrækkelig dokumentation til at diagnosticere fejl, mens unødig indsamling undgås. 07 Læs hostingmuligheder som dele af designet SwissOctet Veil viser valg af applikationsstak, onion-adresse og sikkerhedskopiering. Vælg den stak, din software forventer, og tilstrækkelig CPU, hukommelse og lagerplads til arbejdsbelastningen. Bekræft, hvordan den faktiske tjeneste håndterer implementering, tjenesteidentitet og gendannelse, før du afhænger af den. Katalogets schweiziske placering er adskilt fra din applikations privatlivsadfærd. Hold tjenesten beregnet til legitim publicering og autoriserede brugere. Planlæg administratoropdateringer, adgangsgennemgange og en reaktion på kompromitterede applikationslegitimationsoplysninger. En onion-publikation fungerer bedst, når indhold, backend-eksponering og gendannelse er forståelige; transporten bør understøtte den plan i stedet for at blive en undskyldning for at springe almindelig softwaresikkerhed over. GØR DET TIL HANDLING Din praktiske tjekliste. ✓ Definér offentligt og begrænset indhold før implementering. ✓ Verificér backend-lytterens faktiske eksponering. ✓ Gennemgå sider, uploads og eksterne ressourceanmodninger. ✓ Beskyt og test gendannelse af tjenestenøglemateriale. ✓ Adskil klientgodkendelse fra applikationsroller. ✓ Test vedligeholdelse og læserrejser gennem onion-vejen. Download tjekliste ALMINDELIGE SPØRGSMÅL De detaljer, der betyder noget. Gør onion-hosting en applikation anonym i sig selv? + Nej. Offentliggjort indhold, konfiguration, konti og operationelle praksisser kan afsløre information. Gennemgå hele tjenesten i stedet for at stole på forbindelsesmetoden. Bør ethvert onion-websted bruge klientgodkendelse? + Nej. Beslut ud fra den tilsigtede målgruppe. Klientgodkendelse begrænser forbindelsesadgang og tilføjer en livscyklus for legitimationsoplysninger; applikationstilladelser forbliver adskilte. Hvad skal jeg beskytte i en gendannelseskopi? + Webstedsdata og konfiguration kræver passende adgangskontroller. Eventuelt inkluderet tjenestenøglemateriale er særligt følsomt og skal forblive privat under lagring og gendannelse. PRIMÆRE REFERENCER Gå til kilden. Disse referencer understøtter de tekniske begreber i denne guide. Følg den aktuelle dokumentation, før du ændrer et produktionssystem. Tor Project: Opsæt din onion-tjeneste community.torproject.org Tor Project: Avancerede indstillinger for onion-tjenester community.torproject.org Tor Project: Klientgodkendelse community.torproject.org Redaktionel vejledning af SwissOctet. Eksempler er illustrative. Servicespecifikationer, tilgængelige valgmuligheder og kontraktvilkår skal verificeres separat. FORBIND VIDENEN Relateret infrastruktur. Veil Onion Schweiz Vector VPS Schweiz Vault Storage Schweiz BEHOLD TRÅDEN Dine næste feltnoter. Udforsk alle guider FELTNOTE / 01 + Cloud & VPS Fundament Sådan vælger du en VPS uden at gætte Omsæt en applikationsidé til et brugbart ressourcebudget, og sammenlign derefter CPU, hukommelse, storage og overførsel samlet. 4 min læsning Læs guiden FELTNOTE / 02 + Web og onion Fundament Webhosting eller en VPS: vælg det arbejde, du vil eje Sammenlign applikationskrav, kontrol og vedligeholdelsesansvar i stedet for at behandle en VPS som det automatiske næste skridt for ethvert website. 6 min. læsning Læs guiden FELTNOTE / 03 + Web og onion Anvendt En runbook til overgang af domæne, DNS og TLS til en ny server Forbered værtsnavnerouting, certifikater og tilbagerulning samlet, så en migrering ændrer serveren uden at bryde webstedets identitet eller sikre forbindelser. 4 min læsning Læs guiden