4.5. Autentizace a zabezpečení

4.5.1. Metody autentizace

Elza podporuje tyto metody autentizace:

Interní účty - uživatelé a hesla uložená v Elze (vždy k dispozici).
Active Directory (LDAP) - jméno a heslo uživatele se ověří vůči doméně Active Directory.
Kerberos (SPNEGO) - jednotné přihlášení (SSO) v doméně Windows, volitelně i ověření jména a hesla vůči KDC.
SSO hlavička - reverzní proxy, která uživatele ověřila, předá jeho uživatelské jméno v HTTP hlavičce.
OAuth2 / JWT - požadavky nesou token (bearer) vydaný poskytovatelem identit.
Osobní API klíče - pro integrace volající rozhraní REST.

Metody lze kombinovat. Při přihlášení jménem a heslem (přihlašovací formulář nebo HTTP Basic) se zkoušejí v tomto pořadí: Active Directory, Kerberos, interní heslo. Platí první metoda, která heslo přijme.

Kromě OAuth2 všechny metody pouze ověřují identitu: uživatel musí v Elze již existovat se stejným uživatelským jménem a musí být aktivní. Uživatelé se nezakládají automaticky a skupiny ani role z adresářové služby se nepoužívají; oprávnění se vždy přidělují v Elze.

4.5.2. První administrátor

Dokud databáze neobsahuje žádného uživatele, nabízí aplikace Úvodní nastavení, které založí prvního administrátora; viz První administrátor. Jeho endpointy (/api/v1/setup) jsou dostupné bez přihlášení a uživatele založí, jen dokud žádný uživatel neexistuje. Do té doby může prvního administrátora založit kdokoli, kdo se k aplikaci dostane; založte jej proto dříve, než aplikaci zpřístupníte v síti. Jakmile existuje jakýkoli uživatel, je úvodní nastavení trvale uzavřeno.

Uživatele lze nastavit také v konfiguraci, v seznamu elza.security.override; viz Uživatelé z konfigurace. Seznam se uplatní při každém startu: chybějící uživatel se založí jako administrátor bez hesla v databázi, deaktivovaný uživatel se aktivuje a heslo existujícího uživatele v databázi se nemění. Uvedený uživatel se přihlásí svým vlastním heslem nebo heslem z konfigurace. Heslo z konfigurace je prostý text a platí vedle vlastního hesla uživatele; položku odstraňte, jakmile ji nepotřebujete.

4.5.3. Výchozí uživatel

Nová instalace obsahuje vestavěného uživatele admin s heslem admin a oprávněním administrátora. Existuje pouze v konfiguraci, nikoli v databázi, a je dostupný, dokud v databázi neexistuje uživatel stejného jména.

Varování

Výchozího uživatele vypněte, jakmile existují účty administrátorů:

elza:
  security:
    allowDefaultUser: false

Výchozí uživatel se rozpoznává pouze podle jména. Dokud je zapnutý, metody SSO hlavička, Kerberos, Active Directory a OAuth2 přijmou identitu admin bez hesla a přidělí jí oprávnění administrátora. Při použití kterékoli z těchto metod výchozího uživatele vždy vypněte. Dokud je výchozí uživatel zapnutý, nezakládejte ani databázového uživatele se jménem admin: jeho vlastní heslo a oprávnění by byly ignorovány.

Klíč	Výchozí hodnota	Význam
`elza.security.allowDefaultUser`	`true`	Zapíná výchozího uživatele.
`elza.security.defaultUsername`	`admin`	Jméno výchozího uživatele.
`elza.security.defaultPassword`	hash hesla `admin`	Heslo výchozího uživatele jako zakódovaný hash (`{bcrypt}...`), nikoli jako prostý text.

4.5.4. Interní účty a hesla

Uživatelé se zakládají v modulu Administrace > Uživatelé. Hesla se ukládají jako hash bcrypt. Hesla ze starých verzí uložená pomocí SHA-256 se převedou na bcrypt při dalším přihlášení uživatele heslem.

Když se deaktivovaný uživatel přihlásí správným heslem, přihlašovací formulář oznámí, že je účet deaktivovaný. Při chybném hesle formulář zobrazí stejnou zprávu jako pro neznámého uživatele („Neplatné uživatelské jméno nebo heslo“), takže neprozradí, zda účet existuje nebo je deaktivovaný.

