Autentifikácia v aplikácii: SSO, dvojfaktorové overenie a správa používateľov
Používateľ sa prihlási, no zobrazí cudziu objednávku. Alebo odíde z firmy a otvorená relácia ďalej funguje. Prihlasovanie je iba začiatok. Aplikácia musí spojiť overenie identity, oprávnenia, obnovu účtu a včasné odobratie prístupu.
01Rozlišujte identitu, práva a prihlásenú reláciu
Autentifikácia overuje, pod akým účtom človek koná. Autorizácia rozhoduje, čo smie urobiť. Relácia udržiava prihlásenie medzi požiadavkami. Tieto časti navrhujte spoločne, ale overujte každú zvlášť. Úspešné prihlásenie ešte neznamená právo stiahnuť konkrétnu faktúru.
Pred výberom služby spíšte zamestnancov, zákazníkov, externistov, správcov a technické integrácie. Pri každej skupine určte zakladateľa účtu, organizáciu a schvaľovateľa práv. Účet človeka a automatické prepojenie majú odlišný životný cyklus. Spoločné heslo správcu pre obe potreby vám túto hranicu zmaže.
02SSO nezastupuje všetky pravidlá prístupu
SSO umožňuje využiť prihlásenie u poskytovateľa identity vo viacerých aplikáciách. Firma môže sústrediť pravidlá overovania a časť správy na jedno miesto. Každá aplikácia však naďalej zodpovedá za priradenie človeka k správnej organizácii a za svoje operácie.
OpenID Connect pridáva vrstvu identity nad OAuth 2.0. Samotný OAuth rieši delegované oprávnenie a nie je úplným prihlasovacím protokolom. SAML je ďalší spôsob federovaného prihlasovania, používaný aj v podnikových integráciách.
| Pojem | Úloha | Čo nenahrádza |
|---|---|---|
| SSO | Spoločné prihlasovanie | Práva ku konkrétnym údajom |
| OIDC alebo SAML | Odovzdanie overenej identity | Schválenie účtu a jeho práv |
| OAuth 2.0 | Delegovaný prístup k zdrojom | Celý návrh prihlasovania |
| MFA | Viac rôznych druhov faktorov | Bezpečnú obnovu a reláciu |
| SCIM | Správa používateľov a skupín | Okamžité ukončenie každej relácie |
Overte protokoly podporované skutočným prostredím zákazníka. Určte aj to, kto môže pripojiť ďalšiu organizáciu a ako preukáže oprávnenie. Znalosť názvu firmy alebo e-mailovej domény nemá sama umožniť prevziať jej správu.
03Použite udržiavanú implementáciu a overujte odpovede
Vlastná implementácia prihlasovacieho protokolu prináša ďalšie riziká. Žiadajte udržiavanú knižnicu a opis overovania odpovedí. Aktuálne odporúčania pre OAuth obsahuje RFC 9700, vrátane PKCE a kontroly presmerovania. Token s identitou nie je automaticky prístupovým tokenom pre ľubovoľné API.
Dodávateľ má predviesť odmietnutie cudzieho vydavateľa, nesprávneho príjemcu, neplatného tokenu aj chybne priradenej organizácie. Dva účty neprepájajte len preto, že zdroje vrátia rovnaký e-mail. Dohodnite dôveryhodné podmienky prepojenia a bezpečný postup pri konflikte.
04MFA posudzujte podľa hrozieb a náhradného prístupu
Dve heslá nepredstavujú dva odlišné faktory. Kombinácia môže využiť znalosť a držanie prostriedku. NIST rozlišuje odolnosť proti phishingu; ručne prepisované jednorazové kódy ju samy neposkytujú. Počet obrazoviek preto nie je mierou bezpečnosti.
Passkeys využívajú kryptografické kľúče naviazané na konkrétnu službu, ako vysvetľuje FIDO Alliance. Môžu sa synchronizovať medzi zariadeniami alebo zostať viazané na konkrétny prostriedok. Podporované možnosti vyberajte podľa citlivosti účtov, zariadení a spôsobu obnovy.
Pre správcov navrhnite prísnejšie pravidlá než pre bežné čítanie. Pri zmene fakturačných údajov, pridaní správcu alebo výmene overovacieho prostriedku zvážte nové overenie. Otestujte aj človeka bez inteligentného telefónu a stratu všetkých obvyklých prostriedkov.
Organizačnú stránku zavádzania opisuje návod MFA a passkeys vo firme. Pri návrhu aplikácie potrebujete navyše preveriť nadväznosť identity na jednotlivé oprávnenia a relácie.
05Obnova účtu nesmie obísť ochranu
Ak zostávajú heslá, povoľte správcov hesiel, obmedzujte pokusy a kontrolujte známe kompromitované heslá. Ukladanie zverte overenému riešeniu. OWASP spája prihlasovanie aj s opätovným overením pri citlivých zmenách.
Odporúčania OWASP pre zabudnuté heslo zahŕňajú jednorazové tokeny s obmedzenou platnosťou a odpovede, ktoré zbytočne neprezradia existenciu účtu. Pridajte upozornenie na zmenu a pravidlá pre už otvorené relácie. Rovnako dôsledne riešte obnovu MFA.
Podpora potrebuje postup overenia žiadateľa, schvaľovania výnimiek a zaznamenania zásahu. Naliehavý telefonát od údajného riaditeľa nemá automaticky vypnúť ochranu. Pri citlivých účtoch si vopred dohodnite druhého schvaľovateľa a kontrolovaný náhradný prístup. Vyskúšajte ho na testovacom účte.
06Roly preložte do konkrétnych operácií
Začnite maticou: zobraziť zákazku, upraviť ju, schváliť zľavu, exportovať údaje a spravovať členov. Neurčitá rola správcu postupne získa priveľa práv. RBAC prideľuje oprávnenia rolám; niekedy musíte pridať podmienku organizácie, vlastníctva záznamu alebo limitu sumy.
OWASP odporúča najmenšie potrebné práva a kontrolu každej požiadavky. Skryté tlačidlo nie je kontrolou prístupu. Server musí odmietnuť zakázanú operáciu aj pri požiadavke odoslanej mimo vášho rozhrania.
| Modelová rola | Môže | Nemôže automaticky |
|---|---|---|
| Obchodník | Upraviť pridelenú ponuku | Exportovať všetkých zákazníkov |
| Schvaľovateľ | Potvrdiť výnimku vo svojom rozsahu | Prideliť si práva správcu |
| Správca organizácie | Spravovať členov vlastnej firmy | Čítať údaje inej firmy |
| Podpora | Riešiť schválenú požiadavku | Trvalo vstupovať do všetkých účtov |
Ide o ilustračný príklad. Upravte ho podľa skutočných zodpovedností a testujte aj kombinácie rolí. Pri prepínaní medzi organizáciami preverujte vyhľadávanie, export, prílohy a odkazy zo správ. Oddelenie údajov musí fungovať aj mimo hlavného zoznamu.
07Odhlásenie a odobratie práv musia mať účinok
Požadujte bezpečné cookie, primerané vypršanie relácií a serverové zneplatnenie. OWASP pri správe relácií opisuje aj atribúty Secure, HttpOnly a SameSite. Samy osebe však nenahrádzajú celý návrh ochrany pred podvrhnutými požiadavkami.
Rozlišujte odhlásenie z aplikácie, odhlásenie u poskytovateľa identity a zrušenie prístupu na všetkých zariadeniach. Zistite, ako dlho sa dá po odobratí práv použiť existujúci token. Prijateľné oneskorenie zapíšte a overte meraním, aj v otvorenom prehliadači a mobilnom klientovi.
08Riešte nástup, zmenu práce aj odchod
Účet má mať vlastníka, dôvod a podľa potreby dátum skončenia. Pri nástupe schváľte organizáciu a minimálne práva. Pri presune na inú pozíciu odoberte staré oprávnenia. Pri odchode nezabudnite na relácie, API kľúče, zdieľané odkazy a odovzdanie rozpracovaných úloh.
SCIM štandardizuje správu používateľov a skupín medzi systémami. Aj tak overte účinok konkrétnej integrácie: zabráni deaktivácia iba novému prihláseniu, alebo ukončí aj existujúci prístup? Úspešná synchronizácia sama nedokazuje dokončený odchod.
09Čo overiť pred spustením
- Schválenú maticu rolí a odmietnutie zakázaných operácií.
- Prihlásenie cez skutočného poskytovateľa identity aj jeho výpadok.
- Obnovu účtu, zmenu e-mailu a výmenu overovacieho prostriedku.
- Odhlásenie, odobratie práv a deaktiváciu v otvorených reláciách.
- Audit zmien a obnovy bez hesiel, tokenov a tajomstiev v záznamoch.
- Zodpovednosť za aktualizácie, incidenty a revízie prístupov.
Ku každému testu zapíšte verziu, účet, očakávaný a skutočný výsledok. Protokol má doložiť správanie systému, nie iba označenie „SSO hotové“. Najcennejší býva test, ktorý odlíši prihláseného človeka od človeka oprávneného vykonať konkrétnu operáciu.
10Spravovaná služba alebo vlastná prevádzka
Spravovaný poskytovateľ identity môže prevziať aktualizácie a dostupnosť prihlasovacej infraštruktúry. Firma stále zodpovedá za pravidlá účtov, integráciu a reakciu na incident. Vlastná prevádzka potrebuje navyše odborníkov na aktualizácie, obnovu, dohľad a správu kľúčov. Porovnávajte rozdelenie zodpovednosti, nielen licenčný poplatok.
Do dopytu uveďte aktívnych používateľov, zákaznícke organizácie a počet SSO pripojení. Zistite, či konkrétny balík zahŕňa audit, automatickú správu účtov, náhradné metódy a export. Vyžiadajte aj postup pri odchode od poskytovateľa: ktoré údaje možno preniesť, ako znovu pripojíte overovacie prostriedky a kto zabezpečí migráciu.
11Pripravte prechod bez straty účtov
Najprv zmapujte existujúce identity. Jedna osoba môže mať niekoľko účtov, zmenený e-mail a členstvo vo viacerých firmách. Použite stabilný interný identifikátor. Zmena adresy nemá vytvoriť iného vlastníka objednávok. Nejasné prepojenia riešte kontrolovane; hromadná migrácia ich nemá potichu zlúčiť.
- V testovacom prostredí skontrolujte účty, členstvá a roly bez živých tajomstiev.
- Do pilotu zapojte správcu, externistu aj človeka v dvoch organizáciách.
- Preverte nové prihlásenie, obnovu a správanie starej otvorenej relácie.
- Pripravte podporu, informovanie ľudí a postup pri výpadku.
- Po prechode ukončite staré cesty podľa plánu a skontrolujte záznamy.
Každá záložná cesta musí mať vlastníka a termín ukončenia. Inak sa pôvodné prihlásenie bez MFA zmení na trvalú výnimku. Návrat pri poruche nemá znamenať vypnutie ochrany pre všetkých. Dopredu určte účty oprávnené na núdzovú prácu a podmienky ich dohľadu.
12Modelový odchod správcu zákazníka
Predstavte si správcu firmy A, ktorý je zároveň bežným členom firmy B. Po odchode z A mu odoberiete toto členstvo. Aplikácia má zachovať povolenú prácu pre B, ale odmietnuť export A, starý odkaz na prílohu aj správu členov A. Každú cestu otestujte zvlášť.
Následne deaktivujte celý účet. Skúste otvorený prehliadač, iné zariadenie a osobné API kľúče. Záznam má ukázať vykonávateľa zmeny a čas jej účinku. Je to ilustračný preberací scenár, nie výsledok skúšky konkrétneho produktu. Odhalí aj problém, ktorý samotné nové prihlásenie nezachytí.
Pri prenose zodpovednosti skontrolujte tiež vlastníka automatických úloh a schvaľovacích pravidiel. Odobratie účtu nemá zastaviť fakturáciu iba preto, že ju pôvodne nastavil odchádzajúci človek. Systém má odlíšiť osobné oprávnenie od schválenej firemnej automatizácie.
13Časté otázky o autentifikácii
Stačí SSO bez MFA?
SSO opisuje spoločné prihlásenie. Silu overenia určujú konkrétne metódy a pravidlá. Pri citlivých účtoch nastavte primerané MFA a vyskúšajte aj náhradný prístup.
Musíme prihlasovanie vyvíjať sami?
Spravidla je vhodné použiť overenú službu alebo udržiavanú implementáciu. Aplikácia stále potrebuje správne oprávnenia, bezpečné prepájanie účtov a proces odchodu.
Odstránia passkeys všetky útoky?
Nie. Zvyšujú odolnosť prihlasovania proti phishingu, ale neopravia dostupné cudzie záznamy, odcudzenú reláciu ani slabý postup obnovy.
Ako overiť odobratie prístupu?
Deaktivujte testovacieho používateľa a skúste pokračovať v jeho existujúcich reláciách aj integráciách. Výsledok porovnajte s dohodnutým časom zneplatnenia.
Pripravujete portál alebo meníte prihlasovanie? Pri vývoji webových aplikácií s vami prejdeme identity, roly a preberacie scenáre. Začnite ľuďmi, organizáciami a operáciami, ktoré systém musí rozlíšiť.