facebook
Tematické sekce
 
Branžové sekce
Přehledy
 
Tematické seriály
 

GDPR

General Data Protection Regulation zásadně mění zpracování osobních údajů a zavádí nové povinnosti...

články >>

 

Jak uřídit IT projekt a nezbláznit se

Užitečné tipy a nástroje pro řešení problémů řízení inovací a vývoje produktů...

články >>

 

Industry 4.0

Průmysl 4.0

Jaký vliv bude mít čtvrtá průmyslová revoluce na výrobu a výrobní firmy?

články >>

 

Komplexní svět eIDAS

O nařízení eIDAS již bylo mnoho řečeno i napsáno. A proto jediné, o čem...

články >>

 

Trendy v CRM

Systémy pro řízení vztahů se zákazníky (CRM) prochází v posledních letech výraznou změnou. Zatímco dříve...

články >>

 

Příručka úspěšného IT manažera

Dnes je řada IT manažerů opomíjena. Úspěšní bývají brouci Pytlíci a Ferdové...

články >>

 

Pokročilá analýza provozu datových sítí

V tomto čtyřdílném seriálu vás seznámíme s různými metodami a přístupy...

1. až 4. díl >>

 

Cesta k efektivnímu identity managementu

Správa identit a přístupů (IAM) je klíčová oblast pro zaručení bezpečnosti...

1. až 9. díl >>

Partneři webu
Aimtec
IT SYSTEMS 10/2018 , IT Security

Jak na procesy okolo firewallu?

Lukáš Solil


AECJako technici se často dostáváme k různým projektům, které zahrnují implementaci firewallu. Obvykle se při nich setkáváme s tím, že zákazníci nemají úplně pod kontrolou firewallové politiky. Někdy je politika celkem v pořádku a vadu na kráse představuje jen nedostatečná dokumentace a nepopisné komentáře (např. komentář „Pro Elišku“ nám nenapoví, co se stane, až to pravidlo smažeme), ale většinou je problém mnohem rozsáhlejší – pravidla jsou tvořena náhodně, jsou zbytečně otevřená a zastaralá. Někdy je dokonce v pravidlech, nebojím se to říct, dokonce nepořádek.


Kdo dělá nepořádek?

Podívejme se na to blíže. Jak je možné, že se většinou nedaří udržovat pravidla uklizená a přehledná?

Tak například proto, že administrátorů je více a každý z nich skládá pravidla do politiky trochu jinak. Obvykle si každý vymyslí nějaký systém, jak mu to přijde správné a používá ho. Samozřejmě si je při tom plně vědom toho, že to dělá správně a mnohem lépe, než jeho kolegové. Když každý z administrátorů použije ten nejlepší způsob, tedy svůj, může být složité se v politice vyznat.

Další důvod, proč se pořádek z politiky vytrácí, jsou stresující situace, ve kterých administrátoři často musí pracovat. Nebo to, že pravidla ráda vznikají na základě telefonátu, který přijde kolem desáté večer a obsahuje slova jako „migrace, rychle a čekáme“. V těchto chvílích obvykle vznikají zbytečně otevřená pravidla, protože administrátor potřebuje co nejdříve zajistit funkčnost, ale na bezpečnost už nemá čas ani chuť. Ta se většinou odloží na blíže nedefinované „později“.

Aby to administrátoři měli ještě složitější, podléhají pravidla sama o sobě erozi. I v politice, která je jinak udělaná dobře, se obvykle objevují pravidla, která jsou zastaralá a nedávají už žádný smysl. Prostě zanikne důvod k existenci daného pravidla (skončí projekt, vývoj nebo zaměstnanec) a pravidlo by měl někdo odstranit. Jenže ten někdo to neví. A tak pravidlo zůstane. Protože už dávno nikdo netuší, proč vzniklo, tak se ho všichni bojí odstranit a pro jistotu jej přidávají i do nových verzí politik. Takto se na politiku nabalují zbytečná pravidla.

