Adatbiztonság és architektúra

Ügyvédi titoktartás és a szolgáltatás határai

Az ügyvédi tevékenységről szóló 2017. évi LXXVIII. törvény (Üttv. 9–13. §) szerinti ügyvédi titoktartás védelme a LegalEase tervezési szempontja. Az alkalmazott kontrollok csökkentik a jogosulatlan hozzáférés és adattovábbítás kockázatát; nem jelentenek kockázatmentességet vagy kamarai tanúsítást.

Az ügyiratok adatkezelője az Ügyvédi Iroda, a Watt Mind Kft. e körben adatfeldolgozóként jár el. A szerepeket és kötelezettségeket a GDPR 28. cikke szerinti adatfeldolgozási megállapodásban kell rögzíteni. A megállapodás nem helyettesíti a konkrét adatkezelés és a továbbítás feltételeinek vizsgálatát.

1. Belépésvédelem és azonosítás

A felhőszolgáltatások elleni visszaélések döntő többsége nem a kriptográfiai algoritmusok feltörésével, hanem a felhasználói jelszavak ellopásával, adathalászattal (phishing) vagy jelszótalálgatással (brute-force) kezdődik. Ha egy irodai munkatárs jelszava egy másik internetes felületről kiszivárog, vagy egy megtévesztő megkeresésben megadja azt, a támadó közvetlenül az iroda bizalmas ügyirataihoz és adataihoz férhet hozzá. A biztonság első és legfontosabb védelmi vonala ezért magának a belépésnek a védelme.

A LegalEase a modern, hardveresen támogatott FIDO2 szabványra épülő Passkey technológiát alkalmazza. A belépés során a jelszó soha nem utazik a hálózaton: az azonosítás a felhasználó saját eszközének (Mac, iPhone, Windows Hello vagy YubiKey) hardveres biztonsági chipjében tárolt kulccsal, biometrikus megerősítéssel (Touch ID, Face ID) történik, amely teljes védelmet nyújt az adathalászat és a jelszólopás ellen. A hagyományos jelszavas azonosítás mellett a kétfaktoros hitelesítés (MFA / TOTP) beállítása kötelezően előírható, az illetéktelen próbálkozásokat pedig automatikus forgalomkorlátozás (rate limiting) akadályozza meg.

Központi vállalati belépés (Single Sign-On, SSO, például Microsoft Entra ID vagy Google Workspace alapon) jelenleg nem érhető el; nagyobb irodák és vállalati jogi osztályok igénye esetén egyeztetünk róla. Addig a munkatársak hozzáférését az iroda kezelője a LegalEase-ben tartja karban: szerepköröket ad, ügyenként korlátoz, és a távozó munkatárs hozzáférését visszavonja.

2. Irodánkénti titkosítási kulcsok

A felhőszolgáltatások igénybevételekor az ügyvédi irodák elsődleges kérdése: hogyan garantálható, hogy a bizalmas ügyiratokhoz ne férhessen hozzá egy másik iroda, egy külső behatoló vagy akár a felhő üzemeltetője? Egy bekapcsolt irodai számítógépen a fájlok gyakran titkosítatlanul pihennek a merevlemezen, így a fizikai vagy rendszergazdai hozzáférés azonnal kiszolgáltatja az ügyvédi titkot. A felhőben az infrastruktúra általános védelme önmagában nem elég; az adatokat maguknak az iratoknak a szintjén kell lezárni.

A LegalEase-ben az adatok soha nem léteznek nyers, olvasható formában a háttértáron (nyugalmi titkosítás, Encryption at Rest). Minden egyes dokumentumot egyedi, katonai szintű AES-256-GCM titkosítás véd. A dokumentum saját adatkulcsát (DEK) egy különálló, megerősített kulcskezelőben (OpenBao Transit KMS) őrzött, irodánként dedikált, nem exportálható főkulcs (KEK) zárja le (borítékolt titkosítás, Envelope Encryption). Még a fizikai merevlemezek vagy a biztonsági mentések ellopása esetén is csupán értelmezhetetlen zaj szerezhető meg: az adott iroda saját főkulcsa nélkül egyetlen irat sem fejthető vissza.

