← Cloudflare One / cloudflare-one / access-controls

Zásady

Cloudflare Access určuje, kdo se dostane k vaší aplikaci, a to na základě nakonfigurovaných zásad Access.

Každá zásada Access má čtyři stavební bloky:

• Akce: Co se stane, když uživatel odpovídá zásadě (Allow, Block, Bypass nebo Service Auth)
• Typy pravidel: Jak se kritéria kombinují (Include, Require nebo Exclude)
• Selektory: Kontrolované atributy (například doména e-mailu, země nebo stav zařízení)
• Hodnoty: Konkrétní hodnoty, se kterými se má porovnávat (například @example.com)

Akce umožňují udělit nebo zamítnout oprávnění konkrétnímu uživateli nebo skupině uživatelů. Ke každé zásadě lze nastavit jen jednu akci.

Akce Allow v Cloudflare Access umožňuje uživatelům splňujícím určitá kritéria dosáhnout aplikace za Access.

Následující tabulka ukazuje příklad zásady Cloudflare Access typu Allow, která umožňuje přístup libovolnému uživateli s @example.com e-mailová adresa, ověřená vůči IdP, měla přístup k aplikaci:

Do stejné akce zásady můžete přidat pravidlo Require, které vynutí další kontroly. Pokud zásada obsahuje pravidlo Exclude, uživatelům splňujícím danou definici je nakonec znemožněn přístup k aplikaci.

Následující tabulka například zobrazuje zásadu Allow s pravidly Require a Exclude. Tato konfigurace umožňuje libovolnému uživateli z Portugalska s @team.com e-mailová adresa, ověřená vůči IdP, měla přístup k aplikaci, kromě user-1 a user-2:

Akce Block v Cloudflare Access brání uživatelům splňujícím určitá kritéria v přístupu k aplikaci. Následující tabulka například zobrazuje zásadu Block, která blokuje požadavky z ruských zdrojových IP adres, jež nejsou na vašem seznam schválených IP adres.

Zásady blokování se nejlépe používají v kombinaci s Zásady povolení jako způsob, jak vytvořit výjimky v těchto zásadách Allow. Protože Access ve výchozím nastavení vše zamítá, uživatelům, kteří neodpovídají zásadě Block, bude přístup i nadále odepřen, pokud výslovně neodpovídají zásadě Allow.

Akce Bypass v Cloudflare Access deaktivuje vynucování Access pro konkrétní provoz.

Akce Bypass deaktivuje veškeré vynucování Access u provozu splňujícího kritéria definovaná v pravidle. Bypass se obvykle používá u aplikací, které vyžadují, aby konkrétní endpointy zůstaly veřejně přístupné.

Některé aplikace mají například endpoint pod /admin trasu, která musí být veřejně směrovatelná. V takové situaci můžete pro doménu vytvořit aplikaci Access test.example.com/admin/<your-url> a přidejte zásadu Bypass uvedenou v následující tabulce:

V rámci zavádění bezpečnostního modelu Zero Trust společnost Cloudflare nedoporučuje používat Bypass k udělení přímého trvalého přístupu k vašim interním aplikacím. Chcete-li zaměstnancům připojeným k síti zajistit plynulý a bezpečný přístup, použijte Cloudflare Tunnel k připojit vaši soukromou síť a nechte uživatele připojovat se prostřednictvím Cloudflare One Client.

Zásady Bypass, které obsahují kontrola stavu zařízení pravidla nebudou fungovat, pokud:

• Zaraz je povoleno pro zónu chráněnou službou Access
• A Worker zachytí požadavek

Chcete-li obejít tato omezení a vynechat kontrolu Access, doporučujeme změnit akci zásady na Service Auth.

Pravidla Service Auth v Cloudflare Access vynucují ověřovací postupy, které nevyžadují přihlášení k poskytovateli identity IdP, jako jsou service tokeny a vzájemné TLS.

Následující tabulka ukazuje příklad konfigurace zásady Cloudflare Access Service Auth:

Typy pravidel fungují jako logické operátory a určují, jak se kombinují vaše kritéria při vyhodnocování uživatele. Každá zásada Access musí obsahovat alespoň jedno pravidlo Include, které vymezuje počáteční okruh oprávněných uživatelů s přístupem k aplikaci. Rozsah pak můžete zúžit přidáním pravidel Exclude a Require.

Pravidlo Include v Cloudflare Access se podobá logickému operátoru OR. Pokud je zadáno více pravidel Include, stačí, aby uživatelé splnili jen jedno z kritérií.