Samozřejmě je i mnoho dalších důvodů, proč se nedaří dlouhodobě udržovat politiku firewallu v úplném pořádku. Například pokud může pravidla vytvářet příliš mnoho lidí. Pokud se administrátor řídí heslem: „Kdyby to bylo důležité, nesvěřili by to mně.“ Nebo pokud technologie umožňuje místo smazání pravidla jenom jeho dočasné zneplatnění. Důvodů se dá najít mnoho, ale když se nad tím zamyslíme, jedná se stále o to samé, jen z jiných úhlů pohledu: Chybí pravidla pro tvorbu a kontrolu pravidel, nebo když už ta pravidla jsou, tak je někdo nedodržuje, protože ho nikdo nekontroluje.

Obrázek 1: Ukázka politiky firewallu s různými chybami
Obrázek 1: Ukázka politiky firewallu s různými chybami 1) Pravidla nemají logickou strukturu, jsou vytvářena více méně náhodně. Nástroj umožňuje oddělení pravidel titulkem, tato funkce se ale nevyužívá. 2) V politice zůstávají zastaralá pravidla, která za poslední dobu nebyla vůbec použita. 3) Názvy pravidel buďto nejsou vůbec žádné nebo neposkytují užitečné informace. 4) Názvy objektů nejsou dost popisné, nelze určit, co přesně obsahují. 5) V pravidlech by se nemělo příliš využívat univerzálního označení pro všechny objekty (např. Any), správné je definovat pravidlo přesněji. 6) Pravidla jsou různě rozházená, je vhodné je seskupovat do logických celků, například podle cíle. Na obrázku je vidět různá pravidla pro servery rozházená po celé politice. 7) Opět málo popisný název. Není jasné, co skupina portů obsahuje. 8) Tam, kde je to možné, je vhodné volit názvy raději než generické popisky. 9) Špatná struktura pravidel se projevuje i v tom, že jsou povolující a zakazující pravidla náhodně promíchána. Správně by měla být nejprve povolovací pravidla a na závěr pravidlo, které zakáže zbytek. Zákaz části komunikace je méně vhodný, protože snižuje přehlednost. 10) Pokud log z pravidla může poskytovat důležitou informaci, mělo by se logovat. Rozhodně je špatně pravidlo, které umožňuje administrátorům přístup kamkoliv a ještě bez logování. 11) Míchání různých bran, na které se politika instaluje, velmi snižuje přehlednost. 12) Nepoužívají se komentáře, což v budoucnu povede k ještě většímu chaosu. 13) Chybí závěrečné blokující pravidlo, které by logovalo zbývající komunikaci.

Nám to nevadí, zvládáme i chaos

Konec předchozího odstavce by byl pěkný můstek do textu o procesech a řízení. To je samozřejmě téma, ke kterému tento článek pomalu směřuje, ale nejprve se ještě podíváme na to, proč je vůbec potřeba se pořádkem v pravidlech zabývat. Možná bychom si mohli vystačit s mojí oblíbenou frází, kterou říkám ženě, když mám doma uklízet (tedy neříkám ji tak úplně nahlas, ale důrazně si ji myslím): „Inteligent zvládne i chaos.“ První část fráze si raději stále jen důrazně myslím. Nicméně její pointa je zřejmá. Proč ji neaplikovat i na firewallové politiky?

Tak zaprvé chaos v pravidlech výrazně ztěžuje jejich správu. Je možné, že někdo se v nich stále vyzná, měl by ale pamatovat i na svoje kolegy a ostatní, kdo se musí v politice zorientovat. Nezapomínejte například na auditory. Zejména nepoužívaná a zastaralá pravidla zbytečně snižují přehlednost. Chaos má navíc tendenci sám od sebe narůstat. Zbytečná pravidla snižují přehlednost, nepřehlednost ztěžuje vyhledání a odstranění zbytečných pravidel.

Zadruhé je zde bezpečnostní otázka. Ta je v případě nastavení firewallu velice důležitá. Ve chvíli, kdy administrátor kvůli nedostatku času nastavuje pravidla příliš mírně, snižuje účinnost firewallu. I když firewall případného útočníka nemusí úplně zastavit, může mu alespoň významně ztížit práci (tímto bychom se chtěli omluvit kolegům pentesterům). Firewall není jenom povinná krabice, kterou musí mít v síti každá běžná organizace. Jde o velmi důležitý a účinný prvek, který tvoří jednu z mnoha vrstev bezpečnosti. Datová bezpečnost je založená na vrstvách, každou z nich je možné nějak obejít, ale projít všechny může být pro útočníka téměř nemožné.