A titkosított fájltárolás a tartalom mellett a becsomagolt adatkulcsot őrzi. Az alkalmazás csak a jogosultsággal rendelkező ügyvéd kifejezett műveletéhez kéri le az OpenBao kulcsszolgáltatástól a feloldott adatkulcsot a memóriába. A HMAC vakindex egyes titkosított azonosítómezők pontos keresését támogatja anélkül, hogy a keresett értéket fel kellene fedni az adatbázisban. Kulcsszolgáltatási hiba esetén a nem elérhető kulcsot igénylő művelet azonnal leáll (fail-closed).

Az ügyirat önkiszolgáló eltávolítása megszünteti annak aktív megjelenését a kutatási munkaterületen. Ez nem azonos az eredeti fájl, az előzmények és a biztonsági mentések végleges megsemmisítésével. Teljes törlési igényt a support@legalease.hu címen lehet jelezni; annak terjedelmét és a megőrzési kötelezettségeket külön egyeztetjük. A kriptográfiai megsemmisítés (Cryptographic Shredding) minden visszafejtési lehetőség megszüntetését igényli, beleértve a kulcsmásolatokat, a mentéseket és a gyorsítótárakat is.

3. Ügyenként elkülönített munkaterületek

Amikor a mesterséges intelligencia elemez egy ügyiratot, a szöveget be kell tölteni a kiszolgáló szerver operatív memóriájába (RAM). A hagyományos felhőalkalmazásokban a különböző bérlők kérései gyakran egyetlen közös operációs rendszeren, csupán szoftveresen elválasztott konténerekben futnak. Egy ilyen környezetben egy operációsrendszer-hiba vagy kártékony kód (konténer-áttörés) azt eredményezheti, hogy az egyik bérlő folyamata beleláthat a másik bérlő memóriájában lévő aktív ügyiratokba.

A LegalEase-ben az ügyek elemzése nem közös környezetben zajlik: minden egyes ügyhöz egy önálló, hardveresen elszigetelt miniatűr virtuális gép (Kata MicroVM) jön létre, saját operációsrendszer-kernellel. Ez a technológia fizikailag zárt, dedikált memóriaterületet biztosít a munkaterületnek a szerveren, így más ügyvédi irodák – sőt még az adott iroda egyéb ügyei – sem férhetnek hozzá a folyamatban lévő iratok memóriatartalmához.

A hardveres virtualizáció drasztikusan csökkenti a futtatókörnyezeti átfedések kockázatát, de nem helyettesíti az alkalmazásszintű hozzáférés-szabályozást és a naprakész hálózati korlátozásokat. Amikor az aktív futtatás leáll, a mikrovirtuális gép megsemmisül, az operatív memória (RAM) teljes tartalma törlődik, az iratok pedig kizárólag a háttértáron, biztonságosan lezárt, titkosított állapotban maradnak meg a következő feloldásig. A futtatás lezárása ugyanakkor nem azonos a feltöltött iratok tartós tárolásának végleges törlésével; a fájlok megőrzési idejéről és a törlési igényekről az iroda külön rendelkezhet.

4. Korlátozott kimenő kapcsolatok és saját API-kulcs

Ha egy AI-asszisztens vagy háttérfolyamat korlátlan internetkapcsolattal rendelkezne, fennállna a veszélye, hogy egy irat tartalma észrevétlenül illetéktelen harmadik felekhez, hirdetőkhöz vagy követőszerverekhez szivárog ki. A biztonságos üzemeltetés alapelve, hogy a munkaterületről kifelé vezető minden egyes adatutat szigorú ellenőrzés alatt kell tartani.

A LegalEase munkaterületein a közvetlen, tetszőleges internetelérés alapértelmezetten tiltott. A munkaterületről kimenő forgalmat szigorú hálózati engedélylista szabályozza: kizárólag a névfeloldás (DNS), az alkalmazásproxy, a nyilvános jogforrástár és az irodai modellátjáró (Model Egress Gateway) érhető el. A modellszolgáltatók elérése kizárólag ezen a dedikált belső átjárón keresztül lehetséges.

