API Gateway a řízení přístupu

API Gateway a řízení přístupu: proč na tom záleží

API Gateway je centrální bod pro publikaci, ochranu, škálování a monitorování API rozhraní. V kontextu API managementu slouží jako brána mezi klienty (mobilní aplikace, weby, partneři) a backendovými službami (mikroslužby, monolity, datové zdroje). Kvalitně navržená gateway sjednocuje autentizaci, autorizaci, řízení provozu, observabilitu a governance – čímž výrazně snižuje rizika i náklady.

Role API Gateway v architektuře

Terminace protokolů: Převod HTTP/2 & gRPC na HTTP/1.1, TLS terminace, podpora mTLS.
Bezpečnostní enforcement: Validace tokenů (JWT, opaque), kontrola scopes, rate limiting, WAF pravidla, ochrana proti útokům.
Směrování a agregace: Routing na cílové služby, path-based a header-based routing, transformace požadavků a odpovědí.
Observabilita: Centralizované logování, metriky (SLI), distribuované trasování.
Governance: Publikace katalogu API, správa verzí, politik, monetizace a kvót.

Základní pojmy: identita, autentizace, autorizace

Identita představuje subjekt (uživatel, služba, zařízení). Autentizace ověřuje, že subjekt je tím, za koho se vydává (např. OAuth 2.1/OIDC, mTLS). Autorizace rozhoduje, zda je akce povolena (RBAC/ABAC/PBAC) a v API kontextu se často vyjadřuje přes scopes a claims v tokenech.

Modely autorizace: RBAC, ABAC a PBAC

