Trenutno stanje: PHP2Shell. Dvije kritične PHP ranjivosti (CVSS 9.2) omogućuju zlonamjerni kod bez prijave. Zakrpe od 21. 10. 2026.Što sada učiniti →

Sigurnosna svijest administratora i urednika: security awareness u web timu

Tko održava web-stranice, svaki dan odlučuje o sigurnosti, često a da to ne primijeti. Kako obučiti administratore i urednike prema ulozi i bez bitke prezentacijama.

Stanje 5 min čitanjaUpravljanje i pravo

Ukratko: Security awareness zaposlenika u web timu znači: svaka osoba koja održava web-stranicu poznaje tri do četiri rizika svoje uloge, prepoznaje neobičnosti i prijavljuje ih brzo i bez straha od prijekora. Urednicima trebaju drugi sadržaji nego administratorima. Kratke, ponavljajuće cjeline s primjerima iz vlastitog CMS-a djeluju bolje od godišnje obvezne obuke.

Zašto je upravo sada u središtu web tim

Situacija oko PHP2Shella pokazala je koliko toga u nekoliko dana pada na operatere web-stranica: upozorenja BSI-ja (njemačkog Saveznog ureda za informacijsku sigurnost), obavijesti pružatelja hostinga, savjeti na forumima i društvenim mrežama, među njima i pogrešni. U takvim tjednima ne odlučuju samo administratori, nego i urednici, marketing i asistenti, koju će poruku otvoriti i na koju će poveznicu kliknuti.

Velike vijesti prema iskustvu su povod za prevarante. Računajte s porukama koje se predstavljaju kao pružatelj hostinga, proizvođač CMS-a ili „IT odjel“ i pozivaju na hitnu prijavu ili navodno sigurnosno ažuriranje. Tko poznaje stvarnu situaciju, rjeđe na to nasjeda. Tehničku ranjivost ne zatvara nijedan urednik, ali ukradeni administratorski pristup otvara vrata i bez ranjivosti.

Security awareness zaposlenika: tko što treba?

Obuka za sve s istim slajdovima najčešće promašuje cilj. Smislenije je prilagoditi je ulogama. Sljedeći pregled pomaže pri planiranju:

Uloga Tipični rizici Što osoba treba znati
Urednik, marketing phishing poruke, nesigurno učitavanje datoteka, dijeljeni pristupi provjeriti pošiljatelja, učitavati samo očekivane vrste datoteka, nikada ne prosljeđivati vlastite pristupne podatke
CMS administrator dodaci iz nepoznatog izvora, previše administratorskih računa, stari računi bivših zaposlenika štedljivo dodjeljivati prava, redovito provjeravati račune, proširenja samo uz odobrenje
Administrator poslužitelja neprovjereni savjeti s interneta, izmjene bez zapisnika, zaboravljene testne datoteke procjenjivati izvore, dokumentirati izmjene, poznavati put u hitnom slučaju
Uprava pritisak na brze odluke, nejasne odgovornosti odrediti putove odlučivanja, ozbiljno shvaćati obavijesti, odobriti proračun za prevenciju
Vanjska agencija zajednički pristupi, nedostatak dogovora koristiti vlastite, osobne račune, najavljivati izmjene

Tablica pokazuje i gdje tehnika mora pomoći. Osobni računi umjesto zajedničkih pristupa i dvofaktorska prijava za sve s pravom pisanja skidaju mnogo pritiska s obuke. Kako se to radi, piše u članku Dvofaktorska prijava za administratorske pristupe.

Što urednici trebaju znati, a da ne postanu tehničari

Urednici ne moraju znati što je PHP worker. Ali bi trebali sigurno vladati trima stvarima. Prvo: poziv da se zbog „sigurnosnog incidenta“ ponovno prijave nikada se ne izvršava putem poveznice iz poruke, nego uobičajenim putem u CMS ili upitom administratoru.

Drugo: prijavljivati neobičnosti. Tu spadaju nepoznati korisnički računi na popisu korisnika, stranice ili članci koje nitko nije izradio, iznenadna preusmjeravanja i upozorenja u pregledniku. Urednik web-stranicu često vidi češće od administratora i ranije primjećuje promjene.

Treće: svjesno postupati s učitavanjem. Slike i PDF-ovi su svakodnevica, ali datoteka s neuobičajenim nastavkom, arhiva „za prosljeđivanje“ ili dokument s makroima ne pripada u CMS. Ako se datoteka ne može učitati, to je najčešće namjerno, a ne pogreška koju treba zaobilaziti.

Što administratorima treba dodatno

