Hlavní navigace

Práce na dálku: Základní chyby při převodu aplikací do cloudu

1. 4. 2021

Sdílet

 Autor: Adobe Stock
Jak se organizace snaží rychle přesunout své klíčové aplikace do cloudu kvůli snazší podpoře práce na dálku, vytvářejí přitom často příležitosti pro útočníky. Uvádíme nejčastější chyby, na které je potřeba si dát pozor.

S příchodem pandemie mnoho firem umístilo větší rozsah aplikací do cloudu, protože více jejich zaměstnanců pracuje na dálku. V průzkumu společnosti Menlo Security mezi 200 IT manažery uvedlo 40 % respondentů, že v důsledku tohoto trendu čelí nárůstu hrozeb útoků z oblasti cloudových aplikací a internetu věcí (IoT).

Migraci do cloudu lze realizovat dobrými i nevhodnými způsoby. Mnoho úskalí však není tak úplně nových. Například na jednom ze setkání společnosti Gartner v roce 2019 dva IT manažeři uvedli, že jejich nasazení Office 365 se zastavilo z důvodu potřeby modernizovat starší vybavení.

Nyní došlo ke změně způsobu, jakým využíváme a sdílíme naše domácí počítače. Naše počítače vlastně nejsou už tak osobní. Ten samý počítač totiž může sloužit ke vzdálené výuce vašeho dítěte i pro aplikace vašeho partnera.

Průzkum společnosti CyberArk zjistil, že více než polovina respondentů ukládala svá hesla v prohlížečích svých podnikových počítačů. To samozřejmě nevyhovuje žádným přijatelným podnikovým zásadám zabezpečení.

Zde je sedm hlavních chyb, které mohou negativně ovlivnit zabezpečení, a pár tipů, jak se jim vyhnout.

1. Použití VPN pro vzdálený přístup

Když pracují na dálku všichni, nemusí být použití VPN tím nejlepším řešením vzdáleného přístupu. Podívejte se, co se třeba v prosinci 2020 stalo při útoku FireEye. Kompromitovaný účet VPN posloužil hackerům jako vstupní bod. V minulosti jsme používali sítě VPN k zabezpečení práce na dálku.

Je mnohem lepší nahradit sítě VPN sítěmi s konceptem Zero Trust, kde je řídicí rovina tvořena identitou poskytující přístupový kontext. Měli byste používat zásady zabezpečení informací zohledňující specifika práce z domova, které byly vytvořené po začátku pandemie tak, aby vzaly v potaz veškeré relevantní skutečností, mj. také využívání domácího počítače více osobami.

2. Volba nesprávného cloudového portfolia

Tím myslíme zohlednění několika faktorů. Potřebujete privátní cloudy, abyste udrželi stěžejní data vaší firmy oddělená od zbytku vesmíru? Máte k dispozici správné sub-verze OS pro spouštění konkrétních aplikací, které závisí na konkrétních konfiguracích systému Windows nebo Linux?

Máte správné druhy konektorů a autentizační ochrany pro zajištění provozu některých vašich aplikací a vybavení běžícího ve vaší infrastruktuře, kde nepočítáte s migrací?

Pokud máte starší mainframové aplikace, pravděpodobně je budete nejprve chtít zprovoznit v privátním cloudu, abyste našli vhodné prostředí schopné co nejvíce napodobit současnou konfiguraci takového mainframu.

3. Vaše bezpečnostní situace není pro cloud vhodná

Běžné chyby zabezpečení v cloudu zahrnují nezabezpečené úložné kontejnery, nesprávné nastavení přístupových práv a autentizačních parametrů a zbytečně otevřené porty.

Chcete udržet stabilní stav zabezpečení nehledě na to, zda se nacházíte ve své infrastruktuře, nebo se připojujete z druhého konce světa. Také potřebujete integrovat zabezpečení do svého řešení dříve, než byste do cloudu přesunuli byť i jen jedinou aplikaci.

Například společnost Johnson & Johnson to udělala před několika lety, když migrovala většinu svých pracovních zátěží do cloudu a centralizovala svůj bezpečnostní model.

Existuje ale pomoc: Netflix vydal open source nástroj s názvem ConsoleMe, který dokáže spravovat více účtů AWS (Amazon Web Services) v rámci jedné relace prohlížeče.

