Biztonsági architektúra

Borítékolt mező-titkosítás

Az érzékeny mezők (ügyfélnevek, e-mail címek, telefonszámok, ügy- és kapcsolattartó-adatok) nem nyers szövegként tárolódnak, hanem mezőnként hitelesített titkosítással: AES-256-GCM. A GCM hitelesítő címkéje az integritást is védi, a rejtjelezett érték észrevétlenül nem módosítható.

A kulcskezelés borítékolt: minden iroda (tenant) saját 256 bites adatkulcsot kap, amelyet egy, az adatbázison és a kódtáron kívül tárolt fő kulcs borítékol. Az irodánkénti kulcsból HKDF származtat két alkulcsot: egyet a titkosításhoz, egyet a kereső-indexhez. Adat és kulcs így fizikailag soha nincs egy helyen, és az irodák adatai kulcs-szinten is elkülönülnek.

Algoritmus

AES-256-GCM, mezőnkénti véletlen nonce-szal, hitelesítő címkével.

Tárolt formátum

v1: verzió-prefix + Base64(nonce | hitelesítő címke | rejtjel). Prefix nélküli, titkosítatlan értéket a visszafejtő nem fogad el.

Kulcs-hierarchia

Fő kulcs (adatbázison kívül) → irodánkénti 256 bites adatkulcs → HKDF-alkulcsok.

Izoláció

Irodánként külön kulcs: egy iroda kulcsa a másik iroda adatához matematikailag sem használható.

Vak index: keresés nyers szöveg nélkül

A titkosított mezőkre keresni is lehet, anélkül, hogy az adatbázis valaha nyers szöveget látna. A rendszer a normalizált értékből HMAC-SHA-256 kulcsolt lenyomatot (vak indexet) képez, és az egyezés-keresés ezen a lenyomaton fut. Az index kulcsa is irodánkénti, HKDF-fel származtatott alkulcs, így az index önmagában sem fejthető vissza, és irodák között nem vethető össze.

Korlát: pontos egyezés

A vak index csak normalizált (kisbetűsített, ékezet-megtartó) pontos egyezést talál; részlet- vagy hasonlóság-keresést nem szolgál ki.

Korlát: egyezés-mintázat

Azonos érték azonos lenyomatot ad, így irodán belül az látható, hogy két rekord mezője egyezik - maga az érték nem. Ez a determinisztikus kereshetőség szükségszerű ára.

Jelszavak és munkamenet

A jelszavakat Argon2id memóriakemény hash védi, visszafejthető formában soha nem tárolódnak. Belépéskor a munkamenet-azonosító cserélődik (session fixation ellen), a munkamenet-cookie HttpOnly és SameSite=Lax beállítású, élesben Secure jelzővel. A tartós belépés (emlékezz rám) tokenje az adatbázisban csak hash-elve szerepel.

Belépés-védelem

Próbálkozás-korlát

Iroda + e-mail + IP hármasra: 5 hibás kísérlet után 15 perc zárolás.

Letiltott fiók

A letiltás kérésenként újraellenőrződik: az élő munkamenet is azonnal megszakad.

Jelszó-visszaállítás

64 hexjegyű véletlen token, az adatbázisban hash-elve, egyszer használatos, lejárattal.

Kétlépcsős belépés (2FA)

Minden felhasználó bekapcsolhatja az időalapú egyszeri kódos (TOTP) kétlépcsős belépést a szokásos hitelesítő alkalmazásokkal. A TOTP-titok a szerveren az iroda kulcsával titkosítva tárolódik, a nyolc egyszer használatos visszaállító kód pedig csak SHA-256 lenyomatként. A kód-ellenőrzés próbálkozás-korlátos (5 hibás kód után 15 perc zárolás), a jelszó utáni 2FA-lépés 5 perc után lejár.

Kérés-szintű védelem

Minden állapot-módosító (POST) kérést központi CSRF-védelem kapuz: token nélkül vagy hibás tokennel a kérés 419-cel elutasításra kerül. Minden erőforrás-hozzáférés iroda- és szülő-hatókörrel szűrt (IDOR ellen): egy tétel csak a saját irodáján és saját szülő-rekordján keresztül érhető el.

Content-Security-Policy

Szigorú forrás-lista: csak saját kiszolgáló és a nevesített betűtípus-/CDN-források.

HSTS

HTTPS kikényszerítése a böngésző szintjén.

Egyéb headerek

nosniff, X-Frame-Options: DENY, Referrer-Policy.

Audit-napló

A belépések (sikeres, tartós és kétlépcsős), a sikertelen 2FA-kísérletek, valamint minden lényeges írás-művelet (ügyfél, ügy, időbejegyzés, díjelszámoló, díjszabás, felhasználó, beállítás) naplózódik: ki, mit, mikor és melyik IP-címről. A naplót az iroda adminisztrátora az alkalmazásban szűrhetően visszanézheti; a bejegyzések érzékeny adatot nem tartalmaznak, csak azonosítókat.

Titkosított mentések

Az adatbázisról naponta automatikus mentés készül, amely AES-256 titkosítással (PBKDF2 kulcs-deriválással) tárolódik. A mentési kulcs a mentésektől és az adatbázistól elkülönítve él, a mentések 14 nap után automatikusan törlődnek. A mentett állomány a mező-titkosítás miatt eleve csak rejtjelezett érzékeny adatot tartalmaz - a mentés-titkosítás erre tesz még egy réteget.

Kulcs-rotáció

Az irodánkénti kulcsok parancssori eszközzel rotálhatók: az újratitkosítás irodánként, tranzakcióban fut, éles módosítás előtt dry-run móddal ellenőrizhető. Rotáció után a régi kulccsal titkosított adat már nem olvasható, a folyamat az indexeket is újraképzi.

Incidenskezelés

Biztonsági incidens esetén írásos eljárásrend szerint járunk el: azonnali elszigetelés (fiók-zárolás, token-érvénytelenítés, szükség esetén kulcs-rotáció), hatásfelmérés az audit-napló alapján, majd bejelentés. Adatvédelmi incidensnél az érintett irodákat indokolatlan késedelem nélkül értesítjük, hogy a GDPR szerinti 72 órás hatósági bejelentési határidejüket tartani tudják; a helyreállítás a titkosított mentésekből történik.

Sebezhetőség bejelentése

Ha biztonsági hibát találsz a LexTime-ban, kérjük, jelezd a kapcsolati űrlapon vagy a security.txt-ben megadott csatornán. 72 órán belül érdemben válaszolunk, és a felelős közzétételt kérjük: a javításig ne hozd nyilvánosságra a részleteket.