Autentifikácia vs. autorizácia

Autentifikácia a autorizácia sa v bežnej reči často používajú ako synonymá — obe začínajú na „auth", obe sa týkajú prihlasovania a obe znejú ako niečo, čo „rieši IT oddelenie". V bezpečnostnej praxi je to však jedno z najdôležitejších rozlíšení vôbec: autentifikácia odpovedá na otázku „kto si", autorizácia na otázku „čo môžeš robiť". Firma môže mať dokonale nastavené prihlasovanie — silné heslá, viacfaktorové overenie, žiadny únik prístupových údajov — a napriek tomu prísť o dáta zákazníkov len preto, že po úspešnom prihlásení nikto neskontroloval, či má konkrétny používateľ naozaj právo vidieť to, o čo si práve povedal.

Dva pojmy, jedna skratka „Auth" — a jeden častý omyl

V odbornej terminológii sa pre oba pojmy zaužívali skratky AuthN (authentication, autentifikácia) a AuthZ (authorization, autorizácia) — práve preto, aby sa jasne odlíšili aj v písanej podobe, keď samotné slovo „auth" ostáva nejednoznačné. Autentifikácia je proces overenia, že subjekt (používateľ, zariadenie, proces) je naozaj tým, za koho sa vydáva. Autorizácia je priznanie konkrétnych prístupových oprávnení danému subjektu — teda rozhodnutie, čo presne smie po overení identity robiť.

Autentifikácia: dôkaz, že ste to naozaj vy

Autentifikácia stojí na tzv. autentifikačných faktoroch — niečo, čo poznáte (heslo, PIN), niečo, čo vlastníte (telefón s aplikáciou, hardvérový kľúč), alebo niečo, čím ste (odtlačok prsta, tvár). Viacfaktorové overenie (MFA) kombinuje aspoň dva z nich, a práve preto výrazne sťažuje zneužitie odcudzeného hesla. Dôležité je ale pochopiť hranicu toho, čo MFA rieši: dokazuje identitu, nič viac. Neurčuje, ku ktorým systémom, záznamom alebo funkciám má daná identita prístup — to je už úloha autorizácie, ktorá nastupuje hneď po nej. Podrobne sme princípy nastavenia MFA rozobrali v samostatnom článku o viacfaktorovej autentifikácii.

Práve tu vzniká najčastejší mylný predpoklad v praxi: že zapnuté MFA automaticky znamená zabezpečenú aplikáciu. MFA chráni dvere na vstupe. Čo sa deje potom — ku ktorým miestnostiam má prihlásený človek kľúč — je úplne samostatná otázka.

Autorizácia: čo smiete robiť, keď už ste vnútri

Autorizácia sa v praxi najčastejšie rieši pomocou RBAC (role-based access control) — každému používateľovi sa priradí jedna alebo viac rolí a každá rola má definovaný súbor oprávnení, čo výrazne zjednodušuje správu oproti nastavovaniu prístupov jednotlivo pre každého človeka. Platí pri tom princíp najnižších oprávnení: každému subjektu prideliť len také prístupy, ktoré nevyhnutne potrebuje na svoju úlohu — nič navyše „pre istotu".

Keď prihlásenie funguje, ale kontrola prístupu nie — reálne prípady

V praxi to vyzerá napríklad takto: webová appka zobrazuje faktúry na adrese „faktura.html?id=1042" — appka pri tejto požiadavke overí, že ste prihlásený (autentifikovaný) používateľ, ale už neskontroluje, či faktúra číslo 1042 patrí práve vám (autorizáciu). Stačí v adrese zmeniť číslo a systém bez námietok zobrazí cudziu faktúru. Tento typ chyby má aj svoj odborný názov — Broken Object Level Authorization (BOLA) — no podstatné je, že chyba nie je v prihlásení: útočník sa nikam nenabúral, systém mu dáta sám vydal, lebo si ich nikto „neporovnal" s tým, kto konkrétne sa pýta.

Časté chyby a odporúčania

• Stotožňovanie zapnutého MFA so zabezpečenou aplikáciou — MFA dokazuje identitu, nerozhoduje o rozsahu prístupu k dátam ani funkciám.
• Kontrola oprávnení len pri prihlásení, nie pri každej akcii — správne nastavenie overuje autorizáciu na úrovni každého jednotlivého požadovaného záznamu alebo objektu, nielen na úrovni „je prihlásený".
• Príliš široké východiskové oprávnenia po vytvorení účtu — namiesto princípu najnižších oprávnení sa novým používateľom často pridelí viac prístupu, než reálne potrebujú, „aby to fungovalo bez ďalšieho riešenia".
• Netestovanie autorizácie na úrovni API — práve táto medzera stojí za rizikom BOLA, bežnou chybou v appkách a API.