← Cloudflare API Shield / api-shield

Začínáme s API Shield

API Shield chrání vaše API tím, že obj evuje koncové body, ověřuje schémata požadavků a odhaluje vzorce zneužití. Tento návod vás provede počátečním nastavením od konfigurace identifikátorů relace až po zapnutí pokročilé ochrany.

Ačkoli to není nezbytně nutné, doporučujeme nakonfigurovat identifikátory relace hned na začátku práce s API Shield. Když Cloudflare kontroluje provoz vašeho API na úrovni jednotlivých relací, můžeme nabídnout více nástrojů pro viditelnost, správu a kontrolu.

Pokud si nejste jisti, jaké identifikátory relace vaše API používá, poraďte se se svým vývojářským týmem.

Identifikátory relace by měly jednoznačně identifikovat klienty API. Běžným identifikátorem relace pro provoz API je Authorization hlavička. Když JSON Web Token (JWT) používá API k ověřování klienta, jeho hodnota se může postupem času měnit. Můžete použít hodnotu claimu uvnitř JWT, například sub nebo email jako ID relace k jednoznačné identifikaci relace v průběhu času.

Pokud vaše API používá Authorization hlavičku u více než 1 % úspěšných požadavků na vaši zónu, Cloudflare ji automaticky nastaví jako identifikátor relace API Shield.

Ke konfiguraci identifikátorů relace nebo cookies jako formy identifikátorů potřebujete specifická oprávnění, například předplatné Enterprise, a to pro funkce jako API Discovery, Mitigace sekvencí nebo doporučení pro rate limiting, a výsledky zobrazíte v Sequence Analytics a Authentication Posture.

Jakmile nastavíte identifikátory relací a necháte Cloudflare nějakou dobu poznávat vzorce vašeho provozu, můžete si zobrazit doporučení pro omezení frekvence požadavků za koncový bod i za relaci a vytvořením nových pravidel tato omezení také vynutit. Identifikátory relací vám navíc umožní zobrazit výsledky API Discovery ze zjišťování založeného na ID relace a vzorce provozu relací v Sequence Analytics.

Application Profiles poskytuje jeden Schema Profile se dvěma zdroji. Schema Learning odvozuje profil z provozu, zatímco Schema Validation používá nahraný Schéma OpenAPI.

Oba zdroje poskytují nepřetržitá detekce po zpřístupnění jejich profilu. Zmírnění vyžaduje samostatné WAF Custom Rule.

Pokud spravujete schéma OpenAPI, postupujte podle Postup nahrání pro Schema Validation. API Shield zůstává referenčním řešením pro kompatibilitu s OpenAPI, správu schémat a automatizaci.

API Shield spolupracuje s Cloudflare WAF Sensitive Data Detection ruleset k identifikaci Koncové body API, které ve svých odpovědích HTTP vracejí citlivá data, například čísla sociálního zabezpečení nebo platebních karet. Zkontrolujte tyto koncové body a ověřte, že se citlivá data vracejí pouze tam, kde se to očekává.

Endpointy vracející citlivá data poznáte podle ikony vedle cesty v daném řádku. Rozbalením endpointu zobrazíte podrobnosti o tom, která pravidla se spustila, a další informace najdete v událostech v Firewall Events.

Web Assets průběžně objevuje operace na základě provozu. Operace představuje endpoint definovaný metodou HTTP, vzorem hostitele a vzorem cesty.

Operace také můžete přidat ručně v Webová aktiva > Operace. Discovery a manuální vytváření pouze přidávají položky do inventáře.

Chcete-li spustit Schema Learning, vyberte Naučit profil z rozbalovací nabídky operace. Naučené schéma zkontrolujte přes Zobrazit podrobnosti > Přehled zabezpečení.

Úplný pracovní postup a prahové hodnoty provozu najdete v Začínáme s Application Profiles.

Rate limiting rules vám umožňují definovat limity četnosti požadavků pro požadavky odpovídající danému výrazu a zvolit akci, která se provede po dosažení těchto limitů.

API Shield generuje doporučení pro omezení frekvence požadavků pro každý koncový bod na základě vašich identifikátorů relace. Tato doporučení platí vždy pro konkrétní koncový bod a relaci, nikoli pro celý web nebo na základě IP adresy.

Limity počtu požadavků na relaci sledují provoz jednotlivých návštěvníků během jejich relace ke konkrétnímu koncovému bodu. Díky tomu se snižuje počet falešně pozitivních výsledků u široce nastavených pravidel, aniž by se tím omezila účinnost proti zneužívajícímu provozu.

Naučená schémata obsahují hostname, všechny endpointy podle hostitele, metody a cesty a zjištěné proměnné v cestě (například /users/{id}). Mohou také obsahovat zjištěné parametry dotazu a jejich formát. Volitelně můžete zahrnout i doporučené prahové hodnoty pro omezení frekvence.

Naučená schémata můžete exportovat v Cloudflare dashboard nebo prostřednictvím API.

Export vytváří OpenAPI v3.0.0 souboru. Chcete-li použít pevný profil, nahrajte tento soubor přes Schema Validation.

Sequence Analytics identifikuje běžné vzorce API požadavků, například když si uživatel zkontroluje zůstatek účtu před zahájením převodu prostředků.

Sekvence jsou seřazeny podle skóre priority, které měří, jak pravděpodobné je, že se konkrétní požadavky API vyskytnou společně v konzistentním pořadí. Sekvence s vysokým skóre obsahují požadavky API, kterým s vysokou pravděpodobností předcházejí ostatní operace v dané sekvenci.

Sequence mitigation vám umožňuje vynucovat vzorce požadavků u ověřených klientů komunikujících s vaším API. Pomocí Sequence Analytics zjistíte, jaké sekvence vaši klienti API dodržují, a poté na endpointy v sekvencích s vysokým skóre uplatněte ochrany API Shield (rate limiting, Schema validation, JWT validation a mTLS). Očekávané pořadí endpointů si ověřte s vývojářským týmem.

Další informace najdete v tématu Automatická detekce zneužití API pomocí analýzy sekvencí ↗ blogovém příspěvku.

Ověřování JSON Web Tokens (JWT) ověřuje, že tokeny odeslané klienty nebyly pozměněny a nevypršela jejich platnost. Ověřování JWT nakonfigurujte pomocí Cloudflare dashboardu nebo API.

Pokud váš origin používá GraphQL, zvažte nastavení limitů na velikost a hloubku GraphQL dotazů.

Ochrana před škodlivými GraphQL dotazy skenuje provoz GraphQL a hledá dotazy s nadměrným zanořením nebo velikostí, které by mohly přetížit váš origin server a způsobit odepření služby. Můžete vytvořit pravidla, která nastaví maximální hloubku a velikost dotazu, a zablokovat tak tyto dotazy dříve, než dosáhnou vašeho origin serveru.

Další informace naleznete v blogový příspěvek ↗.

Pokud provozujete API, které vyžaduje nebo by mohlo těžit z další vrstvy ochrany, zvažte použití Mutual TLS (mTLS).

Ověřování Mutual TLS (mTLS) vyžaduje, aby si klient i server navzájem ověřili identitu pomocí certifikátů. Ve standardním TLS prokazuje svou identitu pouze server. mTLS přidává ověření klienta, což se hodí pro zařízení, jako je IoT hardware, která se neautentizují přes poskytovatele identity.