Visi straipsniai
Saugumo praktika9 min skaitymo· 2026-05-27· Atnaujinta 2026-06-03

Kaip saugiai perduoti prieigą prie svetainės saugumo specialistui

El. paštas ir messenger — ne saugūs kanalai slaptažodžiams. Kaip perduoti WordPress, FTP ir hostingo prieigą taip, kad duomenys neatsidurtų svetimose rankose.

Aleksandras Izmalkovas

Autorius

Aleksandras Izmalkovas

Kaip saugiai perduoti prieigą prie svetainės saugumo specialistui

Kreipiantis dėl svetainės valymo ar saugumo patikros, vienas pirmų klausimų yra praktinis: kaip perduoti prisijungimo duomenis? El. paštas atrodo paprasčiausias variantas, messenger: greičiausias. Bet abu yra blogas pasirinkimas, ir ne dėl nepagrįsto atsargumo.

Slaptažodžiai, išsiųsti el. paštu ar žinute, saugomi ne tik gavėjo įrenginyje, jie lieka siuntėjo serveryje, gavėjo serveryje, ir kiekviename tarpiniame taške. Bet kuris iš šių serverių gali būti pažeistas dabar ar ateityje. O jūs šiuo metu ir taip jau turite problemą su saugumu: ne laikas kurti papildomų silpnų vietų.

Trumpas atsakymas: kaip perduoti saugiai

Vienas saugus kelias: vienkartinė šifruota nuoroda:

  1. 1Eikite į saugaus perdavimo formą
  2. 2Įveskite slaptažodį ar prieigos duomenis
  3. 3Nukopijuokite sugeneruotą vienkartinę nuorodą
  4. 4Atsiųskite nuorodą sutartu kanalu. Nors raktas nėra siunčiamas serveriui, visa nuoroda su #key dalimi turi būti laikoma slapta, nes pirmas ją atidaręs žmogus galės perskaityti perduotus duomenis
  5. 5Pranešite, kokius duomenis perdavėte (pvz., „WordPress admin" arba „FTP hostname ir vardas")

Svarbu: pati nuoroda nėra jūsų WordPress ar hostingo slaptažodis, tačiau pilna nuoroda su #key dalimi yra slaptas raktas į perduotą informaciją. Todėl jos nereikia skelbti viešai ar siųsti žmonėms, kuriems prieiga nereikalinga.

Kodėl negalima siųsti slaptažodžių el. paštu

El. paštas nėra šifruotas pagal nutylėjimą, net jei ryšys tarp jūsų ir serverio šifruotas, laiškas saugomas siuntėjo ir gavėjo serveriuose paprastai metų metus.

Konkrečios rizikos:

  • Ilgalaikis saugojimas. El. laiškai saugomi serveriuose ilgus metus. Jei serveris kada nors bus pažeistas: seni laiškai su slaptažodžiais bus pirmasis taikinys.
  • Tarpiniai serveriai. El. laiškas keliauja per kelis serverius. Kiekvienas iš jų gali saugoti kopijas arba žurnalus.
  • Siuntėjo paskyros pažeidžiamumas. Jei jūsų el. pašto paskyra kada nors bus kompromituota: užpuolikas gali peržiūrėti visus išsiųstus laiškus, įskaitant slaptažodžius.
  • Automatinė sinchronizacija. Daugelis el. pašto klientų automatiškai sinchronizuoja laiškus į debesų saugyklas ar kitus įrenginius.

Net jei kai kurie messenger'iai naudoja šifravimą, slaptažodžiai vis tiek lieka pokalbių istorijoje, atsarginėse kopijose, keliuose įrenginiuose — arba gali būti atskleisti per paskyros pažeidimą. Todėl vienkartinė nuoroda arba laikina paskyra su ribotomis teisėmis yra geresnė praktika.

Iliustracija

Kaip veikia vienkartinė šifruota nuoroda

