(Ne)bezpečnost cloudu a cesty k němu

(Ne)bezpečnost cloudu a cesty k němu

Každá cesta do cloudu je spojena s pozitivními překvapeními i negativními emocemi.  Cloud je velká změna, která vyžaduje adopci. Každá cesta do cloudu je spojena s pozitivními překvapeními i negativními emocemi. Cloud je velká změna, která vyžaduje adopcia správnou sekvenci kroků v IT a bezpečnosti. Porozumíte, jak je pro oblast bezpečnosti důležité pochopení sdílené odpovědnosti v cloudu,znalost smluv s poskytovatele, nastavení cloudového prostředí, využití cloudových nástrojů bezpečnosti a předpřipravených politik,continuous cloud compliance.

                                      Cloud journey                                    Cybersecurity                                    Sdílená odpovědnost                           Politiky a nástroje cloudu                         Landing zóna                       Cloud Continuous Compliance

 

Jak cestu do cloudu vnímají IT týmy – pozitivní emoce na začátku

Na začátku cesty do cloudu převládají v IT týmech pozitivní emoce. Takto začíná 90 % cest do cloudu:

  • radost z nových technologií – kontejnery, AI, Event Streaming, Data bricks…,
  • potěšení – jak jednoduše lze zkoušet, experimentovat a inovovat,
  • cena – na první pohled to nestojí mnoho,
  • snadnost – procesy nezdržují,
  • rychlost – stačí naklikat a propojit dohromady servery, storage, sítě, bezpečnost…,
  • výsledek, který je okamžitě vidět,

… sen každého ajťáka, který si rád hraje a změna je pro něj životní filozofií.

Následuje druhá fáze cloud journey pod heslem „pojďme si cloud vyzkoušet na reálných aplikacích“:

  • nasazení do cloudu jde o něco pomaleji, ale stále rychleji než nyní,
  • některé aplikace do cloudu padnou jako ulité, jiné už méně, některé vůbec,
  • ne všichni ajťáci jsou nadšeni změnou, a už vůbec ne cloudem,
  • připomínají se témata, která jsme dávno měli řešit, ale musely se odložit, např. několik konfiguračních databází, integrace pomocí kafky, migrace na DB Postgres, …

Vystřízlivění a poznání k nezaplacení

Na konci druhé fáze pozitiva přetrvávají, ale přichází vystřízlivění. Každý, kdo s cloudem prošel úvodními fázemi, dojde k mnoha překvapivým poznáním v různých rovinách. Příklady poznání:

  • „Cloud je podobný jako on-premise, ale chová se to jinak“.
  • „Některé postupy se do cloudu dají přinést, ale některé je nutno změnit od základu“.
  • „Náklady jsou transparentně průhledné, ale plná peněženka se rychle vyprazdňuje …“
  • „Možnosti automatizace v cloudu jsou úžasné, ale jak je využít?“
  • „Prostředí cloudu lze nastavit, ale naše aktuální limity schopnosti a znalosti o cloudu určitě způsobí předělání?!“

Cloud je v mnoha směrech jiný než on-premise IT a vyvolává podobně rozporuplné reakce/pocity jako následující obrázek bájného zvířete (viz Obr. 1).

Klášterský obr.1Obr. 1: Rozdílnost On-premise a Cloudu

Cloud je velká změna a pro jeho adopci je potřeba mnoho respektu i odvahy dohromady, obzvláště pro IT týmy s delší historií v on-premise. Ptáte se určitě: Proč?

IT týmy se musejí připravit, že budou řídit a provozovat dvě prostředí: on-premise a cloud, která musejí být navíc integrovaná. Každý, kdo se o to pokusí, zjistí, že začne fungovat zvláštní matematika 1 + 1 = 3 pro aplikace a infrastrukturu:

  • není vhodné se pokoušet o migraci do cloudu – Legacy (Ne Cloud),
  • dává velký smysl využít cloud – Cloud Native (Ano Cloud),
  • je možné za určitých podmínek migrovat – Cloud Ready (Nevím Cloud).

IT týmy s historií mají svůj vzorec chování cesty do cloudu (viz Obr. 2).

Klášterský obr.2Obr. 2: Vzorec cesty do cloud pro IT týmy s historií

Lehká cesta do cloudu je dopřána pouze firmám nově začínajícím nebo těm s krátkou historií, které mají vzorec kouzelně jednoduchý = „Moje IT = Cloud only“.

Odhodlání a realizace