elza.security.salt slouží pouze k ověření těchto starých hashů SHA-256. Neměňte jej: uživatelé, jejichž heslo ještě nebylo převedeno, by se už nemohli přihlásit a administrátor by jim musel heslo nastavit znovu.

Uživatele, kteří mají heslo stále ve starém formátu (od aktualizace se heslem nepřihlásili), vypíše dotaz:

SELECT u.username FROM usr_user u
JOIN usr_authentication a ON a.user_id = u.user_id
WHERE a.auth_type = 'PASSWORD' AND a.auth_value NOT LIKE '{%';

Pravidla pro hesla

Pravidla pro interní hesla se nastavují v Administrace > Uživatelé > Pravidla pro hesla; tlačítko vyžaduje oprávnění Správa oprávnění a uživatelů (nebo oprávnění administrátora). Pravidla platí pro celou instanci:

Platnost hesla (dní): Jak dlouho heslo platí od svého nastavení.
Minimální délka hesla: Minimální počet znaků.
Minimální počet skupin znaků: Z kolika ze čtyř skupin - malá písmena, velká písmena, číslice, ostatní znaky - musí heslo obsahovat alespoň jeden znak (1-4).

Prázdná hodnota nebo 0 pravidlo vypíná; nová instalace má všechna pravidla vypnutá. Prázdné heslo se nepřijme nikdy.

Délka a skupiny znaků se kontrolují při každém nastavení hesla: když si uživatel mění vlastní heslo, když administrátor nastavuje heslo uživatele a když se uživatel zakládá nebo upravuje s novým heslem. Administrátoři nejsou výjimkou; nepřijme se ani slabé dočasné heslo. Existující hesla se nekontrolují, dokud se nezmění.

Platnost se počítá od okamžiku posledního nastavení hesla. Převod starého hashe SHA-256 při přihlášení heslo nemění a lhůtu znovu nespouští.

Varování

Hesla nastavená před aktualizací na verzi s pravidly pro hesla se počítají jako nastavená 1. 1. 2016. Zapnutí platnosti proto způsobí, že všechna hesla nezměněná od aktualizace okamžitě expirují: každý takový uživatel si musí heslo při příštím přihlášení změnit.

Expirované heslo a vyžadovaná změna hesla

Když administrátor nastavuje heslo uživatele (Administrace > Uživatelé > Změnit heslo), jsou k dispozici dvě volby:

Vyžadovat změnu hesla při dalším přihlášení: Typicky pro dočasné heslo předávané uživateli.
Heslo bez expirace: Vyjme účet z platnosti hesla, například technický účet.

Po přihlášení interním heslem, které expirovalo nebo jehož změna je vyžadována, je přihlášení úspěšné a aplikace otevře dialog, který nelze zavřít, dokud uživatel nenastaví nové heslo. Nové heslo musí splňovat pravidla. Po změně se požadavek zruší a lhůta platnosti začne znovu.

Změnu hesla vynucuje pouze webový klient. Požadavky na rozhraní REST v takové session blokovány nejsou.

Platnost a vyžadovaná změna se týkají jen přihlášení interním heslem. Uživatelé přihlášení přes Active Directory, Kerberos, SSO hlavičku, OAuth2 nebo API klíč nejsou ke změně hesla nikdy vyzváni; pokud hesla ověřuje Active Directory nebo Kerberos, použije se interní heslo jen tehdy, když doména heslo odmítne. Vyzván není ani výchozí uživatel: jeho heslo se nastavuje jen v konfiguraci (elza.security.defaultPassword) a v aplikaci je změnit nelze.

Obnovení přístupu k účtu

Pokud administrátor zapomněl heslo a žádný jiný administrátor mu nemůže nastavit nové, obnoví se přístup pomocí uživatelů z konfigurace (viz Uživatelé z konfigurace):

Přidejte uživatele s dočasným heslem do elza.security.override v elza.yaml a restartujte Elzu. Deaktivovaný uživatel se aktivuje; vlastní heslo uživatele v databázi se nemění.
Přihlaste se dočasným heslem a změňte heslo v aplikaci.
Odstraňte položku z elza.yaml a restartujte Elzu. Do té doby platí dočasné heslo vedle nového.

Bezpečnostní auditní log zaznamená, že je dočasné heslo aktivní (override_active), a každé přihlášení jím (authentication_type OVERRIDE). Výchozí uživatel se tímto způsobem neobnovuje; jeho heslo se nastavuje v konfiguraci (elza.security.defaultPassword).