Pravidlo Exclude v Cloudflare Access funguje jako logický operátor NOT. Uživatel, který splní jakékoli kritérium vyloučení, nezíská přístup k aplikaci.

Pravidlo Require v Cloudflare Access funguje jako logický operátor AND. Aby uživatel získal přístup, musí splnit všechna zadaná pravidla Require.

Hodnoty přidané do pravidla Require se ve výchozím nastavení spojují operátorem AND. Řekněme například, že chcete udělit přístup k aplikaci zaměstnancům na plný úvazek i kontraktorům, a to jen těm, kteří se nacházejí v konkrétních zemích (řekněme v Portugalsku a Spojených státech). Pokud nastavíte pravidlo s touto konfigurací:

Tato zásada vyžaduje, aby se uživatel nacházel současně ve Spojených státech AND Portugalsku a měl e-mail končící na obě @cloudflare.com AND @contractors.com. K aplikaci proto nebude mít přístup nikdo.

Řešení: Použijte skupina pravidel převést logiku AND na logiku OR v rámci pravidla Require.

1. Vytvořte skupinu pravidel s názvem Country requirements která zahrnuje uživatele v Portugalsku OR ve Spojených státech:

   Typ pravidla	Selektor	Hodnota
   Include	Země	United States, Portugal

2. Vytvořte zásadu, která vyžaduje skupinu pravidel a zároveň zahrnuje uživatele s e-maily končícími na @cloudflare.com NEBO @contractors.com:

   Akce	Typ pravidla	Selektor	Hodnota
   Allow	Require	Skupina pravidel	Country requirements
   	Include	E-maily končící na	@cloudflare.com, @contractors.com

Když do zásady Cloudflare Access přidáte pravidlo, budete vyzváni k zadání kritérií neboli atributů, které mají uživatelé splňovat. Tyto atributy jsou dostupné pro všechny typy aplikací Access, včetně SaaS, self-hosted, a jiný než HTTP aplikace.

Atributy bez identity jsou průběžně dotazovány, což znamená, že jsou vyhodnocovány při každém novém požadavku HTTP na změny během relace uživatele. Pokud jste nakonfigurovali Zajišťování SCIM, můžete přimět uživatele, aby prostřednictvím Access znovu potvrdil všechny atributy, kdykoli uživatele v IdP odvoláte nebo aktualizujete jeho členství ve skupině IdP.

¹ U aplikací SaaS může Access vynucovat zásady pouze při počátečním přihlášení a při obnovení relace SaaS. Jakmile se uživatel v aplikaci SaaS ověří, správa relace už spadá výhradně pod danou aplikaci SaaS.

Nastavení kontextu připojení umožňují řídit způsob, jakým uživatelé pracují s aplikací po udělení přístupu. Zatímco selektory určují, kdo se může k aplikaci připojit, nastavení kontextu připojení určují, jaké akce mohou uživatelé během relace provádět. Dostupná nastavení kontextu připojení závisí na typu aplikace.

Kontext připojení se nastavuje pro jednotlivé zásady, takže různým skupinám uživatelů můžete přidělit různá oprávnění. Zaměstnancům na plný úvazek tak můžete například povolit kopírování dat ze vzdálené relace RDP, zatímco externí dodavatele omezíte pouze na čtení.

Zásady Cloudflare Access se vyhodnocují podle typu akce a pořadí, které nastavíte. Nejprve se odshora dolů, v pořadí zobrazeném v rozhraní, vyhodnocují zásady Bypass a Service Auth. Poté se stejným způsobem odshora dolů vyhodnocují zásady Block a Allow, opět podle jejich pořadí.

Pokud máte zásady uspořádané například takto:

• Povolit A
• Blok B
• Service Auth C
• Obejít D
• Povolit E

Zásady se budou vyhodnocovat v tomto pořadí: Service Auth C > Bypass D > Allow A > Block B > Allow E. Jakmile uživatel odpovídá zásadě Povolit nebo Blokovat, vyhodnocování se zastaví a žádná další zásada už rozhodnutí nemůže přepsat.

Pokud do zásady Allow přidáte některé z následujících pravidel, k vaší aplikaci bude mít přístup kdokoli.

Následující tabulka ukazuje zásadu Cloudflare Access, která zahrnuje úplně všechny:

Následující tabulka ukazuje zásadu Cloudflare Access, která zahrnuje všechny uživatele s platnými metodami přihlášení e-mailem:

API a Terraform poskytují programové způsoby správy zásad a konfigurací Access.