Co ještě brání přechodu na cloud?
Jednotlivé organizace se liší fází, ve které se s přechodem na cloudová řešení nachází. Řada firem se i v dnešní době nachází ve stavu, kdy z důvodu organizačních opatření např. s ohledem na pravidla mateřské společnosti, nemůžou o využití cloudových služeb ani uvažovat. Jiné organizace mohou bojovat s neochotou ke změně u vlastních zaměstnanců. Důležitým faktorem, který společnostem v přechodu na cloud brání, bývá také nedostatečná technologická vyspělost organizace.
Mohlo by vás zajímat: Jak se ženy chovají v dopravě?
Základem je začít dříve, než to udělají vaši zaměstnanci
Doba jde však rychle kupředu a cloudové nástroje pro správu dokumentů se stávají běžnou součástí našich životů. I proto, dříve či později, bude v každé organizaci problematika cloudu s největší pravděpodobností otevřena. Zástupcům bezpečnosti pak zůstává jen jedna možnost – zapojit se proaktivně do těchto iniciativ a podchytit všechny problematické oblasti od začátku. Protože pokud by se rozhodli tyto aktivity ignorovat, případně dokonce zakázat, je více než jisté, že si zaměstnanci najdou svoji cestu a cloudové prostředí ve společnosti vznikne, jen o něm nebude bezpečnost informována.
Celé toto téma může působit jako velké sousto, pokud si ale celou aktivitu rozpadneme do menších dílů, získáme jasnější obrysy jednotlivých kroků. Z pohledu ochrany informací v cloudu se zaměříme na ochranu důvěrnosti (zamezení „data breach“) dat na úložišti ( „data in rest“) a při komunikaci („data in motion“).
Mohlo by vás zajímat: Petr Jedlička: Jaký je vývoj povinného ručení v roce 2020?
Strukturalizace jako základní kámen ochrany
Základem ochrany informací jsou následující parametry: klasifikace, označení dat a vlastnictví. Všechny tyto parametry je poměrně těžké implementovat do on-premise prostředí a vynutit jejich používání uživateli. Běžně se potýkáme s velkou hromadou neklasifikovaných nestrukturovaných dat, které se nám nekontrolovatelně šíří v organizaci a nad kterými jejich vlastník od prvního momentu sdílení ztrácí kontrolu. Požadavky na klasifikaci a označení jsou pouze na organizační úrovni a nejsou implementovány technicky.
Pokud bychom vzali tuto hromadu dat a jednoduše ji přesunuli do cloudového prostředí, zmíněné problémy si ještě rozšíříme o řadu dalších. Bez koncepčního designu takového prostředí můžeme ztratit vhled do síťového provozu externích zařízení, a ještě si rozšířit okruh uživatelů (a zařízení) přistupujících k informacím.
Přípravu konceptu si můžeme rozdělit do několika kroků:
- Zmapování cloudových řešení organizace
- Revize klasifikace informací
- Porozumění životnímu cyklu informace
- Návrh architektonického řešení
- Vyhodnocení dopadu na uživatele.
Prvním a nejdůležitějším krokem je detailní zmapování využívaných / požadovaných cloudových služeb v organizaci a toho, co všechno se oblasti cloudových služeb stihlo stát (i bez našeho vědomí). Touto fází strávíte pravděpodobně nejvíce času, nicméně do budoucna je právě její kvalita klíčová. Zásadní je zapojení businessu, např. formou workshopů, a porozumění, jaká řešení využívají / potřebují do budoucna a proč. V rámci této aktivity si zároveň i zmapujte, jaké jsou již existující a dostupné cloudové licence ve vaší organizaci. Významnou aktivitou je pak i vyhodnocení rizik přechodu na cloudové řešení. Jaká rizika jsou pro vaši organizaci klíčová? Z pohledu dopadu jde spíše o dostupnost informace nebo její důvěrnost? Kvalitní vyhodnocení rizik pak ulehčí tvorbu architektury daného řešení, protože přesně budete vědět na co se zaměřit v jednotlivých fázích životního cyklu organizace a co můžete vyřešit bez vyšších nákladů a energie. Pro účely analýzy rizik lze využít některé ze standardizovaných a již ověřených metodik, jako ISO 27005, IRAM2, OCTAVE a dalších.
Mohlo by vás zajímat: ČNB: Jaká je úspěšnost odborných zkoušek za 3Q 2020?
V dalším kroku je nutné revidovat klasifikaci informací a pravidla jejich označování. Dává nám naše klasická 4stupňová škála (veřejné, interní, důvěrné, tajné) dostatek informací pro přechod na cloud? Je jasné z našich procedur pro nakládání s daty, zda je možné sdílet informaci mimo skupinu nebo externím zaměstnancům? Pokud ne, lze škálu rozšířit o další úrovně. Z pohledu označování je pak důležité si stanovit, jaká budou pravidla pro „auto-labelling“ i kdo může označení měnit na určitém typu informace.
Nepodceňte vizualizaci životního cyklu informací
Abychom byli schopni správně vytvořit architekturu koncového řešení, musíme pochopit celý životní cyklus informace. Jak nám informace vznikne a dostane se do cloudového prostředí, jakým způsobem toto prostředí opouští a co se s ní děje v mezičase. Doporučený způsob je si životní cyklus vizualizovat.
To nám pomůže si ověřit, že nám životní cyklus i jednotlivá opatření fungují i v případě různých uživatelů, různé klasifikace informace nebo různých zařízení, ze kterých je k nim přistupováno. V jednotlivých krocích si pak můžeme zanést i technická / organizační opatření, která budou v daném kroku aplikována. To, jaká opatření zvolit, víme již z našeho prvního kroku – analýzy rizik.
Dále nám může pomoci i některé z nativních řešení daného cloudového řešení (např. MS 365 nabízí Secure Score, který mapuje jednotlivé aplikované kontroly, ohodnocuje je body, vizualizuje úroveň vyspělosti daného prostředí a dává doporučení jaké kontroly aplikovat, aby došlo ke zvýšení vyspělosti).
Důležité je si často připomínat, proč a co děláme, abychom se vyhnuli situaci, kdy implementujeme řešení jen proto, aby bylo, ale postrádáme jeho skutečný smysl. Zde nám opět pomůže výsledek analýzy rizik z prvního kroku. V případě např. DLP je dobré vědět, že nám sice zamezí neúmyslnému úniku informací způsobené chybou zaměstnance, ale nejspíše ne sofistikovanému a úmyslnému pokusu o vynesení informací. Klíčové pak v případě DLP je i zapojení lidských zdrojů a definice disciplinárních řízení – pokud totiž nevymáháme zavedená opatření, postupem času nebudou dodržována.
Mohlo by vás zajímat: Připravují se Evropané na penzi?
Vždy myslete na uživatele vašeho cloudu
V momentě, kdy jsme již pochopili životní cyklus informace i jaká opatření v jednotlivých fázích budeme aplikovat, můžeme začít s návrhem architektury řešení. Z původního nekoncepčního přímého napojení na cloudovou platformu s opatřeními pouze na organizační úrovni nám může vzniknout funkční řešení, které ošetřuje jak interní, tak externí zařízení a využívá nativní technologická opatření dané platformy (konfigurace na úrovni omezení zachycení obrazovky, auto-labelling, a další) i doplňková řešení typu CASB, které nám pomáhá zvýšit viditelnost do síťového provozu externích zařízení. Veškerá komunikace je pak směřována přes např. Azure AD zajišťující správu uživatelských identit přistupujících k informacím v cloudu.
Navržené řešení je pak důležité hodnotit z pohledu dopadu na uživatele. Musíme se ujistit, že navrhovaná architektura nebude mít velký dopad na funkcionalitu koncových stanic a pracovní efektivitu. Zároveň musíme pamatovat na pravidelnou a jasnou komunikaci směrem k uživateli, co se mění a jaké dopady z pohledu funkcionality i zodpovědnosti to na ně bude mít.
Závěrem už jen shrnutí. Co je tedy potřeba udělat?
- Zmapovat si současné prostředí organizace – zorganizovat workshop s jednotlivými skupinami uživatelů a porozumět jejím potřebám spojeným s cloudovými řešeními a zmapovat existující licence.
- Vyhodnotit rizika spojená s přechodem na cloudové řešení.
- Zrevidovat si klasifikaci informací a v případě potřeby ji rozšířit o další úrovně.
- Pochopit životní cyklu informace, jak vzniká, zaniká, jaká opatření jsou v jednotlivých fázích aplikována a zda uvažujeme všechny scénáře, které mohou nastat.
- Navrhnout architekturu cílového řešení s využitím nativních funkcionalit i dodatečných nástrojů.
- Důkladně a průběžně informovat uživatele o změnách a zodpovědnosti z nich vyplývající.
Komentáře
Přidat komentář