4. Netestování plánů pro obnovy po havárii

Kdy jste naposledy testovali svůj plán pro obnovu po havárii (DR, disaster recovery)? Pravděpodobně je to už příliš dávno, zvláště pokud jste byli zaneprázdněni snahou udržet krok s denními výzvami při podpoře personálu pracujícího na dálku z domova.

Jen proto, že jsou vaše aplikace v cloudu, to ale ještě neznamená, že nejsou závislé na konkrétních webových či databázových serverech a na dalších prvcích infrastruktury. Součástí každého dobrého DR plánu je dokumentace těchto závislostí a existence scénáře, který popisuje nejdůležitější pracovní toky.

Další významnou součástí každého DR plánu je vykonávání nepřetržitého testování pro dílčí selhání cloudu. Je pravděpodobné, že nějaké výpadky zažijete. Čas od času to postihne i poskytovatele cloudu, jako jsou např. Amazon, Google a Microsoft.

Již zmíněný Netflix byl jedním z prvních míst, kde se před několika lety podařilo pomocí jejího open source nástroje s názvem Chaos Monkey zpopularizovat tzv. chaos engineering. Byl navržen tak, aby testoval firemní infrastrukturu v cloudu AWS neustálým (a náhodným) vypínáním různých produkčních serverů.

Použijte tyto lekce a nástroje k vytvoření vlastní metody testování odolnosti vůči náhodným selháním, zejména s využitím bezpečnostních testů, které odhalují slabiny cloudové konfigurace.

Klíčovým prvkem je zajistit automatizaci a nepřetržitost procesu, aby došlo k odhalení úzkých míst a nedostatků infrastruktury. 

Kromě použití bezplatných nástrojů od společnosti Netflix lze využít i komerční produkty jako Verodin/Mandiant Security Validation, nástroj Breach and Attack Simulation od společnosti SafeBreach, simulační nástroje společnosti Cymulate nebo nástroj AttackIQ Security Optimization Platform.

5. Nedostatečně optimalizovaná autentizace pro převážně cloudové portfolio

Můžete mít nástroje pro správu identit a přístupu (IAM), SIEM, CASB nebo SSO, které jste si pořídili v době svého fungování ve vlastní infrastruktuře, jenže jejich současný způsob využití nepředstavuje ideální řešení Vašich autentizačních potřeb pro fungování převážně v cloudu a převážně na dálku.

Tyto nástroje blíže přezkoumejte a najděte způsob, jak by mohly pokrýt potřeby vašeho cloudového prostředí a celého aplikačního portfolia tak, aby byly vaše systémy odpovídajícím způsobem chráněné.

Přestože jsou například CASB skvělé pro správu přístupu ke cloudovým aplikacím, můžete potřebovat podporu pro svou konkrétní interně vyvinutou aplikaci a možnost práce s autentizací zohledňující riziko, nebo ochranu před sofistikovanějšími a kombinovanými hrozbami.

6. Zastaralost obsahu Active Directory

„Identita je nyní novým perimetrem a data tečou všude,“ popisují David Mahdi a Steve Riley z Gartneru ve své prezentaci. „Musíte dát správným lidem správný přístup ke správným zdrojům ve správný čas a ze správného důvodu.“

To je spousta věcí, které je potřeba udělat správně. To znamená, že váš adresář Active Directory (AD) nemusí odpovídat realitě, a to jak z hlediska seznamu existujících a autorizovaných uživatelů, tak i současných a autorizovaných aplikací i serverů.

Může být nejvyšší čas na pročištění obsahu. Migrace do cloudu půjde lépe, pokud budete používat pro přesun co nejpřesnější informace.

7. Nevyužití potřebné pomoci

soutez_casestudy

Mnoho poskytovatelů spravovaných služeb zabezpečení (MSSP, managed security services provider) se specializuje na tyto druhy migrací. Neměli byste se ostýchat požádat je o pomoc.

Také byste mohli být příliš zaneprázdnění migrací a mohli byste neúmyslně opominout nějaké důležité aspekty. Nebo byste ve spěchu s přesunem všeho do cloudu nechtěně ponechali v systému otevřená několikerá zadní vrátka nebo vytvořili zranitelnosti.

Byl pro vás článek přínosný?