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

Návrh přístupových zásad ZTNA pro Cloudflare Access

Organizace dnes stále více přijímají Zabezpečení Zero Trust ↗ zabezpečení k ochraně firemních aktiv a infrastruktury v neustále se vyvíjejícím prostředí hrozeb. Tradiční zabezpečení spojené se zastaralým návrhem sítě předpokládá důvěru uvnitř perimetru firemní sítě. Zero Trust naproti tomu funguje na principu „Nikdy nedůvěřuj, vždy ověřuj“ a zavádí průběžné ověřování a přísné řízení přístupu ↗ pro všechny uživatele, zařízení a aplikace bez ohledu na jejich umístění nebo síť.

V architektuře Zero Trust obvykle hrají roli dvě technologie. První je Secure Web Gateway (SWG) ↗ filtruje odchozí provoz směřující na internet a brání uživatelům v přístupu na vysoce rizikové weby, například ty zapojené do phishingových kampaní. Aby uživatelé následně získali vzdálený přístup k SaaS aplikacím, interně hostovaným aplikacím a sítím, slouží Zero Trust Network Access (ZTNA ↗) služby se používají k vytváření zabezpečených tunelů a poskytují vzdáleným uživatelům přístup k privátním aplikacím.

Tento průvodce je určen zákazníkům, kteří chtějí nasadit službu ZTNA od Cloudflare (Access) a poskytuje osvědčené postupy a pokyny pro efektivní vytváření správných zásad. Pokud jste tak ještě neučinili, doporučujeme přečíst si také dokument Cloudflare Referenční architektura SASE, která podrobně popisuje všechny aspekty používání Cloudflare v rámci vašich iniciativ Zero Trust.

Tento dokument je určen administrátorům, kteří zvažují nebo již zavedli Cloudflare jako náhradu stávajících VPN služeb nebo jako nový způsob vzdáleného přístupu k interním prostředkům. Slouží jako výchozí bod pro návrh prvních zásad ZTNA i jako trvalá referenční příručka. Tento průvodce obsahuje tři hlavní části:

• Technické předpoklady: Co musí být zavedeno, než budete moci zabezpečit přístup k první aplikaci a definovat přístupové politiky.
• Vytváření zásad: Hlavní součásti přístupové politiky a způsob jejich kombinace.
• Případy použití: Běžné případy použití a zásady, které mohou posloužit jako vzor pro návrh vašich vlastních zásad.

Tento průvodce návrhem předpokládá základní znalost řešení Cloudflare ZTNA, Cloudflare Access. Tento návod se proto zaměřuje na návrh efektivních zásad přístupu a předpokládá, že již máte nakonfigurováno DNS, identita a poskytovatelé stavu zařízení a také vytvořená konektivita k self-hosted aplikacím a souvisejícím sítím.

Na konci této příručky budete umět zavést podrobné zásady přístupu, které prosazují principy Zero Trust napříč běžnými podnikovými scénáři.

Tato část popisuje klíčové architektonické komponenty a koncepty, které je třeba znát před návrhem podrobných zásad přístupu.

Cloudflare umožňuje organizacím zjednodušit přístup k aplikacím pomocí naší cloud pro konektivitu ↗, která bezpečně propojuje uživatele, aplikace a data bez ohledu na jejich umístění. Jádrem této platformy je rozsáhlá globální síť ↗ která uživatelům po celém světě poskytuje konektivitu s nízkou latencí. Díky tomu, že Cloudflare provozuje každou službu v každém datovém centru, aplikuje síťové, výkonnostní a bezpečnostní funkce v jednom průchodu, čímž eliminuje nutnost směrovat provoz přes více specializovaných bezpečnostních serverů, snižuje latenci a předchází výkonnostním úzkým hrdlům.

Přístup k privátním aplikacím a sítím lze zajistit dvěma hlavními způsoby: pomocí veřejného hostname, kdy jsou požadavky proxovány do aplikace, nebo pomocí privátní IP adresy, kdy je uživatel na zařízení nebo v síti, které jej ke privátní firemní síti připojují přes Cloudflare.

Chcete-li používat veřejné názvy hostitelů, musíte mít aktivní doména v Cloudflare. Většina zákazníků používá Cloudflare jako svou primární DNS službu, lze ale nakonfigurovat domény pro použití s Access a zároveň si zachovat Záznamy DNS jinde.

Aby mohla Cloudflare řídit přístup, musí být před aplikací a mít zabezpečenou a spolehlivou síťovou cestu pro úspěšně ověřené uživatele. Požadavky na přístup k aplikaci nejprve projdou přes Cloudflare, kde se uplatní zásady, a teprve po úspěšném ověření jsou požadavky uživatele směrovány do aplikace.

Cloudflare podporuje přístup k následujícím typům aplikací:

• SaaS aplikace na internetu
• Self-hosted aplikace přístupné přes veřejný hostname
• Self-hosted aplikace přístupné přes privátní IP

U SaaS a dalších aplikací dostupných z internetu je přístup z Cloudflare jednoduchý, protože jsou již na internetu. U samostatně hostovaných aplikací ale vytvoříte tunel z Cloudflare do privátní sítě, kde aplikace běží. K tomu existují dvě metody:

• Doporučujeme použít softwaroví agenti jako například cloudflared nebo Cloudflare Mesh. (Upozornění: proxování veřejných hostname na privátní aplikace v současnosti podporuje pouze cloudflared.)
• Pro síťovou konektivitu, Cloudflare WAN (dříve Magic WAN) používá tunely IPsec nebo GRE, které propojují Cloudflare se stávajícími síťovými zařízeními připojenými k soukromým sítím, a Network Interconnect vytváří přímé připojení, pokud vaše aplikace běží na serverech v datacentru, kde působí Cloudflare. (Pokud přecházíte ze stávajících starších řešení VPN na tunely založené na síti, může se vám hodit tento průvodce užitečné.)

Jakmile je připojení k vašim aplikacím navázáno, je čas umožnit přístup uživatelům. V závislosti na požadavcích vašich zásad (o tom více později) mohou uživatelé přistupovat k aplikaci přímo přes internetové připojení na veřejný hostname, nebo pro vyšší úroveň zabezpečení doporučujeme použít naši agent zařízení, klienta Cloudflare One, který vytváří tunel přímo do Cloudflare a zároveň poskytuje informace o zařízení pro použití v zásadách přístupu.

