← Referenční architektury / reference-architecture / design-guides

Zavedení architektury Zero Trust do vašeho startupu

Většina dokumentace Cloudflare (a obecně i dokumentace většiny dodavatelů v tomto oboru) vychází z předpokladu, že zavedení produktů Zero Trust bude vyžadovat odklon od něčeho, co už existuje. Pokud však firma nic takového nemá zavedeno nebo nepoužívá žádný nástroj, který by plnil cíle, o něž váš tým usiluje, může to působit matoucím až odcizujícím dojmem. Nejhůře na tom jsou nové startupy: když veškerou energii věnujete rozjezdu byznysu, čtení dokumentace zaměřené na podniky procházející síťovou transformací může být zdlouhavé a nepřehledné.

Tento průvodce vysvětluje, jak pomocí Cloudflare položit základy architektury Zero Trust už v raných fázích budování vašich postupů v oblasti zabezpečení, sítí a provozu vývoje. Cílem je vybudovat udržitelný a škálovatelný byznys založený na principech zabezpečení Zero Trust.

Základní principy budování „byznysu“ se zásadně proměnily. Před dvaceti lety to mohlo vypadat tak, že jste si pořídili kancelářské prostory (nebo garáž), koupili hardwarovou infrastrukturu, servery a uživatelské počítače, na kterých jste začali stavět. Jak stavba pokračovala, přidávali jste hardwarové firewally a bezpečnostní zařízení, abyste vytvořili firemní perimetr a chránili věci, které existovaly převážně na jednom místě. O vývoji síťových a bezpečnostních postupů existuje spousta kvalitního obsahu, takže se zde tímto tématem nebudeme dále zabývat: důležité je pochopit, jak je „nový“ model relevantní pro váš startup ve fázi budování.

Je velmi pravděpodobné, že dnes většina vaší infrastruktury běží u veřejného cloudového poskytovatele. Většinu kódu pravděpodobně nahráváte a kontrolujete pomocí běžných nástrojů pro správu repozitářů, většina vašich vývojářů píše kód na počítačích s MacOS nebo Linuxem a při lokálním vývoji se pravděpodobně silně spoléhá na určitou formu kontejnerizace. V tomto modelu jsou principy zabezpečení Zero Trust stejně důležité, i když je v tomto stadiu mnohem snazší je naplnit, než až firma naroste do mnoha složitých funkcí, oddělení a stále rozsáhlejší množiny aktiv a dat.

Cloudflare Zero Trust je pro startupy jednoduchým, občas i bezplatným způsobem, jak si vybudovat komplexní strategii Zero Trust, která bude přirozeně růst spolu s vaším podnikáním.

Cloudflare už má k dispozici mnoho materiálů týkajících se migrace a nasazení naší sady produktů Zero Trust. Tento dokument je určen přímo technickým zakladatelům a zakládajícím inženýrům mladých startupů, kteří chtějí od první řádky kódu budovat rámec pro moderní firemní síť s moderními bezpečnostními kontrolami.

V tomto dokumentu se podíváme na:

• Začínáme s praktickými funkcemi vzdáleného přístupu Zero Trust (ZTNA)
• Vytvoření důvěryhodných zdrojů pro identitu a stav zařízení a osvojení si jejich používání
• Budování sítě, tradiční i mesh
• Zavedení Zero Trust do interních nástrojů
• Kontrola hrozeb na internetu
• Dešifrování TLS a jeho význam pro vaše cíle
• Zero Trust pro vaše SaaS nástroje
• Řízení přístupu dodavatelů a zákazníků
• Budování pomocí Infrastructure as Code

Několik věcí, které tento dokument explicitně nepokrývá:

• Úvod do základní terminologie a konceptů Zero Trust
• Doporučení pro použití konkrétních dodavatelů třetích stran, nebo naopak proti němu (i když jsou v tomto dokumentu zmíněni i další dodavatelé, jde čistě o ilustraci a nejedná se o formální doporučení ze strany Cloudflare)
• Podrobnosti o tom, proč zvážit přechod na bezpečnostní metodiku Zero Trust (v odkazech níže najdete řadu užitečných zdrojů s dalšími informacemi)
• Mikrosegmentace a koncepty autonomního Zero Trust (tato témata mohou být pokryta v budoucích aktualizacích)
• Autentizace bez hesla (jde o zajímavou a rychle se rozvíjející oblast, ke které v budoucnu doplníme doporučení)

Pro hlubší základní pochopení Cloudflare doporučujeme následující zdroje:

• Co je Cloudflare? | Web ↗ (čtení na pět minut) nebo video ↗ (dvě minuty)
• Blog: Zero Trust, SASE a SSE: základní koncepty pro vaši síť nové generace ↗ (čtení na 14 minut)
• Referenční architektura: Přechod na architekturu SASE s Cloudflare (čtení na tři hodiny)

Než začnete přemýšlet o cílech vzdáleného přístupu nebo zabezpečení, je důležité zmapovat svá stávající aktiva. Zamyslete se nad odpověďmi na následující otázky:

• Co už existuje a potřebuje udržitelný model zabezpečení?
• Pokud jste začali budovat infrastrukturu u poskytovatele veřejného cloudu, kolik odlišných virtuálních privátních cloudů (VPC) jste už vytvořili a jak spolu tyto sítě komunikují? A hlavně, jak a proč k těmto prostředím přistupují vaši uživatelé?
• Probíhá vše přes konzoli a správu v prohlížeči, nebo přes terminálové nástroje?
• Nastavili jste pro některé služby veřejný přístup na IP adresu přes HTTPS nebo SSH?
• Existují prostředky, které sice mají být zcela privátní, ale mohly by přesto umožňovat přístup z internetu?
• Zavedli jste tradiční VPN pro umožnění vzdáleného přístupu do prostředí a jak je tento přístup podmíněn?

Dále si vytvořte mapu své fyzické a virtuální privátní infrastruktury, v podstatě všeho, co obsahuje firemní data. U řady startupů může jít jen o jednoho cloudového poskytovatele. Zaznamenejte všechny prostředky v tomto prostředí, ke kterým přistupují lidé, jiná infrastruktura nebo veřejná či privátní API, a u každé služby, která zaznamenává pravidelný provoz, popište její účel. Při tom se snažte zodpovědět následující otázky:

• Jde o interní webový nástroj vytvořený pro sledování vaší buildovací pipeline?
• Jde o svépomocí provozovaný analytický nástroj, jako je Grafana, nebo o podpůrný metrický server, jako je Prometheus?
• Jakým způsobem se uživatelé k dané službě připojují: přes veřejnou IP adresu, privátní IP adresu, nebo lokální cestu?
• Mohou se uživatelé ke službě dostat i z jiných cloudových prostředí nebo VPC? Pokud ano, jakým způsobem jsou připojeni?

Jakmile si sestavíte ucelený seznam svých stávajících prostředků, poslouží vám jako inventář aktiv při budování architektury Zero Trust. Pokud nevíte, co potřebujete chránit, bude obtížné to ochránit bez ohledu na to, kolik bezpečnostních nástrojů máte k dispozici.

Hodnotným třetím krokem může být seřazení těchto služeb podle úrovně rizika v případě úniku dat, což později pomůže určit míru podrobnosti vaší bezpečnostní politiky. Váš interní nástroj upozorňující na stav buildu může být například na úrovni 3, zatímco produkční databáze s údaji o klientech bude na úrovni 1. K aplikaci úrovně 3 se může dostat uživatel i ze svého vlastního zařízení, pokud splní požadavky na ověření identity, ale aplikace úrovně 1 může vyžadovat přístup pouze z firemního zařízení a použití konkrétního typu vícefaktorové autentizace (MFA).