Obrázek 2: Špatně spravovaná politika snadno skryje bezpečnostní rizika. Administrátoři zřejmě měli v úmyslu pravidlem 9 zakázat přístup na servery z externích sítí. Zapomenuté pravidlo 14 ale nechává otevřené ssh a telnet minimálně z vnitřních sítí, a to ještě bez logování přístupu. V závislosti na obsahu špatně pojmenované skupiny porty_k_zahozeni může být telnet dokonce povolen i z externích sítí. Správnější by bylo vytvořit blok pravidel cílených na servery. Tato pravidla by přesně stanovila, jaká komunikace bude povolená. Na konci bloku by potom mělo být pravidlo, které veškerou zbývající komunikaci zakáže.
Obrázek 2: Špatně spravovaná politika snadno skryje bezpečnostní rizika. Administrátoři zřejmě měli v úmyslu pravidlem 9 zakázat přístup na servery z externích sítí. Zapomenuté pravidlo 14 ale nechává otevřené ssh a telnet minimálně z vnitřních sítí, a to ještě bez logování přístupu. V závislosti na obsahu špatně pojmenované skupiny porty_k_zahozeni může být telnet dokonce povolen i z externích sítí.
Správnější by bylo vytvořit blok pravidel cílených na servery. Tato pravidla by přesně stanovila, jaká komunikace bude povolená. Na konci bloku by potom mělo být pravidlo, které veškerou zbývající komunikaci zakáže.

Další důvod, proč se snažit pravidla udržovat v pořádku, je správné využití výkonu hardware. Zde hodně záleží na technologii a na tom jaký princip využívá pro vyhodnocování politiky. Velmi často jsou pravidla vyhodnocována jedno za druhým od horní části politiky až dolů. Když má firewall rozhodnout, zda komunikaci propustí nebo ne, postupuje takto: Srovná zdroj, cíl a port dané komunikace s prvním pravidlem. Potom s druhým, třetím, atd. dokud nenarazí na pravidlo, které odpovídá. Potom provede akci danou tímto pravidlem (komunikaci zahodí nebo povolí).

Zde si můžete všimnout, že hlavně u zakázané komunikace záleží na uspořádání pravidel. Pokud ji totiž zakážeme někde v první části politiky, nebude firewall muset kontrolovat všechna ostatní pravidla a rovnou komunikaci zahodí. Když naopak bude poslední, bude to, no… naopak. Někdy je možné správným uspořádáním politiky firewallu značně ulehčit.

Konečně procesy

Teď sice chybí můstek z předchozího odstavce, ale přesto se konečně dostáváme k jádru tohoto článku. Zjistili jsme, že máme problém s udržováním firewallových pravidel, ale co s tím? Jednoduchá korporátní odpověď je, že na to připravíme proces. Nebo raději více procesů. Čím více procesů, tím lépe.

I když to tak možná z formy předchozího odstavce úplně nevyznělo, tato odpověď je v podstatě správná. Je potřeba administrátorům připravit návod, jak mají postupovat, aby udrželi pořádek. Má to ale háček – nastavit procesy správně není vůbec jednoduché.

Z pohledu technika řadím procesy do několika kategorií. Ty zbytečné, které nepotřebuji, protože bych to tak stejně dělal. Ty otravné, které nedodržuji, protože jsou zbytečné a nikdo mě nehlídá. Ty otravné, které dodržuji, protože mě hlídají. Ty, které mi dávají smysl, jsou opravdu dobré, a proto je dodržuji. Přičemž ty poslední pravděpodobně neexistují.