Az irodai modellátjáró rögzített célpontot használ; a jelenlegi integráció OpenAI-hozzáférést használ, további szolgáltatók (például Anthropic Claude vagy Mistral) bevonását előzetesen egyeztetjük. Saját szolgáltatói API-kulcs használata (Bring Your Own Key, BYOK) kérésre elérhető; a saját szerződés feltételei irányadók, a BYOK önmagában nem jelent zéró adatmegőrzést.

A beépített CDV- és formátumszűrő a magyar azonosítók (adószám, TAJ, cégadatok) megbízható felismerését és álnevesítését végzi a kimenő adatfolyamban. Nem helyettesíti a teljes szöveg szakmai vizsgálatát, és nem ígér minden egyedi kontextusban rejlő személyes adatra kiterjedő felismerést.

5. Személyes adatok, modelltanítás és megőrzés

A továbbított kérdés és iratrészlet személyes adatot vagy ügyvédi titkot tartalmazhat. Az ügyvédi hivatás legszigorúbb etikai és jogi elvárása a titoktartás: a külső félhez eljutó adatok nem kerülhetnek be nyilvános adatbázisokba, és nem szolgálhatnak mások által használt AI modellek tanítására.

A LegalEase csak olyan külső AI-szolgáltatókkal dolgozik, amelyek garantálják, hogy a LegalEase által közvetített kérdéseket, iratrészleteket, válaszokat és egyéb információkat nem használják fel modellek tanítására. Ezt minden igénybe vett szolgáltatás, modell és funkció esetén az adott hozzáféréshez tartozó szerződés és beállítás alapján értékeljük; egy fejlesztői API feltételei nem alkalmazhatók automatikusan egy eltérő előfizetéses szolgáltatásra.

A külső AI-szolgáltatónál a kérdések, iratrészletek és válaszok megőrzését az igénybe vett szolgáltatás, modell, funkció és szerződés határozza meg. Biztonsági visszaélés-ellenőrzés (abuse monitoring) vagy más szolgáltatási cél miatt tartós tárolás is történhet; nincs valamennyi szolgáltatásra érvényes 30 napos felső korlát.

A Zero Data Retention (ZDR) nem általános szolgáltatási feltétel. Csak az adott szolgáltatásra és funkcióra ténylegesen érvényes, aktivált megállapodás alapján alkalmazható. A modelltanítás kizárása, az adatmegőrzés és a saját kulcs használata külön feltétel.

A helyi kétirányú PII-álnevesítés (PII Guard) a 6. pontban részletezettek szerint minimalizálja a külső szolgáltatóhoz eljutó személyes adatokat. Az álnevesítés alkalmazása mellett is megmaradhat a közvetett azonosíthatóság vagy a kötetlen szövegben fel nem ismert információk továbbításának kockázata, ezért a szakmai ellenőrzés továbbra is elengedhetetlen.

Az OpenAI vállalati adatvédelmi vállalásairól az OpenAI Enterprise Privacy oldalán olvashat részletesen.

6. Személyes adatok álnevesítése

A modellszolgáltatók szerződéses adatvédelmi ígéretei és tanításmentességi nyilatkozatai elengedhetetlenek, az ügyvédi titoktartás és a GDPR szempontjából azonban az is számít, mennyi valós azonosító és személyes adat jut el egyáltalán a külső szolgáltatóhoz. Amit a külső modell nem kap meg, az a szolgáltató naplóiból sem szivároghat ki; ezért a LegalEase ügyenként bekapcsolható helyi álnevesítéssel csökkenti a továbbított személyes adatok körét.

Erre ad megoldást a kétirányú helyi PII-álnevesítés (PII Guard). A munkaterületről kimenő hívásokban a helyi proxy még a szerver elhagyása előtt szintetikus, determinisztikus álnevekre cseréli a felismert személyes és védett adatokat. Bekapcsolt PII Guard mellett a külső AI-szolgáltató a felismert adatok helyett álneveket kap; a válasz érkezésekor pedig a helyi réteg valós időben, a háttérben végzi el a visszacserélést (detokenizálás), így a jogász a felületen a valós, ügyhöz illeszkedő neveket és adatokat látja.

