Incident s tiketima podrške Virtualizora: zašto se root lozinke nikad ne smiju čuvati
Sigurnosni incident iz veljače 2026., koji je zahvatio sustav podrške Virtualizora, istaknuo je jedan od najstarijih sigurnosnih problema hosting industrije: platforme podrške nehotice postaju spremišta korisničkih pristupnih podataka.
Prema vlastitoj sigurnosnoj obavijesti Virtualizora, neovlašten pristup njihovu sustavu tiketa razotkrio je otprilike 1500 starih upita podršci. Virtualizor je izvijestio da su neki od tih tiketa sadržavali osjetljive podatke, uključujući root pristupne podatke u čistom tekstu koje su klijenti ranije dijelili tražeći pomoć. Tvrtka je navela da je incident vezan uz sustav podrške i da ga nije prouzročio propust u samom softveru Virtualizor. 1
Važna pouka ne ostaje na jednoj platformi ni na jednom pružatelju.
Problem je u tome što sustavi podrške često sadrže godine korisničkih podataka koji nikad nisu bili zamišljeni kao trajna sigurnosna evidencija.
Službe podrške su zanemareni sigurnosni sustavi
Mnogi pružatelji hostinga s vremenom nakupe istu vrstu podataka.
Root lozinke zalijepljene tijekom rješavanja problema. SSH ključevi priloženi pri migraciji. API tokeni unutar poruka o pogreškama. Izvozi baza podataka učitani da bi se problem ponovio.
Tiket se zatvori. Problem je riješen. Klijent nastavlja svojim poslom.
A podaci često ostaju pohranjeni u bazama tiketa, sigurnosnim kopijama, privicima i internim arhivima.
Sigurnosna izloženost sustava podrške usko je vezana uz svaku tajnu koju su klijenti kroz njega podijelili. Kod mnogih pružatelja u toj povijesti ima više osjetljivog nego što misle.
Nikad ne šaljite podršci trajne pristupne podatke
Pristupne podatke poslane kroz tiket podrške treba smatrati potencijalno kompromitiranima.
To uključuje:
- root lozinke
- administratorske lozinke
- API ključeve
- privatne ključeve
- pristupne podatke baza podataka
- lozinke upravljačke ploče
- privremene lozinke stvorene radi rješavanja problema
Ako su pristupni podaci već podijeljeni, promijenite ih.
Sigurniji je pristup privremeni:
- otvorite privremeni račun za podršku
- dajte mu ograničena prava
- oduzmite pristup nakon posla
- koristite konzolu kad SSH nije dostupan
Pružatelj bi trebao moći riješiti problem s vašom uslugom bez vaših trajnih pristupnih podataka.
Što bi pružatelji hostinga trebali promijeniti
Odgovornost nije samo na klijentima.
Pružatelji bi trebali pretpostaviti da u starim tiketima ima osjetljivih podataka i poduzeti mjere da smanje štetu.
Dobre prakse uključuju:
- pregledavanje starih tiketa u potrazi za podacima nalik pristupnima
- uklanjanje nepotrebnih privitaka nakon isteka rokova čuvanja
- zaštitu sustava podrške jakim mehanizmima provjere identiteta
- ograničavanje pristupa zaposlenika korisničkim podacima
- dokumentiranje pravila postupanja s pristupnim podacima
Platformu podrške treba tretirati kao produkcijski sigurnosni sustav. U njoj su korisnički podaci, operativni detalji i moguće autentifikacijski materijal.
Pristup bez pristupnih podataka
U AVS ISP-u od klijenata ne tražimo root lozinke.
Naše VPS i VDS usluge uključuju pristup noVNC konzoli kroz preglednik, iz korisničkog portala. Ako SSH nije dostupan zbog pogreške u vatrozidu, pokvarene konfiguracije, neuspjelog ažuriranja ili drugog problema sa sustavom, klijent na stroj ulazi izravno, bez dijeljenja ijednog trajnog pristupnog podatka.
Kad zatreba pomoć podrške, cilj je klijentu pomoći u dijagnozi bez stvaranja još jedne kopije njegovih tajni.
Naša VPS infrastruktura radi na virtualizaciji temeljenoj na KVM-u, pa granice izolacije počivaju na sklopovski potpomognutoj virtualizaciji koju provodi hipervizor, a ne samo na izolaciji na razini operativnog sustava.
U razgovoru s podrškom trebaju biti dijagnostički podaci, a ne lozinke.
Ako ste ikad poslali pristupne podatke bilo kojem pružatelju hostinga, uključujući nas, najsigurniji je potez isti: promijenite ih.
Ransomware loš dizajn kopija pretvara u trajni gubitak
Najrazorniji dio napada ransomwareom često nije sam početni proboj.
Nego gubitak mogućnosti oporavka.
Ako napadači dođu do produkcijskih sustava i do sigurnosnih kopija dostupnih s njih, prekid se pretvara u trajan gubitak podataka.
Prava strategija sigurnosnih kopija traži odvojenost:
- odvojene pristupne podatke
- odvojene sustave
- odvojene domene kvara
- po mogućnosti odvojene fizičke lokacije
Sigurnosna kopija koja stoji u istom okruženju i štiti se istim pristupnim podacima kao produkcija nije neovisna kopija za oporavak.
AVS ISP drži infrastrukturu na više lokacija i nudi dodatne VPS lokacije klijentima kojima treba zemljopisna odvojenost. Načelo ipak vrijedi svugdje: klijenti bi trebali imati kopije kojima upravljaju sami, a ne samo kopije unutar okruženja svojeg pružatelja hostinga.
Šira pouka za hosting
Pouka ovakvih incidenata jednostavna je:
Sigurnost nisu samo vatrozidi, hipervizori i mrežna zaštita.
To su i obične radne navike.
Lozinka danas kopirana u tiket podrške za koju godinu postaje sigurnosni incident.
Pružatelji hostinga trebali bi sustave graditi pretpostavljajući da će klijenti griješiti. Klijenti bi trebali birati pružatelje kod kojih su te pogreške manje opasne.
Najbolji je tiket podrške onaj koji riješi problem, a da nikad nije sadržavao nijednu tajnu.
Česta pitanja
Trebam li VPS pružatelju dati svoju root lozinku?
Ne. Pružatelj hostinga ne bi smio tražiti trajne pristupne podatke. Privremeni pristup, konzola ili ograničeni računi sigurniji su.
Jesu li tiketi podrške sigurnosni rizik?
Jesu. U tiketima često završe zapisi, detalji konfiguracije, pristupni podaci i korisnički podaci, a čuvaju se godinama.
Što učiniti ako sam lozinku poslao podršci hostinga?
Odmah je promijenite. Promijenite i sve povezane ključeve, tokene i pristupne podatke koji su mogli završiti u istoj poruci.
Izvori
- Security Update: Transparency Regarding a Recent Support Ticket Incident, Virtualizor (3. veljače 2026.) — primarni izvor
- Mass VPS Provider Ransomware Attack Linked to Stolen Credentials from Virtualizor Support Breach, Cyber Kendra (veljača 2026.) — neovisno izvješće