Bezpečnostní standardy komunikace API: implementace OAuth, JWT a SSL/TLS

API management
Natália Šimková
Bezpečnostní standardy pro API komunikaci: Implementace OAuth, JWT a SSL/TLS

Proč řešit bezpečnostní standardy pro komunikaci API

Rozhraní API jsou páteří moderních digitálních ekosystémů. Slouží ke komunikaci mezi mikroslužbami, mobilními aplikacemi, partnery i zařízeními IoT. S rostoucím vystavením internetu se však API stávají primárním cílem útoků. Standardizovaný přístup k autentizaci, autorizaci, šifrování, protokolování a řízení rizik je proto klíčový. Tento článek shrnuje osvědčené bezpečnostní standardy a doporučení v oblasti správy API, včetně vazby na normy, referenční architektury a praktické politiky, které lze implementovat v API gateway i aplikační vrstvě.

Model hrozeb a bezpečnostní cíle

  • Důvěrnost: Zabránit úniku dat při přenosu i v klidu (TLS 1.3, šifrování payloadu, tokenů a tajných klíčů).
  • Integrita: Detekovat manipulaci s požadavky a odpověďmi a bránit se jí (digitální podpisy, JWS, kontrola hashů).
  • Dostupnost: Udržet službu v chodu i při vysokém zatížení (omezení rychlosti, WAF, ochrana proti DDoS, circuit breaker).
  • Autentizace a autorizace: Jednoznačně ověřit volajícího a vynucovat minimální oprávnění (OAuth 2.1, OIDC, zásady ABAC/RBAC).
  • Audit a dohled: Zajistit prokazatelnost a sledovatelnost a včasnou detekci incidentů (bezpečné protokolování, SIEM, detekce anomálií).

Transportní bezpečnost: TLS 1.3, HSTS a moderní kryptografie

  • TLS 1.3 všude: Vynucujte moderní šifry a perfect forward secrecy, využijte zkrácený handshake a zakažte zastaralé verze (TLS 1.0/1.1/1.2 povolujte jen výjimečně).
  • HSTS: Přidejte hlavičku Strict-Transport-Security (vhodné pro domény obsluhující webové klienty) a vynucujte HTTPS.
  • Bez slabých šifer: Zakažte RC4, 3DES a statické DH; upřednostňujte ECDHE a AEAD (např. AES-GCM, ChaCha20-Poly1305).
  • OCSP stapling a certifikáty: Používejte certifikáty s krátkou platností a automatizovaným obnovováním (ACME), rotujte privátní klíče a key pinning využívejte pouze s opatrností.

Vzájemné ověřování koncových bodů: mTLS a identita služeb

Pro komunikaci mezi službami (mikroslužby, service mesh) používejte mTLS pro oboustranné ověřování. Správu identit služeb standardizujte (SPIFFE ID) a automatizujte vydávání certifikátů (SPIRE, mesh CA). Vynucujte krátkou platnost certifikátů a jejich pravidelnou rotaci.

Autentizace uživatelů a klientů: OAuth 2.1 a OpenID Connect

  • OAuth 2.1: Upřednostňujte tok Authorization Code s PKCE pro veřejné klienty (SPA, mobilní aplikace). Nepoužívejte implicitní tok.
  • OpenID Connect: Pro federovanou identitu a jednotné přihlašování využijte OIDC (ID tokeny, dokument discovery, endpoint JWKS).
  • DPoP / tokeny vázané na mTLS: Vázání tokenu pomocí Proof-of-Possession na klíč klienta zabrání zneužití odcizeného tokenu bearer.
  • PAR, JAR a JARM: Pushed Authorization Requests a podepsané či šifrované žádosti a odpovědi snižují riziko manipulace a útoků typu mix-up.
  • Profily FAPI: Ve finančním sektoru využijte FAPI (Financial-grade API) pro zvýšené požadavky na bezpečnost a interoperabilitu.

Tokeny a standardy: JWT, JWS, JWE a správa klíčů

  • JWT: Používejte minimalistické, krátkodobé tokeny (exp 5–15 min) s claimy iss, sub, aud, iat, jti. Omezte jejich velikost a množství citlivých údajů.
  • JWS: Digitálně podepisujte tokeny pomocí ES256 (nebo PS256), označte klíč pomocí kid a veřejné klíče zveřejněte na adrese /.well-known/jwks.json.
  • JWE: Šifrujte obsah, pokud token nebo payload obsahuje citlivá data. U API upřednostňujte podepisování; šifrujte pouze tehdy, je-li to nezbytné.
  • Rotace klíčů: Zajistěte pravidelnou, automatizovanou rotaci, správné verzování klíčů, odvolání kompromitovaných klíčů a zásady key escrow.