RBAC (Role-Based): Rozhodování na základě rolí (např. role=admin má přístup k /v1/users/*). Jednoduché, ale hrubozrnné.
ABAC (Attribute-Based): Pravidla vyhodnocují atributy subjektu, prostředku a kontextu (např. department=Sales, region=EU, risk_score<50).
PBAC (Policy-Based): Politiky definované jako deklarativní pravidla (např. pomocí OPA/Rego) oddělují logiku rozhodování od kódu.

Autentizační standardy: OAuth 2.1 a OpenID Connect

Pro přístup třetích stran je de facto standardem OAuth v kombinaci s OpenID Connect pro identifikaci uživatele. API Gateway obvykle:

přijímá bearer tokeny (většinou JWT),
validuje podpis a expiraci,
ověřuje audience, issuer a vyžadované scopes,
provádí introspection u opaque tokenů,
aplikuje token exchange nebo delegation pro volání downstream služeb.

mTLS a identita služeb

Vzájemná autentizace pomocí TLS certifikátů (mTLS) je robustní metoda pro komunikaci stroj–stroj. API Gateway může vynucovat mTLS na edge i mezi službami (north–south i east–west), přičemž certifikáty spravuje interní PKI. Claims z certifikátu (např. SPIFFE ID) lze mapovat na politiky přístupu.

API klíče versus tokeny

API klíče jsou vhodné pro jednoduché, nízkorizikové integrace a identifikaci klienta, nikoli však pro jemnozrnnou autorizaci. Tokeny (JWT/OAuth) poskytují lepší auditovatelnost, časovou omezenost a kontext (scopes, claims). Bezpečnou praxí je rotace a princip least privilege.

Strategie řízení přístupu v praxi

Definujte klasifikaci API (interní, partnerské, veřejné) a citlivost dat.
Zvolte model autorizace (RBAC/ABAC/PBAC) pro každé API a definujte politiky jako kód.
Vyberte identitní toky (Client Credentials, Auth Code + PKCE, Device Code) dle typu klienta.
Vynucujte síťové hranice (WAF, mTLS, privátní ingress) a principy zero trust.
Implementujte rate limiting a kvóty na úrovni consumer app i tenant.
Monitorujte a auditujte požadavky, rozhodnutí politik a anomálie.

Rate limiting, throttling, kvóty a ochrana proti DoS

Gateway vynucuje limity jako 100 req/min na klíč/tenant, burst limity a algoritmy leaky bucket/token bucket. Kvóty (např. počet volání za den) podporují monetizaci a férové využití. Ochrana proti DoS zahrnuje IP reputation, bot detection a circuit breakers.

Validace požadavků a schémat

Validace vůči OpenAPI/JSON Schema zabraňuje průniku neočekávaných polí, předchází mass assignment a snižuje zátěž backendů. Gateway může provádět transformace (např. mapování v1 → v2), normalizaci hlaviček a sanitizaci dat.

Jemnozrnná autorizace pomocí scopes a claims

Scopes jako payments:read a payments:write umožňují oddělit čtení a zápis. Claims (např. tenant_id, role, consent=granted) rozšiřují kontext, který gateway zohledňuje v politikách, například omezují přístup na zdroje konkrétního nájemce.

Vícevrstvé řízení přístupu: edge, gateway, service mesh

Edge vrstva řeší hrubozrnnou filtraci a zmírnění DDoS útoků. API Gateway aplikuje autentizaci/autorizaci a business limity. Service mesh (sidecar proxy) vynucuje mTLS a principy zero trust mezi mikroslužbami. Kombinace poskytuje obranu do hloubky.

Architektonické vzory nasazení

Centralizovaná gateway: Jedno místo řízení, snadná governance, riziko bottlenecku.
Více gatewayí (per domain): Lepší izolace a autonomnost týmů, vyšší provozní složitost.
Hybridní/edge + mesh ingress: Edge gateway pro externí klienty, mesh ingress pro interní provoz.

Životní cyklus API a governance

API procházejí fázemi návrhu, publikace, provozu, verze a deprecace. Gateway a vývojářský portál zajišťují katalog, registraci aplikací, správu klíčů, schvalování a notifikace o změnách. Politiky verzí (např. /v1, /v2) a SLA musí být transparentní.

Verzování, kompatibilita a migrace

Preferujte kompatibilní změny (přidávání polí). Pro breaking změny publikujte novou major verzi a naplánujte deprecaci s milníky. Gateway může pomocí transformací dočasně usnadnit migraci klientů, ale trvalé „shimování“ zvyšuje technický dluh.

Testování a CI/CD politik

Politiky a konfigurace gatewaye verzujte jako kód. V CI/CD pipeline automatizujte:

lint a validaci OpenAPI,
kontraktační testy (producer/consumer),
bezpečnostní testy (fuzzing, negativní testy),
výkonnostní testy (latence P50/P95/P99, průchodnost),
canary a postupné rollouty s měřením dopadů.

Observabilita, audit a forenzní analýza

Gateway generuje auditní záznamy pro každé rozhodnutí (kdo/kdy/co/proč zamítnuto/povoleno), metry (chybovost, latence, saturace) a trace (např. W3C Trace Context). Uchovávejte logy bezpečně, oddělte osobní údaje a zajistěte tamper-evident úložiště.

Výkon, škálování a cache

Gateway musí být horizontálně škálovatelná, s podporou autoscalingu podle metrik (CPU, RPS, latence). U veřejných API využijte cache (CDN, response caching) s řízením stárnutí (Cache-Control), aby se snížila zátěž backendu a latence pro klienty.

Vysoká dostupnost a disaster recovery

Nasazujte více replik v různých zónách a regionech, s health checks, circuit breakers a failover routováním. Udržujte RTO/RPO cíle a pravidelně testujte DR plány, včetně obnovy konfigurace gatewaye a klíčového materiálu.

Multitenance a monetizace

Více-nájemcová prostředí vyžadují separaci klíčů, kvót a limitů, izolaci dat a vyúčtování. Gateway zprostředkuje plány předplatného, reporty spotřeby a eventy pro fakturaci. Politiky musí zohledňovat tenant_id a nájemcovské smluvní SLA.

Soukromí, compliance a ochrana dat

Pro prostředí s osobními údaji dodržujte GDPR a další regulace: data minimization, purpose limitation, maskování a tokenizace citlivých polí, řízení souhlasů, data residency a práva subjektů. Gateway může provádět data redaction v logách a vynucovat geografická omezení.

Bezpečnostní hrozby a mitigace

Injection a deserializace: Validace schémat, WAF, whitelistování content-type.
Broken Auth: Krátká expirace tokenů, rotace klíčů, refresh flow s detekcí anomálií.
Replay: nonce, iat, exp, PoP tokeny (proof-of-possession).
Exfiltrace dat: Limity odpovědí, filtrování na úrovni polí, DLP skeny.
Supply chain: Podepisování konfigurací, princip two-person rule, schvalování změn.

API design a dopad na řízení přístupu

Konzistentní návrh cest, metod a chybových kódů usnadňuje definici politik. Příklady:

GET /v1/resources/{id} – čtení řídit pomocí scope resource:read.
POST /v1/resources – zápis řídit scope resource:write a kontrolu citlivých polí.
Idempotentní operace usnadňují rate limiting a retry mechanismy.

Service-to-service autorizace a delegace

Pro volání mezi službami použijte mTLS a short-lived tokeny vázané na identitu služby. Delegace (např. token exchange) umožní backendu jednat jménem uživatele s omezenými právy (downscoping).

Zero Trust a kontextové rozhodování

Zero Trust předpokládá nedůvěru k síti i identitám. Gateway proto zohledňuje kontext (geolokace, rizikové skóre, typ klienta, stav zařízení) a dynamicky zvyšuje požadavky (např. vyžádá silnější autentizaci nebo zablokuje anomální transakci).

Provozní model: týmy, odpovědnosti a rozhraní

Rozdělte odpovědnosti mezi API Platform (správa gatewaye a politik), Product týmy (návrh API, SLO) a Security (politiky, hrozby). Zaveďte guardrails: šablony služeb, předpřipravené politiky, self-service portál a školicí materiály.

Metodika zavedení API Gateway a přístupových politik

Discovery a klasifikace: Inventarizujte existující API, citlivost a konzumenty.
Návrh cílového stavu: Zvolte deployment pattern, identitní toky, model autorizace, observabilitu.
Pilot: Vyberte reprezentativní API, implementujte politiky, nastavte metriky a alerty.
Industrializace: Policy-as-code, CI/CD, katalog, samoobsluha pro vývojáře.
Škálování: Multiregion, DR, multitenant, monetizace, smluvní SLA.
Průběžné zlepšování: Threat modeling, pen testy, revize politik, post-mortems.

Příklad politik (konceptuálně)

Uvažujme kombinaci pravidel:

Autentizace: vyžadovat Authorization: Bearer <JWT>, shoda iss a aud, platnost exp po aktuálním čase.
Aut