Ugrás a fő tartalomra

Adatbázis-titkosítás

A Libre WebUI alkalmazásszintű titkosítási szolgáltatást tartalmaz, amely az érzékeny értékeket a tárolás előtt titkosítja.

Titkosítási módszer​

A backend a Node.js crypto modulján keresztül AES-256-GCM-et használ. A titkosítási kulcsnak 32 bájtosnak kell lennie, 64 karakteres hexadecimális karakterláncként ábrázolva:

ENCRYPTION_KEY=0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef

Kulcs létrehozása:

openssl rand -hex 32

Kulcstárolás​

A Libre WebUI a következő sorrendben tölti be a kulcsot:

  1. ENCRYPTION_KEY a környezetből.
  2. A kiválasztott DATA_DIR alatt tartósan tárolt .encryption_key fájl.
  3. Csak új tárolónál egy frissen létrehozott kulcs, amely az adatbázis indulása előtt tartósan a DATA_DIR/.encryption_key fájlba íródik.

Ha a környezet és a tartós fájl is megad kulcsot, azoknak egyezniük kell, különben az indítás meghiúsul. Az eredeti kulcsa nélküli meglévő titkosított állapot szintén biztonságosan meghiúsul; a Libre soha nem hoz létre helyettesítő kulcsot meglévő tárolóhoz.

Fontos kulcsszabályok​

  • Az ENCRYPTION_KEY értékéről az adatbázissal együtt készítsen biztonsági mentést.
  • Ne cserélje a kulcsot a titkosított értékek migrációs terve nélkül.
  • A kulcs elvesztése esetén a titkosított értékek nem állíthatók helyre.
  • A kulcs módosítása az adatok újratitkosítása nélkül olvashatatlanná teszi a meglévő titkosított értékeket.

Mit véd ez?​

A titkosítást a titkosítási szolgáltatást vagy a titkosított tárolási segédfüggvényeket használó kódutak alkalmazzák. Olyan érzékeny alkalmazásértékekhez készült, mint a hitelesítő adatok és az e segédfüggvények által kezelt személyes felhasználói adatok.

Ez nem teljes lemeztitkosítás, SQLite-oldaltitkosítás vagy a felhasználó és a böngésző közötti végpontok közötti titkosítás. Ezekhez a rétegekhez használjon lemeztitkosítást és HTTPS-t.

Work-adatok​

Az alkalmazásszintű titkosítás nem titkosít egy teljes Work-feladatot. A Work forrásfájljai és projektfüggőségei közönséges fájlok a feladathoz tartozó elnevezett Docker-kötetekben. A Work-beszélgetések, eszközeredmények, parancskimenetek és feladatmetaadatok SQLite-ban tárolódnak, és nem lesznek automatikusan titkosítva pusztán azért, mert egyes hitelesítőadat-tárolási utak használják a titkosítási szolgáltatást.

Szükség esetén hozzáférés-vezérléssel és lemeztitkosítással védje a Docker adatgyökerét és a DATA_DIR könyvtárat. Az adatbázisról, az ENCRYPTION_KEY értékéről és a kezelt Work-kötetekről együtt készítsen biztonsági mentést. Egy Work-feladat távoli modellnek küldése a beszélgetés környezetét, valamint a kért fájl- vagy parancskimenetet is felfedheti a szolgáltató előtt; a tárolási titkosítás nem változtatja meg ezt a hálózati határt.

Docker és Kubernetes​

Éles környezetben kifejezetten állítson be stabil kulcsot:

ENCRYPTION_KEY=replace-with-64-hex-characters
DATA_DIR=/data

A DATA_DIR könyvtárat tartós tárolóra csatolja. Kubernetesben a kulcsot Secretben tárolja, az adatokat pedig PersistentVolume-ra csatolja.

Hibaelhárítás​

Érvénytelen kulcshossz

A kulcsnak pontosan 64 hexadecimális karakterből kell állnia. Új kulcs létrehozása:

openssl rand -hex 32

Az adatok az újratelepítés után nem fejthetők vissza

Ellenőrizze, hogy ugyanaz az ENCRYPTION_KEY van használatban, és ugyanaz a DATA_DIR kötet van csatolva.

A fejlesztési környezet új kulcsot hozott létre

A DATA_DIR/.encryption_key fájlt tartsa együtt az adatbázissal. Ugyanezt az értéket az ENCRYPTION_KEY segítségével is beállíthatja; ha mindkét forrás létezik, egyezniük kell.

Kapcsolódó dokumentáció​