Řadu startupů, které používají Cloudflare, k zavedení bezpečnostního přístupu Zero Trust motivují externí strany: investoři, partneři, dodavatelé, analytici rizik nebo pracovníci compliance. I když tento projekt nebo hodnocení iniciují vnější strany, stále je možné stanovit společné cíle, které zajistí měřitelný a žádoucí dopad.

Některé běžné cíle, se kterými se u klientů setkáváme:

• Zajistit uživatelům bezpečný a snadný přístup k interním nástrojům
• Zabudujte zabezpečení přímo do vývojové pipeline
• Zvýšení zabezpečení, aniž by to bylo na úkor uživatelského a pracovního komfortu
• Definujte a zaveďte strategii BYOD (bring your own device)
• Zjednodušte správu sítí a přístupu k aplikacím
• Ochrana dat v aplikacích SaaS a ve firemní síti
• Zajistěte auditovatelnost („stručný přehled toho, co se děje, kdo to dělá a jestli je to v pořádku“)
• Prokažte našim zákazníkům a koncovým uživatelům, že dodržujeme osvědčené bezpečnostní postupy

Vaše cíle mohou být také jednodušší nebo taktičtější, například zavést moderní nástroj pro vzdálený přístup, bezpečně propojit vlastní interní sítě nebo umožnit připojení k tenantu Gitlab Enterprise pouze firemním zařízením. Ať je váš cíl jakýkoli, při jeho stanovování je nejdůležitější určit, co potřebujete nyní, a porovnat to s tím, co budete pravděpodobně potřebovat v blízké až střednědobé budoucnosti. Pokud plánujete výrazný růst, počítáte se zákazníky s náročnými bezpečnostními audity nebo se chystáte žádat o novou certifikaci shody, například SOC II nebo PCI, je zásadní začít u dodavatele řešení Zero Trust, který vám pomůže postupně přidávat další bezpečnostní nástroje a možnosti, aniž by exponenciálně rostla složitost nebo náklady.

Stanovení cílů je také důležitým krokem pro určení priorit. Pokud víte, že vaším hlavním cílem je identifikovat uživatele a před všechny naše interní služby nasadit zabezpečení založené na identitě, ale v následujících šesti měsících plánujete omezit používání zařízení BYOD na aplikace úrovně 3, váš první cíl musí strategicky podporovat plnění toho druhého. Znalost pořadí priorit na několik nejbližších měsíců (a je jasné, že se ve vašem startupu věci mění rychle) vám může ušetřit čas strávený diskusemi o přestavbě architektury nebo rozplétáním technických či obchodních rozhodnutí s dodavateli, kteří vyhovují vašim potřebám z krátkodobého, ale ne střednědobého hlediska.

Identita stojí v jádru každé strategie Zero Trust. Většině zákazníků jde v konečném důsledku o to, aby pomocí centrálního zdroje identity ověřovali, validovali a zaznamenávali veškeré akce uživatele, a to jak u „vlastních“ (hostovaných, privátní síť) aplikací, tak u aplikací SaaS. Na identitu (například prostřednictvím poskytovatele SSO) pak lze navrstvit další bezpečnostní prvky, jako je vícefaktorové ověřování nebo ověřování odolné vůči phishingu.

Jednou z nejdůležitějších věcí, které můžete udělat už v raných fázích, je naučit uživatele používat vícefaktorové ověřování. Cloudflare uvádí možnosti MFA odolné vůči phishingu, jako jsou fyzické klíče, lokální ověřovací aplikace a biometrické ověřování, jako hlavní faktor při zastavení pokusu o narušení ↗ kterému v roce 2022 čelila společnost Twilio a další firmy poskytující SaaS.

Při začátcích se Zero Trust je typ poskytovatele identity, který se rozhodnete použít (nejčastěji Google Workspace a Microsoft Entra Identity), méně důležitý než vaše implementační strategie. Pokud máte zabezpečený adresář, který umožňuje metody ověřování odolné vůči phishingu a je určen jako váš zdroj pravdy, máte vše potřebné k integraci s poskytovatelem Zero Trust, jako je Cloudflare, a k průběžnému ověřování identity jako bezpečnostního stavu napříč všemi firemními nástroji.

Mnoho adresářových služeb také nabízí řešení jednotného přihlašování (SSO) pro přímou integraci s aplikacemi SaaS. I když je to jednoduchá a logická volba, u řady podnikových aplikací představuje integrace SSO problém a onboarding kritického množství aplikací SaaS do jedné adresářové služby může vést k závislosti na jednom dodavateli. Jak vaše organizace dál roste, vaše strategie správy identit se nevyhnutelně bude měnit a vyvíjet, a proto je důležité zachovat flexibilitu pro řešení nečekaných problémů, jako byly některé z úniků u dodavatelů, které jsme viděli v roce 2023.

Vedle problémů s flexibilitou řada poskytovatelů SSO stále plně nezačlenila koncept stavu zařízení do svého modelu takzvaného zdroje pravdy. Někteří dodavatelé, jako Okta, nabízejí certifikaci zařízení jako součást ověřovací události, ale ta je omezena na produkt Okta FastPass a nezahrnuje signály z jiných zdrojů či dodavatelů, které by lépe určily, co vlastně firemní zařízení je.

Nakonec ne vždy budete vlastnit identity, které se používají k přístupu do vašich systémů. Můžete si najmout externí auditory, kteří se potřebují ověřovat pomocí identit vlastní firmy. Můžete se také rozhodnout povolit dodavatelům přístup k soukromým repozitářům GitHub pomocí jejich stávajících identit GitHub. Někdy stačí poskytnout přístup k málo rizikovému zdroji jen na základě e-mailové adresy, například při ukázce náhledu nového uživatelského rozhraní produktu zákazníkům. Vaše řešení Zero Trust proto musí umožnit přístup i identitám mimo váš centrální adresář.

Dále v tomto dokumentu popíšeme, jak pomocí Cloudflare Zero Trust chránit vaše interní aplikace a jak Cloudflare využít jako SSO před vašimi SaaS aplikacemi, aby všude platil jednotný a jednoduchý přístup k zabezpečení.

Cloudflare záleží v tomto případě proto, že jakmile určíte zdroj pravdy pro svého poskytovatele identity, potřebujete nástroje k provádění nepřetržitého ověřování vůči celé své uživatelské základně. Tyto nástroje se obtížně vytvářejí a udržují, o čemž svědčí řada známých technologických společností, které v roce 2023 opustily svůj interně vytvořený proxy Zero Trust a přešly na Cloudflare s odkazem na složitost správy a nemožnost doplňovat nové bezpečnostní funkce.

Cloudflare dokáže zjednodušit vaši architekturu tím, že se stane jediným místem prosazování identity vůči vašim privátním aplikacím, sítím, vývojářským službám i SaaS aplikacím. Cloudflare patří mezi několik málo dodavatelů, kteří umí poskytovat koncepty ověřování Zero Trust jako webovou proxy (služby na vrstvě 7), jako náhradu VPN (služby na vrstvě 3/4) i jako zabezpečenou webovou bránu.

S růstem vaší firmy a s tím, jak začínáte distribuci koncových bodů mezi uživatele provozně zavádět, se stav zařízení stává klíčovou součástí silné strategie Zero Trust. Jakmile ověříte stav identity svých uživatelů, můžete podniknout další kroky, které dále sníží riziko úniku dat. Zamyslete se nad tím: i platný uživatel s aktivní relací identity může mít teoreticky napadené zařízení, a útočníci by z toho mohli těžit (nebo únos) jejich platnou relaci identity.

