TakéPolitika informační bezpečnosti, ISMS politika, Security policy documentZákladní
Definice
Bezpečnostní politika je závazný dokument organizace, který stanovuje pravidla, odpovědnosti a přijatelnou míru rizika při práci s informacemi a IT systémy. Určuje, kdo má k čemu přístup, jak se nakládá s hesly, daty a incidenty, a co se stane při porušení pravidel. Schvaluje ji vedení a doplňují ji navazující směrnice a technická opatření.
Nezaměňujte: Bezpečnostní politika může znamenat organizační dokument s pravidly informační bezpečnosti, nebo strojově vynucované pravidlo v systému (IAM policy, Content Security Policy, NetworkPolicy).
Než se na to spolehnete: Odkaz na Wikidata Q1935420 jsem neověřil, prosím zkontrolujte, zda odpovídá pojmu security policy. Formulace o českém zákonu o kybernetické bezpečnosti je záměrně obecná, protože transpozice NIS2 se v ČR v době psaní mění.
Co bezpečnostní politika řeší
Bezpečnostní politika převádí obecné přání „být v bezpečí“ na rozhodnutí, která lze vymáhat. Odpovídá na otázky, u nichž se jinak každý tým rozhodne jinak: kdo smí vydat přístup do produkce, jak dlouho se uchovávají logy, zda se smí firemní data ukládat na soukromý notebook, kdy se musí hlásit incident a komu. Bez takového dokumentu se pravidla drží v hlavách několika lidí a s jejich odchodem zmizí.
Vrstvy dokumentace: od politiky ke konfiguraci
Praxe rozlišuje několik úrovní. Nahoře stojí krátká zastřešující politika (často 2 až 5 stran), kterou podepisuje vedení a která deklaruje cíle a odpovědnosti. Pod ní jsou tematické politiky: přístupová, hesel, zálohování, řízení dodavatelů, práce na dálku. Ještě níž leží provozní postupy a konkrétní konfigurace, například nastavení dvoufaktorového ověření nebo pravidla firewallu. Politika říká „co a proč“, směrnice „kdo a kdy“, konfigurace „jak přesně“.
Proč se politika píše podle rizik, ne podle katalogu opatření
Smysluplná politika vychází z analýzy rizik konkrétní organizace. Pětičlenné SaaS studio a nemocnice mají jiná aktiva, jiné hrozby i jinou toleranci k výpadku. Normy jako ISO/IEC 27001 nebo rámec NIST proto nediktují jedinou správnou sadu opatření, ale požadují, aby organizace uměla doložit, proč zvolila právě tato. Opsaná šablona z internetu obvykle slibuje kontroly, které nikdo nedělá, což je při auditu horší než skromnější, ale dodržovaný dokument.
Kdy je politika jen papír
Politika ztrácí hodnotu ve chvíli, kdy popisuje jinou realitu, než jaká ve firmě panuje. Typické signály: zakazuje sdílené účty, ale celý tým používá jeden přístup do administrace; vyžaduje čtvrtletní revizi oprávnění, kterou nikdo nikdy neprovedl; odkazuje na systém vyřazený před dvěma lety. Proto k ní patří vlastník, datum revize a měřitelné kontroly, ideálně automatizované v CI/CD nebo v monitoringu.
Bezpečnostní politika versus technická politika v kódu
Stejné slovo se používá i pro strojově čitelná pravidla: IAM politiky v cloudu, NetworkPolicy v Kubernetes, Content Security Policy v prohlížeči. Tyto artefakty jsou vynucovaná implementace, nikoli organizační dokument. Zdravý stav nastává, když organizační pravidlo má svůj technický protějšek: zásada „služby spolu komunikují jen tam, kde je to nutné“ se projeví jako konkrétní síťová pravidla, ne jako věta v PDF.
Právní kontext v Česku
Bezpečnostní politiku vyžaduje nebo předpokládá několik regulací. GDPR mluví o vhodných technických a organizačních opatřeních, směrnice NIS2 a navazující český zákon o kybernetické bezpečnosti ukládají regulovaným subjektům řízení rizik včetně dodavatelského řetězce, standard PCI DSS pak vyžaduje dokumentovanou politiku pro prostředí s platebními kartami. Pro řadu firem je tak politika i podmínkou pro uzavření smlouvy s větším zákazníkem.
Příklady z praxe
Politika přístupů v malém vývojářském týmu
Studio s dvanácti lidmi zavede pravidlo, že přístup do produkční databáze má nejvýše pět osob, uděluje se na dobu určitou a čtvrtletně se reviduje. V politice je uvedený vlastník procesu (CTO), forma žádosti a doba uchování záznamu. Technicky se pravidlo promítne do IAM rolí, takže lze kdykoli doložit, kdo měl přístup v daný den.
Organizační pravidlo přepsané do vynutitelné konfigurace
Politika říká, že veřejné webové aplikace nesmí načítat skripty z neschválených domén. Toto pravidlo se v provozu projeví jako hlavička Content Security Policy, kterou aplikace posílá v každé odpovědi. Prohlížeč pak zablokuje vložený skript z cizí domény i v případě, že se útočníkovi podaří do stránky něco vložit.
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; frame-ancestors 'none'
Časté omyly
- MýtusBezpečnostní politika je papír pro auditora, na reálnou bezpečnost nemá vliv.
- Ve skutečnostiPolitika sama o sobě nechrání nic, ale určuje, která opatření se mají zavést a kdo za ně odpovídá. Bez ní se rozhodnutí dělají ad hoc a při odchodu klíčového člověka se ztrácejí. Vliv na bezpečnost má až ve chvíli, kdy se z jejích vět stanou kontroly a konfigurace.
- MýtusStáhneme šablonu podle ISO 27001 a máme hotovo.
- Ve skutečnostiNormy nevyžadují konkrétní text, ale doložitelnou vazbu na rizika dané organizace. Šablona typicky slibuje procesy, které ve firmě nikdo neprovádí, a při auditu i po incidentu je nedodržovaná politika horší než stručná a pravdivá.
- MýtusBezpečnostní politiku potřebují jen velké firmy a banky.
- Ve skutečnostiPovinnost přiměřených organizačních opatření plyne už z GDPR pro každého správce osobních údajů. Malé firmy navíc politiku běžně potřebují jako podmínku dodavatelských smluv nebo bezpečnostních dotazníků od zákazníků.
Časté dotazy
- Kdo má bezpečnostní politiku ve firmě schvalovat?
- Bezpečnostní politiku schvaluje statutární orgán nebo vrcholové vedení, protože jde o rozhodnutí o akceptované míře rizika a o alokaci zdrojů. Připravuje ji obvykle bezpečnostní manažer, CTO nebo externí konzultant ve spolupráci s vlastníky jednotlivých systémů. Bez podpisu vedení dokument nemá autoritu vynucovat pravidla vůči jiným oddělením a v auditu se hodnotí jako nezávazný. Součástí schválení bývá i určení vlastníka dokumentu, který odpovídá za revize.
- Jak často se bezpečnostní politika reviduje?
- Bezpečnostní politika se běžně reviduje jednou ročně a navíc mimořádně po významné změně: po bezpečnostním incidentu, po nasazení nové kritické služby, při změně regulace nebo po velké reorganizaci. Datum poslední revize a plánovaný termín další patří přímo do dokumentu, jinak nelze doložit, že je aktuální. U rychle se měnících prostředí se často reviduje jen dotčená tematická směrnice, zatímco zastřešující politika zůstává stabilní několik let.
- Co má bezpečnostní politika minimálně obsahovat?
- Bezpečnostní politika by měla obsahovat rozsah platnosti (které systémy, lokality a osoby pokrývá), cíle a přijatelnou míru rizika, role a odpovědnosti, pravidla přístupů a autentizace, nakládání s daty včetně jejich klasifikace, zálohování a obnovu, hlášení incidentů, požadavky na dodavatele a důsledky porušení. Dále vlastníka dokumentu, verzi a datum revize. Detailní postupy patří do navazujících směrnic, aby hlavní dokument zůstal čitelný.
- Jak poznat, že bezpečnostní politika ve firmě reálně funguje?
- Funkční bezpečnostní politika se pozná podle toho, že se na ni lidé odvolávají mimo audit: při schvalování přístupu, při výběru dodavatele nebo při rozhodování, kam uložit data. Dalším znakem jsou důkazy, že kontroly opravdu probíhají, tedy záznamy o revizích oprávnění, zápisy z testů obnovy ze zálohy nebo automatizované kontroly v pipeline. Pokud dokument nikdo kromě jeho autora nečetl a žádné záznamy neexistují, politika existuje jen formálně.
Zdroje
- ISO/IEC 27001 Information security management systems(otevře se v novém okně)
- Cybersecurity Framework(otevře se v novém okně)
- PCI Security Standards Council: Document Library(otevře se v novém okně)
- Content Security Policy (CSP)(otevře se v novém okně)
- Nařízení (EU) 2016/679 (GDPR)(otevře se v novém okně)
Související pojmy
