Zaposleni odlaze, agencije se menjaju, a freelanceri završavaju projekte. Njihovi WordPress nalozi i drugi pristupni podaci, međutim, mogu ostati aktivni godinama. Provera korisničkih pristupa pomaže vam da utvrdite ko još uvek može da pristupi sajtu, koje dozvole ima i da li su mu one i dalje potrebne.
Last updated
22. septembar 2026.
Vaš WordPress sajt napravljen je pre pet godina.
Od tada je na njemu radio developer. Dizajner je napravio nekoliko izmena. SEO agencija je imala pristup. Marketing tim je objavljivao sadržaj. Freelancer je rešio jedan problem. Nekoliko zaposlenih je u međuvremenu došlo i otišlo.
Koliko tih ljudi i danas može da se prijavi na vaš sajt?
Ako ne znate odgovor, otvorite Korisnici → Svi korisnici (Users → All Users) u WordPress administraciji.
Možda ćete se iznenaditi onim što pronađete.
Stare korisničke naloge lako je zaboraviti jer uglavnom ne izazivaju očigledan problem. Sajt nastavlja da radi, niko se ne žali, a nalog napravljen pre tri godine može da ostane aktivan unedogled.
Ali pristup poslovnom sajtu ne bi trebalo da bude trajan samo zato što niko nije zapamtio da ga ukloni.
Redovna provera korisničkih pristupa pomaže vam da utvrdite ko može da pristupi vašem WordPress sajtu, šta može da radi i da li su mu te dozvole i dalje potrebne.
Provera korisničkih pristupa podrazumeva pregled naloga koji imaju pristup vašem sajtu i dozvola koje su im dodeljene.
Cilj je prilično jednostavan. Za svaki nalog trebalo bi da možete da odgovorite na tri pitanja:
Ko je ova osoba?
Zašto joj je potreban pristup?
Da li joj trenutna korisnička uloga daje više dozvola nego što joj je potrebno?
WordPress ima sistem korisničkih uloga i dozvola koji određuje šta različiti korisnici mogu da rade.
Podrazumevane uloge su:
Na standardnoj WordPress instalaciji za jedan sajt, Administrator ima pristup administratorskim funkcijama sajta, dok ostale uloge imaju postepeno ograničenije mogućnosti.
Pluginovi i custom razvoj mogu da uvedu i dodatne uloge i dozvole, pa se na vašoj listi korisnika može nalaziti više od ovih pet podrazumevanih uloga.
Zbog toga je pregled stvarne konfiguracije vašeg sajta korisniji od samog poznavanja naziva standardnih WordPress uloga.
Počnite od najjednostavnijeg koraka.
Prijavite se u WordPress i otvorite:
Korisnici → Svi korisnici (Users → All Users)
Videćete naloge registrovane na sajtu i njihove korisničke uloge.
Nemojte odmah početi da brišete naloge. Prvo posmatrajte listu kao evidenciju svih ljudi koji su tokom vremena dobili pristup sajtu.
Neki nalozi će vam biti potpuno jasni. Drugi mogu pripadati bivšim zaposlenima, prethodnim agencijama, freelancerima koji su završili projekat pre nekoliko godina ili ljudima koje niko iz trenutnog tima ne prepoznaje.
Za svakog korisnika postavite sledeća pitanja:
Da li ova osoba još uvek radi sa nama?
Da li joj je i dalje potreban pristup ovom sajtu?
Da li njena korisnička uloga odgovara onome što zaista treba da radi?
Poslednje pitanje je posebno važno. Nekome zaista može biti potreban pristup WordPressu, a da mu pritom nije potreban pristup svemu u WordPressu.
Administratorski nalog koji niko ne prepoznaje zahteva dodatnu pažnju. Možda je u pitanju samo stari nalog koji su svi zaboravili, ali neočekivani nalog sa visokim nivoom privilegija može ukazivati i na neovlašćen pristup.
Umesto da ga odmah obrišete i smatrate problem rešenim, proverite kada se nalog pojavio i da li postoje druge neočekivane izmene ili pristupni podaci koje bi trebalo pregledati.
Administratorski pristup je praktičan.
Neko zatraži pristup sajtu, napravite mu nalog, izaberete Administrator i nastavite dalje.
Tako sajtovi vremenom mogu da završe sa mnogo više administratora nego što je zaista potrebno.
Administrator može da izvršava radnje koje imaju veliki uticaj na WordPress sajt. U zavisnosti od konfiguracije, to može uključivati upravljanje korisnicima, instaliranje i upravljanje pluginovima i temama, promenu podešavanja i izmene važnih delova sajta.
Osobi koja samo objavljuje članke nije nužno potreban taj nivo pristupa.
Nije potreban ni svakom SEO konsultantu, content editoru ili eksternom saradniku.
Bolji pristup je da svako dobije nivo pristupa koji mu je potreban za posao koji obavlja.
Na primer, osobi zaduženoj za uređivanje i objavljivanje sadržaja možda više odgovara uloga Editor nego Administrator.
Tačan izbor zavisi od toga šta osoba treba da radi, kao i od custom uloga i dozvola koje su eventualno podešene na sajtu.
Administratorski pristup treba da bude svesna odluka, a ne podrazumevani odgovor na svaki zahtev za pristup sajtu.
Ovde počinju mnogi problemi sa pristupom.
Zaposleni napusti kompaniju.
Razvoj projekta se završi.
Promenite marketing agenciju.
Freelancer završi jednokratni posao.
Njihov WordPress nalog ostane aktivan.
Nekoliko meseci kasnije, niko se više ne seća zašto je nalog napravljen.
Kada se nečiji rad na sajtu završi, njegov pristup treba proveriti kao deo procesa odlaska iz kompanije ili završetka saradnje, a ne dve godine kasnije tokom slučajnog čišćenja naloga.
Pre nego što obrišete WordPress korisnika, proverite da li je taj nalog vlasnik nekog sadržaja.
WordPress omogućava da sadržaj povezan sa korisnikom prilikom brisanja naloga dodelite drugom korisniku. Pre nego što potvrdite brisanje, odlučite šta treba da se dogodi sa tim sadržajem.
Brisanje naloga nije jedina stvar o kojoj treba razmišljati kada se nečiji pristup menja.
Ako nalog ostaje aktivan, ali mu smanjujete dozvole, razmotrite i prekid postojećih WordPress sesija. U korisničkom profilu postoji opcija Log Out Everywhere Else, kojom se mogu prekinuti sesije na drugim uređajima.
Ovo je takođe dobar trenutak da razmišljate šire od obične WordPress lozinke. Ista osoba je tokom rada na sajtu možda dobila i druge pristupne podatke, od Application Passwords i SFTP kredencijala do pristupa hostingu ili deployment sistemima.
Promena jedne lozinke ne uklanja nužno svaki drugi način na koji je ta osoba mogla da pristupi sajtu ili utiče na njega.
Zato bi pravilna provera nakon završetka saradnje trebalo da odgovori na šire pitanje:
Koje je sve pristupe ova osoba dobila dok je radila sa nama i da li smo svaki od njih proverili?
I zapamtite, uklanjanje WordPress naloga rešava samo WordPress deo problema.
Na prvi pogled može delovati jednostavnije.
Umesto da napravite zasebne naloge za tri osobe, svi koriste nešto poput:
ili zajednički:
admin
Problem nastaje kasnije.
Neko promeni važno podešavanje.
Ko je to uradio?
Jedna osoba napusti kompaniju.
Da li sada menjate zajedničku lozinku svima?
Želite da ukinete pristup samo jednoj osobi.
Kako to uraditi bez uticaja na ostale?
Individualni nalozi olakšavaju upravljanje pristupom jer je pristup vezan za konkretnu osobu, a ne za ceo tim.
Takođe olakšavaju ukidanje pristupa kada se nečije odgovornosti promene ili osoba napusti kompaniju.
Ako više ljudi trenutno koristi jedan administratorski nalog, vredi razmotriti prelazak na zasebne korisničke naloge.
Jaka lozinka je važna, ali je lozinka i dalje samo jedan faktor autentifikacije.
Dvofaktorska autentifikacija dodaje još jedan korak potvrde identiteta prilikom prijavljivanja.
WordPress core trenutno nema ugrađenu dvofaktorsku autentifikaciju za standardne instalacije.
Jedna od opcija je Two Factor, besplatan open-source plugin dostupan u zvaničnom WordPress direktorijumu pluginova. Podržava više metoda autentifikacije, uključujući TOTP aplikacije za autentifikaciju, kodove putem emaila i rezervne verifikacione kodove.
Postoji važno ograničenje koje treba uzeti u obzir na sajtovima sa više korisnika.
Kod osnovnog Two Factor plugina korisnici podešavaju dvofaktorsku autentifikaciju kroz sopstvene profile. Ako želite da obavezno korišćenje 2FA nametnete određenim korisnicima ili ulogama u okviru organizacije, biće vam potrebna dodatna implementacija ili rešenje koje omogućava takvu kontrolu.
Kod naloga sa visokim nivoom privilegija, posebno administratorskih, dodatni faktor autentifikacije može da smanji rizik povezan sa kompromitovanom lozinkom.
Ali 2FA ne rešava loše upravljanje pristupom.
Stari administratorski nalog zaštićen dvofaktorskom autentifikacijom i dalje je nepotreban administratorski nalog ako toj osobi pristup više nije potreban.
Za širu sliku o tome odakle zapravo dolaze bezbednosni rizici u WordPressu, pročitajte naš vodič o bezbednosti WordPressa i podacima koji stoje iza najčešćih rizika.
Postoji još jedna vrsta pristupa koju je mnogo lakše prevideti tokom provere.
Od WordPress verzije 5.6 postoje Application Passwords, namenjene programskom pristupu sajtu.
To su zasebni pristupni podaci povezani sa WordPress korisničkim nalogom. Namenjeni su aplikacijama, integracijama i skriptama koje koriste interfejse kao što su WordPress REST API i XML-RPC, a ne standardnom prijavljivanju u wp-admin.
Možete ih pregledati u sekciji Application Passwords na profilu odgovarajućeg korisnika.
U zavisnosti od načina korišćenja, WordPress može da prikaže informacije poput naziva dodeljenog Application Passwordu, vremena poslednjeg korišćenja i IP adrese povezane sa poslednjom upotrebom.
Pojedinačni Application Password može i zasebno da se opozove.
Ovo je važno zato što promena obične WordPress lozinke korisnika ne opoziva automatski njegove Application Passwords.
To su zasebni pristupni podaci.
Zamislite da je neka integracija podešena pre dve godine pomoću Application Passworda. Integracija se više ne koristi, ljudi koji su je podesili više ne rade na sajtu, a obična WordPress lozinka je u međuvremenu promenjena.
Taj Application Password i dalje treba proveriti.
Tokom provere pristupa pogledajte koji Application Passwords postoje, čemu služe i da li je svaki od njih i dalje potreban.
Ako integraciji, aplikaciji ili skripti pristup više nije potreban, opozovite odgovarajući pristupni podatak.
Uklanjanje starog WordPress naloga ne znači nužno da ta osoba više nema pristup infrastrukturi vašeg sajta.
WordPress je samo jedan sloj modernog sajta.
Developeri, agencije i interni timovi tokom rada na sajtu mogu dobiti pristup hostingu, serverima, domenima, repozitorijumima, bazama podataka ili servisima trećih strana. Neki od tih pristupa mogu pružiti znatno veću kontrolu nad sajtom od samog WordPress naloga.
Zato provera pristupa treba da obuhvati i sisteme koji okružuju WordPress, a ne samo naloge koje vidite u okviru Korisnici → Svi korisnici.
Princip je isti za svaki servis: utvrdite ko ima pristup, proverite da li mu je i dalje potreban i opozovite pristupne podatke koji više nemaju opravdanu svrhu.
| Pristup koji treba proveriti | Šta proveriti |
|---|---|
| Hosting | Ko može da se prijavi na hosting nalog ili kontrolni panel? |
| SFTP / FTP | Koji korisnici ili pristupni podaci i dalje omogućavaju pristup fajlovima sajta? |
| SSH | Ko ima pristup serveru i da li su stari SSH ključevi i dalje autorizovani? |
| Domen / DNS | Ko može da menja DNS zapise, nameservere ili podešavanja domena? |
| Baza podataka | Koji korisnici ili alati imaju direktan pristup bazi podataka? |
| CDN / bezbednosni servisi | Ko može da menja firewall, keširanje ili bezbednosna podešavanja? |
| Analitika / tracking | Koji korisnici i agencije i dalje imaju pristup analitici i tracking nalozima? |
| Email servisi | Ko ima pristup servisima zaduženim za transakcione ili druge emailove sa sajta? |
| Backup sistemi | Ko može da pristupi, preuzme, vrati ili obriše backup sajta? |
| Git / deployment alati | Koji developeri ili timovi i dalje imaju pristup repozitorijumima ili mogu da objave izmene? |
| Integracije trećih strana | Koji eksterni servisi, API pristupni podaci ili povezane aplikacije i dalje imaju pristup? |
Upravljanje pristupom samo je jedan deo održavanja poslovnog sajta pod kontrolom. Isti princip važi za update i tehničke izmene, koje bi trebalo testirati pre nego što stignu na produkciju. Pogledajte zašto je staging sajt važan za WordPress.
Zamislite da bivšem developeru uklonite WordPress nalog, dok njegovi pristupni podaci za hosting ili SFTP i dalje rade.
Sa stanovišta upravljanja pristupom, posao nije završen.
Ne morate od ovoga da pravite veliki projekat.
Počnite od liste WordPress korisnika, a zatim proširite proveru.
Otvorite Korisnici → Svi korisnici (Users → All Users).
Identifikujte svaki administratorski nalog.
Istražite naloge koje ne prepoznajete.
Potvrdite da li je svakoj osobi pristup i dalje potreban.
Proverite da li korisnička uloga odgovara njenim stvarnim odgovornostima.
Pregledajte naloge bivših zaposlenih, agencija, developera i drugih saradnika.
Zamenite nepotrebne zajedničke naloge individualnim nalozima.
Proverite dvofaktorsku autentifikaciju za naloge sa visokim nivoom privilegija.
Proverite Application Passwords na relevantnim korisničkim profilima.
Opozovite pristupne podatke integracija, aplikacija ili skripti koje se više ne koriste.
Prekinite postojeće sesije kada je potrebno ukinuti pristup.
Zatim izađite iz WordPressa i proverite relevantne pristupe hostingu, SFTP-u ili SSH-u, domenu, bazi podataka i ostaloj infrastrukturi.
Na kraju provere trebalo bi da možete da odgovorite na jednostavno pitanje:
Ko trenutno može da pravi izmene na našem sajtu?
Ako odgovor i dalje nije jasan, provera nije završena.
Ne postoji jedan raspored provere koji odgovara svakom sajtu.
Mali poslovni sajt sa dva administratora nema iste potrebe za upravljanjem pristupom kao velika platforma sa desetinama editora, developera i eksternih saradnika.
Praktičan pristup je da proverite pristupe svaki put kada se nešto promeni.
Na primer:
Periodične provere su i dalje korisne jer se svaka promena pristupa ne obradi savršeno u trenutku kada se dogodi.
Što više ljudi i eksternih saradnika radi na sajtu, redovna provera postaje važnija.
Isto važi i za druge komponente koje se vremenom nagomilavaju oko WordPress sajta. Ako već proveravate pristupe, to može biti dobar trenutak da proverite i pluginove od kojih vaš sajt i dalje zavisi.
Šta Evropski akt o pristupačnosti znači za WordPress sajtove? Saznajte koja preduzeća mogu biti obuhvaćena, koje informacije o pristupačnosti mogu biti potrebne i kako da prepoznate probleme sa navigacijom, formama, sadržajem i WordPress komponentama.
Koliko košta WordPress sajt u 2026. godini? Saznajte od čega zavisi cena izrade, šta često nije uključeno u ponudu i kako da uporedite dva WordPress projekta prema obimu, a ne samo prema ceni.
WordPress kontakt forma izgleda kao da radi, ali poruke ne stižu? Saznajte kako da proverite podešavanja forme, SMTP, DNS autentifikaciju, konflikte između plugina i druge moguće uzroke problema sa email isporukom.
Vaš 24wp sajt razvijaju stručnjaci iz Cubes-a - IT kompanije koja deceniju unazad kreira kompleksne IT ekosisteme i stabilne web sisteme.
Posetite cubes.rs