← Cloudflare One / cloudflare-one / access-controls / applications

Zvolte typ aplikace

Cloudflare Access stojí před vašimi aplikacemi a každý požadavek nejprve porovná s vašimi zásadami Access, než uživatele pustí dál. Podporuje několik typů aplikací, z nichž každý je určený pro jiný případ použití. Výběr závisí na tom, kde je vaše aplikace hostovaná, jak se k ní uživatelé připojují a jakou úroveň kontroly nad relacemi a autorizací potřebujete.

Většina týmů začíná se self-hosted aplikacemi a postupně přechází k aplikacím SaaS, cílům infrastruktury nebo jejich kombinaci.

Následující tabulka shrnuje klíčové rozdíly mezi jednotlivými typy aplikací. Podrobné pokyny k nastavení najdete v části věnované danému typu.

Self-hosted aplikace jsou nejuniverzálnějším typem aplikace a tvoří většinu nasazení Access. Self-hosted aplikace představuje libovolný prostředek, u kterého sami určujete směrování provozu: může jít o veřejný web na DNS Cloudflare, o jinou než webovou službu ve vaší privátní síti připojenou přes Cloudflare Tunnel, nebo o Worker běžící na Cloudflare.

Self-hosted aplikace využívají kompletní systém zásad Access, včetně správy relací, aplikačních tokenů, vynuceného opětovného ověření, kontrol stavu zařízení a skupin poskytovatele identity.

Pokud je vaše aplikace už na veřejném internetu s DNS spravovaným přes Cloudflare (nebo s částečnou konfigurací CNAME, kdy je vaše DNS hostované jinde, ale provoz proxíruje Cloudflare), můžete před ni umístit Access tak, že se shoduje s hostname aplikace. Cloudflare požadavek proxíruje, zobrazí přihlašovací stránku a provoz na váš origin přeposílá až poté, co uživatel projde vašimi zásadami Access.

Toto je nejběžnější výchozí bod: do zařízení uživatele není potřeba nic instalovat, ověření proběhne celé v prohlížeči.

Pokyny k nastavení viz Přidejte samostatně hostovanou veřejnou aplikaci.

Můžete také použít self-hosted aplikace k ochraně prostředků ve vaší privátní síti tím, že je zacílíte na konkrétní privátní IP adresy, hostname nebo rozsahy CIDR (bloky IP adres, například 10.0.0.0/8) s připojeným portem nebo rozsahem portů. Toto je hlavní způsob budování síťového přístupu Zero Trust na Cloudflare.

Aplikace privátní sítě vyžadují, aby uživatelé směrovali provoz přes Cloudflare, obvykle spuštěním Cloudflare One Client na svém zařízení. Zároveň musíte svou privátní síť připojit ke Cloudflare pomocí Cloudflare Tunnel nebo Cloudflare Mesh.

S aplikacemi privátní sítě definujete stejné typy zásad Access jako u veřejných aplikací, ale aplikujete je na privátní cíle. Díky tomu máte podrobnou kontrolu nad tím, kdo se s ohledem na identitu může k čemu ve vaší síti dostat, čímž nahrazujete široký přístup na úrovni VPN zásadami pro jednotlivé aplikace nebo služby. Zásady Access jsou opakovaně použitelné, takže stejnou zásadu můžete uplatnit napříč více aplikacemi.

Pokyny k nastavení viz Přidejte samostatně hostovanou soukromou aplikaci.

Self-hosted aplikace mohou také chránit Cloudflare Worker přímo podle názvu, nikoli podle hostname nebo IP adresy. Když jako cíl vyberete Worker, můžete pokrýt Worker včetně všech jeho preview deploymentů, nebo pokrýt pouze preview deploymenty.

Toto je nejbezpečnější a nejjednodušší způsob, jak předřadit ověřování před Worker. Místo konfigurace jednotlivých tras na Workeru a správy ověřování na úrovni trasy propojíte celý Worker (volitelně včetně jeho preview deploymentů) s aplikací Access. Každý požadavek na Worker na jakékoli trase pak nejdřív projde přes Access.

Pokyny k nastavení specifické pro Workers najdete v Cloudflare Access for Workers.

Self-hosted aplikace podporují klientskou cloudflared ověřování. Uživatelé mohou nainstalovat cloudflared na svém zařízení a spustí cloudflared access login <hostname> z příkazové řádky k ověření prostřednictvím vašich zásad Access bez nainstalovaného Cloudflare One Client. To se hodí pro relace SSH, volání API a další pracovní postupy z příkazové řádky, kde by přihlašování přes prohlížeč nebylo praktické.

Další informace najdete v tématu Ověření cloudflared.

Aplikace SaaS slouží pro nástroje třetích stran, které vaše organizace používá, ale sama nehostuje: jde o služby jako Salesforce, Atlassian, Slack nebo Workday. U aplikace SaaS nastavíte Cloudflare Access jako poskytovatele jednotného přihlašování (SSO) pro danou službu třetí strany pomocí SAML nebo OIDC, dvou nejběžnějších protokolů federace identity.

