I-secure ang aplikasyon at administratibong access nito, limitahan ang backend listener, protektahan ang mga key ng onion-service at subukan ang publication sa pamamagitan ng compatible na client. Ang onion routing ay isang layer ng disenyo. Hindi nito inaalis ang mga kahinaan ng aplikasyon, pagkakamali sa na-publish na nilalaman o pangangailangang tukuyin kung sino ang dapat magkaroon ng access.
Tukuyin ang publication at ang audience nito
Magsimula sa isang legal na layunin sa paglalathala at paglalarawan ng audience. Ang isang pampublikong publikasyon sa pananaliksik at isang portal ng proyektong may paghihigpit ay may magkaibang pangangailangan sa pag-access. Magpasya kung aling nilalaman ang inilaan na maging pampubliko, alin ang nangangailangan ng authentication ng application at alin ang hindi dapat umabot sa web root. Panatilihing hiwalay ang mga desisyong iyon sa transport na ginagamit upang maabot ang site.
Magsulat ng maliit na imbentaryo ng data bago ang deployment: mga pahina, upload, nilalaman ng database, mga administrator account at configuration ng serbisyo. Magtalaga ng may-ari para sa mga update at paghawak ng insidente. Ang katotohanan na ang isang site ay gumagamit ng onion address ay hindi nagtatakda ng retention, mga karapatan sa nilalaman o mga responsibilidad sa seguridad. Nananatili ang mga iyon na praktikal na desisyon sa application na nangangailangan ng malinaw na plano sa pagpapatakbo.
Panatilihing sinadya ang backend listener
Ang isang onion service ay nagmamapa ng koneksyon sa isang lokal na endpoint ng application. Suriin kung saan nakikinig ang endpoint na iyon at kung anong iba pang mga network ang makakaabot dito. Inilalarawan ng setup guide ng Tor Project ang Unix sockets bilang isang kapaki-pakinabang na paraan upang maiwasan ang paglalantad ng backend sa isang lokal na network. Pumili ng paraang sinusuportahan ng iyong server at i-verify ang aktwal na maaabot nito.
Ang isang koneksyong gumagana sa pamamagitan ng Tor ay maaaring magkasabay sa isang hindi sinasadyang pampublikong listener. Subukan ang parehong inilaan na landas ng pag-access at ang mga hangganan sa paligid ng backend. Iwasan ang mga generic na palagay sa configuration; basahin ang mga setting ng pakikinig ng application at ang virtual-host routing ng web server. Panatilihing naiiba ang mga interface ng pamamahala mula sa pampublikong inilaang serbisyo at limitahan kung sino ang maaaring magbago ng mga setting na iyon.
Suriin kung ano ang ipinapublish ng aplikasyon
Suriin ang mga pahina, na-upload na file, output ng error at naka-embed na resource tulad ng makikita ng isang mambabasa. Ang isang application ay maaaring magbunyag ng mga detalye sa pagpapatakbo sa pamamagitan ng mga mensahe sa debugging o mag-link sa mga panlabas na asset nang hindi iyon halata sa pangunahing disenyo nito. Suriin ang mga nabuong URL at metadata ng nilalaman. Ihain lamang ang mga resource na kailangan ng publikasyon at unawain ang anumang third-party na kahilingang sinisimulan nito.
Para sa isang ilustratibong site ng pananaliksik, suriin ang isang sample na artikulo, attachment at pahina ng contact bago ilunsad. I-verify na ang isang pribadong dokumentong editoryal at isang environment file ay nasa labas ng pampublikong direktoryo. Gumamit ng hindi sensitibong materyal sa pagsubok kapag sinusuri ang mga upload. Ang isang matagumpay na koneksyon sa onion ay nagpapatunay ng maaabot; ang pagsusuring ito sa nilalaman ay sumusuri kung ano talaga ang ibinubunyag ng serbisyo sa audience nito.
Ituring ang identity ng serbisyo bilang protektadong materyal
Kasama sa configuration ng onion-service ang key material na dapat manatiling pribado. Panatilihin ito sa labas ng mga pampublikong file ng website at limitahan ang access sa mga operator na nangangailangan nito. Planuhin kung paano pinapanatili ng isang lehitimong recovery ang inilaang pagkakakilanlan ng serbisyo at kung paano haharapin ang isang compromise. Huwag ilagay ang mga service key sa isang pampublikong archive, mensahe ng suporta o ibinahaging repository ng proyekto.
Isama ang application, data at kinakailangang configuration ng serbisyo sa disenyo ng recovery, na may angkop na proteksyon para sa bawat isa. Ang backup ng nilalaman ng site lamang ay maaaring hindi maibalik ang inilaang address, habang ang isang kopyang naglalaman ng mga private key ay lumilikha ng sensitibong backup. Idokumento kung sino ang maaaring mag-decrypt at mag-restore nito at subukan ang access na iyon nang hindi inilalantad ang mga key sa mga ulat ng pagsasanay.
Pumili nang tahasan ng public o restricted access
Ang pag-login sa application at ang awtorisasyon ng Tor client ay magkaibang mga layer. Idinodokumento ng Tor Project ang client authorisation para gawing nakadepende sa isang client credential ang pag-access sa isang v3 onion service. Magpasya kung ang modelong iyon ay umaangkop sa audience at proseso ng pagpapatakbo. Hindi ito awtomatikong kailangan para sa isang pampublikong publikasyon at hindi nito pinapalitan ang mga pahintulot ng application kapag nakakonekta na ang isang client.
Isaalang-alang ang isang portal ng proyekto na may maliit na aprubadong grupo. Kailangan mo ng paraan upang mamahagi, magpalit at magbawi ng access material nang pribado, gayundin ang pamahalaan ang mga account ng application. Subukan nang hiwalay ang pagtanggal ng isang awtorisadong client at ng isang user ng application. Pinapanatiling naiiba ng sumusunod na talahanayan ang mga kontrol na ito sa halip na mangako na isang setting lang ang sasagot sa lahat ng problema sa pag-access.
| Kontrol | Tanong na sinasagot nito | Hiwalay na responsibilidad |
|---|---|---|
| Tagatanggap ng koneksiyon sa backend | Sino ang makakaabot sa lokal na endpoint ng application? | Web server at configuration ng network |
| Awtorisasyon ng client | Aling mga client ang maaaring kumonekta sa onion service? | Pribadong pamamahagi at pagbawi ng credential |
| Mga pahintulot ng application | Ano ang maaaring gawin ng isang nakakonektang user? | Mga role ng account at pag-access sa data |
| Pagsusuri sa paglalathala | Ano ang ibinubunyag ng site? | Nilalaman, upload at paghawak ng error |
Subukan sa pamamagitan ng koneksyon ng reader
Gumamit ng compatible na client upang subukan ang mga pahina, navigation, form at download sa inilaang landas ng pag-access sa onion. Obserbahan ang mga error at paggamit ng resource ng application gamit ang hindi mapanganib na test traffic. Iwasan ang pagsukat lamang ng lokal na kahilingan sa backend, dahil hindi nito nasusubukan ang buong koneksyon ng mambabasa. Panatilihing pribado ang mga test account at anumang credential sa may paghihigpit na pag-access.
Suriin din ang mga pamamaraan sa recovery at maintenance. Ang isang update ng application ay dapat may rollback point at paraan upang mapatunayan ang ruta ng onion pagkatapos. Tukuyin ang mga kapaki-pakinabang na operational log at retention nang hindi ipinapalagay na ang isang label ng distribution o transport ay lumilikha ng zero-logs policy. Panatilihin ang sapat na ebidensya upang masuri ang mga fault habang iniiwasan ang hindi kinakailangang pangongolekta.
Basahin ang mga opsyon sa hosting bilang bahagi ng disenyo
Naglilista ang SwissOctet Veil ng mga pagpipilian sa application-stack, onion-address at backup. Piliin ang stack na inaasahan ng iyong software at sapat na CPU, memory at storage para sa workload. Kumpirmahin kung paano hinahawakan ng aktwal na serbisyo ang deployment, pagkakakilanlan ng serbisyo at pagpapanumbalik bago umasa dito. Ang lokasyong Swiss ng catalogue ay hiwalay sa pag-uugali sa privacy ng iyong application.
Panatilihin ang serbisyo para sa lehitimong paglalathala at mga awtorisadong user. Planuhin ang mga update ng administrator, pagsusuri sa access at pagtugon sa mga nakompromisong credential ng application. Pinakamainam na gumagana ang isang onion publication kapag ang nilalaman, paglalantad ng backend at recovery ay nauunawaan; dapat suportahan ng transport ang planong iyon sa halip na maging dahilan upang laktawan ang ordinaryong seguridad ng software.
Ang iyong praktikal na checklist.
- Tukuyin ang pampubliko at may paghihigpit na nilalaman bago ang deployment.
- I-verify ang aktwal na paglalantad ng backend listener.
- Suriin ang mga pahina, upload at panlabas na kahilingan sa resource.
- Protektahan at subukan ang recovery ng service-key material.
- Ihiwalay ang awtorisasyon ng client mula sa mga role ng application.
- Subukan ang maintenance at mga paglalakbay ng mambabasa sa landas ng onion.
Ang mga detalyeng mahalaga.
Ginagawa ba ng onion hosting na anonymous ang isang application nang mag-isa?+
Hindi. Ang nailathalang nilalaman, configuration, account at mga kasanayan sa pagpapatakbo ay maaaring magbunyag ng impormasyon. Suriin ang buong serbisyo sa halip na umasa sa paraan ng koneksyon.
Dapat bang gumamit ng client authorisation ang bawat onion site?+
Hindi. Magpasya batay sa inilaang audience. Ang client authorisation ay naghihigpit sa pag-access sa koneksyon at nagdaragdag ng lifecycle ng credential; nananatiling hiwalay ang mga pahintulot ng application.
Ano ang dapat kong protektahan sa isang kopya ng recovery?+
Ang data at configuration ng site ay nangangailangan ng angkop na mga kontrol sa pag-access. Ang anumang kasamang service-key material ay lalong sensitibo at dapat manatiling pribado habang nakaimbak at sa pagpapanumbalik.
Pumunta sa pinagmulan.
Sinusuportahan ng mga sangguniang ito ang mga teknikal na konsepto sa gabay na ito. Sundin ang kasalukuyang dokumentasyon bago baguhin ang isang production system.
- Tor Project: I-set up ang iyong onion service community.torproject.org
- Tor Project: Mga advanced na setting ng onion-service community.torproject.org
- Tor Project: Awtorisasyon ng client community.torproject.org
Editorial guidance ni SwissOctet. Ang mga halimbawa ay ilustratibo. Ang service specifications, available options at contractual conditions ay dapat beripikahin nang hiwalay.