Principy autentizace a autorizace: ověřování a řízení přístupu

Proč autentizace a autorizace tvoří jádro IAM

Autentizace a autorizace jsou dvě vzájemně provázané disciplíny, které společně určují kdo jste (ověření identity) a co smíte dělat (řízení přístupu). V ekosystému IAM (Identity and Access Management) tvoří spolu s auditováním, správou životního cyklu identit a správou privilegovaných přístupů ucelený rámec pro bezpečné, auditovatelné a uživatelsky přívětivé poskytování přístupu k prostředkům v organizaci i mimo ni.

Základní pojmy a hranice odpovědností

• Identita (identity) – reprezentace subjektu (osoba, služba, zařízení). Nese atributy (jméno, role, oddělení, skóre rizika).
• Principal – entita, která se autentizuje vůči systému (uživatel, služba, workload).
• Autentizace – proces prokázání, že subjekt je tím, za koho se vydává.
• Autorizace – proces rozhodnutí, zda autentizovaný subjekt smí provést danou akci nad daným zdrojem.
• AAA – Authentication, Authorization, Accounting (auditní záznamy a účtování aktivit).
• PEP/PDP/PIP/PAP – enforcement (PEP), decision point (PDP), zdroj atributů (PIP), autor politik (PAP); základní architektura řízení přístupu.

Autentizační faktory a jejich vlastnosti

• Něco, co znáte – hesla, PINy, odpovědi na otázky. Nízká odolnost vůči phishingu a opakovanému použití.
• Něco, co máte – kryptografické klíče, HW tokeny, mobilní zařízení (OTP, push).
• Něco, čím jste – biometrie (otisk, FaceID). Nutná ochrana šablon a vyhodnocení rizik zneužití.

MFA kombinuje minimálně dva různé faktory. Phishing-resistant MFA (FIDO2/WebAuthn s platformním nebo bezpečnostním klíčem) eliminuje předání tajemství útočníkovi a váže přihlášení na původ domény.

Moderní metody autentizace

• Hesla + správné ukládání – hashování se saltem a paměťově náročnými funkcemi (bcrypt, scrypt, Argon2), ideálně také s pepperem v HSM.
• TOTP/HOTP – jednorázové kódy z mobilních aplikací či HW tokenů; nutná ochrana seedů.
• Push a číselné výzvy – minimalizace „MFA fatigue“ pomocí ověřených údajů o žádosti (číslo/poloha/zdroj).
• FIDO2/WebAuthn (passkeys) – asymetrická kryptografie, klíče spárované s originem, vysoká odolnost proti phishingu.
• Certifikáty a mTLS – klientské certifikáty pro uživatele, služby a zařízení; správa životního cyklu (PKI) je klíčová.
• Kerberos – autentizace založená na tiketech v doménových prostředích s delegováním (S4U) a omezenou dobou platnosti ticketu.
• 802.1X/EAP – síťová autentizace na portu (drátová/bezdrátová), metody EAP-TLS/EAP-TTLS/PEAP.

Federace identit a SSO: role protokolů

SSO zvyšuje použitelnost i bezpečnost tím, že snižuje počet relací a míst, kde uživatel zadává tajemství. Federace přenáší ověření mezi důvěryhodnými doménami.

• SAML 2.0 – XML tokeny (Assertion) pro podnikové SSO mezi IdP a SP.
• OpenID Connect (OIDC) – identita nad OAuth 2.0 (ID Token s claims), vhodné pro moderní webové a mobilní aplikace.
• OAuth 2.0 – autorizace (delegování přístupu) pomocí Access Tokenů; nejde o autentizační protokol, byť se často kombinuje s OIDC.
• SCIM – standard pro provisioning identit a atributů napříč SaaS.

Riziková a kontinuální autentizace

Risk-based/Adaptive autentizace vyhodnocuje kontext (geolokace, reputace IP adresy, čas, zařízení, stav zařízení, anomálie) a dynamicky vyžaduje další faktor (step-up). Continuous Authentication udržuje důvěru během relace (behaviorální signály, opětovné výzvy při citlivé akci, relace s krátkým TTL a rotací tokenů).