Firmy používají stav zařízení (device posture) k tomu, aby prokázaly, že připojení pochází z důvěryhodného zařízení. Než uvedeme některé běžné strategie a přístupy pro začátek, podívejme se na teorii, na které stav zařízení stojí. V tomto příkladu máte citlivá data umístěná někde v AWS. Tato data jsou pro chod vaší firmy klíčová. Jsou (správně) chráněna autentizací s ohledem na identitu, takže máte jistotu, že k nim mohou přistupovat pouze uživatelé se správným stavem identity. Všichni vaši uživatelé jsou vzdálení a k AWS se připojují z Macbooků předem nakonfigurovaných s vámi vybraným softwarem pro detekci a reakci na koncových zařízeních (EDR). Uživatelé na svých Macbookách s nainstalovaným podnikovým EDR softwarem mají nižší riziko případného narušení než v případě, kdy k přístupu k firemním datům používají osobní notebooky. Jak ale prokážete, že vaši uživatelé se správným stavem identity pouze přistupovali k vašim citlivým datům ze zařízení s nižším rizikem narušení zabezpečení?

S růstem vašeho bezpečnostního týmu a se zaváděním strategií a nástrojů data loss prevention (DLP) je to dvojnásob důležité. Pokud se uživatelé teoreticky mohou dostat k citlivým datům, aniž by museli doložit důvěryhodnost použitého zařízení, mohou (ať už záměrně, nebo neúmyslně) obejít vaše bezpečnostní nástroje a vytvořit riziko úniku dat, nebo přinejmenším slepá místa ve vaší viditelnosti a auditovatelnosti.

Běžné strategie pro stav zařízení (device posture) obvykle kombinují nástroj pro správu koncových zařízení (například JAMF, Intune apod.), firemní certifikát a bezpečnostní nástroje, jako je EDR software nainstalovaný na zařízení. Některé z těchto nástrojů umí vytvořit otisk zařízení tak, aby jej bylo možné externě ověřit, pokud je to podporováno. Aby bylo možné dosáhnout řízení přístupu Zero Trust s ověřováním stavu zařízení, je obvykle nutné na zařízení nasadit endpoint agenta od dodavatele Zero Trust řešení. Ten pak slouží k „nezávislému“ ověření tvrzení dodavatele třetí strany, než se stav zařízení uplatní v politice. Při hodnocení dodavatelů je důležité posoudit, jak často jsou schopni stav zařízení dotazovat, aby dodržovali filozofii Zero Trust politik založenou na „nepřetržitém vyhodnocování“ stavu.

Jakmile začnete pro dosažení výsledků Zero Trust využívat externí dodavatele, potřebují tito dodavatelé pro nejlepší bezpečnostní rozhodnutí získávat vaše vlastní signály. V takovém případě se Cloudflare stává místem prosazování zásad pro stav zařízení, a to vedle stavu identity. Agent zařízení Cloudflare vyhodnocuje vlastnictví zařízení nebo metriky jeho stavu a společně se zásadami týkajícími se identity uživatele zajišťuje, aby přístup k citlivým prostředkům měl jak správné ověření identity, tak původ ze zařízení splňujícího požadavky s přijatelnou úrovní bezpečnostní kontroly.

Ve „starém světě“ (známém také jako bezpečnostní architektura hrad a příkop) byla infrastruktura obvykle homogenní a chráněná firewallem. Uživatelé mimo kancelář (nebo jiné třetí strany, dodavatelé apod.) se k síťovým zdrojům museli připojovat přes VPN a firewall, případně využít jinou dostupnou síťovou cestu přes veřejnou IP adresu. Protože dnes většina infrastruktury běží v cloudu a většina startupů začíná jako remote first, žádný z tradičních síťových konceptů už nebude při návrhu počátečních fází vaší „firemní sítě“ přímo relevantní.

V tomto tradičnějším síťovém modelu bude vaše infrastruktura pravděpodobně strukturována některým z následujících způsobů:

• Bude existovat v jedné nebo více VPC (které mohou, ale nemusí být propojeny tranzitními branami poskytovatele cloudu)
• Adresaci vašich služeb bude pravděpodobně spravovat váš poskytovatel cloudu
• Budete používat interní DNS od cloudového poskytovatele, například Route53 DNS od AWS (většina firem se na interní DNS do určité míry stále spoléhá, bez ohledu na to, jak cloud-native jsou)
• Dokud si organizace udržuje vlastní infrastrukturu, může mít vždy důvod zachovat určitou koncepci privátně síťovaného prostoru
• Je možné, že ne všichni uživatelé budou potřebovat rozumět vaší interní DNS infrastruktuře nebo se v ní orientovat (technicky zdatní uživatelé a služby to ale pravděpodobně potřebovat budou)

Jakmile ve své infrastruktuře začnete vytvářet ustálené vzory, pravděpodobně se ustálíte u jediného primárního cloudového poskytovatele. Tento dokument se zaměřuje především na uživatele, kteří se připojují k vaší síti kvůli přístupu k interním prostředkům a službám, a na to, jak vaše interní služby obecně komunikují s internetem. Správa oprávnění a zásad cloudové infrastruktury i způsob, jakým spolu vaše interní služby navzájem komunikují, jsou pro komplexní strategii Zero Trust stejně důležité, ale podrobně se jim budeme věnovat až v budoucích aktualizacích tohoto dokumentu.

Pro většinu startupů půjde pravděpodobně o jeden z nejběžnějších případů použití Zero Trust. Možná si kladete otázku: Jak mohu svým uživatelům umožnit přístup k interní síti nebo aplikaci, aniž bych spravoval hardware VPN nebo vystavoval firmu riziku? Při hledání nejlepšího způsobu, jak propojit uživatele s privátními sítěmi a službami při zachování principů Zero Trust, je třeba zvážit dvě důležité věci:

1. Omezení expozice : Filozofie Zero Trust nabádá organizace, aby omezily počet způsobů, kterými lze přistupovat k sítím nebo službám. Veřejné IP adresy nebo vstupní cesty do sítě mohou představovat nežádoucí riziko. Toho se obvykle dosahuje pomocí výhradně odchozích proxy, které se připojují k poskytovatelům Zero Trust a do sítě proxují jen ověřený provoz, aniž by vyžadovaly jakýkoli veřejný přístup přes IP adresu.
2. Omezení laterálního pohybu : Jedním z nejlepších způsobů, jak omezit rozsah případného úniku dat, je uplatňovat přístup s nejnižšími oprávněními pro všechny zdroje. Přístup s nejnižšími oprávněními je základním principem architektury Zero Trust, kdy uživatelé dostávají jen takovou úroveň přístupu, jakou potřebují pro svou roli, místo neomezeného přístupu k celé firemní síti. Nejbližším analogickým konceptem v rámci Zero Trust je koncept takzvaných mikrotunelů: doporučeného přístupu, kdy každá aplikace nebo služba, ke které je potřeba přistupovat, dostane svou vlastní samostatnou 'cestu'. Podobně jako mikrotunely umožňuje přístup s nejnižšími oprávněními vybudovat praxi, kdy mají ke konkrétním zdrojům přístup jen explicitně určené služby a uživatelé, což do budoucna velmi příznivě ovlivňuje postavení bezpečnostních týmů organizace.

Jasná strategie pro vytváření a správu infrastruktury spolu s předvídatelnou strukturou interních IP adres a DNS záznamů bude nedocenitelná pro přístup k vašim aktivům a jejich ochranu, jak vaše organizace poroste. Později v dokumentu se budeme věnovat tomu, jak pomocí automatizovaných workflow vytvářet infrastrukturu, která se okamžitě integruje se zvoleným poskytovatelem zabezpečení Zero Trust. Budete-li mít neustálý a jasný přehled o tom, jaká infrastruktura existuje a jak je aktuálně adresována, bude pro vás mnohem snazší vrstvit bezpečnostní zásady nad své modely řízení přístupu.