Za administratore je manje riječ o phishingu, a više o prosudbi pod vremenskim pritiskom. U tjednu PHP2Shella kružili su savjeti koje stručni autori izričito odbacuju, primjerice blokirati sve zahtjeve s PHPSESSID. Pregled takvih zabluda nudi članak Opasni pogrešni savjeti o PHP2Shellu. Dobri administratori prije izmjene konfiguracije provjeravaju primarni izvor, dakle php.net, BSI ili proizvođača.

Tome pripada i disciplina pri izmjenama: što je kada i zašto promijenjeno i kako se može poništiti? Dovoljan je kratak unos u tiket ili wiki. U kritičnom trenutku taj je popis zlata vrijedan jer pokazuje koja je izmjena Vaša, a koja nije.

Naposljetku, administratori bi trebali znati po čemu prepoznaju moguću provalu i što tada ne treba činiti: ne brisati u panici, ne instalirati odmah iznova, nego osigurati i prijaviti. Tipične znakove sažima članak Jesam li već kompromitiran?.

U 90 dana do budnog web tima

Program ne mora biti velik da bi djelovao. Ovi su se koraci pokazali dobrima:

  1. Razjasniti stanje (tjedan 1 do 2): Tko ima koje pristupe CMS-u, hostingu, domeni i poslužitelju? Ukinuti zajedničke račune, blokirati stare račune.
  2. Odrediti put prijave (tjedan 2): Jedna adresa ili kanal za „nešto mi se čini čudno“. Na svaku se prijavu odgovara, čak i ako je bila bezazlena.
  3. Prva kratka cjelina po ulozi (tjedan 3 do 4): 20 minuta, primjeri iz vlastitog CMS-a, snimke zaslona stvarnih izbornika.
  4. Uvesti dvofaktorsku prijavu (do tjedna 6): Za sve s pravom pisanja, s rezervnim kodovima na sigurnom mjestu.
  5. Probna poruka i evaluacija (tjedan 8): Najavljena testna kampanja bez razotkrivanja pojedinaca. Procjenjuje se je li prijavljeno, a ne tko je kliknuo.
  6. Druga cjelina povodom događaja (tjedan 10 do 12): Na primjer aktualna sigurnosna situacija, provedena na vlastitom sustavu.

Uspjeh mjerite prijavama, a ne postotkom klikova. Tim koji mnogo prijavljuje je budan. Tim koji nikad ne prijavljuje ili je savršen ili nesiguran, a prvo je rijetko.

Kako PHP SOS konkretno pomaže?

  • Zajedno s Vama evidentiramo tko ima koje pristupe i pokazujemo zajedničke račune, suvišne administratore i zaboravljene pristupe.
  • Održavamo kratke cjeline po ulozi na daljinu, s primjerima iz Vašeg CMS-a i Vašeg poslužiteljskog okruženja.
  • Zajedno postavljamo put prijave i, ako to želite, procjenjujemo pristigle prijave sumnji.
  • U okviru ugovora o sigurnosnom održavanju ponavljamo cjeline povodom aktualnih događaja i redovito provjeravamo račune.

Zaključak

Sigurnosna svijest u web timu ne nastaje strahom, nego jasnoćom: svatko poznaje svoju ulogu, svoje tipične rizike i put prijave neobičnosti. U kombinaciji s osobnim računima i dvofaktorskom prijavom to je zaštita koja drži i u sljedećem kriznom tjednu.

Česta pitanja

Trebaju li urednici uopće sigurnosnu obuku?

Da. Urednici imaju pristup CMS-u, učitavaju datoteke i primaju poruke e-pošte koje izgledaju kao sistemske poruke. Ne moraju razumjeti tehniku, ali trebaju prepoznati kada je nešto neobično i znati kome to prijaviti.

Koliko često treba obučavati web tim?

Bolje kratko i redovito nego jednom godišnje dugo. Pokazale su se dobrima cjeline od 15 do 20 minuta u razmaku od nekoliko tjedana, dopunjene povodom poput aktualne sigurnosne situacije.

Što učiniti ako je zaposlenik kliknuo na phishing poveznicu?

Odmah ga potaknuti da prijavi, bez prijekora. Zatim promijeniti pogođenu lozinku, prekinuti aktivne sesije i provjeriti je li se s računom nešto mijenjalo. Što prije stigne prijava, šteta je u pravilu manja.

Zamjenjuje li obuka tehničke zaštitne mjere?

Ne. Obuka i tehnika se nadopunjuju. Dvofaktorska prijava, odvojene uloge i ažuran softver hvataju pogreške koje se događaju i dobro obučenim ljudima.

Izvori

Hitni kontakt

Svaki sat se računa. Pišite nam odmah.

Ukratko opišite sustav, verziju PHP-a i opažanje. Javit ćemo Vam se, razjasniti situaciju i raditi na daljinu dok incident nije zaključen i dokumentiran.

Hitna pomoć