Saugaus perdavimo forma sukurta būtent šiam tikslui. Ji veikia taip:

  • Slaptažodis šifruojamas jūsų naršyklėje prieš išsiunčiant: naudojamas AES-256-GCM algoritmas su naršyklėje sugeneruotu raktu
  • Šifravimo raktas niekada nesiunčiamas serveriui: jis lieka tik sugeneruotos nuorodos fragmente (#key=…)
  • Serveris gauna ir saugo tik šifruotą bloką, kurio negali perskaityti
  • Sugeneruojama vienkartinė nuoroda su unikaliu ID
  • Nuoroda galioja 30 dienų arba iki pirmo atidarymo, kas nutinka anksčiau
  • Po atidarymo nuoroda paslepiama nuo kitų lankytojų

Jei nuorodą pirmas atidarys ne tas žmogus, duomenys gali būti atskleisti. Todėl pilna nuoroda su #key dalimi turi būti siunčiama tik sutartu kanalu ir tik tam žmogui, kuriam prieiga skirta.

Kaip mes saugome perduotus duomenis

Techninis žmogus gali paklausti: o kaip tiksliai tai veikia? Atsakome atvirai.

Šifravimas vyksta naršyklėje, ne serveryje. Raktas generuojamas jūsų naršyklėje naudojant standartinį Web Crypto API. Serveris gauna tik jau užšifruotą bloką.

AGuard serveris niekada nemato pradinių duomenų. Raktas keliauja tik URL fragmente (dalis po #): naršyklė šį fragmentą nesiunčia serveriui jokiomis HTTP užklausomis. Tai reiškia, kad net jei serverio užklausų žurnalai būtų nutekinti, jie neturėtų rakto iššifruoti.

Raktas nesaugomas serveryje. Jis egzistuoja tik sugeneruotoje nuorodoje — ir niekur kitur.

Žurnaluose saugoma: sukūrimo laikas, nuorodos atidarymo laikas ir peržiūros IP adresas. Turinio — ne.

Duomenų galiojimas: 30 dienų arba iki pirmo atidarymo vienkartiniame režime. Po to failas automatiškai paslepiamas.

Po pirmo atidarymo: vienkartinio režimo nuoroda paslepiama nuo naujų lankytojų. Duomenys nebepasiekiami.

Jei nenorite naudoti AGuard formos

Statija skirta ne reklamuoti vieną įrankį, o padėti perduoti prieigą saugiai. Jei turite kitą patikimą kanalą, čia yra techniškai pagrįstos alternatyvos:

  • Slaptažodžių tvarkyklės dalinimosi funkcija. 1Password, Bitwarden ar Proton Pass leidžia saugiai dalintis kredencialais su konkrečiu žmogumi. Šifravimas vyksta klientų pusėje, paslaugos teikėjas turinio nemato.
  • Vienkartinės šifruotos nuorodos. Lygiavertės alternatyvos: Bitwarden Send, PrivateBin arba savarankiškai talpinamas Passbolt. Visi naudoja kliento pusės šifravimą.
  • Laikina paskyra su ribotomis teisėmis. Tai geriausia praktika: suteikiate ne pagrindinę prieigą, o naują paskyrą, kurią po darbo galima ištrinti. Jokių nuorodų, jokių šifruotų blobų — prieiga tiesiog nustoja egzistuoti.

Bet kuris iš šių variantų yra techniškai tinkamas. Svarbiausia, kad jokiu atveju nenaudotumėte el. pašto, SMS ar neapsaugotos žinutės.

Mažiausios būtinos teisės

Pagrindinė taisyklė: perduokite tik tiek prieigos, kiek reikia konkrečiam darbui. Kuo mažiau prieigos — tuo mažesnė žala, jei kažkas nutiktų.

  • Pirminė patikra: WordPress administratoriaus paskyra arba ribota skaitymo paskyra. FTP ar hostingo prieigos nereikia.
  • Failų valymas: FTP subpaskyra (tik konkrečiam katalogui) arba hostingo valdymo panelė. Ne pagrindinė paskyra.
  • DNS ir WAF darbai: Cloudflare prieiga (Zone-level API token arba apribotas vartotojas). Ne paskyros savininko prieiga.
  • Duomenų bazės darbai: atskiras DB vartotojas su teisėmis tik konkrečiai duomenų bazei.
  • Po darbo: atšaukti, ištrinti arba pakeisti. Jokia laikina prieiga neturėtų gyventi ilgiau nei reikia.
Iliustracija

Laikinų paskyrų kūrimas: geriausia praktika

Jei jūsų sistema leidžia kurti laikinas paskyras su ribotomis teisėmis, tai geriausia praktika, kurią rekomenduojame. Administracinės prieigos ribojimą ir griežtą autentifikaciją perduodant prieigą rekomenduoja ir NKSC interneto svetainių apsaugos gairės.

WordPress laikinas administratorius. Sukurkite naują administratoriaus paskyrą su stipriu atsitiktiniu slaptažodžiu, kurią po darbo galėsite ištrinti. Taip esama jūsų administratoriaus paskyra lieka neliesta.

FTP subpaskyra. Daugelis hostingo sistemų leidžia kurti papildomas FTP paskyras su prieiga tik prie konkretaus katalogo. Tai leidžia suteikti prieigą nepadalinant pagrindinės paskyros.

Hostingo subpaskyra. Kai kurios hostingo sistemos leidžia kurti laikinas paskyras su ribotomis teisėmis. Tai priklauso nuo naudojamos sistemos.

Jei laikinų paskyrų kūrimas nėra įmanomas: tiesiog pasidalinkite esama prieiga per vienkartinę nuorodą ir pakeiskite slaptažodžius po darbo.

Ko nedaryti perduodant prieigą

Nesiųskite slaptažodžių el. paštu ar žinute. Net jei atrodo, kad kanalas patikimas, žr. aukščiau dėl saugojimo rizikų.

Nesiųskite visos informacijos vienu laišku. Jei vis dėlto naudojate el. paštą: bent padalinkite: vartotojo vardą vienu laišku, slaptažodį kitu kanalu.

Neperduokite daugiau, nei reikia. Jei pirminei patikrai reikia tik WordPress administratoriaus: nereikia iš karto perduoti FTP ir hostingo prieigos. Prieigą galima suteikti etapais.

Nekeiskite slaptažodžių prieš darbą, jei svetainė vis dar yra užkrėsta. Keičiant slaptažodžius prieš valymą, o ne po jo, tai gali sudaryti papildomų komplikacijų, ypač jei duomenų bazė ar cron dar turi aktyvių kenkėjiškų procesų.

Po darbo: privalomas sąrašas

Šis žingsnis svarbus ne mažiau nei saugus perdavimas. Po valymo ir galutinio patikrinimo būtina:

  • Ištrinti laikiną WordPress administratoriaus paskyrą
  • Išjungti FTP subpaskyrą arba pakeisti jos slaptažodį
  • Pakeisti visus perduotus slaptažodžius (WordPress, hostingas, duomenų bazė)
  • Atšaukti API raktus (Cloudflare Zone token ar kitus)
  • Patikrinti vartotojų sąrašą: ar neliko nežinomų paskyrų

Mūsų ataskaitoje visada nurodoma, kuriuos konkrečiai slaptažodžius reikia pakeisti ir kodėl. VDAI rekomenduoja riboti prieigą prie sistemų, kuriose tvarkomi asmens duomenys, ir dokumentuoti, kam ir kada prieiga buvo suteikta.

Kontrolinis sąrašas: prieigos perdavimas

  • Nustatyti, kokios prieigos reikia konkrečiai paslaugai
  • Sukurti laikinę paskyrą su minimaliais leidimais (jei sistema leidžia)
  • Perduoti duomenis per vienkartinę šifruotą nuorodą
  • Pranešti, ką tiksliai perdavėte (pvz., „WordPress admin, vartotojo vardas: admin2")
  • Išsaugoti informaciją, kada ir kam buvo perduota prieiga
  • Po darbo: pakeisti arba ištrinti visus perduotus prieigos duomenis

Dažnai užduodami klausimai

Ar galima siųsti slaptažodžius per Telegram ar WhatsApp?

Kai kurie messengeriai naudoja šifravimą (pvz., WhatsApp naudoja end-to-end šifravimą asmeniniams pokalbiams, Telegram — tik „Secret Chats" režime), tačiau slaptažodžiai vis tiek lieka pokalbių istorijoje, atsarginėse kopijose ir keliuose įrenginiuose. Paskyros pažeidimo atveju visa istorija tampa pasiekiama. Vienkartinė šifruota nuoroda arba laikina paskyra yra techniškai patikimesnis pasirinkimas.

Kiek laiko galioja vienkartinė nuoroda?

Mūsų sistemoje nuoroda galioja 30 dienų arba iki pirmo atidarymo, priklausomai nuo to, kas įvyksta anksčiau. Po atidarymo nuoroda paslepiama nuo naujų lankytojų.

Ką daryti, jei reikia perduoti ir FTP, ir duomenų bazę, ir WordPress prieigą?

Geriausia perduoti atskiromis nuorodomis: kiekvieną kredencialų rinkinį atskirai. Taip sumažinama rizika, kad vienas pažeidimas atskleistų visą prieigą vienu metu.

Ar reikia keisti slaptažodžius po to, kai specialistas baigia darbą?

Taip, visada. Tai standartinė praktika po bet kokio išorinio darbo, nepriklausomai nuo specialisto patikimumo. Ataskaitoje visada nurodome, kuriuos slaptažodžius reikia pakeisti.

Kada kreiptis su klausimais

Nesate tikri, kokios prieigos reikia jūsų atvejui? Nesate tikri, kaip sukurti laikinę paskyrą jūsų hostingo sistemoje? Parašykite mums per kontaktų formą: pasitarsime prieš perduodant bet ką.

Kad ir koks kanalas būtų pasirinktas prieigos perdavimui, svarbu, kad jis nesaugo duomenų ilgiau nei būtina, ir kad po darbo prieiga būtų atšaukta.


Reikia pagalbos

Susidūrėte su panašia situacija?

Aprašykite, kas vyksta — per nemokamą konsultaciją pasakysime, ką galima padaryti ir kiek tai kainuotų.

Nemokama konsultacija