Cloudflare Zero Trust dokáže díky kombinaci softwaru pro koncové body a konektorů pro cloudové sítě rozšířit koncepty privátního síťování až k vašim koncovým uživatelům. V takovém případě můžete Cloudflare použít jako „overlay“ síť a rozšířit zabezpečený přístup ke své interní síti pro koncové uživatele, aniž byste vystavovali veřejné IP adresy, povolovali ingress z vašich cloudových prostředí nebo zaváděli jakákoli další rizika, která obvykle vzdálený přístup přináší.

V rámci této „překryvné“ sítě běží ve vaší síti malá softwarová komponenta, která poskytuje jak „síťové“ tunely (dávají uživatelům administrativní přístup ke službám ve vaší interní síti a nahrazují tradiční koncept exponovaného bastionu), tak „aplikační“ tunely (mikrotunely, které umožní ověřenému uživateli přístup výhradně k jediné službě definované v daném tunelu).

Výrazně to usnadňuje správu uživatelského přístupu k více odděleným privátním síťovým prostředím, aniž by uživatel musel měnit profil, přepínat nastavení nebo se neustále odpojovat od jednoho či více klientů a znovu se k nim připojovat. Zároveň to umožňuje snadno zpřístupnit jednu privátní aplikaci nebo službu konkrétním skupinám uživatelů při zachování principů Zero Trust.

U většiny startupů není síťování na prvním místě seznamu věcí, které je potřeba změnit. Firmy obvykle volí cestu nejmenšího odporu, což zpravidla znamená správu propojených VPC v AWS nebo GCP a případně vytvoření několika externích připojení k fyzickým lokalitám. Většina firem ale zjistí, že jejich růst vede ke stále složitější topologii sítě, a tento proces se navíc obvykle odehrává velmi rychle.

Při zjednodušování firemní sítě mezi běžná rozšíření patří zákaznické sítě, partneři, multicloud, akvizice, plánování obnovy po havárii a další. S tím, jak vaše bezpečnostní organizace dozrává, přibývá důvodů rozkládat infrastrukturu do víc VPC (i v rámci stejného cloudového prostředí). A jak se bezpečnostní skupiny pro tyto VPC stávají čím dál složitějšími, zjistíte, že spravujete víc vnitřních sítí s odlišnými zásadami a někdy i odlišným provozem.

S tím, jak jsou tato síťová rozšíření pro vaši firmu stále důležitější, se vyplatí zvážit, které možnosti konektivity dávají největší smysl, a promyslet strategie pro budování funkčně komplexní, ale zásadně bezpečné sítě.

Tradiční metody síťové konektivity mají ve fyzickém i cloudovém prostředí stále značný význam, jejich efektivní využití při zachování funkčního bezpečnostního perimetru ale může být náročné. Když firmy potřebovaly jen fyzickou konektivitu, například pro pobočky nebo doplňková datacentra, bylo řešení mnohem jednodušší. Pro ukončení fyzické konektivity se používala hraniční zařízení, jako jsou routery nebo firewally, nebo dedikované koncové zařízení pro vybudování síťové konektivity VPN („virtuální“) mezi lokalitami. V podstatě šlo o propojení dvou „sítí“ vytvořením nové trasy k nové síti nebo podsíti pro všechny stroje ve výchozí lokalitě.

Kromě vytvoření WAN konektivity je konečným cílem propojení více lokalit zjednodušení správy. Jednotná síť usnadňuje podporu síťových funkcí, jako je edge routing, brány a přidělování adres přes DHCP. To však může vést i k příliš širokým zásadám správy a může být obtížné řídit bezpečnostní dopady stále rostoucích sítí se stále složitějšími okrajovými případy a specifickými scénáři.

U moderních startupů se problémy nemusí přesně shodovat s výše popsanými, přesto budete pravděpodobně muset řešit rostoucí složitost sítě. Nejlepší způsob, jak si s tím poradit, je efektivně plánovat. Pokud budete firemní síť budovat s ohledem na zabezpečení a škálovatelnost už od začátku, snadno zvládnete rostoucí složitost, jak se budou vaše bezpečnostní a IT oddělení dále rozvíjet.

Zatímco tradiční síťové koncepty se zaměřují především na propojování sítí navzájem, koncepty sítí typu mesh nebo peer-to-peer propojují sítě s prostředky nebo samostatnými koncovými body, například koncovými zařízeními uživatelů, jako jsou notebooky a mobilní telefony, nebo zařízeními IoT, jako jsou chytrá světla a bezpečnostní kamery.

V tradiční síti může existovat VPN tunel vytvářející spojení typu site to site mezi rozsahy IP adres 10.0.0.0/8 a 192.168.0.0/24, díky čemuž mají všechna zařízení v obou sítích bránu pro lokální komunikaci se zařízeními v kterékoli z nich. Naproti tomu v modelu mesh sítě může být žádoucí, aby spolu komunikovaly jen určité rozsahy IP adres. Lze tak například umožnit, aby 10.2.3.4 komunikovalo se zařízením s IP adresou 192.168.0.50.

Pokud pracujete pouze s takzvanými mikrotunely (např. konkrétní zařízení X může komunikovat pouze s konkrétním zařízením Y), výrazně tím omezíte možnosti laterálního pohybu útočníka. Například při použití modelu mesh sítě by IP adresa 10.2.3.4 nemohla dosáhnout na citlivá data na jiné adrese v rozsahu 192.168.0.0/24 (zatímco v tradičním síťovém modelu by to možné bylo). Toto zvýšené zabezpečení má ovšem za následek i vyšší komplexnost. Nejenže obvykle musíte spravovat agenty na každém relevantním koncovém bodu mesh sítě, ale zároveň musíte být připraveni vytvářet a spravovat samostatné zásady pro každé aktivum a cestu připojení.

Pokud vám oba provozní modely připadají komplikované a nedokonalé, je to proto, že skutečně jsou. Cloudflare proto věří, že správnou cestou pro firmy všech velikostí je obvykle kombinace obou přístupů.

Pokud vaše organizace experimentuje s mesh konektivitou, může jí Cloudflare pomoci podporovat samostatné modely připojení a zároveň vrstvit jedinečné koncepty identity a podporovat vaše potřeby v oblasti zabezpečení a škálovatelnosti při budování síťové architektury pro budoucí růst.

Produkty Cloudflare, které jsou pro startupy obvykle nejrelevantnější, jsou Cloudflare One Client na uživatelských zařízeních, Cloudflare Tunnel (cloudflared) pro publikování privátních služeb a Cloudflare Mesh pro obousměrné připojení i připojení mezi lokalitami (site to site). Díky tomu můžete spravovat vzdálený přístup, mesh připojení i tradiční síťové připojení z jediného dashboardu. Na podrobnější úrovni to znamená, že z jednoho místa pro prosazování zásad můžete nastavit informace o stavu zařízení, informace o identitě, klientské certifikáty i běžné indikátory na úrovni L4 (například port, IP adresu a protokoly zdroje či cíle), a vytvářet tak robustní bezpečnostní zásady jak pro lidskou, tak pro autonomní síťovou komunikaci.

Tato kombinace síťových modelů podporuje širokou škálu případů použití, ať už chcete zajistit vzdálený přístup ke své firemní síti, rozšířit firemní síť o cloudová prostředí nad rámec on-premise zařízení, nebo dále budovat model mesh konektivity mezi kritickou infrastrukturou bez zvyšování rizika či režijní zátěže.