Klíčovou součástí přístupu k aplikacím je ověřování uživatele. Cloudflare k tomu má vestavěné ověřování metodu založenou na e-mailu. Důrazně ale doporučujeme nakonfigurovat poskytovatele identity třetí strany. Podporujeme jak spotřebitelské, tak podnikové poskytovatelé identity, přičemž lze použít libovolnou službu podporující SAML nebo OpenID. Členství ve skupině patří mezi nejběžnější atributy pro definování přístupu k aplikacím a lze je definovat ručně, nebo importovat pomocí systému System for Cross-Domain Identity Management (SCIM).

Posledním předpokladem pro vytvoření skutečně účinných přístupových zásad je nakonfigurovat stav zařízení. Při použití agent zařízení, Cloudflare má přístup k řada informací o zařízení, které lze následně použít v zásadě přístupu. Při použití metoda bez agenta k přístupu k aplikacím jsou k dispozici pouze informace o identitě uživatele. Podporujeme rovněž použití informací o stavu zařízení z jiní dodavatelé, jako jsou Microsoft, Crowdstrike a Sentinel One.

Stručně shrnuto, architektura popsaná doposud znamená, že Cloudflare je:

• Před síťovým přístupem k aplikaci.
• Integrováno s vašimi poskytovateli identity.
• Zohledňuje informace o device posture vašich uživatelů získané pomocí našeho device agenta nebo řešení třetí strany.

Když uživatel odešle požadavek na přístup k aplikaci, musí se nejprve ověřit. Než je přístup udělen, vyhodnotí se zásady aplikace na základě údajů spojených s žádajícím uživatelem. Zásady a další nastavení specifická pro danou aplikaci se definují v aplikaci Access.

Cloudflare Access podporuje čtyři hlavní typy aplikací:

• Self-hosted označuje aplikace, které vaše organizace hostuje a spravuje, ať už lokálně nebo v cloudu. Cloudflare vytvoří veřejný hostitelský název, který používá k zprostředkování provozu do aplikace prostřednictvím zabezpečeného tunelu. Přístup přes veřejné hostitelské názvy je sice podporován, pokud je váš server veřejně přístupný na internetu, doporučujeme však použít cloudflared k vytvoření zabezpečeného, pouze odchozího připojení mezi vaší aplikací a okrajovou sítí Cloudflare. Jakmile k tomu dojde, Cloudflare pak formou reverzní proxy zpřístupní cílovou aplikaci nebo obsah vašim uživatelům.
• Privátní IP aplikace jsou obdobně hostované soukromě, ale nemají plně kvalifikované veřejné hostitelské názvy. Přístup lze zprostředkovat pomocí cloudflared, Cloudflare Mesh, Cloudflare WAN nebo Cloudflare Network Interconnect. Vzdálení uživatelé, kteří nejsou připojeni k síti již propojené s Cloudflare, budou muset k přístupu k aplikaci přes privátní IP adresu použít klienta zařízení, a aby se u uživatelů nemusely používat IP adresy, použijte interní služby DNS k překladu privátních hostname na privátní IP adresy. Přístup je ale možné poskytnout i bez nasazení jakéhokoli softwaru na straně klienta, a to pomocí našeho bezagentního řešení služba izolace prohlížeče.
• SaaS aplikace se přistupuje přes veřejný internet, a proto nevyžaduje žádné tunelové připojení k Cloudflare. Access místo toho funguje jako proxy identity mezi uživateli a SaaS aplikací. Když se uživatel pokusí o přístup k SaaS aplikaci, nejprve ho ověří Cloudflare, který přesměruje na vaši hlavní identitní službu. SaaS aplikace se pak nakonfigurují tak, aby prostřednictvím SAML nebo OAuth důvěřovaly Cloudflare. Díky tomu mohou organizace zavést další vrstvy zabezpečení (například kontroly stavu zařízení) a centralizovat řízení přístupu ke svým SaaS aplikacím, i když SaaS aplikace nebo poskytovatel identity tyto funkce nativně nepodporují.
• Infrastruktura aplikace umožňují uživatelům řídit přístup k jednotlivým serverům, clusterům nebo databázím v privátní síti. Infrastrukturní aplikace fungují tak, že definují „target“, jehož provoz je proxován přes cloudflared, ale umožňuje uživatelům seskupit více strojů pod stejný cíl, tedy definovat společné zásady přístupu napříč potenciálně různorodými infrastrukturními zdroji. Vestavěné funkce protokolování přístupu a příkazů umožňují organizacím uchovávat podrobné auditní záznamy pro účely dodržování předpisů a bezpečnostních šetření.

Aplikace Access obvykle odpovídají přímo jedné aplikaci. Je ale možné, aby aplikace Access a její přidružené politiky byly nasazeny před více než jedním koncovým bodem aplikace. Může se jednat například o rozsah IP adres patřících několika serverům Windows RDP, u kterých chcete uplatnit společnou přístupovou politiku. Stejný princip lze uplatnit i u veřejných hostname, kde může více hostname odkazovat na několik aplikací, na které chcete uplatnit stejné politiky. Můžete mít například wiki.domain.com a wiki.domain.co.uk: jde o různé instance aplikací, ale se společnými požadavky na přístupovou politiku.

Dále se podíváme na hlavní prvky aplikace chráněné pomocí ZTNA, které je potřeba znát pro vytvoření účinných přístupových zásad. Později v dokumentu si pak ukážeme případy použití, které tyto konkrétní prvky využívají.

Ověření identity uživatele je klíčovou součástí každé zásady Zero Trust. Při pokusu o přihlášení do aplikace bude uživatel přesměrován na nakonfigurovaného poskytovatele identity. Pokud se u poskytovatele identity neověří, Cloudflare jeho požadavek na aplikaci nepřijme.

Jak již bylo zmíněno, Cloudflare lze integrovat se všemi vašimi poskytovateli identity (IdP), ať už firemními, nebo spotřebitelskými. Na úrovni aplikace a zásad si pak zvolíte, které IdP chcete pro ověřování povolit. Můžete mít například aplikaci, ke které smí přistupovat jen omezený počet zaměstnanců, a proto pro ni povolíte pouze svého firemního poskytovatele IdP. U jiné aplikace naopak můžete chtít umožnit přístup širší skupině uživatelů mimo firmu, například dodavatelům nebo externím partnerům. Některé z těchto uživatelů pak můžete ověřovat pomocí jejich přihlašovacích údajů GitHub nebo LinkedIn.

