API s regulovanými daty zabezpečíte tak, že si namodelujete, kdo by ho mohl zneužít, autorizaci kontrolujete u každého objektu a pole, sbíráte a vracíte co nejméně dat a tajné klíče i auditní logy držíte pod přísnou kontrolou. Slabiny, na kterých v praxi nejvíc záleží, jsou mezery v autorizaci a odpovědi, které odhalují příliš mnoho dat, ne prolomené šifrování.
Začněte modelem hrozeb pro data, ne pro framework
Než zvolíte nástroje, sepište, co API zpřístupňuje a kdo by ho mohl zneužít. Pro banku to znamená data o účtech a transakcích; pro energetickou nebo utilitní firmu to mohou být data z měření, smlouvy se zákazníky a provozní hodnoty ze sítě.
Užitečný model hrozeb je krátký. Uvádí citlivá data, každého volajícího, který se k nim dostane, akce, které by každý volající měl smět provést, a co se stane, když bude některý z nich kompromitován. Tento dokument pak řídí všechna opatření níže a říká revidujícím, co mají testovat.
- Která data jsou osobní, důvěrná nebo regulovaná a kde jsou uložena.
- Každý konzument API: interní služby, partneři, mobilní aplikace a administrátoři.
- Co smí každý konzument číst, měnit nebo spouštět.
- Dopad uniklého tokenu, zlovolného člověka uvnitř firmy nebo kompromitovaného systému partnera.
Autentizujte každého volajícího a pak autorizujte každý objekt
Pro uživatele použijte standardní protokol, například OAuth 2.0 s OpenID Connect, a pro volání mezi službami krátkodobé tokeny nebo vzájemné TLS (mutual TLS). Vyhněte se dlouhodobým sdíleným API klíčům, protože nikdo nepozná, který systém je použil, a nelze je zneplatnit, aniž by se rozbily ostatní.
Autentizace jen dokazuje, kdo volá. První položkou v OWASP API Security Top 10 je chybná autorizace na úrovni objektů (broken object level authorization): platný uživatel změní v požadavku identifikátor a přečte cizí záznam. Vlastnictví nebo příslušnost k tenantovi kontrolujte na serveru u každého objektu, každé funkce a každého citlivého pole a nikdy nevěřte identifikátoru ani roli, které posílá klient.
Každému klientovi a službě dejte jen nejmenší nutná oprávnění
Princip nejmenších oprávnění omezuje škodu, když se přece jen něco pokazí. Vydávejte samostatné přístupové údaje pro každého konzumenta, omezte tokeny na konkrétní operace a administrativní endpointy držte na samostatné cestě s přísnějšími kontrolami.
Stejné pravidlo uplatněte i pod API. Servisní účet, který čte data z měření, by je neměl umět smazat, a reportovací úloha by se měla k databázi připojovat s rolí jen pro čtení. Oprávnění pravidelně revidujte, protože přístup udělený kvůli jednorázovému úkolu má sklon zůstat navždy.
Sbírejte méně, vracejte méně a uchovávejte kratší dobu
Minimalizace dat je zásada GDPR i silné bezpečnostní opatření: data, která nikdy neuložíte, nemohou uniknout. U každého pole se ptejte, zda ho služba opravdu potřebuje, a co nepotřebuje, vypusťte nebo pseudonymizujte.
Stejnou disciplínu uplatněte u odpovědí. Místo serializace celých databázových objektů definujte explicitní schémata odpovědí, maskujte identifikátory, jako jsou čísla účtů, tam, kde není potřeba celá hodnota, a nastavte doby uchovávání, aby se staré záznamy mazaly. Pro každý účel zpracování zdokumentujte právní základ a s každým dodavatelem, který s daty pracuje, podepište zpracovatelskou smlouvu. Jde o technickou praxi, ne o právní radu, proto k právnímu posouzení přizvěte svého pověřence pro ochranu osobních údajů nebo právníka.
Validujte každý vstup a omezte, kolik může jeden volající spotřebovat
Každý požadavek považujte za nepřátelský, dokud není zvalidován. Pro každý endpoint vynucujte schéma, odmítejte neznámá pole a používejte parametrizované dotazy, aby se vstup nikdy nestal součástí databázového příkazu.
Několik rizik z OWASP pro API vzniká z chybějících limitů, ne ze špatného kódu. Omezte počet požadavků na klienta (rate limiting), velikost stránek i objem dat v požadavku a chraňte citlivé obchodní procesy, jako jsou platby nebo změny smluv, před automatizovaným zneužitím. Pokud API jménem volajících stahuje vzdálené URL, omezte povolené cíle, abyste zabránili podvržení požadavků na straně serveru (SSRF).
Tajné klíče nepatří do kódu, obrazů ani logů
Hesla k databázím, podpisové klíče a přístupové údaje partnerů patří do specializovaného správce tajných klíčů, odkud se vkládají za běhu a pravidelně se rotují. V build pipeline prohledávejte repozitáře a obrazy kontejnerů na tajné klíče a každý tajný klíč, který se dostane do správy verzí, považujte za kompromitovaný.
Tajné klíče oddělte podle prostředí, aby uniklý testovací přístup nikdy neotevřel produkci. Omezte, kdo může tajné klíče v produkci číst, a každý přístup k nim zaznamenávejte.
Logujte kvůli auditu a navrhujte tak, aby incidentů bylo méně
Regulovaná prostředí musejí zpětně odpovědět na jednoduchou otázku: kdo přistoupil ke kterým datům, kdy a přes kterého klienta. Zaznamenávejte to u každého citlivého čtení a zápisu, logy ukládejte tam, kde je provozovatelé aplikace nemohou měnit, a do zpráv v logu nedávejte osobní údaje.
Logování doplňte upozorněními na neobvyklé vzorce, například když jeden klient čte mnohem víc záznamů než obvykle, a otestovaným plánem reakce na incidenty. Přes Sopra Steria naši inženýři stavěli zabezpečená API pro citlivá data energetických a utilitních firem v regulatorních omezeních a vedli vývoj nástroje pro provozní dohled, u kterého vynucené bezpečnostní standardy šly ruku v ruce s menším počtem produkčních incidentů. SDK Enterprises dnes uplatňuje stejné postupy na klientských projektech.
Hlavní body
- Krátký písemný model hrozeb pro data by měl řídit každé bezpečnostní opatření v API.
- Autorizaci kontrolujte na serveru u každého objektu, funkce a citlivého pole, ne jen při přihlášení.
- Princip nejmenších oprávnění platí pro tokeny, servisní účty i databázové role.
- Minimalizace dat snižuje rizika z pohledu GDPR i dopad jakéhokoli úniku.
- Auditní logy musejí ukázat, kdo k čemu a kdy přistoupil, aniž by samy vynášely osobní údaje.
Časté dotazy
Stačí k zabezpečení API HTTPS?
Ne. TLS chrání data při přenosu, ale mnoho úniků přes API se týká autentizovaných volajících, kteří se dostanou k datům, jež by vidět neměli. Kontroly autorizace, validace vstupů, limity požadavků a auditní logování jsou nutné i tak.
Co je chybná autorizace na úrovni objektů?
Je to chyba, kdy API kontroluje, že je volající přihlášen, ale ne to, že požadovaný záznam patří jemu. Změna identifikátoru v URL nebo v těle požadavku pak odhalí data jiných uživatelů. Opravou je kontrola vlastnictví nebo příslušnosti k tenantovi na serveru u každého objektu.
Předepisuje GDPR konkrétní bezpečnostní opatření pro API?
GDPR vyžaduje technická a organizační opatření přiměřená danému riziku, aniž by předepisovalo konkrétní nástroje. Opatření jako omezení přístupu, minimalizace, pseudonymizace a logování jsou běžné způsoby, jak tento požadavek splnit, a vaši právní poradci by měli potvrdit, co platí pro váš případ.