Téměř u všech začínajících (i zavedených) firem, se kterými Cloudflare spolupracoval, zůstává zabezpečení interních nástrojů běžným problémem. Můžete si vytvořit nástroje potřebné pro úkoly specifické pro vaše podnikání, nebo se rozhodnout pro self-hosting či open source software, který lze rovněž využívat v podobě oblíbených aplikací SaaS pro služby, monitoring či jiné funkce.

Principy popsané v předchozích částech se týkají způsobů správy vzdáleného přístupu k těmto zdrojům a zaměřují se především na autentizaci. Stručně řečeno, k praktickému dosažení modelu Zero Trust potřebujete zajistit, aby přístup ke každé interní službě řídil průběžný autentizační proxy identity, ideálně fyzicky oddělený od hranice vaší sítě, s jasnou auditovatelností a možností rychle podle potřeby odebrat přístup uživateli.

Jednou z největších výzev, kterým firmy při zavádění modelu Zero Trust čelí, ale není autentizace, nýbrž autorizace. Dostat uživatele ke dveřím aplikace je v modelu Zero Trust poměrně snadné, ale správa jeho přihlašovacích údajů pro autentizaci i autorizaci, zajištění jejich souladu a zároveň zachování příjemného a nerušivého uživatelského zážitku může být velmi obtížné.

V ideálním světě by podle nás měla ověřování a autorizaci zajišťovat stejná služba. To by znamenalo, že při rozhodování, jak zabezpečit interní aplikace, ať už zabudováním funkcí OAUTH přímo do nich, nebo přímou integrací s hlavním SSO, které používáte pro SaaS aplikace, byste zároveň zvažovali, jak se vaše metody ověřování mohou dostávat do konfliktu nebo duplicity s metodami ověřování identity. Existují dva základní způsoby, jak tyto koncepty využít k dosažení škálovatelného úspěchu v oblasti ověřování a autorizace.

Koncept 'tokenů dodavatele' neexistuje u každého poskytovatele Zero Trust nebo SSE. Je to dáno poměrně jedinečným přístupem Cloudflare: protože jsme největším světovým poskytovatelem autoritativního DNS, poskytujeme DNS pro 'externí' cestu k vašim interním aplikacím a poté vytváříme tokeny pro přístup uživatelů.

Tyto tokeny vycházejí z informací, které Cloudflare obdrží od vašeho poskytovatele identity po úspěšném ověření, a porovnávají se s vlastními zásadami dané aplikace. Každý token obsahuje veškerý obsah, který by byl podepsán při ověření uživatele u jeho IdP: jméno, uživatelské jméno, e-mail, členství ve skupinách a další přítomné hodnoty. Kromě toho získává jedinečný štítek, který určuje jeho příslušnost ke konkrétní aplikaci.

Jakmile Cloudflare token je vytvořen, předává se vašim interním aplikacím k ověřování jejich požadavků a autorizaci přístupu k vašim interním nástrojům. Vyžaduje to jen minimum dodatečné práce na jednu aplikaci a lze to zakomponovat do workflow vytváření aplikací tam, kde byste jinak potřebovali kompletní integraci OAUTH nebo SSO.

Díky tokenům Cloudflare budou mít vaši uživatelé plynulý zážitek jak ověřování přes váš zavedený proxy Zero Trust a získávat autorizovaný přímo do vaší aplikace se stejnými informacemi.

Někteří poskytovatelé Zero Trust umožňují fungovat i jako poskytovatel SSO a integrovat se přímo s vašimi aplikacemi, například open-source nebo self-hosted řešeními, které mají předpřipravený konektor SSO. V tomto scénáři řídí autorizaci k aplikaci vaše SSO a poskytovatel Zero Trust se dotazuje vašeho zprostředkovatele identity, aby rozhodl o ověření, aniž by bylo nutné spravovat několik primárních adresářů.

Uživatelům Cloudflare to přináší řadu výhod: pomáhá to zjednodušit autentizaci (AuthN) a autorizaci (AuthZ), snižuje to závislost na konkrétním poskytovateli SSO a umožňuje to používat více autentizačních poskytovatelů současně. Především vám to umožní snadno přejít na nového poskytovatele identity nebo jej přijmout. Firmy, které mají 25 až 50 uživatelů, často nepoužívají stejného poskytovatele identity jako firmy s 300 a více uživateli, a přechod z jedné integrace SSO na jinou vždy přináší značné tření. Tento přechod může být obzvlášť obtížný vzhledem k času a frustraci, které některé integrace SSO u aplikací přinášejí. Použití Cloudflare jako poskytovatele SSO pomáhá toto tření zmírnit tím, že agreguje veškerou vaši identitu, kontrolu stavu zařízení a integrace rizik do jednoho místa vynucování zásad, čímž zjednodušuje vaše AuthZ/AuthN a přidává další bezpečnostní kontroly před vaše samostatně hostované aplikace.

Pro vzdálený přístup k vašim interním službám doporučujeme používat produkt Cloudflare Access (prostřednictvím softwaru Cloudflare Tunnel nasazeného ve vaší síti). Se službou Cloudflare Access můžete zpracovat JWT vytvořeného službou Cloudflare Access, nebo použijte Access for SaaS aby fungoval jako proxy SAML nebo OAuth pro vaše privátní, self-hosted aplikace (které mají integraci SSO zabudovanou již od začátku).

V mnoha případech můžete pro přístup k aplikacím dokonce použít oba produkty současně. Pokud například sami hostujete Sentry ↗ , která v současnosti není dostupná na veřejném internetu, postupujte podle těchto kroků:

1. Nastavte veřejný hostname pomocí Cloudflare Access (na který by uživatelé přistupovali, aby se dostali do Sentry).
2. Nainstalujte Cloudflare Tunnel s přidruženým Publikovaná aplikace tak, aby směřoval na vaši lokální službu Sentry.
3. Integrujte Sentry se službou Access for SaaS jako poskytovatelem SSO.

Uživatelé, kteří k aplikaci přistupují mimo vaši síť, budou nyní mít Cloudflare JWT již k dispozici a do aplikace se ověří automaticky, bez dalšího zásahu.

Zavedené a obvyklé vzory vzdáleného přístupu firemních uživatelů se ne vždy dají uplatnit na různorodé skupiny uživatelů, mezi které obvykle patří dodavatelé, externí partneři, a dokonce i zákazníci. Všechny tyto skupiny mohou mít oprávněné důvody pro práci s vašimi privátními zdroji. Můžete si najmout vývojářské nebo servisní dodavatele, kteří potřebují přístup jen k některým částem sítě nebo aplikací, ale poskytnutí plného přístupu k síti by pro ně znamenalo zbytečné riziko.

Také je možné, že svým zákazníkům poskytujete hostované nebo spravované služby, které si následně nasadí ve vlastních sítích. V takovém případě se k těmto službám možná budete muset připojit, abyste je mohli řádně spravovat. Případně můžete pro zákazníky hostovat privátní prostředky ve vlastním prostředí a potřebujete jim dát bezpečný přístup pouze k jejich příslušnému tenantovi.

Kdykoli zjistíte, že potřebujete umožnit přístup uživatelů třetí strany do svého prostředí, měli byste nejprve určit tři atributy:

• K čemu potřebují přístup
• Jaká úroveň ověření je pro daný přístup vyžadována
• Jak dlouho bude tento přístup potřebný

Po určení rozsahu byste měli zvolit model přístupu s nejmenšími oprávněními odpovídající dané skupině uživatelů. To může znamenat integraci se sekundárním poskytovatelem identity (například IdP zákazníka nebo dodavatele) pro použití při ověřování, případně použití dočasné metody ověření, jako je jednorázový PIN zaslaný pouze na jejich e-mailovou adresu.