4.5.5. Active Directory

elza:
  security:
    ldap:
      ad-domain: archiv.example
      ad-server: ldap://dc1.archiv.example/

ad-domain: Doména Active Directory. Jejím nastavením se metoda zapne.
ad-server: URL řadiče domény.

Uživatel se přihlašuje doménovým jménem a heslem. Poté, co doména heslo přijme, Elza vyhledá uživatele podle zadaného jména; uživatele v Elze zakládejte se stejnými jmény jako v doméně. Pokud doména heslo odmítne, zkusí se interní heslo.

Při nastaveném Active Directory kontroluje kontrola stavu (viz Monitorování) i spojení s řadičem domény.

4.5.6. Kerberos (SPNEGO)

elza:
  security:
    kerberos:
      service-principal: HTTP/elza.archiv.example@ARCHIV.EXAMPLE
      keytab-location: /etc/elza/elza.keytab
      authenticate-with-password: true

service-principal: Jméno služby (SPN) aplikace Elza. Jeho nastavením se metoda zapne.
keytab-location: Cesta k souboru keytab s klíčem služby. Soubor smí číst pouze uživatel, pod kterým běží služba.
authenticate-with-password: Ověřovat jména a hesla z přihlašovacího formuláře také vůči KDC (výchozí true).
kerberos-client-debug, ticket-validator-debug: Ladicí výpisy klienta Kerberos a ověřování ticketů (výchozí false).

Konfigurace Kerberos pro JVM (realm a KDC, krb5.conf) se přebírá z operačního systému nebo z nastavení Javy.

Při nastaveném Kerberos nabízí přihlašovací dialog jednotné přihlášení. Prohlížeč se pak ověří doménovým ticketem uživatele; pro adresu Elzy musí mít povolenou integrovanou autentizaci. Z principalu se odstraní realm a uživatel se vyhledá podle zbytku jména (jan.novak@ARCHIV.EXAMPLE se změní na jan.novak). Samotný realm se nekontroluje. Pokud jednotné přihlášení selže, uživatel se může přihlásit formulářem.

4.5.7. SSO hlavička

Reverzní proxy nebo přístupová brána, která uživatele ověřuje, může předávat uživatelské jméno v HTTP hlavičce:

elza:
  security:
    allowDefaultUser: false
    sso-header:
      user-header: X-SSO-User

Elza vyhledá uživatele podle hodnoty hlavičky. Pokud hlavička uvádí jiného uživatele než aktuální session, session se nahradí.

Varování

Elza hlavičce plně důvěřuje. Řešení je bezpečné, jen pokud:

je Elza dostupná výhradně přes proxy (naslouchá na 127.0.0.1 nebo je port omezen firewallem),
proxy hlavičku u každého požadavku odstraní nebo přepíše, takže ji klient nemůže poslat sám,
je výchozí uživatel vypnutý.

Do elza.security.logoutUrl nastavte adresu odhlášení brány, aby odhlášení z Elzy ukončilo i session na bráně.

4.5.8. OAuth2 / JWT

Elza může přijímat tokeny (Authorization: Bearer ...) vydané poskytovatelem identit. Vystupuje pouze jako resource server; přesměrování na přihlášení u poskytovatele neprovádí.

elza:
  security:
    o-auth2:
      key-url: https://idp.archiv.example/oauth/token_key
      permissions:
        - authority: ELZA_ADMIN
          permissions: [ADMIN]

key-url: URL, které vrací veřejný klíč pro ověření podpisu tokenů, jako JSON s klíčem RSA ve formátu PEM v poli value. Klíč se načte jednou při startu; pokud jej nelze načíst, aplikace nenastartuje. Tokeny musí být podepsány algoritmem RS256.
permissions: Mapování hodnot z položky authorities tokenu na oprávnění Elzy. scope omezuje oprávnění na oblast archivních entit (podle kódu).
user-scope, user-ap-type: Oblast a třída archivních entit uživatelů zakládaných z tokenů; výchozí JWT_USERS a PERSON_INDIVIDUAL. Třídu musí nabízet pravidla oblasti.

Položka sub tokenu je uživatelské jméno a name zobrazované jméno. Na rozdíl od ostatních metod se neexistující uživatel založí, a to včetně archivní entity osoby v oblasti user-scope. Přímo přidělená oprávnění uživatele se nahradí oprávněními odvozenými z tokenu. Údaje o uživateli se ukládají do cache na pět minut, změna oprávnění nebo deaktivace se tedy projeví do pěti minut.

