E-mail-tartalom és keresési tartalom titkosítása
Ha a titkosítás be van kapcsolva vagy kötelező, a MailGen a kezelt törzseket és a kapcsolódó tartalmat tulajdonoshoz kötött, titkosított formában tárolja. A felhasználó őrzi a privát kulcs biztonsági mentését. A szerver csak aktív kulcsbérlet alatt fejti vissza a tartalmat: ez ideiglenes engedély arra, hogy a tulajdonos privát kulcsát használja. Olvasd el először a kulcsbeállítást.
Egy jogosult backend és egy külső MI-szolgáltató ideiglenesen megkaphatja az olvasható tartalmat. Az indexelt keresési kifejezések kereshetők maradnak. Ez nem jelent teljes keresésiindex-titkosságot.
A meglévő tartalom átalakítása a tárolt adatok átírása előtt ellenőrzi a tulajdonjogot és a tartalom azonosságát. Nem igényel resetet. Az aktuális objektum átalakítása nem törli automatikusan a korábbi verziókat vagy a mentéseket. A kezelt átalakítás állapotához használd a titkosítási beállításokat és a Szinkronizálási központot.
Tulajdonos szerinti migráció előkészítése
A backend eszköz a mailGen/msmicroservices-architexture/scripts/email-encryption-migration.ts. Implementációs moduljai a mailGen/msmicroservices-architexture/src/lib/utils/encryption/migration/ mappában vannak. Egy Better Auth-tulajdonost leltároz és alakít át, nem a bérlő összes postafiókját.
Futtatás előtt készítsd elő:
- A pontos Better Auth tulajdonos-azonosítót és a tervezett jelentésfájl útvonalát.
- A folyamat konfigurációját a
DATABASE_URL, az S3, a KeyStore és a keresés számára, ha szükséges. A szkript nem tölti be automatikusan a.envfájlt. - A tulajdonos nyilvános kulcs-nyilvántartási bejegyzését és aktív privátkulcs-bérletét a visszafejtési és visszaolvasási ellenőrzésekhez.
- Feltételes S3-írások, amelyeket először egy külön, eldobható objektumon ellenőrizz egy S3-kompatibilis átjárón.
Hiányzó vagy zárolt tulajdonosi kulcs nyílt, függő munkát hagy. Ne hozz létre csereként új kulcsot a meglévő titkosított szöveghez. A tulajdonos alkalmazás-bejelentkezési azonosítója eltér az egyes szolgáltatói postafiók-azonosítóktól. Lásd: identitás- és tárolási fogalmak.
Leltározás és tartalom átalakítása
A mailGen/msmicroservices-architexture mappából cseréld le a tulajdonos helyőrzőjét:
node --import tsx scripts/email-encryption-migration.ts \
--owner '<Better Auth owner id>' \
--report /tmp/email-encryption-report.json
Az alapértelmezés a próbafuttatás (dry-run). Az adatok módosítása előtt olvasd el a jelentés tulajdonosát, számlálóit és a függő kategóriákat. Ha ugyanarra a tulajdonosra alkalmazod az átalakítást:
node --import tsx scripts/email-encryption-migration.ts \
--owner '<Better Auth owner id>' \
--report /tmp/email-encryption-report.json \
--apply
Az --apply módosítja a kanonikus objektumokat és a jogosult SQL- és előzménytartalmat. Nem végez resetet a postafiókon, és nem változtatja meg a megőrzési szabályokat.
| Kapcsoló | Szerződés |
|---|---|
--owner | Kötelező Better Auth tulajdonos-azonosító |
--report | Kötelező jelentésfájlnév. Az eszköz létrehozza a szülőmappát |
--apply | Írások alkalmazása. Alapértelmezés: hamis |
--dry-run | Explicit olvasási és leltározási mód. Nem kombinálható az --apply kapcsolóval |
--backfill-search | Keresés újraépítése a kanonikus tartalomból. Megköveteli az --apply kapcsolót, egy friss célt és aktív tulajdonosi feloldást |
--search-index | Friss indexalap a keresési visszatöltéshez. Minta: ^[a-z0-9_][a-z0-9_.-]{0,200}$ |
Az eszköz a jelentést ideiglenes fájlon keresztül, atomi módon írja ki. A tulajdonos hatókörét, a számlálókat és a függő munkát jelenti, törzstartalmat vagy kulcstitkot nem.
Átalakítási garanciák és korlátok
A leltár lefedi a kanonikus HTML-t, az egyedi törzs-melléklet sidecar fájlokat, a nyers FastTransfer-bájtokat, a régi törzsobjektumokat, az SQL-törzseket és előnézeteket, valamint a megőrzött előzményműveletek jogosult részét. Lefedi az automatikus válasz javaslatait és döntéseit, az átiratokat, a szolgáltatói előzményeket és az események payloadjait. Az aktív parancsok és naplók függőben maradhatnak, hogy megőrizzék a worker revízióit.
Egy objektumnál az átalakító ugyanabból az olvasásból kapja a bájtokat és az ETagot. Titkosítja és visszafejti a jelöltet az összehasonlításhoz. Ezután titkosított átmeneti objektumot ír. Ezt visszaolvassa, és ellenőrzi a visszafejtett bájtokat. Csak ezek után céloz egy If-Match írás az eredeti ETagra. Utána újra olvassa és ellenőrzi a kanonikus objektumot.
Egy párhuzamos módosítás függő munkává válik, nem vakon felülírt adat. A bináris FastTransfer-tartalom bájtként marad meg. A hibás titkosítási boríték hibát ad, és nem esik vissza titkosítatlan szövegre.
Az SQL-törzstartalom csak akkor ürül ki, ha egy ellenőrzött kanonikus másolat azonos titkosítatlan bájtokat tartalmaz. A feltételes frissítési feltételek megőrzik a párhuzamos sormódosításokat. Egy objektum-mutató nélküli törzs ellenőrzött, változatlan objektumot és feltételes mutatófrissítést kap. Ha ez a frissítés sikertelen, a többletobjektum megmarad. Az egyedi törzs SQL-tartalma csak akkor ürül, ha a bájtra azonos sidecar átmegy az ellenőrzésein.
A megőrzött, lezárt outbox- és admission-előzmények az eredeti PostgreSQL JSONB szöveges bájtjait titkosított tárolóban tartják. Az engedélyezett visszafejtés után az aláírás-ellenőrzés ugyanezeket a bájtokat kapja. Az átalakítás nem cseréli le az eredeti aláírást vagy digestet. A lezárt parancs-jogosultság a payload.operationId azonosította műveletet ellenőrzi, nem az outbox-esemény azonosítóját. Az írás újra ellenőrzi a lezárt állapotot és a várt tárolt értéket.
Az automatikus válasz elágazása a megbízható chat.forked eredeten keresztül örökli a tulajdonosi hatókört. Az actornak, a bérlőnek és a fióknak egyeznie kell. A ciklus- és mélységellenőrzések az eredetet 32 szintre korlátozzák. A megbízható eredet nélküli régi elágazásokat külön kell átvizsgálni.
Minden újrafuttatás újra leltározza az aktuális tartalmat, beleértve a már titkosított objektumok visszafejtési ellenőrzését is. Egy korábbi sikeres futás nem teszi automatikusan teljessé a később módosult objektumot.
| Kilépési kód | Jelentés |
|---|---|
0 | A szkript befejeződött, nincs jelentett függő lefedettség és nincs futásidejű hiba |
2 | Jelentett függő lefedettség vagy párhuzamos módosítási számláló maradt |
1 | Futásidejű, konfigurációs vagy ellenőrzési hiba |
Sikeres írás vagy keresési visszatöltés után is nézd meg a jelentést. A leltár külön jelzi a böngésző-helyreállítási, a közvetítő-megőrzési és a történeti verzió- vagy mentési feladatokat. A 2 kilépési kód ezért akkor is maradhat, ha a kanonikus átalakítás sikeres. Minden kategóriát külön kezelj. Egy kilépési kód sem bizonyítja a történeti biztonságos törlést.
Keresési projekció visszaállítása
A keresési projekció a hiteles postafiók-tárolásból származó indexmásolat. Használd a kanonikus S3-tartalmat és egy friss, adatvédelmi szempontból megfelelő indexalapot. A kizárt _source mezők nem állítanak vissza hiányzó teljes tartalmat. Mielőtt módosítod a keresési útválasztást, olvasd el a keresés elérhetőségét.
A szükséges konfigurációval és aktív tulajdonosi bérlettel a backend könyvtárból futtasd:
node --import tsx scripts/email-encryption-migration.ts \
--owner '<Better Auth owner id>' \
--report /tmp/email-encryption-report.json \
--apply --backfill-search --search-index '<fresh-base>'
A <fresh-base> helyére egy érvényes, új alapnevet írj. Az eszköz a src/lib/system/opensearch/emailSearchBackfill.ts fájlban lévő, revízióbiztos postafiók-visszatöltést használja. Korlátos adatbázis-oldalakat és kanonikus tartalmat olvas. Nem indexeli újra vakon a kizárt mezőket egy régi indexből.
Minden postafiókhoz ellenőrzőpont készül a jelentés mellett:
<fresh-base>-<mailbox-id>.search-checkpoint.json
A jelentés rögzíti a kiválasztott alapot és a sikeres visszatöltés befejezését. Mielőtt az alkalmazás olvasóit erre irányítanád, ellenőrizd a függő jelentéskategóriákat és a postafiókonkénti ellenőrzőpontokat. Nézd meg az indexlefedettséget és a keresési eredmények egyezését is.
A --search-index csak a migrációs folyamat célját módosítja. Nem kapcsolja át az alkalmazás konfigurációját. A tulajdonosra jellemző lefedettség-ellenőrzés után az üzemeltető külön állítja be:
| Beállítás | Szerep |
|---|---|
OPENSEARCH_ENCRYPTED_INDEX | Friss, adatvédelmi szempontból megfelelő alap a beállított alkalmazási útvonalhoz |
EMAIL_ENCRYPTION_MIGRATED_OWNERS | Azon tulajdonos-azonosítók vesszővel elválasztott listája, akiknek a lefedettségét a bevezetés előtt ellenőrizték |
OPENSEARCH_INDEX | Megtartott örökölt alap azoknak a tulajdonosoknak, akiknek még kell a kompatibilitás |
BODY_ENCRYPTION_ALLOW_LEGACY_READ | Örökölt törzsolvasási kapu. Egy felsorolt, átalakított tulajdonos akkor sem használhat titkosítatlan visszaesést, ha ez true |
Ehhez a külön kapcsolóhoz használd a támogatott futásidejű konfigurációs eljárást. Ezek a beállítások nem helyettesítik a befejezett átalakítást, a helyes tulajdonosi kulcsokat vagy a lefedettség-ellenőrzést. A migrációs eszköz nem módosítja őket a futó alkalmazáshoz.
Megőrzés és helyreállítás
A titkosított átmeneti kulcsok tartalmazzák a titkosított szöveg SHA-256 hash-ét, és megszakítás után is megmaradnak. Az eszköz megőrzi a régi indexeket, az átmeneti objektumokat, a történeti objektumverziókat, a közvetítő előzményeit és a mentéseket. Nem állítja, hogy az állapot teljesen adatvédelmi szempontból kész, és nem vállal visszamenőleges biztonságos törlést.
A kanonikus átalakítás lefedettségét és a történeti megőrzési feladatok kezelését külön ellenőrizd. Mielőtt egy tulajdonost teljesen lefedettnek nyilvánítanál, nézd át a böngésző-helyreállítási tárolót és minden függő előzménykategóriát. Hiba esetén őrizd meg a jelentést, és előbb javítsd a célzott okot, majd futtasd újra. A reset nem része ennek a migrációs eljárásnak.