Přesto by mělo být cílem se při vymýšlení procesu snažit dosáhnout toho, aby byl smysluplný a pomáhal tomu, kdo se jím bude řídit. Je zřejmé, že zaměstnancům se zpočátku moc líbit nebude. Zaprvé proto, že se lidem většinou nelíbí cokoli nového, co mění jejich zvyky. Zadruhé proto, že jim proces zdánlivě přinese více práce. Zatřetí proto, že se málokdy stane, aby se člověk podíval zpětně a řekl si, aha, ono to opravdu pomohlo.

Když už se proces nepodaří dostat do vysněné kategorie těch, které jsou tak dobré, že je sám od sebe dodržuji, je dobré se o to alespoň pokusit. A pro jistotu provádět pravidelnou kontrolu. Tím totiž přinejhorším sklouzneme do kategorie otravných, ale dodržovaných procesů s kontrolou. Což je pořád poměrně kvalitní kategorie.

Když si vzpomeneme na část, kde jsme probírali zdroje nepořádku, máme popsané vstupy pro vymyšlení procesu, který nám pomůže udržovat bázi pravidel v čistotě a pořádku.

Architektura firewallové politiky

Určitě se bude nejprve nutné zamyslet nad celou architekturou pravidel. Budeme pravidla řadit podle cílů komunikace? Nebo podle jednotlivých požadavků/aplikací, kvůli kterým pravidla vznikají? Případně nějak jinak, třeba hybridně? Toto rozhodnutí je velice důležité a nedá se říct, která odpověď je správná. Hodně záleží na prostředí. Špatně navržená architektura může způsobit, že se místo jednoho pravidla bude vytvářet třeba pět pravidel. Správná architektura může pomoci v tom, že bude pro administrátora složitější vytvořit pravidlo typu „z nějakého zdroje povol všude všechno“, než se zamyslet nad tím, kam skutečně může daný zdroj přistupovat.

Proces vytváření pravidel

Z architektury pravidel vyplyne proces pro přidávání nových pravidel. V tom hrají zásadní roli vstupy, které administrátor dostane, aby vůbec pravidlo vytvořil. Ty je vhodné nějak standardizovat. Díky tomu bude možné hlídat, že pro každé pravidlo v politice existuje nějaký požadavek na povolení komunikace. Navíc takový, který jasně říká, odkud kam a proč má být daná komunikace povolena.

Samozřejmě okamžitě narazíme na problém, kdo by měl vědět, co kam komunikuje a proč. Zkušený čtenář již nyní lehce znervózněl, protože si uvědomuje, kam tyto úvahy často směřují. K vývojářům.

Ano, je to tak. Jsou různé skupiny uživatelů, které mají důvod žádat o vytvoření prostupů, u většiny z nich není pro administrátora zvlášť složité zjistit, jaké prostupy potřebují a proč. Pak jsou tu projektový manažeři. Ti často mívají velmi zvláštní požadavky, ale po chvíli se administrátor dopátrá někoho, kdo ve skutečnosti prostupy požaduje, ví jaké i proč. A potom je zde ona skupina vývojářů. Ti připraví aplikaci ve vývojovém prostředí, kde mají všechny prostupy povolené. Po přesunu do restriktivnějšího testovacího prostředí najednou přestane aplikace správně fungovat. Jenže jaké prostupy vlastně aplikace potřebuje?

To už je v této fázi vývoje často velmi obtížné říct, takže se musí začít s experimenty. Zkouší se různé povolování a zakazování, dokud se neurčí, co aplikace skutečně potřebuje povolit. Experimenty často skončí povolením prostupů, které by nebyly potřeba, aby aplikace fungovala. Tato část práce je navíc pro administrátory i vývojáře velmi nepříjemná, protože se spolu musí bavit, takže se ji snaží zkrátit na minimum. Obvykle na úkor bezpečnosti. To vše navíc často probíhá urychleně i kvůli blížícím se termínům dodání aplikace.

Z předchozích odstavců vyplývá, že část procesů vztahujících se k firewallovým pravidlům, je potřeba zahrnout i do procesů pro vývoj aplikací. Vývojáři by měli průběžně vytvářet komunikační matici, ideálně rovnou ve standardizovaném formátu, který slouží administrátorům jako vstup.


Obrázek 3: Vytváření pravidel probíhá stále dokola

Popis pravidel