Když se uživatel pokusí přistoupit k aplikaci, zobrazí se mu přihlašovací stránka, kde si vybere, přes který IdP se chce ověřit. U aplikací s jediným IdP můžete uživatele k tomuto IdP přesměrovat automaticky. Aplikaci lze také nastavit tak, aby zobrazovala všechny nakonfigurované IdP, díky čemuž můžete v budoucnu přidávat nové poskytovatele, aniž byste museli upravovat zásadu.

Po ověření odešle IdP zpět Cloudflare informace o identitě. V závislosti na IdP mohou tyto informace obsahovat Authentication Method Reference ↗ (amr), skupiny poskytovatele identity, atributy SAML nebo claims OIDC, které lze poté použít v zásadách.

Při použití našeho agenta zařízení se musí uživatelé také ověřit a může se jim zobrazit vlastní seznam poskytovatelů IdP. Jakmile se agent ověří, může se připojit ke Cloudflare, a aplikace lze nastavit tak, aby ověřování přeskočily a místo toho důvěřovaly stávající ověřovací relaci spojené s agentem zařízení.

Dostáváme se k hlavnímu tématu této příručky: zásadám, které definují přístup k aplikacím. Právě zde se odehrává klíčová práce, tedy definování toho, kdo má přístup a jakým způsobem. Než se podíváme na ukázkové případy použití, vysvětlíme si, jak zásady fungují.

Každá aplikace může obsahovat více zásad, které se vyhodnocují v daném pořadí. Protože více zásad, z nichž každá může mít několik sad pravidel, může být poměrně složité, existuje tester zásad: zadáte uživatelské jméno a uvidíte, jak je uživatel vyhodnocen vůči všem zásadám a pravidlům. Zásady se skládají z těchto prvků:

I když se může zdát zřejmé, k čemu to slouží, důrazně doporučujeme mít strategii pro pojmenovávání zásad. Podobné zásady totiž pravděpodobně vytvoříte napříč víc aplikacemi, například „Povolit všem zaměstnancům na plný úvazek“ nebo „Blokovat vysoce rizikové uživatele“. Použití stejného schématu pojmenovávání ve všech aplikacích výrazně zjednoduší kontrolu přístupu k aplikacím a přehled o celém seznamu zásad do budoucna.

Pole Action v zásadě určuje, co se stane, když uživatel nebo služba splní kritéria dané zásady. Existují čtyři hlavní typy akcí:

• Allow uděluje přístup k aplikaci. Při prvním požadavku na přístup se uživateli zobrazí přihlašovací stránka.
• Block odepírá přístup k aplikaci. Obvykle to není nutné, protože přístup je ve výchozím nastavení odepřen. Jediným důvodem, proč by uživatelé měli zavádět blokovací zásadu, je testování konkrétní podmínky zásady nebo zkrácené vyhodnocení zásad. Pokud má blokovací zásada vyšší prioritu než zásada Allow a uživatel jí vyhovuje, veškeré další vyhodnocování zásad se zastaví.
• Bypass umožňuje uživatelům nebo službám vypnout jakékoli vynucování zásad pro provoz ještě před přístupem k aplikaci. Konkrétní endpoint aplikace například může potřebovat být široce dostupný přes internet.
• Service Auth umožňuje ověřovat požadavky od jiných služeb nebo aplikací pomocí mTLS nebo service tokeny. Pokud uživatel nebo služba splní kritéria dané zásady, přihlašovací stránka se jim nezobrazí. Je to navrženo tak, aby k zabezpečeným prostředkům měly přístup i požadavky, které nepocházejí od uživatele, například požadavky z jiných aplikací.

Doba trvání relace udává, jak dlouho zůstává ověření uživatele platné po úspěšném přihlášení do aplikace. Obvykle se doba trvání relace nastavuje na 24 hodin, u citlivých aplikací však lze nastavit i okamžité vypršení platnosti. Tento přístup odpovídá klíčové zásadě Zero Trust „nikdy nedůvěřuj, vždy ověřuj“. I když uživatel na začátku splní požadovaný stav zabezpečení zařízení a identity, neustálé ověřování zajišťuje, že se přístupová práva znovu posuzují při každém novém požadavku. Tato metoda výrazně zkracuje časové okno rizika, protože odstraňuje předpoklad, že počáteční stav ověření a autorizace zůstává platný po delší dobu.

Právě na ně se zásada primárně zaměřuje. Pravidla definují všechny atributy, které určují, zda zásada přístup povolí, zamítne, nebo aplikaci vykreslí v izolovaném prohlížeči. Skládají se ze selektoru a hodnoty, tedy v podstatě z atributu, který chcete vyhodnotit, a dat, podle kterých jej vyhodnocujete.

Každé pravidlo je filtr, který určuje, na které uživatele bude daná zásada dopadat. Existuje několik kategorií pravidel:

• Include pravidla definují, kdo nebo co má nárok na přístup. Pokud uživatel odpovídá pravidlu „Include“, stává se kandidátem na přístup, a to v závislosti na ostatních typech pravidel v dané politice. Tato pravidla používají logiku OR, takže stačí splnit jen jednu podmínku. Aplikaci můžete zpřístupnit například konkrétní skupině, ale zároveň potřebujete zahrnout dodavatele uvedené na e-mailovém seznamu. Pokud uživatel odpovídá alespoň jedné z těchto podmínek (členství ve skupině nebo platná e-mailová adresa), je do pravidla zahrnut. Každá politika musí obsahovat alespoň jednu klauzuli Include.

• Require pravidla stanovují povinné podmínky, které musí být splněny, aby byl přístup udělen. Na rozdíl od pravidel Include používají pravidla „Require“ logiku AND, takže musí být splněna všechna pravidla. Obvykle se používají k tomu, aby nad základními kritérii přístupu definovanými pravidly Include přidala další vrstvu zabezpečení. Administrátoři tak mohou například vyžadovat, aby každý, kdo se pokouší o přístup k aplikaci, použil konkrétní metody MFA.

• Vyloučit pravidla definují výjimky z přístupu a mají přednost před ostatními typy pravidel. Pokud uživatel odpovídá pravidlu „Exclude“, je mu přístup odepřen bez ohledu na ostatní podmínky politiky. Uživatel může například splňovat požadavek na použití metody MFA při přihlášení, ale pokud jeho konkrétní metoda vícefaktorového ověřování (MFA) je definováno v pravidle Exclude, bude zásadou blokováno. Pokud je uživatel přidružen ke skupině IdP s "vysokým rizikem", může být na tomto základě vyloučen i v případě, že splňuje všechny ostatní požadavky na stav zařízení.