Některé firmy navíc přidávají uživatele dodavatelů a smluvních partnerů do jejich poskytovatele identity ke zjednodušení ověřování a ke kontrole metod (jako je použití MFA a dalších ověřovacích faktorů). Minimálně doporučujeme spolupracovat s poskytovatelem zabezpečení Zero Trust, který podporuje více současných metod ověřování a umožňuje je uplatňovat prostřednictvím konkrétních zásad nebo aplikací.

Díky tomu si můžete zachovat konzistenci všech stávajících metod zabezpečeného vzdáleného přístupu. Vaši externí uživatelé budou do sítě vstupovat stejnými cestami a budou podléhat všem vašim bezpečnostním kontrolám. Zároveň získáte podrobné protokolování a auditní stopy, které přesně ukazují, k čemu měli uživatelé přístup, jak často jej využívali a jaké akce v síti prováděli. Přidělení kontrol na základě principu nejnižších oprávnění navíc snadno vytvoří přístupový model, který uživatelům zabrání v postranních pohybech nebo v přístupu k prostředkům sítě nad rámec skutečné potřeby.

Pokud tento přístup nelze zajistit přes webový prohlížeč a vyžaduje kontrolu na úrovni sítě, budou si externí uživatelé možná muset nainstalovat agenta koncového bodu používaného pro vaše nasazení Zero Trust. Skupiny kontraktorů mají na jednom uživatelském počítači často připojeno více agentů koncového bodu, což může vnést do směrování sítě složitost, případně i konflikty, pokud se privátní sítě různých firem vzájemně překrývají.

Aby byl proces zajištění přístupu třetích stran jednoduchý a snadno spravovatelný, zvažte následující:

1. Dokáže váš dodavatel Zero Trust podporovat více profilů pro nasazení agenta na koncových zařízeních? Uživatelé externích dodavatelů by měli mít úzce vymezené prvky řízení směrování, které zajistí omezený přístup do vaší sítě a omezené riziko konfliktu s dalšími agenty na zařízení.
2. Liší se přístup třetích stran zásadně od přístupu firemních uživatelů? Pokud ne, můžete zefektivnit administrativní správu vytvořením funkčních identit a integrací pro třetí strany. Nové zásady nemusí být nutně potřeba vytvářet, pokud je vše možné auditovat a rozlišovat.

V některých případech potřebují firemní uživatelé zabezpečený (trvalý nebo dočasný) přístup do zákaznických prostředí, případně zákazníci potřebují obdobný zabezpečený přístup do unikátních hostovaných prostředí ve vaší síti. Tento proces může zahrnovat hostování softwarových tenantů pro zákazníky, provádění údržby softwaru hostovaného u zákazníka nebo poskytování konektorů pro funkčnost produktu propojenou s interními sítěmi zákazníků.

Pro tyto případy užití byla tradičně doporučovaným modelem síťová konfigurace typu site-to-site VPN a podobná řešení. Ta lze sice vhodně omezit rozsahem, často ale vedou k příliš širokému propojení mezi vaší firemní sítí a sítí zákazníka a mohou přinést riziko nebo příliš širokou možnost přístupu.

V rámci zabezpečení podle principu Zero Trust by tento typ přístupu měl být výslovně omezen modelem nejmenších oprávnění. Toho lze dosáhnout nastavením konektivity mezi lokalitami s ohledem na identitu nebo službu, případně použitím jednosměrných modelů konektorů, které poskytují zabezpečený přístup v obou směrech a lze je omezit na konkrétní akce.

Cloudflare dokáže v rámci zero trust poskytnout vašim externím uživatelům omezený zabezpečený přístup jak k webové, tak k síťové konektivitě.

• Cloudflare Access dokáže integrovat a využívat více poskytovatelů identity současně. Toto lze omezit na jedinou aplikaci a jedinou zásadu a lze také podrobně nastavit, že se u některých uživatelů přístup „vynutí“ ověřit konkrétním způsobem. Existuje také řada specifických postupů pro jednotlivé externí poskytovatele, například odůvodnění účelu , které zajišťuje, že přístup uživatelů je pro třetí strany snadný a zároveň zdokumentovaný a kontrolovatelný pro administrátory.
• Cloudflare Zero Trust lze nasadit s flexibilními parametry agenta koncového bodu a logická seskupení pro dodavatele a uživatele třetích stran. Pokud máte externí uživatele s potřebou interního přístupu, můžete jim nastavit úzce vymezená oprávnění a zároveň omezit případný konflikt s dalšími externími systémy.
• Cloudflare Tunnel může fungovat jako jednosměrný model přístupu, který firemním uživatelům poskytuje přístup k vymezeným prostředkům zákazníka. Je odlehčený, snadno se nasazuje a lze ho dokonce zabudovat do vašich nasazovacích balíčků a nasadit společně se službami, které spravujete v prostředích zákazníků.
• Cloudflare Mesh (dříve WARP Connector) vám pomůže vybudovat zabezpečené a rozšiřitelné sítě odpovídající jednotlivým typům klientských ovládacích prvků. To je užitečné zejména tehdy, když obousměrný provoz (site-to-site) potřebujete pro komunikaci se zákazníky, práci s jejich aplikacemi nebo řešení dalších provozních záležitostí. Cloudflare Mesh nabízí stejné možnosti průběžného uplatňování bezpečnostních zásad a auditovatelnosti jako zbytek vašeho nasazení, takže si můžete zachovat model zabezpečení Zero Trust a zároveň zajistit propojení se zákazníky.

Koncept přístupu Zero Trust se tradičně vztahoval výhradně na přístup uživatelů nebo strojů k interním či privilegovaným zdrojům. Na funkční úrovni to znamená nahrazení rozšíření sítě, omezení nadměrných oprávnění a minimalizaci bočního pohybu a vektorů hrozeb, které typicky přináší vzdálený přístup přes VPN. Pro mnoho firem ale jejich VPN nesloužila jen k proxování provozu soukromé sítě. Řídila také jejich internetový provoz a umožňovala jim udržovat jednotný přehled o hrozbách, obvykle buď pomocí modulu odesílajícího dotazy DNS poskytovateli cloudu, nebo prostým zpětným směrováním veškerého uživatelského provozu do podnikové sítě a jeho odesíláním přes podnikové firewally.

Bezpečnostní a komplexnostní problémy tohoto modelu „hrad a příkop“ (castle-and-moat) donutily řadu dodavatelů řešit dvě hlavní funkce, které plní VPN. Dnes je běžné, že se secure web gateway (SWG) a Zero Trust access (ZTNA) zmiňují v jedné větě nebo jako součást jednoho produktu.

Ačkoli tento posun vedli dodavatelé a analytici, a ne bezpečnostní výzkumníci, zdá se, že zlepšil zvládnutelnost zabezpečení pro zákazníky a zároveň zjednodušil proces nákupu a nasazení pro začínající firmy. Nasazení jediného agenta pro zvládnutí firemního i internetového provozu je totiž výrazným zlepšením oproti používání více agentů na zařízení pro veškeré bezpečnostní nástroje.

Ve starém světě byl váš perimetr definován veřejnou výstupní IP adresou a znamenal, že provoz před odchodem na internet procházel řadou bezpečnostních kontrol, ať už šlo o firewall, IPS, IDS nebo něco jiného. Firmy proto začaly u provozu vyžadovat konkrétní zdrojovou IP adresu, aby jej mohly považovat za „důvěryhodný“, a to jak u dodavatelů, třetích stran, tak u SaaS aplikací. Provoz vycházející z firemní sítě (s firemními zdrojovými IP adresami) byl jedním z hlavních ukazatelů „důvěry“. Dnes to už tak jednoduché není.