4.5.9. Osobní API klíče

Integrace volají rozhraní REST s osobním API klíčem místo hesla uživatele. Klíč patří uživateli a pracuje s jeho oprávněními; pro každou integraci založte samostatného uživatele.

Uživatelé zakládají a ruší své klíče v uživatelském nastavení (kategorie Elza). Celý klíč se zobrazí pouze jednou, při vytvoření; Elza ukládá jen jeho hash. Administrátoři mohou zobrazit a zrušit klíče ostatních uživatelů. Klíče lze zakládat a rušit jen po interaktivním přihlášení, nikoli s jiným API klíčem. Požadavek ověřený API klíčem nemůže měnit ani hesla či jiné přihlašovací údaje žádného uživatele; je odmítnut s 403.

Klíč se posílá v hlavičce:

curl -H "X-API-Key: elza_..." https://elza.archiv.example/api/v1/...

Klíč	Výchozí hodnota	Význam
`elza.security.api-keys.enabled`	`true`	Přijímat API klíče. Při `false` se hlavička ignoruje.
`elza.security.api-keys.header-name`	`X-API-Key`	Název hlavičky.
`elza.security.api-keys.default-validity-days`	365	Platnost nového klíče, pokud ji uživatel nezvolí.
`elza.security.api-keys.max-validity-days`	730	Maximální platnost klíče.

Odmítnutý klíč je zodpovězen HTTP 401 s tělem JSON uvádějícím důvod (MALFORMED_TOKEN, UNKNOWN_KEY, INVALID_SECRET, EXPIRED, REVOKED, USER_INACTIVE).

4.5.10. Bezpečnostní auditní log

Při nastaveném elza.siemLogFile (viz Konfigurace aplikace) zapisuje Elza události autentizace, uživatelských účtů a archivních souborů do samostatného logu ve formátu JSON, jedna událost na řádek, vhodného pro systém SIEM. Názvy polí odpovídají schématu OSSEC/Wazuh, takže je mohou využít vestavěná pravidla takového SIEM. Každá událost obsahuje:

Pole	Význam
`timestamp`	Čas události (ISO 8601).
`program_name`	Vždy `elza`.
`log_type`	`secure` pro autentizaci, `audit` pro změny uživatelů a jejich přístupu.
`event_type`, `action`	Druh události a operace, viz tabulka níže.
`result`	`success` nebo `failed`.
`srcuser`	Kdo akci provedl: přihlášený uživatel, nebo `configuration` pro změny provedené z `elza.security.override`, `setup` pro prvního administrátora založeného v dialogu úvodního nastavení, `system` pro uživatele založeného automaticky při prvním přihlášení JWT.
`dstuser`	Koho se akce týká; u přihlášení totéž co `srcuser`.
`srcip`	Zdrojová adresa požadavku; chybí u událostí mimo požadavek (start).
`reason`	Důvod selhání (jen při `result` = `failed`).
`msg`	Stručný popis v angličtině, např. `User martin logged in from IP 192.168.1.10.`
`details`	Volitelný technický popis selhání v angličtině, např. důvod odmítnutí JWT.
`dstgroup`	Kód skupiny, které se akce týká (oprávnění a skupiny).
`permission`, `permission_target`	Změněné oprávnění (např. `FUND_ARR`) a entita, na kterou se vztahuje, jako `typ:id` (`fund:123`, `node:456`, `scope:5`, `user:7`, `group:3`, `issue_list:9`); u globálního oprávnění cíl chybí.

Události:

