Audit-lánc
Minden biztonsági szempontból releváns művelet kriptográfiailag láncolva. Tervezésileg manipuláció-érzékeny.
HMAC-SHA256 sor-láncolás, append-only adatbázis-trigger és bérlőnként monoton sorozat. Három független manipulációs jel a sémában, nem ráaggatva.
MIÉRT NEM EZ EGY FUNKCIÓ
Az audit-naplónk sor szinten kriptográfiailag láncolt
Egy támadó teljes adatbázis-írásjoggal sem tud sort hamisítani vagy törölni úgy, hogy ne hagyna nyomot. Ugyanaz a hash-lánc primitív, amit a blockchain főkönyvek is használnak, sor szinten alkalmazva, konszenzus-protokoll helyett HMAC-titokkal.
7 év. 2555 nap. Minden felhasználó minden biztonsági szempontból releváns művelete elkapva és ellenőrizhetően.
HOGYAN MŰKÖDIK
Három mező alakítja át a sort bizonyítékká
Az audit_logs minden sora három védő mezőt hordoz. A tábla maga köznapi; a fegyelem abban van, mit számítunk ki és írunk alá minden beszúrásnál.
sequence
Bérlőnként monoton növekvő egész szám. Egy hiány a sorozatban azt jelenti, hogy egy sor törlésre került, és a verifier kijelöli az első hiányzó számot.
prev_hash
Az előző sor row_hash értékére mutat. Megtört lánc azt jelenti, hogy valaki átrendezett vagy szabálytalanul beszúrt egy sort.
row_hash
HMAC-SHA256 a {tenant_id, sequence, prev_hash, actor_id, action, resource_type, resource_id, payload, created_at} kanonikus sorosításán, AUDIT_HMAC_KEY-vel aláírva, amit az alkalmazás tart, nem az adatbázis.
HÁROM MANIPULÁCIÓS JEL
Mit észlelünk, és hogyan
| Támadás | Amit észlelünk | Hogyan |
|---|---|---|
| Sor-módosítás | A tárolt row_hash már nem egyezik az újraszámolt HMAC-cel. | A verifier végigjárja a láncot, és minden sort újraszámol a kanonikus tartalomból. |
| Sor-törlés | Megjelenik egy sorozathiány, és a fennmaradó sor prev_hash értéke már nem egyezik a tényleges előzményével. | Sorozat-ellenőrzés és lánc-ellenőrzés; bármelyik elég az észleléshez. |
| Sor beszúrás vagy átrendezés | A beszúrt sor nem tud valós prev_hash-t hivatkozni, így a lánc a beszúrt sornál vagy az utána levőnél megszakad. | A láncbejárás az első érvénytelen hash-nél elkapja a folytonossági hibát. |
MÉLYSÉGI VÉDELEM
Három réteg, szándékosan elválasztva
Append-only kényszerítés
Egy PostgreSQL-trigger blokkol minden DELETE-et az audit_logs ellen. Csak olyan tranzakcióban lehet törölni, amely beállította a SET LOCAL app.audit_retention_cleanup = on jelzőt, amelyet kizárólag a megőrzési söprés tart. A SET LOCAL tranzakció-szintű, így a flag a commit vagy rollback hatására automatikusan törlődik, és nem szivároghat át későbbi utasításokra.
Kulcs-szétválasztás
A HMAC-titok az alkalmazás-konfigban van, nem az adatbázisban. Egy csak-olvasható adatbázis-kompromittálás nem tud érvényes sort hamisítani. Egy írás-szintű kompromittálást a következő verifier-futás kifog: a HMAC-titokkal minden sort újraszámol, és a hibákat saját audit-eseményként felszínre hozza.
A verifier függetlensége
A verifier az alkalmazás által tartott HMAC-titokkal végigjárja a bérlő láncát. Az eredmények maguk is az audit-lánc bejegyzései, így a kikapcsolt vagy kihagyott futás abban a pillanatban látszik, amikor megtörténik.
MIT NAPLÓZUNK
Minden esemény, amely az operatív nyilvántartást érinti
- 01 Minden hitelesítés: bejelentkezés, kijelentkezés, MFA-regisztráció, jelszóváltás, jelszóvisszaállítás
- 02 Minden jogosultság-művelet: szerepkör-változás, jogosultság-adás, API-kulcs létrehozása és visszavonása
- 03 Minden érzékeny admin-művelet: bérlő-beállítások, megőrzési változtatások, RLS-kontextus-felülírások
- 04 Minden munkalap-aláírás, az aláírás-tartalom SHA-256 értékével együtt
- 05 Minden előfizetési és számlázási esemény: webhook-fogadás, csomag-csere, ügyfélportál-munkamenet
- 06 Minden beolvasó-forrás konfigurációs változás
- 07 Minden SSO-konfigurációs változás
- 08 Minden export: CSV, PDF, ütemezett jelentés-kézbesítés
- 09 Minden tömeges törlés és érintetti törlési kérelem
MEGŐRZÉS
2555 nap. Független az operatív megőrzéstől.
A RetentionConfig.AUDIT_LOG_DAYS hét évig őrzi a láncot. A Tenant.data_retention_days úgy van megtervezve, hogy az operatív adatokat külön szabályozza, így a gép-telemetria konfigurálható ablakon belül törölhető, miközben az audit-lánc tovább lefedi a SOC 2 CC2.2 bizonyíték-ablakot és a pénzügyileg szomszédos megőrzési szabványokat.
MEGFELELÉSI LEKÉPEZÉS
Mire ad választ a lánc
SOC 2 CC6.1 és CC7.2
Manipuláció-érzékeny naplózás és a változáskezelés bizonyíték-nyomvonala. A láncot a SOC 2 auditor a megfigyelési időszakban végigjárja, hogy CC6.1 (logikai hozzáférés) és CC7.2 (rendszerfigyelés) teljesüljön.
ISO 27001 A.12.4
Eseménynaplózás és kezelői napló-integritás. Minden adminisztrátori művelet és kivétel a láncra kerül időbélyeggel, attribúcióval és a kanonikus tartalommal, amire reagáltak.
FDA 21 CFR Part 11 §11.10(e)
Biztonságos, számítógéppel generált, időbélyegzett audit-nyomvonalak elektronikus rekordokhoz. Minden aláírt esemény attribúciós, egyidejű, eredeti, pontos és időbélyeges, ami támogatja az ügyfél 21 CFR Part 11 validációs munkáját.
GDPR 30. cikk
Adatkezelési tevékenységek nyilvántartása. Az adatvédelmi tisztviselő igény szerint bérlőre szűkített audit-szeletet húzhat le. Az audit_logs-ban a személyes adat felhasználói azonosítóra és IP-címre korlátozott; a gazdagabb tartalmak csak az eseményrekonstrukcióhoz szükséges minimális kontextust hordozzák.
EU NIS2 irányelv
Incidens-vizsgálati bizonyíték. A tagállami CSIRT-ek és a saját kriminalisztikai csapata pontosan rekonstruálni tudja, ki mit és mikor csinált, olyan lánccal, amelynek integritása nem függ a DBA iránti bizalomtól.
A VERIFIER
Audit-naplózott audit-ellenőrzés
A lánc-verifikáció a bérlő HMAC-titokával újraszámol minden sort a kanonikus tartalom alapján, és PASS-t ad sorszámmal, vagy FAIL-t az első megtört sorszámnál. A verifier eredményei maguk is audit-lánc bejegyzések.
Ütemezés
Ma az admin verifier-végponton, igény szerint. Az ütemezett napi verifikáció a platform GA kiadásával érkezik.
Eredmény
PASS a sorszámlálóval, vagy FAIL az első sorszámmal, ahol a lánc megtört. Maga a sor bizonyítékként megmarad.
Forráskód
A verifier forráskódja elérhető, hogy az auditor végigjárhassa. Mi ott ülünk a szobában, miközben ezt teszi.
MIÉRT ERŐSEBB EZ A „VAN AUDIT-NAPLÓNK"-NÁL
A szokványos audit-naplók nem élik túl az elszánt rendszergazdát
Sima audit-tábla
Append-barát, de módosítható. Bárki, akinek írásjoga van az adatbázishoz, megváltoztathat egy sort, törölhet egy sort vagy beilleszthet egyet. Matematikai jel arra, hogy ez megtörtént, nincs.
WORM-tároló
A törlés ellen segít, a beszúrás vagy átrendezés ellen kevésbé. A tároló-szintű integritás nem fogja el azt a sort, aminek sosem kellett volna ott lennie.
Hash-láncolt napló (ez)
Matematikailag manipuláció-érzékeny. Sor szinten észleli a módosítást, törlést és beszúrást, integritás-horgonyként a szülő hash-sel.
GYAKORI KÉRDÉSEK
Mi történik a lánccal, ha egy hash nem stimmel?
A verifier FAIL-t ad vissza az első sorszámmal, ahol a lánc megtört. A sort nem töröljük, megőrizzük a bizonyítékot. A sikertelenség saját láncbejegyzésként rögzül, és a platform incidens-csatornáján kerül felszínre.
Tud-e az adatbázis-adminisztrátor a lánccal manipulálni?
Nem, kivéve, ha egyszerre (a) megtöri az append-only triggert, (b) megszerzi az adatbázison kívül élő HMAC-titkot, és (c) újraírja az érintett bérlő minden további sorát. Mindhárom lépés saját kriminalisztikai nyomot hagy.
Törölhető-e egy sor a GDPR-törlési jog miatt?
Az audit_logs személyes adata már user_id-re és IP-re minimalizált. A felhasználói rekord törlése nem törli az audit-történetet, mert ez a kezelés a 6(1)(c) jogi kötelezettségen és a (f) jogos érdeken nyugszik. A user_id hivatkozást álnévvel láthatjuk el, ha az adatvédelmi tisztviselő kéri.
Lassítja-e a lánc az írásokat?
Minden beszúrás kiszámol egy HMAC-et, és beolvas egy előző sort, mindkettő indexelt. Jellemző terhelésnél elhanyagolható költség, a verifier pedig a gyors útvonalon kívül fut.