Dnes vaše firma pravděpodobně nemá žádný centrální „perimetr“. Nejspíš vznikla v cloudu, uživatelům dodává koncová zařízení buď bez úprav, nebo s předem nastavenými bezpečnostními prvky, a veškerý provoz probíhá vzdáleně a asynchronně. Tento model výrazně přispívá k produktivitě a schopnosti škálovat. S tím, jak vaše bezpečnostní organizace roste a dozrává, ale přináší zásadní výhodu nastavení základního bezpečnostního „postoje“, který bude představovat nový perimetr.

Ve světě, kde by váš poskytovatel Zero Trust a vaše SSO měly dokázat chránit většinu vašich privátních aplikací, sítí, služeb a SaaS aplikací, by uživatelé měli mít větší volnost než kdy dřív pracovat odkudkoli. Váš asynchronní, vysoce efektivní způsob práce by tak při dodržování osvědčených postupů neměl muset být přerušován. Jinými slovy, vaše definice „zabezpečeného“ koncového bodu se stává vaším novým firemním perimetrem.

Definovaný zabezpečený koncový bod s jasnou měřitelností je pro bezpečnostní pozici výrazně lepší, protože na rozdíl od zdrojové IP adresy je vysoce cílený a neustále ověřovaný. Ve starém modelu by to znamenalo průchod firewallem a podléhání bezpečnostním kontrolám. V novém modelu to typicky znamená ověřování šifrování, kontrolu stavu zařízení (posture) a určení, zda byl provoz z daného zařízení zkontrolován zabezpečenou webovou branou. Zdrojová IP adresa může být stále součástí ověřování, ale nikdy jako hlavní kontrolní mechanismus.

Při úvahách o tom, jak chcete řídit používání BYOD (a jak zajistit bezpečný přístup k firemním datům), je třeba nejprve určit, co bude tvořit vaši strategii zabezpečených koncových bodů. Poté zvažte, jak byste měli u požadavků na citlivé prostředky ověřovat soulad s touto strategií. Zamyslete se například nad tím, jaké kroky budou uživatelé muset podniknout, aby se dostali k Workday (nebo jinému systému s velkým množstvím osobních údajů). Před udělením přístupu možná budete chtít jejich provoz nasměrovat přes Secure Web Gateway a uplatnit zásady Data Loss Prevention. Nyní se zamyslete, jaké další kroky musíte podniknout, abyste tyto požadavky skutečně vynutili?

V rámci tohoto výkladu chápeme internetovou bezpečnost (např. secure web gateway, DNS filtrování, proxying provozu a podobně) jako soubor pokročilých bezpečnostních signálů, na jejichž základě můžete pro citlivé zdroje uplatňovat přesnější a granulárnější zásady Zero Trust. Je také vhodné začít s DNS filtrováním co nejdříve, protože nasazování softwaru a proxying provozu z vašich koncových bodů se s růstem obchodních a bezpečnostních potřeb bude jen komplikovat. Jakmile začnete uvažovat o dalších pokročilých bezpečnostních kontrolách, jako je HTTP filtrování a prevence úniku dat (DLP), doporučujeme přečíst si Začínáme s dešifrováním TLS ↗ k lepší představě o rozhodnutích, která je třeba učinit před dešifrováním provozu.

Kromě poskytování bezpečnostních funkcí Zero Trust pro interní aplikace, vzdálený přístup k síti a SaaS aplikace nabízí Cloudflare i následující funkce:

• Filtrování DNS
• Firewall na vrstvě L4
• Secure web gateway (SWG), který zahrnuje rozpoznávání aplikací, dešifrování TLS, ochranu proti úniku dat (DLP), funkce CASB, izolaci prohlížeče a možnost využívat vyhrazenou strukturu odchozích IP adres přímo ze sítě Cloudflare

Veškerá funkčnost SWG je řízena zásadami, které zohledňují identitu uživatele, stav zařízení a riziko uživatele, a je poskytována stejným agentem na koncovém zařízení jako vaše ovládací prvky Zero Trust: využívají totéž zásadové jádro (policy engine) a stejné možnosti prosazování zásad.

Cloudflare vám umožňuje fakticky vybudovat nový perimetr tím, že identifikujete odchozí provoz na svých spravovaných koncových zařízeních, uplatňujete na něj zásady a zabezpečujete ho. Díky tomu dosáhnete stejné jednotné bezpečnostní kontroly jako u starého perimetru typu hrad a příkop, ale zároveň uplatňujete nezávislé a granulární bezpečnostní hodnocení, aniž byste museli veškerý uživatelský provoz přesměrovávat zpět. Toto bezpečnostní hodnocení pak můžete využít k nasazení ještě přísnějších kontrol ve svých aplikacích chráněných pomocí Zero Trust, což vám pomůže rozlišovat uživatele s nízkým, středním a vysokým rizikem, rozhodovat, jak nakládat s provozem BYOD, a mnohem více.

Koncept zabezpečení SaaS znamená pro různé lidi různé věci. Proto jde o poněkud kontroverzní téma, zejména ve vztahu k Zero Trust. Služby SaaS zažily během první vlny covidu obrovský nárůst uživatelů, z velké části v důsledku výrazného nárůstu práce na dálku. Téměř přes noc se pro uživatele stalo jednodušší a praktičtější připojovat se ke službám mimo firemní infrastrukturu než ke službám interním.

Někdo argumentuje tím, že aplikace SaaS jsou 1) přirozeně zabezpečené, pokud máte integrované SSO, nebo 2) že je za jejich zabezpečení funkčně odpovědný poskytovatel SaaS. Tyto argumenty se však týkají jen způsobu přístupu k vaší investici do SaaS a jejího zabezpečení, nevysvětlují ale, proč firmy SaaS vůbec používají, a to obvykle pro uchovávání firemních dat. Narůstající počet míst, kde mohou být vaše citlivá data uložena, bude v rozhodování o zabezpečení SaaS hrát stále významnější roli.

Všechna výše uvedená tvrzení předpokládají, že víte, jaké nástroje SaaS vaši uživatelé používají, což ale často neplatí. Nejprve se budeme věnovat „schválenému“ používání SaaS a poté probereme koncepty týkající se „neschváleného“ SaaS (také známého jako shadow IT).

Určení požadované úrovně zabezpečení je pro koncové uživatele důležitým prvním krokem ještě předtím, než vytvoříte jakoukoli bezpečnostní zásadu. Pokud tedy máte aplikace obsahující velké množství firemních dat nebo jiných dat podléhajících zákonům o compliance či jiným regulacím, může dávat smysl omezit přístup k nim výhradně na zařízení spadající do výše zmíněného „perimetru“.

Nejlepší cestou je najít agregátor vašich signálů (například Cloudflare Access for SaaS), který zajistí, aby se všechny jednotlivé části vaší bezpečnostní zásady průběžně uplatňovaly na přístup uživatelů. Dá se toho dosáhnout i s tradičním poskytovatelem SSO? Možná. Okta FastPass například určuje identitu zařízení ověřením certifikátu nainstalovaného na lokálních zařízeních a následným zjištěním zdrojové IP adresy požadavku. Ve většině případů vám ale FastPass neřekne nic dalšího o bezpečnostních kontrolních událostech v provozu daného uživatele ani o stavu zařízení koncového uživatele. Platí totiž, že váš poskytovatel SSO je užitečný jen tak, jak velké množství dat dokáže zpracovat pro rozhodnutí o zásadě.

Pokud se rozhodnete, že pro označení firemního zařízení je vhodný pouze certifikát zařízení, nebo jen jiný signál, je to v jakékoli fázi bezpečnostní vyspělosti firmy naprosto v pořádku. Řada firem totiž zatím nezavedla posuzování stavu zařízení (device posture) v žádné podobě.

