# Auditní stopa (https://docs.vitrinka.ai/cs/security/audit) ## Jedna tabulka [#table] Bezpečnostně relevantní události — přihlášení a zamítnuté pokusy, souhlasy a odvolání konektorů, sdílené odkazy, použití nouzového přístupu, odmítnutí vynuceným SSO, udělení role platformního admina, zničení klíče — se přidávají do jedné tabulky `audit_log` v řídicí databázi, v hostované službě i na vlastní instalaci stejně. | Sloupec | Význam | | ------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `ts` | Kdy, v UTC. | | `org_id`, `workspace_id` | Rozsah, ke kterému událost patří. | | `actor_kind`, `actor_id`, `actor_label` | Kdo — uživatel, token, konektor, pravidlo — a jak se v tu chvíli jmenoval. | | `on_behalf_of` | Uživatel, za kterého agent nebo token jednal, pokud se liší od aktéra. | | `action` | Co se stalo. | | `target_kind`, `target_id`, `target_label` | S čím, a jak se to v tu chvíli jmenovalo. | | `result` | Povoleno nebo zamítnuto. | | `ip`, `user_agent` | Odkud — zaznamenává se u akcí člověka; řádky tokenů a agentů místo toho uvádějí pověření. Adresa je hlavička `X-Real-Ip`, kterou předává vaše reverzní proxy, převzatá jen z loopbacku nebo od proxy uvedené ve `VITRINKA_TRUSTED_PROXIES`; od jakéhokoli jiného protějšku se hlavička ignoruje a zapíše se adresa samotného spojení, takže volající nemůže do logu zapsat libovolnou adresu. Ať proxy tuto hlavičku vždy přepíše, a pokud k serveru vede přes síť, uveďte ji — jinak sloupec obsahuje adresu proxy. | | `detail` | JSON objekt s podrobnostmi události, očištěný od tajemství. | ## Jen přidávání, ve stejné transakci [#append] Dva SQLite triggery, `audit_log_no_update` a `audit_log_no_delete`, přeruší každý `UPDATE` nebo `DELETE` nad tabulkou, takže úpravu přes SQL odmítá sama databáze. Řádky se zapisují uvnitř transakce volajícího: akce a její auditní řádek se potvrdí spolu, nebo vůbec, a zamítnutý pokus nechá svůj řádek, i když se nic jiného nezměnilo. Stopa se drží po celý život organizace a nepodléhá [lhůtám uchovávání](/cs/security/retention#control). Triggery vážou databázi, ne toho, kdo drží její soubor: [export](#export) kopíruje stopu mimo hostitele jako hashem řetězené, podepsané dávky, které `vitrinka audit-verify` ověří offline. ## Export mimo hostitele [#export] `VITRINKA_AUDIT_EXPORT` posílá stopu tam, kde ji hostitel nemůže přepsat: každých `VITRINKA_AUDIT_EXPORT_EVERY` exportér vezme řádky od poslední dávky, zapíše je jako jeden objekt JSONL, ve kterém každý řádek nese SHA-256 řádku před ním i vlastního obsahu, dávku podepíše klíčem Ed25519 instalace a uloží ji do cíle. Cílem hostované služby je bucket objektového úložiště s object lockem; odpojená instalace používá místní adresář jen pro zápis. Neúspěšný export se zapíše do logu a započítá — `vitrinka_audit_export_failures_total`, a od druhého selhání v řadě `vitrinka_audit_export_repeat_failures_total`, na který se vyplatí budit, oba na listeneru `VITRINKA_METRICS_ADDR`; řádky zůstávají v tabulce a odejdou s další dávkou. | Proměnná | Výchozí | Poznámky | | ----------------------------------------------------------------------------------------------------------------------------------------- | --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `VITRINKA_AUDIT_EXPORT` | `off` | `off`, `dir` nebo `s3`. | | `VITRINKA_AUDIT_EXPORT_DIR` | `DATA_DIR/audit-worm` | Adresář jen pro zápis pro `dir`. | | `VITRINKA_AUDIT_EXPORT_S3_ENDPOINT` `VITRINKA_AUDIT_EXPORT_S3_REGION` `VITRINKA_AUDIT_EXPORT_S3_BUCKET` `VITRINKA_AUDIT_EXPORT_S3_PREFIX` | — | Bucket pro `s3`. Zapněte object lock a verzování, aby dávku nešlo nahradit. | | `VITRINKA_AUDIT_EXPORT_S3_ACCESS_KEY_ID` `VITRINKA_AUDIT_EXPORT_S3_SECRET_ACCESS_KEY` | — | Přihlašovací údaje, které smějí ukládat, ale ne mazat. Tajné. | | `VITRINKA_AUDIT_EXPORT_EVERY` | `5m` | Jak často se zapisuje dávka. | | `VITRINKA_AUDIT_EXPORT_RETAIN_DAYS` | — | Jen `s3`: otiskne na každou dávku retenci Object Locku v režimu compliance na daný počet dní a po uložení ji zpětně přečte — bucket, který zámek ignoruje, export shodí. Nenastavená nic neotiskne a retenci nechá na výchozím nastavení bucketu. Cíl `dir` nikdy nic neexpiruje. | `vitrinka audit-verify` přečte uložený export od začátku do konce, zkontroluje každý hashový článek a každý podpis a porovná řetěz se živou tabulkou, kde je dostupná; při prvním přerušeném článku skončí nenulově a pojmenuje ho. Ověření offline kopie potřebuje veřejný podpisový klíč instalace, který vypíše `vitrinka audit-export-key` — uchovávejte jeho kopii mimo hostitele, aby ověřovatel nikdy nemusel věřit stroji, který kontroluje. ```bash vitrinka audit-export-key -data /data # vypíše veřejný podpisový klíč vitrinka audit-verify -data /data # živá tabulka proti exportnímu cíli z prostředí vitrinka audit-verify -dir /mnt/audit-worm -key /root/audit.pub # samostatná offline kopie; -key bere base64 nebo soubor vitrinka audit-verify -dir /mnt/audit-worm -key /root/audit.pub -from-hash # navázat částečnou kontrolu od známého dobrého článku ``` Postup obnovy — mezera po výpadku, odrotovaný podpisový klíč, bucket, který přišel o lock — je runbook `docs/runbooks/audit-export.md` ve zdrojovém repozitáři. ## Čtení [#read] Stopa je v produktu pod **Nastavení → Organizace → Audit log** a na `GET /api/v1/audit`, vždy v rozsahu volajícího ve workspace, na který se obrací: admin workspace vidí tento workspace a k tomu vlastní akce na úrovni účtu, třeba přihlášení, admin organizace navíc vidí vlastní události organizace, platformní admin vidí všechno a všichni ostatní jen své vlastní akce. Filtry: `actor`, `action`, `target`, `from` a `to` (RFC 3339), `q` pro volný text nad označením aktérů, akcemi, cíli a detailem s tolerancí překlepů, `limit` a `cursor` pro stránkování.