API Gateway a řízení přístupu: bezpečnost a správa rozhraní API

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

API Gateway je ústředním bodem pro publikaci, zabezpečení, škálování a monitoring rozhraní API. V rámci API managementu funguje 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 a náklady.

Role API Gateway v architektuře

Terminace protokolů: Převod HTTP/2 a gRPC na HTTP/1.1, TLS terminace, podpora mTLS.
Bezpečnostní prosazování: Validace tokenů (JWT, opaque), kontrola scopes, rate limiting, WAF pravidla, ochrana proti útokům.
Směrování a agregace: Směrování na cílové služby, routing založený na cestě (path-based) a hlavičkách (header-based), 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 kontextu API se často vyjadřuje prostřednictvím 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 hodnotí 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í rozhodovací logiku od aplikačního 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 tokenů,
ověřuje audience, issuer a pož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 přes TLS certifikáty (mTLS) představuje robustní řešení 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átů (např. SPIFFE ID) lze mapovat na přístupové politiky.

API klíče versus tokeny

API klíče jsou vhodné pro jednoduché, nízkorizikové integrace a identifikaci klienta, ne 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 politiku jako kód.
Vyberte identitní toky (Client Credentials, Authorization Code + PKCE, Device Code) podle typu klienta.
Vynucujte síťové hranice (WAF, mTLS, privátní ingress) s 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 uplatňuje limity jako 100 req/min na klíč/tenant, burst limity a algoritmy leaky bucket nebo token bucket. Kvóty (např. počet volání za den) podporují monetizaci a spravedlivé využití. Ochrana proti DoS zahrnuje mechanismy jako IP reputation, bot detection a circuit breakers.

Validace požadavků a schémat

Validace proti OpenAPI/JSON Schema zabraňuje průniku nečekaných polí, předchází mass assignment a snižuje zátěž backendů. Gateway může provádět transformace (např. mapování v1 na 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 mitigaci DDoS útoků. API Gateway aplikuje autentizaci/autorizaci a business limity. Service mesh (sidecar proxy) vynucuje mTLS a principy zero trust mezi mikroslužbami. Kombinace těchto vrstev 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, verzování 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 (např. 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ů, avšak trvalé „shimování“ zvyšuje technický dluh.

Testování a CI/CD politik

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

lint a validaci OpenAPI,
kontraktační testy (producer/consumer),
bezpečnostní testy (fuzzing, negative tests),
výkonové testy (latence P50/P95/P99, propustnost),
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č bylo zamítnuto či 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 na základě metrik (CPU, RPS, latence). U veřejných API využijte cache (CDN, response caching) s řízením platnosti (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 cíle RTO/RPO 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 smluvní SLA nájemců.

Soukromí, compliance a ochrana dat

V 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ů údajů. Gateway může provádět data redaction v logech 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 útoky: Použití nonce, iat, exp, PoP tokenů (proof-of-possession).
Exfiltrace dat: Limity odpovědí, filtrace 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í řízeno scope resource:read.
POST /v1/resources – zápis řízen scope resource:write a kontrolou 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žívejte mTLS a short-lived tokeny vázané na identitu služby. Delegace (např. token exchange) umožňuje 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 bezpečnostní 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), produktové 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 dat a spotřebitele.
Návrh cílového stavu: Zvolte deployment pattern, identitní toky, model autorizace a 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, disaster recovery, multitenance, monetizace, smluvní SLA.
Průběžné zlepšování: Threat modeling, penetrační testy, revize politik, post-mortem analýzy.

Příklad politik (konceptuálně)

Uvažujme kombinaci pravidel:

Autentizace: vyžadovat Authorization