Užitečným způsobem, jak si představit, jak se tyto různé typy pravidel uplatňují, je pomyslet na trychtýř. Selektory Include definují, které atributy uživatele, provozu nebo zařízení se zahrnou do politiky, která bude Allowed, Blocked a podobně. Require následně z tohoto seznamu dále filtruje, jaké atributy musí být s uživatelem spojeny, a typ Exclude naopak vyřazuje uživatele, kteří odpovídali jak podmínkám Include, tak Require.

Výše uvedený diagram znázorňuje příklad zásady "All employees and contractors on secure devices using strong MFA". Této zásadě vyhoví každý, kdo patří do skupiny "All Employees", nebo dodavatel, který se ověřil uživatelským jménem ve firemní doméně. Musí přitom používat zařízení s nejnovějším OS a šifrovaným úložištěm. Ověření muselo proběhnout pomocí faktoru MFA, ale ne přes SMS. Aplikaci navíc musí přistupovat přes Cloudflare Secure Web Gateway.

Existuje mnoho různých typy selektorů. Ne všechny možné selektory jsou zde uvedeny, ale následující seznam popisuje konkrétní výsledky, kterých organizace používající Cloudflare Access obvykle chtějí při tvorbě zásad dosáhnout. Pomůže vám pochopit, jak daného výsledku dosáhnout.

• Prochází uživatelský provoz přes Cloudflare Gateway? Zajištění, že uživatel přistupuje k aplikaci výhradně přes náš SWG, Cloudflare Gateway, je účinný způsob, jak zabránit neoprávněnému přístupu způsobenému phishingem nebo krádeží přihlašovacích údajů. Kromě toho můžete zajistit, že veškerý provoz směřující k aplikaci Cloudflare Gateway zaznamenává a filtruje.

  Tuto kontrolu můžete nakonfigurovat aktivací kontroly stavu zařízení „gateway“ a následným vyžadováním „gateway“ ve vašich zásadách aplikací. Vyžadování „gateway“ je flexibilnější než spoléhání se pouze na agenta zařízení, protože uživatelé se mohou připojit i přes Browser Isolation nebo lokalitu připojenou k Cloudflare WAN, přičemž obě tyto možnosti zajišťují logování a filtrování provozu. Navíc při použití agenta zařízení tímto způsobem zaručíte, že uživatel přichází ze zařízení splňujícího soubor kontrol stavu zařízení.

  Vyžadování brány se nepřetržitě vynucuje po dobu self-hosted aplikace. U aplikací SaaS se toto vynucuje pouze při přihlášení. Současně však lze využít vyhrazenou výstupní IP adresu, která zajistí, že provoz vždy prochází přes Cloudflare Gateway.

• Patří uživatel do existující skupiny, nebo má konkrétní atributy identity? Pokud váš poskytovatel identity podporuje SCIM, lze informace o členství ve skupinách importovat do Cloudflare a použít je v zásadách. Údaje o skupinách mohou pocházet také z dat SAML nebo OAuth odeslaných v rámci ověřování. Pokud se používá OIDC nebo SAML a jsou odesílány claims, lze je v zásadě rovněž použít. Pokud se tedy vaši uživatelé ověřují u poskytovatele identity pomocí SAML a výsledný token obsahuje jejich „role“, můžete tuto hodnotu dotazovat v pravidle.

• Jaká identitní služba byla použita k ověření? Stejně jako u skupin a atributů poskytovatele identity se selektor „Login methods“ dotazuje, jaká identity služba byla použita, a podobně jako skupiny poskytovatele identity se lépe hodí do skupiny přístupu než jako samostatná položka v zásadě přístupu. Login methods umožňují uplatnit odlišné zásady na konkrétní uživatele podle toho, u jakého poskytovatele identity se ověřili. Můžete tak například povolit přístup jen uživatelům ověřeným pomocí spotřebitelské identity, jako je GitHub nebo LinkedIn, pokud jejich metoda ověření zahrnovala vícefaktorové ověření (MFA) založené na hardwarovém tokenu.

  Jde o netypický scénář, ale pokud potřebujete pro ověřování povolit více poskytovatelů IdP, můžete tímto selektorem zajistit, že se uživatelé ověřují u konkrétní služby. Přínos tohoto požadavku vynikne zejména u více vrstvených bezpečnostních zásad, kde je potřeba definovat různé úrovně přístupu podle způsobu přihlášení.

• Osobní nebo firemní e-maily Všechny služby identity poskytují e-mailovou adresu, která se v mnoha případech shoduje s uživatelským jménem dané osoby. Použití e-mailu v zásadě se hodí, když chcete povolit přístup celé doméně uživatelů, ale uživatel se může ověřit i přes spotřebitelského poskytovatele identity, který připouští libovolný e-mail. Můžete proto povolit přístup jen uživatelům, kteří se ověřili přes GitHub pomocí e-mailové adresy @company.com.

  Dalším dobrým využitím tohoto selektoru je situace, kdy správujete seznam e-mailů uživatelů, kteří mohou představovat vysoké riziko nebo kterým byl zablokován přístup ke konkrétní aplikaci. Pomocí pravidla Exclude a tohoto seznamu můžete zajistit, že podmnožina uživatelů nebude mít k aplikaci přístup.

• Jak se uživatel ověřil? Když poskytovatel identity ověří uživatele a přesměruje ho zpět na Cloudflare, připojí informaci o tom, jaká metoda ověření byla použita. Obvykle se odesílá jako Authentication Method Reference ↗ data. Pomocí nich můžete zkontrolovat, zda bylo použito MFA a jakého typu.

  To se hodí při definování různých úrovní požadavků na přihlašovací údaje pro různé aplikace. Běžná firemní aplikace může vyžadovat pouze použití MFA bez ohledu na to, jakou formou. Vysoce citlivý administrátorský nástroj ale může vyžadovat hardwarový bezpečnostní klíč FIDO2, a proto při ověření explicitně zamítne přístup, pokud byl použit jen OTP kód přes SMS.

• Ze které země požadavek přichází? Můžete nastavit pravidla podle geografické polohy příchozího požadavku, což se hodí například k omezení přístupu jen na určité země, kde podnikáte.