`event_type`	`action`	Popis
`user_login`	`login`	Přihlášení uživatele, úspěšné nebo neúspěšné. `authentication_type` uvádí metodu (`PASSWORD`, `ACTIVE_DIRECTORY`, `KERBEROS`, `SSO_HEADER`, `JWT`, `API_KEY`, `OVERRIDE` pro heslo z `elza.security.override`), `key_id` veřejný identifikátor API klíče; obě pole jsou uvedena i při selhání. `reason` selhání: `INVALID_USERNAME` (uživatel v Elze neexistuje), `INVALID_PASSWORD`, `INACTIVE_USER`, `INVALID_CREDENTIALS` (SSO hlavička), `INVALID_TOKEN` / `TOKEN_DECODING_FAILED` (JWT), kódy API klíčů uvedené výše, nebo `AUTHENTICATION_ERROR` pro neočekávanou chybu s popisem v `details`. Neúspěšné přihlášení API klíčem nebo JWT nemá `srcuser`. JWT a API klíč se ověřují u každého požadavku, proto se jejich úspěšné přihlášení zapisuje nejvýše jednou za hodinu pro tentýž klíč (nebo uživatele) a adresu; selhání se zapisují vždy.
`user_logout`	`logout`	Odhlášení uživatele. Vypršení session se nezapisuje.
`api_key_create`	`create_api_key`	Byl založen API klíč; `key_id` a `expire_date`.
`api_key_revoke`	`revoke_api_key`	Byl zrušen API klíč (vlastníkem nebo administrátorem); `key_id`.
`user_create`	`create_user`	Uživatele založil administrátor (UI, REST, SOAP), byl založen v úvodním nastavení, automaticky při prvním přihlášení JWT, nebo při startu z `elza.security.override`.
`password_change`	`change_password`	Heslo změnil uživatel (`srcuser` = `dstuser`) nebo administrátor. Změna uživatelem selže s `reason` = `OLD_PASSWORD_MISMATCH`, pokud nesouhlasí původní heslo.
`user_activate`	`activate_user`	Účet aktivoval administrátor nebo byl aktivován při startu z `elza.security.override`. Zapisuje se jen při změně stavu.
`user_rename`	`rename_user`	Administrátor přejmenoval uživatele; `dstuser` je nové jméno, `old_username` předchozí.
`override_active`	`enable_override`	Zapisuje se při každém startu pro každého uživatele v `elza.security.override`: heslo z konfigurace platí pro uživatele (`dstuser`) vedle jeho vlastního.
`user_disable`	`disable_user`	Administrátor deaktivoval účet. Zapisuje se jen při změně stavu.
`permission_grant`, `permission_revoke`, `permission_change`	`grant_permission`, `revoke_permission`, `change_permission`	Oprávnění uživatele (`dstuser`) nebo skupiny (`dstgroup`) bylo přiděleno, odebráno nebo upraveno - administrátorem, přes SOAP, při kopírování oprávnění, autorovi nového archivního souboru, nebo z tokenu poskytovatele identit (JWT, `srcuser` = `system`; zapisují se jen skutečné změny).
`group_member_add`, `group_member_remove`	`add_group_member`, `remove_group_member`	Uživatel byl přidán do skupiny nebo z ní odebrán.
`group_create`, `group_delete`	`create_group`, `delete_group`	Skupina byla založena nebo smazána. Smazání skupiny odebere její oprávnění všem jejím členům; to se po jednotlivých členech nezapisuje.
`fund_create`	`create_fund`	Byl založen archivní soubor, ručně nebo importem (`fund_import` = `true`); `fund_id` a `fund_name`.
`fund_delete`	`delete_fund`	Archivní soubor byl smazán se všemi daty; `fund_id` a `fund_name`.
`fund_history_delete`	`delete_fund_history`	Byla smazána historie archivního souboru (staré verze a změny); `fund_id` a `fund_name`.
`config_admin`	`apply_config_admin`	Uživatele z `elza.security.override` nebylo možné uplatnit (vždy `failed`).

Log se rotuje denně a uchovává se 90 dní. Za reverzní proxy je srcip adresou klienta jen se zapnutým elza.security.acceptForwardedHeaders a proxy nastavenou podle Adresa klienta; jinak je to adresa proxy.

4.5.11. Další nastavení

Klíč	Výchozí hodnota	Význam
`elza.security.acceptForwardedHeaders`	`false`	Přijímat hlavičky `X-Forwarded-*` od reverzní proxy; nutné, pokud Elza běží pod cestou, a pro adresu klienta v bezpečnostním auditním logu (viz Provoz za reverzní proxy).
`elza.security.logoutUrl`	(nenastaveno)	Adresa, kterou prohlížeč otevře po odhlášení, například stránka odhlášení SSO brány.
`elza.security.displayUserInfo`	`true`	Zobrazovat v záhlaví aplikace nabídku uživatele.

Session vyprší po standardní době nečinnosti vloženého serveru (30 minut), kterou lze změnit klíčem server.servlet.session.timeout. Jeden uživatel může mít současně nejvýše deset session; jedenácté přihlášení ukončí nejstarší z nich.

Endpointy monitorování nevyžadují autentizaci a musí zůstat dostupné jen lokálně (viz Monitorování).