Ve chvíli, kdy administrátor dostane přehledně a úplně popsané požadavky na vytvoření prostupů, musí se zamyslet, jak se s touto novou životní situací vyrovná. Administrátor ví, jak by měl požadavek implementovat do podoby firewallových pravidel. Protože je ale uvědomělý, zamýšlí se nad tím, jak nová pravidla pojmenovat, okomentovat, a jak označit objekty, které kvůli tomu vytvoří.

V ideálním případě by měl mít k dispozici nějaký návod, který mu poradí. Díky standardizované jmenné konvenci nebude těžké vymyslet názvy objektů ani pravidel. A pak tu má svou oblíbenou metodiku. Ta mu jasně říká, že komentáře k pravidlům odkazují do databáze požadavků o vytvoření daného pravidla. Upozorní ho, že je potřeba přidat časovou značku a identifikovat se jako autor pravidla. Tím mu dobře napsaný proces ušetřil spoustu času, který může věnovat dohadování s projektovými manažery a uštěpačným poznámkám na adresu uživatelů.

Časově omezená pravidla

Je to příjemný, hřejivý pocit, když se firewall začíná systematicky plnit pravidly. Správnými pravidly, u kterých někdo ví, proč tam jsou. U kterých i nový brigádník na pozici High Level Security Administration And Documentation Part-Time Senior Officier může díky správným názvům a komentářům zjistit důvod jejich existence. Pocit ale může být ještě lepší, když se zavede používání časově omezených pravidel.

Pokud to technologie firewallu umožňuje, mohou mít pravidla omezenou časovou platnost. Uveďme si příklad. V rámci projektu Kyrill vznikl požadavek na prostupy pro testovací prostředí. V požadavku nechybí informace, že projekt za měsíc končí. Administrátor může využít časové omezení pravidel a nastavit, že se pravidlo za měsíc samo zneplatní. Tedy soudný administrátor pravděpodobně použije koeficient pro pravděpodobně protahování projektů, takže nastaví omezení na pět měsíců.

Princip ale zůstane stejný. Díky časovému omezení ve firewallu zbytečně nezůstane pravidlo, které již nemá význam. Když budete hledat informace o tom, jak dělat správně firewallová pravidla, narazíte na názor, že by měla být časově omezená všechna. S možností časového omezení pravidel je určitě dobré počítat při vymýšlení procesu pro tvorbu pravidel.

Rušení pravidel

Tím, jak postupně přidáváme do firewallu pravidla, začínají konečně fungovat věci, které nikdy pořádně nefungovaly. Všichni jsou nebývale spokojeni, čehož si ale nezbytně musí všimnout někdo z oddělení informační bezpečnosti. Samozřejmě mu to přijde divné a začne pátrat po tom, jak je to možné a koho by za to mohl potrestat. Jistě si brzy najde cestu i za administrátorem firewallu. Ten mu ukáže, že pro každé pravidlo ve firewallu má podklady. To samozřejmě musí každého bezpečáka vyprovokovat k tomu, aby našel něco, co dělá administrátor špatně. A záhy na to přijde.

Tenhle projekt už přeci skončil, jak to, že jsou tu stále pravidla, která využíval? Správně by je měl administrátor odstranit, jenže to by se musel dozvědět, že projekt už skončil. Při vytváření procesů je potřeba pamatovat i na to, že se administrátor musí dozvědět o všech podobných změnách. Jakmile nejsou nějaké prostupy potřeba, měl by existovat někdo, kdo bude mít povinnost upozornit, že je možné odstranit patřičná pravidla.

Obrázek 4: Proces vytváření pravidel
Obrázek 4: Proces vytváření pravidel

S tím souvisí i to, že administrátor musí mít ke každému požadavku o vytvoření pravidel také informaci o někom, kdo má odpovědnost za hlášení změn. Díky tomu má možnost převést situaci na PNJ (Problém někoho jiného, viz Stopařův průvodce po galaxii) a odeslat pracovníka informační bezpečnosti jednoduše za někým jiným.