• Z jakého rozsahu IP adres požadavek přichází? Můžete nastavit pravidla podle rozsahu IP adres příchozího požadavku, například povolit přístup pouze z rozsahů IP adres vaší firemní sítě.

• Je možné ověřit informace o zařízení nebo uživateli podle seznamu? Někdy potřebujete udělit nebo omezit přístup na základě konkrétních vlastností zařízení či uživatele, které přesně nezapadají do jiných kategorií. Zde přichází ke slovu seznamy se hodí: můžete definovat nebo importovat seznam e-mailů dodavatelů nebo seznam schválených sériových čísel zařízení a použít je jako kritéria v zásadě Access. Tyto seznamy lze aktualizovat ručně nebo prostřednictvím našeho API, což umožňuje integraci s dalšími systémy pro správu zařízení nebo uživatelů.

• Je stav zabezpečení zařízení dostatečný? Zde poskytuje telemetrii o samotném zařízení, ze kterého přichází požadavek na přístup, klient zařízení. Děje se tak prostřednictvím kontrol na úrovni zařízení. Je pevný disk zařízení zašifrovaný? Agent dokáže ověřit, zda jsou aktivní technologie jako BitLocker nebo FileVault, a navíc zkontrolovat i konkrétní názvy svazků. Pokud chráníte citlivou aplikaci nebo něco, co obsahuje kritické informace, jde o účinný požadavek, který se vyplatí vynutit.

• Provádí požadavek jiný proces nebo aplikace? O přístup k aplikaci se ne vždy pokouší skutečný člověk na zařízení. Proto se vyplatí využít Cloudflare Access i ke správě komunikace jiného softwaru s API. Požadavek může obsahovat service tokeny, certifikáty mutual TLS a certifikáty SSH, což umožňuje přihlašování automatizovaných procesů a komunikaci typu machine-to-machine. Používání možností service auth v Cloudflare navíc centralizuje ukládání těchto tokenů a certifikátů i správu jejich životního cyklu.

• Co o vašem zařízení říká váš nástroj třetí strany? Mnoho organizací používá pro zabezpečení koncových zařízení další specializované nástroje, jako je Crowdstrike, SentinelOne nebo Microsoft Intune, které poskytují telemetrii o bezpečnostním stavu zařízení odesílajícího požadavek na aplikaci. Místo aby uživatel musel přepínat mezi několika rozhraními, můžete tyto nástroje integrovat do Cloudflare One přes jejich API a jejich poznatky promítnout do atributů stavu zařízení, které lze vynutit při přihlašování k aplikaci.

Níže najdete několik dalších nastavení aplikace, která stojí za zvážení a pomohou zlepšit zabezpečení.

Někdy chcete řídit přístup k vlastní (self-hosted) aplikaci pro méně důvěryhodné uživatele třetích stran, jako jsou dodavatelé nebo partneři. Můžete jim chtít umožnit číst obsah v aplikaci, ale omezit jejich možnost stahovat soubory, kopírovat a vkládat data nebo tisknout stránku. Cloudflare Access umožňuje vykreslit aplikaci ve vzdáleném prohlížeč (pomocí vzdálená izolace prohlížeče neboli RBI) aby se aplikace vykreslovala pomocí headless prohlížeče v naší síti, místo aby se veškerý obsah posílal do prohlížeče uživatele. Díky tomu může Cloudflare následně vynucovat řadu kontrolních mechanismů nad tím, jak uživatel s obsahem interaguje.

Toto nastavení funguje na úrovni zásady, takže jedna zásada může důvěryhodným uživatelům (například zaměstnancům) umožnit běžný přístup k aplikacím, zatímco jiná zásada se zapnutou izolací prohlížeče může na externí dodavatele uplatnit službu RBI.

Toto nastavení směruje provoz před doručením koncovému uživateli do izolovaného prohlížeče, takže veškerý provoz následně kontroluje a spravuje Cloudflare Gateway. Chcete-li omezit, co uživatel může dělat, musíte v Gateway vytvořit doprovodnou zásadu, která identifikuje stejné uživatele a poté vynucuje kontroly chcete omezit přístup. Je důležité napsat zásadu Gateway tak, aby vynucovala RBI jen pro stejnou skupinu uživatelů, na kterou se vztahuje zásada Cloudflare Access pro přístup k aplikaci. Jinak bude zásada ve výchozím nastavení vynucovat izolaci prohlížeče pro všechny uživatele.

Pro stejnou skupinu uživatelů lze RBI skutečně vynutit i v případě, že se pokusí přistoupit k aplikaci z nezabezpečeného zařízení. V takovém případě byste v Cloudflare Access nadále definovali zásadu pro zaměstnance, ale zároveň byste v Cloudflare Gateway vytvořili zásadu, která aplikaci izoluje, pokud uživatelé přistupující na stejnou adresu URL aplikace neprojdou kontrolou stavu zařízení, jež zařízení označí za nespravované nebo nezabezpečené. Může jít o zařízení bez nainstalovaného firemního bezpečnostního klienta koncového bodu, například Crowdstrike nebo SentinelOne, nebo o zařízení, které neprošlo bezpečnostní kontrolou. Ukážeme si to na následujících případech použití.

Naopak izolace prohlížeče chrání i samotné lokální zařízení před pokusy o zneužití zranitelností nebo spuštění škodlivého kódu proti aplikaci.

Můžete chtít auditovat úplně každou autentizační událost aplikace a zaznamenávat důvody přístupu. Toto nastavení vytváří přehlednější auditní stopu přístupů uživatelů a umožňuje administrátorům přezkoumávat a analyzovat vzorce přístupu a jejich zdůvodnění. Po zapnutí budou uživatelé před získáním přístupu vyzváni k uvedení stručného vysvětlení. To se hodí zejména u citlivých aplikací nebo v konkrétních časových obdobích, například mimo běžnou pracovní dobu.

Přidejte další vrstvu řízení přístupu tím, že budete od uživatelů požadovat schválení "temporary authentication" od určených schvalovatelů, než získají přístup k aplikaci. Po zapnutí této funkce vyvolá žádost uživatele o přístup oznámení autorizovaným schvalovatelům.

