{"componentChunkName":"component---src-templates-blog-template-js","path":"/cs/blog/password-policy-dos-donts-best-practices","result":{"data":{"markdownRemark":{"html":"<p>Heslová politika by měla ztížit kompromitaci účtů, aniž by zbytečně komplikovala bezpečné chování uživatelů.\nNejlepší pravidla jsou jasná, praktická a odpovídají tomu, jak lidé skutečně pracují. Podporují dlouhá a unikátní hesla,\nschvalují používání správce hesel, vyžadují vícestupňové ověřování tam, kde je to vhodné, a ruší stará pravidla, která uživatele nutí k předvídatelnému chování.</p>\n<p>Tento článek vysvětluje, co by měla moderní heslová politika obsahovat, čemu se vyhýbat, osvědčené postupy a nabízí šablonu, kterou si můžete upravit dle potřeb vaší organizace.</p>\n<h2>Co je to heslová politika?</h2>\n<p>Heslová politika je soubor pravidel určujících, jak jsou hesla vytvářena, ukládána, používána, sdílena, měněna a chráněna.\nPlatí pro zaměstnance, dodavatele, administrátory, servisní účty a někdy i zákazníky v závislosti na daných systémech.</p>\n<p>Dobrá heslová politika odpovídá na praktické otázky:</p>\n<ul>\n<li>Jak dlouhá by měla být hesla?</li>\n<li>Jsou povoleny přístupové fráze?</li>\n<li>Mohou uživatelé vkládat hesla ze správce hesel?</li>\n<li>Kdy se musí heslo změnit?</li>\n<li>Je vyžadováno vícestupňové ověření?</li>\n<li>Jak jsou řešeny sdílené přihlašovací údaje?</li>\n<li>Co dělat v případě podezření na kompromitaci hesla?</li>\n</ul>\n<p>Cílem není vytvořit nejsložitější sadu pravidel, ale snížit skutečné riziko.</p>\n<h2>Co dělat v rámci moderní heslové politiky</h2>\n<h2>Vyžadujte dostatečnou délku</h2>\n<p>Délka hesla je jednou z největších obran proti hádání či útokům hrubou silou. Jedno minimální pravidlo pro celou organizaci je často snazší pro uživatele i IT tým než rozlišování mezi běžnými, administrátorskými a speciálními účty. Praktickým výchozím bodem je požadavek na minimálně 16 znaků pro všechny účty lidských uživatelů. Delší hesla jsou lepší, obzvlášť pokud je uživatelé vytváří pomocí správce hesel nebo nahodilých přístupových frází.</p>\n<h2>Povolit dlouhá hesla a přístupové fráze</h2>\n<p>Uživatelé by měli mít možnost používat hesla mnohem delší než minimální požadavek. Vyhněte se nízkým maximům, například 16 nebo 20 znaků. Maximální délka by měla být alespoň 64 znaků, mnohé systémy snesou i více.</p>\n<p>Přístupové fráze by měly být povoleny, pokud jsou dlouhé a nejsou založené na známých citátech, textech písní, názvu firmy nebo předvídatelných frázích. Například fráze sestavená z několika náhodných slov je obvykle lepší než krátké heslo s nucenými záměnami znaků.</p>\n<h2>Vyžadujte jedinečnost</h2>\n<p>Každý účet by měl mít unikátní heslo. Znovupoužívání hesel patří mezi hlavní příčiny, proč prolomení jednoho účtu vede k převzetí dalších. Správce hesel umožňuje jedinečná hesla bez nutnosti je pamatovat.</p>\n<h2>Podporujte správce hesel</h2>\n<p>Vaše politika by měla výslovně povolovat a podporovat schválené správce hesel. Uživatelé by měli mít možnost vkládat hesla do formulářů, používat automatické vyplnění a generovat náhodná hesla. Blokování vkládání působí sice ochranitelsky, ale ve skutečnosti často odrazuje od používání silných hesel ze správce.</p>\n<h2>Kontrolujte hesla proti známým uniklým heslům</h2>\n<p>Hesla by měla být odmítnuta, pokud se nacházejí ve veřejných seznamech uniklých hesel, často používaných hesel nebo na firemním seznamu \"zakázaných\" hesel. Toto je užitečnější než vynucovat např. jedno velké písmeno, číslici a symbol.</p>\n<h2>Vyžadujte MFA, kde je to technicky možné</h2>\n<p>Vícestupňové ověření (MFA) má být povoleno, kdekoliv je to technicky možné, zvláště pro administrátory, vzdálený přístup, cloudové služby, e-maily, správce hesel a finance či jiné citlivé systémy. MFA nenahrazuje silná hesla, ale snižuje dopady při úniku přihlašovacích údajů.</p>\n<p>Preferujte MFA odolné vůči phishingu, například přihlašování pomocí bezpečnostních klíčů, passkeys nebo autentizátorů integrovaných v zařízení. Aplikace pro autentizaci jsou lepší než SMS. Ověření pomocí SMS by se nikdy nemělo používat, pokud je technicky dostupný jiný způsob, protože telefonní čísla mohou být přesměrována, převedena na jiného operátora či zneužita během obnovy účtu.</p>\n<p>Nejde jen o teorii. V roce 2018 Reddit zveřejnil, že útočníci zachytili SMS ověření a získali přístup k interním systémům: <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>. V roce 2021 Coinbase nahlásil, že útočníci zneužili údaje a slabé místo v SMS obnově, aby získali kryptoměny minimálně 6 000 zákazníků: <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>Měňte hesla po kompromitaci</h2>\n<p>Hesla je třeba změnit, když existuje důkaz nebo důvodné podezření na kompromitaci. Například po phishingu, malwaru na zařízení uživatele, úniku přihlašovacích údajů, podezřelé aktivitě nebo nechtěném zveřejnění hesla.</p>\n<h2>Správně zabezpečte sdílené přihlašovací údaje</h2>\n<p>Pokud je možné použít individuální účet, sdílená hesla by se měla vyvarovat. Jsou-li sdílené přihlašovací údaje nevyhnutelné, uchovávejte je pouze ve schváleném správci hesel, přístup omezte na oprávněné osoby a sdílení zaznamenávejte.</p>\n<h2>Zabezpečte procesy pro reset hesla</h2>\n<p>Obnova hesla je často nejslabším bodem zabezpečení účtu. Ověřujte identitu uživatele, expirujte odkazy pro reset rychle, používejte jednorázové tokeny a informujte uživatele o změně hesla.</p>\n<h2>Čemu se v moderní heslové politice vyhnout</h2>\n<h2>Nevynucujte častou změnu hesel bez důvodu</h2>\n<p>Povinná změna hesel každých 30, 60 nebo 90 dní často vede ke slabším heslům. Uživatelé dělají drobné předvídatelné změny, například přidají číslo nebo změní roční období. NIST již rutinní expirační intervaly nedoporučuje, místo toho požaduje změnu po podezření na kompromitaci. Viz sekce 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>. Požadujte změnu hesla pouze po podezření na kompromitaci, změně role, obnově účtu nebo když heslo již nesplňuje aktuální politiku.</p>\n<h2>Nespoléhejte pouze na pravidla \"komplexity\"</h2>\n<p>Pravidla typu \"musí obsahovat velké písmeno, malé písmeno, číslici a symbol\" nezaručují sílu hesla. <code>Password1!</code> vyhovuje mnohým z těchto pravidel, přesto je slabé. Přednost dejte délce, jedinečnosti, náhodnosti a kontrole proti uniklým heslům.</p>\n<h2>Nezakazujte kopírování a vkládání hesel</h2>\n<p>Zakázání vkládání hesla komplikuje používání správce hesel. To může uživatele vést ke krátkým, snadno zapamatovatelným heslům. Povolte vkládání a automatické vyplnění, pokud k tomu není jasný a dokumentovaný bezpečnostní důvod.</p>\n<h2>Nepovolujte nápovědy k heslům</h2>\n<p>Nápovědy často prozradí příliš mnoho. Pokud si uživatel podle nápovědy heslo vzpomene, útočník to často zvládne také. Využijte raději zabezpečené resetovací procesy.</p>\n<h2>Neukládejte hesla v čistém textu</h2>\n<p>Systémy nikdy nesmí ukládat hesla v otevřeném textu nebo reverzibilně zašifrovaná. Hesla musí být hashována moderním, pomalým a \"soleným\" algoritmem, jako jsou Argon2id, bcrypt, scrypt nebo PBKDF2, dle systému a regulací.</p>\n<p>Rychlé obecné hashovací algoritmy jako MD5, SHA-1, SHA-256 či SHA-512 nejsou pro ukládání hesel vhodné. Jsou navržené na rychlost, což útočníkům při úniku databáze usnadňuje prolomení hesel. Další informace najdete v našem článku o <a href=\"/blog/evolution-of-password-hashing\">vývoji hashování hesel</a>.</p>\n<h2>Nesdílejte hesla přes chat nebo e-mail</h2>\n<p>Hesla nikdy neposílejte e-mailem, chatem, přes tikety, dokumenty či screenshoty. Používejte správce hesel s bezpečným sdílením a řízením přístupu.</p>\n<h2>Nepoužívejte osobní údaje nebo předvídatelné vzory</h2>\n<p>Hesla nesmí obsahovat jména, data narození, názvy firem, vzory na klávesnici, opakující znaky ani běžné zástupné znaky, jako je <code>@</code> místo <code>a</code> a <code>0</code> místo <code>o</code>. Útočníci tyto vzory testují na začátku.</p>\n<h2>Osvědčené postupy pro organizace</h2>\n<h2>Nastavte jasné minimální požadavky</h2>\n<p>Vyžadujte požadavky, kterým uživatelé rozumí:</p>\n<ul>\n<li>Jedno minimální pravidlo pro délku, například 16 znaků pro všechny lidské účty</li>\n<li>Povolte alespoň 64 znaků</li>\n<li>Povolte mezery a běžné symboly</li>\n<li>Povolit přístupové fráze a správce hesel</li>\n<li>Odmítnout kompromitovaná a často používaná hesla</li>\n</ul>\n<h2>Upravte pravidla pro privilegované účty</h2>\n<p>Administrátorské účty, servisní účty a výroba vyžadují přísnější kontrolu. Vynucujte silnější hesla, MFA, omezený přístup, monitoring a okamžitou rotaci přístupů při změně.</p>\n<h2>Zavádějte řízení přístupu a princip minimálního oprávnění</h2>\n<p>Silná hesla nenahradí přehnaně široká oprávnění. Každý by měl mít přístup jen tam, kde je to nezbytné pro jeho roli.</p>\n<h2>Sledujte podezřelou aktivitu</h2>\n<p>Detekujte neobvyklé pokusy o přihlášení, nemožné cestování, opakované neúspěšné pokusy, přihlášení z nových zemí či mimo běžnou pracovní dobu. Heslovou politiku doplňte monitorováním a reakcí na incidenty.</p>\n<h2>Školte uživatele na reálné hrozby</h2>\n<p>Školení by mělo být zaměřeno na znovupoužívání hesel, phishing, falešné přihlašovací stránky, únavu z MFA, bezpečné sdílení a jak hlásit podezření na kompromitaci. Neobviňujte uživatele – podpořte bezpečné chování.</p>\n<h2>Udržujte politiku stručnou a srozumitelnou</h2>\n<p>Heslová politika by měla být pochopitelná. Příliš dlouhá, vágní či přísná politika vede uživatele k jejímu obcházení. Nejlepší politika je ta, která lze efektivně uplatnit a dodržet.</p>\n<h2>Šablona heslové politiky ke zkopírování</h2>\n<p>Použijte tuto šablonu jako výchozí bod. Upravte části v hranatých závorkách podle vaší organizace, systémů, úrovně rizika a legislativy.</p>\n<pre><code class=\"language-text\">Heslová politika\n\nVerze: [1.0]\nVlastník: [Bezpečnostní / IT oddělení]\nDatum platnosti: [RRRR-MM-DD]\nPerioda revize: [každých 12 měsíců]\n\n1. Účel\n\nTato politika definuje požadavky na tvorbu, používání, ukládání, sdílení a změnu hesel pro [Název organizace]. Cílem je snížení rizika neoprávněného přístupu, krádeže přihlašovacích údajů, převzetí účtu a ztráty dat.\n\n2. Rozsah\n\nTato politika se vztahuje na všechny zaměstnance, dodavatele, dočasné pracovníky, poskytovatele služeb a další uživatele, kteří přistupují k systémům, aplikacím, sítím, cloudovým službám nebo datům [Název organizace].\n\nVztahuje se na běžné uživatelské účty, privilegované účty, servisní účty, sdílené účty a na všechny systémy, kde jsou hesla používána k ověření identity.\n\n3. Požadavky na tvorbu hesel\n\nVšechna hesla musí splňovat následující:\n\n- Lidské účty musí mít heslo o délce minimálně 16 znaků.\n- Hesla musí být jedinečná a nesmí být používána napříč pracovními a osobními účty.\n- Hesla nesmí obsahovat jména, uživatelská jména, názvy firem, data narození, vzory na klávesnici, opakující se znaky nebo jiné snadno odhadnutelné informace.\n- Hesla nesmí být založena na běžných frázích, citátech, textech písní ani předvídatelných zástupných znacích.\n- Hesla se nesmí nacházet v seznamu kompromitovaných či často používaných hesel.\n- Hesla mohou obsahovat mezery, symboly, číslice, velká i malá písmena.\n- Přístupové fráze jsou povoleny, pokud jsou dlouhé, jedinečné a nejsou založené na veřejně známých či předvídatelných frázích.\n\n4. Správci hesel\n\n[Název organizace] vyžaduje nebo silně doporučuje používání schváleného správce hesel pro tvorbu, uchovávání a sdílení hesel.\n\nUživatelé mohou využívat generátor hesel, automatické vyplňování a funkci kopírování/vkládání ze schváleného správce hesel. Hesla nesmí být ukládána do prohlížečů, tabulek, dokumentů, poznámkových aplikací, e-mailů, chatů, screenshotů ani jiných neschválených nástrojů.\n\n5. Vícestupňové ověření\n\nVícestupňové ověření (MFA) musí být povoleno všude, kde je to technicky možné, včetně (ale nejen):\n\n- E-mailové účty\n- Systémy pro vzdálený přístup\n- Účty správce hesel\n- Cloudové služby\n- Administrátorské účty\n- Finanční, HR a další vysoce rizikové systémy\n- Jakýkoliv systém klasifikovaný jako [důvěrný / kritický]\n\nKde je to možné, musí uživatelé využívat MFA odolné vůči phishingu (např. passkeys, bezpečnostní klíče nebo autentizátory zařízení). Aplikace pro autentizaci jsou preferované před SMS. Ověření pomocí SMS je zakázáno, pokud je technicky dostupná silnější varianta, a smí být použito jen v případě, že jiný způsob není technicky možný.\n\n6. Změna hesel\n\nHesla musí být neprodleně změněna, když:\n\n- Je heslo známo nebo existuje podezření na jeho kompromitaci.\n- Uživatel zadal heslo na podezřelou/phishingovou stránku.\n- Heslo bylo sdíleno s neoprávněnou osobou.\n- Byla zjištěna infekce malwarem nebo neautorizovaný přístup k zařízení uživatele.\n- Heslo se objeví v databázi uniklých dat.\n- Privilegovanému uživateli se změní role nebo ukončí zaměstnání.\n- IT/Bezpečnost nařídí uživateli změnit heslo.\n\nPravidelná expirační lhůta není požadována, pokud to nevyžaduje legislativa, smlouva nebo technické omezení systému. Hesla nesmí být měněna drobnými předvídatelnými změnami původního hesla.\n\n7. Sdílení hesel\n\nHesla nesmí být sdílena prostřednictvím e-mailu, chatu, tiketů, dokumentů, screenshotů, telefonických hovorů ani ústně.\n\nSdílené přihlašovací údaje jsou povoleny pouze tehdy, kdy není možné individuální řešení nebo jsou výslovně schváleny [Bezpečností/IT]. Schválené sdílené údaje musí být uchovávány a sdíleny pouze přes schváleného správce hesel s omezeným přístupem.\n\n8. Privilegované účty\n\nPrivilegované účty musí používat jedinečná hesla, která nejsou využívána pro běžné uživatelské účty. Musí využívat MFA kdekoliv je to možné a být pravidelně prověřovány.\n\nHesla privilegovaných účtů musí být změněna při odchodu administrátora, změně role, ztrátě oprávnění nebo podezření na kompromitaci.\n\n9. Servisní účty a aplikační tajemství\n\nHesla servisních účtů, API klíče, tokeny a aplikační klíče je třeba ukládat do schváleného systému pro správu tajemství nebo správce hesel.\n\nPřihlašovací údaje servisních účtů nesmí být vkládány do zdrojových kódů, konfiguračních souborů, obrázků, dokumentací či skriptů, pokud nejsou chráněny schváleným systémem pro správu tajemství.\n\n10. Reset hesla a obnova účtu\n\nProcesy pro reset hesla musí ověřit identitu uživatele před obnovením přístupu. Resetovací odkazy a dočasná hesla musí být jednorázová, s rychlou expirací, a přenášena pouze schváleným způsobem.\n\nUživatelé musí být informováni o změně nebo resetu hesla. Dočasná hesla musí být změněna při prvním přihlášení.\n\n11. Technické požadavky\n\nSystémy, které ukládají nebo zpracovávají hesla musí:\n\n- Nikdy neukládat hesla v čistém textu.\n- Hashovat hesla moderním \"soleným\" algoritmem: PBKDF2, scrypt, bcrypt nebo Argon2.\n- Nepoužívat samostatně MD5, SHA-1, SHA-256, SHA-512 ani jiné rychlé hashovací algoritmy pro hesla.\n- Chránit autentizační koncové body omezením počtu pokusů nebo ekvivalentními opatřeními.\n- Odmítat běžně používaná, slabá nebo kompromitovaná hesla.\n- Povolit vkládání hesel ze správce hesel.\n- Podporovat rozumnou délku hesel a minimálně 64 znaků, pokud je to technicky možné.\n- Logovat bezpečnostně relevantní události týkající se ověřování.\n\n12. Hlášení podezření na kompromitaci\n\nUživatelé musí okamžitě hlásit podezření na kompromitaci hesla, phishing, neobvyklé výzvy k přihlášení, výzvy k MFA, které nevyvolali, nebo náhodné zveřejnění hesla kontaktu [Bezpečnost / IT].\n\n13. Výjimky\n\nVýjimky z této politiky musí být zdokumentovány, posouzeny z pohledu rizik, časově omezeny a schváleny [vedením Bezpečnosti / IT]. Musí být zavedeny náhradní kontrolní opatření, pokud je to možné.\n\n14. Vymáhání\n\nNedodržení této politiky může znamenat odebrání přístupu, povinné proškolení, kárná opatření nebo jiné kroky v souladu s politikou [Název organizace] a platnými zákony.\n\n15. Revize\n\nTato politika musí být přezkoumávána minimálně jednou ročně nebo po významné změně systémů, hrozeb, zákonů či fungování firmy.\n</code></pre>\n<h2>Závěrečné myšlenky</h2>\n<p>Silná heslová politika není o tom, udělat z hesel \"trest\". Jde o odstranění slabých zvyků, podporu správce hesel, použití MFA a rychlé reakce při úniku přihlašovacích údajů. Držte se praktických, vymahatelných pravidel a zaměřte se na reálné útoky jako je phishing, znovuvyužití hesel, credential stuffing a kompromitované účty.</p>","frontmatter":{"date":"May 07, 2026","slug":"password-policy-dos-donts-best-practices","title":"Heslová politika: doporučení, čemu se vyhnout, osvědčené postupy a šablona ke zkopírování","description":"Zjistěte, co by dnes měla vyžadovat moderní heslová politika, kterým zastaralým pravidlům se vyhnout, a zkopírujte praktickou šablonu pro vaši organizaci.","author":"Sascha Pfeiffer","featuredImage":null}}},"pageContext":{"slug":"password-policy-dos-donts-best-practices","lang":"cs","langPathPrefix":"/cs"}},"staticQueryHashes":["2149092236","3128451518","3192060438"]}