IT týmy odhodlané pro cloud pokračují třetí fází, která znamená jeden nebo více projektů zasazujících cloud do stávajícího IT prostředí:

  1. definuje se, které aplikace jsou vhodné do cloudu a které ne,
  2. stanovují se předpoklady, které musejí nastat, aby využití cloudu bylo maximální,
  3. plánují se vlny nasazení aplikací spolu s řešením architektonických dluhů,
  4. určují se znalosti IT týmu a nezbytný plán pro zvýšení cloudové maturity,
  5. nastavují se cloudová prostředí pro budoucí aplikace,
  6. vytváří se dedikovaný tým pro rozvoj a provoz cloudu,
  7. formuje se pomocný tým pro akceleraci migrace aplikací do cloudu,
  8. sestavuje se tým pro adopci nezbytných procesů a pro koexistenci cloudu a on-premise,
  9. řeší se nezbytné compliance požadavky (pokud jsem regulovaným subjektem),
  10. realizují se vlny migrace aplikací do cloudu (jen ty, které tam patří).

Nic naplat, cloud je specifické řemeslo v IT odvětví a každý jednotlivec i týmy musejí projít nezbytnými kroky poznání cloudového prostředí, aby byli schopni ho zvládnout a efektivně využít. Zkušenosti z úspěšných migrací do cloudu ukazují, že na cestě ke cloudu je nutné projít postupně pěti navazujícími kroky:

  1. Mít strategii – proč do cloudu chci, k čemu ho chci použít a jak se s ním vyrovnat.
  2. Určit roadmapu – s čím do cloudu chci jít a kroky, které musím realizovat.
  3. Navrhnout architekturu – jak správně cloudové prostředí nastavit, aby bylo připraveno na migrace aplikací a rozvíjelo se zkušenostmi s cloudem.
  4. Naplánovat migrace – mít naplánované migrační vlny a pro jednotlivé aplikace definovat, co musí být předem připraveno a otestováno.
  5. Zvládnout provoz – jak se bude monitorovat prostředí, aplikace, bezpečnost, náklady, kapacita, jaké procesy bude nutné upravit, přestat nebo naopak začít dělat

(Ne)bezpečnost cloudu

Každý příběh cesty do cloudu je nerozlučně spjatý s tématem (ne)bezpečnosti. Pro úspěšné zvládnutí bezpečnosti v cloudu je vhodné jako u IT týmů projít experimentováním a adopcí technologií, které cloud poskytuje. Následuje fáze vystřízlivění a poznání, jak technologie, vlastnosti a procesy cloudu pro zabezpečení správně a vhodně využít. Aby se implementace cloudu překlopila z nebezpečného do úspěšného a bezpečného, je nutné navíc zvládnout tři důležité oblasti.

Adopce základních disciplín governance bezpečnosti cloudu

Porozumění sdílené odpovědnosti cloudu, znalost smluv s poskytovateli, nastavení cloudového prostředí a jeho integrace s on-premise, specifické oblasti zájmu pro cloud, základní škola bezpečnosti v cloudu. Zvládnutí těchto disciplín je důležité pro adopci cloudu a porozumění rizik s cloudem spojených.

Porozumění sdílené odpovědnosti cloudu a znalost smluv poskytovatelů

V cloudu platí sdílená odpovědnost mezi zákazníkem a poskytovatelem. Poskytovatel je vždy odpovědný za bezpečnost cloudové platformy. Odpovědnost za bezpečnost dat, koncových zařízení, identity, aplikace a za řízení sítě a infrastruktury se dělí mezi poskytovatele a zákazníka podle typu cloudu podle CIS (viz Obr. 3). V cloudu platí jednoduché pravidlo: „Cloud je moje prostředí a musím se postarat o jeho bezpečnost.“ Orientace ve smluvních podmínkách spolu s pochopením sdílené odpovědnosti určuje hlavní principy řízení bezpečnosti – za co je odpovědný zákazník, za co poskytovatel a co je nutné průběžně kontrolovat. Smluvní podmínky pro cloud jsou klíčovými opěrnými body pro řízení bezpečnosti v cloudu v porovnání s on- -premise.

Klášterský obr.3Obr. 3: Sdílená odpovědnost v cloudu dle cisecurity.org

Dobrý cloudový poskytovatel má ve smluvních podmínkách popsané certifikace a úrovně garancí bezpečnosti včetně podmínek auditu od zákazníků. Nevýhodou smluvních podmínek cloudových služeb je určitá „neměnnost“ v porovnání s individuálními smlouvami.

Klášterský obr.4

Nastavení landing zóny a integrace s on-premise