Jednou z nejdůležitějších součástí definování zásad ZTNA je využití opakovaně použitelných prvků nazývaných Access Groups. Každá skupina přístupu využívá stejná pravidla, jaká jsme právě popsali, k definici uživatelů, provozu nebo zařízení. Tyto skupiny pak lze použít napříč mnoha zásadami k tomu, aby přístup k aplikaci povolovaly, odepíraly, obcházely nebo izolovaly.

Skupinu "Employees" můžete například jednou definovat jako Access Group a poté ji použít v každé aplikační zásadě, kde chcete odkazovat na zaměstnance. Aktualizace této Access Group se pak projeví ve všech zásadách. Je to také dobrý způsob, jak zahrnout vnořenou logiku (například uživatele se zařízením Linux, které má povolený antivirový software)

Níže je diagram s Access Group nazvanou "Secure Administrators", která pomocí řady atributů definuje vlastnosti zabezpečených administrátorů. Diagram ukazuje přidání dvou dalších Access Group do skupiny "Secure Administrators". Tyto skupiny zahrnují zařízení s nejnovější verzí Windows nebo macOS a požadavek, aby zařízení mělo buď File

Nyní, když jsme probrali základní infrastrukturu pro zabezpečení přístupu k aplikaci a systémy zásad, se podíváme na několik běžných případů použití.

Mnoho společností provozuje nějaký interní systém pro správu obsahu, kde jsou uloženy důvěrné firemní informace. Wiki je běžným typem aplikace, která zaměstnancům umožňuje snadno spolupracovat s kýmkoli. Protože jsou ale tyto informace důvěrné, je důležité jak ověřovat uživatele pomocí silných přihlašovacích údajů, tak zajistit, že k nim přistupují ze zabezpečeného zařízení přes zabezpečené připojení.

Firemní uživatelé však někdy potřebují k wiki přistupovat i z nefiremních zařízení. V takovém případě může být vhodné nastavit zásadu, která to umožní, ale zároveň omezí, co uživatel smí dělat, například mu zabrání data upravovat nebo je kopírovat do svého nespravovaného zařízení. Tento případ použití popisuje, jak v Cloudflare Access nastavit aplikaci tak, aby zaměstnancům na zabezpečeném zařízení a přes zabezpečené připojení poskytovala plný přístup, zatímco z nezabezpečeného zařízení jim umožnila jen omezený přístup.

Nejprve vytvořte aplikaci Access s následujícími parametry:

Než se podíváme, jak jsou obě zásady definovány, projděme si příklad, ve kterém byla vytvořena Access Group pro identifikaci zaměstnance, přičemž schválená zařízení musela mít nejnovější verzi operačního systému.

Tato skupina přístupu se použije v obou zásadách a jejím jediným účelem je definovat, co znamená "zabezpečený zaměstnanec".

Toto je velmi jednoduchá skupina Access Group jen se dvěma selektory skupin. Protože ověřujeme členství podle skupin z konkrétního adresáře, znamená to zároveň, že se uživatel musí k tomuto adresáři ověřit. Do budoucna to znamená, že při přechodu na jiného poskytovatele identity nebo při změně požadavků na členství ve skupině definující zaměstnance na plný úvazek stačí upravit tuto skupinu Access Group jen na jednom místě.

Jak vidíte, definuje se zde, že „všichni zaměstnanci“ jsou ti, kdo patří do skupiny Azure AD „Full Time Employees“ a zároveň do skupiny „Completed security training“. První selektor určuje počáteční rozsah Access Group, druhý selektor pak vyžaduje, aby dané osoby patřily i do této konkrétní skupiny.

Tato skupina přístupu vyžaduje, aby tři kontroly stavu zařízení byly vytvořeny pro Verze OS. Kontrola stavu (posture check) „Latest version of macOS“ je například definována jako „macOS version is greater than or equal to 15.1“ a odpovídá nejnovější verzi, kterou firma považuje za stabilní a bezpečnou (na rozdíl od skutečně nejnovější verze OS). Jakmile se zahrne do zásady Access, vynutí se tím právě popsaná logika: pokud se chce uživatel přihlásit jako „Secure Employee“, musí tyto požadavky splňovat.

Nyní definujeme první zásadu v aplikaci. Nejprve vyberte již definovanou Access Group. Poté nastavte následující pravidla, která určí, jak se uživatelé ověřují a jak se k aplikaci připojují.

Tato zásada zajišťuje, že uživatelé získají plný přístup k firemní wiki, pouze pokud splní následující požadavky:

• Jde o zaměstnance na plný úvazek se zařízeními s nejnovější verzí operačního systému.
• Uživatelé se ověřili pomocí MFA.
• Uživatelé přistupují k aplikaci ze zařízení, na kterém běží agent zařízení Cloudflare.

Druhá zásada by měla řešit uživatele, kteří nepoužívají zabezpečená zařízení. Tato zásada je v seznamu zásad aplikace druhá v pořadí, a vyhodnocuje se tedy až tehdy, když uživatel nesplní požadavky první zásady.

Ačkoli je tato zásada velmi podobná první, odstraňuje požadavek na zařízení s nejnovějším operačním systémem a na použití našeho agenta na zařízení. Uživatel musí i nadále být zaměstnancem na plný úvazek ověřeným pomocí silných přihlašovacích údajů s vícefaktorovým ověřením (MFA).

Všimněte si však, že nyní zapneme možnost „Isolate Application“. Co to znamená? Všechny požadavky na aplikaci se od této chvíle vykreslují prostřednictvím naší technologie RBI. RBI zabrání tomu, aby se uživatelské rozhraní wiki načítalo přímo v prohlížeči koncového uživatele, a místo toho obsah vykresluje headless prohlížeč běžící na serveru v globální cloudové síti Cloudflare. Výsledek tohoto vykreslení se pak bezpečně a efektivně přenáší zpět do prohlížeče koncového uživatele. Díky tomu požadavek prochází i naší službou SWG, což vám umožňuje napsat zásadu, která řídí, jak mohou uživatelé s wiki pracovat.

Gateway HTTP Policy

V příkladu výše zásada SWG odpovídá veškerému provozu směřujícímu na firemní wiki, následně vynucuje RBI (v souladu se zásadou aplikace ZTNA) a poté zakazuje jakoukoli interakci s wiki.

Zároveň přidá kontrolu stavu zařízení "WARP Check (Mac OS)", která na zařízení uživatele ověří přítomnost našeho agenta zařízení. Pokud uživatel nemá agenta nainstalovaného a povoleného, kontrola stavu zařízení neproběhne a požadavky zásad automaticky nesplní. Pokud uživatel agenta zařízení povoleného má, kontrolou projde a získá plný přístup k wiki. Upozorňujeme, že "WARP" je předchozí název pro Cloudflare One Client, což je agent zařízení od Cloudflare.