Bezpečné řízení relací a tokenů

• Tokeny – bearer (např. JWT) i sender-constrained (DPoP, mTLS). Důležité jsou expirace, audience, issuer, nonce, rotace refresh tokenů, revokace a introspekce.
• Správa relací – cookies s atributy httpOnly a Secure, SameSite, ochrana proti fixaci relace, pravidelná obnova autentizace (reauth), detekce souběžných relací.
• Úložiště klíčů – KMS/HSM pro podpisové klíče, rotace a verzování (kid), publikování prostřednictvím JWKS.

Modely autorizace: od rolí k atributům a vztahům

• DAC – diskreční řízení (vlastník zdroje rozhoduje); flexibilní, ale ve velkém měřítku hůře řiditelné.
• MAC – mandatorní (např. štítky utajení); vhodné pro vládní a obranný sektor.
• RBAC – role mapují pracovní funkce na sady oprávnění; nutná je správa rolí a jejich hierarchií.
• ABAC – pravidla založená na atributech subjektu, zdroje, akce a kontextu (čas, poloha, citlivost).
• ReBAC – založeno na vztazích (graf přístupů: „uživatel je editorem dokumentu“); vhodné pro spolupráci a detailní oprávnění.
• PBAC/Policy-as-Code – politiky v deklarativním jazyce (např. Rego pro OPA) a jejich řízení v CI/CD.

Architektura rozhodování o přístupu

Typický tok: PEP zachytí požadavek → získá kontext od PIP (atributy, skupiny, stav zařízení) → odešle dotaz do PDP (vyhodnocuje politiky) → PDP vrátí Permit/Deny s případnými obligations (např. maskování dat) → PEP vynutí rozhodnutí. V praxi se kombinuje centrální rozhodování (API Gateway, sidecar) s lokální cache a vyhodnocováním při každé citlivé operaci (autorizace just-in-time).

Zero Trust a princip minimálních oprávnění

Zero Trust vynucuje nepředpokládat důvěru na základě sítě či umístění. Přístup je podmíněn identitou a stavem zařízení, které se průběžně ověřují. Least Privilege a Separation of Duties se uplatňují v politikách, schvalovacích procesech a při předcházení riziku kumulace oprávnění.

Privilegované přístupy (PAM)

• JIT/JEA – dočasné privilegované přístupy s granularitou až na úroveň příkazu/operace.
• Trezor tajemství – rotace účtů typu break-glass, kontrolované výpůjčky, záznam relací.
• Schvalovací workflow – víceúrovňové, auditované a napojené na tiketovací systémy.

API a služební identity v mikroservisách

Pro komunikaci mezi službami je standardem mTLS s oboustranným ověřením, SPIFFE/SPIRE pro workload identity, OAuth 2.0 (Client Credentials) a jemnozrnná autorizace v API Gateway. Sidecar (Envoy) v service mesh uplatňuje PEP s politikami (OPA, Rego) a vynucuje mTLS na síťové vrstvě.

Zařízení, IoT a neosobní identity

Zařízení a IoT často využívají device identity s výrobními certifikáty, TPM/TEE pro ochranu klíčů a atestaci (remote attestation) k prokázání integrity. Autorizace vychází z profilu zařízení (typ, firmware, stav zařízení) a segmentace sítě.

Správa životního cyklu identit

• Joiner-Mover-Leaver – automatizované přidělování, změny a odebírání přístupů podle změn v HR/CMDB.
• Provisioning – standard SCIM, konektory do SaaS a adresářů (AD/AAD/LDAP).
• Access Reviews – pravidelné recertifikace přístupů vlastníky aplikací a manažery.
• SoD – detekce a prevence konfliktů rolí (např. schvalování i vytváření plateb).

Ochrana tajemství a integrita přihlašování