API klíče vs. OAuth: kdy zvolit kterou možnost

  • API klíče: Vhodné pro integrace mezi servery s nízkým rizikem a omezeným rozsahem. Vždy je kombinujte s omezením IP adres, časovou platností, kvótami a možností okamžitého odvolání.
  • OAuth/OIDC: Upřednostňovaná volba pro uživatelskou identitu, delegovaný přístup, partnery a třetí strany. Umožňuje používat scopes, souhlas uživatele a granulární oprávnění.

Autorizace: princip minimálních oprávnění a zásady ABAC/RBAC

  • Scopes a claims: Při rozhodování pracujte s scopes a kontextovými claims (role, tenant, důvěryhodnost zařízení).
  • OPA/OPAL: Centralizujte zásady v Open Policy Agent (Rego), dynamicky je distribuujte a vyhodnocujte v gateway i službách.
  • Zabezpečení na úrovni řádků a polí: Vynucujte zabezpečení na úrovni zdrojů i atributů a podle požadavků právních předpisů data anonymizujte a maskujte (GDPR).

Validace a integrita požadavků: schémata, idempotence a podpisy

  • Schémata: Validujte JSON pomocí JSON Schema (nebo Protobuf pro gRPC). Odmítejte nadbytečná pole a neznámé typy.
  • Idempotence: Pro operace zápisu zavádějte idempotency keys a zásady opakování (retry) s backoff.
  • Podpisy webhooků: Při příjmu webhooků ověřujte podpisy HMAC/JWS, replay window a jedinečné event-id.

Ochrana proti zneužití: omezení rychlosti, kvóty a WAF

  • Omezení rychlosti: Používejte zásady token bucket/leaky bucket, sliding window a limity na klienta, tenanta či endpoint.
  • Kvóty a omezování provozu: Nastavujte denní a měsíční kvóty pro partnery; při anomáliích limity přizpůsobujte.
  • WAF/WAAP: Používejte filtry proti OWASP API Top 10 (např. BOLA/IDOR) a detekujte SSRF, SQLi a XSS v polyglotních payloadech.
  • DDoS: Zajistěte ochranu na síťové i aplikační vrstvě, connection draining a ochranu L7 s prokázáním vykonané práce (proof-of-work) či challenge pro podezřelé klienty.

Bezpečnost hlaviček a protokolů HTTP/gRPC

  • HTTP Strict-Transport-Security, X-Content-Type-Options, Content-Security-Policy (pro klienty v prohlížeči), Cache-Control pro citlivé odpovědi.
  • gRPC: Vynucujte TLS/mTLS a autorizaci metod, nastavujte limity velikosti zpráv, deadlines a cancellation pro zajištění robustnosti.

Správa tajemství a konfigurací

  • Ukládání do trezorů: Ukládejte tajemství do vyhrazených trezorů (KMS, HSM, Secret Manager). Nikdy neukládejte klíče do repozitáře.
  • Rotace a expirace: Zajistěte krátkou platnost, automatické obnovování a postupy break-glass.
  • Princip nejmenších oprávnění: Používejte RBAC pro přístup k tajemstvím, auditujte přístupy a přidělujte oprávnění just-in-time.

Protokolování, audit a detekce anomálií

  • Strukturované logy: Používejte korelovaná trace_id/span_id, omezte PII na minimum a nezaznamenávejte žádná tajemství. Využívejte formát JSON a standard OpenTelemetry.
  • Nezpochybnitelnost: Podepisujte logy, používejte úložiště WORM a dodržujte dobu uchovávání stanovenou předpisy.
  • SIEM a upozorňování: Nastavte pravidla pro nárůst odpovědí 4xx/5xx, neobvyklé vzorce volání a abnormální čerpání kvót.

Bezpečný životní cyklus API: SDLC, testování a kontroly CI/CD

  • Posun bezpečnosti doleva: Provádějte modelování hrozeb (STRIDE, LINDDUN), definujte bezpečnostní požadavky a security acceptance criteria.
  • SAST/DAST/IAST: Provádějte statickou, dynamickou a interaktivní analýzu, pravidelné penetrační testy a fuzzing API.
  • Kontroly v CI/CD: Používejte skener závislostí (SCA), kontrolujte podpisy artefaktů a uplatňujte zásady no-admin on prod a policy as code.

Dodavatelský řetězec a standardy supply chain

  • SBOM: Generujte softwarové kusovníky (CycloneDX, SPDX) pro API brány i služby.
  • Podpisy a původ: Podepisujte kontejnery a artefakty (Sigstore/Cosign), dodržujte úrovně SLSA.
  • Správa závislostí: Povolujte pouze schválené repozitáře, pravidelně aktualizujte závislosti a blokujte zranitelné verze.

