| Bezpečnostní politika a hesla |
|
Autor: Tomáš Přibyl, externí odborný redaktor ICTsecurity Hesla jsou důležitým aspektem informační bezpečnosti: je to vlastně první linie ochrany uživatelských účtů a práv. Proto je nutné jejich vytváření i použití ošetřit bezpečnostní politikou, aby byla dodržována jasná a transparentní pravidla. Nejen technické prostředky Protože kvalita hesel (míněno jejich vytváření, ukládání i používání) je něco, co je poměrně špatně ovlivnitelné technickými prostředky, musíme o to větší důraz klást na ošetření celé problematiky v bezpečnostní politice. Ta musí obsahovat standard pro vytváření silných hesel, jejich ochranu a četnost změn. Základním zdrojem tipů a norem pro vypracování bezpečnostní politiky ve vztahu k heslům se nám mohou stát doporučení vydaná organizací SANS Institute (SysAdmin, Audit, Network, Security). Pojďme se na její směrnice podívat blíže – třeba nám mohou být v mnohém prospěšné a užitečné. Na základě těchto doporučení by se měla všechna systémová hesla (rootová, administrátorská...) měnit minimálně jednou za čtvrtletí. Stejně tak musí být všechna hesla zálohovaná v globální databázi, aby byl zajištěný přístup do systému i v případě nedostupnosti majitelů těchto přihlašovacích atributů (nemoc, dovolená, ukončení pracovního poměru...). Uživatelská hesla naproti tomu dostačuje dle SANSu měnit dvakrát ročně s tím, že je doporučeno tuto frekvenci zvýšit na tři roční změny. Silná a slabá hesla Slabá a nedostatečná hesla jsou kratší patnácti znaků, přičemž nesmí být použito žádné slovo ze slovníku. Nesmí to být žádný běžně užívaný pojem nebo osobní informace. Stejně jako logická posloupnost čísel nebo znaků (123456, aaa aj.). Stejně tak nesmí být heslem cokoliv z výše uvedeného hláskované pozpátku nebo cokoliv z výše uvedeného doprovázeného číslicí. Naproti tomu silná hesla musí obsahovat malá i velká písmena (a systém přitom musí být schopen je rozlišovat). Navíc obsahuje čísla a punkční znaménka. Musí být delší, než patnáct znaků. Nejde o slovo z jazyka, dialektu či žargonu – tedy o žádné běžně vyžívané slovo, nýbrž v ideálním případě o passfrázi. Nesmí být jakýmkoliv způsobem spojeno s osobními či rodinnými informacemi. Stejně tak s heslem musí být nakládáno tak, aby nemohlo být okopírováno nebo odcizeno on-line. Co se ochrany hesel týká, nemělo by se používat stejné pro různá prostředí (aby se zabránilo možnosti přenášení hesel). Stejně tak musí platit přísný zákaz sdílení hesla s kýmkoliv včetně nadřízených či administrátorů – a stejně tak zákaz sdělovat heslo telefonicky nebo jinou formou elektronické komunikace (typicky e-mailem). Součástí bezpečnostní politiky také musí být pravidlo, že o heslech by se uživatelé neměli bavit s nikým, a to ani v žertu. Neměl by též být nikde a nijak prozrazovaný formát hesla – tedy kromě jiného nesmí dojít k jakémukoliv vyzrazování vyžadované politiky týkající se tvorby hesel. Heslo nesmít být vyzrazeno v dotaznících nebo i v bezpečnostních formulářích. Heslo nelze sdělovat ani spolupracovníkům – a to ani v době nemoci nebo dovolené. Bezpečnostní politika totiž se zastupitelností a sdílením zdrojů musí počítat: organizace závislá na telefonátech nedostupným pracovníkům je totiž na nejlepší cestě k megaprůšvihu. Žádné elektronické pomůcky Striktně též musí být zakázáno používat jakoukoliv aplikaci sloužící k zapamatování si hesel nebo funkci ukládání hesel. Při změně hesla by mělo být znemožněno vracet se k heslu minulému: častým prohřeškem uživatelů je totiž střídání dvou hesel. Stejně tak se nesmí hesla zapisovat nebo ukládat do elektronického zařízení (mobilní telefon, PDA apod.). Uživatel musí mít možnost při podezření na kompromitaci hesla informovat odpovídající autoritu, která provede následné šetření a všechny úkony. Naopak, tato autorita má mít pravomoc kontrolovat hesla, zdali splňují všechny předepsané požadavky. Ruku na srdce: pouhá možnost kontroly působí sama o sobě jako prevence, neb uživatelé si dávají větší pozor. Kontrola hesla může být jednak automatická (systém odmítne akceptovat heslo, které neodpovídá bezpečnostní politice), jednak penetrační (při něm dochází k cíleným útokům na uživatelská hesla ve snaze zajistit kvalitu systému). O tom, že by bezpečnostní politika kromě pravidel měla obsahovat také možné sankce, se jistě není třeba dlouze rozepisovat. Na závěr ještě pár slovo ke standardům pro vývojáře aplikací. Tyto musí podporovat autentizaci jednotlivců, nikoliv skupin (i když přidělená práva mohou být v konečném důsledku skupinová, vždy musí být nade vší pochybnost jasné, komu jsou přidělována). Hesla se nesmí ukládat v textové podobě – nebo být jakýmkoliv jiným způsobem snadno extrahovatelná. Aplikace musí umožňovat řízení rolí: uživatelé mohou vykonávat i úkoly někoho jiného, a to aniž by znali jeho heslo. Samozřejmostí by měla být podpora standardů a technologií jako TACACS+, RADIUS a/nebo X.509 s LDAP. Politika coby opora Nezapomínejme, že bezpečnostní politika se svými pravidly a sankcemi je tu nejen jako vodítko pro uživatele či administrátory, ale že je zároveň musí chránit. Třeba v případě nestandardních požadavků na sdělení hesla ze strany spolupracovníků či nadřízených (nebo nedejbože cizích osob) je nutné, aby měl uživatel v bezpečnostní politice oporu a mohl se jí zaštítit. |