• Hashování hesel – Argon2id s vhodnými parametry (paměť, počet iterací), unikátním saltem a odděleným pepperem.
• Rate limiting a lockout – postupné prodlužování prodlevy, detekce útoků credential stuffing (na základě telemetrie).
• Detekce kompromitovaných přihlašovacích údajů – porovnání se známými úniky, vynucení změny.
• Čisté UX – minimalizace zadávání hesel (SSO, passkeys), bezpečný samoobslužný reset s ověřením prostřednictvím více kanálů.

Bezpečnostní hrozby a mitigace

• Phishing/MFA fatigue – passkeys, číselné výzvy, vazba na origin, edukace uživatelů.
• Session hijacking/fixation – bezpečné cookies, rotace po přihlášení, detekce anomální aktivity.
• Token replay – tokeny sender-constrained (DPoP, mTLS), krátké TTL, vazba na zařízení.
• CSRF – SameSite, anti-CSRF tokeny, kontrola metody a původu.
• Privilegovaná eskalace – SoD, přístupy JIT, audit příkazů a schvalování.

Soukromí a regulace: Privacy-by-Design

Politiky a implementace musí respektovat minimalizaci sběru dat, účelové omezení, retenci a práva subjektů údajů (GDPR). Atributy používané pro autorizaci mají být nezbytné a transparentní; logy musí být pseudonymizované a přístup k nim řízený.

Dostupnost, škálování a odolnost

• Vysoká dostupnost – více aktivních instancí IdP/PDP, geografická redundance, quorum pro klíče.
• Výkon – cache rozhodnutí (odpovědí PDP), lokální vynucování, asynchronní doplňování kontextu.
• Disaster Recovery – chráněná PKI, zálohy klíčů, testované plány obnovy.

Metriky a governance IAM

• Auth Success Rate, MTTR incidentů, průměrná doba provisioningu, počet požadavků na step-up.
• Abnormal Login Rate, míra blokovaných útoků, úplnost recertifikací, pokrytí passkeys/MFA.

Praktický návrh IAM: doporučený postup

1. Model rizik a segmentace – klasifikace aplikací a dat, definice zón důvěry a požadavků na autentizaci.
2. Volba IdP a protokolů – OIDC/SAML pro SSO, OAuth 2.0 pro API, SCIM pro provisioning.
3. Strategie MFA – upřednostňovat FIDO2/WebAuthn; TOTP/push jako záložní kanál; minimalizovat výjimky.
4. Policy-as-Code – centralizovaný PDP s OPA/Rego, testy politik a CI/CD s peer review.
5. PAM – JIT/JEA, trezor tajemství, důsledné schvalování a audit relací.
6. Monitorování a reakce – SIEM, detekce anomálií, playbooky SOAR (blokace, reset tajemství, izolace).
7. UX a inkluze – samoobslužné funkce, podpůrné kanály pro bezpečné obnovení přístupu, minimalizace překážek bez snížení bezpečnosti.

Časté omyly a anti-patterny

• Používání OAuth 2.0 místo autentizace (bez OIDC) a záměna pojmů.
• Dlouhodobě platné tokeny bearer bez možnosti revokace a bez vazby na klienta.
• „Role explosion“ v RBAC bez governance a bez přechodu na ABAC pro jemnozrnná pravidla.
• Nevyvážený poměr UX a bezpečnosti – přílišné tření vede k obcházení politik.
• Nedostatečná správa klíčů, chybějící rotace a absence verzování klíčů.

Závěr

Úspěšná strategie IAM spojuje odolnou autentizaci (ideálně phishing-resistant passkeys) s kontextovou autorizací řízenou politikami, automatizovaným životním cyklem identit a přísnou správou privilegovaných přístupů. Důraz na policy-as-code, měřitelnost, soulad s regulacemi a uživatelskou přívětivost zajišťuje, že přístup je nejen bezpečný a auditovatelný, ale také škálovatelný a udržitelný v dynamickém hybridním a cloud-native prostředí.