Mo\u017eda \u0107ete se iznenaditi onim \u0161to prona\u0111ete.<\/p>\n
Stare korisni\u010dke naloge lako je zaboraviti jer uglavnom ne izazivaju o\u010digledan problem. Sajt nastavlja da radi, niko se ne \u017eali, a nalog napravljen pre tri godine mo\u017ee da ostane aktivan unedogled.<\/p>\n
Ali pristup poslovnom sajtu ne bi trebalo da bude trajan samo zato \u0161to niko nije zapamtio da ga ukloni.<\/p>\n
Redovna provera korisni\u010dkih pristupa poma\u017ee vam da utvrdite ko mo\u017ee da pristupi va\u0161em WordPress sajtu, \u0161ta mo\u017ee da radi i da li su mu te dozvole i dalje potrebne.<\/p>\n
\u0160ta je provera korisni\u010dkih pristupa WordPress sajtu?<\/span><\/h2>\nProvera korisni\u010dkih pristupa podrazumeva pregled naloga koji imaju pristup va\u0161em sajtu i dozvola koje su im dodeljene.<\/p>\n
Cilj je prili\u010dno jednostavan. Za svaki nalog trebalo bi da mo\u017eete da odgovorite na tri pitanja:<\/p>\n
Ko je ova osoba?<\/strong><\/p>\nZa\u0161to joj je potreban pristup?<\/strong><\/p>\nDa li joj trenutna korisni\u010dka uloga daje vi\u0161e dozvola nego \u0161to joj je potrebno?<\/strong><\/p>\nWordPress ima sistem korisni\u010dkih uloga i dozvola koji odre\u0111uje \u0161ta razli\u010diti korisnici mogu da rade.<\/p>\n
Podrazumevane uloge su:<\/p>\n
\n- Administrator<\/li>\n
- Editor<\/li>\n
- Author<\/li>\n
- Contributor<\/li>\n
- Subscriber<\/li>\n<\/ul>\n
Na standardnoj WordPress instalaciji za jedan sajt, Administrator ima pristup administratorskim funkcijama sajta, dok ostale uloge imaju postepeno ograni\u010denije mogu\u0107nosti.<\/p>\n
Pluginovi i custom razvoj mogu da uvedu i dodatne uloge i dozvole, pa se na va\u0161oj listi korisnika mo\u017ee nalaziti vi\u0161e od ovih pet podrazumevanih uloga.<\/p>\n
Zbog toga je pregled stvarne konfiguracije va\u0161eg sajta korisniji od samog poznavanja naziva standardnih WordPress uloga.<\/p>\n
Kako da proverite ko ima pristup va\u0161em WordPress sajtu?<\/span><\/h2>\nPo\u010dnite od najjednostavnijeg koraka.<\/p>\n
Prijavite se u WordPress i otvorite:<\/p>\n
Korisnici \u2192 Svi korisnici (Users \u2192 All Users)<\/strong><\/p>\nVide\u0107ete naloge registrovane na sajtu i njihove korisni\u010dke uloge.<\/p>\n
Po\u010dnite od naloga koje ne prepoznajete<\/span><\/h3>\nNemojte odmah po\u010deti da bri\u0161ete naloge. Prvo posmatrajte listu kao evidenciju svih ljudi koji su tokom vremena dobili pristup sajtu.<\/p>\n
Neki nalozi \u0107e vam biti potpuno jasni. Drugi mogu pripadati biv\u0161im zaposlenima, prethodnim agencijama, freelancerima koji su zavr\u0161ili projekat pre nekoliko godina ili ljudima koje niko iz trenutnog tima ne prepoznaje.<\/p>\n
Za svakog korisnika postavite slede\u0107a pitanja:<\/p>\n
Da li ova osoba jo\u0161 uvek radi sa nama?<\/strong><\/p>\nDa li joj je i dalje potreban pristup ovom sajtu?<\/strong><\/p>\nDa li njena korisni\u010dka uloga odgovara onome \u0161to zaista treba da radi?<\/strong><\/p>\nPoslednje pitanje je posebno va\u017eno. Nekome zaista mo\u017ee biti potreban pristup WordPressu, a da mu pritom nije potreban pristup svemu u WordPressu.<\/p>\n
Administratorski nalog koji niko ne prepoznaje zahteva dodatnu pa\u017enju. Mo\u017eda je u pitanju samo stari nalog koji su svi zaboravili, ali neo\u010dekivani nalog sa visokim nivoom privilegija mo\u017ee ukazivati i na neovla\u0161\u0107en pristup.<\/p>\n
Umesto da ga odmah obri\u0161ete i smatrate problem re\u0161enim, proverite kada se nalog pojavio i da li postoje druge neo\u010dekivane izmene ili pristupni podaci koje bi trebalo pregledati.<\/p>\n
Kome je zaista potreban administratorski pristup?<\/span><\/h2>\nAdministratorski pristup je prakti\u010dan.<\/p>\n
Neko zatra\u017ei pristup sajtu, napravite mu nalog, izaberete Administrator i nastavite dalje.<\/p>\n
Tako sajtovi vremenom mogu da zavr\u0161e sa mnogo vi\u0161e administratora nego \u0161to je zaista potrebno.<\/p>\n
Administrator mo\u017ee da izvr\u0161ava radnje koje imaju veliki uticaj na WordPress sajt. U zavisnosti od konfiguracije, to mo\u017ee uklju\u010divati upravljanje korisnicima, instaliranje i upravljanje pluginovima i temama, promenu pode\u0161avanja i izmene va\u017enih delova sajta.<\/p>\n
Osobi koja samo objavljuje \u010dlanke nije nu\u017eno potreban taj nivo pristupa.<\/p>\n
Nije potreban ni svakom SEO konsultantu, content editoru ili eksternom saradniku.<\/p>\n
Bolji pristup je da svako dobije nivo pristupa koji mu je potreban za posao koji obavlja.<\/p>\n
Na primer, osobi zadu\u017eenoj za ure\u0111ivanje i objavljivanje sadr\u017eaja mo\u017eda vi\u0161e odgovara uloga Editor nego Administrator.<\/p>\n
Ta\u010dan izbor zavisi od toga \u0161ta osoba treba da radi, kao i od custom uloga i dozvola koje su eventualno pode\u0161ene na sajtu.<\/p>\n
Administratorski pristup treba da bude svesna odluka, a ne podrazumevani odgovor na svaki zahtev za pristup sajtu.<\/strong><\/p>\n![\"WordPress](\"https:\/\/24wp.net\/wp-content\/uploads\/2026\/09\/WP-User-Accesss-text-image-1.png\")
<\/p>\n
\u0160ta uraditi sa nalozima biv\u0161ih zaposlenih i saradnika?<\/span><\/h2>\nOvde po\u010dinju mnogi problemi sa pristupom.<\/p>\n
Zaposleni napusti kompaniju.<\/p>\n
Razvoj projekta se zavr\u0161i.<\/p>\n
Promenite marketing agenciju.<\/p>\n
Freelancer zavr\u0161i jednokratni posao.<\/p>\n
Njihov WordPress nalog ostane aktivan.<\/p>\n
Nekoliko meseci kasnije, niko se vi\u0161e ne se\u0107a za\u0161to je nalog napravljen.<\/p>\n
Kada se ne\u010diji rad na sajtu zavr\u0161i, njegov pristup treba proveriti kao deo procesa odlaska iz kompanije ili zavr\u0161etka saradnje, a ne dve godine kasnije tokom slu\u010dajnog \u010di\u0161\u0107enja naloga.<\/p>\n
Pre nego \u0161to obri\u0161ete WordPress korisnika, proverite da li je taj nalog vlasnik nekog sadr\u017eaja.<\/p>\n
WordPress omogu\u0107ava da sadr\u017eaj povezan sa korisnikom prilikom brisanja naloga dodelite drugom korisniku. Pre nego \u0161to potvrdite brisanje, odlu\u010dite \u0161ta treba da se dogodi sa tim sadr\u017eajem.<\/p>\n
Ne zaboravite aktivne sesije i druge pristupne podatke<\/span><\/h3>\nBrisanje naloga nije jedina stvar o kojoj treba razmi\u0161ljati kada se ne\u010diji pristup menja.<\/p>\n
Ako nalog ostaje aktivan, ali mu smanjujete dozvole, razmotrite i prekid postoje\u0107ih WordPress sesija. U korisni\u010dkom profilu postoji opcija Log Out Everywhere Else<\/strong>, kojom se mogu prekinuti sesije na drugim ure\u0111ajima.<\/p>\nOvo je tako\u0111e dobar trenutak da razmi\u0161ljate \u0161ire od obi\u010dne WordPress lozinke. Ista osoba je tokom rada na sajtu mo\u017eda dobila i druge pristupne podatke, od Application Passwords i SFTP kredencijala do pristupa hostingu ili deployment sistemima.<\/p>\n
Promena jedne lozinke ne uklanja nu\u017eno svaki drugi na\u010din na koji je ta osoba mogla da pristupi sajtu ili uti\u010de na njega.<\/p>\n
Zato bi pravilna provera nakon zavr\u0161etka saradnje trebalo da odgovori na \u0161ire pitanje:<\/p>\n
Koje je sve pristupe ova osoba dobila dok je radila sa nama i da li smo svaki od njih proverili?<\/strong><\/p>\nI zapamtite, uklanjanje WordPress naloga re\u0161ava samo WordPress deo problema.<\/p>\n
Da li vi\u0161e ljudi treba da koristi isti WordPress nalog?<\/span><\/h2>\nNa prvi pogled mo\u017ee delovati jednostavnije.<\/p>\n
Umesto da napravite zasebne naloge za tri osobe, svi koriste ne\u0161to poput:<\/p>\n
marketing@company.com<\/a><\/strong><\/p>\nili zajedni\u010dki:<\/p>\n
admin<\/strong><\/p>\nProblem nastaje kasnije.<\/p>\n
Neko promeni va\u017eno pode\u0161avanje.<\/p>\n
Ko je to uradio?<\/p>\n
Jedna osoba napusti kompaniju.<\/p>\n
Da li sada menjate zajedni\u010dku lozinku svima?<\/p>\n
\u017delite da ukinete pristup samo jednoj osobi.<\/p>\n
Kako to uraditi bez uticaja na ostale?<\/p>\n
Individualni nalozi olak\u0161avaju upravljanje pristupom jer je pristup vezan za konkretnu osobu, a ne za ceo tim.<\/p>\n
Tako\u0111e olak\u0161avaju ukidanje pristupa kada se ne\u010dije odgovornosti promene ili osoba napusti kompaniju.<\/p>\n
Ako vi\u0161e ljudi trenutno koristi jedan administratorski nalog, vredi razmotriti prelazak na zasebne korisni\u010dke naloge.<\/p>\n
\u0160ta je sa dvofaktorskom autentifikacijom?<\/span><\/h2>\nJaka lozinka je va\u017ena, ali je lozinka i dalje samo jedan faktor autentifikacije.<\/p>\n
Dvofaktorska autentifikacija dodaje jo\u0161 jedan korak potvrde identiteta prilikom prijavljivanja.<\/p>\n
WordPress core trenutno nema ugra\u0111enu dvofaktorsku autentifikaciju za standardne instalacije.<\/p>\n
Jedna od opcija je Two Factor<\/strong>, besplatan open-source plugin dostupan u zvani\u010dnom WordPress direktorijumu pluginova. Podr\u017eava vi\u0161e metoda autentifikacije, uklju\u010duju\u0107i TOTP aplikacije za autentifikaciju, kodove putem emaila i rezervne verifikacione kodove.<\/p>\nPostoji va\u017eno ograni\u010denje koje treba uzeti u obzir na sajtovima sa vi\u0161e korisnika.<\/p>\n
Kod osnovnog Two Factor plugina korisnici pode\u0161avaju dvofaktorsku autentifikaciju kroz sopstvene profile. Ako \u017eelite da obavezno kori\u0161\u0107enje 2FA nametnete odre\u0111enim korisnicima ili ulogama u okviru organizacije, bi\u0107e vam potrebna dodatna implementacija ili re\u0161enje koje omogu\u0107ava takvu kontrolu.<\/p>\n
Kod naloga sa visokim nivoom privilegija, posebno administratorskih, dodatni faktor autentifikacije mo\u017ee da smanji rizik povezan sa kompromitovanom lozinkom.<\/p>\n
Ali 2FA ne re\u0161ava lo\u0161e upravljanje pristupom.<\/p>\n
Stari administratorski nalog za\u0161ti\u0107en dvofaktorskom autentifikacijom i dalje je nepotreban administratorski nalog ako toj osobi pristup vi\u0161e nije potreban.<\/p>\n
Za \u0161iru sliku o tome odakle zapravo dolaze bezbednosni rizici u WordPressu, pro\u010ditajte na\u0161 vodi\u010d o bezbednosti WordPressa i podacima koji stoje iza naj\u010de\u0161\u0107ih rizika<\/a><\/span><\/span>.<\/strong><\/span><\/p>\nNe zaboravite WordPress Application Passwords<\/span><\/h2>\nPostoji jo\u0161 jedna vrsta pristupa koju je mnogo lak\u0161e prevideti tokom provere.<\/p>\n
Od WordPress verzije 5.6 postoje Application Passwords<\/strong>, namenjene programskom pristupu sajtu.<\/p>\nTo su zasebni pristupni podaci povezani sa WordPress korisni\u010dkim nalogom. Namenjeni su aplikacijama, integracijama i skriptama koje koriste interfejse kao \u0161to su WordPress REST API i XML-RPC, a ne standardnom prijavljivanju u wp-admin.<\/p>\n
Mo\u017eete ih pregledati u sekciji Application Passwords<\/strong> na profilu odgovaraju\u0107eg korisnika.<\/p>\nU zavisnosti od na\u010dina kori\u0161\u0107enja, WordPress mo\u017ee da prika\u017ee informacije poput naziva dodeljenog Application Passwordu, vremena poslednjeg kori\u0161\u0107enja i IP adrese povezane sa poslednjom upotrebom.<\/p>\n
Pojedina\u010dni Application Password mo\u017ee i zasebno da se opozove.<\/p>\n
Ovo je va\u017eno zato \u0161to promena obi\u010dne WordPress lozinke korisnika ne opoziva automatski njegove Application Passwords<\/strong>.<\/p>\nTo su zasebni pristupni podaci.<\/p>\n
Zamislite da je neka integracija pode\u0161ena pre dve godine pomo\u0107u Application Passworda. Integracija se vi\u0161e ne koristi, ljudi koji su je podesili vi\u0161e ne rade na sajtu, a obi\u010dna WordPress lozinka je u me\u0111uvremenu promenjena.<\/p>\n
Taj Application Password i dalje treba proveriti.<\/p>\n
Tokom provere pristupa pogledajte koji Application Passwords postoje, \u010demu slu\u017ee i da li je svaki od njih i dalje potreban.<\/p>\n
Ako integraciji, aplikaciji ili skripti pristup vi\u0161e nije potreban, opozovite odgovaraju\u0107i pristupni podatak.<\/p>\n
![\"WordPress](\"https:\/\/24wp.net\/wp-content\/uploads\/2026\/09\/WP-User-Access-text-image-2-1.png\")
<\/p>\n
Nemojte zavr\u0161iti proveru pristupa unutar WordPressa<\/span><\/h2>\nUklanjanje starog WordPress naloga ne zna\u010di nu\u017eno da ta osoba vi\u0161e nema pristup infrastrukturi va\u0161eg sajta.<\/p>\n
Koje jo\u0161 pristupe sajtu treba proveriti?<\/span><\/h3>\nWordPress je samo jedan sloj modernog sajta.<\/p>\n
Developeri, agencije i interni timovi tokom rada na sajtu mogu dobiti pristup hostingu, serverima, domenima, repozitorijumima, bazama podataka ili servisima tre\u0107ih strana. Neki od tih pristupa mogu pru\u017eiti znatno ve\u0107u kontrolu nad sajtom od samog WordPress naloga.<\/p>\n
Zato provera pristupa treba da obuhvati i sisteme koji okru\u017euju WordPress, a ne samo naloge koje vidite u okviru Korisnici \u2192 Svi korisnici<\/strong>.<\/p>\nPrincip je isti za svaki servis: utvrdite ko ima pristup, proverite da li mu je i dalje potreban i opozovite pristupne podatke koji vi\u0161e nemaju opravdanu svrhu.<\/p>\n
\n\n\n\n\nPristup koji treba proveriti<\/th>\n \u0160ta proveriti<\/th>\n<\/tr>\n<\/thead>\n \n\nHosting<\/strong><\/td>\nKo mo\u017ee da se prijavi na hosting nalog ili kontrolni panel?<\/td>\n<\/tr>\n \nSFTP \/ FTP<\/strong><\/td>\nKoji korisnici ili pristupni podaci i dalje omogu\u0107avaju pristup fajlovima sajta?<\/td>\n<\/tr>\n \nSSH<\/strong><\/td>\nKo ima pristup serveru i da li su stari SSH klju\u010devi i dalje autorizovani?<\/td>\n<\/tr>\n \nDomen \/ DNS<\/strong><\/td>\nKo mo\u017ee da menja DNS zapise, nameservere ili pode\u0161avanja domena?<\/td>\n<\/tr>\n \nBaza podataka<\/strong><\/td>\nKoji korisnici ili alati imaju direktan pristup bazi podataka?<\/td>\n<\/tr>\n \nCDN \/ bezbednosni servisi<\/strong><\/td>\nKo mo\u017ee da menja firewall, ke\u0161iranje ili bezbednosna pode\u0161avanja?<\/td>\n<\/tr>\n \nAnalitika \/ tracking<\/strong><\/td>\nKoji korisnici i agencije i dalje imaju pristup analitici i tracking nalozima?<\/td>\n<\/tr>\n \nEmail servisi<\/strong><\/td>\nKo ima pristup servisima zadu\u017eenim za transakcione ili druge emailove sa sajta?<\/td>\n<\/tr>\n \nBackup sistemi<\/strong><\/td>\nKo mo\u017ee da pristupi, preuzme, vrati ili obri\u0161e backup sajta?<\/td>\n<\/tr>\n \nGit \/ deployment alati<\/strong><\/td>\nKoji developeri ili timovi i dalje imaju pristup repozitorijumima ili mogu da objave izmene?<\/td>\n<\/tr>\n \nIntegracije tre\u0107ih strana<\/strong><\/td>\nKoji eksterni servisi, API pristupni podaci ili povezane aplikacije i dalje imaju pristup?<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n
Za\u0161to joj je potreban pristup?<\/strong><\/p>\n Da li joj trenutna korisni\u010dka uloga daje vi\u0161e dozvola nego \u0161to joj je potrebno?<\/strong><\/p>\n WordPress ima sistem korisni\u010dkih uloga i dozvola koji odre\u0111uje \u0161ta razli\u010diti korisnici mogu da rade.<\/p>\n Podrazumevane uloge su:<\/p>\n Na standardnoj WordPress instalaciji za jedan sajt, Administrator ima pristup administratorskim funkcijama sajta, dok ostale uloge imaju postepeno ograni\u010denije mogu\u0107nosti.<\/p>\n Pluginovi i custom razvoj mogu da uvedu i dodatne uloge i dozvole, pa se na va\u0161oj listi korisnika mo\u017ee nalaziti vi\u0161e od ovih pet podrazumevanih uloga.<\/p>\n Zbog toga je pregled stvarne konfiguracije va\u0161eg sajta korisniji od samog poznavanja naziva standardnih WordPress uloga.<\/p>\n Po\u010dnite od najjednostavnijeg koraka.<\/p>\n Prijavite se u WordPress i otvorite:<\/p>\n Korisnici \u2192 Svi korisnici (Users \u2192 All Users)<\/strong><\/p>\n Vide\u0107ete naloge registrovane na sajtu i njihove korisni\u010dke uloge.<\/p>\n Nemojte odmah po\u010deti da bri\u0161ete naloge. Prvo posmatrajte listu kao evidenciju svih ljudi koji su tokom vremena dobili pristup sajtu.<\/p>\n Neki nalozi \u0107e vam biti potpuno jasni. Drugi mogu pripadati biv\u0161im zaposlenima, prethodnim agencijama, freelancerima koji su zavr\u0161ili projekat pre nekoliko godina ili ljudima koje niko iz trenutnog tima ne prepoznaje.<\/p>\n Za svakog korisnika postavite slede\u0107a pitanja:<\/p>\n Da li ova osoba jo\u0161 uvek radi sa nama?<\/strong><\/p>\n Da li joj je i dalje potreban pristup ovom sajtu?<\/strong><\/p>\n Da li njena korisni\u010dka uloga odgovara onome \u0161to zaista treba da radi?<\/strong><\/p>\n Poslednje pitanje je posebno va\u017eno. Nekome zaista mo\u017ee biti potreban pristup WordPressu, a da mu pritom nije potreban pristup svemu u WordPressu.<\/p>\n Administratorski nalog koji niko ne prepoznaje zahteva dodatnu pa\u017enju. Mo\u017eda je u pitanju samo stari nalog koji su svi zaboravili, ali neo\u010dekivani nalog sa visokim nivoom privilegija mo\u017ee ukazivati i na neovla\u0161\u0107en pristup.<\/p>\n Umesto da ga odmah obri\u0161ete i smatrate problem re\u0161enim, proverite kada se nalog pojavio i da li postoje druge neo\u010dekivane izmene ili pristupni podaci koje bi trebalo pregledati.<\/p>\n Administratorski pristup je prakti\u010dan.<\/p>\n Neko zatra\u017ei pristup sajtu, napravite mu nalog, izaberete Administrator i nastavite dalje.<\/p>\n Tako sajtovi vremenom mogu da zavr\u0161e sa mnogo vi\u0161e administratora nego \u0161to je zaista potrebno.<\/p>\n Administrator mo\u017ee da izvr\u0161ava radnje koje imaju veliki uticaj na WordPress sajt. U zavisnosti od konfiguracije, to mo\u017ee uklju\u010divati upravljanje korisnicima, instaliranje i upravljanje pluginovima i temama, promenu pode\u0161avanja i izmene va\u017enih delova sajta.<\/p>\n Osobi koja samo objavljuje \u010dlanke nije nu\u017eno potreban taj nivo pristupa.<\/p>\n Nije potreban ni svakom SEO konsultantu, content editoru ili eksternom saradniku.<\/p>\n Bolji pristup je da svako dobije nivo pristupa koji mu je potreban za posao koji obavlja.<\/p>\n Na primer, osobi zadu\u017eenoj za ure\u0111ivanje i objavljivanje sadr\u017eaja mo\u017eda vi\u0161e odgovara uloga Editor nego Administrator.<\/p>\n Ta\u010dan izbor zavisi od toga \u0161ta osoba treba da radi, kao i od custom uloga i dozvola koje su eventualno pode\u0161ene na sajtu.<\/p>\n Administratorski pristup treba da bude svesna odluka, a ne podrazumevani odgovor na svaki zahtev za pristup sajtu.<\/strong><\/p>\n Ovde po\u010dinju mnogi problemi sa pristupom.<\/p>\n Zaposleni napusti kompaniju.<\/p>\n Razvoj projekta se zavr\u0161i.<\/p>\n Promenite marketing agenciju.<\/p>\n Freelancer zavr\u0161i jednokratni posao.<\/p>\n Njihov WordPress nalog ostane aktivan.<\/p>\n Nekoliko meseci kasnije, niko se vi\u0161e ne se\u0107a za\u0161to je nalog napravljen.<\/p>\n Kada se ne\u010diji rad na sajtu zavr\u0161i, njegov pristup treba proveriti kao deo procesa odlaska iz kompanije ili zavr\u0161etka saradnje, a ne dve godine kasnije tokom slu\u010dajnog \u010di\u0161\u0107enja naloga.<\/p>\n Pre nego \u0161to obri\u0161ete WordPress korisnika, proverite da li je taj nalog vlasnik nekog sadr\u017eaja.<\/p>\n WordPress omogu\u0107ava da sadr\u017eaj povezan sa korisnikom prilikom brisanja naloga dodelite drugom korisniku. Pre nego \u0161to potvrdite brisanje, odlu\u010dite \u0161ta treba da se dogodi sa tim sadr\u017eajem.<\/p>\n Brisanje naloga nije jedina stvar o kojoj treba razmi\u0161ljati kada se ne\u010diji pristup menja.<\/p>\n Ako nalog ostaje aktivan, ali mu smanjujete dozvole, razmotrite i prekid postoje\u0107ih WordPress sesija. U korisni\u010dkom profilu postoji opcija Log Out Everywhere Else<\/strong>, kojom se mogu prekinuti sesije na drugim ure\u0111ajima.<\/p>\n Ovo je tako\u0111e dobar trenutak da razmi\u0161ljate \u0161ire od obi\u010dne WordPress lozinke. Ista osoba je tokom rada na sajtu mo\u017eda dobila i druge pristupne podatke, od Application Passwords i SFTP kredencijala do pristupa hostingu ili deployment sistemima.<\/p>\n Promena jedne lozinke ne uklanja nu\u017eno svaki drugi na\u010din na koji je ta osoba mogla da pristupi sajtu ili uti\u010de na njega.<\/p>\n Zato bi pravilna provera nakon zavr\u0161etka saradnje trebalo da odgovori na \u0161ire pitanje:<\/p>\n Koje je sve pristupe ova osoba dobila dok je radila sa nama i da li smo svaki od njih proverili?<\/strong><\/p>\n I zapamtite, uklanjanje WordPress naloga re\u0161ava samo WordPress deo problema.<\/p>\n Na prvi pogled mo\u017ee delovati jednostavnije.<\/p>\n Umesto da napravite zasebne naloge za tri osobe, svi koriste ne\u0161to poput:<\/p>\n marketing@company.com<\/a><\/strong><\/p>\n ili zajedni\u010dki:<\/p>\n admin<\/strong><\/p>\n Problem nastaje kasnije.<\/p>\n Neko promeni va\u017eno pode\u0161avanje.<\/p>\n Ko je to uradio?<\/p>\n Jedna osoba napusti kompaniju.<\/p>\n Da li sada menjate zajedni\u010dku lozinku svima?<\/p>\n \u017delite da ukinete pristup samo jednoj osobi.<\/p>\n Kako to uraditi bez uticaja na ostale?<\/p>\n Individualni nalozi olak\u0161avaju upravljanje pristupom jer je pristup vezan za konkretnu osobu, a ne za ceo tim.<\/p>\n Tako\u0111e olak\u0161avaju ukidanje pristupa kada se ne\u010dije odgovornosti promene ili osoba napusti kompaniju.<\/p>\n Ako vi\u0161e ljudi trenutno koristi jedan administratorski nalog, vredi razmotriti prelazak na zasebne korisni\u010dke naloge.<\/p>\n Jaka lozinka je va\u017ena, ali je lozinka i dalje samo jedan faktor autentifikacije.<\/p>\n Dvofaktorska autentifikacija dodaje jo\u0161 jedan korak potvrde identiteta prilikom prijavljivanja.<\/p>\n WordPress core trenutno nema ugra\u0111enu dvofaktorsku autentifikaciju za standardne instalacije.<\/p>\n Jedna od opcija je Two Factor<\/strong>, besplatan open-source plugin dostupan u zvani\u010dnom WordPress direktorijumu pluginova. Podr\u017eava vi\u0161e metoda autentifikacije, uklju\u010duju\u0107i TOTP aplikacije za autentifikaciju, kodove putem emaila i rezervne verifikacione kodove.<\/p>\n Postoji va\u017eno ograni\u010denje koje treba uzeti u obzir na sajtovima sa vi\u0161e korisnika.<\/p>\n Kod osnovnog Two Factor plugina korisnici pode\u0161avaju dvofaktorsku autentifikaciju kroz sopstvene profile. Ako \u017eelite da obavezno kori\u0161\u0107enje 2FA nametnete odre\u0111enim korisnicima ili ulogama u okviru organizacije, bi\u0107e vam potrebna dodatna implementacija ili re\u0161enje koje omogu\u0107ava takvu kontrolu.<\/p>\n Kod naloga sa visokim nivoom privilegija, posebno administratorskih, dodatni faktor autentifikacije mo\u017ee da smanji rizik povezan sa kompromitovanom lozinkom.<\/p>\n Ali 2FA ne re\u0161ava lo\u0161e upravljanje pristupom.<\/p>\n Stari administratorski nalog za\u0161ti\u0107en dvofaktorskom autentifikacijom i dalje je nepotreban administratorski nalog ako toj osobi pristup vi\u0161e nije potreban.<\/p>\n Za \u0161iru sliku o tome odakle zapravo dolaze bezbednosni rizici u WordPressu, pro\u010ditajte na\u0161 vodi\u010d o bezbednosti WordPressa i podacima koji stoje iza naj\u010de\u0161\u0107ih rizika<\/a><\/span><\/span>.<\/strong><\/span><\/p>\n Postoji jo\u0161 jedna vrsta pristupa koju je mnogo lak\u0161e prevideti tokom provere.<\/p>\n Od WordPress verzije 5.6 postoje Application Passwords<\/strong>, namenjene programskom pristupu sajtu.<\/p>\n To su zasebni pristupni podaci povezani sa WordPress korisni\u010dkim nalogom. Namenjeni su aplikacijama, integracijama i skriptama koje koriste interfejse kao \u0161to su WordPress REST API i XML-RPC, a ne standardnom prijavljivanju u wp-admin.<\/p>\n Mo\u017eete ih pregledati u sekciji Application Passwords<\/strong> na profilu odgovaraju\u0107eg korisnika.<\/p>\n U zavisnosti od na\u010dina kori\u0161\u0107enja, WordPress mo\u017ee da prika\u017ee informacije poput naziva dodeljenog Application Passwordu, vremena poslednjeg kori\u0161\u0107enja i IP adrese povezane sa poslednjom upotrebom.<\/p>\n Pojedina\u010dni Application Password mo\u017ee i zasebno da se opozove.<\/p>\n Ovo je va\u017eno zato \u0161to promena obi\u010dne WordPress lozinke korisnika ne opoziva automatski njegove Application Passwords<\/strong>.<\/p>\n To su zasebni pristupni podaci.<\/p>\n Zamislite da je neka integracija pode\u0161ena pre dve godine pomo\u0107u Application Passworda. Integracija se vi\u0161e ne koristi, ljudi koji su je podesili vi\u0161e ne rade na sajtu, a obi\u010dna WordPress lozinka je u me\u0111uvremenu promenjena.<\/p>\n Taj Application Password i dalje treba proveriti.<\/p>\n Tokom provere pristupa pogledajte koji Application Passwords postoje, \u010demu slu\u017ee i da li je svaki od njih i dalje potreban.<\/p>\n Ako integraciji, aplikaciji ili skripti pristup vi\u0161e nije potreban, opozovite odgovaraju\u0107i pristupni podatak.<\/p>\n Uklanjanje starog WordPress naloga ne zna\u010di nu\u017eno da ta osoba vi\u0161e nema pristup infrastrukturi va\u0161eg sajta.<\/p>\n WordPress je samo jedan sloj modernog sajta.<\/p>\n Developeri, agencije i interni timovi tokom rada na sajtu mogu dobiti pristup hostingu, serverima, domenima, repozitorijumima, bazama podataka ili servisima tre\u0107ih strana. Neki od tih pristupa mogu pru\u017eiti znatno ve\u0107u kontrolu nad sajtom od samog WordPress naloga.<\/p>\n Zato provera pristupa treba da obuhvati i sisteme koji okru\u017euju WordPress, a ne samo naloge koje vidite u okviru Korisnici \u2192 Svi korisnici<\/strong>.<\/p>\n Princip je isti za svaki servis: utvrdite ko ima pristup, proverite da li mu je i dalje potreban i opozovite pristupne podatke koji vi\u0161e nemaju opravdanu svrhu.<\/p>\n\n
Kako da proverite ko ima pristup va\u0161em WordPress sajtu?<\/span><\/h2>\n
Po\u010dnite od naloga koje ne prepoznajete<\/span><\/h3>\n
Kome je zaista potreban administratorski pristup?<\/span><\/h2>\n
<\/p>\n\u0160ta uraditi sa nalozima biv\u0161ih zaposlenih i saradnika?<\/span><\/h2>\n
Ne zaboravite aktivne sesije i druge pristupne podatke<\/span><\/h3>\n
Da li vi\u0161e ljudi treba da koristi isti WordPress nalog?<\/span><\/h2>\n
\u0160ta je sa dvofaktorskom autentifikacijom?<\/span><\/h2>\n
Ne zaboravite WordPress Application Passwords<\/span><\/h2>\n
<\/p>\nNemojte zavr\u0161iti proveru pristupa unutar WordPressa<\/span><\/h2>\n
Koje jo\u0161 pristupe sajtu treba proveriti?<\/span><\/h3>\n
\n\n
\n \nPristup koji treba proveriti<\/th>\n \u0160ta proveriti<\/th>\n<\/tr>\n<\/thead>\n \n Hosting<\/strong><\/td>\n Ko mo\u017ee da se prijavi na hosting nalog ili kontrolni panel?<\/td>\n<\/tr>\n \n SFTP \/ FTP<\/strong><\/td>\n Koji korisnici ili pristupni podaci i dalje omogu\u0107avaju pristup fajlovima sajta?<\/td>\n<\/tr>\n \n SSH<\/strong><\/td>\n Ko ima pristup serveru i da li su stari SSH klju\u010devi i dalje autorizovani?<\/td>\n<\/tr>\n \n Domen \/ DNS<\/strong><\/td>\n Ko mo\u017ee da menja DNS zapise, nameservere ili pode\u0161avanja domena?<\/td>\n<\/tr>\n \n Baza podataka<\/strong><\/td>\n Koji korisnici ili alati imaju direktan pristup bazi podataka?<\/td>\n<\/tr>\n \n CDN \/ bezbednosni servisi<\/strong><\/td>\n Ko mo\u017ee da menja firewall, ke\u0161iranje ili bezbednosna pode\u0161avanja?<\/td>\n<\/tr>\n \n Analitika \/ tracking<\/strong><\/td>\n Koji korisnici i agencije i dalje imaju pristup analitici i tracking nalozima?<\/td>\n<\/tr>\n \n Email servisi<\/strong><\/td>\n Ko ima pristup servisima zadu\u017eenim za transakcione ili druge emailove sa sajta?<\/td>\n<\/tr>\n \n Backup sistemi<\/strong><\/td>\n Ko mo\u017ee da pristupi, preuzme, vrati ili obri\u0161e backup sajta?<\/td>\n<\/tr>\n \n Git \/ deployment alati<\/strong><\/td>\n Koji developeri ili timovi i dalje imaju pristup repozitorijumima ili mogu da objave izmene?<\/td>\n<\/tr>\n \n Integracije tre\u0107ih strana<\/strong><\/td>\n Koji eksterni servisi, API pristupni podaci ili povezane aplikacije i dalje imaju pristup?<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n