Zaměstnanec na nezabezpečeném zařízení má v podstatě povolen jen prohlížeč wiki v režimu „pouze pro čtení“, ale nemůže provádět další akce, jako je nahrávání/stahování nebo kopírování a vkládání důvěrných informací.

Tento přístup k zásadám plní hned několik cílů:

1. Vynucuje používání důvěryhodných zařízení pro plný přístup k wiki, což odpovídá vašim bezpečnostním cílům v oblasti Zero Trust.
2. Poskytuje záložní možnost pro zaměstnance používající osobní zařízení, kteří tak mohou k wiki přistupovat omezeně, ale bezpečně díky izolaci prohlížeče.
3. Motivuje zaměstnance k používání firemních zařízení a/nebo k udržování povoleného Cloudflare One Client, což celkově zlepšuje úroveň zabezpečení organizace.
4. Ukazuje sílu a flexibilitu detailnějších bezpečnostních kontrol, kterých dosáhnete kombinací zásad Cloudflare Access se zásadami HTTP v Cloudflare Gateway.

Tento přístup zabezpečuje vaši wiki a zároveň vytváří model pro ochranu dalších aplikací, díky čemuž si organizace udržuje vysokou úroveň kybernetické hygieny a zároveň se přizpůsobuje realitě hybridní práce.

Druhý případ použití zavádí strategii zabezpečeného přístupu, která rovněž vyžaduje použití klienta zařízení. Její implementace je ale o něco náročnější než u předchozího příkladu s wiki.

Než se dostaneme ke konkrétním krokům, seznámíte se s výhodami zabezpečení přístupu k aplikacím SaaS pomocí Cloudflare. Salesforce a další velcí poskytovatelé SaaS ostatně už dnes nabízejí robustní zabezpečení, včetně vlastního řízení přístupu, MFA a auditních záznamů. Proč tedy některé organizace i přesto směrují svůj provoz SaaS přes Cloudflare?

Klíčovým přínosem je centralizace vynucování bezpečnostních zásad napříč celým IT ekosystémem. Nasměrováním přístupu k Salesforce přes Cloudflare nejen zabezpečíte Salesforce, ale zároveň jej začleníte do širší strategie Zero Trust, která přináší jednotný přehled o veškeré aktivitě uživatelů a snižuje složitost správy více bezpečnostních systémů. Zároveň tak můžete pro přístup k jediné aplikaci SaaS vynucovat zásady mnoha různých IdP.

V kontextu tohoto případu použití je důležité chránit Salesforce, který obsahuje citlivá data zákazníků, před zneužitím a zajistit přístup pouze oprávněným uživatelům. Navrhneme zásadu zabezpečeného přístupu, která pokryje oba tyto cíle.

Prvním krokem je nakonfigurovat zásada odchozí IP adresy ve službě Cloudflare Gateway. Díky tomu můžete zakoupit a přiřadit konkrétní IP adresy svým uživatelům, jejichž provoz je filtrován přes Gateway. V Salesforce pak můžete vynutit, aby byl přístup povolen pouze provozu, jehož zdrojová IP adresa odpovídá té ve vaší zásadě pro odchozí provoz. Tato kombinace zajišťuje, že jediná cesta k přístupu do Salesforce vede přes Cloudflare.

Nejde jen o zabezpečení přístupu k Salesforce, ale i o odpovídající ochranu jeho obsahu při používání. Dalším krokem je podívat se na zásadu přístupu, která je podobná té, jakou jsme právě vytvořili pro wiki. Tato zásada však omezuje přístup na členy skupin Sales nebo Executives. Zároveň využíváme integraci s Crowdstrike, abychom zajistili, že uživatelé pracují na zařízeních spravovaných firmou.

Druhá zásada se nyní vztahuje na všechny zaměstnance, před udělením přístupu ale ještě uplatníme několik dalších kroků.

Do této druhé politiky nyní přidáme dočasné ověřování. To znamená, že pokud Cloudflare vyhodnotí, že příchozí požadavek pochází od někoho mimo oddělení Sales nebo Executives, bude muset administrátor takový dočasný přístup výslovně schválit. V praxi lze tuto politiku využít například k zabezpečení přístupu do Salesforce pro zaměstnance mimo oddělení Sales, protože zákaznické údaje mohou být citlivé a důvěrné.

Tento přístup je důležitý z několika důvodů:

• Umožňuje lidský dohled nad potenciálně rizikovými pokusy o přístup a snižuje tak riziko neoprávněného přístupu přes kompromitovaná nebo nezabezpečená zařízení.
• Poskytuje legitimním uživatelům flexibilitu při přístupu k aplikaci i v případě, že jejich zařízení nesplňuje nejpřísnější bezpečnostní standardy. To uživatele motivuje udržovat na svých zařízeních dobré bezpečnostní návyky.
• Protože je navíc veškerý uživatelský provoz směrován přes Cloudflare, můžeme prostřednictvím zásad pro webový provoz vynucovat další bezpečnostní opatření (například zamezení stahování citlivých dat).

Tento scénář se týká ochrany nástroje pro správu databáze PostgreSQL. Jde o privátně hostovaný cíl s vysokou hodnotou vzhledem k přístupu k citlivým datům, což vyžaduje mimořádnou péči při návrhu zabezpečeného přístupu. Vzhledem k povaze databázových nástrojů nebudou zásady přístupu v tomto případě vrstvené.

Zde zavádíme velké množství kontrol bezpečnostního stavu, počínaje MFA. K MFA máme dva výrazy: první vyžaduje, aby se uživatelé ověřovali metodou MFA. Druhý výraz typu 'vylučuje' určuje, že SMS se nepovažuje za platnou metodu ověření. Děláme to proto, že SMS patří mezi metody, které útočníci snadněji zneužijí a obejdou, a proto považováno za méně bezpečné ↗ než ostatní metody MFA. Přístup proto povolujeme pouze v případě, že uživatel poskytne silnější přihlašovací údaje, například hardwarový klíč nebo OTP z autentizační aplikace. Vynucení těchto přísnějších požadavků na MFA snižuje riziko útoků založených na kompromitovaných přihlašovacích údajích a útočníkům výrazně ztěžuje neoprávněný přístup k této kritické databázi, a to i v případě, že by heslo uživatele získali.

