Autentizace a autorizace

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

Autentizace a autorizace jsou dvě vzájemně provázané discipliny, 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í, risk skóre).
• 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 z různých faktorů. Phishing-resistant MFA (FIDO2/WebAuthn s platformním nebo bezpečnostním klíčem) eliminuje přenos tajemství na útočníka a váže přihlášení na původ domény.

Moderní metody autentizace

• Hesla + správné ukládání – hashování s salt a paměťově náročnými funkcemi (bcrypt, scrypt, Argon2), ideálně i pepper v HSM.
• TOTP/HOTP – jednorázové kódy z mobilních aplikací či HW tokenů; nutná ochrana seedů.
• Push a číslicové výzvy – minimalizace „MFA fatigue“ pomocí ověřených detailů žádosti (číslo/poloha/zdroj).
• FIDO2/WebAuthn (passkeys) – asynchronní kryptografie, klíče pá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 – ticket-based autentizace v doménových prostředích s delegací (S4U) a omezením Ticket Lifetime.
• 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 enterprise SSO mezi IdP a SP.
• OpenID Connect (OIDC) – identita na OAuth 2.0 (ID Token s claims), vhodné pro web/mobile moderní aplikace.
• OAuth 2.0 – autorizace (delegace přístupu) s Access Tokeny; není to 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, čas, zařízení, posture, anomálie) a dynamicky vyžaduje step-up faktor. 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é: expirace, audience, issuer, nonce, rotace refresh tokenů, revokace a introspekce.
• Správa relací – httpOnly a Secure cookies, SameSite, ochrana proti fixaci relace, pravidelná obnova (reauth), detekce souběžných relací.
• Úložiště klíčů – KMS/HSM pro podepisovací klíče, rotace a verze (kid), publish přes JWKS.

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

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

Architektura rozhodování o přístupu

Typický tok: PEP zachytí požadavek → získá kontext od PIP (atributy, skupiny, device posture) → pošle dotaz do PDP (hodnotí 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 hodnocením při každé citlivé operaci (just-in-time autorizace).

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í, ověřovaným průběžně. Least Privilege a Separation of Duties se uplatní v politikách, schvalováních a vyloučení rizik kumulace oprávnění.

Privilegované přístupy (PAM)

• JIT/JEA – dočasné privilegované přístupy, granularita na příkaz/operaci.
• Trezor tajemství – rotace účtů typu break-glass, kontrolované checkouty, záznam relací.
• Schvalovací workflow – víceúrovňové, auditované s napojením na tiketovací systémy.

API a služební identity v mikroservisách

Pro komunikaci služba-služba 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 aplikuje PEP s politikami (OPA, Rego) a vynucuje mTLS na síťové vrstvě.

Zařízení, IoT a neosobní identity

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

Správa životního cyklu identit

• Joiner-Mover-Leaver – automatizované přidělování/změny/odebírání přístupů dle 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ř. schvaluje i vytváří platby).

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

• Hashování hesel – Argon2id s vhodnými parametry (paměť, iterace), unikátní salting a oddělený pepper.
• Rate limiting a lockout – progresivní zpoždění, detekce credential stuffing (přes telemetrii).
• Detekce kompromitovaných přihlašovacích údajů – porovnání proti známým únikům, vynucení změny.
• Čisté UX – minimalizace zadávání hesel (SSO, passkeys), bezpečné self-service reset s více kanály ověření.

Bezpečnostní hrozby a mitigace

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

Soukromí a regulace: Privacy-by-Design

Politiky a implementace musí respektovat minimální sběr 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é s řízeným přístupem.

Dostupnost, škálování a odolnost

• Vysoká dostupnost – více aktivních IdP/PDP instancí, geo-redundance, quorum pro klíče.
• Performance – cache rozhodnutí (odpovědi PDP), lokální enforcement, asynchronní obohacení 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 step-up požadavků.
• Abnormal Login Rate, míra blokovaných útoků, kompletnost 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. MFA strategie – preferovat FIDO2/WebAuthn; TOTP/push jako záložní kanál; výjimky minimalizovat.
4. Policy-as-Code – centralizovaný PDP s OPA/Rego, testy politik a CI/CD s peer-review.
5. PAM – JIT/JEA, trezor tajemství, silné schvalování a audit relací.
6. Monitorování a reakce – SIEM, detekce anomálií, SOAR playbooky (blokace, reset tajemství, izolace).
7. UX a inkluze – self-service, podpůrné kanály pro recovery (silné), minimalizace frikce 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ů.
• Dlouhožijící bearer tokeny 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ý UX vs. bezpečnost – přehnané friction vede k obcházení politik.
• Nedostatečná správa klíčů, chybějící rotace a absence key versioningu.

Závěr

Úspěšná IAM strategie 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 i škálovatelný a udržitelný v dynamickém hybridním a cloud-native prostředí.