Az észlelési tartomány kiterjed a magyar adóazonosító jelek és TAJ-számok ellenőrzőösszeg-alapú (CDV) validációjára, a cégjegyzékszámok, céges adószámok, e-mail-címek és telefonszámok formátumszűrésére, valamint az ügy strukturált szereplőinek (természetes személyek és gazdasági társaságok neveinek) felismerésére és álnevesítésére. A feltöltött és Google Drive-ból szinkronizált iratok feldolgozásakor automatikus háttérelemzés térképezi fel a személyes adatokat; a dokumentumlistában elhelyezett biztonsági pajzs jelvény közvetlenül mutatja az észlelt entitások számát és állapotát.

A védelem nem fekete doboz: az AI Munkaterületen a felhasználó bármikor megnyithatja az adott ügyhöz tartozó Adatvédelmi Szűrőt (Privacy Filter Drawer), ahol tételesen áttekintheti a felismert entitásokat, típusukat és álneveiket. Az egyes azonosítók egyenként ki- vagy bekapcsolhatók, és indokolt esetben az egész védelem vészhelyzeti kapcsolóval inaktiválható, amely művelet automatikusan bekerül a belső auditnaplóba.

A védelem határa: a helyi álnevesítés az azonosított formai szabályokra és az ügy ismert szereplőire támaszkodik. Nem helyettesíti a szakmai körültekintést, és nem garantálja a folyószövegben rejlő egyedi, közvetett azonosítók 100%-os felismerését. Az álnevesítés a külső modellszolgáltatók tanításmentességi garanciáival és a Zero Data Retention feltételekkel párhuzamos, egymást kiegészítő védelmi vonalként működik.

7. Ellenőrizhető jogforrások

A nyelvi modellek egyik legveszélyesebb sajátossága a jogászi munkában a magabiztos hallucináció: az általános AI hajlamos hatályon kívül helyezett törvényhelyeket, kitalált paragrafusokat vagy pontatlan időállapotokat idézni megbízható forrásként. Egy nem létező vagy elavult jogszabály-hivatkozásra épített beadvány vagy szakvélemény súlyos szakmai és felelősségi kockázatot jelent az eljáró jogász számára.

A LegalEase nem az AI modell bizonytalan belső emlékezetére támaszkodik, hanem közvetlenül a hivatalos Nemzeti Jogszabálytár (NJT) szövegeit használja fel. A kutatás során a rendszer pontosan rögzíti a felhasznált jogforrást, annak hivatalos hatályossági időállapotát és az Európai Jogszabály-azonosítót (ELI), a rekurzív njtGetBlock technológiával kifejtve a dinamikusan betöltődő szakaszokat is.

A jogforrás-adatbázis integritását megbízhatóan rögzített kiadás, kriptográfiai ujjlenyomat (SHA-256 manifest) és automatizált minőségellenőrző kapu (Retrieval Contract Suite) védi a kiadások előtt. A rendszer nem ígér automatikusan minden ügyben helyes időbeli jogalkalmazást: a hivatkozott szöveg és az irányadó időállapot ellenőrzése továbbra is a jogász felelőssége.

8. Biztonságos fejlesztés és üzemeltetés

Egy felhőszolgáltatás vizsgálatakor a jogászokban és megfelelőségi vezetőkben joggal merül fel a kérdés: mi védi a megbízóik ügyvédi titkait maguktól a platform üzemeltetőitől és fejlesztőitől? Látják-e a fejlesztők a valós szerződéseket a tesztelés során, belepiszkálhat-e bárki kézzel az éles adatbázisba, és hogyan kerülnek ki a programfrissítések?

