AES-256-GCM mezőszintű titkosítás, ami átmegy az audit-on
A database-wide titkosítás nem elég. Megmutatjuk, hogyan titkosítunk pontosan azokat a mezőket, amiket muszáj — és hogyan keresünk a titkosított adatban.
A rossz titkosítás rosszabb, mint a semmilyen — mert téves biztonságérzetet ad.
A legtöbb "encryption at rest" megoldás a lemezt titkosítja. Ez jó a lopott HDD ellen, de haszontalan minden más támadási modell ellen — ha a DB elérhető, a támadó minden mezőt plaintextben lát. A mezőszintű titkosítás erre válasz: minden érzékeny mező a DB-ben is titkosítva van, csak az alkalmazás tudja visszaolvasni.
A pattern rövid formában
- AES-256-GCM, mert authentikált titkosítás (integritás + titkosság)
- Minden mező saját, véletlenszerű 96-bites IV-t kap
- A kulcsot KEK → DEK hierarchiában tároljuk, a KEK KMS-ben él
- A TypeORM transformer automatikusan titkosít és dekódol
- A titkosított oszlop legalább 1024 karakteres VARCHAR (GCM overhead)
- Retrofit esetén külön migráció szélesíti az oszlopot, mielőtt titkosítunk
Hogyan keresünk titkosított mezőben
A klasszikus "nem lehet keresni, ha titkosítva van" válasz nem elég. Két mintát használunk: hash-oszlop pontos egyezéshez (például email → SHA-256 hash külön oszlopban), és blind index n-gramokkal a like-kereséshez. Egyik sem tökéletes, de ezzel ki tudjuk elégíteni a 95%-ot anélkül, hogy visszatérnénk a plaintext-hez.
Ezt a mintát a Netorigo backend és a logistics szolgáltatás már éles üzemben használja, és a migráció kevesebb mint egy nap volt mindegyikben. A 200+ érintett sort egy nap alatt átírtuk — azért, mert a TypeORM transformer az egyedüli érintkezési pont.
Kulcsrotáció: az, amit mindenki elhallgat
A titkosítás "megírása" a könnyű rész. A nehéz az, hogy 18 hónap múlva, amikor az első kulcs lejár, mit csinálsz a meglévő titkosított adattal. A mi mintánkban minden rekord rögzíti, hogy melyik KEK verzióval lett titkosítva. Új kulcs bevezetésekor egy háttér-migráció 2-3 hét alatt újratitkosít mindent, és közben a régi és új verzió is olvasható marad. A dekódolás sosem áll le, nincs downtime, nincs "maintenance window az éjszaka közepén".
Amit egy audit tényleg megkérdez
- Ki tudja dekódolni az adatot? (Válasz: csak az alkalmazás, a DBA nem)
- Hol van a KEK és ki fér hozzá? (KMS-ben, IAM policy-val)
- Hány különböző kulcsverzió van éles rendszerben? (Rögzítve a rekord-szinten)
- Mi történik egy kulcs kompromittálódása esetén? (Rotáció runbook, 24h alatt lecserélt)
- Tesztelhető-e a dekódolás vészhelyzeti visszaállításkor? (Igen, staging-en mindennap fut)
Az auditor soha nem a titkosítás matematikájára kíváncsi. A kérdés mindig a hozzáférés és a kulcskezelés. Ha ezt a két dolgot dokumentáltan és tesztelt módon megoldod, az audit 80%-a megvan.