{"componentChunkName":"component---src-templates-blog-template-js","path":"/hr/blog/password-policy-dos-donts-best-practices","result":{"data":{"markdownRemark":{"html":"<p>Pravila za lozinke trebala bi otežati kompromitaciju računa, a da ne otežavaju sigurnu upotrebu više nego što je potrebno.\nNajbolja pravila su jasna, praktična i usklađena s načinom na koji ljudi stvarno rade. Ona potiču upotrebu dugih i jedinstvenih lozinki,\npodržavaju upravitelje lozinki, zahtijevaju višefaktorsku autentifikaciju gdje je primjereno i uklanjaju zastarjele zahtjeve koji potiču\npredvidljivo ponašanje korisnika.</p>\n<p>Ovaj članak objašnjava što bi moderna pravila za lozinke trebala, a što ne bi trebala uključivati, što izbjegavati, koje su najbolje prakse, te donosi predložak koji možete prilagoditi svojoj organizaciji.</p>\n<h2>Što su pravila za lozinke?</h2>\n<p>Pravila za lozinke su skup pravila koja definiraju kako se lozinke stvaraju, pohranjuju, koriste, dijele, mijenjaju i štite.\nOdnose se na zaposlenike, vanjske suradnike, administratore, servisne račune, a ponekad i na korisnike, ovisno o sustavi(ma) na koje se odnose.</p>\n<p>Dobra pravila za lozinke trebala bi odgovoriti na praktična pitanja:</p>\n<ul>\n<li>Koliko lozinke trebaju biti duge?</li>\n<li>Jesu li dopuštene lozinke-izreke (passphrase)?</li>\n<li>Mogu li korisnici zalijepiti lozinke iz upravitelja lozinki?</li>\n<li>Kada se mora promijeniti lozinka?</li>\n<li>Je li višefaktorska autentifikacija obavezna?</li>\n<li>Kako se rješava zajedničko korištenje vjerodajnica?</li>\n<li>Što se događa ako postoji sumnja na kompromitaciju lozinke?</li>\n</ul>\n<p>Cilj nije stvoriti najsloženija moguća pravila. Cilj je smanjiti stvarni rizik.</p>\n<h2>Što treba učiniti u modernoj politici za lozinke</h2>\n<h2>Tražite dovoljnu duljinu</h2>\n<p>Duljina je jedna od najsnažnijih obrana od pogodaka i napada brutalnom silom. Jedan organizacijski minimum često je lakše razumljiv korisnicima i jednostavnije ga je informatičkom timu provoditi nego različita pravila za standardne korisnike, administratore i posebne slučajeve. Praktično je zahtijevati minimalno 16 znakova za sve račune krajnjih korisnika. Dulja lozinka je uvijek bolja, osobito ako korisnici koriste upravitelje lozinki ili nasumično generirane lozinke-izreke.</p>\n<h2>Dopustite duge lozinke i lozinke-izreke</h2>\n<p>Korisnici trebaju imati mogućnost kreiranja lozinki koje su puno dulje od minimuma. Izbjegavajte niske maksimalne granice poput 16 ili 20 znakova. Minimalno 64 znaka je razuman maksimum, a mnogi sustavi mogu podržati i dulje lozinke.</p>\n<p>Dozvolite upotrebu lozinki-izreka ako su duge i nisu temeljene na poznatim citatima, stihovima pjesama, imenu tvrtke ili predvidljivim frazama. Na primjer, lozinka-izreka koja se sastoji od nekoliko nasumičnih riječi obično je sigurnija od kratke lozinke s prisilnim izmjenama slova.</p>\n<h2>Zahtijevajte jedinstvenost</h2>\n<p>Svaki račun mora imati jedinstvenu lozinku. Ponovno korištenje lozinki jedan je od glavnih razloga zašto provala na jednom servisu vodi do kompromitacije računa na drugom. Upravitelj lozinki omogućuje jedinstvene lozinke bez potrebe da korisnici pamte svaku.</p>\n<h2>Podržavajte korištenje upravitelja lozinki</h2>\n<p>Vaša pravila trebala bi izričito dopuštati i poticati odobrene upravitelje lozinki. Korisnicima treba biti omogućeno lijepljenje lozinki u obrasce za prijavu, korištenje automatskog popunjavanja i generiranje lozinki. Blokiranje \"paste\" može se činiti sigurnim, ali često demotivira korištenje snažnih lozinki kroz upravljane alate.</p>\n<h2>Provjeravajte lozinke prema poznatim kompromitiranim lozinkama</h2>\n<p>Treba odbijati lozinke koje se nalaze na popisima provaljenih lozinki, često korištenih lozinki ili na popisu zabranjenih lozinki unutar vaše organizacije. Ovo ima veći učinak od pravila poput “mora sadržavati veliko slovo, broj i simbol\".</p>\n<h2>Zahtijevajte MFA gdje god je to tehnički moguće</h2>\n<p>Višefaktorska autentifikacija treba biti omogućena gdje god je to tehnički moguće, posebno za administratore, udaljeni pristup, cloud servise, email, upravitelje lozinki, financijske sustave i druge sustave visoke vrijednosti. MFA ne zamjenjuje jake lozinke, ali znatno umanjuje posljedice krađe vjerodajnica.</p>\n<p>Dajte prednost MFA otpornom na phishing, kao što su Passkey-evi, hardverski sigurnosni ključevi ili platformni autentifikatori. Aplikacijski autentifikatori su obično sigurniji od SMS-a. MFA temeljena na SMS-u ne smije se koristiti ako je tehnički moguće koristiti bilo koju drugu metodu, jer se brojevi mogu presresti, zamijeniti SIM-om, prebaciti na drugi uređaj ili zloupotrijebiti kroz procese oporavka računa.</p>\n<p>Ovo nije hipotetski problem. 2018. Reddit je objavio da su napadači presreli dvofaktorsku autentifikaciju putem SMS-a i pristupili internim sustavima: <a href=\"https://www.reddit.com/r/announcements/comments/93qnm5/we_had_a_security_incident_heres_what_you_need_to/\" rel=\"nofollow\">https://www.reddit.com/r/announcements/comments/93qnm5/we<em>had</em>a<em>security</em>incident<em>heres</em>what<em>you</em>need_to/</a>. 2021. Coinbase je prijavio da je napadačima ukradena kriptovaluta od najmanje 6000 korisnika korištenjem kompromitiranih vjerodajnica i slabosti u procesu SMS oporavka računa: <a href=\"https://www.reuters.com/technology/coinbase-says-hackers-stole-cryptocurrency-least-6000-customers-2021-10-01/\" rel=\"nofollow\">https://www.reuters.com/technology/coinbase-says-hackers-stole-cryptocurrency-least-6000-customers-2021-10-01/</a>.</p>\n<h2>Mijenjajte lozinke nakon kompromitacije</h2>\n<p>Lozinke treba mijenjati kad postoje dokazi ili opravdana sumnja na kompromitaciju. Primjeri su phishing napadi, malver na korisničkom uređaju, otkrivanje vjerodajnica u provali, sumnjiva aktivnost prijave ili nenamjerno otkrivanje lozinke.</p>\n<h2>Zaštitite zajedničke lozinke na pravi način</h2>\n<p>Dijeljene lozinke treba izbjegavati gdje god je moguće koristiti osobne račune. Ako su zajedničke lozinke neizbježne, trebaju biti pohranjene u odobrenom upravitelju lozinki, pristup treba biti ograničen samo na ovlaštene korisnike, a razmjena kada je moguće mora biti evidentirana.</p>\n<h2>Osigurajte procese za resetiranje lozinki</h2>\n<p>Resetiranje lozinke je često najslabija točka sigurnosti računa. Procesi resetiranja trebaju potvrditi identitet korisnika, linkovi za resetiranje trebaju brzo isteći, koristiti jednokratne kodove i obavještavati korisnika kad je njegova lozinka promijenjena.</p>\n<h2>Što NE raditi u modernoj politici za lozinke</h2>\n<h2>Nemojte forsirati česte promjene lozinke bez opravdanog razloga</h2>\n<p>Obvezne promjene lozinki svakih 30, 60 ili 90 dana često vode do slabijih lozinki. Korisnici tada rade male i predvidljive izmjene poput dodavanja broja ili promjene sezone. NIST-ove smjernice odustale su od rutinske periodične promjene lozinki i umjesto toga zahtijevaju promjenu lozinke kad postoje dokazi o kompromitaciji. Vidjeti sekciju 3.1.1.2.: <a href=\"https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver\" rel=\"nofollow\">https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver</a>. Zahtijevajte promjene nakon sumnje na kompromitaciju, promjene uloga, oporavka računa ili kad lozinka više ne zadovoljava politiku.</p>\n<h2>Nemojte se oslanjati samo na pravila o složenosti</h2>\n<p>Pravila poput \"mora sadržavati veliko slovo, malo slovo, broj i simbol\" ne jamče sigurnost. <code>Password1!</code> zadovoljava mnoge takve zahtjeve, ali je i dalje slaba lozinka. Dajte prednost duljini, jedinstvenosti, nasumičnosti i provjeri prema compromitiranim lozinkama.</p>\n<h2>Nemojte blokirati copy-paste</h2>\n<p>Blokiranje lijepljenja otežava upotrebu upravitelja lozinki. To može navesti korisnike da posegnu za kraćim, lakšim lozinkama. Dopuštajte zaljepljivanje i automatsko popunjavanje osim u iznimnim i dokumentiranim sigurnosnim situacijama.</p>\n<h2>Nemojte dopuštati savjete za lozinke</h2>\n<p>Savjeti za lozinku često otkrivaju previše informacija. Ako se korisnik može sjetiti odgovora iz savjeta, može i napadač. Umjesto toga koristite sigurne procese resetiranja.</p>\n<h2>Nemojte pohranjivati lozinke u čistom tekstu</h2>\n<p>Sustavi nikada ne smiju pohranjivati lozinke u čistom tekstu niti u reverzibilnoj enkripciji. Lozinke treba hashirati modernim, sporim, soljenim algoritmom za hashiranje lozinki kao što su Argon2id, bcrypt, scrypt, ili PBKDF2, ovisno o mogućnostima sustava i regulativi.</p>\n<p>Brzi, opći hash algoritmi kao što su MD5, SHA-1, SHA-256 ili SHA-512 nisu prikladni za hashiranje lozinki sami po sebi. Dizajnirani su da budu brzi, što napadaču olakšava napade nakon provale baze podataka. Za više, pogledajte naš članak o <a href=\"/blog/evolution-of-password-hashing\">evoluciji hashiranja lozinki</a>.</p>\n<h2>Nemojte dijeliti lozinke putem chata ili e-pošte</h2>\n<p>Lozinke se ne smiju slati putem e-pošte, chata, tiketa, dokumenata ili screenshota. Koristite upravitelje lozinki sa sigurnim dijeljenjem i kontrolom pristupa.</p>\n<h2>Nemojte koristiti osobne podatke ili predvidljive uzorke</h2>\n<p>Lozinke ne smiju sadržavati imena, datume rođenja, nazive tvrtke, tipkovničke uzorke, ponavljajuće znakove niti uobičajene zamjene poput <code>@</code> umjesto <code>a</code> ili <code>0</code> umjesto <code>o</code>. Napadači brzo ispituju takve uzorke.</p>\n<h2>Najbolje prakse za organizacije</h2>\n<h2>Postavite jasne minimalne zahtjeve</h2>\n<p>Koristite lako razumljive zahtjeve:</p>\n<ul>\n<li>Jedan minimalni zahtjev za duljinu, npr. 16 znakova za sve korisničke račune</li>\n<li>Dopustite barem 64 znaka maksimalne duljine</li>\n<li>Dopustite razmake i uobičajene simbole</li>\n<li>Dopustite lozinke-izreke i upravitelje lozinki</li>\n<li>Odbijte provaljene i često korištene lozinke</li>\n</ul>\n<h2>Posebno tretirajte privilegirane račune</h2>\n<p>Administratorski, servisni i pristup produkciji zahtijevaju strože kontrole. Tražite jače lozinke, MFA, ograničen pristup, praćenje i trenutnu rotaciju kad dođe do promjene pristupa.</p>\n<h2>Temeljite pristup na ulozi i načelu najmanjih privilegija</h2>\n<p>Jake lozinke ne mogu nadoknaditi prevelike ovlasti. Korisnici trebaju imati pristup samo onim sustavima i tajnama koje su im potrebne za ulogu.</p>\n<h2>Nadgledajte sumnjivu aktivnost</h2>\n<p>Otkrivajte neuobičajene uzorke prijave, pokušaje prijave iz nemogućih lokacija, višestruke neuspjele pokušaje, prijave iz novih država i pristup izvan radnog vremena. Pravila za lozinke trebaju biti nadopunjena praćenjem i odgovorom na incidente.</p>\n<h2>Educirajte korisnike o realnim prijetnjama</h2>\n<p>Obuka treba pokrivati ponovu upotrebu lozinki, phishing, lažne stranice za prijavu, MFA zamor, sigurno dijeljenje i kako prijaviti sumnju na kompromitaciju. Ne okrivljujte korisnike. Olakšajte sigurno ponašanje.</p>\n<h2>Neka pravila budu dovoljno kratka za pridržavanje</h2>\n<p>Pravila za lozinke trebaju biti razumljiva. Ako su preduga, preopćenita ili prestroga, ljudi će ih zaobilaziti. Najbolja pravila su ona koja se stvarno mogu provesti i slijediti.</p>\n<h2>Predložak pravila za lozinke za kopiranje</h2>\n<p>Koristite sljedeći predložak kao početnu točku. Prilagodite tekst u zagradama prema vašoj organizaciji, sustavima, razini rizika i zakonskim zahtjevima.</p>\n<pre><code class=\"language-text\">Pravila za lozinke\n\nVerzija: [1.0]\nVlasnik: [Odjel za sigurnost / IT]\nDatum stupanja na snagu: [GGGG-MM-DD]\nCiklus pregleda: [Svakih 12 mjeseci]\n\n1. Svrha\n\nOva pravila definiraju zahtjeve za kreiranje, korištenje, pohranu, dijeljenje i promjenu lozinki za [Naziv organizacije]. Svrha je smanjiti rizik od neovlaštenog pristupa, krađe vjerodajnica, kompromitacije računa i gubitka podataka.\n\n2. Opseg\n\nOva pravila odnose se na sve zaposlenike, vanjske suradnike, privremeno osoblje, pružatelje usluga i sve druge korisnike koji pristupaju sustavima, aplikacijama, mrežama, cloud servisima ili podacima [Naziv organizacije].\n\nOva pravila odnose se na krajnje korisničke račune, privilegirane račune, servisne račune, dijeljene račune i svaki sustav gdje su lozinke korištene za autentifikaciju.\n\n3. Zahtjevi za kreiranje lozinki\n\nSve lozinke moraju ispunjavati sljedeće zahtjeve:\n\n- Računi krajnjih korisnika moraju koristiti lozinke od najmanje 16 znakova.\n- Lozinke moraju biti jedinstvene i ne smiju se koristiti na više poslovnih ili privatnih računa.\n- Lozinke ne smiju sadržavati imena, korisnička imena, nazive tvrtke, datume rođenja, tipkovničke uzorke, ponavljajuće znakove ili druge lako pogađene informacije.\n- Lozinke ne smiju biti temeljene na uobičajenim frazama, citatima, stihovima pjesama niti predvidljivim zamjenama.\n- Lozinke ne smiju biti na popisima poznatih provaljenih lozinki ili često korištenih lozinki.\n- Lozinke mogu sadržavati razmake, simbole, brojeve, velika i mala slova.\n- Lozinke-izreke su dozvoljene ako su duge, jedinstvene i nisu temeljene na predvidivim ili javnim frazama.\n\n4. Upravitelji lozinki\n\n[Naziv organizacije] zahtijeva ili snažno preporučuje korištenje odobrenog upravitelja lozinki za kreiranje, pohranu i razmjenu lozinki.\n\nKorisnici smiju koristiti generator lozinki, automatsko popunjavanje i copy-paste funkcije odobrenog upravitelja lozinki. Lozinke se ne smiju pohranjivati u preglednicima, tablicama, dokumentima, aplikacijama za bilješke, e-pošti, chat porukama, snimkama ekrana niti neodobrenim alatima.\n\n5. Višefaktorska autentifikacija\n\nVišefaktorska autentifikacija mora biti omogućena gdje god je tehnički moguće, uključujući (ali ne ograničavajući se na):\n\n- Računi e-pošte\n- Sustavi daljinskog pristupa\n- Računi upravitelja lozinki\n- Cloud servisi\n- Administratorski računi\n- Financijski, kadrovski i drugi visokorizični sustavi\n- Svi sustavi klasificirani kao [povjerljivi / kritični]\n\nKada je dostupno, korisnici moraju koristiti MFA otpornu na phishing kao što su passkey-evi, hardverski sigurnosni ključevi ili autentifikatori platforme. Aplikacijski autentifikatori su poželjniji od SMS-a. MFA putem SMS-a zabranjena je ako je moguće koristiti bilo koju jaču metodu i može se koristiti samo kada nema jače MFA opcije.\n\n6. Promjene lozinki\n\nLozinke se moraju odmah promijeniti kada:\n\n- Je lozinka poznata ili se sumnja na njenu kompromitaciju.\n- Je korisnik unio lozinku na sumnjivu phishing stranicu.\n- Je lozinka podijeljena neovlaštenoj osobi.\n- Je malware ili neovlašteni pristup detektiran na uređaju korisnika.\n- Se lozinka pojavi u poznatoj povredi podataka.\n- Se promijeni uloga ili zaposlenje privilegiranog korisnika.\n- IT ili sigurnost zatraže promjenu lozinke.\n\nRutinirano istjecanje lozinki nije obavezno osim kad to zahtijeva zakon, regulativa, ugovor ili tehnička ograničenja. Lozinke se ne smiju mijenjati malim predvidivim izmjenama prethodne lozinke.\n\n7. Dijeljenje lozinki\n\nLozinke se ne smiju dijeliti putem e-maila, chata, tiketa, dokumenata, screenshota, telefona niti usmenom komunikacijom.\n\nZajedničke vjerodajnice su dopuštene samo kada osobni računi nisu tehnički mogući ili kad ih izričito odobri [sigurnost / IT]. Odobrene zajedničke vjerodajnice moraju se pohranjivati i dijeliti putem odobrenog upravitelja lozinki s pristupom ograničenim na ovlaštene korisnike.\n\n8. Privilegirani računi\n\nPrivilegirani računi moraju koristiti jedinstvene lozinke koje se ne koriste na nijednom standardnom računu. Privilegirani računi moraju koristiti MFA gdje god je to moguće i redovito se pregledavati.\n\nPrivilegirane lozinke trebaju se rotirati kad administrator napusti organizaciju, promijeni ulogu, više ne treba pristup ili postoji sumnja na kompromitaciju.\n\n9. Servisni računi i tajne aplikacija\n\nLozinke servisnih računa, API-ključevi, tokeni i tajne aplikacija moraju biti pohranjene u odobrenom sustavu za upravljanje tajnama ili upravitelju lozinki.\n\nServisne vjerodajnice ne smiju biti ugrađene u izvorni kod, konfiguracijske datoteke, slike, dokumentaciju ili skripte osim kad su zaštićene odobrenim sustavom za upravljanje tajnama.\n\n10. Resetiranje lozinke i oporavak računa\n\nProcesi resetiranja lozinke moraju potvrditi identitet korisnika prije povratka pristupa. Linkovi za resetiranje i privremene lozinke moraju biti jednokratne, brzo isteći i biti dostavljene putem odobrenih kanala.\n\nKorisnici moraju biti obaviješteni kada je njihova lozinka promijenjena ili resetirana. Privremene lozinke moraju se promijeniti pri prvoj prijavi.\n\n11. Tehničke kontrole\n\nSustavi koji pohranjuju ili obrađuju lozinke moraju:\n\n- Nikada ne pohranjivati lozinke u čistom tekstu.\n- Hashirati lozinke koristeći odobreni, moderni, soljeni algoritam: PBKDF2, scrypt, bcrypt ili Argon2.\n- Ne koristiti MD5, SHA-1, SHA-256, SHA-512 ni druge brze generalne hash-algoritme sami za hashiranje lozinki.\n- Štititi autentifikacijske krajnje točke limitiranjem broja pokušaja ili ekvivalentnim kontrolama.\n- Odbijati često korištene, slabe i poznate kompromitirane lozinke.\n- Dopuštati korisnicima zaljepljivanje lozinki iz upravitelja.\n- Podržavati razumnu duljinu lozinke, uključujući barem 64 znaka gdje je to moguće.\n- Evidentirati sigurnosno relevantne događaje prijave.\n\n12. Prijava sumnje na kompromitaciju\n\nKorisnici moraju odmah prijaviti sumnju na kompromitaciju lozinke, phishing, neuobičajene zahtjeve za prijavu, MFA zahtjeve koje nisu inicirali ili slučajno otkrivanje lozinki na [sigurnosni / IT kontakt].\n\n13. Iznimke\n\nIznimke od ovih pravila moraju biti dokumentirane, procijenjene po riziku, vremenski ograničene i odobrene od strane [sigurnosnog / IT vodstva]. Gdje je moguće, treba primijeniti kompenzacijske kontrole.\n\n14. Provedba\n\nNepridržavanje ovih pravila može dovesti do uklanjanja pristupa, obavezne sigurnosne obuke, disciplinskih mjera ili drugih aktivnosti u skladu s pravilima [Naziv organizacije] i primjenjivim zakonom.\n\n15. Pregled\n\nOva pravila trebaju se pregledavati najmanje godišnje ili nakon značajnih promjena sustava, prijetnji, zakonskih zahtjeva ili poslovanja.\n</code></pre>\n<h2>Završne misli</h2>\n<p>Snažna pravila za lozinke ne bi trebala otežavati život korisnicima, nego uklanjati loše navike, poticati upravitelje lozinki, koristiti MFA i brzo reagirati kad su vjerodajnice kompromitirane. Pravila neka budu praktična, provediva i usmjerena na stvarne napade poput phishinga, ponovne uporabe lozinki, credential stuffing-a i kompromitiranih računa.</p>","frontmatter":{"date":"May 07, 2026","slug":"password-policy-dos-donts-best-practices","title":"Pravila za lozinke: Što treba, što ne treba, najbolje prakse i predložak za kopiranje","description":"Saznajte što moderna pravila za lozinke trebaju zahtijevati, kojih se zastarjelih pravila treba kloniti te iskoristite praktičan predložak za svoju organizaciju.","author":"Sascha Pfeiffer","featuredImage":null}}},"pageContext":{"slug":"password-policy-dos-donts-best-practices","lang":"hr","langPathPrefix":"/hr"}},"staticQueryHashes":["2149092236","3128451518","3192060438"]}