Zatímco v on-premise se centrální řídící místo buduje těžko, v cloudu je „řídící kokpit landing zóny“ k dispozici od začátku. Aby cloud bezpečně sloužil potřebám, je nutné landing zónu cloudu správně nastavit a integrovat s on-premise:

  • Rozdělení prostorů cloudového prostředí – odpovědnosti pro jednotlivé aplikace, týmy, centrální části IT a bezpečnost.
  • Integrace sítí – nekolizní IP adresace a DNS služby.
  • Zabezpečení přístupů – internet/landing zóna, uvnitř landing zóny propojení s on-premise DC.
  • Zajištění odolnosti služeb – využití povinných a volitelně použitelných služeb.
  • Identita a přístupová práva – integrace s on-premise DC, pravidla přidělování přístupových práv pro běžné a privilegované uživatele.
  • Bezpečnostní logování a monitoring landing zóny – přidělení prostorů a jednotlivých aplikací.
  • Sdílení nákladů na bezpečnost – povinné a volitelné bezpečnostní služby.

U služeb IaaS a PaaS vám poskytovatel dává k dispozici prostředí tenantu a landing zónu i její kokpit si můžete nastavovat podle libosti a bez omezení.

Služby SaaS jsou odlišné a velmi individuální v tom, jakévlastnosti si v landing zóně můžete měnit a nastavovat. Pro governance bezpečnosti je důležité porozumět, jaké služby:

  • jsou základní, obsažené v ceně a mám je vždy dostupné,
  • jsou konfigurovatelné, obsažené v ceně, nasazení závisí na nastavení,
  • jsou konfigurovatelné jako vícenáklad.

Návrh landing zóny může být komplikovaný, pokud existují historické architektonické dluhy, které se IT a bezpečnostním týmům nepodařilo vyřešit před nasazením cloudu. Nasazení cloudu většinou způsobí, že odložená témata je nutno vyřešit. Nastavení odpovědností, pravidel, procesů a politik landing zóny je dalším klíčovým faktorem governance bezpečnosti cloudu.

Zvládnutí oblastí, které v on-premise nejsou vůbec nebo nejsou důležité

V cloudu nabývají na významu témata (většinou netechnická), která jsme dříve neznali nebo nepotřebovali, např.: J

  • Jaká odolnost služeb je k dispozici? – Existují regiony, availability zóny, virtual sety, platformní služby, …
  • Jaký business continuity plán musíme mít? – Kontinuita je závislá na mém řešení, ale i na poskytovateli a typu použitých služeb.
  • Kde jsou umístěna naše data? – Kdo určuje, kde jsou data uložena; kde data mohou nebo musejí být umístěna.
  • Jaké možnosti jejich ochrany máme k dispozici? – Jaké nástroje pro technické zabezpečení jsou k dispozici; využití šifrovacích klíčů – vlastní, poskytovatele; služby pro ukládání šifrovacích klíčů.
  • Jakým způsobem od služeb odejít (exit)? – Jaké nástroje k tomu poskytovatel poskytuje, jaká lhůta je k dispozici.
  • Jak poskytovatel garantuje nakládání s daty? – Od jeho zaměstnanců a subdodavatelů, co se bude dít s daty po exitu.
  • Jak poskytovatel řídí bezpečnost? – Jaké certifikace poskytovatel má; kdo a jak provádí poskytovateli audit.

Ujasnění odpovědí na výše uvedené otázky často vede k revizi již existující architektury cloudového prostředí včetně revize modelu provozu, governance, bezpečnosti včetně rolí a odpovědností.

Využití nástrojů cloudu, které jsou k dispozici