Mezi další prvky posture zde patří:

• Vyžadování nejnovějšího OS.
• Zařízení uživatele je připojeno k doméně Microsoft Active Directory.
• Zařízení uživatele je výslovně firemní spravované zařízení (prokazuje se odkazem na seznam sériových čísel spravovaných zařízení).

Tato kombinace kontrol stavu zařízení zajišťuje, že k databázi mají přístup pouze aktuální zařízení pod kontrolou firmy v rámci vašeho spravovaného prostředí, čímž se dále zmenšuje útočná plocha a riziko přístupu z potenciálně kompromitovaných nebo nespravovaných koncových zařízení.

V dalších nastaveních také vyžadujeme, aby uživatelé při přístupu k databázi uvedli zdůvodnění účelu. Vašim bezpečnostním týmům to umožňuje analyzovat vzorce přístupu a odhalovat potenciálně podezřelé chování. Tato sada bezpečnostních kontrol zároveň zajišťuje, že přístup ke kritické databázi je přísně regulovaný, zaznamenávaný a zdůvodněný, což výrazně snižuje riziko neoprávněného přístupu nebo zneužití.

Dosáhnout stejné úrovně ochrany a přehledu pomocí oddělených samostatných bezpečnostních řešení by bylo výrazně složitější a náročnější na zdroje. Centralizace prosazování bezpečnostních zásad prostřednictvím Cloudflare zjednodušuje zavedení jemně odstupňovaného přístupu ke kritickým interním zdrojům.

Poslední případ použití se týká zabezpečení vzdáleného přístupu k zařízením přes RDP, a to dvěma způsoby: řešením typu self-hosted nebo prostřednictvím privátní IP adresy. Obě varianty mají své přednosti, konečná volba ale závisí na vašich prioritách: je pro vás důležitější zjednodušit přístup, nebo důsledně sledovat aktivitu?

Začneme variantou se self-hosted řešením: port 3389 přesměrujeme přes tunel a namapujeme jej na hostname.

Definujte zásadu:

V rámci zásady jsme tuto aplikaci zpřístupnili nové přístupové skupině pro IT Admins. V sekci "Require" konkrétně vynucujeme použití Cloudflare One Client (na rozdíl od samotného Cloudflare Gateway). Uživatel musí být na zařízení spravovaném firmou s aktivním klientem zařízení ověřeným vůči firemní instanci Cloudflare, při přihlášení musí použít MFA a níže je k dispozici další volitelná možnost pro externí vyhodnocení.

External evaluation znamená, že máme endpoint API obsahující nějaký logika přístupu ↗ : v tomto případě přístup podle denní doby. Voláme API tohoto koncového bodu a definujeme klíč, který Cloudflare používá k ověření, že odpověď skutečně pochází z tohoto API. To je užitečné z několika důvodů:

External evaluation umožňuje uživatelům vytvářet vlastní kontroly stavu zabezpečení podle kritérií, která nemusí pokrývat výchozí sada kontrol stavu. V tomto příkladu použijeme službu založenou na Cloudflare Workers ↗.

• Omezení přístupu k terminálu mimo pracovní dobu je formou časově podmíněného řízení přístupu. Tím se přidává další vrstva zabezpečení, protože se zužuje časové okno, které by útočníci mohli využít.

Nyní se naučíte, jak zabezpečit přístup RDP jako privátní IP aplikaci:

Jak již bylo zmíněno, aplikace s privátními IP adresami fungují díky tomu, že Cloudflare daný rozsah IP adres proxuje napříč svou sítí. Tato povaha aplikace vyžaduje použití klienta zařízení, protože pokud uživatel není připojen ke Cloudflare (konkrétně pokud nemůže využít konektivitu Client-to-Tunnel), nedostane se k nelokálním adresám RFC 1918.

Definice aplikace je zde jednoduchá, protože Cloudflare automaticky doplní rozsah IP adres a stačí omezit detekovaný protokol na RDP. U aplikací s privátní IP adresou jsou pravidla trochu jiná. Všimnete si, že se zobrazují jako síťové zásady v nabídce Cloudflare Gateway, přestože je spravujete v Access. Některé možnosti, jako je kontrola MFA nebo externí vyhodnocení, se zde nezobrazují. Tyto atributy je ale možné ověřit ve chvíli, kdy uživatel aktivuje klienta na svém zařízení a ověří se vůči organizaci.

Jednou z dostupných možností je vynucení délky trvání relace klienta agenta zařízení. To znamená, že po určité době bude uživatel nucen se znovu ověřit. Tato funkce umožňuje uplatnit přístup Zero Trust i při ochraně soukromých IP aplikací. Zajišťuje, že i v případě, že dojde ke kompromitaci přihlašovacích údajů uživatele nebo je jeho zařízení ponecháno bez dozoru, je časové okno pro neoprávněný přístup omezené. Pravidelným vyžadováním opětovného ověření průběžně ověřujeme identitu a oprávnění uživatele, což odpovídá základnímu principu Zero Trust "nikdy nedůvěřuj, vždy ověřuj".

Díky kombinaci podrobného řízení přístupu a detailního protokolování aktivit nabízí Cloudflare komplexní bezpečnostní řešení pro ochranu a monitorování přístupu ke kritickým zdrojům v rámci metodiky Zero Trust.

Úspěšná implementace ZTNA vyžaduje víc než jen technickou konfiguraci: je třeba pečlivě zvážit konkrétní potřeby vaší organizace, pracovní postupy uživatelů a bezpečnostní požadavky. Díky flexibilitě Cloudflare můžete začít se základními zásadami zabezpečeného přístupu a postupně je rozvíjet podle toho, jak se mění potřeby vaší organizace a jak dozrávají bezpečnostní požadavky. Když se budete řídit zásadami a postupy popsanými v tomto průvodci, vytvoříte robustní úroveň zabezpečení, která vás chrání co nejpřesněji a nejtransparentněji.

Pokud se chcete dozvědět více o ZTNA, SASE nebo dalších aspektech platformy Cloudflare One, navštivte naši knihovna referenčních architektur nebo naši dokumentace pro vývojáře pro začátek.

Související zdroje

• Referenční architektura Cloudflare SASE
• Cloudflare SASE s Microsoftem
• Jak nasadit Cloudflare ZTNA