# Sigurnosna svijest administratora i urednika: security awareness u web timu

> Sigurnosna svijest za administratore i urednike: koji rizici vrijede po ulozi, kako djeluju kratke obuke i kako web tim osposobiti u 90 dana.

Izvor: https://phpsos.de/hr/blog/sicherheitsbewusstsein-redaktion/  
Stanje: 25.10.2026  
Pružatelj: PHP SOS, PHP hitna pomoć i sigurnost poslužitelja. Hitna pomoć putem WhatsAppa: https://wa.me/491736494914?text=Pozdrav%20PHP%20SOS%2C%20trebamo%20pomo%C4%87%20s%20na%C5%A1im%20PHP%20poslu%C5%BEiteljem.%20Tvrtka%3A%20%E2%80%A6%20Web-stranica%3A%20%E2%80%A6

**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](https://phpsos.de/hr/ratgeber/zwei-faktor-admin/).

## Š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](https://phpsos.de/hr/blog/gefaehrliche-falschtipps/). 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?](https://phpsos.de/hr/php2shell/bin-ich-gehackt-anzeichen/).

## 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](https://phpsos.de/hr/leistungen/security-wartungsvertrag/) 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

- [BSI: informacije za tvrtke](https://www.bsi.bund.de/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [php.net: sigurnosne objave](https://www.php.net/)