A LegalEase fejlesztési, tesztelési és éles kiszolgálói környezetei hálózatilag és jogosultságilag szigorúan el vannak választva egymástól. A szoftver fejlesztése és az automatizált tesztelés során kizárólag szintetikus, mesterségesen generált tesztadatokat használunk; éles ügyfélirat, személyes adat vagy bérlői adatbázis-mentés soha, semmilyen indokkal nem kerülhet ki a védett éles környezetből fejlesztői gépekre.

Az éles kiszolgálók közvetlen, manuális módosítása szigorúan tiltott. Minden szoftvermódosítás zárt verziókövető rendszerben, a négy szem elve szerinti kódátvizsgálással készül, és szigorú automatizált minőségi kapukon megy keresztül. Az élesítés feltétele a biztonsági statikus kódanalízis, a több-bérlős izolációt garantáló tesztek, valamint az adatbázis-migrációs integritás hibátlan lefutása. Az új verziók emberi kézi beavatkozás nélkül, automatizált folyamaton keresztül kerülnek kiszolgálásra.

A fejlesztők és üzemeltetők nem rendelkeznek állandó hozzáféréssel az ügyfelek dokumentumaihoz vagy az irodák dedikált OpenBao főkulcsaihoz (Least Privilege és Zero Standing Access elv). A bérlői dokumentumokat védő borítékolt titkosítás (Envelope Encryption) technológiai garanciát nyújt arra, hogy az infrastruktúra szintjén se lehessen az ügyiratok tartalmához hozzáférni az iroda saját kulcsai nélkül.

Bár a LegalEase a jelenlegi korai fázisában még nem rendelkezik akkreditált harmadik fél által kiadott SOC 2 Type II vagy ISO/IEC 27001 tanúsítvánnyal, üzemeltetési és fejlesztési folyamatainkat az első naptól kezdve ezen nemzetközi szabványok kontrolljaival összhangban működtetjük, megteremtve a jövőbeni formális auditok zökkenőmentes elvégzésének műszaki és eljárási alapjait.

9. Szakmai és műszaki kontrollok

Az AI nem eljáró ügyvéd, és nem viselhet kamarai vagy kártérítési felelősséget. Bármilyen fejlett a technológiai háttér, a szoftver csupán segédeszköz: a szakmai döntések, a perbeli nyilatkozatok és a szerződéses szövegek érdemi ellenőrzése mindig az eljáró jogász személyes felelőssége marad.

Az ügyhöz kötött hozzáférés, a kimenő kapcsolatok korlátozása és az ügyvédi ellenőrzés egymást kiegészítő kontrollok. A külső AI válaszait és hivatkozásait a szakmai felhasználás előtt ellenőrizni kell.

A BYOK kérésre elérhető. Az önkiszolgáló irateltávolítás és a teljes, végleges törlés külön kezelendő. A szolgáltatás nem ígér hibamentes AI-válaszokat, korlátlan forráslefedettséget vagy az adatszivárgás teljes kizárását.

10. Biztonsági ellenőrzőlista

Egy szolgáltatás értékelésénél a konkrét adatút, jogosultsági határ, törlési folyamat és szerződéses feltétel számít. Az alábbi kérdések a LegalEase és más megoldások vizsgálatához is használhatók.

Egy infrastruktúra-szolgáltató tanúsítványa a benne meghatározott szolgáltatási körre vonatkozik. Nem helyettesíti az alkalmazás saját működésének és adatkezelésének ellenőrzését.

Keskeny képernyőn a táblázat oldalra görgethető; billentyűzettel a fókuszálás után a nyílbillentyűkkel olvasható.

11. Auditnaplók: események, tárolás és hozzáférés

A bizalmas ügyek kezelése során alapvető elvárás az utólagos elszámoltathatóság: pontosan és vitathatatlanul vissza kell tudni követni, hogy ki, mikor, melyik irodában és milyen műveletet végzett. Az auditnaplók rögzítik például a bejelentkezéseket, a jogosultságok módosítását, egy dokumentum letöltését vagy a kutatási munkaterület eseményeit (például a PII-védelem ki- vagy bekapcsolását). Ezek strukturált eseménynaplók, nem a beszélgetések nyers másolatai.

