Zabezpečení webového API - Web API security

Zabezpečení webového API znamená ověřování programy nebo uživatelé, kteří vyvolávají a webové rozhraní API.

Spolu se snadnou integrací API přicházejí potíže se zajištěním správnosti ověřování (AuthN) a oprávnění (AuthZ). V prostředí multitenant mohou ovládací prvky zabezpečení založené na správném AuthN a AuthZ pomoci zajistit, aby byl přístup API omezen na ty, kteří to potřebují (a mají na to nárok). Vhodná schémata AuthN umožňují producentům (API nebo službám) správně identifikovat spotřebitele (klienty nebo volající programy) a vyhodnotit jejich úroveň přístupu (AuthZ). Jinými slovy, může a spotřebitel vyvolat konkrétní metodu (obchodní logiku) založenou na pověření představil?

"Chyby designu rozhraní jsou velmi rozšířené ze světa Windows krypto procesory přes různévestavěné systémy až do antivirový software a samotný operační systém. “^[1]

Způsob ověřování a autorizace

Mezi nejběžnější metody pro ověřování a autorizaci patří.

1. Statické řetězce: Jsou to jako hesla, která API poskytují spotřebitelům.
2. Dynamické tokeny: Jedná se o časově založené tokeny získané volajícím z ověřovací služby.
3. Uživatelem delegované tokeny: Jedná se o tokeny jako např OAuth^[2] které jsou poskytovány na základě autentizace uživatele.
4. Politika & řízení přístupu na základě atributů: zásady pomocí atributů definují, jak lze vyvolat API pomocí standardů, jako je ALFA nebo XACML.

Výše uvedené metody poskytují jinou úroveň zabezpečení a snadnou integraci. Nejjednodušší způsob integrace často nabízí také nejslabší model zabezpečení.

Statické řetězce

Blokové schéma základního ověřování

V metodě statických řetězců volající API nebo klient vloží řetězec jako token do požadavku. Tato metoda se často označuje jako základní autentizace. „Z bezpečnostního hlediska není základní ověřování příliš uspokojivé. Znamená to zasílat heslo uživatele po síti ve formátu prostého textu pro každou jednotlivou stránku, na kterou přistupujete (pokud není k dispozici zabezpečený protokol nižší úrovně, například SSL, se používá k šifrování všech transakcí). Uživatel je tedy vůči všem velmi zranitelný paketové čichače na síti."^[3]

Dynamické tokeny

Když API je chráněn dynamickým tokenem, existuje časově nonce vložen do tokenu. Token má čas žít (TTL), po kterém musí klient získat nový token. Metoda API má časovou kontrolu algoritmus, a pokud platnost tokenu vypršela, je požadavek zakázán. "Příkladem takového tokenu je Webový token JSON. Nárok „exp“ (čas vypršení platnosti) označuje čas vypršení platnosti, po kterém NESMÍ BÝT JWT přijato ke zpracování. “^[4]

Uživatelem delegovaný token

Tento typ tokenu se používá v třínohých systémech, kde aplikace potřebuje přístup k API jménem uživatele. Namísto odhalení uživatelského jména a hesla k aplikaci uživatel uděluje token, který zapouzdřuje uživatelům oprávnění pro aplikaci k vyvolání API.

Autorizační rámec OAuth 2.0 umožňuje aplikaci třetí strany získat omezený přístup k HTTP služba buď jménem vlastníka prostředku tak, že zorganizuje interakci schválení mezi vlastníkem prostředku a službou HTTP, nebo povolí aplikaci třetí strany získat přístup svým vlastním jménem.^[5]

Podrobná autorizace pro API

Atributové řízení přístupu

V tomto přístupu existuje Policy Enforcement Point buď v samotném API, v rámci API (jako zachycovač nebo obslužná rutina zpráv), nebo jako brána API (např. WSO2, Kong nebo podobný ), který zachytí volání API a / nebo odpověď zpět z API. Převede jej na žádost o autorizaci (obvykle v XACML), kterou odešle do bodu rozhodnutí rozhodnutí (PDP), např. AuthZForce nebo Axiomatika. Bod rozhodování o zásadách je konfigurován se zásadami, které implementují dynamické řízení přístupu, které může k určení, který přístup je povolen nebo odepřen, použít libovolný počet atributů uživatele, prostředku, akce a kontextu. Pravidla mohou být o:

1. zdroj (např. bankovní účet)
2. uživatel (např. zákazník)
3. kontext (např. denní doba)
4. vztah (např. zákazník, jemuž účet patří).

Zásady jsou vyjádřeny v ALFA nebo XACML.

Reference