Politika hesiel by mala sťažiť kompromitovanie účtov, a pritom zbytočne neuťažovať bezpečné správanie používateľov.\nNajlepšie politiky sú prehľadné, praktické a prispôsobené realite práce ľudí. Podporujú dlhé, jedinečné heslá,\numožňujú použitie správcov hesiel, vyžadujú viacfaktorové overenie tam, kde je to vhodné, a odstraňujú zastarané pravidlá,\nktoré nútia používateľov voliť predvídateľné postupy.
\nTento článok vysvetľuje, čo by mala moderná politika hesiel vyžadovať, čomu sa vyhnúť, najlepšie praktiky a ponúka šablónu, ktorú môžete priamo použiť vo svojej organizácii.
\nPolitika hesiel je súbor pravidiel, ktoré definujú spôsob vytvárania, uchovávania, používania, zdieľania, menenia a ochrany hesiel.\nVzťahuje sa na zamestnancov, dodávateľov, administrátorov, servisné účty a niekedy aj na zákazníkov — podľa rozsahu systémov.
\nDobrá politika hesiel by mala odpovedať na praktické otázky:
\nCieľom nie je vytvoriť čo najkomplikovanejšiu sadu pravidiel. Cieľom je reálne znížiť riziko.
\nDĺžka hesla je jeden z najúčinnejších spôsobov ochrany pred hádaním a útokmi hrubou silou. Jediné minimum platné pre celú organizáciu býva pochopiteľnejšie pre používateľov aj pre IT tím ako rozdielne pravidlá pre štandardných používateľov a adminov. Praktickým štandardom je minimálne 16 znakov pre všetky účty využívané ľuďmi. Dlhšie je lepšie, najmä ak používateľ využíva správcu hesiel alebo náhodne generované prístupové frázy.
\nPoužívatelia by mali mať možnosť vytvoriť heslá omnoho dlhšie ako minimálna požiadavka. Vyhnite sa nízkym maximálnym limitom ako 16 alebo 20 znakov. Maximálna dĺžka aspoň 64 znakov je rozumný základ a mnohé systémy zvládnu podporiť aj viac.
\nPrístupové frázy sú povolené, ak sú dlhé a nie sú založené na známych citátoch, textoch piesní, názvoch spoločností alebo predvídateľných frázach. Zoskupenie viacerých náhodných slov býva lepšie ako krátke heslá s nútenými zámennými znakmi.
\nKaždý účet musí mať jedinečné heslo. Opätovné používanie hesiel je hlavnou príčinou, prečo únik v jednej službe vedie k prevzatiu účtov v iných systémoch. Správca hesiel umožňuje mať jedinečné heslá bez potreby všetky si pamätať.
\nVaša politika by mala výslovne povoľovať a podporovať používanie schváleného správcu hesiel. Môžete povoliť vkladanie hesiel do prihlasovacích formulárov, používanie automatického vypĺňania aj generovanie náhodných hesiel. Blokovanie vkladania z \"Copy-Paste\" môže pôsobiť ochranne, ale často odrádza od používania silných správ hesiel.
\nHeslá by mali byť odmietnuté, ak sa nachádzajú v databázach únikov, medzi často používanými heslami alebo na interných \"deny listoch\". Je to užitočnejšie než nútenie používať napríklad jedno veľké písmeno, jednu číslicu a symbol.
\nViacfaktorová autentizácia by mala byť povolená všade, kde je to možné, predovšetkým pre administrátorov, vzdialený prístup, cloudové služby, e-mail, správcov hesiel, finančné systémy a ďalšie kritické prostredia. MFA nenahrádza silné heslo, ale výrazne znižuje dopad, ak sú prihlasovacie údaje kompromitované.
\nUprednostnite MFA odolné voči phishingu, napríklad passkeys, hardvérové bezpečnostné kľúče alebo platformové autentizátory. Aplikácie generujúce kódy sú vo všeobecnosti lepšie ako SMS. MFA cez SMS nesmie byť využité, ak existuje iná technická možnosť MFA, pretože telefónne čísla môžu byť zachytené, zneužité cez SIM swap, prenesené, alebo zneužité pri obnovovaní účtu.
\nToto nie je teória. V roku 2018 Reddit oznámil útok kombinujúcí ukradnuté SMS druhého faktora pre prístup k vnútorným systémom: https://www.reddit.com/r/announcements/comments/93qnm5/wehadasecurityincidenthereswhatyouneed_to/. V roku 2021 Coinbase informoval o odcudzení kryptomeny najmenej 6 000 zákazníkov cez ukradnuté prihlasovacie údaje a zraniteľnosť SMS obnovy: https://www.reuters.com/technology/coinbase-says-hackers-stole-cryptocurrency-least-6000-customers-2021-10-01/.
\nHeslo sa musí vymeniť, ak existuje dôkaz alebo odôvodnené podozrenie na kompromitáciu — phishing, malware v zariadení používateľa, únik údajov, podozrivé prihlasovanie alebo náhodné zverejnenie hesla.
\nZdieľané heslá treba minimalizovať. Ak sa im nedá vyhnúť, musia byť uložené v schválenom správcovi hesiel, prístup k nim majú len oprávnení používatelia a zdieľanie sa musí logovať, kde je to možné.
\nReset hesla je často najslabším bodom bezpečnosti účtov. Oboznámenie identity používateľa je povinné, odkazy na reset musia rýchlo exspirovať, tokeny na reset by mali byť jednorazové a používateľ má byť informovaný o zmene hesla.
\nNútená zmena hesla každých 30, 60 alebo 90 dní vedie často k slabším heslám. Používatelia majú tendenciu meniť len málo, napríklad doplniť číslo alebo meniť sezónu. Digitálne smernice NIST opustili periodickú výmenu hesiel a vyžadujú zmenu iba pri dôkaze kompromitácie. Viď sekcia 3.1.1.2: https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver. Vyžadujte výmenu po podozrení na kompromitáciu, zmene role, obnove účtu alebo ak heslo nevyhovuje politike.
\nPravidlá typu \"musí obsahovať veľké písmeno, malé písmeno, číslo a symbol\" negarantujú silu hesla. Password1! spĺňa mnohé pravidlá, ale je stále slabé. Uprednostnite dĺžku, jedinečnosť, náhodnosť a preverené heslá voči únikom.
Blokovanie \"Copy-Paste\" sťažuje používanie správcov hesiel. To môže viesť k voľbe kratších hesiel, ktoré si ľahko zapamätajú. Povoliť vloženie a automatické vypĺňanie — zakážte len, ak je na to vážny bezpečnostný dôvod.
\nNápovedy zvyčajne prezradia priveľa. Ak si používateľ vie na základe nápovedy heslo pripomenúť, útočník ho môže uhádnuť tiež. Namiesto toho využívajte bezpečné procesy resetu.
\nHeslá nikdy nesmú byť uložené v čitateľnej forme či reverzibilne zašifrované. Musia byť hašované modernými, pomalými algoritmami so soľou, napríklad Argon2id, bcrypt, scrypt alebo PBKDF2, na základe možností systému a požiadaviek zákonov.
\nRýchle hašovacie algoritmy ako MD5, SHA-1, SHA-256 či SHA-512 nie sú vhodné na ukladanie hesiel bez ďalších opatrení. Ich účel je rýchlosť, čo v prípade úniku uľahčuje útoky hrubou silou. Pozrite si tiež náš článok o vývoji hashovania hesiel.
\nHeslá sa nesmú posielať cez e-mail, chat, tikety, dokumenty ani screenshoty. Používajte správcu hesiel s bezpečným zdieľaním a kontrolou prístupov.
\nV heslách nesmú byť mená, dátumy narodenia, názvy spoločností, klávesnicové vzory, opakované znaky či bežné substitúcie ako @ namiesto a či 0 za o. Útočníci tieto vzory bežne testujú.
Používajte ľahko pochopiteľné požiadavky:
\nAdministrátorské účty, servisné účty, prístup na produkciu si vyžadujú prísnejšie kontroly. Vyžadujte silnejšie heslá, MFA, obmedzený prístup, monitoring a okamžitú rotáciu pri zmene oprávnení.
\nAni tie najsilnejšie heslá nevyvážia prílišné oprávnenia. Používateľ má mať prístup len k systémom a tajomstvám, ktoré potrebuje pre svoju prácu.
\nDetekujte nezvyčajné prihlasovania, nemožné cestovanie, opakované chyby v hesle, prihlasovanie z nových krajín či mimo bežného pracovného času. Politika hesiel musí byť podporená monitoringom a reakciou na incidenty.
\nŠkolenia sa majú zamerať na opätovné použitie hesla, phishing, falošné prihlasovacie stránky, MFA fatigue, bezpečné zdieľanie a spôsob nahlásenia podozrenia. Nenechávajte vinu len na používateľoch — umožnite bezpečné správanie jednoduchým spôsobom.
\nPolitika hesiel musí byť pochopiteľná. Ak je príliš dlhá, nejasná alebo príliš prísna, ľudia ju budú obchádzať. Najlepšia politika je taká, ktorú možno naozaj vynucovať a dodržiavať.
\nNasledujúcu šablónu môžete využiť ako základ. Upraviť si ju môžete podľa [Vašej organizácie], systémov, úrovne rizika a zákonných požiadaviek.
\nPolitika hesiel\n\nVerzia: [1.0]\nVlastník: [Bezpečnostné/IT oddelenie]\nÚčinnosť od: [RRRR-MM-DD]\nRevízny cyklus: [Každých 12 mesiacov]\n\n1. Účel\n\nTáto politika definuje požiadavky na vytváranie, používanie, uchovávanie, zdieľanie a zmenu hesiel v [Názov organizácie]. Cieľom je znížiť riziko neoprávneného prístupu, krádeže údajov, prevzatia účtu a straty dát.\n\n2. Rozsah\n\nPolitika platí pre všetkých zamestnancov, dodávateľov, dočasný personál, poskytovateľov služieb a ďalšie osoby, ktoré pristupujú k systémom, aplikáciám, sieťam, cloudovým službám alebo dátam [Názov organizácie].\n\nPlatí na štandardné účty, privilegované účty, servisné účty, zdieľané účty a akýkoľvek systém, kde sa na autentizáciu používa heslo.\n\n3. Požiadavky na vytváranie hesiel\n\nVšetky heslá musia spĺňať nasledovné:\n\n- Účty pre fyzických používateľov musia mať heslo aspoň 16 znakov.\n- Heslá musia byť jedinečné a nesmú sa opakovane použiť v pracovnom či osobnom prostredí.\n- Heslá nesmú obsahovať mená, používateľské mená, názov spoločnosti, dátumy narodenia, klávesnicové vzory, opakované znaky či ľahko uhádnuteľné informácie.\n- Heslá nesmú byť založené na bežných frázach, citátoch, textoch piesní či predvídateľných substitúciách.\n- Nesmejú sa nachádzať v zoznamoch uniknutých či bežne používaných hesiel.\n- V hesle môžu byť medzery, symboly, čísla, veľké a malé písmená.\n- Prístupové frázy sú povolené ak sú dlhé, jedinečné a nie verejne známe alebo predvídateľné.\n\n4. Správca hesiel\n\n[Názov organizácie] vyžaduje alebo dôrazne odporúča použitie schváleného správcu hesiel na vytváranie, uchovávanie a zdieľanie hesiel.\n\nPoužívatelia môžu využívať generovanie hesiel, automatické vypĺňanie a kopírovanie/vkladanie z povoleného správcu hesiel. Heslá nesmú byť uložené v prehliadačoch, tabuľkách, dokumentoch, poznámkach, e-maile, chate, screenshotoch ani v neschválených pomôckach.\n\n5. Viacfaktorová autentizácia\n\nViacfaktorová autentizácia (MFA) musí byť nasadená všade, kde je to technicky možné, vrátane (nie však výlučne):\n\n- E-mailových účtov\n- Systémov vzdialeného prístupu\n- Účtov správcu hesiel\n- Cloudových služieb\n- Administrátorských účtov\n- Finančných, HR a iných rizikových systémov\n- Každého systému klasifikovaného ako [dôverný/kritický]\n\nKde je možné, musia používatelia zvoliť MFA odolné voči phishingu — passkeys, hardvérové bezpečnostné kľúče, platformové autentizátory. Aplikačné autentizátory sú preferované pred SMS. MFA cez SMS je zakázané, ak existuje iná technická možnosť, a môže sa výnimočne použiť iba ak neexistuje bezpečnejší spôsob MFA.\n\n6. Zmena hesiel\n\nHeslá sa musia okamžite zmeniť, ak:\n\n- Je heslo známe alebo existuje podozrenie na kompromitáciu.\n- Používateľ zadal heslo na podozrivé/phishingové stránky.\n- Heslo bolo zdieľané s neoprávnenou osobou.\n- Na zariadení používateľa bol detekovaný malware alebo neoprávnený prístup.\n- Heslo sa objavilo v známom úniku dát.\n- Došlo k zmene role alebo odchodu privilegovaného používateľa.\n- IT alebo bezpečnostné oddelenie na to vyzve.\n\nRutinná expirácia hesiel nie je vyžadovaná, pokiaľ to neprikazuje zákon, zmluva či obmedzenie systému. Heslo sa nesmie meniť malými predvídateľnými úpravami predchádzajúceho.\n\n7. Zdieľanie hesiel\n\nHeslá sa nesmú zdieľať e-mailom, chatom, tiketmi, dokumentmi, screenshotoch, telefonicky ani ústne.\n\nZdieľané účty sú povolené len ak nie je technicky možné založiť individuálny účet, alebo po výslovnom schválení [Bezpečnosti/IT]. Zdieľané údaje sa musia ukladať a zdieľať cez schváleného správcu hesiel s obmedzeným prístupom.\n\n8. Privilegované účty\n\nPrivilegované účty musia používať jedinečné heslá nepoužívané nikde inde. Musia mať povinne MFA a byť pravidelne revidované.\n\nPrivilegované heslá sa rotujú pri odchode administrátora, zmene role, ukončení prístupu alebo podozrení na kompromitáciu.\n\n9. Servisné účty a aplikačné tajomstvá\n\nHeslá pre servisné účty, API kľúče, tokeny a ďalšie tajomstvá sa uchovávajú v schválenom systéme pre správu tajomstiev alebo správcu hesiel.\n\nTieto údaje nesmú byť uložené v zdrojovom kóde, konfiguračných súboroch, obrázkoch, dokumentácii ani skriptoch, pokiaľ nie sú adekvátne chránené schváleným procesom.\n\n10. Reset hesla a obnova účtu\n\nProcesy obnovy hesiel musia overiť identitu používateľa pred obnovením prístupu. Odkazy a dočasné heslá na reset sú jednorazové, rýchlo exspirované a doručované len schválenými kanálmi.\n\nPoužívateľ musí byť informovaný o zmene/resetovaní hesla. Dočasné heslá sa menia pri prvom prihlásení.\n\n11. Technické opatrenia\n\nSystémy, ktoré ukladajú alebo spracúvajú heslá, musia:\n\n- Nikdy neukladať heslá v čitateľnej podobe.\n- Hašovať heslá pomocou moderného algoritmu: PBKDF2, scrypt, bcrypt alebo Argon2 so soľou.\n- Nepoužívať samotné MD5, SHA-1, SHA-256, SHA-512 ani iné rýchle hašovacie algoritmy.\n- Chrániť autentizačné API/koncové body rate limitingom alebo ekvivalentom.\n- Odmietať slabé, často používané a známe kompromitované heslá.\n- Povoliť používateľom vkladanie hesiel zo správcu hesiel.\n- Podporovať rozumnú dĺžku hesla, minimálne 64 znakov kde je to technicky možné.\n- Logovať bezpečnostne dôležité autentizačné udalosti.\n\n12. Nahlasovanie podozrenia z kompromitácie\n\nPoužívatelia sú povinní bezodkladne nahlásiť podozrenie na kompromitáciu, phishing, nečakané prihlasovacie/MFA výzvy alebo náhodné zverejnenie hesla na [Kontakt na Bezpečnostné/IT oddelenie].\n\n13. Výnimky\n\nVýnimky musia byť zdokumentované, vyhodnotené z pohľadu rizika, časovo obmedzené a schválené [Vedúcim Bezpečnosti/IT]. Je potrebné aplikovať náhradné (kompenzačné) opatrenia kde je to možné.\n\n14. Vynucovanie\n\nNedodržanie tejto politiky môže viesť k odobratiu prístupu, povinnej bezpečnostnej inštruktáži, disciplinárnym krokom či iným opatreniam podľa politiky [Názov organizácie] a platnej legislatívy.\n\n15. Revízia\n\nPolitika sa musí revidovať aspoň raz ročne alebo po významných zmenách v systémoch, rizikách, legislatíve alebo podnikaní.\nSilná politika hesiel nie je o komplikovaní života. Je o odstránení slabých zvykov, podpore správcu hesiel, využívaní viacfaktorového overovania a rýchlej reakcii na únik údajov. Držte sa praktických opatrení, vymáhateľnosti a zamerania na reálne útoky — phishing, credential stuffing, opakované použitia hesiel a kompromitované účty.
","frontmatter":{"date":"May 07, 2026","slug":"password-policy-dos-donts-best-practices","title":"Politika hesiel: Čo robiť, čomu sa vyhnúť, najlepšie praktiky a šablóna na kopírovanie","description":"Zistite, čo by mala moderná politika hesiel vyžadovať, ktorým zastaraným pravidlám sa treba vyhnúť a skopírujte si praktickú šablónu pre Vašu organizáciu.","author":"Sascha Pfeiffer","featuredImage":null}}},"pageContext":{"slug":"password-policy-dos-donts-best-practices","lang":"sk","langPathPrefix":"/sk"}},"staticQueryHashes":["2149092236","3128451518","3192060438"]}