Zero Trust pro API

  • Nevěř, vždy ověřuj: Autentizujte a autorizujte na každé hranici a používejte mTLS mezi všemi komponentami.
  • Kontextové zásady: Rozhodujte podle rizika (umístění, stav zařízení, čas, chování klienta).
  • Segmentace: Zaveďte mikrosegmentaci služeb a pravidla firewallu deny-by-default.

Specifika mobilních, IoT a edge klientů

  • Mobilní klienti: Vážte tokeny (DPoP), ověřujte atestaci zařízení (SafetyNet/DeviceCheck) a minimalizujte množství tajemství v aplikaci.
  • IoT: Používejte pro každé zařízení jedinečné certifikáty, pravidelně je rotujte, zajistěte bezpečné spouštění a podepisujte aktualizace OTA.
  • Edge: Zajistěte místní validaci zásad, synchronizaci tajemství a odolnost při výpadku připojení.

Chybové stavy, návratové kódy a bezpečná komunikace o problémech

  • Neprozrazujte interní podrobnosti: V produkčním prostředí vracejte obecné zprávy; podrobnosti zaznamenávejte pouze do logů.
  • Konzistence: Používejte standardizované kódy (HTTP/gRPC) a v odpovědích uvádějte korelační ID.
  • Bezpečné opakování: Používejte idempotentní operace, exponenciální backoff a jitter.

Compliance a regulace

  • GDPR: Minimalizujte data, uplatňujte zásadu data protection by design, respektujte práva subjektů údajů a používejte pseudonymizaci či maskování.
  • Odvětvové standardy: PCI DSS pro platební údaje, HIPAA ve zdravotnictví, FAPI/Open Banking ve finančnictví.
  • Rezidence dat: Řiďte umístění dat a jejich přeshraniční přenosy; data v klidu šifrujte pomocí KMS/HSM.

Role API gateway a service mesh v bezpečnostní architektuře

  • API Gateway: Centralizovaná autentizace a autorizace, ukončování mTLS, omezení rychlosti, validace schémat, transformace a audit.
  • Service Mesh: Transparentní mTLS mezi službami, vynucování zásad, tvarování provozu a circuit breaking.
  • Obrana ve vrstvách: Kombinujte gateway (ochrana hranice) a mesh (vnitřní ochrana) pro zabezpečení od začátku do konce.

Metriky, observabilita a reakce na incidenty

  • Telemetrie: Používejte OpenTelemetry pro metriky, logy a trasování; nastavte SLO/SLI pro chyby autorizace a latenci.
  • Provozní příručky: Připravte postupy pro únik tajemství, expiraci klíčů, odvolání tokenů a obnovu služeb.
  • Cvičení: Provádějte stolní cvičení, chaos engineering a pravidelně ověřujte obnovu.

Referenční bezpečnostní architektura

  1. DNS a ochrana edge → WAF/WAAP → API Gateway (OAuth/OIDC, validace, omezení rychlosti) → Service Mesh (mTLS, OPA) → mikroslužby.
  2. KMS/HSM a Secret Manager pro klíče a tajemství; CI/CD s podepisováním artefaktů a SCA.
  3. SIEM/SOAR napojené na logy z gateway, mesh, IdP a infrastrukturních komponent.

Kontrolní seznam pro bezpečné nasazení API

  • Povinné TLS 1.3, zapnuté HSTS; slabé šifry zakázány.
  • OAuth 2.1 + OIDC, PKCE, krátká expirace tokenů, rotace klíčů a JWKS.
  • mTLS pro interní komunikaci, automatizovaná správa certifikátů.
  • Validace schémat, limity velikosti a rychlosti požadavků.
  • Zásady OPA pro autorizaci, princip minimálních oprávnění.
  • WAF/WAAP proti OWASP API Top 10, ochrana proti DDoS.
  • Bezpečné protokolování (bez tajemství), korelační ID, OpenTelemetry.
  • CI/CD se SAST/DAST/SCA, podepisováním artefaktů a SBOM.
  • Provozní příručky a pravidelná cvičení reakce na incidenty.

Závěr

Bezpečnost API není jednorázová konfigurace, ale soubor provázaných standardů, zásad a provozních návyků. Kombinace ochrany přenosu (TLS 1.3, mTLS), moderní identity (OAuth 2.1, OIDC), správné práce s tokeny (JWT/JWS/JWE), granulární autorizace (OPA), řízení zneužití (omezení rychlosti, WAF) a disciplinovaného SDLC (SAST/DAST, SBOM, podepisování) poskytuje robustní, auditovatelný a škálovatelný základ. Tyto prvky implementujte postupně podle míry rizika a vyspělosti organizace a průběžně je zlepšujte pomocí měřitelných cílů (SLO) a pravidelných bezpečnostních auditů.