A szervernaplókat, a rendszerhozzáféréseket és a bérlői auditnaplókat már jelenleg is centralizált naplókezelő rendszerben gyűjtjük. Az auditbejegyzések az alkalmazás adatbázisa mellett egy elkülönített naplózási környezetbe kerülnek, rögzítve az eljáró felhasználót, a művelet és a célpont azonosítóját, az időpontot, az eredményt, valamint az IP-címet, böngészőadatot és változási metaadatokat. Az irodai hozzáférési napló megtekintése irodakezelési jogosultsághoz kötött; a naplóbejegyzések utólagos módosítását vagy törlését a rendszer tiltja.

A megmásíthatatlanság legmagasabb szintű biztosítására kérésre az auditnaplókat valós időben is szállítjuk az ügyvédi iroda által kijelölt, független harmadik félhez vagy a saját biztonsági naplókezelő rendszeréhez (SIEM). Az események azonnali, külső környezetbe történő kiszállítása garantálja, hogy a naplóbejegyzések a LegalEase-től függetlenül, utólag megmásíthatatlanul maradjanak meg. Az átadás előtt egyeztetjük a fogadó rendszert, az érintett mezőket, a szállítási formátumot és a titkosítási feltételeket.

A dokumentumok borítékolt titkosítása nem terjed ki automatikusan az auditnaplók adatbázismezőire. A naplók védelmét az adatbázishoz való hozzáférés szabályozása és a telepített tárolási környezet biztosítja; nem állítunk minden auditmezőre külön irodai kulcsos titkosítást.

A központi eseményrögzítő a változási és metaadatok egyes érzékeny mezőit, például jelszó- és tokenmezőket kitakarja. Ez nem teljes körű anonimizálás: a napló továbbra is tartalmazhat személyes adatot. Az auditnaplók megőrzése elkülönül a hibaelemzéshez és teljesítményértékeléshez használt részletes futási naplókétól; egységes automatikus törlési határidőt nem ígérünk.

12. Szerepkörök és ügyenkénti hozzáférés az irodán belül

Az irodák közötti elkülönítés mellett az egy irodán belüli hozzáférés is szabályozható. A munkatárs szerepköre határozza meg az elvégezhető műveleteket; az ügyhozzáférési beállítás azt, hogy mely ügyeken dolgozhat. Az ügyhöz adott hozzáférés önmagában nem bővíti a szerepkör műveleti jogosultságait.

A választható szerepkörök: Irodavezető partner, Alkalmazott ügyvéd, Ügyvédjelölt és Irodai asszisztens. Az irodai tagságok és beállítások kezelése, a szerződéstervezetek készítése, a kutatás és a jóváhagyási műveletek eltérő jogosultságokhoz kötöttek.

A munkatárs ügyhozzáférése lehet „Minden ügy” vagy „Csak hozzárendelt ügyek”. Az alapértelmezett „Minden ügy” mód a nem korlátozott ügyekre terjed ki. A „Csak hozzárendelt ügyek” módhoz minden elérhető ügyre külön, aktív hozzárendelés szükséges; így például egy munkatárs csak a számára kijelölt ügyeken dolgozhat. Az irodavezető partner szerepköre a „Minden ügy” módot használja, a korlátozott ügyekre vonatkozó kivétellel.

Egy ügy külön is korlátozható. Ilyenkor a tartalmához az irodavezető partnernek is kifejezett ügyhozzáférés szükséges. Az ügyhöz tartozó hozzáférésnél a megtekintés, a módosítás és a hozzáférések adminisztrálása külön szabályozható. Az ellenőrzések a kiszolgálóoldali műveletekben és adatlekérdezésekben érvényesülnek.

A védelem határa: az ügyhöz nem kapcsolt, közös irodai adatok a szerepkör szerint továbbra is elérhetők lehetnek. Az ügyenkénti hozzáférés ezért nem jelenti valamennyi irodai törzsadat felhasználónkénti elkülönítését. A kívánt korlátozáshoz az irodának be kell állítania és rendszeresen felül kell vizsgálnia a munkatársak szerepkörét, ügyhozzáférési módját és hozzárendeléseit.