Tato oblast je „střední školou“ bezpečnosti cloudu a předpokládá úspěšné ukončení přechozího stupně. Dobrou zprávou je, že cloudové platformy nabízejí řadu služeb pro bezpečnost v bezplatné i placené verzi, které jen stačí začít využívat:

  • Bezpečnostní nástroje, např.: AWS Security Hub (viz Obr. 4), AWS Config, Azure Policy nebo Defender For Cloud, které umožňují budovat centra bezpečnosti, definici a plnění bezpečnostních politik i vyhodnocování bezpečnostních skóre.
  • Předpřipravená konfigurační pravidla, např.: Je zapnutý web application firewall na našem loadbalanceru? Je databáze zálohovaná? Je zakázán veřejný přístup k našemu Kubernetes clusteru?
  • Předpřipravené bezpečnostní politiky podle různých standardů: ISO 27000:2013, CIS benchmark (Center for Internet Security benchmark, NIST Framework, Payment Card Industry Data Security Standard (PCIDSS).

Klášterský obr.5Obr. 4: AWS Security hub

Stačí pouze aktivovat vybraný nástroj, předdefinovaná pravidla či politiky a začít sledovat informace o stavu shody. Hotová pravidla a politiky lze aplikovat na celou landing zónu, prostory či skupiny prostorů nebo na jednotlivé prostředky v cloudu. Podstatnou výhodou je, že si můžete existující pravidla upravovat podle vlastních potřeb nebo vytvářet svá vlastní.

Continuous cloud compliance

Slova bezpečnost a compliance dostávají v cloudu úplně jiný význam. Díky propojení nástrojů bezpečnosti pro cloud, předefinovaným politikám, automatizaci a vlastnosti IaC (Infrastructure as Code) lze v cloudu snadno, rychle a průběžně zvyšovat svou bezpečnost a pomocí continuous cloud compliance získat vysokou školu bezpečnosti (viz Obr. 5).

Klášterský obr.6Obr. 5: Principy Continuous Cloud Compliance

Jak? Mám-li konfiguraci cloudového prostředku popsanou pomocí kódu (IaC), mohu automaticky pravidelně kontrolovat, zda aktuální konfigurace odpovídá předepsaným standardům bezpečnosti. Mohu i zjistit, zda shoda/neshoda se standardem byla již při vytvoření prostředku nebo až v průběhu provozu a kdo byl autorem změny. Mohu mít pravidelné reporty shody a neshody v jednotlivých časových snímcích. U neshod mohu notifikovat zodpovědnou osobu za daný prostředek, aby neshodu napravila. Nebo dokonce mohu automaticky vynutit, aby se chybějící konfigurace bezpečnostního standardu doinstalovala automaticky. Taková funkčnost „continuous compliance“ je v on-premise obtížně dosažitelná.

Závěr k (ne)bezpečnosti v cloudu

Porozumění sdílené odpovědnosti cloudu, znalost smluv s poskytovateli, nastavení cloudového prostředí a jeho integrace s on-premise, specifické oblasti zájmu pro cloud patří do základní školy bezpečnosti v cloudu. Zvládnutí těchto disciplín zrychluje adopci cloudu, porozumění rizik a mění cloud z nebezpečného na bezpečnější.

Využitím cloudových nástrojů bezpečnosti spolu s předefinovanými pravidly a politiky lze skokově zvýšit kvalitu i úroveň bezpečnosti a dosáhnout maturity bezpečnostii úroveň bezpečnosti a dosáhnout maturity bezpečnostistřední školy. Podmínkou je nepřeskočit základní disciplínygovernance bezpečnosti v cloudu.Následným propojením s automatizací a IaC (Infrastructureas Code) – continuous cloud compliance – akcelerovat bezpečnostna úroveň vysokoškolského diplomu, navíc trvaleudržovaného (viz Obr. 6).

Klášterský obr.7Obr. 6: Continuous Compliance pro trvale bezpečný cloud

Klášterský obr.8Tato e-mailová adresa je chráněna před spamboty. Pro její zobrazení musíte mít povolen Javascript.

Použité zdroje:

[ 1 ] Shared Responsibility for Cloud Security: What You Need to Know. Dostupné z: https://www.cisecurity.org/insights/blog/shared-responsibility-cloud-security-what-you-need-to-know
[ 2 ] AWS Security Hub: Automate AWS security checks and centralize security alerts. Dostupné z: https://aws.amazon.com/security-hub/
[ 3 ] Azure Policy built-in initiative definitions. Dostupné z: https://learn.microsoft.com/en-us/azure/governance/policy/samples/built-in-initiatives
[ 4 ] What is infrastructure as code (IaC)? Dostupné z: https://learn.microsoft.com/en-us/devops/deliver/what-is-infrastructure-as-code
[ 5 ] Cesta do cloudu: co k ní vedlo a jak úspěšně migrovat do cloudu. Dostupné z: https://www.orbit.cz/encyklopedie-cloudu/cesta-do-cloudu-co-k-ni-vedlo-a-jak-uspesne-migrovat-do-cloudu/
[ 6 ] Příprava cloudového prostředí: jak na to? Dostupné z: https://www.orbit.cz/encyklopedie-cloudu/priprava-cloudoveho-prostredi-jak-na-to-2/
[ 7 ] Cloudová zralost: jak jsem zralý pro cloud? Dostupné z: https://www.orbit.cz/encyklopedie-cloudu/cloudova-zralost-aneb-jak-jsem-zraly-pro-cloud/
[ 8 ] Continuous cloud compliance: Aby byl váš cloud stále v bezpečí. Dostupné z: https://www.orbit.cz/encyklopedie-cloudu/continuous-cloud-compliance-aby-byl-vas-cloud-stale-v-bezpeci/


Vytisknout