Když se uživatelé přihlásí do aplikace SaaS, jsou přesměrováni na Cloudflare. Cloudflare je k ověření přesměruje na vámi nakonfigurovaného poskytovatele identity a poté proti ověřenému uživateli vyhodnotí vaše zásady Access. Pokud uživatel projde oběma kontrolami, Cloudflare vydá aplikaci SaaS podepsané pověření (SAML assertion nebo token OIDC), které potvrzuje identitu uživatele.

SaaS aplikaci použijte, pokud chcete:

• Vynucujte jednotné zásady Access napříč nástroji třetích stran. Na externí nástroje SaaS uplatněte stejné požadavky na identitu, stav zařízení a polohu jako u interních aplikací.
• Agregace více poskytovatelů identity. Cloudflare umí federovat autentizaci napříč více poskytovateli identity (IdP), takže poskytovatele identity můžete měnit nebo přidávat, aniž byste museli jednotlivě překonfigurovávat každou aplikaci SaaS. U přímých integrací SSO to obvykle možné není.
• Použijte ovládací prvky specifické pro Cloudflare. Vynucujte požadavky, které váš poskytovatel SaaS nedokáže ověřit sám, například vyžadujte Cloudflare One Client nebo úspěšnou kontrolu stavu zařízení, než uživateli udělíte přístup k nástroji SaaS.

Aplikace SaaS vyžadují, aby nástroj třetí strany podporoval federaci SAML nebo OIDC. Ne všechny nástroje SaaS to nabízejí a některé omezují počet integrací SSO nebo funkce dostupné prostřednictvím federovaného ověřování. Podporu SSO si ověřte v dokumentaci svého dodavatele SaaS.

Pokyny k nastavení viz Aplikace SaaS.

Infrastructure aplikace poskytují řízení přístupu podle protokolu pro servery a infrastrukturní cíle, ať už jsou dostupné přes veřejný hostname, nebo přes privátní síť. Na rozdíl od self-hosted aplikací, které pouze vyhodnocují, zda se uživatel může dostat k cíli, infrastructure aplikace navíc řídí, co může uživatel dělat po připojení: pod jakými uživatelskými jmény se může ověřit, ke kterým portům má přístup a jaké příkazy může spouštět.

Infrastructure aplikace vyžadují Cloudflare One Client. Pro cíle ve vaší privátní síti musíte síť k Cloudflare navíc připojit přes Cloudflare Tunnel nebo Cloudflare Mesh.

Infrastrukturní aplikaci použijte, pokud potřebujete:

• Autorizace na úrovni protokolu. Definujte zásady, které konkrétním uživatelům udělí přístup ke konkrétním portům a uživatelským jménům na cílovém serveru.
• Protokolování příkazů. Všechny relace a příkazy SSH se zaznamenávají pro účely compliance a auditu. Protokoly můžete exportovat do úložiště nebo do SIEM pomocí Logpush.
• Krátkodobé certifikáty. Zbavte se dlouhodobě platných klíčů SSH tím, že uživatele budete ověřovat certifikáty s krátkou platností. Odstraníte tak riziko, že by odcizený nebo zapomenutý klíč umožnil trvalý přístup k vašim serverům.

Infrastructure aplikace podporují SSH. Stále však můžete používat self-hosted aplikace a zabezpečit přístup k serverům pomocí jiných protokolů (včetně SSH), infrastrukturní aplikace jsou však jediným způsobem, jak doplňkově řídit autorizaci uživatelů.

Pokyny k nastavení viz Přidejte infrastrukturní aplikaci.

Bookmarky nejsou zabezpečeny pomocí Access. Bookmark je odkaz na libovolnou adresu URL, kterou chcete zobrazit v App Launcher vedle vašich dalších aplikací. Zásady Access můžete přiřadit záložkám (bookmarks), ale tyto zásady určují pouze to, zda je dlaždice záložky viditelná v App Launcher; cílovou URL adresu nechrání.

Pomocí bookmarks poskytněte uživatelům jediný portál, kde najdou všechny nástroje, které používají, včetně externích aplikací, jež nejsou integrované s Cloudflare.

Pokyny k nastavení viz Přidání bookmarků.

Starší typ aplikace privátní sítě vytváří zásady Gateway Network, které řídí přístup k privátní IP adrese. Když přidáte starší aplikaci privátní sítě, Cloudflare vygeneruje dvě pravidla Gateway: jedno pravidlo Allow a jedno pravidlo Block. Je to proto, že zásady Gateway Network standardně provoz neodepírají, na rozdíl od zásad Access, které vyžadují explicitní pravidlo Allow, než se uživatel může dostat k chráněné aplikaci.

Starší aplikace privátní sítě nepodporují správu na úrovni relace, tokeny aplikací ani celou sadu funkcí dostupných v zásadách Access. Tento typ aplikace je pro nové zákazníky zastaralý a zůstává dostupný pro stávající zákazníky.

Pokud v současnosti používáte starší aplikace pro privátní síť, důrazně doporučujeme přejít na self-hosted aplikace privátní sítě pro komplexnější řízení zásad a správu relací.

Další informace najdete v tématu Aplikace privátní sítě (starší verze).