Většinou není vhodné nadbytečná pravidla rovnou mazat. Pokud je to možné, je lepší je pouze zneplatnit. Díky tomu zůstanou připravena pro další použití. Při vytváření procesu je ale třeba pamatovat i na to, že zneplatněná pravidla je potřeba občas odstranit.

V procesu je možné také trochu přitlačit na odpovědnou osobu, aby pravidelně potvrzovala, že jsou prostupy stále potřeba. Sice pak nikdo nebude chtít být odpovědná osoba, ale zajistí se tím, že v bázi pravidel nebudou dlouhodobě zůstávat zbytečná pravidla. Technicky lze toto pěkně kontrolovat pomocí časově omezených pravidel.

Kontrola

Procesy nikdo nedodržuje, pokud nemusí. Teoreticky by možná takový proces mohl existovat, ale takové platy u nás zatím nejsou. Proto je nutné pravidelně kontrolovat, jestli všechno probíhá správně. Nebo alespoň ne úplně špatně.

Kontroly by měly především ověřovat, jestli jsou pro všechna pravidla podklady, a že jsou odstraněna stará pravidla. Když na to někdo bude mít čas, může ideálně zkontrolovat i to, že tyto podklady jsou stále platné. Kontrolovat se toho dá i spoustu dalšího.

Otázka je, kdo by měl kontrolu provádět. Pokud to bude někdo interní, bylo by dobré mu také předepsat, co přesně má kontrolovat, aby na něco nezapomněl. Čas od času je také vhodné pozvat nějaký externí audit, který ověří i to, zda na něco nezapomněl tvůrce procesů.

Proboha, kde na to mám vzít čas?

Je možné, že máte takovou smůlu, že vytváření procesů padlo právě na vás. Nebo jste se k tomu dokonce dobrovolně přihlásili v domnění, že toho nebude moc a uděláte si u šéfa malé bezvýznamné plus. A teď si možná říkáte, že jste to přeci jen neměli dělat, protože toho zase tak málo není a ještě se zdá, že je celkem důležité, udělat ty procesy správně.

Je pravda, že vytvořit procesy dobře a od nuly není úplně jednoduché. Někdy se situace vymkne kontrole a proces způsobí víc škody než užitku. Při vytváření procesů je potřeba pamatovat nejen na to, jak by se něco mělo dělat správně, ale i na to, jak by se to dalo udělat prakticky.

Někdy je lepší si najmout někoho, kdo má s vytvářením procesů zkušenosti. Kdo už může použít připravené procesy, které použil v X předchozích společnostech (z nichž zkrachovalo maximálně 10 %) a jen je upraví pro potřeby té vaší. Ať už tento někdo bude procesy za vás přímo psát, nebo vám bude jen napovídat, je jisté, že vám ušetří hodně práce.

Je na vás, zda si necháte s nastavením a implementací procesů pro správu firewallových pravidel pomoci, nebo to zvládnete sami. V každém případě doufám, že se vám to podaří. Těším se, až k vám přijdeme my, technici, například vyměnit firewall od jednoho výrobce za jiný. A budeme vaši společnost moci připsat na krátký seznam výjimečných, které mají v pravidlech pořádek.

Lukáš Solil Lukáš Solil
Autor článku působí jako Security Specialist ve společnosti AEC a.s.
Chcete získat časopis IT Systems s tímto a mnoha dalšími články z oblasti informačních systémů a řízení podnikové informatiky? Objednejte si předplatné nebo konkrétní vydání časopisu IT Systems z našeho archivu.
OLTIS group


Inzerce

Propojení mezi konstrukčním softwarem a ERP systémem

ve společnosti ŘETĚZY VAMBERK

11-vision-01Společnost Řetězy Vamberk, spol. s r. o., je tradičním výrobcem řetězů a řetězových kol a patří k největším ve svém oboru ve střední Evropě. Cca 75 % jejich produkce je určeno pro export. Poskytují komplexní servis od návrhu a vývoje přes výrobu až po montáž a technickou podporu. Denně zpracují více než 100 požadavků od zákazníků z celého světa. Z toho důvodu se firma neustále zabývá zlepšováním a zefektivňováním provozu, zejména cestou využívání moderních technologií a softwaru.