Schválené aplikace SaaS lze spravovat i propojením s vaším poskytovatelem Zero Trust přes API. Ten je pak dokáže kontrolovat na chybnou konfiguraci nebo výskyt neočekávaných citlivých dat. Tento proces je nezávislý na tradičních přístupových kontrolách Zero Trust, ale nabízí ho většina poskytovatelů Zero Trust a umožňuje průběžně odhalovat potřebné změny konfigurace napříč všemi vašimi nástroji SaaS v jednom přehledu.

Vyhodnocením výskytu citlivých dat ve spravovaných SaaS aplikacích si můžete začít vytvářet představu o prioritách jednotlivých zásad. Jinými slovy to může změnit váš pohled na to, co by mělo být dostupné přes BYOD a co by naopak mělo vyžadovat autorizovaný přístup ze spravovaného koncového zařízení. Nebo naopak, jak lze kvantifikovat riziko přístupu přes BYOD tak, aby bylo možné uživatele efektivně nasměrovat ke správnému chování?

Bezpečnostní model se výrazně mění, když přejdete od aplikací SaaS, které máte pod kontrolou (tedy je lze propojit se SSO a dalšími nástroji třetích stran), k aplikacím, které pod kontrolou nemáte. Takové aplikace SaaS se často označují jako „neschválené“, ať už proto, že je spravuje sekundární dodavatel, který SSO nepodporuje, nebo proto, že jde o služby, které vaše IT oddělení k používání výslovně neschválilo. Tyto neschválené aplikace se nazývají shadow IT.

Jak se tyto aplikace ve vašem prostředí šíří? Důvod je prostý, zejména ve startupech: uživatelé chtějí postupovat rychle a tíhnou k nejpohodlnějšímu způsobu, jak dokončit svou práci. Někdy to znamená použití nástrojů, které nebyly prověřeny ani schváleny, ať už z hlediska použití, nebo možného ukládání citlivých dat.

Shadow IT se obvykle řeší jako součást obecného programu zabezpečení internetu, který někdy spadá do stejné oblasti úvah, případně ke stejným dodavatelům, jako nasazení Zero Trust. Snížení rizik neschválených aplikací SaaS se téměř vždy odvíjí od viditelnosti. Nejdůležitější věcí, kterou lze udělat bez integrace nástrojů jako SSO nebo CASB do dané aplikace, je pochopit rozsah používání shadow IT.

Zdokumentovat neschválené aplikace obvykle vyžaduje nástroj typu forward proxy, jako je DNS filtr, secure web gateway, nebo nějaký nástroj specifický pro e-mail. Tyto nástroje umožňují zjistit, kteří uživatelé pracovali s neschválenými SaaS aplikacemi, a případně i jak s nimi pracovali (zda nahrávali nebo stahovali soubory, kolik dat přenesli a podobně).

Zavedením zásad a postupů pro dokumentaci využívání SaaS si můžete začít lépe uvědomovat, jak jsou vaše citlivá data v rámci SaaS nástrojů ukládána, přenášena či upravována. Některé firmy omezují používání SaaS pouze na výslovně schválené firemní nástroje, jiné jsou benevolentnější. Žádný z těchto přístupů není špatný, ale pokud si už od začátku vytvoříte rámec pro zachycování informací o využívání, pomůže vám to zpětně dohledat potřebné údaje, kdyby se toto téma pro vaši organizaci stalo naléhavým.

Tento rámec může vašemu IT oddělení pomoci i při rozhodování, u kterých nástrojů zvážit zařazení do nákupních cyklů. Pokud například danou aplikaci už aktivně využívá kritické množství uživatelů, může dávat smysl pořídit k ní funkce úrovně Enterprise. Snížíte tím riziko shadow IT a umožníte týmu nasadit rozšířené zabezpečení, často bez výrazného navýšení nákladů.

Cloudflare dokáže položit základy pro viditelnost a správu vašich Shadow IT prostředí a na následné poznatky. Provoz uživatelů směřující na internet lze auditovat a organizovat z Cloudflare One Client a naší Secure Web Gateway (SWG), a zjistíte, kam se vaše citlivá data přesouvají mimo tenanty SaaS schválené vaší firmou.

To pak může být příležitost k dalšímu rozšíření vaší strategie Zero Trust: nově objevené nástroje můžete explicitně zablokovat nebo povolit, nastavit pro ně konkrétní kontroly zabezpečení dat, nebo je integrovat s vaším dodavatelem Zero Trust (například pomocí Access for SaaS k uplatnění bezpečnostních politik).

Mnoho startupů, se kterými mluvíme, se nakonec obává počtu lidí a odborných znalostí potřebných ke správě bezpečnostních nástrojů, které se pro jejich případy použití jeví jako složité nebo předimenzované. Velkou část vývoje už řídí pomocí orchestračních nástrojů, Infrastructure as Code a přímo přes API, přesto ale často chtějí dosáhnout stavu DevSecOps, kdy lze všechny projekty Zero Trust (a další bezpečnostní nástroje) budovat, spravovat a udržovat jako kód.

I když jde v tradičních bezpečnostních nástrojích o poměrně nový koncept, měli byste jej při hodnocení potenciálních dodavatelů i tak zásadně zohlednit. Mějte na paměti, že ačkoli řada dodavatelů Zero Trust podporuje koncepty jako Terraform, nemusí u těchto dodavatelů existovat, případně být zveřejněný, provider nebo koncové body API pro každý koncept v produktu, což může vést ke zdvojení nebo roztříštění úsilí při správě.

Pokud je vaším cílem jako organizace spravovat síťovou a bezpečnostní infrastrukturu jako kód, je důležité s tímto přístupem začít už v raných fázích cesty k Zero Trust. Ačkoli se přitom můžete potýkat s určitými výzvami, náskok získaný včasným rozvojem sítě se vám vyplatí ve chvíli, kdy nároky vaší firmy a bezpečnosti nevyhnutelně narostou a stanou se hůře spravovatelnými.

Při dalším hodnocení dodavatelských partnerů pro Zero Trust nebo obecné bezpečnostní iniciativy doporučujeme ověřit, že mají dobře zdokumentovaná a kompletní API rozhraní pro celé své produktové portfolio i pro nástroje správy, a to včetně dokumentace pro orchestraci a nástroje Infrastructure as Code (například Terraform).

Zabezpečení Zero Trust v kontextu DevSecOps je pro Cloudflare zásadním tématem. Přístup API-first je hlavní zásadou u všech našich produktů, a proto zpřístupňujeme zákazníkům všechny relevantní koncové body API už první den dostupnosti dané funkce, spolu s naší rozsáhlou dokumentace ↗.

Mnoho našich zákazníků kromě toho spravuje své nasazení Cloudflare Zero Trust, aniž by se kdy dotklo našeho dashboardu, a pro celou svou řídicí rovinu (management plane) místo toho používá Terraform nebo podobné nástroje. Pokud je to i váš případ, máme pro vás komplexní a ucelený Terraform provider ↗ abyste mohli realizovat koncept Zero Trust as Code.

Závěrem, několik promyšlených rozhodnutí, která dnes vaše firma učiní ohledně základů zabezpečení a ověřování, jí přinese užitek na řadu let dopředu. Rozhodnutí, která učiníte nyní, položí základ moderní bezpečnostní infrastruktury, jež se bude plynule škálovat s růstem vaší firmy. Ať už se vydáte jakoukoli cestou, několik dobře zvážených kroků zajistí, že váš startup bude postaven na udržitelných a škálovatelných principech zabezpečení Zero Trust.

Pokud byste chtěli podrobněji probrat své požadavky na Zero Trust a spojit se s jedním z našich architektů, navštivte https://www.cloudflare.com/cloudflare-one/ ↗ a požádejte o konzultaci.