Belső Felhasználási Szabályzat

Mező	Adat
Dokumentum típusa	Belső szabályzat
Dokumentum azonosítója	BFSZ-GOTC-001
Hatályos	2026. június 28-tól
Verzió	1.0
Utolsó felülvizsgálat	2026. június 28.
Következő felülvizsgálat	2027. június 28.
Felelős / jóváhagyta	Svercsok Nándor, ügyvezető (egyben adatvédelmi kapcsolattartó)

---

BEVEZETŐ RÉSZ

---

1. Bevezető rendelkezések

1.1 A Szabályzat célja és rendeltetése

Jelen Belső Felhasználási Szabályzat (a továbbiakban: „Szabályzat" vagy „BFSZ") célja, hogy a Georto Vision elnevezésű belső vállalati webalkalmazás (a továbbiakban: „Rendszer" vagy „Alkalmazás") valamennyi felhasználója számára egységes, egyértelmű és kötelező erejű keretrendszert határozzon meg a Rendszer rendeltetésszerű, biztonságos, jogszerű és a vonatkozó adatvédelmi előírásoknak megfelelő igénybevételéhez.

A Szabályzat kettős rendeltetést tölt be:

a) Belső magatartási kódex: A Szabályzat meghatározza azokat a kötelező viselkedési normákat, tilalmakat és kötelezettségeket, amelyeket a Rendszer valamennyi felhasználójának — szerepkörétől függetlenül — ismernie kell és maradéktalanul be kell tartania. A Szabályzat szabályozza különösen a hozzáférési jogosultságok kereteit, a Rendszerben kezelt adatok helyes kezelési módját, a biztonsági előírásokat, az adatvédelmi incidensek esetén követendő belső eljárásrendet, valamint a Szabályzat megszegésének következményeit.

b) Adatvédelmi megfelelőségi eszköz: A Szabályzat az Adatkezelő adatvédelmi megfelelőségi dokumentációjának szerves részeként az Európai Parlament és a Tanács (EU) 2016/679 rendelete (a továbbiakban: „GDPR"), az információs önrendelkezési jogról és az információszabadságról szóló 2011. évi CXII. törvény (a továbbiakban: „Infotv."), a munka törvénykönyvéről szóló 2012. évi I. törvény (a továbbiakban: „Mt.") vonatkozó rendelkezéseivel, valamint az egyéb hatályos magyar és európai uniós jogi előírásokkal összhangban operatív szintre fordítja le az Adatkezelő adatvédelmi tájékoztatójában és incidenskezelési szabályzatában rögzített elveket — a mindennapos rendszerhasználat szintjén alkalmazható konkrét szabályok formájában.

A Szabályzat megalkotásának alapvető indoka, hogy a Georto Vision — belső, vállalati munkaeszköz-jellegéből adódóan — olyan informatikai rendszer, amelyben a felhasználók a munkavégzésük részeként személyes adatokat (saját fiókadataikat) és szakmai adatokat (geodéziai, térképészeti fájlokat) egyaránt kezelnek. A Rendszer hatékony, biztonságos és jogszerű üzemeltetése kizárólag abban az esetben biztosítható, ha valamennyi felhasználó tisztában van azzal, hogy a Rendszert mire és hogyan használhatja, milyen tevékenységek minősülnek rendeltetésszerű belső munkavégzésnek, és milyen magatartások minősülnek a Szabályzat megsértésének.

1.2 A Szabályzat viszonya más belső dokumentumokhoz

A Szabályzat az Adatkezelő belső dokumentációs rendszerének részét képezi, és az alábbi dokumentumokkal szoros összefüggésben értelmezendő:

1.2.1 Kapcsolat az Adatvédelmi Tájékoztatóval

Az Adatkezelő a Georto Vision Rendszer üzemeltetésével összefüggő személyes adatkezelési tevékenységeket az Adatvédelmi Tájékoztatóban (a továbbiakban: „Tájékoztató") részletesen szabályozza. A Tájékoztató a GDPR 13. és 14. cikke, valamint az Infotv. vonatkozó rendelkezései szerinti tájékoztatási kötelezettséget hivatott teljesíteni: tartalmazza az adatkezelő azonosítóit és elérhetőségeit, az egyes adatkategóriák kezelésének célját, jogalapját és megőrzési idejét, az igénybe vett adatfeldolgozókat, az alkalmazott technikai és szervezési biztonsági intézkedéseket, valamint az érintetti jogokat és azok gyakorlásának módját.

Jelen Szabályzat a Tájékoztatóval párhuzamosan és azt kiegészítve alkalmazandó: míg a Tájékoztató az adatkezelési tevékenységek jogi és technikai leírását tartalmazza, addig a Szabályzat az adott jogi és technikai keretek között mit szabad, mit kell és mit tilos tenni a felhasználóknak — a napi rendszerhasználat szintjén megfogalmazott, konkrét kötelezettségek és tilalmak formájában.

Ellentmondás esetén a Tájékoztató rendelkezései az irányadók; a Szabályzat a Tájékoztatóban rögzített elveket nem korlátozhatja, csupán pontosíthatja és kiegészítheti.

1.2.2 Kapcsolat az Adatvédelmi Incidenskezelési Szabályzattal

Az Adatkezelő az adatvédelmi incidensek észlelésére, kivizsgálására, kezelésére, hatósági bejelentésére és az érintett személyek tájékoztatására vonatkozó részletes eljárásrendet az Adatvédelmi Incidenskezelési Szabályzatban (a továbbiakban: „Incidenskezelési Szabályzat") rögzíti.

Jelen Szabályzat 13. és 14. fejezete az Incidenskezelési Szabályzatból kivonatolt, a felhasználókat közvetlenül érintő kötelezettségeket — különösen a bejelentési kötelezettséget, a bejelentési határidőket, a bizonyítékmegőrzési tilalmakat és a titoktartási kötelezettséget — foglalja össze a felhasználóbarát rendszerhasználat igényeihez igazított formában. Az incidenskezelési eljárásrend teljeskörű leírása az Incidenskezelési Szabályzatban található; jelen Szabályzat vonatkozó fejezetei nem helyettesítik, hanem kiegészítik azt.

1.2.3 Kapcsolat más szervezeti dokumentumokkal

A Szabályzat alkalmazása nem érinti és nem helyettesíti az Adatkezelő szervezetére vonatkozó egyéb belső szabályzatokat, így különösen a munkaszerződéseket, az általános munkavállalói magatartási kódexet, az informatikai biztonsági szabályzatot (amennyiben ilyen külön dokumentumban kerül szabályozásra), valamint a titoktartási nyilatkozatokat. Jelen Szabályzat ezen dokumentumokkal párhuzamosan alkalmazandó.

1.3 Személyi hatály – A Szabályzat hatálya alá tartozó személyek köre

Jelen Szabályzat személyi hatálya kiterjed:

a) az Adatkezelő valamennyi munkavállalójára és megbízottjára, aki a Georto Vision Rendszerhez bármely szerepkörben — Rendszergazdaként, Szerkesztőként vagy Felhasználóként — hozzáféréssel rendelkezik, függetlenül attól, hogy a Rendszert milyen eszközről, milyen időpontban és milyen munkavégzési helyszínről veszi igénybe;

b) az Adatkezelő nevében a Rendszer üzemeltetésével, fejlesztésével vagy karbantartásával megbízott külső személyekre (vállalkozókra, alvállalkozókra, tanácsadókra), akik a feladataik ellátása céljából a Rendszerhez hozzáférést kapnak — rájuk a Szabályzat rendelkezései az Adatkezelővel fennálló szerződéses jogviszonyuk keretein belül kötelezők;

c) az Adatkezelő adatvédelmi kapcsolattartójára a Szabályzatban számára meghatározott feladatok tekintetében;

d) az Adatkezelő által igénybe vett adatfeldolgozókra (Supabase, Inc. és Cloudflare, Inc.) az e Szabályzatban, illetőleg az Incidenskezelési Szabályzatban számukra meghatározott kötelezettségek tekintetében, az adatfeldolgozói szerződésekben foglaltakkal összhangban.

Az Adatkezelő rögzíti, hogy a Rendszernek nincsenek és nem is lehetnek nyilvánosan regisztrált, anonim vagy ismeretlen felhasználói: a Rendszerbe való belépés kizárólag az Adatkezelő által — Rendszergazda útján — kiküldött, személyhez szóló meghívó alapján lehetséges (lásd részletesen a 3. fejezetet). Ennek megfelelően a Szabályzat hatálya alá kizárólag az Adatkezelő által ismert és azonosított, a Rendszerbe regisztrált természetes személyek tartoznak.

1.4 Tárgyi hatály – A Rendszer és az érintett tevékenységek meghatározása

Jelen Szabályzat tárgyi hatálya kiterjed a Georto Vision elnevezésű belső vállalati webalkalmazás igénybevételével összefüggő valamennyi tevékenységre, amelyet a személyi hatály alá tartozó személyek a Rendszer keretein belül végeznek.

Az érintett tevékenységek köre különösen — de nem kizárólagosan — az alábbiakat foglalja magában:

• a Rendszerbe való bejelentkezés és onnan való kijelentkezés;
• felhasználói fiók aktiválása, adatainak módosítása és a fiók törlése;
• profilkép feltöltése, cseréje és törlése;
• geodéziai, térképészeti és térinformatikai fájlok feltöltése, megtekintése, átnevezése és törlése;
• FTP-szerverekről történő fájlimport elvégzése;
• térképkonfigurációk létrehozása, szerkesztése, mentése, megosztása és törlése;
• GPS-alapú helymeghatározás engedélyezése és a funkció igénybevétele;
• rendszerüzenetek megjelenítése és elolvasása;
• a tevékenységi napló (audit log) megtekintése és kezelése (kizárólag Rendszergazda számára);
• felhasználói fiókok kezelése, meghívók kiküldése, szerepkörök módosítása (kizárólag Rendszergazda számára);
• adatvédelmi incidens gyanújának észlelése és bejelentése.

A Szabályzat tárgyi hatálya nem terjed ki az Adatkezelő más informatikai rendszereiben (például vállalatirányítási szoftverben, e-mail-rendszerben, HR-szoftverben, egyéb belső alkalmazásokban) végzett tevékenységekre. Ezen rendszerek tekintetében az ott érvényes, külön szabályzatok rendelkezései az irányadók.

1.5 Az Adatkezelő megnevezése és elérhetőségei

A Rendszer üzemeltetője és adatkezelője az alábbi szervezet (a továbbiakban: „Adatkezelő"):

A felhasználók a jelen Szabályzattal, a Rendszer használatával, az adatkezelési tevékenységekkel, valamint az érintetti jogok gyakorlásával kapcsolatos valamennyi kérdésükkel, kérelmeikkel és panaszaikkal az adatvédelmi kapcsolattartóhoz fordulhatnak a fenti elérhetőségeken.

1.6 A Szabályzat hatályba lépése és érvényessége

1.6.1 Hatályba lépés

Jelen Szabályzat 2026. június 28. napján lép hatályba, és határozatlan ideig érvényes. A Szabályzat ezen időponttól kezdve kötelező erejű az 1.3 pontban meghatározott személyi hatály alá tartozó valamennyi személy vonatkozásában.

1.6.2 A Szabályzat megismerésének és elfogadásának kötelezettsége

A Rendszerhez hozzáférést kapó minden személy a Rendszer első igénybevétele előtt köteles jelen Szabályzatot teljes egészében megismerni. A Rendszer használatának megkezdésével, illetőleg — ahol ez külön megkövetelt — a Szabályzat aláírásával az érintett személy nyilatkozik arról, hogy jelen Szabályzat rendelkezéseit megismerte, megértette és azokat kötelezőnek ismeri el magára nézve.

A Szabályzat elektronikus elfogadása kötelező a fiókaktiválás során (ld. 3.2.2 pont), valamint a Szabályzat verziófrissítése esetén a sikeres bejelentkezést követően felugró ablakban (ld. 3.2.3 pont). A rendszerüzenetben történő tájékoztatás önmagában jogi elfogadásnak nem minősül.

A Szabályzat megismerési és elfogadási kötelezettségének teljesítéséről a beléptetési folyamat keretében az adatvédelmi kapcsolattartó, illetőleg a Rendszergazda gondoskodik (lásd az 1. mellékletet).

1.6.3 A Szabályzat hozzáférhetősége

A Szabályzat mindenkori hatályos változata az Adatkezelő belső dokumentumtárában, a fiókaktiválási felületen és a Rendszer felhasználói profilpaneljén elérhető jogi dokumentumok között, valamint az adatvédelmi kapcsolattartótól kérésre érhető el. A Szabályzat módosításáról a Rendszer belső rendszerüzenet-mechanizmusa és szükség esetén e-mail útján is tájékoztatás kerül kiküldésre, amely a hatályos szöveg elérési helyére hivatkozik. Az adatvédelmi kapcsolattartó köteles gondoskodni arról, hogy a Szabályzat aktuális verziója valamennyi érintett személy számára folyamatosan hozzáférhető legyen.

1.6.4 Verziózás és korábbi szabályzatok hatályon kívül helyezése

A Szabályzat jelen, 1.0-s verziója hatályba lépésének napján érvényteleníti az Adatkezelő által korábban esetlegesen kiadott, a Georto Vision Rendszer belső felhasználói magatartására vonatkozó valamennyi korábbi belső utasítást, tájékoztatót és előírást. A Szabályzat korábbi verziói archiválásra kerülnek, és az adatvédelmi kapcsolattartónál — különösen jogorvoslati eljárás esetén — rendelkezésre állnak.

---

2. Fogalommeghatározások

Jelen fejezet célja, hogy a Szabályzatban alkalmazott szakkifejezések — tekintettel a Rendszer technikai sajátosságaira, az alkalmazandó adatvédelmi jogszabályokra és a belső szervezeti összefüggésekre — egységes értelmezési keretet kapjanak. Az alábbi meghatározásokat a Szabályzat teljes szövege vonatkozásában kell alkalmazni; ahol jelen fejezet a fogalmat nem határozza meg, ott a GDPR, az Infotv. és az Mt. vonatkozó fogalommeghatározásai az irányadók.

2.1 A Rendszerre vonatkozó fogalmak

Georto Vision (Rendszer, Alkalmazás): Az Adatkezelő által fejlesztett és üzemeltetett, kizárólagosan belső, vállalati munkavégzési célra igénybe vett webalkalmazás, amelynek elsődleges rendeltetése geodéziai, térképészeti és térinformatikai adatok (geodata-fájlok) kezelése, csapatszintű megosztása, térképes megjelenítése és térinformatikai műveletek elvégzése. A Rendszer böngészőalapú alkalmazás; igénybevételéhez dedikált szoftver telepítése nem szükséges. A Rendszerhez való hozzáférés kizárólag az Adatkezelő által kiküldött egyszeri meghívó alapján lehetséges; nyilvánosan regisztrálható felhasználói fiók nem áll rendelkezésre.

Frontend (kliens oldal): A Rendszer azon rétege, amely az érintett felhasználó böngészőjében fut. A frontend a felhasználói felületet, a térképes megjelenítést (MapLibre GL JS könyvtár segítségével), a fájlkezelési felületet, a felhasználói profilpanelt, valamint a bejelentkezési és fiókaktiválási oldalt foglalja magában. A frontend forráskódja statikus fájlokból áll, és a Cloudflare infrastruktúrán keresztül kerül kiszolgálásra.

Backend (szerver oldal, API): A Rendszer azon rétege, amely a Cloudflare Workers platformon fut, és az összes adatkezelési műveletet — beleértve a hitelesítés ellenőrzését, a fájlkezelési műveleteket, a felhasználókezelést, az FTP-proxy funkciót és a tevékenységi napló rögzítését — kiszolgálja. A backend állapotmentes (stateless) architektúrán alapul: az egyes kérések feldolgozása után a Cloudflare Worker memóriájában tárolt adatok törlődnek.

Éles (produkciós) környezet: A Rendszer azon üzemelési állapota, amelyben az Adatkezelő munkavállalói és megbízottjai a napi munkavégzésük során a Rendszert ténylegesen igénybe veszik. Az éles környezetben kizárólag titkosított HTTPS-kapcsolaton keresztül érhető el a Rendszer; a https://georto.com domain alatt. Jelen Szabályzat rendelkezései kizárólag az éles környezetre vonatkoznak; a fejlesztői és tesztkörnyezeteket külön előírások szabályozhatják.

Fejlesztői / tesztkörnyezet: A Rendszer azon üzemelési állapota, amelyet kizárólag az Adatkezelő Rendszer fejlesztéséért, teszteléséért és karbantartásáért felelős munkatársai vehetnek igénybe, kizárólag fejlesztési és tesztelési célból. A fejlesztői és tesztkörnyezetben valós személyes adatok kezelése tilos.

API-végpont: A backend API egy-egy konkrét, HTTP-kéréssel elérhető erőforrása vagy funkciója (például /maps, /files, /upload, /invite, /user/{userId}, /ftp/list). A Cloudflare Worker GET, POST és DELETE HTTP-módszereket fogad; PATCH és PUT végpontok a Rendszerben nem kerültek kialakításra. Az API-végpontok kizárólag érvényes JWT hitelesítési tokennel rendelkező, hitelesített felhasználók számára elérhetők; a szükséges szerepköri jogosultság hiányában a szerver a kérést HTTP 403 Forbidden hibakóddal utasítja vissza.

2.2 Felhasználói szerepkörök fogalmai

Felhasználó (User szerepkör): A Rendszerbe regisztrált természetes személy, akinek szerepköre „Felhasználó" szinten kerül meghatározásra. A Felhasználó olvasói és mérési jogkörrel rendelkezik: megtekintheti a Rendszerben tárolt geodata-fájlokat és a számára megosztott vagy általa létrehozott térképkonfigurációkat, elvégezhet terepi méréseket és koordinátaszámításokat a térképes felületen, valamint kezelheti a saját térképkonfigurációit. A Felhasználó fájlokat nem tölthet fel, nem törölhet és nem nevezhet át; FTP-importálási funkciója és adminisztrációs hozzáférése nincsen.

Szerkesztő (Editor szerepkör): A Rendszerbe regisztrált természetes személy, akinek szerepköre „Szerkesztő" szinten kerül meghatározásra. A Szerkesztő rendelkezik a Felhasználó összes jogosultságával, ezenfelül jogosult geodata-fájlok feltöltésére, meglévő fájlok átnevezésére és törlésére, valamint FTP-szerverekről történő fájlimport elvégzésére. A Szerkesztő felhasználói fiókok kezelésére, meghívók kiküldésére, a tevékenységi napló megtekintésére és törlésére, illetőleg más felhasználók fiókadatainak módosítására nem jogosult.

Rendszergazda (Admin szerepkör): A Rendszerbe regisztrált természetes személy, akinek szerepköre „Rendszergazda" szinten kerül meghatározásra. A Rendszergazda az Adatkezelő által megbízott, emelt jogosultságszintű munkatárs, aki rendelkezik a Szerkesztő összes jogosultságával, ezenfelül jogosult: új felhasználók meghívására és az ideiglenes jelszó meghatározására (a profilpanel → Beállítások → Új felhasználó felületen); más felhasználók fiók- és profiladatai (e-mail-cím, jelszó, vezetéknév, keresztnév, szerepkör, profilkép URL) módosítására és fiókjuk törlésére (a megfelelő Worker API-végpontokon, illetve a Supabase adminisztrációs felületén; dedikált webes admin felület a Rendszerben ezekhez nincs); a tevékenységi napló (audit log) megtekintésére és törlésére (profilpanel → Beállítások → Műveletek ellenőrzése). A Rendszergazda az emelt jogosultságokból fakadó fokozott felelősséggel bír, és köteles ezeket a jogosultságokat kizárólag az Adatkezelő által meghatározott feladatok elvégzésére igénybe venni (lásd részletesen a 4.2 pontot).

Meghívott (Invited) állapot: A felhasználói fiók ideiglenes állapota, amelybe a fiók a meghívó kiküldésekor kerül, és amely a fiókaktiválás elvégzéséig fennáll. Meghívott állapotban a felhasználó a Rendszert nem veheti igénybe; a meghívott fiókhoz ideiglenes jelszó tartozik, amelyet az érintett az első bejelentkezéskor köteles megváltoztatni.

Aktív fiók: A fiókaktiválási folyamat sikeres elvégzése után, az érintett által beállított egyéni jelszóval védett, a Rendszer valamennyi, az adott szerepkörnek megfelelő funkciójához hozzáféréssel rendelkező felhasználói fiók.

Letiltott fiók: Az a felhasználói fiók, amelyhez a Rendszergazda, illetőleg az adatfeldolgozó (Supabase) adminisztrátori felülete útján az aktív hozzáférési jogosultságot felfüggesztette. Letiltott fiókkal a felhasználó a Rendszerbe nem tud belépni. A letiltás visszafordítható állapot; a fiók végleges megszüntetéséhez fiók-törlési műveletre van szükség.

2.3 Adatkezelési fogalmak

Személyes adat: Az azonosított vagy azonosítható természetes személyre (az érintettre) vonatkozó bármely információ. Azonosítható az a természetes személy, aki közvetlen vagy közvetett módon — különösen valamely azonosító, például név, azonosítószám, helyadat, online azonosító, vagy a természetes személy testi, fiziológiai, genetikai, szellemi, gazdasági, kulturális vagy szociális azonosságára vonatkozó egy, vagy több tényező alapján — azonosítható [GDPR 4. cikk 1. pont]. A Georto Vision Rendszerben személyes adatnak minősülnek különösen: a felhasználók e-mail-címe, neve, profilképe, a tevékenységi naplóban szereplő neve és cselekvéseinek időpontja, munkamenet-tokenjei, valamint a feltöltött geodata-fájlokban esetlegesen szereplő, természetes személyre vonatkozó adatok.

Anonimizált adat: Ha a fiók törlésre kerül, a tevékenységi naplóban a törölt felhasználóhoz köthető bejegyzésekben a személyes név helyére a „Törölt felhasználó" generikus megjelölés lép. Ez a megjelölés önmagában nem azonosít konkrét természetes személyt, ezért az anonimizálást követően nem minősül személyes adatnak [GDPR (26) preambulumbekezdés]. A naplóbejegyzés fennmaradó tartalma — a művelet típusa, a fájlnév és az időbélyeg — audit célú adat marad, és a napló megőrzési idejéig elérhető.

Adatkezelés: A személyes adatokon vagy adatállományokon automatizált vagy nem automatizált módon végzett bármely művelet vagy műveletek összessége, így a gyűjtés, rögzítés, rendszerezés, tagolás, tárolás, átalakítás vagy megváltoztatás, lekérdezés, betekintés, felhasználás, közlés, továbbítás, terjesztés vagy egyéb módon történő hozzáférhetővé tétel útján, összehangolás vagy összekapcsolás, korlátozás, törlés, illetve megsemmisítés [GDPR 4. cikk 2. pont].

Adatkezelő: Az a természetes vagy jogi személy, közhatalmi szerv, ügynökség vagy bármely egyéb szerv, amely a személyes adatok kezelésének céljait és eszközeit önállóan vagy másokkal együtt meghatározza [GDPR 4. cikk 7. pont]. Jelen Szabályzat alkalmazásában az Adatkezelő az 1.5 pontban azonosított szervezet.

Adatfeldolgozó: Az a természetes vagy jogi személy, közhatalmi szerv, ügynökség vagy bármely egyéb szerv, amely az Adatkezelő nevében személyes adatokat kezel [GDPR 4. cikk 8. pont]. A Georto Vision Rendszer tekintetében adatfeldolgozónak minősülnek a Supabase, Inc. (hitelesítés, adatbázis, fájltárhely) és a Cloudflare, Inc. (API-backend, objektumtároló, kulcs-érték tároló), amelyek az Adatkezelő utasításai szerint és nevében kezelik a személyes adatokat, önálló adatkezelői minőségben nem járnak el.

Érintett: Az a azonosított vagy azonosítható természetes személy, akinek személyes adatait az Adatkezelő a Rendszer keretében kezeli. A Georto Vision Rendszer tekintetében az érintett minden esetben a Rendszerbe regisztrált felhasználó, vagyis az Adatkezelő munkavállalója, megbízottja vagy egyébként az Adatkezelő nevében és utasítására eljáró természetes személy.

Adatkezelés jogalapja: A GDPR 6. cikk (1) bekezdésének azon feltétele, amelyre az adatkezelési tevékenység támaszkodik. A Georto Vision Rendszer vonatkozásában alkalmazott jogalapok:

• Jogos érdek [GDPR 6. cikk (1) bek. f) pont]: Az adatkezelési tevékenységek döntő hányada — így különösen a hozzáférés-kezelés, a fájlkezelési műveletek, a tevékenységi naplózás, a rendszerbiztonság és az IP-cím alapú kérésszám-korlátozás — az Adatkezelő jogos érdekén alapul.
• Jogi kötelezettség teljesítése [GDPR 6. cikk (1) bek. c) pont]: Egyes adatkezelési tevékenységek — különösen a tevékenységi naplók megőrzése — az Adatkezelőre vonatkozó jogszabályi kötelezettségek teljesítéséhez szükségesek.
• Hozzájárulás [GDPR 6. cikk (1) bek. a) pont]: A profilkép feltöltése és a GPS-alapú helymeghatározás kizárólag az érintett önkéntes, egyértelmű és tájékozott hozzájárulása alapján valósul meg.

Adattovábbítás: Személyes adatoknak meghatározott harmadik személy vagy szervezet részére, szándékos döntés alapján történő hozzáférhetővé tétele. A Georto Vision Rendszeren belüli adatáramlás — azaz az egyik belső felhasználó által kezelt adatoknak más belső felhasználó általi megtekintése vagy módosítása — nem minősül adattovábbításnak, mivel az ilyen adatáramlás az Adatkezelő szervezetén belül, az Adatkezelő utasításai és felügyelete alatt valósul meg. Valódi adattovábbítás a Rendszer keretében kizárólag az adatfeldolgozók (Supabase, Cloudflare) és az alaptérkép-csempéket kiszolgáló OpenStreetMap Foundation felé valósul meg.

Adatminimalizálás elve: A GDPR 5. cikk (1) bekezdésének c) pontjában rögzített elv, amelynek értelmében a személyes adatoknak az adatkezelés céljai szempontjából megfelelőknek és relevánsoknak kell lenniük, és a szükségesre kell korlátozódniuk. A Rendszer felhasználói e elvnek megfelelően kötelesek a Rendszer keretében kizárólag a munkavégzési feladataik elvégzéséhez szükséges adatokat kezelni.

Célhoz kötöttség elve: A GDPR 5. cikk (1) bekezdésének b) pontjában rögzített elv, amelynek értelmében a személyes adatokat csak meghatározott, egyértelmű és jogszerű célból lehet gyűjteni, és azokat nem lehet e célokkal össze nem egyeztethető módon kezelni. A Rendszer felhasználói kötelesek a Rendszert kizárólag az Adatkezelő által meghatározott belső munkavégzési célokra igénybe venni.

2.4 Biztonsági fogalmak

JWT token (JSON Web Token): A Rendszerben alkalmazott hitelesítési mechanizmus alapját képező, iparági szabványos (RFC 7519) tokenformátum. A JWT token egy digitálisan aláírt, JSON-formátumú adatstruktúra, amely tartalmazza a bejelentkezett felhasználó azonosítóját (UUID), szerepkörét, a token kiállításának és lejáratának időpontját, valamint egyéb munkamenet-azonosítókat. A token érvényességét a Cloudflare Worker backend minden egyes API-kérésnél ellenőrzi; érvénytelen vagy lejárt tokennel a Rendszer API-végpontjai nem érhetők el.

Hozzáférési token (access_token): A Supabase Auth szolgáltatás által kiállított, rövid élettartamú (jellemzően 1 óra) JWT token, amely az érintett böngészőjének localStorage tárolójában kerül elhelyezésre. A hozzáférési token tartalmazza a felhasználói azonosítót, a szerepkört és a munkamenet-azonosítót. Minden API-kérésnél az Authorization: Bearer fejlécben kerül elküldésre.

Megújítási token (refresh_token): A Supabase Auth szolgáltatás által kiállított, hosszabb élettartamú token, amelynek kizárólagos rendeltetése a lejárt hozzáférési token automatikus megújítása (rotálása), anélkül, hogy a felhasználónak újra be kellene jelentkeznie. A megújítási token szintén a böngésző localStorage tárolójában kerül elhelyezésre; kijelentkezéskor mindkét token törlésre kerül.

localStorage: A böngésző szabványos, tartós helyi adattárolási mechanizmusa, amelynek tartalma a böngészőlap vagy -ablak bezárása után is megmarad, mindaddig, amíg azt a felhasználó vagy a Rendszer kifejezetten törli. A Georto Vision Rendszer a localStorage-ban tárolja: a Supabase JWT és refresh tokent (sb-[ref]-auth-token kulcs alatt), az FTP-szerver hostnevét (ftp-saved-host kulcs) és az FTP-felhasználónevet (ftp-saved-user kulcs). A localStorage tartalma kizárólag az érintett saját eszközének böngészőjében él; az Adatkezelő szerverei ahhoz közvetlenül nem férnek hozzá.

sessionStorage: A böngésző munkamenet-szintű, ideiglenes helyi adattárolási mechanizmusa, amelynek tartalma a böngészőlap bezárásakor automatikusan törlődik. A Georto Vision Rendszer a sessionStorage-ban ideiglenesen tárolja a megosztott térkép-hivatkozáson keresztül érkező felhasználók átirányítási paramétereit (pendingSharedMap kulcs), kizárólag a bejelentkezés utáni automatikus átirányítás céljából.

HTTPS (HyperText Transfer Protocol Secure): A HTTP protokoll TLS (Transport Layer Security) titkosítással kombinált változata, amely biztosítja, hogy a böngésző és a szerver közötti adatátvitel titkosított csatornán valósuljon meg, és jogosulatlan harmadik fél számára ne legyen hozzáférhető. A Rendszer éles környezetében kizárólag HTTPS-kapcsolat engedélyezett; a Cloudflare Worker backend minden HTTP-kérést automatikusan HTTPS-re irányít át.

CORS (Cross-Origin Resource Sharing): Olyan biztonsági mechanizmus, amelynek segítségével a Cloudflare Worker backend meghatározza, hogy melyik domain(ek)ről érkező böngészős kérések számára engedélyezi az API elérését. A Rendszer kizárólag a https://georto.com domainről (éles környezet), illetőleg a http://localhost és http://127.0.0.1 címekről (fejlesztői környezet) érkező kéréseket fogadja el; bármely más forrásból érkező kérés CORS-hiba miatt automatikusan elutasításra kerül.

Szerepköralapú hozzáférés-vezérlés (RBAC – Role-Based Access Control): A Rendszerben alkalmazott háromszintű jogosultságkezelési rendszer, amelynek értelmében az egyes API-végpontokhoz és Rendszer-funkciókhoz való hozzáférés nem egyénileg, hanem szerepkörhöz rendelten kerül meghatározásra. A RBAC érvényesítése a Rendszerben három egymást kiegészítő szinten valósul meg: (1.) a Cloudflare Worker szerver oldali, végpontonkénti szerepkör-ellenőrzése (a profiles tábla role mezője alapján), (2.) a Supabase adatbázis sorszintű biztonsági szabályai (RLS – Row Level Security) és adatbázis-triggerek, valamint (3.) a kliens oldali felületi korlátozás (updateUIByRole() JavaScript-függvény). Az RBAC megkerülésének kísérlete a Szabályzat súlyos megsértésének minősül.

RLS (Row Level Security): A Supabase PostgreSQL adatbázisában alkalmazott, adatbázis-szintű hozzáférés-szabályozási mechanizmus, amely biztosítja, hogy a felhasználók az adatbázis tábláiban kizárólag a számukra engedélyezett sorokat (rekordokat) érhessék el és módosíthassák. Például: a profiles tábla bármely hitelesített felhasználó számára olvasható, de módosítani kizárólag a saját profil sorát jogosult az adott felhasználó (auth.uid() = user_id feltétel alapján).

Titkosítás tárolás közben (encryption at rest): Az adatok tárolóeszközön (szerveren, felhőtárhelyen) való fizikai megőrzése során alkalmazott titkosítás, amely biztosítja, hogy a tárolt adatok jogosulatlan fizikai hozzáférés esetén is olvashatatlanok maradjanak. A Rendszer valamennyi szerver oldali adattárolója — a Supabase PostgreSQL adatbázis, a Supabase Storage (avatars tároló), a Cloudflare R2 objektumtároló és a Cloudflare KV kulcs-érték tároló — titkosítást alkalmaz tárolás közben.

IP-cím alapú kérésszám-korlátozás (rate limiting): A Cloudflare Worker backend által alkalmazott, a visszaélések és túlterheléses (DoS) támadások megelőzésére szolgáló technikai mechanizmus, amely az egy IP-címről érkező percenkénti kérések számát legfeljebb 1000-ben korlátozza. Az 1000 kérést/perc küszöbértéket meghaladó kérések esetén a szerver HTTP 429 Too Many Requests hibakóddal utasítja vissza a kérést. A korlátozáshoz felhasznált IP-cím a Cloudflare KV tárolóban 60 másodperces automatikus lejárattal (rate-limit:{ip} kulcs formátumban) kerül ideiglenes tárolásra. A korlátozás alól kivételt képeznek a GET és HEAD módszerű /files/… kérések (PMTiles és FGB fájlok byte-range alapú olvasása), mivel ezek a térképmegjelenítés természetes velejárói, és egyetlen térkép betöltése is sok párhuzamos kérést generálhat; ezért ezek az útvonalak nem számítanak bele a percenkénti kérésszámba.

bcrypt / argon2: A Supabase Auth szolgáltatás által alkalmazott, iparági szabvány szerinti kriptográfiai hash-algoritmusok, amelyek segítségével a felhasználók jelszavai nem olvasható (plaintext), hanem kizárólag visszafejthetetlen hash-értékként kerülnek tárolásra. Az Adatkezelőnek és munkatársainak az érintett felhasználók jelszavaihoz olvasható formában semmilyen körülmények között nincs hozzáférése.

Service Role Key: A Supabase adminisztrátori jogkörű API-kulcsa, amely a normál felhasználói jogosultságokon túlmutató, szerverszintű adatbázis-hozzáférést tesz lehetővé (beleértve az RLS-szabályok megkerülésének képességét). A service role key kizárólag a Cloudflare Worker titkos környezeti változóiban (Cloudflare Secrets) kerül tárolásra; a kliensoldali kódba soha nem kerül be, és nyilvánosan elérhető fájlban nem szerepelhet. A service role key illetéktelen kézre kerülése azonnali biztonsági incidensnek minősül.

Anon Key (nyilvános kulcs): A Supabase nyilvánosan megosztható API-kulcsa, amelynek önmagában nem tulajdonítható hozzáférési jogosultság — kizárólag az RLS-szabályok és a JWT-hitelesítés által egyidejűleg védett végpontokkal együttesen alkalmazva funkcionál. Az anon key a kliensoldali kódban szerepelhet; ez az iparági szabványnak megfelelő, elfogadott eljárás.

2.5 Incidensfogalmak

Adatvédelmi incidens: A biztonság minden olyan sérülése, amely a Rendszer keretében továbbított, tárolt vagy más módon kezelt személyes adatok véletlen vagy jogellenes megsemmisítését, elvesztését, megváltoztatását, jogosulatlan közlését vagy az azokhoz való jogosulatlan hozzáférést eredményezi [GDPR 4. cikk 12. pont]. A Georto Vision Rendszer vonatkozásában az incidens fogalma alá tartozó helyzetek részletes felsorolását a 13. fejezet tartalmazza.

Bizalmassági incidens: Olyan adatvédelmi incidens, amelynek során személyes adatokhoz jogosulatlan személy fér hozzá, vagy azokat jogosulatlanul közlik (például: felhasználói fiókadatok, profilképek, tevékenységi napló tartalmának kiszivárogtatatása).

Integritási incidens: Olyan adatvédelmi incidens, amelynek során személyes adatokat jogosulatlanul vagy véletlenül módosítanak (például: felhasználói profiladatok jogosulatlan megváltoztatása).

Rendelkezésre állási incidens: Olyan adatvédelmi incidens, amelynek során személyes adatok véletlenül vagy jogosulatlanul elvesznek, megsemmisülnek, vagy hozzáférhetetlenné válnak (például: geodata-fájlokban tárolt személyes adatok véletlen tömeges törlése).

Nem minősülő eset: Olyan, a Rendszeren belül bekövetkező esemény, amely első ránézésre adatvédelmi incidensnek tűnhet, azonban a Rendszer belső, vállalati jellegéből és a szerepköralapú hozzáférés-kezelésből adódóan nem minősül annak, mivel az érintett cselekvés az Adatkezelő utasítása alapján, jogosultságkereteken belül, rendeltetésszerűen valósul meg. A nem minősülő esetek részletes, tételesen felsorolt katalógusát a 13.3 pont tartalmazza.

Incidenskezelő: Az adatvédelmi kapcsolattartó, aki az adatvédelmi incidens észlelésétől annak lezárásáig az incidenskezelési eljárás koordinálásáért felelős. Az incidenskezelő feladatait az Incidenskezelési Szabályzat 4.1 pontja részletezi.

Kockázati szint: Az adatvédelmi incidens által az érintett természetes személyek jogaira és szabadságaira gyakorolt valószínűsíthető hatás mértékét kifejező besorolás, amelynek három fokozata van:

• Alacsony kockázat: Az incidens valószínűsíthetően nem jár kockázattal az érintettekre nézve; NAIH-bejelentési kötelezettség nem keletkezik, de belső dokumentáció szükséges.
• Közepes kockázat: Az incidens valószínűsíthetően kockázattal jár az érintett természetes személyek jogaira és szabadságaira nézve; NAIH-bejelentési kötelezettség keletkezik az észleléstől számított 72 órán belül.
• Magas kockázat: Az incidens valószínűsíthetően magas kockázattal jár az érintett természetes személyek jogaira és szabadságaira nézve; NAIH-bejelentési kötelezettség és érintetti tájékoztatási kötelezettség egyaránt fennáll.

72 órás határidő: A GDPR 33. cikk (1) bekezdésében meghatározott határidő, amelyen belül az Adatkezelő köteles az adatvédelmi incidenst a NAIH-nak bejelenteni, amennyiben az incidens kockázattal jár az érintett személyek jogaira és szabadságaira nézve. A határidő az Adatkezelő általi észlelés időpontjától számítandó.

NAIH: Nemzeti Adatvédelmi és Információszabadság Hatóság — Magyarország illetékes adatvédelmi felügyeleti hatósága, amelynek székhelye: 1055 Budapest, Falk Miksa utca 9–11. A NAIH-hoz az érintett panaszt nyújthat be adatvédelmi jogainak vélt megsértése esetén; az Adatkezelő a valódi adatvédelmi incidenseket e hatóságnak köteles bejelenteni.

Incidensnyilvántartó: Az Adatkezelő által a GDPR 33. cikk (5) bekezdése alapján kötelezően vezetett, valamennyi adatvédelmi incidensre — beleértve az alacsony kockázatú, NAIH-bejelentési kötelezettséggel nem járó eseteket is — vonatkozó belső dokumentáció. Az incidensnyilvántartó részletes tartalmi követelményeit az Incidenskezelési Szabályzat 11.2 pontja határozza meg.

2.6 Infrastruktúra-fogalmak

Supabase: A Rendszer által igénybe vett, felhőalapú backend-as-a-service (BaaS) platform, amelyet a Supabase, Inc. (székhely: 970 Toa Payoh North, #07-04, Singapore 318992) üzemeltet. A Supabase a Rendszer keretében a következő funkciókat látja el:

• Hitelesítés – felhasználói fiókok kezelése, bejelentkezési tokenek kiállítása és érvényesítése (Supabase Auth, auth.users tábla);
• Relációs adatbázis – a profiles, messages, user_messages és user_consents táblák tárolása (Supabase PostgreSQL);
• Fájltárhely – profilképek tárolása (avatars bucket, Supabase Storage).

A Supabase adatfeldolgozói minőségben jár el; adatfeldolgozói szerződés (DPA) az Adatkezelő és a Supabase között megkötésre kerül.

Cloudflare: A Rendszer által igénybe vett, felhőalapú hálózati és infrastruktúra-szolgáltató platform, amelyet a Cloudflare, Inc. (székhely: 101 Townsend St., San Francisco, CA 94107, USA) üzemeltet. A Cloudflare a Rendszer keretében a következő technikai komponenseket biztosítja:

• Cloudflare Workers – az állapotmentes, szerver oldali API-backend futtatókörnyezete; az összes felhasználói kérés ezen keresztül kerül feldolgozásra;
• Cloudflare R2 – objektumtároló (georto-vision-r2), amelyben a feltöltött geodata-fájlok (.fgb és .pmtiles, lásd: 7.1.1), a felhasználónkénti térképkonfigurációk (app_data/maps_{userId}.json) és a tevékenységi napló (app_data/file_log_{timestamp}.json) kerülnek elhelyezésre;
• Cloudflare KV – kulcs-érték tároló, amelyet kizárólag az IP-alapú kérésszám-korlátozáshoz szükséges, 60 másodperces lejáratú számlálók tárolására vesz igénybe a Rendszer (LIMITER névtér).

A Cloudflare adatfeldolgozói minőségben jár el; GDPR-megfelelőségét az EU–US Data Privacy Framework (DPF) biztosítja.

Supabase Auth (auth.users tábla): A Supabase hitelesítési szolgáltatásának belső adatbázistáblája, amely a felhasználói fiókok alapadatait — különösen az e-mail-címet, a titkosított (hash-elt) jelszót, a munkamenet-tokeneket, a fiók állapotát, a fiók létrehozásának időpontját és az utolsó sikeres bejelentkezés időpontját — tárolja. E tábla tartalmához a Cloudflare Worker kizárólag a Supabase Admin API-n keresztül, a service role key felhasználásával, szerver oldali kódból fér hozzá.

Supabase Auth (profiles tábla): A Supabase PostgreSQL adatbázisában elhelyezett, az Adatkezelő által definiált, publikusan olvasható (de módosítás tekintetében RLS-sel védett) tábla, amely tartalmazza a felhasználók egyedi azonosítóját (user_id, UUID, a Supabase Auth auth.users.id értékével megegyező), megjelenített nevét (keresztnév, vezetéknév), szerepkörét, e-mail-címét és a profilkép tárhelyének URL-jét. A tábla minden hitelesített felhasználó számára olvasható; az adott sor módosítása kizárólag az auth.uid() = user_id feltétel teljesülése esetén — vagyis a saját profil tekintetében — engedélyezett, illetőleg Rendszergazda által:

• a Cloudflare Worker megfelelő API-végpontjain keresztül, service role key-jel;
• a Supabase adminisztrációs felület Table Editorén, adminisztrátori jogosultsággal (RLS megkerülése).

A hitelesítési adatok (jelszó, Auth-beli e-mail) a Supabase Auth moduljában kezelhetők; részletesen lásd a 4.2.1 pontot.

Cloudflare R2: A Rendszer elsődleges fájltároló komponense (georto-vision-r2), amely AES-256 titkosítással védi a tárolt adatokat. A bucket gyökérkönyvtárában kizárólag .fgb és .pmtiles kiterjesztésű geodata-fájlok, valamint az app_data/ alatti metaadat-fájlok (maps_{userId}.json, file_log_{timestamp}.json) kerülnek tárolásra. Az R2-ben tárolt adatok kizárólag a Cloudflare Worker API-n keresztül, érvényes JWT-token és megfelelő szerepköri jogosultság megléte esetén érhetők el; közvetlen, nyilvános R2-hozzáférés konfigurálva nincsen.

OpenStreetMap (OSM): Az OpenStreetMap Foundation (OSMF, székhely: St John's Innovation Centre, Cowley Road, Cambridge, CB4 0WS, Egyesült Királyság) által üzemeltetett, nyílt forrású, közösségi alapon szerkesztett térképadatbázis és csempeszolgáltatás, amelyet a Rendszer az alaptérkép megjelenítéséhez vesz igénybe. Az OSM csempeszolgáltatás önálló adatkezelőnek minősül; az Adatkezelő az OSMF adatkezeléséért felelősséget nem vállal.

CDN-könyvtárszolgáltatók: A Rendszer által a JavaScript-könyvtárak (MapLibre GL JS, PMTiles, FlatGeobuf, Supabase JS, proj4js, Turf.js, JSZip) betöltéséhez igénybe vett, tartalom-kiszolgáló hálózati (CDN) infrastruktúrák: unpkg.com, cdnjs.cloudflare.com, cdn.jsdelivr.net. E CDN-szolgáltatók nem minősülnek az Adatkezelő adatfeldolgozóinak, mivel az adatátvitel az érintett böngészőjéből közvetlenül, az Adatkezelő közbeavatkozása nélkül valósul meg.

FTP-szerver (külső): Az Adatkezelő szervezetén kívül, harmadik fél által üzemeltetett, FTP (File Transfer Protocol) vagy az azt titkosított formában megvalósító FTPS/SFTP protokollal elérhető fájlszerver, amelyről Szerkesztő és Rendszergazda szerepkörű felhasználók geodata-fájlokat importálhatnak a Rendszerbe. A külső FTP-szerverek nem képezik az Adatkezelő informatikai infrastruktúrájának részét, és nem minősülnek az Adatkezelő adatfeldolgozóinak. Az Adatkezelő a külső FTP-szerver üzemeltetőjének adatkezelési gyakorlatáért felelősséget nem visel.

Geodata-fájl: A Georto Vision Rendszerbe importálható és kezelhető, geodéziai, térképészeti és térinformatikai adatokat tartalmazó fájl. A Rendszer importálható forrásformátumai: .fgb, .pmtiles, .got, .dxf, .xml, .txt. Az R2 objektumtárban kizárólag .fgb és .pmtiles kiterjesztésű fájlok kerülnek tárolásra; az egyéb forrásformátumok feltöltéskor automatikusan FlatGeobuf (.fgb) formátumba konvertálódnak (részletesen: 7.1.1). A geodata-fájlok elsősorban belső szakmai (műszaki) adatokat tartalmaznak (tereptárgy-koordináták, töréspontok, szintvonalak, terepi felvételezési eredmények). Amennyiben természetes személyekre vonatkozó adatot (pl. ingatlan-tulajdonos neve, projektazonosítóhoz rendelt személynév) is tartalmaznak, az ilyen tartalom személyes adatnak minősül, és annak kezelésére a Szabályzat vonatkozó rendelkezései alkalmazandók.

Tevékenységi napló (audit log): A Rendszer által automatikusan, a Cloudflare Worker szerver oldalán rögzített belső napló, amely az R2-ben tárolt .fgb és .pmtiles fájlok fájlkezelési műveleteit (feltöltés, törlés, átnevezés) rögzíti: az időpontot, a művelet típusát, az elvégző felhasználó nevét és az érintett fájl nevét. R2-ben minden frissítéskor új, időbélyeges fájl jön létre (app_data/file_log_{timestamp}.json, ahol a {timestamp} formátuma: YYYYMMDDHHmmss); a korábbi naplófájlok automatikusan törlődnek, így jellemzően egy aktuális napló áll fenn. A Worker API-n a napló letöltése és törlése fix aliasú útvonalon történik (GET / DELETE /files/app_data/file_log.json), amely a legfrissebb időbélyeges R2-fájlra mutat. A tevékenységi napló belső ellenőrzési eszköz; kizárólag Rendszergazda jogkörrel rendelkező munkatárs számára hozzáférhető (profilpanel → Beállítások → Műveletek ellenőrzése), és kizárólag az Adatkezelő által meghatározott belső célokra vehető igénybe.

WGS84 / EOV: A Rendszer által kezelt két koordináta-rendszer. A WGS84 (World Geodetic System 1984) a GPS-koordináták globálisan elterjedt vonatkozási rendszere (szélességi és hosszúsági fokok). Az EOV (Egységes Országos Vetületi rendszer) a Magyarország területén alkalmazott, vetületi alapú koordináta-rendszer (Kelet és Észak komponensekkel, méterben megadva). A Rendszer a proj4js könyvtár segítségével, kizárólag az érintett böngészőjében, helyi szinten végzi el a WGS84 és EOV koordinátarendszerek közötti átszámítást; az átszámítási folyamat a szerverre nem kerül továbbításra.

---

I. RÉSZ – HOZZÁFÉRÉSI ÉS FELHASZNÁLÓI SZABÁLYOK

---

3. A Rendszerhez való hozzáférés általános szabályai

3.1 A meghívóalapú zárt hozzáférési rendszer

A Georto Vision Rendszer a belső, vállalati jellegéből következően zárt hozzáférési rendszerként működik: a Rendszerbe való regisztrációra kizárólag az Adatkezelő által, Rendszergazda jogkörrel rendelkező munkatárson keresztül kiadott, egyszeri és személyhez szóló meghívó alapján van lehetőség. A Rendszernek nincs nyilvánosan elérhető regisztrációs felülete; ismeretlen vagy azonosítatlan személy a Rendszerbe nem juthat be, és nem is kaphat meghívót.

3.1.1 A meghívó kiadásának feltételei és folyamata

A meghívó kiadása az alábbi feltételek egyidejű teljesítéséhez kötött:

a) Az igény jogszerűsége és munkajogi alapja: Meghívó kizárólag olyan természetes személy részére adható ki, aki az Adatkezelővel munkaviszonyban, megbízási jogviszonyban vagy egyéb, dokumentált szerződéses jogviszonyban áll, és a Rendszer igénybevétele a munkakörének vagy feladatainak ellátásához szükséges. A meghívó kiadása előtt az illetékes vezető szóban vagy írásban jóváhagyja az érintett személy Rendszerhez való hozzáférési igényét.

b) A Rendszergazda kizárólagos jogköre: Meghívót kiadni kizárólag Rendszergazda szerepkörrel rendelkező, érvényes JWT-tokennel hitelesített felhasználó jogosult a POST /invite API-végponton keresztül. A meghívó kiadásának joga nem ruházható át más szerepkörű felhasználóra; e korlátozás szerver oldali kényszerítéssel érvényesül — Szerkesztő vagy Felhasználó szerepkörrel kiadott meghívási kísérlet HTTP 403 Forbidden hibakóddal kerül visszautasításra.

c) A meghívó technikai folyamata: A meghívó kiadásakor a Rendszergazda megadja az új felhasználó e-mail-címét és szerepkörét. A POST /invite API-végpont a következő lépéseket hajtja végre automatikusan:

1. Véletlenszerű, erős ideiglenes jelszó generálása.
2. A felhasználói fiók létrehozása a Supabase Admin API-n keresztül, szerver oldali service role key felhasználásával; a fiók „meghívott" (invited) állapotban jön létre.
3. Az ideiglenes jelszó egy alkalommal megjelenik a Rendszergazda képernyőjén, ahol az vágólapra másolható. E jelszót a Rendszergazda biztonságos csatornán (személyesen, titkosított üzenetküldőn keresztül) adja át az érintett felhasználónak.
4. A profiles táblában az érintett felhasználó sora automatikusan létrejön (on_auth_user_created adatbázis-trigger) a Rendszergazda által megadott e-mail-cím, a rendszer által generált UUID-azonosító és a hozzárendelt szerepkör adataival.

d) A meghívó lejárata: Az ideiglenes jelszó kizárólag az első bejelentkezés céljára érvényes. Az érintett felhasználó az első bejelentkezést követően azonnal köteles az ideiglenes jelszót megváltoztatni (lásd 3.2.1 pont). Az ideiglenes jelszó megismerése harmadik személy által azonnali bejelentési kötelezettséget keletkeztet.

3.1.2 A meghívó személyhez kötöttsége és átruházhatatlanság

A meghívó és az általa létrehozott felhasználói fiók kizárólag az adott természetes személyhez kötött, és semmilyen körülmények között nem ruházható át, nem adható kölcsön, és nem osztható meg más személlyel. Ennek megfelelően:

• Tilos a meghívót harmadik személynek továbbítani vagy azzal az ideiglenes jelszót közölni.
• Tilos az érintett fiókadatokkal más személynek a Rendszerbe belépni.
• Tilos a meghívót megkapó személynek nevében más személy által elvégezni a fiókaktiválást.
• Tilos az aktív felhasználói fiók bejelentkezési adatait (e-mail-cím, jelszó) más személlyel megosztani.

E tilalmak megszegése a Szabályzat súlyos megsértésének minősül, és a 18. fejezetben meghatározott következményeket vonja maga után.

3.2 Fiókaktiválás és az első bejelentkezés kötelezettségei

A fiókaktiválás a fiok-aktivalas.html oldalon valósul meg. Az érintett felhasználó a Rendszergazdától kapott e-mail-cím és ideiglenes jelszó megadásával lép be a fiókaktiváló felületre. A fiókaktiválás technikai folyamata és az azzal összefüggő felhasználói kötelezettségek az alábbiakban kerülnek részletezésre.

3.2.1 Az ideiglenes jelszó azonnali cseréjének kötelezettsége

Az érintett felhasználó a fiókaktiváló felületen az ideiglenes jelszóval való első bejelentkezés után haladéktalanul, még a Rendszer érdemi igénybevétele előtt köteles az ideiglenes jelszót egy általa választott, egyéni jelszóra cserélni. Az ideiglenes jelszóval való prolongált bejelentkezési állapot fenntartása — vagyis a jelszócsere elhalasztása — tilos.

Az ideiglenes jelszó cseréjének kötelezettsége az alábbi indokokon alapul:

• Az ideiglenes jelszót a Rendszergazda is ismeri, ezért annak egyéni jelszóra cserélése nélkül a felhasználói fiók nem tekinthető kizárólagosan az érintett felhasználó által ismert hitelesítő adattal védettnek.
• A biztonságos munkamenet-kezelés alapkövetelménye, hogy minden aktív fiókhoz kizárólag az adott felhasználó által ismert jelszó tartozzon.
• Az ideiglenes jelszó biztonságos csatornán kívüli esetleges kiszivárgásának kockázata az azonnali cserével kiküszöbölhető.

A jelszócsere technikai feltételei és követelményei a 10. fejezetben (jelszókezelési kötelezettségek) kerülnek részletezésre.

3.2.2 Kötelezően megadandó adatok a fiók aktiválásakor

A fiókaktiváló felületen (fiok-aktivalas.html) az érintett felhasználó kizárólag az alábbi táblázatban felsorolt adatokat adja meg. A felhasználói fiókhoz tartozó e-mail-címet a Rendszergazda a meghívó kiállításakor határozza meg; az érintett a fiókaktiváló felületre a bejelentkezési oldalon (bejelentkezes.html) a Rendszergazdától kapott e-mail-cím és ideiglenes jelszó megadásával jut el, ahol az e-mail-cím ismételt megadására nincs szükség.

Az Adatkezelő rögzíti, hogy a fenti kötelező adatok megadása a felhasználói fiók aktiválásának feltétele; azok hiányában a fiók nem aktiválható, és a Rendszer nem vehető igénybe. E kötelezettség nem jelenti az érintett szabad döntési jogának korlátozását, mivel a Rendszer igénybevétele az Adatkezelő belső munkavégzési céljait szolgálja, és a szükséges adatok a munkaviszonyból fakadóan egyébként is az Adatkezelő rendelkezésére állnak.

A fiók aktiválásának további feltétele, hogy az érintett a fiókaktiváló felületen jóváhagyja a Belső Felhasználási Szabályzatot, az Adatvédelmi Tájékoztatót és a Titoktartási Nyilatkozatot (a megfelelő jelölőnégyzetek bejelölésével). A dokumentumok elfogadásának időpontja, verziószáma és az elfogadási esemény adatai a Cloudflare Worker POST /consents API-végpontján keresztül, eseménynapló formájában kerülnek a user_consents táblába: minden elfogadás külön rekordként jön létre, a meglévő sorok módosítása technikailag blokkolva van. A rögzítés után authenticated jogosultsággal utólag nem módosítható és nem törölhető (kivéve a fióktörlést). A technikai részletek a 20.3.3 pontban és a Titoktartási Nyilatkozat 8. fejezetében olvashatók.

3.2.3 Módosított Szabályzat elfogadása meglévő felhasználók esetén

Amennyiben a jelen Szabályzat vagy a kapcsolódó jogi dokumentumok (Adatvédelmi Tájékoztató, Titoktartási Nyilatkozat) bármelyike módosul, a Rendszer a meglévő felhasználók számára a soron következő sikeres bejelentkezés alkalmával — egy dedikált felugró ablak formájában — kéri az új, hatályos verzió megismerését és elfogadását. A frissített feltételek elfogadásának megtagadása vagy elmaradása esetén a Rendszer szolgáltatásai nem vehetők igénybe.

Amennyiben az érintett hosszabb ideig nem használja a Rendszert, és ezen időszak alatt több verzióváltás is történik, a bejelentkezéskor kizárólag a legutolsó, jelenleg hatályos verzió megismerése és elfogadása kötelező; a köztes, elavulttá vált verziók visszamenőleges elfogadása nem szükséges.

A Szabályzat módosításáról szóló rendszerüzenet tájékoztató jellegű; önmagában nem helyettesíti a felhasználó kifejezett, aktív elfogadó nyilatkozatát a felugró ablakban.

A profilkép feltöltése a fiókaktiváló felületen nem lehetséges. Az érintett a fiók sikeres aktiválását követően, a Rendszer felhasználói profilpaneljén opcionálisan tölthet fel profilképet; ennek részletei a 6.3.1 pontban olvashatók.

3.3 A felhasználói fiók személyes jellege és megoszthatatlansága

3.3.1 Az egyszemélyes fiókhasználat elve

Minden egyes felhasználói fiók kizárólag egy konkrét, azonosított természetes személy általi használatra jogosít. A Rendszer kialakítása kizárja a megosztott (shared) fiókok lehetőségét: a profiles táblában minden fiókhoz egyedi UUID-azonosító, egyedi e-mail-cím és egyedi JWT-token tartozik, amelyek alapján a tevékenységi napló az egyes fájlkezelési műveletek elvégzőjét visszakövethetően rögzíti.

Az egyszemélyes fiókhasználat elvéből következik, hogy:

• Tilos egy felhasználói fiókot több személy általi egyidejű vagy felváltva történő használatra rendelni vagy alkalmassá tenni.
• Tilos a bejelentkezési adatokat (e-mail-cím, jelszó) munkatársaknak, feletteseknek, helyetteseknek vagy bármely más személynek átadni.
• Tilos más személy fiókjával a Rendszerbe belépni, még annak kifejezett engedélyével sem.
• Tilos a saját bejelentkezési munkamenetet — különösen megosztott eszközön — felügyelet nélkül aktív állapotban hagyni.

Ha valamely feladatkör ellátásához új személy számára szükséges a Rendszerhez való hozzáférés, a megoldás kizárólag új meghívó kiadása és új fiók létrehozása lehet.

3.3.2 A fiókok névlegesítésének tilalma

Az Adatkezelő kifejezetten tiltja az ún. „névleges fiókok" — vagyis olyan fiókok — létrehozását, amelyek nem egy valódi, azonosított személyhez, hanem egy munkakörhoz, pozícióhoz, szervezeti egységhez vagy feladathoz kötöttek (pl. „administrator@georto.com", „szerkeszto1@georto.com"). Minden fiókhoz valódi, teljes nevű természetes személy tartozik, akinek személyes felelőssége kiterjed a fiók keretében végzett valamennyi tevékenységre.

3.3.3 Felelősség a fiókhoz kapcsolódó tevékenységekért

Az érintett felhasználó teljes felelősséggel tartozik minden olyan tevékenységért, amely az ő felhasználói fiókjából kerül végrehajtásra — beleértve azokat az eseteket is, amelyekben a Rendszerbe való illetéktelen belépés az érintett gondatlansága (jelszó kiszivárogtatatása, felügyelet nélkül hagyott munkamenet, gyenge jelszó alkalmazása) miatt vált lehetővé. E felelősség nem zárja ki az Adatkezelő azon kötelezettségét, hogy az adatvédelmi incidenst a megfelelő eljárásrend szerint kezelje és dokumentálja.

3.4 A hozzáférési jogosultság megszűnésének esetei

A Rendszerhez való hozzáférési jogosultság az alábbi esetekben szűnik meg:

3.4.1 A munkaviszony vagy egyéb szerződéses jogviszony megszűnése

Ha az érintett felhasználó és az Adatkezelő között fennálló munkaviszony, megbízási jogviszony vagy egyéb szerződéses jogviszony bármely okból megszűnik, a Rendszergazda köteles az érintett felhasználó fiókját legkésőbb a jogviszony megszűnésének napján letiltani, majd — a megőrzési idők figyelembevételével — törölni. Előre tervezett jogviszony megszűnés esetén (pl. felmondás, lejáró határozott idejű szerződés) a Rendszergazda a megszűnés napján, nem tervezett esetben (pl. azonnali hatályú felmondás, haláleset) az esemény bekövetkezésekor haladéktalanul gondoskodik a hozzáférés letiltásáról.

3.4.2 A munkakör megváltozása

Ha az érintett felhasználó munkaköre megváltozik, és az új munkakör a Rendszer igénybevételét nem igényli, a Rendszergazda az átállás napján letiltja a hozzáférést. Ha az új munkakör eltérő szerepkörű hozzáférést igényel, a Rendszergazda a szükséges szerepkör-módosítást elvégzi (lásd 4.5 pont), és az előző szerepkörhöz tartozó ideiglenes vagy feleslegessé vált adatokat kezeli.

3.4.3 A hozzáférési jogosultság felfüggesztése biztonsági okból

A Rendszergazda, illetőleg az adatvédelmi kapcsolattartó jogosult a felhasználói fiókot azonnali hatállyal letiltani, ha alapos gyanú merül fel arra vonatkozóan, hogy:

• a fiókhoz tartozó hitelesítő adatok illetéktelen személy kezébe kerültek;
• a fiókból szokatlan, a felhasználó szokásos tevékenységétől eltérő, gyanús műveletek kerültek végrehajtásra;
• a fiók adatvédelmi incidens érintettje vagy forrása lehet.

A letiltás visszafordítható; az incidensvizsgálat lezárultával — amennyiben a gyanú alaptalannak bizonyul — a hozzáférés visszaállítható.

3.4.4 A felhasználó kérésére történő törlés

Az érintett felhasználó írásban kérheti a felhasználói fiókjának végleges törlését az adatvédelmi kapcsolattartótól, illetőleg a Rendszergazdától. A törlési kérelem teljesítésekor a Rendszergazda a DELETE /user/{userId} API-végponton keresztül végrehajtja a fiók visszafordíthatatlan törlését, amely kiterjed a Supabase Auth-fiókra (e-mail-cím, titkosított jelszó, munkamenet-tokenek, fiók létrehozásának és utolsó bejelentkezés időpontja), a profiles tábla sorára (keresztnév, vezetéknév, szerepkör, e-mail-cím, profilkép URL), a user_messages tábla olvasottsági rekordjaira, a user_consents tábla elfogadási rekordjaira, a felhasználóhoz tartozó térképkonfigurációkra (Cloudflare R2: app_data/maps_{userId}.json), valamint — amennyiben az adott felhasználóhoz tartozó profilképfájl a Supabase Storage-ban tárolódik — az avatars/{userId}/ mappára. A tevékenységi naplóban szereplő korábbi bejegyzések a napló megőrzési idejéig megmaradnak, azonban a felhasználó személyes neve anonimizálásra kerül: a DELETE /user/{userId} API-végpont az uploaded_by, deleted_by és renamed_by mezőkben szereplő nevet „Törölt felhasználó" értékre cseréli. Az anonimizálást követően e mezők már nem minősülnek személyes adatnak, ezért a naplóbejegyzések megőrzése a GDPR 6. cikk (1) bekezdés f) pontja (jogos érdek — belső ellenőrizhetőség és audit) alapján jogszerű.

3.4.5 Az Adatkezelő döntése alapján történő visszavonás

Az Adatkezelő fenntartja a jogot arra, hogy a Rendszerhez való hozzáférési jogosultságot bármely felhasználó vonatkozásában, indokolás nélkül visszavonja, ha azt a Rendszer biztonságos üzemeltetése, az adatvédelmi előírások betartása vagy az Adatkezelő jogos érdeke szükségessé teszi.

---

4. Szerepkörök, jogosultságok és felelősségi körök

4.1 A szerepköralapú jogosultságkezelés (RBAC) elve

A Georto Vision Rendszerben a felhasználók hozzáférési jogosultságai szerepköralapú hozzáférés-kezelési (RBAC) rendszer szerint kerülnek meghatározásra és érvényesítésre. E rendszer lényege, hogy a Rendszer egyes funkcióihoz és adataihoz való hozzáférési jogosultságokat nem egyedileg, hanem az egyes szerepkörökhöz rendelten definiálja az Adatkezelő, és a konkrét jogosultságok a felhasználóhoz rendelt szerepkör által automatikusan meghatározásra kerülnek.

A Rendszerben három szerepkör kerül alkalmazásra, hierarchikus sorrendben: Rendszergazda (legmagasabb jogosultságszint) — Szerkesztő — Felhasználó (alap-jogosultságszint). Minden magasabb szintű szerepkör teljes mértékben magában foglalja az alacsonyabb szintű szerepkörhöz tartozó összes jogosultságot; a felsőbb szintek kizárólag addicionális — az alacsonyabb szinteken nem elérhető — jogosultságokkal egészítik ki az alsóbb szinteket.

4.1.1 A jogosultságérvényesítés három szintje

A Rendszer a szerepköralapú hozzáférés-korlátozást három egymást kiegészítő, egymástól független szinten kényszeríti ki, biztosítva, hogy az egyes szintek egyikének megkerülése esetén a többi szint önállóan is védelmet nyújtson:

1. szint — Cloudflare Worker szerver oldali szerepkörellenőrzés: A Cloudflare Worker minden védett API-végponton ellenőrzi, hogy a kéréshez mellékelt JWT-token alapján azonosított felhasználó profiles táblában tárolt szerepköre feljogosítja-e a kérelmezőt az adott művelet elvégzésére. Ha a szükséges szerepkör nem áll fenn, a szerver HTTP 403 Forbidden hibakóddal utasítja vissza a kérést; a kérés adatbázis-szinten egyáltalán nem kerül tovább feldolgozásra. Ez a szint tekinthető az elsődleges biztonsági vonalnak, amely kizárólag szerver oldali logika alapján, az ügyfél oldalától függetlenül érvényesül.

2. szint — Supabase adatbázis sorszintű biztonsági szabályok (RLS): A Supabase PostgreSQL adatbázisában beállított Row Level Security (RLS) szabályok és adatbázis-triggerek korlátozzák, hogy a hitelesített felhasználók a táblák mely sorait olvashatják, módosíthatják vagy törölhetik. Az RLS-szabályok az auth.uid() függvény segítségével azonosítják a bejelentkezett felhasználót, és a user_id mezővel való összevetés alapján döntik el a hozzáférhetőséget (pl. auth.uid() = user_id). E réteg — különösen a jogi dokumentum-elfogadások és a rendszerüzenet-olvasottság nyilvántartása esetén — tartalék-védelmet nyújt arra az esetre is, ha a szerver oldali ellenőrzés valamilyen programozási hiba miatt megkerülhetővé válna: az adatbázis maga utasítja vissza a jogosulatlan hozzáférési kísérletet.

3. szint — Kliens oldali felületi korlátozás: Az updateUIByRole() JavaScript-függvény a bejelentkezett felhasználó szerepkörének megfelelően elrejti vagy letiltja a jogosulatlan funkciókhoz tartozó felhasználói felületi elemeket (gombokat, menüpontokat, beviteli mezőket). Ez a szint kizárólag a felhasználói élményt és az átláthatóságot szolgálja; önállóan nem tekinthető biztonsági intézkedésnek, mivel a böngészőben futó JavaScript-kód módosítható. Az érdemi biztonsági védelmet az 1. és 2. szint együttesen biztosítja.

4.1.2 A jogosultságok kizárólagossága és korlátai

A Rendszerben érvényes jogosultságokat az Adatkezelő határozza meg. A felhasználók jogosultságaikat kizárólag a hozzájuk rendelt szerepkör keretein belül gyakorolhatják, és semmilyen körülmények között nem kísérelhetik meg a jogosultsági korlátok technikai eszközökkel való megkerülését. Az erre irányuló kísérlet — beleértve az API-végpontok közvetlen hívását böngészőn kívüli eszközökkel, a JWT-token hamisítására irányuló próbálkozásokat, az RLS-szabályok kikerülésének kísérletét, vagy a kliens oldali kód módosítását — a Szabályzat súlyos megsértésének minősül, és a 18. fejezetben meghatározott következményeket vonja maga után, ideértve a legsúlyosabb esetben a büntető- vagy polgári jogi felelősséget is.

4.2 A Rendszergazda szerepkör

4.2.1 A Rendszergazda jogosultságainak teljeskörű leírása

A Rendszergazda a Rendszer legmagasabb jogosultságszintű felhasználója, akit az Adatkezelő kifejezetten megbíz a Rendszer felhasználói és tartalmi szintű üzemeltetésével. A Rendszergazda az alábbi jogosultságokkal rendelkezik:

Felhasználókezelési jogosultságok:

A profiles táblában tárolt profiladatok (keresztnév, vezetéknév, e-mail, szerepkör, profilkép URL) Rendszergazda esetén nemcsak a Worker API-n, hanem a Supabase adminisztrációs felület Table Editorén is módosíthatók. Ahol dedikált Worker API-végpont áll rendelkezésre, az az elsődleges út; a Supabase admin felület kivételes, a normál működésen kívüli belső adminisztrációs beavatkozásra, vagy olyan mezők módosítására szolgál, amelyekhez nincs külön API (szerepkör). A hitelesítési adatok (jelszó) a Supabase Auth moduljában vagy a megfelelő API-végponton módosíthatók. A profilpanel → Beállítások → Supabase megnyitása menüpont a Supabase adminisztrációs felületre visz.

Fájlkezelési jogosultságok:

Tevékenységi napló kezelési jogosultságok:

Térképkezelési és egyéb jogosultságok:

4.2.2 A Rendszergazda fokozott felelőssége és korlátai

Az emelt jogosultságszint fokozott felelősséggel jár. A Rendszergazda az alábbi korlátokat köteles maradéktalanul betartani:

a) A jogosultságok kizárólag feladatvégzési célra vehetők igénybe. A Rendszergazda az emelt jogosultságait — különösen más felhasználók adataival való interakciót (e-mail-cím módosítás, jelszóvisszaállítás, fiók-törlés) — kizárólag az Adatkezelő által számára meghatározott, konkrét feladatok elvégzése érdekében veheti igénybe. A jogosultságok kíváncsiságból, személyes érdekből vagy jogosulatlan célból történő felhasználása tilos.

b) A tevékenységi napló visszakövethetőséget biztosít. A Rendszergazda által elvégzett fájlkezelési műveletek a tevékenységi naplóban rögzítésre kerülnek. A Rendszergazda ezt a körülményt tudomásul veszi, és a napló tartalma alapján tevékenységéről elszámolni köteles.

c) A service role key kizárólagos titkossága. A Cloudflare Worker titkos változókban tárolt Supabase service role key az Adatkezelő legérzékenyebb technikai titkának minősül. A Rendszergazda — amennyiben a Rendszer fejlesztésével is megbízott — köteles biztosítani, hogy a service role key semmilyen körülmények között ne kerüljön a kliensoldali kódba, nyilvánosan elérhető fájlba, verziókövetési rendszerbe (git), vagy harmadik személy tudomására.

d) Más felhasználók adatainak védelme. Noha a Rendszergazda technikailag hozzáfér más felhasználók profiladataihoz (nevéhez, e-mail-címéhez, szerepköréhez), e hozzáférés kizárólag az adminisztrációs feladatok elvégzéséhez jogosítja fel. A más felhasználók személyes adatainak felesleges megtekintése, másolása, feljegyzése vagy harmadik személy felé való közlése tilos, és adatvédelmi incidensnek minősülhet.

e) Jelszóvisszaállítás biztonsági protokollja. Más felhasználó jelszavának visszaállításakor a Rendszergazda köteles az újonnan generált ideiglenes jelszót kizárólag az érintett felhasználónak, biztonságos csatornán (személyesen vagy titkosított üzenetküldő alkalmazáson keresztül) átadni. Az ideiglenes jelszó e-mailben, titkosítatlan kommunikációban, nyílt csatornán vagy harmadik személynek való átadása tilos.

4.2.3 A Rendszergazdára vonatkozó különös kötelezettségek

A Rendszergazda az általános felhasználói kötelezettségeken felül az alábbi különös kötelezettségek teljesítésére is köteles:

1. Fiók-inaktivitás figyelemmel kísérése: A Rendszergazda rendszeresen ellenőrzi a felhasználói fiókok aktivitását, és haladéktalanul letiltja azokat a fiókokat, amelyek tulajdonosainak jogviszonya megszűnt és amelyek letiltása egyéb csatornán még nem érkezett meg hozzá.

2. Tevékenységi napló rendszeres átvizsgálása: A Rendszergazda — az adatvédelmi kapcsolattartóval együttműködve — rendszeresen, de legalább negyedévente átvizsgálja a tevékenységi napló tartalmát a rendellenes műveletek észlelése érdekében.

3. Tevékenységi napló megőrzési idejének betartása: A Rendszergazda gondoskodik arról, hogy az egy évnél régebbi tevékenységi napló bejegyzések törlésre kerüljenek (ajánlott megőrzési idő: legfeljebb 1 év), kivéve, ha jogszabályi kötelezettség vagy folyamatban lévő incidenseljárás a hosszabb megőrzést szükségessé teszi.

4. Beléptetési folyamat és kiléptetési folyamat koordinálása: A Rendszergazda felelős az új felhasználók meghívásának és a hozzáférési jogosultságok megvonásának munkáltatói döntésekkel összhangban történő, határidőben való végrehajtásáért.

5. Elsőszintű biztonsági észlelés: A Rendszergazda azonnali technikai intézkedéseket igénylő incidensgyanú esetén — az adatvédelmi kapcsolattartóval egyeztetve — köteles haladéktalanul elvégezni a 13.4 pontban meghatározott azonnali technikai lépéseket (hozzáférés letiltása, bizonyítékmentés, terjedés megállítása).

4.3 A Szerkesztő szerepkör

4.3.1 A Szerkesztő jogosultságainak leírása

A Szerkesztő a Rendszer geodata-tartalmát kezelő munkatárs, aki rendelkezik a Felhasználó összes jogosultságával, ezenfelül az alábbiakkal:

Fájlkezelési jogosultságok:

Térképkezelési jogosultságok (a Felhasználóéval azonos, de megosztási lehetőséggel):

4.3.2 A Szerkesztőre vonatkozó korlátozások

A Szerkesztő az alábbi tevékenységeket nem jogosult elvégezni; ezek kísérlete HTTP 403 Forbidden hibakódot eredményez szerver oldalon:

• Más felhasználó meghívása (POST /invite).
• Más felhasználó e-mail-címének módosítása (POST /update-email).
• Más felhasználó jelszavának visszaállítása (POST /reset-user-password).
• Más felhasználó szerepkörének megváltoztatása (Supabase profiles tábla, dashboardon keresztül).
• Más felhasználó fiókjának törlése (DELETE /user/{userId}).
• A tevékenységi napló megtekintése (GET /files/app_data/file_log.json).
• A tevékenységi napló törlése (DELETE /files/app_data/file_log.json).

A Szerkesztő adatvédelmi szempontból az Adatkezelő nevében jár el, és adatkezelői önállósággal nem rendelkezik. A Rendszerben általa végzett valamennyi tevékenység — így különösen más munkatárs által feltöltött fájl megtekintése, átnevezése vagy törlése — az Adatkezelő utasításai alapján végzett, jogosultságkereteken belüli belső vállalati csapatmunkának minősül (lásd 5.3 pont).

4.4 A Felhasználó (olvasói) szerepkör

4.4.1 A Felhasználó jogosultságainak leírása

A Felhasználó a Rendszer alap-jogosultságszintű tagja, akinek jogosultságai a térképes megjelenítésre, a megtekintésre és a saját konfigurációk kezelésére terjednek ki:

Térképes és megtekintési jogosultságok:

Fiókkezelési jogosultságok (saját fiókra vonatkozóan):

4.4.2 A Felhasználóra vonatkozó korlátozások

A Felhasználó az alábbi tevékenységeket nem jogosult elvégezni; kísérletük HTTP 403 Forbidden hibakódot eredményez:

• Geodata-fájl feltöltése, átnevezése vagy törlése.
• FTP-böngészés vagy FTP-importálás.
• Más felhasználó meghívása.
• Más felhasználó bármely adatának módosítása.
• Más felhasználó fiókjának törlése.
• A tevékenységi napló megtekintése vagy törlése.
• Bármely rendszerszintű adminisztrációs művelet.

4.5 A szerepkörök közötti átjárás és módosítás szabályai

4.5.1 A szerepkör-módosítás kizárólagos jogköre

Egy felhasználó szerepkörét kizárólag Rendszergazda módosíthatja a Supabase profiles tábla role mezőjének frissítésével, a Supabase dashboardon keresztül (dedikált Worker API-végpont nélkül). A felhasználó saját szerepkörét nem módosíthatja.

4.5.2 A szerepkör-módosítás hatálya és eljárásrendje

A szerepkör-módosítás az alábbi szabályok szerint zajlik:

a) Kötelező munkáltatói jóváhagyás: A szerepkör-módosítást az illetékes vezető szóban vagy írásban jóváhagyja a Rendszergazda felé. A Rendszergazda önállóan, a szükséges jóváhagyás nélkül nem változtathat szerepkört.

b) Azonnali hatály: A szerepkör-módosítás a profiles tábla frissítésével azonnal hatályba lép. Az érintett felhasználó következő API-kérésétől kezdve az új szerepkörhöz tartozó jogosultságok érvényesülnek; a módosítás nem igényli az érintett kijelentkezését, bár ajánlott az aktív munkamenet lezárása és újraindítása a felhasználói felületi frissítés érdekében.

c) Jogosultság-csökkentés esetén haladéktalan hatályosítás: Ha a szerepkör-módosítás jogosultság-csökkentéssel jár (pl. Rendszergazdából Felhasználóvá), a módosítást a lehetséges visszaélések megelőzése érdekében haladéktalanul el kell végezni. Amennyiben a csökkentett jogosultságú állapot azonnali hatályra szorul (pl. biztonsági esemény esetén), a Rendszergazda a szerepkör-módosítás helyett a fiók letiltásával is élhet.

d) Az érintett tájékoztatása: A Rendszergazda a szerepkör-módosításról az érintett felhasználót haladéktalanul tájékoztatja, megjelölve a módosítás okát és hatályba lépésének időpontját.

e) Dokumentálás: A szerepkör-módosításokat a Rendszer nem rögzíti automatikusan. A Rendszergazda köteles a szerepkör-módosítás tényét, időpontját, az érintett felhasználó nevét, a korábbi és az új szerepkört, valamint a módosítás jogalapját (pl. vezetői jóváhagyás) az Adatkezelő belső adminisztrációs nyilvántartásában, a Rendszeren kívül manuálisan rögzíteni. E nyilvántartást a jogviszony megszűnéséig meg kell őrizni.

4.5.3 Ideiglenes jogosultságbővítés tilalma

A Rendszerben nincs lehetőség ideiglenes jogosultságbővítésre (pl. egy Felhasználó ideiglenes Szerkesztővé tételére). Amennyiben egy felhasználónak átmeneti időre magasabb jogosultságszintre van szüksége, a megoldás kizárólag a szerepkör végleges módosítása — majd a feladat elvégzése utáni visszaállítása — lehet, amelyhez minden esetben szükséges az illetékes vezető jóváhagyása.

4.6 Helyettesítési rend és ügyeleti elérhetőség

4.6.1 A Rendszergazda helyettesítése

Ha a Rendszergazda feladatait ellátó munkatárs tartósan — tervezett (szabadság, képzés) vagy nem tervezett (betegség, baleset) okból — nem elérhető, az alábbi helyettesítési rend lép életbe:

1. Elsődleges helyettes: Az Adatkezelő által előre kijelölt, Rendszergazda szerepkörrel szintén rendelkező másodlagos Rendszergazda (amennyiben ilyen kijelölésre kerül).
2. Másodlagos helyettes: Ha elsődleges helyettes nem áll rendelkezésre, az ügyvezető vagy az általa haladéktalanul kijelölt személy látja el az incidenskezelési szempontból sürgős Rendszergazdai feladatokat.

Az Adatkezelő ajánlja, hogy az éles üzemelési időszakban legalább két Rendszergazda szerepkörrel rendelkező munkatárs legyen aktív fiókkal jelen a Rendszerben, a helyettesítés zökkenőmentes biztosítása érdekében.

4.6.2 Ügyeleti elérhetőség adatvédelmi incidensek esetén

Az adatvédelmi incidensek időkritikus jellege — különösen a GDPR 33. cikke szerinti 72 órás bejelentési határidő — miatt a Rendszergazda és az adatvédelmi kapcsolattartó munkaidőn kívüli elérhetőségét is biztosítani kell. Az ügyeleti elérhetőség rendjét az Adatkezelő belső munkarendje határozza meg; az ügyeleti telefonszám és e-mail-cím az Incidenskezelési Szabályzat 4.3 pontjában kerül meghatározásra.

4.6.3 A helyettes jogköreinek korlátozása

A helyettes a Rendszergazda feladatait és jogosultságait kizárólag a helyettesítés időtartamára, és kizárólag az ellátandó feladatok elvégzéséhez szükséges mértékben veheti igénybe. A helyettes köteles az általa elvégzett adminisztrációs műveleteket dokumentálni, és azokról a Rendszergazda visszatérésekor tájékoztatást adni.

---

5. A rendeltetésszerű és elfogadható használat szabályai

5.1 A megengedett használat általános keretei

A Georto Vision Rendszer kizárólag az Adatkezelő szervezetének belső, munkavégzési céljaira vehető igénybe. A Rendszer rendeltetése — amelynek keretein belül valamennyi tevékenység megengedettnek tekintendő — a következőkre terjed ki:

• geodéziai, térképészeti és térinformatikai fájlok belső kezelése (feltöltés, megjelenítés, megtekintés, átnevezés, törlés);
• csapatszintű térinformatikai együttműködés (fájlok és térképkonfigurációk megosztása a Rendszer belső felhasználói között);
• terepi mérések és koordináta-átszámítási feladatok elvégzése;
• felhasználói fiókok és jogosultságok kezelése (kizárólag Rendszergazda által);
• a Rendszer technikai állapotának és az adatkezelési tevékenységek belső ellenőrzése (kizárólag Rendszergazda által, a tevékenységi napló útján).

A Rendszer igénybevétele minden esetben a fentiek valamelyikével összefüggő, konkrét munkavégzési feladathoz kötött. Az e kereteken kívül eső tevékenységek — még ha azok technikailag lehetségesek lennének is — nem minősülnek megengedett használatnak.

5.2 Tilalmas tevékenységek és visszaélések

Az alábbiakban felsorolt tevékenységek a Szabályzat súlyos megsértésének minősülnek, és a 18. fejezetben meghatározott következményeket vonják maguk után. A felsorolás nem taxatív: az Adatkezelő a jelen pontban nem nevesített, de egyértelműen visszaélésszerű vagy jogellenes magatartásokat is a Szabályzat megsértéseként kezeli.

5.2.1 Jogosulatlan hozzáférési kísérletek tilalma

Tilos minden olyan kísérlet, amelynek célja a Rendszer jogosultságkezelési mechanizmusainak megkerülése, a hozzáférés-vezérlés kijátszása, vagy jogosultságon felüli funkciók elérése. E tilalom alá tartozik különösen:

• Más felhasználó hitelesítő adataival (e-mail-cím és jelszó kombinációjával) a Rendszerbe való belépési kísérlet — saját jogosultságon felüli funkciók elérése céljából is.
• JWT-token hamisítására, módosítására vagy visszafejtésére irányuló kísérlet.
• A Cloudflare Worker szerver oldali szerepkör-ellenőrzés megkerülési kísérlete, beleértve az API-végpontok közvetlen, böngészőn kívüli eszközökkel (pl. curl, Postman, szkriptek) való hívását magasabb jogosultságot feltételező kérések küldése érdekében.
• A Supabase RLS-szabályok kikerülésére irányuló SQL-injekciós vagy egyéb kísérlet.
• A kliens oldali JavaScript-kód módosítása a felületi jogosultsági korlátozások megkerülése érdekében.
• Bruteforce vagy szótáras jelszókipróbálási kísérlet bármely felhasználói fiókkal szemben.
• A Cloudflare R2 objektumtároló közvetlen elérési kísérlete a Cloudflare Worker API megkerülésével.

5.2.2 A Rendszer más célra való felhasználásának tilalma

Tilos a Rendszert az 5.1 pontban meghatározott belső munkavégzési kereteken kívüli célra igénybe venni. E tilalom alá tartozik különösen:

• A Rendszer vagy az abban tárolt adatok kereskedelmi célú felhasználása, értékesítése vagy harmadik fél részére való hozzáférhetővé tétele.
• A Rendszerben tárolt geodata-fájlok, térképkonfigurációk vagy felhasználói adatok jogosulatlan külső megosztása, nyilvánosságra hozatala, publikálása vagy más szervezet részére való átadása.
• A Rendszer felhasználása személyes célokra, az Adatkezelő munkavégzési feladataival semmilyen összefüggésben nem álló tevékenységekre.
• A Rendszerbe való belépés és az adatok megtekintése kíváncsiságból vagy személyes érdekből, konkrét munkavégzési feladat nélkül.
• A Rendszer felhasználása más személyekre vonatkozó adatok összegyűjtésére (profilalkotás, megfigyelés) az Adatkezelő által meghatározott belső ellenőrzési és naplózási kereteken kívül.
• Jogsértő, megtévesztő, becsületsértő vagy jogszabályba ütköző tartalom feltöltése a Rendszerbe.

5.2.3 Harmadik fél részére való hozzáférés-átadás tilalma

Tilos a Rendszerhez való hozzáférést — bármilyen formában és bármilyen céllal — az Adatkezelő szervezetén kívüli személyek vagy szervezetek részére biztosítani, illetőleg lehetővé tenni. E tilalom alá tartozik különösen:

• A saját bejelentkezési adatok (e-mail-cím, jelszó) külső személynek való átadása vagy nyilvánosságra hozatala.
• Aktív munkamenettel rendelkező eszköz felügyelet nélküli hagyása olyan helyszínen, ahol külső személy ahhoz hozzáférhet.
• A Rendszer elérési URL-jének és az ahhoz tartozó hitelesítő adatoknak külső személynek való megmutatása vagy átadása.
• A meghívó kiadásának kikényszerítése olyan személy számára, aki az Adatkezelővel semmilyen jogviszonyban nem áll.
• A Rendszerhez való hozzáférés közvetítőként való biztosítása harmadik fél részére (pl. az érintett felhasználó nevében, annak megbízásából elvégzett, de ténylegesen más személy javára irányuló adatkezelési tevékenység).

5.2.4 A Rendszer terhelésének szándékos növelése (DoS) tilalma

Tilos a Rendszer backend infrastruktúrájának szándékos, aránytalanul nagy mértékű terhelése, amely más felhasználók Rendszer-hozzáférését akadályozhatja, vagy amely a Cloudflare Worker IP-alapú kérésszám-korlátozási mechanizmusát (rate limiter) szándékosan aktiválja. E tilalom alá tartozik különösen:

• Automatizált szkriptek, botok vagy egyéb nem emberi vezérlésű eszközök alkalmazása tömeges API-kérések küldésére.
• A percenkénti 1000 kérést meghaladó kérésmennyiség tudatos generálása a limitált API-végpontokon, amely a HTTP 429 Too Many Requests hibakódot kiváltja.
• A Rendszer szándékos leterheltté tételére alkalmas egyéb módszerek alkalmazása.

Megjegyzés — PMTiles / nagy fájl megjelenítése: Nem vonatkozik az IP-alapú percenkénti kérésszám-korlát a /files/… útvonalon érkező GET és HEAD módszerű kérésekre. Egyetlen PMTiles-réteg betöltése is sok párhuzamos kérést generálhat; ez a térképmegjelenítés normális és elvárt működése, és nem minősül e tilalom megsértésének, amennyiben a felhasználó nem terhel le szándékosan más API-végpontokat.

Az IP-alapú kérésszám-korlátozás szándékolatlan, véletlenszerű aktiválása (pl. fejlesztési vagy tesztelési tevékenység következtében) nem minősül e tilalom megsértésének, amennyiben a felhasználó haladéktalanul felhagy a terhelést okozó tevékenységgel.

5.2.5 Biztonsági sérülékenységek kezelése

Amennyiben a Rendszer felhasználója a Rendszer működésében biztonsági sérülékenységet, programozási hibát vagy jogosultságkezelési anomáliát észlel, köteles azt haladéktalanul az adatvédelmi kapcsolattartónak vagy a Rendszergazdának bejelenteni. A sérülékenység felfedezője azt maga nem aknázhatja ki, és harmadik félnek sem adhatja tovább. Az Adatkezelő a jóhiszeműen bejelentett sérülékenységeket a felhasználóval szemben hátrányos következmény nélkül kezeli.

5.3 A belső csapatmunka mint rendeltetésszerű használat

A Georto Vision belső, vállalati jellegéből adódóan a Rendszer kialakítása és rendeltetése kifejezetten a csapatszintű együttműködést feltételezi és teszi lehetővé. Az ebből következő, látszólag más felhasználó adataival való interakciónak tűnő tevékenységek a Rendszer rendeltetésszerű, az Adatkezelő utasítása alapján végzett, jogosultságkereteken belüli belső munkának minősülnek — nem jogosulatlan hozzáférésnek, és nem adatvédelmi incidensnek.

5.3.1 Más felhasználó fájljaival való interakció szabályai

Az a körülmény, hogy a Cloudflare R2 objektumtárolóban az összes feltöltött geodata-fájl közösen, minden Szerkesztő és Rendszergazda számára hozzáférhető tárterületen kerül elhelyezésre, az Adatkezelő tudatos és szándékos rendszertervezési döntésének eredménye. Ennek megfelelően az alábbi műveletek — szerepköri jogosultságon belül végrehajtva — nem minősülnek jogosulatlan adathozzáférésnek és nem minősülnek adatvédelmi incidensnek:

A fentiek ellenére az Adatkezelő elvárja, hogy a munkatársak egymás munkájának eredményeit — beleértve a feltöltött fájlokat is — szakmai körültekintéssel kezeljék: a más munkatárs által feltöltött, aktuálisan szükséges fájlok indokolatlan törlése vagy átnevezése — noha technikailag megengedett és jogilag rendeltetésszerű — belső munkaszervezési szempontból kerülendő, és szükség esetén munkajogi fegyelmezési következményeket vonhat maga után.

5.3.2 Rendszergazdai fiókkezelési műveletek jogszerűsége

A Rendszergazda által — az Adatkezelő megbízásából és utasítása alapján — végzett alábbi felhasználói fiókkezelési műveletek szintén rendeltetésszerű belső munkavégzésnek minősülnek, és nem tekinthetők illetéktelen adathozzáférésnek vagy adatvédelmi incidensnek:

• más felhasználó e-mail-címének módosítása (pl. névváltozás, e-mail-cím változása esetén);
• más felhasználó jelszavának visszaállítása (pl. elfelejtett jelszó, biztonsági esemény esetén);
• más felhasználó szerepkörének módosítása (pl. munkakörváltás esetén);
• más felhasználó fiókjának törlése (pl. jogviszony megszűnésekor);
• új felhasználó fiókjának létrehozása meghívón keresztül.

E műveletek jogszerűségének alapja: (a) az Adatkezelő munkáltatói jogkörébe tartozó adminisztrációs tevékenységek; (b) az Adatkezelő jogos érdekén alapuló adatkezelési jogalap [GDPR 6. cikk (1) bek. f) pont]; (c) a RBAC-rendszer által kontrollált, szerver oldalon kizárólag Rendszergazda számára engedélyezett műveletek.

5.3.3 A tevékenységi napló rendeltetésszerű felhasználása

A tevékenységi napló megtekintése és kezelése — kizárólag Rendszergazda által — az alábbiakra terjed ki rendeltetésszerűen:

• Belső visszakövethetőség biztosítása: Annak megállapítása, hogy egy adott fájlt ki és mikor töltött fel, nevezte át vagy törölte. Ez különösen fontos véletlen törlés esetén (a törlés ténye visszakereshető, de a fájl nem állítható vissza).
• Rendszerhiba vagy incidensgyanú esetén a körülmények rekonstruálása: A naplóbejegyzések segítségével megállapítható, hogy egy adott időablakban milyen műveletek kerültek elvégzésre, és azok egybeesnek-e a rendszerhiba vagy az incidens időpontjával.
• Belső szervezeti folyamatok dokumentálása: A munkafolyamatok átláthatóságának biztosítása az Adatkezelő számára.

A tevékenységi napló nem használható fel az egyes felhasználók teljesítményének automatizált értékelésére, munkaidejük figyelemmel kísérésére, fegyelmezési céllal való szankcionálásra, vagy bármely más, a fentiekben nem meghatározott célra. A naplóhoz kizárólag Rendszergazda férhet hozzá; harmadik személynek csak jogszabályi kötelezettség vagy hatósági megkeresés alapján adható ki.

5.4 A Rendszer kizárólag belső, munkavégzési célra való igénybevétele

5.4.1 A belső munkavégzési cél értelmezése

A Rendszer „belső, munkavégzési célra" való igénybevétele azt jelenti, hogy a Rendszerben végzett minden tevékenységnek — közvetve vagy közvetlenül — az Adatkezelő geodéziai, térképészeti vagy térinformatikai szakmai tevékenységéhez kell kapcsolódnia, és az Adatkezelő szervezetén belüli munkavégzési feladatok elvégzését kell szolgálnia. A Rendszer igénybevétele az Adatkezelő munkavállalói és megbízottjai részére a munkaviszonyból vagy megbízási jogviszonyból fakadó jogosultság, egyúttal kötelezettség keretei között mozog.

5.4.2 A belső jelleg következményei az adatvédelmi megítélésre

A Rendszer kizárólagosan belső, vállalati jellege az adatvédelmi megítélés szempontjából az alábbi alapvető következményekkel jár, amelyeket a felhasználóknak ismerniük kell:

a) A Rendszeren belüli adatáramlás nem minősül harmadik félnek való adattovábbításnak. Az egyik belső felhasználó által kezelt adatoknak más belső felhasználó általi megtekintése vagy módosítása az Adatkezelő szervezetén belüli, kontrollált és naplózott adatáramlás, amelyre a GDPR harmadik félnek való adattovábbításra vonatkozó szigorúbb szabályai nem alkalmazandók.

b) A Rendszerben nincsenek anonim vagy ismeretlen személyek. Minden felhasználó azonosított, és szerepköre, fiókadatai az Adatkezelő számára ismert. Ez a körülmény a rendszerbiztonság és az adatvédelem szempontjából egyaránt alapvető garanciát jelent.

c) A belső jelleg nem jelenti a személyes adatok védelme iránti kötelezettség hiányát. A belső, vállalati jelleg kizárólag a Rendszeren belüli adatáramlás minősítésére vonatkozó következményeket hordoz. A felhasználók személyes adatainak — különösen az e-mail-cím, a profilkép és az esetlegesen geodata-fájlokban szereplő személyes adatok — kezelésére a GDPR és az Infotv. teljes körben alkalmazandó, és az Adatkezelő e kötelezettségeinek maradéktalan teljesítésére törekszik.

5.4.3 A Rendszer használatának munkaeszköz-jellege

A Georto Vision az Adatkezelő tulajdonát képező, az Adatkezelő által üzemeltetett, belső munkaeszköz. Ennek megfelelően:

• Az Adatkezelő jogosult a Rendszer igénybevételére vonatkozó szabályokat — a jogszabályi keretek között — meghatározni és módosítani.
• Az Adatkezelő jogosult a tevékenységi napló útján a Rendszerben végzett fájlkezelési tevékenységeket nyomon követni, a belső ellenőrizhetőség és az adatbiztonság fenntartása érdekében.
• A felhasználók a Rendszert az Adatkezelő tulajdonaként, és azzal arányos gondossággal kezelik.

---

II. RÉSZ – ADATKEZELÉSI KÖTELEZETTSÉGEK

---

6. A kezelt adatok köre és az adatkezelési elvek

6.1 Az adatminimalizálás elvének érvényesítése a napi használatban

A GDPR 5. cikk (1) bekezdésének c) pontjában rögzített adatminimalizálás elve a felhasználók számára konkrét, mindennapi kötelezettségeket keletkeztet. E kötelezettségek lényege, hogy a Rendszer keretében kizárólag azok az adatok kerüljenek kezelésre, amelyek az adott munkavégzési feladat elvégzéséhez ténylegesen és arányosan szükségesek.

Az adatminimalizálás elvének a napi rendszerhasználat során az alábbi módokon kell érvényesülnie:

a) Geodata-fájlok feltöltésekor: Kizárólag azok a fájlok kerüljenek feltöltésre, amelyek az aktuális munkavégzési feladathoz szükségesek. A már nem szükséges, elavult vagy duplikált fájlok rendszeres törlése az adatminimalizálás elvének megfelel, és az Adatkezelő által elvárt magatartás.

b) Geodata-fájlok tartalmának kezelésekor: Amennyiben a feltöltendő fájl természetes személyekre vonatkozó adatokat tartalmaz (pl. ingatlan-tulajdonos neve, projekthez kapcsolódó személynév), a fájl feltöltése előtt mérlegelendő, hogy e személyes adatok feltöltése és belső megosztása a munkavégzési cél szempontjából valóban szükséges-e. Ha a személyes adatok kihagyásával a munkavégzési feladat elvégezhető, azok elhagyása ajánlott.

c) Profilkép feltöltésekor: A profilkép feltöltése opcionális és hozzájárulásalapú. Az adatminimalizálás elvével összhangban a felhasználó saját döntése alapján mellőzheti a profilkép feltöltését, anélkül, hogy ez a Rendszer funkcionalitásának igénybevételét bármilyen módon korlátozná.

d) GPS-helymeghatározás engedélyezésekor: A helymeghatározási funkció kizárólag akkor engedélyezendő, ha annak igénybevétele az aktuális munkavégzési feladathoz (pl. helyszíni koordinátaellenőrzés) valóban szükséges. A funkció munkavégzési céltól független, hosszú ideig tartó engedélyezve tartása az adatminimalizálás elvével nem egyeztethető össze; bár technikai akadálya nincsen, a Rendszer a helyadatot szerverre nem rögzíti.

e) FTP-hozzáférési adatok tárolhatósága: Az FTP-szerver hostneve és felhasználóneve a böngésző localStorage tárolójában megőrizhető a következő kapcsolat gyorsabb beállítása érdekében. Ha az FTP-kapcsolat egyszeri, nem ismétlődő jellegű, az adatok böngészőbeli tárolásának mellőzése az adatminimalizálás elvének jobban megfelel.

6.2 Kötelező felhasználói adatok és kezelésük szabályai

6.2.1 E-mail-cím és jelszó

Az e-mail-cím a felhasználói fiók elsődleges azonosítója, amely a következő célokra kerül kezelésre:

• Bejelentkezési azonosítóként a Supabase Auth hitelesítési folyamatában.
• A Rendszer által küldött rendszerüzenetek és jelszó-visszaállítási e-mailek kézbesítési címeként.
• A meghívó és felhasználókezelés során az egyes fiókok azonosítására.
• A profiles táblában az egyedi felhasználói rekordhoz kapcsolva.

A felhasználó köteles valódi, aktív, kizárólag általa használt e-mail-címet megadni a fiókjához. A saját e-mail-cím a profilpanel → Fiók adatok felületen módosítható; a mentés után a Rendszer kijelentkezteti a felhasználót, és a következő bejelentkezéshez az új e-mail-cím használata szükséges. Más felhasználó e-mail-címének módosítása kizárólag Rendszergazda által, adminisztrációs eljárás keretében történhet — elsősorban a POST /update-email Worker API-végponton keresztül, illetve kivételes esetben a Supabase adminisztrációs felületén (Auth) — amennyiben az érintett önállóan ezt nem tudja elvégezni (ld. 15.2.3 pont).

A jelszó a fiókhoz való hitelesített hozzáférés biztosítéka. A jelszóra vonatkozó részletes technikai és kezelési szabályokat a Szabályzat 10. fejezete tartalmazza. E helyütt rögzítendő:

• A jelszó a Rendszer adatbázisában soha nem kerül olvasható (plaintext) formában tárolásra; a Supabase Auth iparági szabványnak megfelelő erős hash-algoritmussal (bcrypt vagy argon2) titkosítja azt.
• Az Adatkezelőnek, a Rendszergazdának és bármely más munkatársnak a jelszóhoz olvasható formában nincs és nem is lehet hozzáférése.
• A felhasználó felelős a jelszava megőrzéséért; a jelszó elvesztése vagy kompromittálódása esetén haladéktalanul gondoskodni kell a jelszó visszaállításáról (saját magának a jelszóváltoztató funkcióval, vagy a Rendszergazda segítségével).

6.2.2 Teljes név és szerepkör

A felhasználó teljes neve (keresztnév és vezetéknév) az alábbi célokra kerül kezelésre:

• A felhasználó azonosítása a Rendszeren belüli felhasználói felületen (profilmegjelenítés, fájlkezelési felület).
• A tevékenységi naplóban az egyes fájlkezelési műveletek elvégzőjének visszakövethetővé tétele: a naplóbejegyzésekben a felhasználó neve (vezetéknév + keresztnév) kerül rögzítésre az adott művelet elvégzőjeként.
• Az Adatkezelő belső szervezeti átláthatóságának biztosítása (a profiles táblában hozzáférhető minden hitelesített felhasználó számára).

A felhasználó köteles valódi teljes nevét megadni. Álnév, becenév, munkakörmegjelölés vagy más, nem a felhasználó valódi nevét tartalmazó bejegyzés nem megengedett. A névadatok — különösen a tevékenységi naplóban szereplő adatok — adatjogi szempontból személyes adatnak minősülnek, és azok kezelésére a Szabályzat és az Adatvédelmi Tájékoztató rendelkezései maradéktalanul alkalmazandók.

A keresztnév és a vezetéknév a profilpanel → Fiók adatok felületen módosítható, külön hitelesítési lépés nélkül. Névváltoztatás esetén a Cloudflare Worker — a profil adatbázisba mentése előtt — a POST /update-log-user-name API-végponton keresztül szerver oldalon frissíti a tevékenységi naplóban az érintett felhasználóhoz köthető összes korábbi bejegyzést: az uploaded_by, deleted_by és renamed_by mezőkben tárolt régi nevet az adatbázisból kiolvasott aktuális értékkel azonosítja, majd az új névre cseréli. A frissítés a felhasználó megerősítő mentési művelete után automatikusan, szerver oldalon zajlik le; a névváltozás tényéről (régi → új név) a Rendszer külön naplóbejegyzést nem készít.

A szerepkör az egyes felhasználókhoz rendelt jogosultságszintet (Rendszergazda / Szerkesztő / Felhasználó) jelöli. A szerepkört kizárólag a Rendszergazda határozza meg (a meghívó kiadásakor) és módosíthatja (utólag, a 4.5 pont szerint). A szerepkör a profiles tábla role mezőjében kerül tárolásra, és a Cloudflare Worker backend JWT-ellenőrző függvénye által minden API-kérésnél hitelesítésre kerül.

6.3 Opcionális adatok és a hozzájárulás szabályai

6.3.1 Profilkép — feltöltés, csere, törlés szabályai

A profilkép feltöltése teljes mértékben önkéntes és hozzájárulásalapú adatkezelés [GDPR 6. cikk (1) bek. a) pont]. A következő szabályok érvényesek:

Feltölthető formátumok és korlátok: JPEG, PNG, GIF és WebP formátumú képfájlok tölthetők fel. A kép feltöltése a profilpanel → Profilkép módosítása felületen lehetséges; a felhasználó a fájlrendszeréből böngészhet kép után, vagy a Rendszer kamerás képkészítési funkcióját is igénybe veheti.

Kamerás képkészítés: Amennyiben a felhasználó a kamerás képkészítési funkcióval él, az Adatkezelő az eszköz kameráját kizárólag az egyetlen fénykép elkészítésének idejére aktiválja; a kamerafolyam rögzítésre nem kerül, és a Rendszer bezárásával, illetőleg a funkció elhagyásával a kamera-hozzáférés azonnal megszűnik.

Tárolás: A profilkép a Supabase Storage avatars tárolójában, a felhasználó egyedi azonosítójához ({userId}) rendelt, időbélyeggel ellátott elérési úton kerül elhelyezésre (avatars/{userId}/{timestamp}.{ext}). A profilkép kizárólag a Rendszerben regisztrált, hitelesített felhasználók számára hozzáférhető; nyilvánosan nem érhető el.

Csere: A profilkép bármikor felváltható egy új képpel; a korábbi kép az új kép feltöltésekor törlésre kerül.

Törlés (a hozzájárulás visszavonása): A felhasználó a profilképet a profilpanel → Profilkép módosítása felületen bármikor törölheti. A törlés egyben a profilkép-kezelésre vonatkozó hozzájárulás visszavonásaként is értelmezendő. A visszavonás a jövőbeni adatkezelést azonnal megszünteti; a visszavonást megelőző adatkezelés jogszerűségét nem érinti [GDPR 7. cikk (3) bekezdés].

Tartalomellenőrzési kötelezettség: A feltöltött profilképnek a feltöltő felhasználó saját, azonosításra alkalmas arcképét kell tartalmaznia, vagy — ha az érintett személyes ábrázolástól eltekint — egy munkaszervezeti szempontból megfelelő, semleges, jogsértő tartalomtól mentes képet. Tilos olyan profilképet feltölteni, amely más személyt az engedélye nélkül ábrázol, szerzői jogi védelem alatt álló alkotást jogosulatlanul tartalmaz, vagy jogszabályba ütköző, sértő, diszkriminatív vagy félrevezető tartalmat hordoz.

6.3.2 GPS-helymeghatározás — engedélyezés és visszavonás szabályai

A GPS-alapú helymeghatározási funkció szintén teljes mértékben önkéntes és hozzájárulásalapú [GDPR 6. cikk (1) bek. a) pont]. A következő szabályok érvényesek:

A hozzájárulás megadásának módja: A helymeghatározás engedélyezése a Rendszer térképes felületén, a böngésző geolokációs engedélyezési párbeszédpanelén keresztül valósul meg. Az érintett felhasználó a böngésző által felkínált „Engedélyezés" / „Tiltás" lehetőségek egyikét választja; az engedélyezés aktív döntést igényel.

Az adatkezelés technikai sajátossága — szerverre nem kerül továbbításra: A helymeghatározási adatok (GPS-koordináták: szélességi fok, hosszúsági fok, pontosság méteres értéke) kizárólag az érintett böngészőjében, helyi szinten kerülnek feldolgozásra. A koordináták szerverre nem kerülnek továbbításra, az Adatkezelő adatbázisában nem tárolódnak, és a tevékenységi naplóban nem kerülnek rögzítésre. Az adatkezelés kizárólag az aktuális munkamenet ideje alatt valósul meg.

Felhasználás: A helymeghatározási adatok kizárólag a következő célokra kerülnek felhasználásra a böngészőben:

• Az érintett aktuális pozíciójának valós idejű megjelenítése a Rendszer térképes felületén (térképes pin vagy jelzőikon formájában).
• A proj4js könyvtár segítségével elvégzett koordináta-átszámítás (WGS84 → EOV), amelynek eredménye a munkavégzési feladathoz (pl. terepkoordináta azonosítása) használható fel.

A hozzájárulás visszavonásának módjai:

• A Rendszer térképes felületén a helymeghatározási funkció kikapcsolásával.
• A böngésző helymeghatározási engedélyének visszavonásával a böngésző beállítási felületén (az adott weboldal helymeghatározási engedélyének visszavonása).
• Az oldal újratöltésével, amennyiben a böngésző az engedélyt munkamenet-szinten tárolta.

A visszavonás a jövőbeni adatkezelést azonnal megszünteti; a helyadatokat a böngésző helyi feldolgozásán kívül az Adatkezelő nem tárolja, ezért a visszavonást megelőző adatkezelés utólagos törlésére szükség nincsen.

6.4 Munkafeladat-specifikus adatok kezelése

6.4.1 FTP-hozzáférési adatok kezelése és tárolhatósága

A Szerkesztő és Rendszergazda szerepkörű felhasználók a Rendszer FTP-importálási funkcióján keresztül külső FTP-szerverekről tölthetnek le geodata-fájlokat. Az e funkcióval összefüggő adatkezelési szabályok az alábbiakban kerülnek részletezésre.

A kezelt adatok és azok kezelési módja:

Különös figyelmeztetés — FTP-protokoll titkosítatlansága:

⚠️ Az Adatkezelő felhívja a figyelmet, hogy az FTP protokoll alapértelmezetten titkosítatlan csatornán (plain FTP) működik, ami azt jelenti, hogy az FTP-szerver hostneve, a felhasználónév és a jelszó hálózati szinten lehallgatható, amennyiben a hálózati kommunikáció titkosítatlan. Az FTP-hozzáférési adatok hálózati titkosítása az igénybe vett FTP-szerver konfigurációjától függ, és az Adatkezelő azt nem garantálhatja. A felhasználóknak a lehető legnagyobb mértékben ajánlott az FTPS (FTP over TLS) vagy az SFTP (SSH File Transfer Protocol) protokollt támogató szervereket előnyben részesíteni. Az Adatkezelő belső FTP-szerverei esetén a szerver üzemeltetője köteles gondoskodni a megfelelő titkosítás alkalmazásáról.

localStorage-ban tárolt FTP-adatok kezelésének felhasználói felelőssége:

A localStorage-ban opcionálisan megőrzött FTP-hostnév és FTP-felhasználónév az érintett böngészőjéhez kötötten él. A felhasználó felelős azért, hogy:

• megosztott (közös) eszköz használata esetén a localStorage tartalmát a munkamenet befejeztével törölje, megelőzve ezzel, hogy az FTP-hozzáférési adatokhoz más személy hozzáférjen;
• az eszköz elvesztése vagy ellopása esetén haladéktalanul értesítse a Rendszergazdát, és — amennyiben lehetséges — távolról törölje a böngésző tárterületét.

6.4.2 Geodata-fájlokban foglalt adatok kezelése

A feltöltött geodata-fájlok elsősorban belső szakmai (műszaki) adatokat tartalmaznak. Azonban bizonyos esetekben a feltöltött fájlok természetes személyekre vonatkozó adatokat is hordozhatnak. Az ilyen tartalmú fájlok kezelésére az alábbi szabályok alkalmazandók:

Mikor minősül a geodata-fájl tartalma személyes adatnak?

A feltöltött geodata-fájl tartalma személyes adatnak minősül, ha abból azonosított vagy azonosítható természetes személy állapítható meg. A Rendszer vonatkozásában ilyen helyzet különösen az alábbi esetekben állhat fenn:

• A fájl ingatlanokhoz kötött koordinátákat tartalmaz, és az ingatlanokhoz tulajdonosnév is hozzárendelve szerepel.
• A fájl projektazonosítókat tartalmaz, amelyek közvetlenül egy-egy megbízóhoz (természetes személyhez) kapcsolódnak.
• A fájlban szereplő pontszámozás vagy attribútumok természetes személyek nevét tartalmazzák.
• A fájl szabad szöveges mezőkben természetes személyek adatait foglalja magában.

A személyes adatot tartalmazó geodata-fájlok kezelésének szabályai:

1. Szükségességi mérlegelés feltöltés előtt: A fájl feltöltése előtt a Szerkesztő és a Rendszergazda mérlegeli, hogy a személyes adatot tartalmazó fájlrészek feltöltése és belső megosztása valóban szükséges-e a munkavégzési cél eléréséhez. Ha a személyes adatok nélkül a feladat elvégezhető, azok kihagyása vagy anonimizálása ajánlott.

2. Adatminimalizálás: A fájlból — amennyiben ez technikailag megvalósítható — a munkavégzési feladat szempontjából felesleges személyes adatok feltöltés előtt eltávolítandók.

3. Megőrzési idő betartása: A személyes adatot tartalmazó geodata-fájlok törlése elvégzendő, amint a munkavégzési feladat elvégzéséhez már nem szükségesek. A szükségtelen személyes adatok tárolása az adatminimalizálás és a tárolási korlát elvével ellentétes.

4. Jogsértő tartalmú fájlok tilalma: Tilos feltölteni olyan fájlt, amelynek tartalma — az abban szereplő személyes adatok jellege alapján — sérti harmadik személyek személyiségi jogait, adatvédelmi jogait, vagy amelynek kezelésére az Adatkezelőnek jogalapja nincsen.

6.5 Automatikusan keletkező adatok

6.5.1 Tevékenységi (audit) napló

A Rendszer a fájlkezelési műveletek részeként automatikusan, szerver oldalon rögzíti a tevékenységi naplót. A naplózás technikai folyamata: a Cloudflare Worker az R2-ben tárolt .fgb és .pmtiles fájlok sikeres feltöltését, törlését és átnevezését követően frissíti a tevékenységi naplót: új app_data/file_log_{timestamp}.json fájlt hoz létre, és a korábbi időbélyeges naplófájlt törli. A naplóbejegyzés az alábbi adatokat tartalmazza:

A tevékenységi napló adatainak kezelésével kapcsolatban a felhasználóknak az alábbiakat kell tudniuk:

• A naplózás automatikus és kötelező: a felhasználó azt nem kapcsolhatja ki és nem kerülheti meg.
• A napló tartalma visszakövethetővé teszi a felhasználó által elvégzett fájlkezelési műveleteket; a felhasználó ezzel tisztában van.
• A napló tartalmát kizárólag a Rendszergazda tekintheti meg; a többi felhasználó saját naplóbejegyzéseihez sem fér hozzá közvetlenül a Rendszer felületén.
• A naplóbejegyzések ajánlott megőrzési ideje legfeljebb 1 év; a Rendszergazda köteles gondoskodni a megőrzési idő betartásáról.

6.5.2 Munkamenet-tokenek (JWT)

A sikeres bejelentkezést követően a Supabase Auth két tokent állít ki és helyez el a böngésző localStorage tárolójában: a rövid élettartamú hozzáférési tokent (access_token, jellemzően 1 óra lejárattal) és a hosszabb élettartamú megújítási tokent (refresh_token). A felhasználónak az alábbi kötelezettségei vannak a tokenek kezelésével kapcsolatban:

• Kijelentkezési kötelezettség megosztott eszközön: Megosztott eszközről (pl. közösen használt irodai számítógépről) való munkamenet-befejezéskor a felhasználó köteles a Rendszerből kijelentkezni (signOut()), amely mindkét tokent törli a localStorage-ból. A böngészőlap egyszerű bezárása — ha a localStorage nem kerül törlésre — nem jelenti a tokenek törlését.
• A token bizalmassága: A localStorage-ban tárolt token — bár formátuma technikai felhasználónak olvasható — személyes adatot tartalmaz (felhasználói azonosítót, szerepkört), és nem kerülhet harmadik személy kezébe.
• Token lejárata és megújulása: A hozzáférési token lejárta esetén a Rendszer automatikusan megújítja azt a megújítási token segítségével. A felhasználónak ezzel kapcsolatban semmilyen teendője nincsen.

6.5.3 Térképkonfigurációk és megosztási adatok

A felhasználó által létrehozott és mentett egyéni térképkonfigurációk a Cloudflare R2-ben, az adott felhasználóhoz rendelt JSON-fájlban (app_data/maps_{userId}.json) kerülnek tárolásra. A tárolt adatok köre: a térkép neve, a fájlok listája és láthatósági beállításai, valamint a megosztási adatok (a megosztás ténye, időpontja, a megosztó neve és a megosztott térkép azonosítója).

A felhasználó köteles biztosítani, hogy a térképkonfigurációk nevei, leírásai, valamint a fájlok listája és láthatósági beállításai ne tartalmazzanak olyan személyes adatot vagy bizalmas információt, amelynek a Rendszer más felhasználói felé való közvetett megosztása (pl. megosztott térkép esetén) nem megengedett.

6.5.4 Rendszerüzenetek olvasottsági adatai

A Rendszer belső üzenetközvetítő mechanizmusa (messages és user_messages táblák, Supabase PostgreSQL) lehetővé teszi, hogy az Adatkezelő belső tájékoztatásokat (pl. adatvédelmi változások, karbantartási értesítők, Szabályzat-módosítások) közvetítsen a felhasználók felé. Az egyes üzenetek elolvasása után a Rendszer a Cloudflare Worker POST /messages/seen API-végpontján keresztül rögzíti a user_messages táblában, hogy az adott felhasználó az adott üzenetet elolvasta, megelőzve ezzel az üzenet ismételt megjelenítését. A user_messages táblához authenticated jogosultsággal nincs közvetlen adatbázis-hozzáférés; az üzenetek listázása és olvasottként jelölése kizárólag a GET /messages és POST /messages/seen API-végpontokon keresztül történik. E technikailag szükséges adatkezelés a GDPR 6. cikk (1) bek. f) pontja (jogos érdek) alapján jogszerű; a rögzített adatok köre (felhasználói azonosító + üzenet azonosítója) a szükséges minimumra korlátozódik.

A felhasználónak e mechanizmussal kapcsolatban nincs különös kötelezettsége; az olvasottsági adatok kezelése automatikus, és az érintett fiókjának törlésekor az összes ilyen rekord törlésre kerül.

---

7. Fájlkezelési kötelezettségek és geodata-tartalmak szabályai

7.1 Feltölthető fájlformátumok és méretkorlátozások

7.1.1 Engedélyezett fájlformátumok

A Rendszer kizárólag az alábbi, geodéziai, térképészeti és térinformatikai munkavégzéshez szükséges fájlformátumok fogadására alkalmas. Más formátumú fájlok feltöltési kísérlete szerver oldali elutasítást eredményez:

A fenti táblázat az importálható forrásformátumokat sorolja fel. A feltöltés során a Rendszer — a .fgb és .pmtiles fájlok kivételével, amelyek változatlan formában kerülnek az R2-be — a forrásfájlt a böngészőben futó, GDAL-alapú fájlkonverziós eljárással automatikusan FlatGeobuf (.fgb) formátumba alakítja. A konvertált (vagy eredeti) fájl a Cloudflare R2 bucket gyökérkönyvtárába kerül (POST /upload); a .got, .dxf, .xml és .txt forrásfájlok az R2-ben nem jelennek meg eredeti kiterjesztésükben. Ugyanez a konverziós eljárás érvényes az FTP-szerverről történő importálásra is. A tevékenységi napló (app_data/file_log_{timestamp}.json) kizárólag az R2-be került .fgb és .pmtiles fájlok feltöltését, törlését és átnevezését rögzíti.

Az Adatkezelő fenntartja a jogot arra, hogy a fentieken túl további fájlformátumokat engedélyezzen, illetőleg meglévő formátumok támogatását megszüntesse. Az engedélyezett formátumok körének változásáról a Rendszergazda a felhasználókat a Rendszer belső üzenetrendszerén keresztül értesíti.

7.1.2 Tilos tartalmak feltöltésének tilalma

A Rendszerbe tilos olyan fájlt feltölteni, amely:

• nem geodéziai, térképészeti vagy térinformatikai szakmai adatot tartalmaz, és amelynek feltöltése a 5.1 pontban meghatározott munkavégzési keretekkel nincs összefüggésben;
• jogsértő tartalmat hordoz, beleértve a szerzői jogi védelemben részesülő tartalmak jogosulatlan feltöltését, személyiségi jogokat sértő adatokat, gyűlöletkeltő, becsületsértő vagy diszkriminatív anyagokat;
• végrehajtható kódot (pl. .exe, .sh, .js, .php fájlokat) vagy kártékony szoftvert (malware, ransomware, spyware stb.) tartalmaz — még akkor is, ha a fájl az engedélyezett formátumok egyikének kiterjesztésével van ellátva;
• harmadik fél bizalmas üzleti adatait tartalmazza, amelyek kezeléséhez az Adatkezelőnek nincs jogalapja;
• különleges kategóriájú személyes adatot [GDPR 9. cikk] tartalmaz (pl. egészségügyi adatot, faji vagy etnikai hovatartozásra vonatkozó adatot) anélkül, hogy az Adatkezelő ilyen adatok kezelésére kifejezett jogalappal rendelkezne.

7.1.3 Fájlméret-korlátok és teljesítményi szempontok

Az Adatkezelő a Cloudflare Workers platform technikai korlátaira és a Rendszer teljesítményoptimalizálására tekintettel ajánlja, hogy az egyes feltöltendő fájlok mérete ne haladja meg az Adatkezelő által esetileg meghatározott, belső kommunikációban közzétett korlátot. Különösen nagy méretű fájlok feltöltése előtt a Szerkesztő és a Rendszergazda egyeztessen a Rendszergazdával az optimális feltöltési stratégiáról (pl. fájldarabolás, tömörítés).

7.2 A geodata-tartalmak minősítése: belső szakmai adat és személyes adat

7.2.1 A minősítés szükségessége és következményei

A Rendszerbe feltöltött geodata-fájlok tartalmát az adatkezelési kötelezettségek szempontjából két kategóriába kell sorolni: belső szakmai (műszaki) adat és személyes adat. A két kategória nem zárja ki egymást: ugyanaz a fájl egyidejűleg tartalmazhat belső szakmai adatot is és személyes adatot is.

A minősítés azért szükséges, mert a személyes adatokat tartalmazó fájlok kezelésére a GDPR, az Infotv. és jelen Szabályzat adatvédelmi rendelkezései teljes körben alkalmazandók, míg a kizárólag belső szakmai adatot tartalmazó fájlokra ezek a kötelezettségek nem terjednek ki.

7.2.2 Belső szakmai (műszaki) adatok

Az alábbi tartalomtípusok — önmagukban, azonosítható természetes személlyel való közvetlen kapcsolat nélkül — belső szakmai adatnak minősülnek, és azok kezelése az Adatkezelő belső munkavégzési folyamataira vonatkozó általános szabályok szerint történik:

• tereptárgyak és töréspontok puszta koordinátái (Kelet, Észak, magasság — EOV és WGS84 rendszerben), amelyek nem kapcsolódnak azonosítható személyhez;
• szintvonalak és terepi felvételezési eredmények, amelyek nem tartalmaznak személynevet, ingatlan-tulajdonos-azonosítót vagy egyéb, természetes személyhez kapcsolódó attribútumot;
• pontszámok és pontleírások, amelyek kizárólag szakmai (geodéziai, műszaki) kontextusban értelmezhetők;
• csempézett térképadatok (.pmtiles), amelyek kizárólag általános térinformatikai tartalmat hordoznak.

7.2.3 Személyes adatot tartalmazó geodata-fájlok azonosítása

A feltöltendő fájl személyes adatot tartalmazhat, ha az alábbi körülmények valamelyike fennáll:

• A fájl attribútumtáblájában személynév, ingatlan-tulajdonos neve, megbízó neve vagy más, természetes személyt azonosítható adat szerepel.
• A fájl projektmappa-struktúrájában, fájlnévben vagy szöveges mezőkben projektazonosítóhoz rendelt személynév szerepel.
• A fájl szabad szöveges mezőkben cím + tulajdonos kombináció vagy egyéb azonosítható személyi adatot tartalmaz.
• A fájl tartalmaz GPS-nyomvonalat vagy helyzetadatot, amelyhez azonosítható személynév is hozzárendelhető.

Ha a feltöltés előtti vizsgálat alapján a fájl személyes adatot tartalmaz, a Szerkesztő és a Rendszergazda köteles a 6.4.2 pontban meghatározott szükségességi mérlegelést elvégezni.

7.3 Fájlok elnevezésére, átnevezésére és törlésére vonatkozó szabályok

7.3.1 Fájlelnevezési konvenciók

Bár a Rendszer technikai szinten nem kényszerít ki kötelező fájlelnevezési sémát, az Adatkezelő az alábbi elnevezési irányelvek betartását várja el a munkavégzési feladatokhoz kapcsolódó visszakereshetőség és azonosíthatóság biztosítása érdekében:

• A fájlnév legyen informatív és egyértelmű: A fájlnév tükrözze a fájl tartalmát, rendeltetését vagy a kapcsolódó projektet (pl. beregszasz_alapfelmeres_2026.fgb).
• Kerülendő elnevezések: Általános, semmitmondó nevek (pl. fajl1.fgb, test.xml, uj.dxf), amelyek a fájl tartalmát nem azonosítják, és megnehezítik a visszakeresést, illetőleg a tevékenységi napló értelmezését.
• Személyes adatot ne tartalmazzon a fájlnév: A fájlnévbe természetes személy neve, személyi azonosítója vagy egyéb személyes adatához kapcsolódó adat ne kerüljön, kivéve, ha ez a szakmai munkafolyamat szempontjából elengedhetetlenül szükséges.
• Karakterkészlet: Kizárólag latin betűk, számok, kötőjel (-) és aláhúzás (_) alkalmazása ajánlott. A szóközök, ékezetes karakterek, speciális jelek és operációs rendszerfüggő karakterek mellőzése kerülendő a fájlnévkompatibilitási problémák megelőzése érdekében.
• Verziózás: Több verziót tartalmazó fájlok esetén a verziószám (_v2, _v3) vagy dátumbélyeg (_20260613) fájlnévbe foglalása ajánlott.

7.3.2 Fájátnevezés szabályai

A fájlok átnevezése kizárólag Szerkesztő és Rendszergazda jogkörrel rendelkező felhasználók által végezhető el. Az átnevezés az alábbi követelményeknek megfelelően hajtandó végre:

• Átnevezés előtti egyeztetés: Ha az átnevezendő fájlt más munkatárs töltötte fel, az átnevezés előtt — ha ez lehetséges — egyeztetés ajánlott a fájl eredeti feltöltőjével, annak érdekében, hogy a névváltozás az érintett munkafolyamatokat ne akadályozza.
• Átnevezés naplózása: Minden átnevezési műveletet a tevékenységi napló automatikusan rögzít: az eredeti fájlnév bejegyzésében a renamed_to (új fájlnév), renamed_at (időpont) és renamed_by (elvégző neve) mezők kerülnek felvételre. Az új fájlnévhez önálló naplóbejegyzés nem jön létre; a névváltoztatás kizárólag az eredeti fájlnév bejegyzésén keresztül követhető vissza. A felhasználó tudomásul veszi, hogy az átnevezés visszakövethetően dokumentálva van.
• Formátumkiterjesztés módosításának tilalma: A fájlnév átnevezése során a fájl kiterjesztése (.fgb, .pmtiles) nem változtatható meg. Az R2 objektumtárban kizárólag e formátumú fájlok kerülnek tárolásra.

7.3.3 Fájltörlés szabályai és következményei

A fájlok törlése kizárólag Szerkesztő és Rendszergazda jogkörrel rendelkező felhasználók által végezhető el. A törlésre vonatkozó kötelező szabályok:

a) Visszafordíthatatlanság tudatosítása: A fájl törlése a Cloudflare R2 objektumtárolóból azonnali és visszafordíthatatlan hatályú. A törölt fájl a Rendszerben semmilyen módon nem állítható vissza. A törlési műveletet megelőzően a felhasználó köteles meggyőződni arról, hogy a fájl törlése szándékos, indokolt és az érintett munkafolyamatokra nézve elfogadható.

b) Más munkatárs fájljának törlése: Más munkatárs által feltöltött fájl törlése — noha az 5.3.1 pont értelmében rendeltetésszerű belső munkának minősül — csak akkor hajtandó végre, ha:

• a törlés az Adatkezelő belső munkafolyamatai szempontjából indokolt (pl. elavult, duplikált, hibás tartalmú fájl eltávolítása);
• a törlés szükségessége — ha lehetséges — az eredeti feltöltővel előzetesen egyeztetésre kerül.

Az egyeztetés mellőzésére csak abban az esetben van lehetőség, ha a törlés halaszthatatlan (pl. jogsértő tartalmú fájl azonnali eltávolítása), vagy ha az eredeti feltöltő már nem elérhető (pl. munkaviszonya megszűnt).

c) Tömeges törlés: Egyszerre nagyszámú fájl törlése előtt a Szerkesztő köteles a Rendszergazdával egyeztetni. A tömeges törlési műveletek fokozott kockázatot hordoznak (rendelkezésre állási incidens lehetősége), ezért azok a Rendszergazda előzetes jóváhagyásához kötöttek.

d) Törlés és az audit napló: A törölt fájl neve és a törlés időpontja a tevékenységi naplóban mindaddig megőrzésre kerül, amíg a Rendszergazda a naplóbejegyzéseket törli. A törölt fájlra vonatkozó naplóbejegyzés önálló, a fájl tényleges tartalmától független, és a törlést követően is fennmarad.

7.4 FTP-importálás szabályai és az FTP-protokoll korlátainak ismerete

7.4.1 Az FTP-importálás rendeltetésszerű kerete

Az FTP-importálási funkció (POST /ftp/list, POST /ftp/search és POST /ftp/get API-végpontok) kizárólag az alábbi feltételek egyidejű teljesülése esetén vehető igénybe rendeltetésszerűen:

• Az importálandó fájl geodata-tartalmú, és a 7.1.1 pontban meghatározott engedélyezett formátumok egyikének megfelelő.
• Az érintett FTP-szerver az Adatkezelő szakmai tevékenységével összefüggésben áll (pl. megbízótól kapott FTP-hozzáférés, belső szerverfarm, alvállalkozói tárhelyszolgáltatás).
• Az FTP-hozzáférési adatok (hostnév, felhasználónév, jelszó) az érintett felhasználó saját, jogszerűen megszerzett hitelesítő adatai.

Tilos az FTP-importálási funkciót olyan szerverekről való letöltésre igénybe venni, amelyekhez az érintett felhasználónak nincs jogosult hozzáférése, illetőleg amelyek az Adatkezelő szakmai tevékenységével semmilyen összefüggésben nem állnak.

7.4.2 A titkosítatlan FTP-kapcsolat kockázatairól való tájékoztatás és felelősség

Az Adatkezelő a következő kockázatokról tájékoztatja a felhasználókat, és elvárja, hogy azokkal a felhasználók tisztában legyenek:

⚠️ Biztonsági figyelmeztetés: Az FTP protokoll (plain FTP, 21-es port) alapértelmezetten titkosítatlan csatornán közvetíti az adatokat, beleértve a hitelesítő adatokat (felhasználónév és jelszó). Ez azt jelenti, hogy nem biztonságos (nem titkosított) hálózaton — különösen nyilvános Wi-Fi hálózatokon — az FTP-kommunikáció hálózati szinten lehallgatható. A hálózaton áthaladó FTP-jelszó illetéktelen kézre kerülése az érintett FTP-szerver teljes tartalmának kompromittálódásához vezethet.

A fenti kockázat kezelése érdekében a felhasználó köteles:

• FTPS (FTP over TLS/SSL) vagy SFTP (SSH File Transfer Protocol) protokoll alkalmazására törekedni, amennyiben az FTP-szerver ezeket a titkosított protokollokat támogatja. Ha az FTP-szerver kizárólag plain FTP-t kínál, a felhasználó köteles ezt a körülményt az Adatkezelő adatvédelmi kapcsolattartójának jelezni, hogy az szükség esetén megtehesse a szükséges biztonsági intézkedéseket.
• Az FTP-kapcsolatot kizárólag megbízható, titkosított hálózaton (pl. az Adatkezelő irodai hálózatán, VPN-kapcsolaton keresztül) kezdeményezni, és az FTP-importálási funkció nyilvános, titkosítatlan Wi-Fi hálózatokról való használatát kerülni.
• Az FTP-hitelesítő adatokat más rendszerekben is érvényes jelszavakra nem használni (jelszómegosztás tilalma), csökkentve ezzel az esetleges jelszó-kompromittálódás kárát.

7.4.3 FTPS és SFTP előnyben részesítésének kötelezettsége

Az Adatkezelő által üzemeltetett vagy az Adatkezelő megrendelésére kialakított FTP-szerverek esetén az FTP-szerver üzemeltetője köteles gondoskodni arról, hogy a szerver FTPS vagy SFTP protokollt támogasson, és a plain FTP hozzáférés lehetőség szerint tiltásra kerüljön, vagy legalábbis erősen korlátozott legyen. Az Adatkezelő külső megbízóktól érkező FTP-szerverek esetén ezt a követelményt technikailag nem tudja kikényszeríteni, azonban a felhasználók figyelmét felhívja a titkosítatlan protokoll kockázataira.

7.5 A Cloudflare R2 objektumtárban tárolt adatok hozzáférési rendje

7.5.1 A hozzáférés technikai megvalósítása

A Cloudflare R2 objektumtároló (georto-vision-r2) közvetlen elérési lehetőséggel nem rendelkezik: az R2-ben tárolt adatok kizárólag a Cloudflare Worker API-n keresztül, az érvényes JWT-token és a megfelelő szerepköri jogosultság egyidejű megléte esetén érhetők el. A Cloudflare R2 közvetlen, API megkerülésével való elérési kísérlete tilos, és a Szabályzat 5.2.1 pontja szerinti jogosulatlan hozzáférési kísérletnek minősül.

7.5.2 Az R2 tárolóban alkalmazott adatstruktúra és hozzáférési jogosultságok

Az R2 tárolóban az alábbi objektumkulcs-struktúra érvényesül, amelyhez az egyes szerepkörök az alábbiak szerint férhetnek hozzá:

7.5.3 Tárolás közbeni titkosítás (encryption at rest)

A Cloudflare R2 tárolóban elhelyezett valamennyi adat AES-256 titkosítással védett tárolás közben (encryption at rest). Ez a védelem automatikusan érvényesül; a felhasználónak e tekintetben semmilyen beállítást nem kell elvégeznie. A titkosítás biztosítja, hogy az R2 infrastruktúrájához való jogosulatlan fizikai hozzáférés esetén az adatok olvashatatlanok maradjanak az illetéktelen számára.

7.5.4 Az adatok integritásáért való felelősség

A Rendszerbe feltöltött geodata-fájlok tartalmának helyességéért és integritásáért a feltöltést elvégző felhasználó felelős. A Rendszer a feltöltött fájlok tartalmát tartalmi szempontból nem ellenőrzi és nem validálja; a szerver oldali ellenőrzés kizárólag a fájlformátum és a hozzáférési jogosultság tekintetében érvényesül.

---

8. Térképkonfigurációk és megosztás szabályai

8.1 Egyéni térképkonfigurációk létrehozásának és mentésének szabályai

8.1.1 A térképkonfiguráció fogalma és rendeltetése

A térképkonfiguráció a Georto Vision Rendszer egyéni, felhasználói szintű munkakörnyezetét jelenti: egy elmentett nézet, amely meghatározza, hogy az adott felhasználó a térképes felületen melyik geodata-fájlokat, milyen láthatósági beállításokkal kívánja megjeleníteni. A térképkonfiguráció a munkavégzési hatékonyság eszköze: lehetővé teszi, hogy az érintett felhasználónak az ismétlődő munkafolyamatokhoz ne kelljen minden alkalommal újra beállítania a megjelenítési paramétereket.

8.1.2 A térképkonfigurációk tárolása

Az elmentett térképkonfigurációk a Cloudflare R2 objektumtárolóban, az adott felhasználóhoz rendelt, elkülönített JSON-fájlban kerülnek tárolásra (app_data/maps_{userId}.json). A tárolási struktúra a következő adatokat tartalmazza:

8.1.3 A térképkonfigurációk elnevezési irányelvei

Az egyéni térképkonfigurációk elnevezésére az alábbi irányelvek érvényesek:

• Az elnevezés legyen egyértelmű és tartalomra utaló, hogy a konfiguráció célja és a benne szereplő fájlok az elnevezésből visszakereshetők legyenek (pl. Beregszász_alapfelmeres_2026, Vízpartok_szintvonalas_nézet).
• Személyes adatot ne tartalmazzon a konfiguráció neve, kivéve, ha az egyértelműen szükséges és a belső munkavégzési céllal arányban áll.
• Félrevezető elnevezések tilalma: A konfiguráció neve nem tartalmazhat más felhasználóra vagy más projektre utaló, megtévesztő megjelölést, amely a konfiguráció tényleges tartalmával ellentétes.

8.1.4 Konfigurációk száma és karbantartása

Bár a Rendszer technikai szinten nem korlátoz konkrét maximális konfigurációszámot, a felhasználónak rendszeresen karban kell tartania a mentett konfigurációit: az elavult, már nem használt konfigurációk törlése ajánlott az adatminimalizálás elvével összhangban és a tárolási terhelés ésszerű szinten tartása érdekében.

8.2 Belső csapatszintű megosztás engedélyezett kerete

8.2.1 A megosztási funkció rendeltetése

A térképkonfiguráció megosztási funkciója lehetővé teszi, hogy az egyik felhasználó saját térképkonfigurációját egy másik belső felhasználóval megossza, és a másik felhasználó a megosztott konfigurációhoz hozzáférjen, illetve azt saját munkakörnyezetébe importálja. E funkció kizárólag az Adatkezelő szervezetén belüli csapatszintű együttműködést szolgálja.

8.2.2 A megosztás technikai folyamata

A megosztás a következő lépések szerint valósul meg:

1. A megosztást kezdeményező felhasználó kiválasztja a megosztandó térképkonfigurációt, és a megosztás gombra kattintva engedélyezi a megosztást (isShared: true).
2. A felhasználó menti a térképeket (POST /maps API-végpont); ekkor a megosztás ténye (isShared), időpontja (shareTime), a megosztó neve (ownerName) és a megosztott térkép azonosítója (a térkép neve; a megosztó felhasználói azonosítója a listázáskor és a megosztási hivatkozásban) az app_data/maps_{userId}.json fájlban rögzítésre kerül.
3. Valamennyi hitelesített belső felhasználó a GET /maps/shared API-végponton keresztül lekérdezheti az összes megosztásra jelölt konfigurációt; a Rendszer felületén ezek a „Velem megosztva" fül alatt jelennek meg. A Rendszer felhasználói a megosztott térképeket a Rendszerbe belépve automatikusan látják.
4. A Rendszer a mentés után opcionálisan megjelenít egy megosztási hivatkozást (URL), amely a térkép nevét és a megosztó felhasználó azonosítóját tartalmazza query paraméterként (sharedMapName, sharedMapOwnerId). Ez a hivatkozás kizárólag kényelmi eszköz: a célfelhasználók bejelentkezés után közvetlenül a kiválasztott megosztott térképhez navigálhatnak vele. A megosztás érvényességét és elérhetőségét az isShared jelölő és a mentett konfiguráció határozza meg, nem maga a hivatkozás.

8.2.3 A megosztás kizárólagos belsővállalati jellege

A megosztási funkcióval kizárólag olyan személlyel osztható meg konfiguráció, aki aktív fiókkal rendelkező, hitelesített belső felhasználó. A megosztott konfigurációk a belső felhasználók számára a „Velem megosztva" fülön keresztül érhetők el. A konfiguráció megosztását követően megjelenő megosztási hivatkozás jogosultság nélkül — vagyis érvényes, hitelesített munkamenet hiányában — nem nyitható meg; a Rendszer a hitelesítetlen hozzáférési kísérletet visszautasítja. Ennek megfelelően a megosztási hivatkozás külső személlyel való megosztása tilos és értelmetlen: a külső személy a hivatkozáson keresztül a konfigurációhoz hozzá nem férhet.

8.2.4 A megosztható tartalmak korlátai

A megosztási funkció igénybevétele az alábbi korlátoknak megfelelően lehetséges:

• Megosztható: Saját, az érintett felhasználó által létrehozott térképkonfiguráció, amely kizárólag az R2-ban nyilvánosan elérhető (az érintett felhasználók számára engedélyezett) geodata-fájlokra hivatkozik.
• Nem megosztható: Olyan térképkonfiguráció, amelynek megosztása más felhasználó személyes adatait, bizalmas üzleti információit, harmadik fél szerzői jog által védett tartalmát, vagy a Szabályzatban tiltott egyéb tartalmat terjesztené.
• Nem megosztható külső felhasználóval: A megosztás kizárólag az Adatkezelő szervezetén belüli, a Rendszerben felhasználói fiókkal rendelkező személyek között érvényes.

8.3 A megosztás visszavonásának szabályai

8.3.1 A visszavonás módja és hatálya

A megosztó felhasználó a megosztást bármikor visszavonhatja. A visszavonás az app_data/maps_{userId}.json fájlban az isShared jelölő törlésével (false értékre állításával) és a mentéssel valósul meg. A visszavonás azonnali hatályú: a visszavonás időpontját követően a megosztott konfiguráció többé nem jelenik meg a többi felhasználó „Velem megosztva" listájában (GET /maps/shared), és a megosztási hivatkozás sem vezet elérhető tartalomhoz.

8.3.2 A célfelhasználóknál esetlegesen mentett személyes beállítások kérdése

A célfelhasználók a megosztott térkép használata során helyi, személyre szabott módosításokat végezhetnek, amelyeket a Rendszer a célfelhasználók saját app_data/maps_{userId}.json fájljaiban, __shared__:{ownerId}:{térképNév} formátumú belső kulcs alatt tárol — különösen a fájlok láthatóságának beállítását, valamint a megosztott térképhez opcionálisan hozzáadott saját fájlokat. E módosítások a megosztott nézetben jelennek meg, de nem minősülnek a megosztó konfigurációjának önálló másolatának.

A megosztás visszavonásakor vagy a megosztott térkép megosztó oldali törlésekor a Rendszer a következő betöltéskor és mentéskor automatikusan eltávolítja a már nem elérhető __shared__: bejegyzéseket a célfelhasználók mentett konfigurációiból. A célfelhasználók a „Velem megosztva" fülön a Térképtartalom visszaállítása funkcióval bármikor törölhetik a megosztott térképhez általuk hozzáadott (nem eredeti) fájlokat, visszaállítva a megosztó által megadott eredeti fájllistát.

Ebből következik:

• A megosztás visszavonása jellemzően azonnal megszünteti a célfelhasználók hozzáférését, és a helyi __shared__: bejegyzések a következő szinkronizáláskor automatikusan törlődnek; külön Rendszergazdai beavatkozás erre a célra általában nem szükséges.
• Amennyiben egy célfelhasználó a megosztott konfiguráció tartalmát a Rendszeren kívül (pl. képernyőmentés, export, másolás) rögzítette, azt a Rendszer technikailag nem vonhatja vissza — ezért a megosztónak érzékeny tartalom esetén különösen körültekintőnek kell lennie a megosztás kezdeményezésekor.

8.3.3 Rendszergazdai beavatkozás megosztással kapcsolatos incidensek esetén

Ha a megosztási funkció igénybevételével összefüggésben adatvédelmi incidens gyanúja merül fel (pl. konfiguráció jogosulatlan megosztása, megosztási hivatkozás illetéktelen kézre kerülése), a Rendszergazda jogosult és köteles:

• a megosztó felhasználót haladéktalanul utasítani a megosztás visszavonására (isShared jelölő törlése és mentés), vagy — infrastruktúra-szintű hozzáféréssel — módosítani a megosztó app_data/maps_{userId}.json fájljában a megosztás jelölőit;
• a célfelhasználókat tájékoztatni a hozzáférés megszűnéséről; a célfelhasználók mentett __shared__: bejegyzései a megosztás visszavonása után a Rendszer által a következő betöltéskor és mentéskor automatikusan takarításra kerülnek;
• szükség esetén a Cloudflare R2-ben tárolt érintett app_data/maps_{userId}.json fájl(ok) közvetlen vizsgálatát vagy módosítását elvégezni (a Rendszer felhasználói felületén és API-ján keresztül más felhasználó térképfájljának módosítására dedikált végpont nincs);
• az incidensgyanút a 13. fejezet szerint kezelni és az adatvédelmi kapcsolattartónak bejelenteni.

8.4 A megosztott tartalmakért való felelősség

8.4.1 A megosztó felhasználó felelőssége

A megosztást kezdeményező felhasználó (isShared jelölés bekapcsolása és mentés) teljes felelősséggel tartozik azért, hogy:

• a megosztott konfiguráció kizárólag az 5.1 pontban meghatározott belső munkavégzési célokat szolgálja;
• a megosztott konfiguráció a belső felhasználók számára való elérhetővé tétele — munkaszervezési szempontból — ténylegesen indokolt és szükséges (a megosztás minden hitelesített belső felhasználó számára látható a „Velem megosztva" fülön, nem célzott, egyedi címzettre szabott megosztás);
• a megosztott konfiguráció ne tartalmazzon jogszabályba ütköző tartalmat, harmadik fél jogait sértő adatokat, vagy olyan személyes adatot, amelynek megosztása jogalap nélküli lenne;
• a megosztást visszavonja, amint a munkavégzési cél szempontjából a megosztás fenntartása már nem szükséges.

8.4.2 A célfelhasználók felelőssége

A megosztott konfigurációhoz hozzáférő célfelhasználók kötelesek:

• a megosztott konfigurációt kizárólag a munkavégzési feladatok elvégzéséhez igénybe venni; a Rendszer a „Velem megosztva" fülön nem biztosít továbbmegosztási lehetőséget (a megosztott térképen nincs megosztás gomb);
• a megosztott térképen csak a Rendszer által engedélyezett módosításokat végezni: a fájlok láthatóságának állítása, opcionálisan saját fájlok hozzáadása; a megosztó eredeti fájljait törölni nem lehet, a megosztott térkép nevét megváltoztatni nem lehet;
• a megosztott konfigurációban szereplő adatokat a Szabályzat adatminimalizálási és célhoz kötöttségi elvével összhangban kezelni;
• a megosztott konfigurációban esetlegesen felismert jogszabályba ütköző, vagy a Szabályzatot egyébként sértő tartalmat haladéktalanul jelezni a Rendszergazdának vagy az adatvédelmi kapcsolattartónak.

8.4.3 A megosztott konfigurációk auditálhatósága

A megosztási állapot és a kapcsolódó metaadatok a Cloudflare R2-ben tárolt app_data/maps_{userId}.json fájlokban rögzítődnek; a Rendszer külön megosztási naplóbejegyzést nem készít. A megosztó fájljában az isShared, shareTime és ownerName mezők jelzik, mely térképek megosztottak. A célfelhasználók fájljaiban az esetleges __shared__:{ownerId}:{térképNév} kulcsú bejegyzések tartalmazzák a célfelhasználók helyi testreszabásait (láthatóság, hozzáadott fájlok).

A Rendszergazda — az R2 tárolóhoz vagy a Cloudflare infrastruktúrához való hozzáféréssel — a felhasználói app_data/maps_{userId}.json fájlok átvizsgálásával megállapíthatja, mely konfigurációk voltak megosztva, mikor és ki által. A tevékenységi napló (app_data/file_log_{timestamp}.json) a megosztási műveleteket nem rögzíti, kizárólag fájlkezelési műveleteket (feltöltés, törlés, átnevezés). Ez az ellenőrzési lehetőség az Adatkezelő belső ellenőrzési jogkörébe tartozik, és a 5.3.3 pontban meghatározott rendeltetésszerű felhasználás keretei között érvényesül.

---

9. Adatmegőrzés és törlés

9.1 Az adatmegőrzési idők áttekintése a felhasználó szempontjából

9.1.1 A tárolási korlát elvének felhasználói vetülete

A GDPR 5. cikk (1) bekezdésének e) pontjában rögzített tárolási korlát elve értelmében a személyes adatok csak addig őrizhetők meg, amíg az adatkezelés céljának megvalósításához szükséges. Ez az elv a Rendszer felhasználói számára konkrét cselekvési kötelezettséget keletkeztet: a felhasználók aktívan közreműködnek az adatmegőrzési idők betartásában azáltal, hogy az általuk a Rendszerbe feltöltött vagy ott tárolt adatokat — amelyekre munkavégzési szempontból már nincs szükség — törlik, illetőleg a törlési kötelezettségek teljesítéséhez a Rendszergazdával együttműködnek.

9.1.2 Az adatmegőrzési idők összefoglalása

Az Adatvédelmi Tájékoztató 7. fejezete és az 5. melléklet az egyes adatkategóriákra vonatkozó megőrzési időket részletesen tartalmazza. Az alábbi táblázat a felhasználók napi munkavégzése szempontjából legfontosabb megőrzési idők összefoglalóját tartalmazza:

A felhasználó a profilpanel „Fiók törlése” funkciójával önállóan is kezdeményezheti a saját fiókja végleges törlését (DELETE /user/{userId}). Ez érinti az e-mail-címet, nevet, szerepkört, jelszót, profilképet, térképkonfigurációkat, valamint a user_messages és user_consents rekordokat; a tevékenységi naplóban pedig anonimizálást von maga után. A tárhelyen lévő geodata-fájlok fiók-törléskor automatikusan nem törlődnek.

9.1.3 A megőrzési idők betartásának közös felelőssége

Az adatmegőrzési idők betartása az Adatkezelő, a Rendszergazda és a felhasználók közös felelőssége:

• Az Adatkezelő meghatározza a megőrzési időket, és gondoskodik azok rendszeres felülvizsgálatáról.
• A Rendszergazda gondoskodik a felhasználói fiókokhoz, tevékenységi naplókhoz és rendszerszintű adatokhoz kapcsolódó megőrzési idők érvényesítéséről.
• A Szerkesztő és a Felhasználó felelős a saját maga által feltöltött geodata-fájlok, létrehozott térképkonfigurációk és böngészőjében tárolt adatok megőrzési idejének figyelemmel kíséréséért, és szükség esetén a törlési lépések megtételéért.

9.2 A felhasználó által kezdeményezhető törlések és azok hatálya

9.2.1 Profilkép törlése

A felhasználó a profilképét a profilpanel → Profilkép módosítása felületen bármikor törölheti. A törlés az alábbi hatályokkal jár:

Technikai hatály: A profilkép törlése a Supabase Storage avatars/{userId}/ mappájából az összes feltöltött képfájlt eltávolítja. A törlés után a profiles táblában a avatar_url mező null értékre áll vissza, és a felhasználói felületen a profilkép helyén az alapértelmezett helyőrző ikon jelenik meg.

Adatjogi hatály: A profilkép törlése egyben a profilkép-kezelésre vonatkozó, hozzájárulásalapú adatkezelés visszavonásának minősül [GDPR 7. cikk (3) bekezdés]. A visszavonás az adatkezelést a jövőre nézve azonnal megszünteti; a visszavonást megelőzően elvégzett adatkezelés — azaz a korábbi profilkép kezelése — jogszerűségét nem érinti.

Visszafordíthatóság: A törlés visszafordíthatatlan. A törölt profilkép nem állítható vissza; a felhasználó szükség esetén új képet tölthet fel.

9.2.2 Geodata-fájlok törlése

A geodata-fájlok törlésére Szerkesztő és Rendszergazda jogkörrel rendelkező felhasználók jogosultak a Rendszer fájlkezelési felületén, a DELETE /files/{filename} API-végponton keresztül. A törlés hatályai:

Technikai hatály: A törlés a Cloudflare R2 georto-vision-r2 objektumtárolóból az érintett fájlt azonnal és visszafordíthatatlanul eltávolítja. A törölt fájl semmiféle szemétkosár-mechanizmusba (trash/recycle bin) nem kerül; a törlés közvetlen és végleges. A térképkonfigurációkban továbbra is hivatkozott, de már törölt fájlok a továbbiakban nem jeleníthetők meg; az érintett térképkonfigurációkat szükség esetén frissíteni kell.

Naplózási hatály: A törlés ténye — a törölt fájl neve, a törlést elvégző felhasználó neve és a törlés időpontja — a tevékenységi naplóban rögzítésre kerül, és a napló megőrzési idejéig elérhető marad a Rendszergazda számára.

Jogi hatály: Az adatminimalizálás elvével összhangban az olyan geodata-fájlok törlése, amelyek már nem szükségesek a munkavégzési cél eléréséhez, elvárható magatartás. Különösen sürgős a törlés, ha a fájl személyes adatot tartalmaz, és a munkavégzési cél megvalósult.

9.2.3 Térképkonfigurációk törlése

A felhasználó saját térképkonfigurációit bármikor törölheti a Rendszer felületén. Más felhasználóhoz tartozó konfigurációk a Rendszeren keresztül kizárólag a teljes felhasználói fiók törlésével (DELETE /user/{userId}) távolíthatók el; ezt az érintett saját maga is kezdeményezheti (profilpanel → Fiók törlése), illetve a Rendszergazda is elvégezheti (ld. 9.2.4 pont). Külön térkép-szintű rendszergazdai törlési funkció a Rendszerben nincs. Kivételes, a normál működésen kívüli belső adminisztrációs beavatkozás esetén a Rendszergazda közvetlen infrastruktúra-hozzáféréssel (R2) is módosíthatja az érintett app_data/maps_{userId}.json fájlt. A törlés hatályai:

Technikai hatály: A törölt konfiguráció az app_data/maps_{userId}.json fájlból eltávolításra kerül. Ha a törölt konfiguráció korábban megosztásra volt jelölve, a többi felhasználó „Velem megosztva" listájából is eltűnik, és az esetleges megosztási hivatkozás érvénytelenné válik.

Visszafordíthatóság: A törölt térképkonfiguráció nem állítható vissza. A felhasználó szükség esetén a konfigurációt újra létrehozhatja, de az előző beállítások nem őrződnek meg.

Célszerűség: Az adatminimalizálás elvével összhangban az elavult, már nem használt vagy duplikált térképkonfigurációk rendszeres törlése elvárt és ajánlott.

9.2.4 Teljes felhasználói fiók törlése

A felhasználó saját fiókjának teljes törlését az adatvédelmi kapcsolattartótól vagy a Rendszergazdától írásban kérheti [GDPR 17. cikk — az elfeledtetéshez való jog]. A kérelem beérkezésétől számított 30 napon belül a Rendszergazda a DELETE /user/{userId} API-végponton keresztül elvégzi a törlést. A fiók-törlés hatályai:

Technikai hatály — a törlés által érintett adatok:

Technikai hatály — anonimizálás a tevékenységi naplóban:

A fiók-törlés a tevékenységi naplóban (app_data/file_log_{timestamp}.json) szereplő naplóbejegyzéseket nem törli, hanem anonimizálja: a DELETE /user/{userId} végpont az uploaded_by, deleted_by és renamed_by mezőkben tárolt nevet „Törölt felhasználó" értékre cseréli. A bejegyzések ezt követően a napló saját megőrzési idejéig (ajánlottan legfeljebb 1 év) elérhetők maradnak az Adatkezelő belső ellenőrizhetőségének és az esetleges biztonsági vizsgálatok elvégezhetőségének fenntartása érdekében. Az anonimizálást követően e mezők már nem tartalmaznak személyes adatot, ezért a megőrzés jogalapja a GDPR 6. cikk (1) bekezdés f) pontja (jogos érdek — belső audit és ellenőrizhetőség).

Adatjogi hatály: A fiók-törlés az érintett személy tekintetében az adatkezelési tevékenységet megszünteti. Az érintett a törlést megelőzően benyújtott érintetti joggyakorlási kérelmeit és az azokra adott adatkezelői válaszokat az Adatkezelő az elévülési időkre figyelemmel megőrizheti.

Visszafordíthatatlanság: A fiók-törlés visszafordíthatatlan. A törölt fiók adatai nem állíthatók vissza; ha az érintett személy a munkavégzési feladataihoz a jövőben ismét hozzáférést kap a Rendszerhez, számára új felhasználói fiókot kell létrehozni.

9.3 Rendszergazda által végezhető törlési műveletek és korlátaik

9.3.1 A Rendszergazda törlési jogköreinek összefoglalása

A Rendszergazda az alábbi törlési műveleteket jogosult elvégezni, az adott adatkategóriára vonatkozó megőrzési és adatkezelési szabályok betartásával:

9.3.2 A törlési kötelezettség korlátai — mikor nem törölhető az adat?

A Rendszergazda az alábbi esetekben köteles megtagadni, illetőleg elhalasztani a törlési kérelmet:

a) Folyamatban lévő incidenseljárás: Ha az adatvédelmi incidensgyanú vagy az incidenskezelési eljárás az érintett adatokat bizonyítékként igényli, az adatok az eljárás lezárultáig nem törölhetők. Az incidenseljárás lezárultáig az érintett adatokat zárolni kell (hozzáférés-korlátozás), de törölni tilos.

b) Hatósági megkeresés vagy bírósági eljárás: Ha a NAIH, más hatóság vagy bíróság az érintett adatokra vonatkozó megőrzési kötelezettséget állapított meg, az adatok a megőrzési kötelezettség fennállásáig nem törölhetők, illetőleg csak a hatóság / bíróság engedélyével.

c) Jogszabályi kötelező megőrzési határidő: Egyes adatok esetén jogszabály kötelező megőrzési minimumot ír elő (pl. számviteli, munkaügyi, elektronikus információbiztonsági szabályok). E határidők leteltéig az érintett adatok törlése tilos.

d) Jogi igény érvényesítése: Ha az Adatkezelőnek az érintett adatokra jogi igény előterjesztéséhez, érvényesítéséhez vagy védelméhez [GDPR 17. cikk (3) bek. e) pont] szüksége van, a törlési kérelem megtagadható a szükséges mértékben.

9.4 Automatikus törlési és lejárati mechanizmusok ismerete

9.4.1 JWT token automatikus lejárata

A hozzáférési token (access_token) jellemzően 1 óra lejárattal rendelkezik; a megújítási token (refresh_token) lejárati ideje a Supabase platform beállításától függ. Lejárt hozzáférési token esetén a Rendszer a megújítási token segítségével automatikusan új hozzáférési tokent igényel — a felhasználónak nincs teendője. Ha a megújítási token is lejár (pl. hosszabb ideig tartó inaktivitás esetén), a felhasználó új bejelentkezésre kötelezett. A felhasználónak a token automatikus lejárati mechanizmusával összefüggő kötelezettsége az, hogy kijelentkezéskor tudatosan él a signOut() funkcióval, amely mindkét tokent manuálisan törli, megelőzve, hogy azok a localStorage-ban a lejáratig érvényes állapotban maradjanak.

9.4.2 IP-cím kérésszám-számláló automatikus lejárata

A Cloudflare KV tárolóban elhelyezett, IP-alapú kérésszám-számláló (rate-limit:{ip}) automatikusan, 60 másodperces TTL (Time-To-Live) lejárattal törlődik. A felhasználónak e mechanizmussal kapcsolatban semmilyen tennivalója nincsen; a lejárat az Adatkezelő részéről is automatikus.

9.4.3 GPS-koordináták és sessionStorage automatikus törlése

A GPS-koordináták — amelyek kizárólag az érintett böngészőjében, helyi szinten kerülnek feldolgozásra — munkamenet-szintű, ideiglenes adatként kezelendők; tartós tárolásra nem kerülnek. A sessionStorage-ban tárolt megosztott térkép-paraméterek (pendingSharedMap kulcs) a böngészőlap bezárásakor automatikusan törlődnek. E mechanizmusok az adatminimalizálás elvének technikai szintű érvényesítését valósítják meg; a felhasználónak különösebb teendője nincsen.

9.4.4 FTP jelszó automatikus törlése

Az FTP-importálási kérés feldolgozása során a Cloudflare Worker memóriájában ideiglenesen tartott FTP-jelszó a kérés befejeztével — akár sikeres, akár sikertelen volt a kapcsolat — automatikusan törlődik. A jelszó sem a Cloudflare KV tárolóban, sem az R2-ben, sem a Supabase adatbázisban nem kerül megőrzésre; kizárólag az aktív kérés időtartamára, a Worker memóriájában létezik.

---

III. RÉSZ – BIZTONSÁGI KÖTELEZETTSÉGEK

---

10. Jelszókezelési és hitelesítési kötelezettségek

10.1 A jelszóval kapcsolatos minimumkövetelmények

10.1.1 Kötelező jelszóerősségi kritériumok

A fiók aktiválásakor, illetőleg minden jelszócsere alkalmával a Rendszer az alábbi, szerver oldalon is érvényesített minimumkövetelményeknek megfelelő jelszó megadását követeli meg. A minimumkövetelményeknek nem megfelelő jelszó beállítása technikai szinten megakadályozásra kerül:

Az Adatkezelő a fenti minimumkövetelményeket kötelező alsó határként határozza meg. A felhasználóktól erősen ajánlott ennél hosszabb — legalább 12–16 karakteres — és speciális karaktereket (pl. !, @, #, $, %) is tartalmazó jelszó alkalmazása a biztonság fokozása érdekében.

10.1.2 Tiltott jelszótípusok és -minták

Az Adatkezelő az alábbi jelszótípusok és -minták alkalmazását kifejezetten tiltja, mivel ezek a biztonság szempontjából súlyosan gyenge vagy könnyen kitalálható jelszavak:

• Általánosan ismert gyenge jelszavak: Password1, Passw0rd, Admin123, Qwerty1!, Welcome1 és az ezekhez hasonló, szótáralapú támadásokkal triviálisan feltörhető jelszavak.
• Billentyűzeti szekvenciák: Qwerty123, 12345678, Asdfjkl1 és ezekhez hasonló, billentyűzeti elrendezésből adódó, megjósolható karaktersorozatok.
• Személyes adatokból képzett jelszavak: A felhasználó neve, születési dátuma, telefonszáma, lakcíme, munkaköre vagy egyéb könnyen azonosítható személyes adatának felhasználásával képzett jelszó.
• Munkahelyhez köthető minták: A vállalat neve, a projekt neve, a Rendszer neve (Georto, Vision) és ezek nyilvánvaló variánsai.
• Korábban már kompromittált jelszavak: Amennyiben a felhasználó tudomást szerez arról, hogy egy korábbi jelszava adatvédelmi incidens során nyilvánosságra került, az érintett jelszó — és annak bármely, azóta más rendszerben is alkalmazott variánsa — nem használható.

10.1.3 Különböző rendszerekben alkalmazott jelszavak elkülönítése

Az Adatkezelő nyomatékosan elvárja, hogy a Georto Vision Rendszerhez használt jelszó más rendszerekben, alkalmazásokban és fiókokban ne kerüljön ismételt felhasználásra (jelszó újrafelhasználás tilalma). Az ún. jelszó újrafelhasználás (password reuse) különösen veszélyes, mivel más rendszerekben bekövetkező adatvédelmi incidens esetén a kompromittált jelszó a Georto Vision Rendszerben is felhasználható lenne jogosulatlan belépésre.

10.2 A jelszó titkossága és megóvásának kötelezettsége

10.2.1 A jelszó kizárólagossága

A felhasználó jelszava kizárólagosan az érintett felhasználó tulajdonát képező, titkos hitelesítő adat. A jelszó titkosságának megőrzése a felhasználó személyes kötelezettsége, amelynek teljesítése nem hárítható át más személyre. A jelszó védelme az alábbi kötelezettségeket foglalja magában:

a) Közlési tilalom: A jelszó semmilyen körülmények között nem közölhető más személlyel — beleértve a közvetlen munkatársakat, feletteseket, a Rendszergazdát, az Adatkezelő képviselőjét és az informatikai támogatást nyújtó személyeket is. Az Adatkezelő egyetlen felhatalmazott munkatársa sem kéri e-mailben, telefonon, személyesen vagy a Rendszer felületén a felhasználó jelszavát. Az ilyen kérés azonnal phishing- (adathalász) kísérletnek tekintendő, és haladéktalanul bejelentendő az adatvédelmi kapcsolattartónak.

b) Rögzítési tilalom: A jelszó nem rögzíthető olyan formában, amely azt jogosulatlan személy számára hozzáférhetővé teszi. Tilos a jelszót papíron, cetlin, könnyen hozzáférhető helyen (pl. monitor mellé tűzve, billentyűzet alá helyezve), titkosítatlan szöveges fájlban, e-mailben, chat-üzenetben vagy más nyílt csatornán tárolni.

c) Jelszókezelő alkalmazás: A jelszó biztonságos tárolásához ajánlott megbízható, titkosított jelszókezelő alkalmazás (password manager) igénybevétele (pl. Bitwarden, 1Password, KeePass). A jelszókezelő alkalmazásban tárolt jelszavak titkosított formában kerülnek megőrzésre, és hozzáférésük a jelszókezelő főjelszavához van kötve.

d) Képernyőláthatóság-tilalom: A bejelentkezési felületen a jelszó bevitele során a felhasználó köteles gondoskodni arról, hogy más személy a begépelt jelszót ne lássa — különösen nyilvános helyszíneken, közlekedési eszközökön, nyitott irodai tereken.

10.2.2 Gyanús körülmények esetén azonnali jelszócsere

A felhasználó köteles jelszavát haladéktalanul megváltoztatni, ha az alábbi körülmények valamelyike fennáll:

• Alapos gyanú merül fel, hogy a jelszó illetéktelen személy tudomására jutott (pl. más személy látta a jelszó bevitelét, jelszó papíron volt rögzítve és az elveszett).
• A Rendszergazda vagy az Adatkezelő gyanús fiókhasználatról értesíti az érintettet (pl. belső rendszerüzenet, e-mail vagy más, a 13. fejezet szerinti csatorna).
• A felhasználó olyan rendszerből kapott adatvédelmi incidens-értesítést, amelyben a Georto Vision belépési jelszavával megegyező jelszót használt (jelszó újrafelhasználás esetén).
• Az Adatkezelő vagy a Rendszergazda jelszócserére szólítja fel az érintettet biztonsági okból.

A jelszó azonnali cseréjének kötelezettségével egyidejűleg az érintett köteles az eseményt — incidensgyanúként — az adatvédelmi kapcsolattartónak bejelenteni a 13. fejezet szerint.

10.3 Jelszócsere kötelező esetei

10.3.1 Ideiglenes jelszó kötelező cseréje

Amint a 3.2.1 pontban részletesen kifejtésre került, az új felhasználó a fiókaktiváló felületen való első bejelentkezés után azonnal és kötelező jelleggel köteles az ideiglenes jelszót egy általa választott, a 10.1 pontban meghatározott erősségi kritériumoknak megfelelő egyéni jelszóra cserélni. Az ideiglenes jelszó fenntartása tilos; a fiók aktiválása kizárólag a jelszócsere elvégzésével tekinthető teljesítettnek.

10.3.2 Rendszergazdai jelszóvisszaállítás utáni kötelező csere

Ha a Rendszergazda egy felhasználó jelszavát visszaállítja (pl. elfelejtett jelszó esetén), az új ideiglenes jelszó megkapása után az érintett felhasználó köteles azt az első bejelentkezés alkalmával haladéktalanul saját, egyéni jelszóra cserélni. Az ideiglenes jelszóval végzett folyamatos rendszerhasználat tilos.

10.3.3 Incidens utáni kötelező jelszócsere

Adatvédelmi incidens esetén — különösen, ha a jelszavak kompromittálódása fennáll vagy nem zárható ki — az Adatkezelő, illetőleg az adatvédelmi kapcsolattartó kötelező jelszócsere elvégzésére szólítja fel az érintett felhasználókat. A felszólítás a Rendszer belső rendszerüzenet-mechanizmusán vagy e-mailben kerül kézbesítésre. Az érintett felhasználó köteles a jelszócserét a felszólítástól számított 4 munkórán belül elvégezni. Az incidens utáni jelszócsere kötelezettségének elmulasztása a Szabályzat megsértésének minősül.

10.3.4 Rendszeres proaktív jelszócsere ajánlása

Bár a Rendszer technikai szinten nem kényszerít ki kötelező rendszeres jelszócsere-ciklust, az Adatkezelő ajánlja, hogy a felhasználók — különösen a Rendszergazda szerepkörű, emelt jogosultságú felhasználók — jelszavukat legalább 6 havonta proaktívan cseréljék le. A rendszeres jelszócsere csökkenti a hosszabb ideje nem változtatott, esetlegesen korábban már kompromittálódott jelszóval való visszaélés kockázatát.

10.4 Jelszóváltoztatás biztonsági követelményei

10.4.1 Újrahitelesítési kötelezettség jelszóváltoztatáskor

A bejelentkezett felhasználó profilpanelen történő jelszóváltoztatásánál a Rendszer biztonsági architektúrájának alapvető eleme, hogy az érintett aktuálisan érvényes jelszavának megadása (újrahitelesítés, signInWithPassword) kötelező, mielőtt az új jelszó érvénybe lépne. Ez a technikai követelmény megakadályozza, hogy:

• egy felügyelet nélkül hagyott, bejelentkezett munkamenet felhasználásával illetéktelen személy az érintett tudta nélkül megváltoztassa a jelszót;
• egy érvényes JWT-token ismeretében — az eredeti jelszó ismerete nélkül — jelszócsere legyen végrehajtható.

Ha a felhasználó elfelejtette aktuális jelszavát, új jelszó beállítását kezdeményezheti a bejelentkezes.html felület „Elfelejtetted a jelszavad?” funkcióján keresztül. Az érintett e-mail-cím megadásával a Supabase Auth jelszó-visszaállító linket küld (resetPasswordForEmail), amely a fiok-aktivalas.html oldalra irányítja vissza, ahol az új jelszó beállítható. Alternatívaként a Rendszergazda is visszaállíthat ideiglenes jelszót (POST /reset-user-password, lásd 10.3.2 pont).

10.4.2 Az új jelszó és a régi jelszó különbözősége

Az új jelszó nem lehet azonos az előző jelszóval, ez a követelmény technikai szinten is érvényesítésre kerül. A felhasználótól elvárt magatartás, hogy ne körforgásban alkalmazzon egy-két jelszót, hanem minden jelszócserénél ténylegesen új, az előzőktől lényegesen eltérő jelszót válasszon.

10.4.3 A jelszócsere végrehajtásának lépései

A jelszócsere elvégzésének ajánlott menete:

1. A profilpanel → Jelszó menüpontjában megnyitni a jelszóváltoztató funkciót.
2. Az aktuálisan érvényes jelszót megadni az újrahitelesítési mezőben.
3. Az új jelszót megadni (legalább a 10.1.1 pontban meghatározott erősségi kritériumoknak megfelelően).
4. Az új jelszót megismételni a megerősítési mezőben (elírás kizárása érdekében).
5. A változtatást menteni; a Rendszer a signInWithPassword ellenőrzése után az új jelszót a Supabase Auth-ban frissíti.
6. A jelszócsere után a localStorage-ban tárolt JWT tokenek a Supabase automatikus megújítási folyamatának keretében frissülnek.

10.5 Megosztott bejelentkezési adatok tilalma

10.5.1 Az egyéni fiókok kizárólagossága

Amint a 3.3 pontban részletesen kifejtésre került, a Georto Vision Rendszerben kizárólag személyhez kötött, egyéni felhasználói fiókok létezhetnek. E szabályból következik a bejelentkezési adatok (e-mail-cím és jelszó kombinációja) megosztásának általános és feltétlen tilalma.

10.5.2 A tilalom alóli kivételek hiánya

A bejelentkezési adatok megosztásának tilalma kivétel nélkül érvényes. Különösen hangsúlyozandó, hogy e tilalom alól nincs kivétel az alábbi helyzetekben sem:

• Ha a felhasználó tartósan akadályozott (pl. beteg, szabadságon), és munkájának ellátásához más személynek a Rendszerbe való belépése szükséges — a megoldás ez esetben sem a jelszó átadása, hanem az 1. mellékletben meghatározott helyettesítési rend aktiválása, illetőleg a Rendszergazda tájékoztatása.
• Ha a vezető vagy felettes szóban kéri a jelszó átadását ellenőrzési, helyettesítési vagy „segítség" céljából — ez esetben az érintett felhasználó köteles megtagadni a jelszó közlését, és az esetet az adatvédelmi kapcsolattartónak bejelenteni.
• Ha a feladat elvégzéséhez szükséges adatok más eszközről is elérhetők lennének — a megoldás ez esetben sem a jelszó átadása, hanem a Rendszergazda bevonása a szükséges hozzáférési forma kialakításába.

10.5.3 Az Adatkezelő jelszókérési tilalma

Az Adatkezelő kifejezetten rögzíti, hogy az Adatkezelő egyetlen felhatalmazott munkatársa — beleértve az informatikai ügyintézőket, a Rendszergazdákat és a vezető tisztségviselőket — sem jogosult a felhasználó jelszavát elkérni, és az ilyen irányú kérés soha nem minősülhet jogszerű utasításnak. Az Adatkezelő technikai és szervezési intézkedései révén szükség esetén (pl. fiókkezelés, jelszóvisszaállítás) a felhasználó jelszavának ismerete nélkül is elvégezheti az adminisztrációs feladatokat a szerver oldali service role key és az adminisztrációs API-k segítségével. Ha a felhasználó olyan kérést kap, amely a jelszava átadására irányul, és az kétségtelenül az Adatkezelő szervezetén belüli személytől érkezik, a felhasználó köteles az esetet haladéktalanul az adatvédelmi kapcsolattartónak jelezni.

---

11. Munkamenet-kezelési és eszközbiztonsági szabályok

11.1 Bejelentkezett munkamenet felügyelet nélkül hagyásának tilalma

11.1.1 Az aktív munkamenet biztonsági kockázata

Egy bejelentkezett, aktív Rendszer-munkamenet fenntartása alatt a böngésző localStorage tárolójában érvényes JWT hozzáférési és megújítási token él. E tokenek egy másik személy által bármikor felhasználhatók a Rendszerbe való belépésre és az abban tárolt adatokhoz, funkciókhoz való hozzáférésre, mindaddig, amíg a token le nem jár, illetőleg amíg a felhasználó ki nem jelentkezik. Az aktív munkamenet felügyelet nélkül hagyása ezért különösen veszélyes, mivel az illetéktelen személynek nincs szüksége a jelszó ismeretére — elegendő, ha az aktív böngészőablakhoz fizikailag hozzáfér.

11.1.2 A munkamenet felügyelet nélkül hagyásának tilalma

A felhasználó köteles minden olyan esetben gondoskodni a Rendszerből való kijelentkezésről vagy a munkamenet zárolásáról, amelyben az eszközt — akár rövid időre is — felügyelet nélkül hagyja. E kötelezettség az alábbi konkrét helyzetekre kiterjed:

• Irodai munkahely elhagyásakor (kávészünet, ebédszünet, megbeszélésre való távozás, irodai épület elhagyása), ha a számítógép aktív, bejelentkezett állapotban marad;
• Nyilvános helyszínen (könyvtár, kávézó, coworking iroda, konferenciaterem) ideiglenesen elhagyott eszköz esetén;
• Munka végeztével a munkanapon belüli utolsó Rendszer-használat befejezésekor, különösen, ha az eszköz megosztott, illetőleg ha az irodai asztalt más is használja;
• Eszközváltáskor, vagyis amikor a felhasználó ugyanazon böngészőablak nyitva hagyásával egy másik számítógépre, eszközre vált át.

11.1.3 A zárolás és kijelentkezés módszerei

A felhasználó az alábbi módszerek valamelyikével gondoskodhat a munkamenet biztonságáról:

Megosztott eszköz esetén a Rendszerből való kifejezett kijelentkezés az egyetlen elfogadható eljárás; a böngészőlap egyszerű bezárása nem elegendő.

11.2 Kijelentkezési kötelezettség megosztott eszközök esetén

11.2.1 A megosztott eszköz fogalma

Megosztott eszköznek minősül minden olyan számítógép, laptop, tablet vagy okostelefon, amelyet az érintett felhasználón kívül más személy is használ, vagy amelyhez más személy fizikai hozzáféréssel rendelkezik. Ide tartoznak különösen:

• irodai közös számítógépek (recepción, tárgyalóteremben, nyomtató mellett elhelyezett gépek);
• más munkatárs számítógépe, amelyet az érintett felhasználó ideiglenesen kölcsönvett;
• otthoni számítógép, amelyet a felhasználó más háztartási tagokkal oszt meg;
• nyilvánosan hozzáférhető számítógépek (könyvtár, internetkávézó, repülőtéri terminál).

11.2.2 Kötelező lépések megosztott eszközön való munkavégzés után

Megosztott eszközön való rendszerhasználat befejeztével a felhasználó az alábbi lépéseket kivétel nélkül kötelező jelleggel elvégzi:

1. Rendszerből való kijelentkezés: A Rendszer felületén a kijelentkezési funkció (signOut()) megnyomása, amely a JWT tokeneket a localStorage-ból törli.
2. localStorage manuális törlésének ellenőrzése: A kijelentkezés után a böngésző fejlesztői eszközeiben (DevTools, Application > Local Storage) ellenőrizhető, hogy a Rendszerhez kapcsolódó kulcsok (sb-[ref]-auth-token, ftp-saved-host, ftp-saved-user) valóban törlésre kerültek-e.
3. Böngészőlap / böngészőablak bezárása: A Rendszert tartalmazó fül(ek) bezárása, megelőzve, hogy a böngésző előzménye alapján más személy visszalépjen a Rendszer oldalára.
4. Böngészési előzmény törlése (ajánlott): Különösen érzékeny munkavégzés esetén a böngészési előzmény, a mentett jelszavak és a gyorsítótár törlése ajánlott.

11.2.3 Megosztott eszközön való tartós munkavégzés tilalma

Az Adatkezelő nem javasolja és lehetőség szerint kerülendőnek tartja, hogy a Rendszer érzékeny feladatok (pl. felhasználókezelés, audit napló megtekintése) elvégzésére rendszeresen megosztott eszközön kerüljön igénybe. Ha a munkavégzés körülményei ezt mégis szükségessé teszik, a felhasználó köteles fokozott körültekintéssel eljárni, és minden munkavégzési egység befejeztekor kivétel nélkül elvégezni a fenti lépéseket.

11.3 A böngésző localStorage tartalmának védelme

11.3.1 A localStorage-ban tárolt adatok érzékenysége

A Rendszer a böngésző localStorage tárolójában az alábbi adatokat őrzi:

A localStorage tartalmához — figyelembe véve a böngésző biztonsági modelljét — közvetlenül csak az azonos origin (domain + protokoll + port kombináció) alól futó JavaScript-kód fér hozzá. Ez praktikusan azt jelenti, hogy a localStorage tartalmát egy másik weboldal script-je nem olvashatja ki; azonban ugyanazon domain alatt futó, esetlegesen injektált vagy XSS-sérülékenységet kihasználó kód hozzáférhet.

11.3.2 A localStorage-tartalom védelme érdekében tett kötelező lépések

A felhasználó köteles az alábbi magatartást tanúsítani a localStorage-ban tárolt adatok védelme érdekében:

• Kijelentkezés megosztott eszközön: Amint a 11.2 pontban részletezésre került, megosztott eszközön a Rendszerből való kifejezett kijelentkezés elvégzése kötelező, mivel az egyedül biztosítja a JWT tokenek localStorage-ból való törlését.
• Gyanús böngészőbővítmények mellőzése: A Rendszert tartalmazó böngészőprofilban nem szabad megbízhatatlan, ismeretlen forrásból telepített böngészőbővítményeket (extensions) engedélyezni, mivel egyes rosszindulatú bővítmények képesek a localStorage tartalmát kiolvasni és továbbítani.
• A böngésző frissen tartása: A Rendszer eléréséhez használt böngészőt (Chrome, Firefox, Edge, Safari) rendszeresen frissíteni kell, mivel a böngészőfrissítések számos biztonsági sérülékenységet — köztük a localStorage-hoz való jogosulatlan hozzáférést lehetővé tévőket — javítanak.
• Eszköz elvesztése esetén azonnali bejelentés: Ha a localStorage-ban aktív JWT tokeneket tartalmazó eszköz elveszik vagy megrongálódik, a felhasználó köteles ezt haladéktalanul bejelenteni a Rendszergazdának, aki a Supabase Admin felületen a munkamenet-tokeneket érvénytelenítheti (session revoke), megelőzve ezzel az elveszett eszközről való jogosulatlan Rendszer-hozzáférést.

11.4 Saját eszköz védelméért való felhasználói felelősség

11.4.1 Az eszközbiztonság alapkövetelményei

A Rendszert a felhasználó saját eszközéről (vállalati vagy magáneszközről) veszi igénybe. Az eszköz biztonsága közvetlenül befolyásolja a Rendszer-munkamenet és a localStorage-ban tárolt adatok védelmét. Az Adatkezelő az alábbi alapkövetelmények teljesítését várja el a Rendszert igénybe vevő valamennyi eszköz tekintetében:

a) Operációs rendszer szintű hozzáférés-vezérlés:

• A Rendszert igénybe vevő eszköz operációs rendszere felhasználói fiókhoz kötött bejelentkezéssel és képernyőzárral legyen ellátva.
• A képernyőzár legfeljebb 5–10 perc inaktivitás után automatikusan aktiválódjon.
• A felhasználói fiók erős jelszóval vagy biometrikus azonosítóval (ujjlenyomat, arcfelismerés) legyen védett.
• Tilos olyan eszközön a Rendszert igénybe venni, amelyen az operációs rendszer bejelentkezési védelme le van tiltva, vagy amelyet jelszó nélkül bárki elindíthat.

b) Naprakész szoftverkörnyezet:

• Az operációs rendszer biztonsági frissítéseinek rendszeres telepítése.
• A Rendszer eléréséhez használt böngésző frissítéseinek rendszeres alkalmazása.
• Megbízható, naprakész vírusvédelmi és kártevőirtó szoftver alkalmazása (különösen Windows alapú eszközökön).

c) Fizikai biztonság:

• Az eszközt nyilvános helyen felügyelet nélkül hagyni tilos; lopás vagy elveszés esetén azonnal bejelentést kell tenni.
• Vállalati eszközök esetén az Adatkezelő belső IT-biztonsági szabályzata az irányadó a fizikai védelmi kötelezettségeket illetően.

11.4.2 Magáneszköz igénybevétele (BYOD — Bring Your Own Device)

Ha a felhasználó magántulajdonú eszközről (saját laptop, tablet, okostelefon) veszi igénybe a Rendszert, az alábbi különös feltételeknek kell teljesülniük:

• A magáneszköz teljesíti a 11.4.1 pontban meghatározott alapkövetelményeket.
• A magáneszközön a Rendszer localStorage-ban tárolt adatai — a 11.2.2 pontban meghatározott kötelezettségeknek megfelelően — a munkavégzés befejeztekor törlésre kerülnek, ha az eszközt más háztartási tagok is használják.
• A magáneszköz elvesztése vagy ellopása esetén a felhasználó azonnal értesíti a Rendszergazdát, hogy a Supabase munkamenet-tokenek érvényteleníthetők legyenek.

Az Adatkezelő fenntartja a jogot arra, hogy biztonsági okokból a magáneszközökről való Rendszer-hozzáférést belső szabályzatban korlátozza vagy kizárólag meghatározott eszközökre engedélyezze.

11.4.3 Elveszett vagy kompromittált eszköz esetén követendő eljárás

Ha a Rendszert igénybe vevő eszköz elveszik, ellopják, illetőleg a felhasználó alapos gyanút szerzett arra, hogy az eszköz adatait más személy elérte (pl. kártékony szoftver telepítése, fizikai hozzáférés feltételezése), az érintett felhasználó az alábbi lépéseket haladéktalanul elvégzi:

1. Rendszergazda azonnali értesítése az eseményről és az eszközön tárolt Rendszer-munkamenet-adatokról (tokenekről).
2. Munkamenet-tokenek érvénytelenítése: A Rendszergazda a Supabase Admin felületen az érintett felhasználó munkamenet-tokenjeit érvényteleníti (session revoke), megelőzve ezzel az elveszett eszközről való jogosulatlan Rendszer-hozzáférést.
3. Jelszócsere: A felhasználó az eseményt követően haladéktalanul — legkésőbb az eszköz pótlásával egyidejűleg — megváltoztatja a Rendszerhez használt jelszavát.
4. Incidensbejelentés: Az esemény a 13. fejezet szerinti incidensgyanú-bejelentési kötelezettség alá eshet; a felhasználó az adatvédelmi kapcsolattartónak is bejelenti az esetet.

11.5 Nyilvános vagy nem megbízható hálózatokra vonatkozó szabályok

11.5.1 HTTPS-kapcsolat mint alapvető védelem

A Rendszer éles környezete kizárólag titkosított HTTPS-kapcsolaton érhető el. Ez azt jelenti, hogy a böngésző és a Cloudflare Worker backend között az adatforgalom — beleértve a bejelentkezési hitelesítő adatokat, a JWT tokeneket, a feltöltött fájlok tartalmát és a profiladatokat — TLS-titkosítással védett, és hálózati szinten lehallgatva értelmezhetetlen marad. A HTTPS-kapcsolat védelmet nyújt a man-in-the-middle (MITM) típusú támadásokkal szemben, amennyiben a TLS-tanúsítvány érvényes és hiteles.

11.5.2 Nyilvános Wi-Fi hálózatokon való Rendszer-használat kockázatai és szabályai

Nyilvános Wi-Fi hálózatokon (repülőtér, szálloda, kávézó, bevásárlóközpont) való Rendszer-hozzáférés az alábbi kockázatokat hordozza:

• Nem megbízható hálózati infrastruktúra: Nyilvános Wi-Fi hálózatokon a hálózati forgalmat potenciálisan más résztvevők is megfigyelhetik; hamis hozzáférési pontok (evil twin AP) valódi hálózatnak álcázhatók.
• Nem titkosított kiegészítő adatforgalom: Bár a Rendszer HTTP-kérései HTTPS-titkosítással védve vannak, a DNS-lekérdezések és egyéb háttérforgalom esetlegesen titkosítatlan csatornán valósulhat meg.
• Fokozott phishing-kockázat: Nyilvános hálózatokon a captive portalok és a rosszindulatú átirányítások révén az érintett figyelmét el lehet terelni.

A fenti kockázatok csökkentése érdekében a felhasználónak az alábbi intézkedések megtétele ajánlott:

• VPN-kapcsolat használata nyilvános Wi-Fi hálózatokon való Rendszer-hozzáférés esetén;
• A böngésző által megjelenített TLS-tanúsítványra vonatkozó figyelmeztetések komolyan vétele és a Rendszerbe való belépés mellőzése, ha a böngésző érvénytelen vagy nem megbízható tanúsítványra figyelmeztet;
• Különösen érzékeny műveletek (pl. új felhasználó meghívása, jelszóvisszaállítás, audit napló megtekintése) elvégzésének nyilvános hálózatokról való lehetőség szerint mellőzése — ezek megbízható, kontrollált hálózatokra halasztása.

11.5.3 Titkosítatlan (HTTP) protokollon való hozzáférési kísérlet

Ha a felhasználó a Rendszert HTTP protokollon (titkosítás nélkül) próbálja elérni (pl. http://georto.com URL-t gépelve), a Cloudflare Worker backend a kérést automatikusan HTTP 301 permanens átirányítással az HTTPS-változatra irányítja. A felhasználónak e tekintetben nincs külön teendője; az átirányítás szerver oldalon automatikusan érvényesül. Mindemellett a felhasználónak ajánlott a Rendszert kizárólag a https://georto.com prefix megadásával elérni.

---

12. A rendszerbiztonsági intézkedések ismerete és betartása

12.1 HTTPS-kapcsolat kötelező használata és a TLS-védelem értelmezése

12.1.1 A HTTPS-kapcsolat kötelező jellege

A Rendszer éles környezetének valamennyi funkcióját — beleértve a bejelentkezést, a fájlkezelési műveleteket, a felhasználókezelést és az összes API-kérést — kizárólag HTTPS-protokollon (TLS titkosítással) keresztül szabad igénybe venni. Az éles környezetben HTTP-protokollon érkező kérések szerver oldalon automatikusan HTTPS-re kerülnek átirányításra; azonban a felhasználónak tudatosan is a HTTPS-URL-t kell alkalmaznia.

12.1.2 A TLS-tanúsítvány érvényességének ellenőrzése

A böngésző a Rendszer betöltésekor automatikusan ellenőrzi a Cloudflare által biztosított TLS-tanúsítvány érvényességét. Ha a böngésző az alábbi figyelmeztetések valamelyikét jeleníti meg, a felhasználónak tilos a Rendszerbe belépni, és köteles az esetet haladéktalanul a Rendszergazdának és az adatvédelmi kapcsolattartónak bejelenteni:

• „A kapcsolat nem biztonságos" / „Your connection is not private" (NET::ERR_CERT_AUTHORITY_INVALID, NET::ERR_CERT_DATE_INVALID stb.)
• „Lehetséges, hogy valaki megpróbálja ellopni az adatait a georto.com webhelyről"
• „Az SSL-tanúsítvány lejárt" vagy „A tanúsítványban szereplő domain nem egyezik"

E figyelmeztetések man-in-the-middle (MITM) támadásra, lejárt tanúsítványra vagy hibás szerverkonfigurációra utalhatnak, és mindhárom esetben azonnali technikai vizsgálatot tesznek szükségessé.

12.2 CORS-korlátozás és az API közvetlen elérésének tilalma

12.2.1 A CORS-mechanizmus rendeltetése és hatálya

A Cloudflare Worker backend Cross-Origin Resource Sharing (CORS) szabályai biztosítják, hogy a Rendszer API-ját kizárólag az éles https://georto.com domainről érkező böngészős kérések érhessék el. Bármely más domainről érkező, a Rendszer API-jára irányuló böngészős kérés CORS-hiba miatt automatikusan elutasításra kerül.

A CORS-mechanizmus elsődleges célja a Cross-Site Request Forgery (CSRF) jellegű támadások kivédése: megakadályozza, hogy egy rosszindulatú weboldal az érintett felhasználó böngészőjén keresztül jogosulatlan API-kéréseket küldjön a Rendszerbe, felhasználva az érvényes munkamenet-tokent.

12.2.2 Az API közvetlen elérésének tilalma böngészőn kívüli eszközökkel

A Rendszer API-végpontjainak böngészőn kívüli eszközökkel (pl. curl, Postman, Insomnia, Python requests könyvtár, Node.js fetch, automatizált szkriptek) való közvetlen elérése az alábbi szabályok szerint minősítendő:

• Tiltott, ha az elérés célja jogosulatlan adathozzáférés, a RBAC megkerülése, vagy a Szabályzatban tiltott tevékenység elvégzése. Az ilyen kísérlet a Szabályzat 5.2.1 pontja szerinti jogosulatlan hozzáférési kísérletnek minősül, és a 18. fejezetben meghatározott következményeket vonja maga után.
• Megengedett, ha az elérés a Rendszer fejlesztésével, tesztelésével vagy karbantartásával megbízott munkatárs által, az Adatkezelő megbízásából, dokumentált célból és a szükséges jogosultságokkal rendelkezve, kizárólag fejlesztői / tesztkörnyezetben valósul meg. Az éles környezetű API közvetlen, automatizált elérése fejlesztési, tesztelési céllal is kizárólag a Rendszergazda és az adatvédelmi kapcsolattartó előzetes tájékoztatása és jóváhagyása mellett lehetséges.

12.2.3 Gyanús CORS-hibák bejelentési kötelezettsége

Ha a felhasználó a Rendszer normál, böngészős igénybevétele során váratlan CORS-hibaüzenetet észlel (amelyet nem maga okozott nem engedélyezett forrásból való hozzáférési kísérlettel), köteles azt haladéktalanul a Rendszergazdának bejelenteni, mivel ez esetlegesen a szerverkonfiguráció megváltoztatására irányuló, illetéktelen beavatkozás jele lehet.

12.3 IP-alapú kérésszám-korlátozás — felhasználói szempontból

12.3.1 A rate limiting rendeltetése és aktiválódásának feltétele

A Cloudflare Worker backend az IP-cím alapú kérésszám-korlátozást (rate limiting) a visszaélések és DoS-támadások elhárítása érdekében alkalmazza. A korlát percenként 1000 kérés; ezt meghaladó kérésszám esetén a szerver HTTP 429 Too Many Requests hibakóddal utasítja vissza a kérést. A korlátozás alól kivételt képeznek a GET és HEAD módszerű /files/… kérések (PMTiles és FGB fájlok byte-range alapú olvasása): ezek nem számítanak bele a percenkénti kérésszámba, mivel a térképbetöltés természetéből adódóan sok párhuzamos kérést igényelhet. A többi API-végpont korlátozott; a korlát a böngészőből a Rendszer szokásos, emberi ütemű igénybevétele esetén soha nem aktiválódik.

12.3.2 A rate limit aktiválódásának lehetséges okai és teendők

Ha a felhasználó HTTP 429-es hibaüzenetet kap a Rendszer használata közben, az az alábbi okokból fakadhat:

A rate limit 60 másodperces TTL-jéből következik, hogy a korlátozás 1 perc elteltével automatikusan feloldódik; a felhasználónak jellemzően rövid várakozás után folytathatja a munkáját.

12.3.3 A rate limiter szándékos aktiválásának tilalma

Amint a Szabályzat 5.2.4 pontjában meghatározásra került, a rate limiter szándékos aktiválása — vagyis a percenkénti 1000 kérést meghaladó, automatizált kéréscsomag tudatos generálása — tilos. Az ilyen magatartás a Rendszer más felhasználók számára való elérhetőségét veszélyezteti, és az Adatkezelő infrastruktúráját károsítja.

12.4 A szerepköralapú hozzáférés-vezérlés megkerülésének tilalma és következményei

12.4.1 A RBAC megkerülési kísérletének tilalma és minősítése

Amint a 4.1.2 pontban részletesen kifejtésre került, a Rendszer szerepköralapú hozzáférés-vezérlési mechanizmusainak (RBAC) megkerülésére irányuló bármely kísérlet a Szabályzat súlyos megsértésének minősül. E tilalom a konkrét technikai megvalósítástól függetlenül fennáll; az alábbiakban a leggyakoribb megkerülési módszerek tételesen kerülnek nevesítésre, kizárva ezzel a nem tudatos jogsértésre való hivatkozás lehetőségét:

Tiltott megkerülési módszerek:

12.4.2 A szerver oldali visszautasítás és naplózás következményei

A fenti tilalmas kísérleteket a szerver HTTP 401 (hitelesítési hiba) vagy HTTP 403 (jogosultság-megtagadás) hibakóddal utasítja vissza. Bár maga a visszautasítás meggátolja az érdemi jogosulatlan hozzáférést, a kísérlet ténye:

• a Cloudflare Workers hibanaplóiban rögzítésre kerülhet;
• az adatvédelmi kapcsolattartó és a Rendszergazda tudomására juthat;
• a 18. fejezetben meghatározott munkajogi és — különösen ismételt, szándékos kísérlet esetén — büntetőjogi következményeket vonhat maga után.

12.5 A Supabase RLS-szabályok és a szerver oldali ellenőrzések jelentőségének ismerete

12.5.1 Az RLS-szabályok felhasználói szintű értelmezése

A Supabase PostgreSQL adatbázisában alkalmazott Row Level Security (RLS) szabályok adatbázis-szintű garanciát nyújtanak arra, hogy a felhasználók az adatbázis tábláinak kizárólag a számukra engedélyezett sorait olvashassák, módosíthassák, vagy törölhessék. E szabályok automatikusan és a felhasználói interakciótól függetlenül érvényesülnek; a felhasználónak a szabályok működtetéséhez semmilyen tevékenységet nem kell végezni.

Az RLS-szabályok legfontosabb felhasználói következményei:

• A profiles tábla minden hitelesített felhasználó által olvasható (a Rendszer felhasználókezelési felülete és a névmegjelenítés ezt igényli), azonban saját profilját kizárólag az érintett felhasználó módosíthatja (auth.uid() = user_id feltétel).
• A user_consents tábla rekordjai közül minden hitelesített felhasználó kizárólag a saját sorait olvashatja, kivéve a Rendszergazdát, aki adminisztrációs célból valamennyi rekordot megtekintheti. Az INSERT, UPDATE és DELETE tiltott authenticated jogosultsággal; a meglévő sorok módosítását adatbázis-szintű trigger is blokkolja. Az elfogadási rekord létrehozása kizárólag a Worker POST /consents végponton keresztül lehetséges; verziófrissítéskor új sor jön létre, a korábbi rekordok megmaradnak.
• A user_messages tábla olvasottsági rekordjaihoz authenticated felhasználóknak nincs közvetlen adatbázis-hozzáférésük; az üzenetek megjelenítése és olvasottként jelölése kizárólag a Worker GET /messages és POST /messages/seen API-végpontjain keresztül valósul meg. Más felhasználó olvasottsági adatait senki nem tekintheti meg, kivéve szerver oldali, service role key-jel végzett adminisztrációs műveletek során a Rendszergazdát.

12.5.2 A szerver oldali ellenőrzések kizárólagos biztonsági szerepe

A felhasználónak tisztában kell lennie azzal, hogy a Rendszer biztonsági védelme szerver oldalon valósul meg, nem kizárólag a böngészőben futó kód szintjén. Ez a körülmény az alábbi következményekkel jár:

• A böngészőben futó JavaScript-kód módosítása — akár a DevTools segítségével, akár böngészőbővítménnyel — nem teszi lehetővé a szerver oldali RBAC- és RLS-korlátok megkerülését; a szerver minden kérésnél önállóan elvégzi az ellenőrzést, függetlenül attól, hogy a kliens oldal mit mutat.
• A kliens oldali felületi korlátozások (updateUIByRole()) kizárólag a felhasználói élményt és az átláthatóságot szolgálják, nem tekinthetők biztonsági intézkedésnek; a tényleges biztonság a Cloudflare Worker szerver oldali szerepkör-ellenőrzésén és az adatbázis szintű RLS-szabályokon alapul.
• A felhasználó nem tehet sikeres kísérletet arra, hogy a böngésző DevTools-ában látható API-kérések paramétereinek módosításával magasabb jogosultságú funkciókhoz férjen hozzá; a szerver minden esetben visszautasítja a jogosultság nélküli kérelmet.

12.5.3 Az érvényes JWT-token nélküli hozzáférési kísérlet automatikus visszautasítása

Minden API-kérés a verifyAuth() hitelesítési ellenőrző függvényen keresztül kerül feldolgozásra. Érvényes JWT hozzáférési token hiányában:

• A szerver HTTP 401 Unauthorized hibakóddal utasítja vissza a kérést.
• A felhasználónak nincs lehetősége adatokhoz hozzáférni, fájlokat kezelni, vagy bármilyen funkciót igénybe venni.
• Az automatikus token-megújítási mechanizmus lejárt refresh token esetén új bejelentkezésre kényszeríti a felhasználót.

A felhasználónak tudnia kell, hogy ez az automatikus visszautasítás a Rendszer szándékolt, helyes működése — nem hibának, hanem biztonsági funkciónak tekintendő. Váratlan, sorozatos hitelesítési hiba esetén a Rendszergazdát kell értesíteni, mivel az incidensgyanút vethet fel.

---

IV. RÉSZ – INCIDENSKEZELÉSI KÖTELEZETTSÉGEK

---

13. Adatvédelmi incidensek azonosítása és bejelentése

13.1 Az incidens fogalma és típusai

13.1.1 Az adatvédelmi incidens GDPR-szerinti meghatározása

A GDPR 4. cikk 12. pontja értelmében adatvédelmi incidens: a biztonság olyan sérülése, amely a továbbított, tárolt vagy más módon kezelt személyes adatok véletlen vagy jogellenes megsemmisítését, elvesztését, megváltoztatását, jogosulatlan közlését vagy az azokhoz való jogosulatlan hozzáférést eredményezi. Jelen Szabályzat alkalmazásában az incidens fogalma magában foglalja mindazokat az eseményeket, amelyek a Rendszerben kezelt személyes adatok bizalmasságát, integritását vagy rendelkezésre állását veszélyeztetik vagy sértik.

Az adatvédelmi incidenst a Rendszer vonatkozásában — az Adatkezelő Adatvédelmi Incidenskezelési Szabályzatával összhangban — az alábbi három alapkategória szerint kell azonosítani:

13.1.2 Az incidens súlyossági fokozatai és azok felhasználói relevanciája

A Rendszerben bekövetkező incidenseket az Adatkezelő kockázatalapú megközelítéssel minősíti. A felhasználónak nem feladata az incidens formális kockázatértékelése — ez az adatvédelmi kapcsolattartó és a Rendszergazda kompetenciájába tartozik —, azonban a felhasználónak alapszinten tisztában kell lennie azzal, hogy:

• Alacsony kockázatú incidens: Valószínűtlen, hogy az érintettekre nézve komolyabb következménnyel jár (pl. rövid ideig tartó rendelkezésre állási zavar személyes adatvesztés nélkül). Belső kezelés és dokumentálás szükséges, hatósági bejelentés nem feltétlenül kötelező.
• Közepes kockázatú incidens: Bizonyos mértékű hátrányt okozhat az érintetteknek (pl. személyes adatok korlátozottabb körű jogosulatlan megismerése). Belső vizsgálat és valószínűleg hatósági bejelentés szükséges.
• Magas kockázatú incidens: Valószínű, hogy súlyos hátrányos következményekkel jár az érintettekre nézve (pl. jelszavak és egyéb érzékeny adatok tömeges kompromittálódása, Rendszergazdai fiók feltörése). Azonnali hatósági bejelentés és érintetti értesítés szükséges.

A felhasználó felelőssége az incidens azonnali észlelése és belső bejelentése — a kockázatminősítés elvégzése nem a felhasználói feladatkör része.

---

13.2 A Georto Vision rendszerre jellemző tipikus incidenstípusok

A következő pontokban tételesen kerülnek felsorolásra azok az incidens-forgatókönyvek, amelyek a Rendszer konkrét technikai architektúrájából és adatkezelési folyamataiból fakadóan a legvalószínűbben fordulhatnak elő. A felhasználónak e forgatókönyveket ismernie kell annak érdekében, hogy azokat felismerve, késlekedés nélkül megtegye a 13.4 pontban meghatározott bejelentési lépéseket.

13.2.1 Fiókadatok és jelszavak kompromittálódása

Leírás: A felhasználó bejelentkezési adatai — e-mail cím és jelszó — jogosulatlan harmadik személy tudomására jutnak, függetlenül attól, hogy ez a felhasználó gondatlanságából (pl. jelszó megosztása, adathalász oldal kitöltése), külső támadás következtében (pl. brute-force kísérlet sikere), vagy infrastruktúraoldali szivárgás miatt következik-e be.

Felismerés jelei:

• A bejelentkezés során „Érvénytelen bejelentkezési adatok” hibaüzenet jelenik meg, noha a felhasználó nem változtatta meg a jelszavát (pl. illetéktelen jelszócsere vagy rendszergazdai visszaállítás után).
• A felhasználó általa nem kezdeményezett jelszó-visszaállító e-mailt kap a Supabase Auth-tól (a bejelentkezes.html „Elfelejtetted a jelszavad?” funkcióján keresztül indított resetPasswordForEmail folyamat).
• A Rendszer váratlanul kijelentkezteti, és a bejelentkezes.html oldalra irányít (HTTP 401 — érvénytelen vagy lejárt munkamenet), noha a felhasználó nem lépett ki.
• A profilpanelen (vezetéknév, keresztnév, e-mail-cím, profilkép) vagy a saját térképkonfigurációkban olyan változást észlel, amelyet nem ő végzett.
• Adathalász (phishing) e-mailt kap, vagy a Rendszer bejelentkezési oldalát utánzó, gyanús weboldalt azonosít.
• A Rendszergazda vagy az adatvédelmi kapcsolattartó gyanús fiókhasználatról értesíti (pl. belső rendszerüzenet).

Teendő: Azonnali belső bejelentés a Rendszergazdának és az adatvédelmi kapcsolattartónak; a fiók jelszavának haladéktalan megváltoztatása (amennyiben a hozzáférés még lehetséges); a Rendszerből való kijelentkezés minden aktív munkamenetből.

13.2.2 JWT tokenek jogosulatlan kézre kerülése

Leírás: A felhasználó böngészőjének localStorage-ában tárolt, érvényes JWT hozzáférési és megújítási token (sb-[ref]-auth-token) jogosulatlan személy vagy folyamat által megszerezhetővé válik. A token birtokában az illetéktelen személy a jelszó ismerete nélkül API-kéréseket indíthat a Rendszerbe (fetchWithAuth, Authorization: Bearer fejléc). Ez bekövetkezhet:

• Cross-Site Scripting (XSS) sebezhetőség vagy rosszindulatú böngészőbővítmény kihasználásával, amely hozzáfér a localStorage tartalmához;
• a felhasználó eszközéhez fizikailag hozzáférő illetéktelen személy által (pl. a böngésző DevTools felületén keresztül);
• megosztott számítógépen bejelentkezve hagyott, felügyelet nélküli munkamenet révén.

Felismerés jelei:

• A profilpanelen, a saját térképkonfigurációkban vagy — szerkesztői/rendszergazdai jogkör esetén — a tárhelyen olyan módosítás jelenik meg, amelyet a felhasználó nem végzett (a token birtokosa a felhasználó nevében API-kéréseket indíthat).
• A Rendszer váratlanul kijelentkezteti, és a bejelentkezes.html oldalra irányít (HTTP 401), noha a felhasználó nem lépett ki — pl. jelszócsere vagy rendszergazdai beavatkozás után, amely a meglévő tokeneket érvénytelenné teszi.
• Az eszközön ismeretlen böngészőbővítményt vagy gyanús szkriptet azonosít.
• Megosztott eszköz használata után olyan állapotot talál (pl. módosított beállítások, nyitott munkamenet), amely arra utal, hogy illetéktelen személy hozzáfért a bejelentkezett böngészőhöz.
• A Rendszergazda a tevékenységi naplóban (app_data/file_log_{timestamp}.json) a felhasználó nevéhez köthető, de általa nem végzett fájlműveletet észlel, és erről értesíti az érintettet.

Teendő: Azonnali belső bejelentés; jelszócsere elvégzése (amennyiben a hozzáférés még lehetséges); a Rendszerből való kijelentkezés; szükség esetén a Rendszergazda a Supabase Admin felületen érvénytelenítheti az érintett munkamenet-tokeneket, illetve ideiglenes jelszót állíthat be (POST /reset-user-password).

13.2.3 Adatfeldolgozói oldali incidensek (Supabase, Cloudflare)

Leírás: A Rendszer adatfeldolgozói — a Supabase, Inc. és a Cloudflare, Inc. — platformjain bekövetkező biztonsági esemény, amely érintheti a Rendszerben kezelt személyes adatokat. Ilyen esemény lehet a Supabase adatbázis-szivárgása, a Cloudflare Workers platformon bekövetkező jogosulatlan hozzáférés, vagy a szolgáltatók saját rendszereiben azonosított biztonsági rés.

Felismerés jelei: Az adatfeldolgozói oldali incidensek felhasználói szinten közvetlenül jellemzően nem ismerhetők fel; ezek elsősorban az Adatkezelő üzemeltetői kommunikációján keresztül, a Supabase és Cloudflare nyilvános biztonsági közleményeiből, illetve a Rendszer rendellenességeiből derülhetnek ki.

Teendő: Ha a felhasználó nyilvánosan elérhető forrásból (pl. adatfeldolgozói biztonsági értesítő) értesül a Supabase vagy Cloudflare platformját érintő incidensről, köteles azt haladéktalanul a Rendszergazdának jelezni.

13.2.4 R2 tárhely nem kívánt nyilvánossá válása

Leírás: A Cloudflare R2 objektumtárban (georto-vision-r2) elhelyezett fájlok konfigurációs hiba vagy illetéktelen beavatkozás következtében nyilvánosan elérhetővé válhatnak, elveszítve hozzáférés-vezérlési védettségüket. Normál üzemelés mellett az R2 közvetlen, nyilvános eléréssel nem rendelkezik; a hozzáférés kizárólag a Cloudflare Worker API-n keresztül, érvényes JWT-tokennel és megfelelő szerepkörrel történik. Az R2-ben tárolt adatkategóriák:

• Geodata-fájlok — a bucket gyökérkönyvtárában (.fgb és .pmtiles, lásd: 7.1.1);
• Térképkonfigurációk — app_data/maps_{userId}.json (térképek, fájlok listája, láthatósági beállítások, megosztási metaadatok);
• Tevékenységi napló — app_data/file_log_{timestamp}.json (fájlműveletek időpontja, elvégző neve).

Felismerés jelei:

• A felhasználó arról értesül (külső fél, munkatárs, Rendszergazda vagy adatvédelmi kapcsolattartó jelzése alapján), hogy az R2-ben tárolt geodata-fájljai, térképkonfigurációi vagy a tevékenységi napló tartalma a Cloudflare Worker API-n (GET /files/…, JWT) keresztül szokásos módon nem érhető el, de mégis illetéktelenül hozzáférhetővé vált.
• A Rendszeren kívüli személy olyan fájltartalomról vagy metaadatról (pl. fájlnév, térképkonfiguráció, megosztási adat, naplóbejegyzés) tud, amelyhez normál üzemelés mellett csak bejelentkezett, jogosult felhasználó férhetett volna hozzá.
• Cloudflare vagy az Adatkezelő nyilvános biztonsági közleménye, illetve belső értesítés R2-bucket konfigurációs hibáról vagy jogosulatlan infrastruktúra-hozzáférésről érkezik.
• A tárhelyen új fájl jelenik meg, meglévő fájl tűnik el vagy változik meg a felhasználó tudta és a tevékenységi napló bejegyzései nélkül — infrastruktúra-szintű beavatkozás gyanúja (kizárólag rendszergazda vagy infrastruktúra-hozzáféréssel rendelkező személy észlelheti közvetlenül).

Teendő: Azonnali belső bejelentés; az érintett fájlokat törölni nem szabad (bizonyítékmegőrzési kötelezettség).

13.2.5 Rendszergazdai fiók feltörése

Leírás: A Rendszer Rendszergazda szerepkörű fiókjához illetéktelen személy hozzáférést szerez. Ez a legsúlyosabb incidenstípusok egyike, mivel a Rendszergazda a felhasználói fiókok kezelésére, a szerepkörök módosítására, a meghívók kiadására, a naplók megtekintésére és az összes feltöltött fájl elérésére jogosult.

Felismerés jelei:

• A Rendszergazda saját fiókjába nem tud bejelentkezni, váratlan kijelentkeztetés történik (HTTP 401), általa nem kezdeményezett jelszó-visszaállító e-mail érkezik, vagy a tevékenységi naplóban a saját nevéhez köthető, általa nem végzett fájlműveletek jelennek meg.
• Más felhasználók esetén szerepkörük megváltozik a profilpanelen (profiles.role mező), de a módosítást senki nem kommunikálta; e-mail-címük vagy jelszavuk rendszergazdai beavatkozás nélkül nem kért módon változik (POST /update-email, POST /reset-user-password); fiókjuk váratlanul törlődik (DELETE /user/{userId}); vagy belső rendszerüzenetet kapnak, amelyet nem indokolt az Adatkezelő.
• Új, ismeretlen fiók jelenik meg a Rendszerben — olyan e-mail-című vagy nevű felhasználó, akinek létrehozását (POST /invite) senki nem kommunikálta (a profiles tábla minden hitelesített felhasználó számára olvasható).
• A tárhelyen (szerkesztői/rendszergazdai jogkörrel) olyan fájlfeltöltés, törlés vagy átnevezés történik, amelyet a tevékenységi napló a Rendszergazda nevéhez rendel, de az érintett Rendszergazda nem végezte — ezt más rendszergazda a naplóból, illetve a tárhely felhasználói a fájllistában észlelhetik.
• Adathalász e-mail, hamis bejelentkezési oldal vagy a Rendszergazda jelszavának illetéktelen megismerésének gyanúja merül fel.

Teendő: Azonnali belső bejelentés az adatvédelmi kapcsolattartónak és az ügyvezetőnek; magas kockázatú incidensként kezelendő, hatósági bejelentési kötelezettség és érintetti értesítés várható.

13.2.6 Egyéb beazonosított incidenstípusok — az I-01 – I-14 kategóriák áttekintése

Az Adatkezelő Adatvédelmi Incidenskezelési Szabályzata az alábbi incidenstípus-katalógust tartalmazza, amelyeket a felhasználónak alapszinten ismernie kell:

A felhasználó az I-01–I-14 kategóriák bármelyikébe sorolható esemény észlelésekor — vagy annak gyanúja esetén — köteles a 13.4 pontban meghatározott bejelentési eljárást haladéktalanul megindítani.

---

13.3 Mi NEM minősül adatvédelmi incidensnek — nem minősülő esetek

A Szabályzatnak a tilalmas és bejelentendő eseményekre vonatkozó rendelkezései kizárólag a valóban jogosulatlan, jogellenes vagy kockázatos eseményekre alkalmazandók. Egyúttal szükséges annak egyértelmű rögzítése, hogy melyek azok a helyzetek, amelyek — bár adatkezelési műveletet valósítanak meg — a Rendszer rendeltetésszerű, jogszerű működéséből fakadnak, és ezért nem minősülnek adatvédelmi incidensnek.

13.3.1 Belső csapatmunkán alapuló fájlkezelési műveletek

Az alábbi, a Rendszer rendeltetésszerű belső csapatmunkájából fakadó fájlkezelési műveletek — még ha azok más felhasználó által feltöltött adatokhoz való hozzáférést is érintenek — nem minősülnek adatvédelmi incidensnek:

• Rendszergazda/Szerkesztő szerepkörű felhasználónak más Rendszergazda/Szerkesztő szerepkörű felhasználó által feltöltött geodata-fájl megtekintése, térképes megjelenítése, átnevezése vagy törlése a Rendszer rendeltetésének megfelelően, a kijelölt munkafeladat elvégzése céljából;
• Geodata-fájlokban esetlegesen szereplő személyes adatok (pl. helyszín-koordináták, amelyek közvetve személy azonosítására alkalmasak) megismerése a szakmai munkafeladat keretein belül, amennyiben az adatokat az érintett szerkesztői jogkörrel rendelkező munkatárs kezeli, és az adatok megismerése a munkafeladat elvégzéséhez szükséges;
• Fájlok törlése a Rendszerben a szerkesztői jogosultság keretein belül, amennyiben a törlésnek nem célja az adatok megsemmisítése jogosulatlan módon.

13.3.2 Rendszergazdai fiókkezelési tevékenységek

Az alábbi, Rendszergazda által végzett fiókkezelési műveletek a jogszerű adatkezelés keretein belül esnek, és nem minősülnek adatvédelmi incidensnek:

• Új felhasználó meghívása a Rendszerbe (meghívóküldés, fiók aktiválásának jóváhagyása);
• Meglévő felhasználó szerepkörének módosítása az Adatkezelő döntése alapján (pl. Felhasználóból Szerkesztővé emelés, vagy Szerkesztőből Felhasználóvá visszaminősítés);
• Felhasználói fiók ideiglenes felfüggesztése vagy végleges törlése az Adatkezelő utasítására;
• Ideiglenes jelszó generálása és átadása az érintett felhasználónak beléptetési folyamat keretében;
• A tevékenységi napló megtekintése a Rendszergazda jogosultságai keretein belül, adminisztrációs, karbantartási vagy incidensmegelőzési céllal;
• Rendszerüzenetek küldése valamennyi vagy egyes felhasználók részére.

13.3.3 Technikai működésből eredő, kockázat nélküli adatfeldolgozások

Az alábbi, a Rendszer rendeltetésszerű technikai működéséből fakadó automatikus adatkezelési folyamatok nem minősülnek adatvédelmi incidensnek:

• JWT token automatikus megújítása (refresh) a munkamenet fennállása alatt, a Supabase Auth által végzett lejárati és megújítási mechanizmus részeként;
• Munkamenet-tokenek lejárata és törlése az alkalmazásból való kijelentkezéskor (signOut()) vagy a munkamenet lejártakor; érvénytelen token esetén a Rendszer HTTP 401-es választ ad, és a felhasználót a bejelentkezési oldalra irányítja;
• A tevékenységi napló (app_data/file_log_{timestamp}.json) automatikus frissítése az R2-ben tárolt .fgb és .pmtiles fájlok feltöltése, törlése és átnevezése után — a naplóbejegyzésben az elvégző felhasználó neve (vezetéknév + keresztnév) szerepel; e-mail-cím és egyéb műveletek (pl. térképkonfiguráció mentése, profil módosítás) a naplóba nem kerülnek;
• GPS-helymeghatározás a böngészőben, a munkamenet során — a koordináták szerverre nem kerülnek továbbításra, adatbázisban és Cloudflare KV-ben nem tárolódnak (lásd: 6.3.2);
• IP-alapú kérésszám-számláló ideiglenes tárolása a Cloudflare KV-ben (rate-limit:{ip}, 60 másodperces TTL) a rate limiting működése érdekében;
• A rendszerüzenetek olvasottsági állapotának rögzítése a user_messages táblában (POST /messages/seen).

---

13.4 A bejelentési kötelezettség és határidők

13.4.1 Belső bejelentés: a kétórás határidő

A felhasználó — függetlenül a betöltött szerepkörtől — köteles az észlelt vagy alapos gyanúval feltételezett adatvédelmi incidenst az észleléstől számított legkésőbb 2 (két) órán belül bejelenteni a Rendszergazdának és az adatvédelmi kapcsolattartónak. E határidő betartása különös jelentőséggel bír, mivel az Adatkezelőnek a GDPR 33. cikke értelmében az incidens tudomásra jutásától számított 72 órán belül kell a Nemzeti Adatvédelmi és Információszabadság Hatóságnak (NAIH) bejelentést tennie, amennyiben az incidens valószínűsíthetően kockázatot jelent az érintett természetes személyek jogaira és szabadságaira nézve.

A 2 órás belső határidő célja, hogy az Adatkezelő kellő időt kapjon:

• az incidens kivizsgálására és kockázatminősítésére;
• a szükséges azonnali műszaki elhárító intézkedések megtételére;
• a NAIH felé fennálló bejelentési kötelezettség teljesítésére;
• az érintett felhasználók értesítésének előkészítésére.

A 2 órás határidő mulasztása a felhasználó felelősségét vonja maga után, és a 18. fejezetben meghatározott következményeket alapozhatja meg.

13.4.2 A bejelentés módja és csatornái

A belső incidensbejelentést az alábbi csatornákon kell megtenni:

Ha az incidens jellege miatt a Rendszerbe való bejelentkezés nem lehetséges (pl. a Rendszergazdai fiók feltörésére utaló jelek esetén a rendszeren belüli kommunikáció kerülendő), a bejelentés kizárólag a Rendszeren kívüli csatornákon (telefon, személyes megkeresés, egyéb belső kommunikációs platform) történjen.

A bejelentésnek tartalmaznia kell:

• a felhasználó nevét és szerepkörét;
• az észlelés pontos időpontját;
• az esemény rövid, tényszerű leírását (mit észlelt, mikor, hol, milyen körülmények között);
• az általa gyanított incidenstípust (ha meghatározható);
• azt, hogy az incidens az I-01–I-14 kategóriák közül melyiknek felelhet meg (ha meghatározható);
• az általa eddig megtett lépéseket (ha tett ilyet);
• a rendelkezésre álló bizonyítékokat (képernyőfelvételek, értesítések, e-mailek, böngészőkonzol-bejegyzések).

13.4.3 Bizonyítékok megőrzésének kötelezettsége és a törlési tilalom

Az incidens észlelésétől kezdődően a felhasználó köteles az összes rendelkezésére álló, az incidenssel összefüggésbe hozható bizonyítékot megőrizni, és azokat haladéktalanul a Rendszergazda / adatvédelmi kapcsolattartó rendelkezésére bocsátani. E körbe tartoznak különösen:

• Képernyőfelvételek (screenshot) a gyanús jelenségekről — különösen hibaüzenetek, profilpanelen vagy térképfelületen észlelt, általa nem végzett módosítások, ismeretlen tevékenységek;
• A böngésző konzolján (DevTools) megjelenő hibaüzenetek, figyelmeztető bejegyzések;
• Phishing-e-mailek, gyanús elektronikus üzenetek, valamint a Supabase Auth által küldött, általa nem kezdeményezett jelszó-visszaállító e-mailek (törlés helyett megőrzendők és továbbítandók);
• A Rendszer belső rendszerüzenetei, amelyek incidensgyanúra utalnak;
• Az észlelt, általa nem végzett fájlműveletek vagy tárhelyen megjelenő változások rövid leírása a bejelentésben (Felhasználó és Szerkesztő szerepkör esetén a tevékenységi naplóhoz nincs hozzáférés);
• A tevékenységi napló (GET /files/app_data/file_log.json) teljes, letöltött példánya — kizárólag Rendszergazda számára, a profilpanel → Beállítások → Műveletek ellenőrzése felületen; a napló kizárólag az R2-ben tárolt .fgb és .pmtiles fájlok feltöltését, törlését és átnevezését rögzíti és a letöltött állományt az incidensvizsgálat idejére változtatás nélkül meg kell őrizni;
• Minden egyéb, az incidens dokumentálásához hasznos technikai adat.

Az incidenssel összefüggő bármely adat, fájl, napló vagy bizonyíték törlése — a Rendszergazda / adatvédelmi kapcsolattartó kifejezett hozzájárulása nélkül — tilos, még akkor is, ha az érintett fájl más okból amúgy törölhető lenne. A bizonyítékok megsemmisítése az incidenskezelési eljárás akadályozásának minősül, és súlyosabb következményeket von maga után.

---

14. Az incidenskezelési eljárásrend felhasználói szintű ismerete

14.1 A belső incidenskezelési folyamat áttekintése — a 0-tól 72 óráig terjedő időszak

E fejezet célja, hogy a felhasználó átfogó képet kapjon az Adatkezelő belső incidenskezelési eljárásrendjéről. A felhasználónak nem feladata az eljárásrend végrehajtása — ez az adatvédelmi kapcsolattartó és a Rendszergazda felelőssége —, azonban a folyamat ismerete segíti a felhasználót abban, hogy a saját feladatait (bejelentés, együttműködés, bizonyítékmegőrzés, titoktartás) megfelelően lássa el.

A teljes incidenskezelési folyamat négy egymást követő fázisból áll:

14.1.1 Azonnali észlelés és bejelentés — 0–4 óra

Ez a fázis az incidens észlelésével kezdődik és a kezdeti elhárító intézkedések megindításával zárul. A felhasználó ebben a fázisban a legaktívabb szerepet tölti be.

A fázis főbb lépései:

1. Észlelés: A felhasználó — vagy az Adatkezelő rendszerei — azonosítanak egy lehetséges incidensnek minősülő eseményt.
2. Belső bejelentés (felhasználói feladat): A felhasználó az észleléstől számított 2 órán belül bejelenti az eseményt a Rendszergazdának és az adatvédelmi kapcsolattartónak (ld. 13.4 pont).
3. Elsődleges értékelés: A Rendszergazda és az adatvédelmi kapcsolattartó megvizsgálja, hogy az esemény valóban incidensnek minősül-e (ld. 13.3 pont).
4. Azonnali elhárítás: Ha az incidens megerősítést nyer, megindulnak az azonnali műszaki elhárító intézkedések — pl. érintett felhasználói fiókok zárolása, JWT tokenek érvénytelenítése, érintett fájlok hozzáférésének felfüggesztése.
5. Az incidens dokumentálása: A Rendszergazda megkezdi az Adatkezelő Incidensregiszterének kitöltését.

A felhasználó konkrét feladatai ebben a fázisban:

• Haladéktalan belső bejelentés elvégzése (ld. 13.4.2 pont);
• Bizonyítékok megőrzése (ld. 13.4.3 pont);
• A Rendszergazda és az adatvédelmi kapcsolattartó kéréseire való azonnali reagálás;
• Tartózkodás az incidenssel összefüggő adatok törlésétől vagy megváltoztatásától.

14.1.2 Kivizsgálás és kockázatértékelés — 4–24 óra

E fázisban az adatvédelmi kapcsolattartó és a Rendszergazda elvégzi az incidens részletes kivizsgálását és kockázatminősítését. A felhasználó ebben a fázisban elsősorban együttműködési szerepet tölt be.

A fázis főbb lépései:

1. Az incidens terjedelmének meghatározása: Milyen személyes adatok érintettek? Hány érintett személyt érint az incidens? Mennyi ideig állt fenn a jogosulatlan hozzáférés vagy az adatvesztés?
2. Az incidens típusának és forrásának azonosítása: Bizalmassági, integritási vagy rendelkezésre állási incidens? Mi volt az incidens kiváltó oka (emberi hiba, külső támadás, rendszerhiba)?
3. Kockázatminősítés: Az incidens valószínűsíthetően kockázatot jelent-e az érintett természetes személyek jogaira és szabadságaira? Az incidens magas kockázatúnak minősül-e, amely érintetti értesítési kötelezettséget alapoz meg?
4. A szükséges intézkedések meghatározása: Milyen további műszaki, szervezési vagy jogi intézkedések szükségesek?

A felhasználó konkrét feladatai ebben a fázisban:

• A Rendszergazda és az adatvédelmi kapcsolattartó által feltett kérdésekre valóságos, hiánytalan és késlekedés nélküli válaszadás;
• Esetlegesen szükséges további bizonyítékok előkeresése és átadása;
• Tartózkodás az incidenssel összefüggő, a vizsgálatot akadályozó intézkedések megtételétől.

14.1.3 Hatósági bejelentés — 24–72 óra

Ha az incidens kockázatminősítése alapján a NAIH felé bejelentési kötelezettség áll fenn, az adatvédelmi kapcsolattartó a GDPR 33. cikke alapján az incidens Adatkezelő általi tudomásra jutásától számított 72 órán belül megteszi a szükséges hatósági bejelentést.

A NAIH felé teljesítendő bejelentés minimálisan tartalmazza:

• Az incidens jellegét, ideértve az érintett személyes adatok kategóriáit és hozzávetőleges számát, valamint az érintett adatrekordok hozzávetőleges számát;
• Az adatvédelmi kapcsolattartó nevét és elérhetőségeit;
• Az incidens valószínűsíthető következményeinek leírását;
• Az Adatkezelő által az incidens orvoslása érdekében tett vagy tervezett intézkedések leírását.

A felhasználó feladatai ebben a fázisban:

• Passzív, de rendelkezésre álló szerep: a Rendszergazda és az adatvédelmi kapcsolattartó bármely időpontban fordulhat a felhasználóhoz pontosítások céljából;
• Titoktartási kötelezettség teljesítése (ld. 14.5 pont).

14.1.4 Érintetti értesítés és helyreállítás

Ha az incidens magas kockázatúnak minősül (GDPR 34. cikk szerinti magas kockázat), az Adatkezelő az érintett természetes személyeket indokolatlan késedelem nélkül értesíti az incidensről. Az értesítés az adatvédelmi kapcsolattartó koordinálásával történik.

Az értesítés tartalma (GDPR 34. cikk (2) bekezdés alapján):

• Az incidens jellege;
• Az adatvédelmi kapcsolattartó neve és elérhetőségei;
• Az incidens valószínűsíthető következményei;
• Az Adatkezelő által tett vagy tervezett intézkedések;
• Az érintetteknek szóló tanácsok a lehetséges hátrányos következmények mérséklése érdekében.

A helyreállítási fázis magában foglalja a sérült adatok visszaállítását (amennyiben lehetséges), a technikai biztonsági rések megszüntetését, a folyamatok felülvizsgálatát és a tanulságok dokumentálását, amelyek alapul szolgálnak a Szabályzat soron kívüli felülvizsgálatához (ld. 19.2.3 pont).

---

14.2 Az adatvédelmi kapcsolattartó és a Rendszergazda szerepe incidenseknél

14.2.1 Az adatvédelmi kapcsolattartó szerepe

Az adatvédelmi kapcsolattartó (ld. 1.5 pont) az Adatkezelő által kijelölt, az adatvédelmi jog területén kellő szakértelemmel rendelkező belső személy. Az incidenskezelés kontextusában az adatvédelmi kapcsolattartó feladatai az alábbiak:

• Az incidens jogi minősítése és kockázatminősítésének elvégzése;
• A NAIH felé fennálló hatósági bejelentési kötelezettség teljesítésének koordinálása;
• Az érintetti értesítési kötelezettség fennállásának meghatározása és végrehajtásának koordinálása;
• Az Incidensregiszter és az incidenssel összefüggő dokumentáció kezelése;
• Az ügyvezető tájékoztatása az incidens jogi és adatvédelmi következményeiről;
• Tanácsadói szerep az Adatkezelő számára az incidenskezelés minden fázisában.

14.2.2 A Rendszergazda szerepe

A Rendszergazda az incidenskezelés műszaki végrehajtásáért felelős. Az incidenssel összefüggő Rendszergazdai feladatok:

• Az incidens műszaki kivizsgálása (Cloudflare Workers naplók, Supabase hitelesítési naplók, tevékenységi napló elemzése);
• Azonnali műszaki elhárítás: fiókzárolás, JWT-tokenek érvénytelenítése, hozzáférési jogok felfüggesztése, szükség esetén a Rendszer egyes funkcióinak ideiglenes letiltása;
• Az adatfeldolgozók (Supabase, Cloudflare) ügyfélszolgálatával való kapcsolattartás, ha az incidens adatfeldolgozói oldalon keletkezett;
• Az adatvédelmi kapcsolattartói feladatkör szempontjából a műszaki vizsgálat eredményeinek dokumentálása (azonos személy esetén belső dokumentálásként);
• A műszaki helyreállítás koordinálása a kockázatminősítés alapján meghatározott intézkedésekkel összhangban.

Az adatvédelmi kapcsolattartó és a Rendszergazda szerepe jelenleg egy személyben teljesül. Az adatvédelmi kapcsolattartó és a Rendszergazda elérhetősége:
Svercsok Nándor
nandor.svercsok@gmail.com
+36 30 646 7033

---

14.3 Az ügyvezető tájékoztatásának kötelezettsége

Az adatvédelmi kapcsolattartó és a Rendszergazda köteles az ügyvezetőt minden olyan incidensről haladéktalanul tájékoztatni, amely:

• Magas kockázatúnak minősül (valószínűsíthetően súlyos következményekkel jár az érintettekre nézve);
• NAIH-bejelentési kötelezettséget alapoz meg;
• Érintetti értesítési kötelezettséget von maga után;
• A Rendszer teljes vagy részleges leállásával jár;
• Rendszergazdai fiók feltörését érinti;
• Adatfeldolgozói oldali incidens keretében keletkezett, amelynek következményeit az Adatkezelő közvetlenül nem tudja befolyásolni;
• Sajtónyilvánosságot, hatósági vizsgálatot vagy bírósági eljárást vonhat maga után.

Az ügyvezető tájékoztatása az adatvédelmi kapcsolattartó feladata; a felhasználó az ügyvezetőt közvetlenül csak akkor értesíti, ha az adatvédelmi kapcsolattartó és a Rendszergazda egyidejűleg elérhetetlen, és az incidens természete azonnali vezetői döntést igényel (pl. a Rendszer azonnali leállításának szükségessége, amelyről a Rendszergazda nem tud dönteni).

---

14.4 Az érintett felhasználók kötelezettségei incidens esetén

Minden felhasználó — függetlenül attól, hogy maga az incidens bejelentője-e vagy sem, illetőleg hogy közvetlenül érintett-e az incidensben — az incidens észlelésétől az incidenskezelés lezárásáig az alábbi kötelezettségeket köteles teljesíteni:

14.4.1 Együttműködési kötelezettség

A felhasználó köteles az incidenskezelési folyamat valamennyi fázisában teljes körűen együttműködni az adatvédelmi kapcsolattartóval és a Rendszergazdával. Az együttműködési kötelezettség magában foglalja:

• A Rendszergazda és az adatvédelmi kapcsolattartó kérdéseire valóságos, hiánytalan és késlekedés nélküli válaszadást;
• A rendelkezésre álló bizonyítékok és adatok haladéktalan átadását;
• A Rendszergazda műszaki intézkedéseinek (pl. jelszócsere, kijelentkezési kötelezettség, fiók ideiglenes zárolása) elfogadását és az azoknak való haladéktalan eleget tételt;
• Elérhetőség biztosítását az incidenskezelés időtartama alatt, különösen az első 72 órában.

14.4.2 Tartózkodási kötelezettségek

A felhasználó az incidenskezelés időtartama alatt köteles tartózkodni az alábbi tevékenységektől:

• Az incidenssel összefüggésbe hozható adatok, fájlok, üzenetek vagy naplóbejegyzések törlésétől vagy megváltoztatásától;
• Az incidensről való — a titoktartási kötelezettségbe (ld. 14.5 pont) ütköző — tájékoztatástól illetéktelen személyek felé;
• Az incidenskezelési eljárást zavaró, akadályozó vagy lassító magatartástól;
• Az érintett rendszerkomponensek vagy hozzáférési útvonalak önkényes megváltoztatásától (pl. jelszócsere a Rendszergazda tájékoztatása nélkül, ha erre épp vizsgálat folyik).

14.4.3 Jelszócsere kötelezettsége

Ha a Rendszergazda az incidens kezelése során a felhasználót jelszavának megváltoztatására utasítja — különösen az I-01 (jelszó kompromittálódása), I-02 (JWT token jogosulatlan megszerzése) vagy I-03 (jogosulatlan fiókba lépés) kategóriájú incidenseknél —, a felhasználó köteles ezt haladéktalanul, a Rendszergazda által meghatározott határidőn belül elvégezni. Az új jelszónak maradéktalanul meg kell felelnie a 10. fejezetben rögzített jelszóerősségi követelményeknek; az incidens előtt használt jelszó újra nem választható.

---

14.5 Titoktartási kötelezettség az incidenskezelés során

14.5.1 A titoktartási kötelezettség tartalma és terjedelme

Az adatvédelmi incidensek kezelése során tudomásra jutott minden információ — ideértve az incidens tényét, jellegét, terjedelmét, az érintett adatokat és személyeket, a vizsgálat menetét, az Adatkezelő által tett intézkedéseket, illetőleg a hatósági bejelentés tényét és tartalmát — szigorúan bizalmas. A felhasználó az incidensről és az incidenskezelésről kizárólag az alábbi személyeknek adhat tájékoztatást:

• Az adatvédelmi kapcsolattartónak;
• A Rendszergazdának;
• Az ügyvezetőnek (ha ezt az adatvédelmi kapcsolattartó vagy a Rendszergazda kifejezetten kéri, vagy ha a 14.3 pont szerinti közvetlen értesítési kötelezettség fennáll);
• Az Adatkezelő által bevont jogi tanácsadónak vagy külső szakértőnek (ha ezzel az adatvédelmi kapcsolattartó a felhasználót megbízza).

14.5.2 Titoktartási tilalmak — kinek NEM szabad tájékoztatást adni

A felhasználó az incidensről nem adhat tájékoztatást:

• Más felhasználóknak, akiket az adatvédelmi kapcsolattartó az incidenskezelési folyamatba nem vont be;
• Külső személyeknek (pl. ügyfeleknek, partnereknek, ismerősöknek, sajtónak), beleértve a közösségi médiában való nyilvánosságra hozatalt;
• Az Adatkezelő szervezetén kívüli munkatársaknak — még akkor sem, ha azok az Adatkezelővel szoros kapcsolatban állnak;
• Bármely egyéb, az adatvédelmi kapcsolattartó által erre nem felhatalmazott személynek.

14.5.3 A titoktartási kötelezettség célja

A titoktartási kötelezettség célja kettős: egyrészt megakadályozza, hogy az incidenssel kapcsolatos információk nyilvánosságra kerülése az érintett személyek további hátrányát, a nyomozás akadályozását, vagy az Adatkezelő megalapozatlan reputációs kárát okozza; másrészt biztosítja, hogy az incidens részleteinek szabályozatlan terjedése ne nehezítse a hatósági és jogi eljárások lefolytatását.

A titoktartási kötelezettség az incidenskezelés lezárása után is fennmarad, kivéve, ha az adatvédelmi kapcsolattartó — az Adatkezelő döntése alapján — annak feloldásáról kifejezetten rendelkezik.

14.5.4 A titoktartási kötelezettség megsértésének következményei

A titoktartási kötelezettség megsértése a 18. fejezetben meghatározott munkajogi következményeket vonja maga után, és — különösen abban az esetben, ha a kötelezettség megsértése az érintetteknek vagy az Adatkezelőnek kárt okoz — polgári jogi kártérítési igényt, illetőleg súlyos esetben büntetőjogi felelősséget is megalapozhat. A titoktartási kötelezettség megsértése mint súlyos kötelezettségszegés azonnali hozzáférés-megvonást is maga után vonhat (ld. 18.4 pont).

---

V. RÉSZ – ÉRINTETTI JOGOK ÉS ADATVÉDELMI GARANCIÁK

---

15. Az érintetti jogok gyakorlása a Rendszeren belül

15.1 Önkiszolgáló adathozzáférési és -módosítási lehetőségek

A Rendszer a felhasználók számára önkiszolgáló módon — azaz a Rendszergazda vagy az adatvédelmi kapcsolattartó közreműködése nélkül — is lehetővé teszi bizonyos személyes adatok megtekintését és módosítását. Az önkiszolgáló funkciók célja a GDPR 5. cikk (1) bekezdés a) pontjában rögzített átláthatóság elvének és a GDPR 12. cikke által előírt hozzáférhetőség követelményének közvetlen, technikai úton való érvényesítése.

15.1.1 Saját profiladatok megtekintése és módosítása

A felhasználó a profilpanelen bármikor megtekintheti a saját fiókjában tárolt, az alábbi táblázatban foglalt adatokat, és — a jelzett körben — önkiszolgálóan módosíthatja azokat:

A vezetéknév és keresztnév módosítása a profilpanel → Fiók adatok felületén, a Mentés gomb megnyomásával valósul meg, és mentéskor azonnal érvénybe lép (közvetlen Supabase profiles frissítés). E-mail-cím-módosítás ugyanezen felületen kezdeményezhető; ekkor a Worker POST /update-email API-végpontja frissíti a Supabase Auth rekordot és a profiles táblát, majd a Rendszer kijelentkezteti a felhasználót. Névváltoztatás esetén a Worker a tevékenységi naplóban a korábbi, az érintett felhasználóhoz köthető fájlművelet-bejegyzések uploaded_by, deleted_by és renamed_by mezőit frissíti (POST /update-log-user-name); a profiladat-módosítás tényéről külön naplóbejegyzés nem készül. E-mail-cím- és profilkép-módosítás a tevékenységi naplóban nem kerül rögzítésre.

15.1.2 Jelszóváltoztatás

A felhasználó a Rendszer beállítási felületén — bejelentkezett állapotban — bármikor megváltoztathatja a jelszavát. A jelszóváltoztatás folyamata:

1. A felhasználó megadja az aktuálisan érvényes jelszavát (újrahitelesítési lépés);
2. A felhasználó megadja az új jelszót és annak megerősítését;
3. A Rendszer ellenőrzi az új jelszó megfelelőségét (ld. 10. fejezet jelszóerősségi követelményei);
4. Sikeres ellenőrzés esetén az új jelszó érvénybe lép, és a Supabase Auth frissíti a hitelesítési rekordot.

Az újrahitelesítési lépés célja annak megakadályozása, hogy felügyelet nélkül hagyott, bejelentkezett munkamenet esetén illetéktelen személy a felhasználó jelszavát megváltoztassa. A jelszóváltoztatás az összes aktív munkamenetre vonatkozóan érvényes; a többi aktív munkamenet érvényességéről a Rendszer implementációja rendelkezik (jelszócsere automatikusan érvénytelenítheti a többi aktív JWT tokent).

A jelszóváltoztatás kötelező eseteit a Szabályzat 10.3 pontja tartalmazza.

15.1.3 Profilkép kezelése

A profilkép feltöltése, cseréje és törlése a felhasználó önkiszolgáló jogkörébe tartozik. A profilkép kezelésének részletes szabályait a Szabályzat 6.3.1 pontja tartalmazza; jelen pont kizárólag az érintetti jog szempontjából összegzi a legfontosabb tudnivalókat:

• Feltöltés és csere: A felhasználó a profilpanel → Profilkép módosítás felületen bármikor feltölthet új profilképet fájlból (JPEG, PNG, GIF, WebP) vagy a kamerás képkészítés funkcióval. A kép a Supabase Storage avatars tárolójában kerül elhelyezésre (avatars/{userId}/{timestamp}.{ext}); a nyilvános elérési URL a profiles.avatar_url mezőben tárolódik. Csere esetén a korábbi fájl(ok) törlésre kerülnek, majd az új kép feltöltődik.
• Törlés: A felhasználó a profilpanelen bármikor törölheti a profilképét; a profiles.avatar_url mező nullára áll, és az avatars/{userId}/ mappában lévő fájlok eltávolításra kerülnek a Supabase Storage-ból. A törlés nem visszafordítható; utána kezdőbetűs helyőrző jelenik meg.
• Hozzájárulás visszavonása: A profilkép feltöltése és tárolása hozzájáruláson alapuló adatkezelés. A hozzájárulás visszavonásának módját a 15.4.1 pont tartalmazza (a törlés a visszavonás gyakorlása).

---

15.2 Rendszergazdához benyújtandó kérelmek

Egyes érintetti jogok — amelyek a Rendszer adatkezelési architektúrájából fakadóan nem valósíthatók meg önkiszolgáló módon — a Rendszergazdához benyújtott kérelemmel gyakorolhatók. A Rendszergazdához benyújtott kérelmet írásban (e-mailben) kell megtenni, és arra a Rendszergazda a kézhezvételtől számított 5 munkanapon belül köteles érdemi választ adni, illetőleg a kért intézkedést megtenni.

15.2.1 Szerepkör-módosítás iránti kérelem

A felhasználó kérelemmel fordulhat a Rendszergazdához a saját szerepkörének módosítása érdekében (pl. Felhasználó szerepkörű munkatárs Szerkesztői jogosultság iránti kérelme). A Rendszergazda a szerepkör-módosítást kizárólag az Adatkezelő — jellemzően az ügyvezető — jóváhagyásával hajtja végre. Puszta felhasználói kérelem alapján, az Adatkezelő jóváhagyása nélkül szerepkör nem módosítható.

A kérelemnek tartalmaznia kell:

• a kérelmező felhasználó nevét és e-mail-címét;
• a jelenlegi szerepkört;
• a kért új szerepkört;
• a módosítás indokát (munkafeladat megjelölése, amelyhez a magasabb jogosultság szükséges);
• az Adatkezelő (ügyvezető) előzetes jóváhagyásának tényét vagy annak kérését.

15.2.2 Törlési kérelem — a fiók megszüntetése

A felhasználó kérelemmel fordulhat a Rendszergazdához a saját felhasználói fiókjának megszüntetése érdekében. Ez a GDPR 17. cikke szerinti törléshez való jog (az „elfeledtetés joga") gyakorlásának egyik lehetséges útja, amennyiben a törlési kérelmet az érintett közvetlenül a Rendszergazdának nyújtja be.

A Rendszergazda a fiók törlésére irányuló kérelmet — ha annak teljesítésével szemben az Adatkezelőnek jogos érdeke, vagy jogszabályi kötelezettségből fakadó adatmegőrzési kötelezettsége nem áll fenn — az 5 munkanapos határidőn belül teljesíti. A törlés hatálya és a törlést megelőzően megtartható adatok körét a Szabályzat 9.2.4 pontja tartalmazza.

Ha a törlési kérelem teljesítésével szemben az Adatkezelőnek kifogása van (pl. folyamatban lévő munkajogi eljárás, jogszabályi adatmegőrzési kötelezettség), a Rendszergazda erről a kérelmezőt írásban értesíti, és az ügyet az adatvédelmi kapcsolattartóhoz utalja.

15.2.3 E-mail-cím módosítása más felhasználó számára

Minden felhasználó a saját e-mail-címét önkiszolgálóan módosíthatja a profilpanel → Fiók adatok felületen (ld. 15.1.1 pont). Amennyiben más felhasználó e-mail-címének módosítása szükséges — például helyesbítési kérelem teljesítésekor, vagy ha az érintett technikai okból nem tudja önállóan elvégezni a módosítást — a kérelmet írásban (e-mailben) a Rendszergazdához kell benyújtani.

A Rendszergazda a módosítást elsősorban a POST /update-email Worker API-végponton keresztül hajtja végre (a kérésben megadott userId és newEmail paraméterekkel); ez a Supabase Auth rekordot és a profiles táblát is frissíti. Kivételes, a normál működésen kívüli belső adminisztrációs beavatkozás esetén a módosítás a Supabase adminisztrációs felületén (Auth) is elvégezhető; ilyenkor a Rendszergazda gondoskodik arról, hogy a profiles tábla e-mail mezője is szinkronban maradjon. Más felhasználó e-mail-címét kizárólag Rendszergazda módosíthatja; sikeres módosítás után az érintett felhasználónak az új e-mail-címmel kell bejelentkeznie. Saját e-mail-cím módosításakor a Rendszer a mentés után kijelentkezteti a felhasználót; más felhasználó adatának módosításakor az érintettet a Rendszergazda külön értesíti.

---

15.3 Adatvédelmi kapcsolattartóhoz benyújtható kérelmek

Az érintetti jogok egy része — jellegéből fakadóan — az adatvédelmi kapcsolattartóhoz benyújtott kérelemmel gyakorolható. Az adatvédelmi kapcsolattartó köteles a kérelmet a GDPR 12. cikke értelmében egy hónapon belül megválaszolni. Különösen összetett vagy nagyszámú kérelmet érintő esetben ez a határidő legfeljebb további két hónappal meghosszabbítható, amelyről az adatvédelmi kapcsolattartó a kérelmezőt a kézhezvételtől számított egy hónapon belül tájékoztatja.

A kérelmet az adatvédelmi kapcsolattartó elérhetőségein (nandor.svercsok@gmail.com) kell benyújtani, és azt az érintett azonosítását lehetővé tevő adatokkal (teljes név, e-mail-cím) kell ellátni.

15.3.1 Hozzáférési jog — GDPR 15. cikk

A GDPR 15. cikke alapján a felhasználónak joga van arra, hogy az adatvédelmi kapcsolattartótól visszajelzést kapjon arra vonatkozóan, hogy személyes adatainak kezelése folyamatban van-e, és ha igen, jogosult arra, hogy a személyes adatokhoz és az alábbi információkhoz hozzáférést kapjon:

• az adatkezelés céljai;
• az érintett személyes adatok kategóriái;
• azon címzettek vagy címzetti kategóriák, akikkel, illetve amelyekkel a személyes adatokat közölték vagy közölni fogják;
• a személyes adatok tárolásának tervezett időtartama;
• a helyesbítés, törlés, adatkezelés korlátozása iránti joggal és a tiltakozási joggal kapcsolatos tájékoztatás;
• a NAIH-hoz való panasztétel joga;
• az adatok forrása (ha nem az érintettől gyűjtötték);
• automatizált döntéshozatal és profilalkotás alkalmazásának ténye és logikája (ha releváns).

A Rendszerben kezelt adatokra alkalmazva: Az adatvédelmi kapcsolattartó a hozzáférési kérelemre adott válaszban tájékoztatást nyújt a kérelmező profiladatairól, a tevékenységi naplóban rögzített, kérelmezőhöz köthető bejegyzések köréről, a tárolt fájlokról, a munkamenet-adatokról és az adatmegőrzési időkről, a Rendszer Adatvédelmi Tájékoztatójában foglaltakkal összhangban.

15.3.2 Helyesbítéshez való jog — GDPR 16. cikk

A GDPR 16. cikke alapján a felhasználónak joga van arra, hogy kérésére az adatvédelmi kapcsolattartó indokolatlan késedelem nélkül helyesbítse a rá vonatkozó, pontatlan személyes adatokat, illetőleg — figyelembe véve az adatkezelés célját — kérje a hiányos személyes adatok kiegészítését.

A Rendszerben alkalmazva: A vezetéknévhez, keresztnévhez, e-mail-címhez vagy egyéb profiladathoz kapcsolódó helyesbítési kérelem az adatvédelmi kapcsolattartóhoz nyújtható be, aki azt a Rendszergazda közreműködésével hajtja végre (mindkét szerepkört ugyanaz a személy látja el). A vezetéknevét, keresztnevét és saját e-mail-címét minden felhasználó önkiszolgálóan módosíthatja (ld. 15.1.1 pont). Ha az érintett technikai okból nem tudja önállóan elvégezni a módosítást, vagy más felhasználó adatának helyesbítéséről van szó, a helyesbítés a Rendszergazdához benyújtott kérelem (ld. 15.2.3 pont) vagy az adatvédelmi kapcsolattartóhoz címzett helyesbítési kérelem útján kezdeményezhető.

15.3.3 Az adatkezelés korlátozásához való jog — GDPR 18. cikk

A GDPR 18. cikke értelmében a felhasználó jogosult arra, hogy kérésére az adatvédelmi kapcsolattartó korlátozza az adatkezelést, ha az alábbi feltételek valamelyike teljesül:

• a felhasználó vitatja a személyes adatok pontosságát — arra az időtartamra, amely lehetővé teszi az adatok pontosságának ellenőrzését;
• az adatkezelés jogellenes, de a felhasználó ellenzi az adatok törlését, és ehelyett azok felhasználásának korlátozását kéri;
• az Adatkezelőnek már nincs szüksége a személyes adatokra az adatkezelés céljából, de a felhasználónak jogi igények előterjesztéséhez, érvényesítéséhez vagy védelméhez szüksége van rájuk;
• a felhasználó tiltakozott az adatkezelés ellen, és folyamatban van annak megállapítása, hogy az Adatkezelő jogos indokai elsőbbséget élveznek-e a felhasználó jogos indokaival szemben.

A Rendszerben alkalmazva: Az adatkezelés korlátozása a Rendszer kontextusában jellemzően a tevékenységi naplóban tárolt adatok, a profiladatok vagy a fájlokhoz kapcsolódó metaadatok további aktív felhasználásának felfüggesztését jelenti. A korlátozás időtartama alatt az érintett adatok nem törölhetők, és az adatkezelés egyéb formái sem folytathatók.

15.3.4 Adathordozhatósághoz való jog — GDPR 20. cikk

A GDPR 20. cikke alapján a felhasználónak joga van arra, hogy a rá vonatkozó, az Adatkezelő rendelkezésére bocsátott személyes adatokat tagolt, széles körben használt, géppel olvasható formátumban megkapja, és ezeket az adatokat egy másik adatkezelőnek továbbítsa.

Az adathordozhatósági jog kizárólag az alábbi feltételek együttes teljesülése esetén áll fenn:

• az adatkezelés hozzájáruláson vagy szerződésen alapul;
• az adatkezelés automatizált módon történik.

A Rendszerből exportálható adatok köre:

Geodata-fájlok és az adathordozhatósági jog: Az R2-ben tárolt geodata-fájlok (.fgb, .pmtiles) belső, megosztott szakmai (műszaki) állományok; nem felhasználónként elkülönítve tárolódnak. A Rendszer felhasználói felületén ezek letöltése (exportálása) nem lehetséges — kizárólag térképes megjelenítés céljából, hitelesített GET /files/{fájlnév} API-hívásokon (byte-range kérések) keresztül érhetők el (ld. 6.4.2, 7.1.1). A GDPR 20. cikke értelmében az adathordozhatósághoz való jog jellemzően nem terjed ki ezekre az állományokra, mivel azok nem minősülnek az érintett által a Rendszerbe bocsátott személyes adatoknak, hanem az Adatkezelő belső munkavégzését szolgáló, szervezeti szinten kezelt geoadatok. Ha egy geodata-fájl tartalma az érintettre vonatkozó személyes adatot foglal magában (ld. 6.4.2), az a hozzáférési jog (GDPR 15. cikk) keretében, egyedi kérelem alapján kerül megítélésre; az adathordozhatóság csak akkor jöhet szóba, ha a 20. cikk valamennyi feltétele együttesen teljesül, és az átadás mások jogait nem sérti (GDPR 20. cikk (4) bekezdés).

A kérelem teljesítése az adatvédelmi kapcsolattartó és a Rendszergazda együttműködésével, az egy hónapos GDPR-határidőn belül történik.

15.3.5 Tiltakozáshoz való jog — GDPR 21. cikk

A GDPR 21. cikke alapján a felhasználónak joga van arra, hogy a saját helyzetével kapcsolatos okokból bármikor tiltakozzon a személyes adatainak az Adatkezelő jogos érdekén (GDPR 6. cikk (1) bekezdés f) pont) alapuló kezelése ellen.

A Rendszerben alkalmazva: A tevékenységi (audit) napló az Adatkezelő jogos érdeke alapján kerül kezelésre (rendszerbiztonság, visszaélések megelőzése, incidenskezelés). A felhasználó tiltakozhat a tevékenységi naplóban a saját felhasználói azonosítójához köthető adatok megőrzése ellen. Az Adatkezelő a tiltakozás esetén mérlegeli, hogy jogos érdeke elsőbbséget élvez-e a felhasználó jogos érdekeivel, jogaival és szabadságaival szemben, illetőleg hogy az adatkezelés jogi igények előterjesztéséhez, érvényesítéséhez vagy védelméhez szükséges-e.

Megjegyzendő, hogy a tevékenységi napló egy részének megőrzése olyan jogszabályi kötelezettséghez is kapcsolódhat (pl. biztonsági esemény bizonyítása NAIH-eljárásban), amely esetén a tiltakozáshoz való jog korlátozott lehet.

---

15.4 A hozzájárulás visszavonásának joga és módjai

A GDPR 7. cikk (3) bekezdése értelmében az érintett jogosult arra, hogy hozzájárulását bármikor visszavonja. A hozzájárulás visszavonása nem érinti a visszavonás előtt a hozzájárulás alapján végrehajtott adatkezelés jogszerűségét. A hozzájárulás visszavonása ugyanolyan egyszerű, mint annak megadása — a Rendszer ezt önkiszolgáló módon teszi lehetővé.

15.4.1 A profilkép hozzájárulásának visszavonása

A profilkép feltöltése és tárolása kizárólag a felhasználó önkéntes, előzetes hozzájárulásán alapul. A hozzájárulás visszavonása a profilkép törlésével valósul meg:

• A visszavonás módja: A felhasználó a profilpanel → Profilkép módosítás felületen törli a profilképét. A törlés egyúttal a hozzájárulás visszavonásának minősül.
• A visszavonás következménye: A profiles.avatar_url mező nullára áll, és az avatars/{userId}/ mappában lévő fájlok eltávolításra kerülnek a Supabase Storage-ból. A törlés nem visszafordítható. A profilkép a törlést követően a Rendszer felületein sem jelenik meg; helyette kezdőbetűs helyőrző jelenik meg.
• A visszavonás nem érinti a törlés előtt elvégzett, profilképhez kapcsolódó adatkezelési műveletek jogszerűségét.

Ha a felhasználó a jövőben ismét szeretne profilképet megjeleníteni, új feltöltéssel és az azzal járó hozzájárulással élhet.

15.4.2 A GPS-helymeghatározás hozzájárulásának visszavonása

A GPS-koordináta-adatok Rendszerben való felhasználása kizárólag a felhasználó önkéntes, böngészőszintű engedélyén alapul. A hozzájárulás visszavonása két szinten lehetséges:

a) Böngészőszintű visszavonás (azonnali hatályú): A felhasználó a böngésző helymeghatározás-engedélyeit kezelő felületén bármikor visszavonhatja a georto.com domain részére megadott helymeghatározási engedélyt. E visszavonás hatályba lépésével a Rendszer nem kap többé hozzáférést a GPS-koordinátákhoz; a helymeghatározás funkció a Rendszer felületén elérhetetlenné válik.

b) Rendszeren belüli visszavonás: A felhasználó a térképes felületen a helymeghatározás gomb ismételt megnyomásával kikapcsolhatja a funkciót (navigator.geolocation.clearWatch). A koordináták kizárólag a böngészőben és a térképfelületen kerülnek feldolgozásra; szerverre vagy adatbázisba nem kerülnek.

A visszavonás következményei:

• A visszavonást követően a Rendszer nem kap újabb GPS-koordináta-adatot.
• A böngészőben ideiglenesen feldolgozott koordináta-adatok a funkció kikapcsolásakor vagy a lap bezárásakor megszűnnek; tartós tárolásuk nem történik.
• A visszavonás nem akadályozza a helymeghatározási funkciótól független rendszerfunkciók igénybevételét.

---

15.5 Jogorvoslati lehetőségek — NAIH és bírósági út

15.5.1 Panasz benyújtása a Nemzeti Adatvédelmi és Információszabadság Hatósághoz

Ha a felhasználó úgy ítéli meg, hogy a személyes adatainak kezelése sérti a GDPR rendelkezéseit, jogosult panaszt benyújtani a Nemzeti Adatvédelmi és Információszabadság Hatósághoz (NAIH):

A NAIH-hoz benyújtott panasz nem érinti a felhasználó bírósági jogorvoslathoz való jogát. A panasz benyújtása előtt célszerű az adatvédelmi kapcsolattartóhoz fordulni, és az ügyet belső úton kísérli meg rendezni — ez azonban nem kötelező feltétele a NAIH-eljárás megindításának.

15.5.2 Bírósági jogorvoslat

A GDPR 79. cikke alapján a felhasználónak joga van hatékony bírósági jogorvoslathoz, ha úgy ítéli meg, hogy személyes adatainak a GDPR-nak nem megfelelő kezelése következtében megsértették a rendelet alapján őt megillető jogokat. A per — a felhasználó választása szerint — az Adatkezelő tevékenységi helye szerinti tagállam bírósága, illetőleg a felhasználó szokásos tartózkodási helye szerinti tagállam bírósága előtt indítható meg. Magyarország vonatkozásában az illetékes bíróság a törvényszék.

15.5.3 Az előzetes belső jogorvoslat ajánlása

Az Adatkezelő az érintetti jogok érvényesítésére az alábbi sorrendű belső eljárást ajánlja, amely a legtöbb esetben gyorsabb és kevésbé terhes megoldást nyújt, mint a hatósági vagy bírósági út:

1. Önkiszolgáló megoldás: Amennyiben az érintetti jog a Rendszer felületén belül, Rendszergazda közreműködése nélkül is érvényesíthető (ld. 15.1 pont), a felhasználó ezt az utat alkalmazza először.
2. Rendszergazdához benyújtott kérelem (ld. 15.2 pont): Amennyiben az önkiszolgáló megoldás nem elegendő.
3. Adatvédelmi kapcsolattartóhoz benyújtott kérelem (ld. 15.3 pont): Amennyiben a kérelem jogi minősítést, mérlegelést igényel, vagy az érintetti jog az előző utakon nem érvényesíthető.
4. NAIH-panasz vagy bírósági eljárás (ld. 15.5.1–15.5.2 pont): Amennyiben a belső jogorvoslat nem vezetett eredményre, vagy a felhasználó azt más okból nem tartja megfelelőnek.

---

16. Adatfeldolgozókra vonatkozó tájékoztatás felhasználói szemmel

16.1 A fejezet célja és az adatfeldolgozói jogviszony általános kerete

E fejezet a felhasználókat tájékoztatja arról, hogy a Georto Vision Rendszer működtetése során az Adatkezelő mely harmadik fél szolgáltatókat vesz igénybe, azok milyen adatkezelési tevékenységet végeznek, és a felhasználó e körülmény ismeretében milyen elvárásokat támaszthat a Rendszer adatkezelési biztonságával szemben.

A GDPR 28. cikke értelmében adatfeldolgozó az a természetes vagy jogi személy, közhatalmi szerv, ügynökség vagy bármely egyéb szerv, amely az Adatkezelő nevében személyes adatokat kezel. Az adatfeldolgozó az adatokat kizárólag az Adatkezelő utasításai szerint kezelheti; saját célra nem használhatja fel azokat.

Az Adatkezelő valamennyi adatfeldolgozóval írásban rögzített adatfeldolgozói megállapodást köt, amely biztosítja a GDPR 28. cikk (3) bekezdésében előírt kötelező tartalmi elemek meglétét.

---

16.2 Supabase, Inc. — hitelesítés, adatbázis és fájltárhely

16.2.1 Az adatfeldolgozói szerepkör és az igénybe vett szolgáltatások

Az adatfeldolgozó alapadatai:

A Supabase a Rendszer számára az alábbi szolgáltatásokat nyújtja, amelyek keretében személyes adatok kerülnek feldolgozásra:

• Supabase Auth: A felhasználói hitelesítés (regisztráció, bejelentkezés, jelszókezelés, JWT tokenek kiállítása és érvénytelenítése) teljes körű kezelése. A Supabase Auth tárolja az e-mail-cím + bcrypt hashelt jelszó párosítást, a refresh tokeneket, a fiók létrehozásának időpontját és az utolsó sikeres bejelentkezés időpontját.
• Supabase Database (PostgreSQL): A messages, profiles, user_consents és user_messages táblák tárolása, amelyekben a felhasználók személyes adatai (vezetéknév, keresztnév, szerepkör, e-mail-cím, profilkép URL, Szabályzat-elfogadások, rendszerüzenet-olvasottság stb.) kerülnek kezelésre.
• Supabase Storage: A profilképek tárolása a Supabase Storage avatars nevű bucketjében (avatars/{userId}/{timestamp}.{ext}).

16.2.2 Az adatfeldolgozói kapcsolat adatvédelmi garanciái

• A Supabase az Európai Unió területéről érkező adatokat elsősorban az EU-n belüli szervereken tárolja (AWS Frankfurt adatközpont), bár a Supabase globális platformként működik, és egyes metaadatok az USA-ban is tárolódhatnak.
• A Supabase SOC 2 Type II tanúsítvánnyal rendelkezik, és GDPR-kompatibilis adatfeldolgozói feltételeket (Data Processing Agreement) biztosít az ügyfelei számára.
• Az adatbázisban alkalmazott Row Level Security (RLS) szabályok (ld. 12.5 pont) az Adatkezelő által konfigurált, adatbázis-szintű hozzáférés-vezérlési mechanizmusok, amelyek biztosítják, hogy a Supabase platform-szintű hozzáférése ellenére a felhasználói adatok csak az arra jogosultak számára legyenek elérhetők.

16.2.3 Felhasználói szempontból releváns tudnivalók

• A Rendszerbe bejelentkező felhasználó hitelesítési adatai a Supabase Auth szervereire kerülnek továbbításra; ez a Rendszer normál működéséből fakadó, elkerülhetetlen technikai adattovábbítás.
• A Supabase platformján bekövetkező adatvédelmi incidens esetén az Adatkezelőt tájékoztatási kötelezettség terheli a GDPR 28. cikk (3) bekezdés f) pontja alapján; ilyen esetben az I-09 vagy I-14 kategóriájú incidenskezelési eljárás indul (ld. 13.2.3 és 13.2.6 pont).

---

16.3 Cloudflare, Inc. — API-backend, R2 tárhely és KV tár

16.3.1 Az adatfeldolgozói szerepkör és az igénybe vett szolgáltatások

Az adatfeldolgozó alapadatai:

A Cloudflare a Rendszer számára az alábbi szolgáltatásokat nyújtja:

• Cloudflare Workers: A Rendszer teljes API-backendjeként működik; minden, a böngészőből érkező kérés a Cloudflare Workers platformon fut le. A Workers feldolgozza a hitelesítési kérelmeket, a RBAC-ellenőrzéseket, a fájlkezelési műveleteket és az összes egyéb API-végpontra irányuló kérést. Ebből fakadóan a Workers-en keresztül átmeneti jelleggel személyes adatok — JWT tokenek tartalma, kérési paraméterek, API-válaszok — is feldolgozásra kerülnek.
• Cloudflare R2 (objektumtárhely): Geodata-fájlok (.fgb, .pmtiles — ld. 7.1.1), felhasználónkénti térképkonfigurációk (app_data/maps_{userId}.json) és tevékenységi napló (app_data/file_log_{timestamp}.json) tartós tárolása a georto-vision-r2 objektumtárban. Az R2-ben tárolt adatok kizárólag a Cloudflare Worker API-n keresztül, érvényes JWT-token és megfelelő szerepköri jogosultság megléte esetén érhetők el (GET /files/…, GET /maps stb.); közvetlen, nyilvános R2-hozzáférés konfigurálva nincsen.
• Cloudflare KV (kulcs-érték tár): A LIMITER névtér kizárólag az IP-alapú kérésszám-korlátozáshoz szükséges, 60 másodperces lejáratú (rate-limit:{ip} kulcsformátum) számlálók ideiglenes tárolására szolgál; A KV rekordok a TTL lejártával automatikusan törlődnek (ld. 9.4.2 és 12.3 pont).

16.3.2 Az adatfeldolgozói kapcsolat adatvédelmi garanciái

• A Cloudflare az Adatkezelő EU-s ügyfelei számára GDPR-kompatibilis adatfeldolgozói feltételeket (Data Processing Addendum) biztosít, amelyek értelmében az adatokat az Adatkezelő utasításai szerint kezeli.
• A Cloudflare Workers az „edge computing" elvén működik: a kérések feldolgozása a felhasználóhoz legközelebb eső Cloudflare adatközpontban történik, ami azt jelenti, hogy a kérések az EU-n belüli adatközpontokban is feldolgozásra kerülhetnek. A tartós tárolás (R2, KV) elsődleges helyszínét az Adatkezelő konfigurációja határozza meg.
• A Cloudflare az SSL/TLS titkosítással biztosítja az adatok átviteli biztonságát, és az R2-ben tárolt adatokat alapértelmezés szerint inaktív állapotban is titkosítva tárolja.
• A Cloudflare a Workers naplózási (logging) funkcióján keresztül átmeneti jelleggel rögzítheti a kérési metaadatokat (IP-cím, kérési fejlécek, időbélyeg); ezek a naplók korlátozott ideig érhetők el, és az Adatkezelő a Cloudflare dashboard felületén tekintheti meg azokat.

16.3.3 Felhasználói szempontból releváns tudnivalók

• A Cloudflare R2-be feltöltött fájlok kizárólag a Cloudflare Worker API-n keresztül, érvényes JWT-tokennel érhetők el (GET /files/…, GET /maps stb.); közvetlen, nyilvános R2-URL-en való elérés alapértelmezés szerint nem lehetséges.
• A Cloudflare Workers rate limiting funkciója a 12.3 pontban leírtak szerint percenként 1000 kérés korlátot alkalmaz; e korlát szándékos meghaladásának tilalmát a Szabályzat 5.2.4 és 12.3.3 pontja tartalmazza.
• A Cloudflare platformján bekövetkező adatvédelmi incidens esetén az I-10, I-11 vagy I-12 kategóriájú incidenskezelési eljárás indul (ld. 13.2.3, 13.2.4 és 13.2.6 pont).

---

16.4 OpenStreetMap — alaptérkép-csempék (önálló adatkezelő)

16.4.1 Az OpenStreetMap különleges jogállása

Az OpenStreetMap (OSM) a Rendszer térképi alaprétegének forrása: a Rendszer a térképfelületen az OpenStreetMap tile (csempe) szerverek által biztosított alaptérkép-csempéket jeleníti meg. Az OpenStreetMap — szemben a Supabase-szel és a Cloudflare-rel — nem adatfeldolgozói jogviszonyban áll az Adatkezelővel, hanem önálló adatkezelőként nyújtja a térképcsempe-szolgáltatást.

16.4.2 Adatkezelési és adatvédelmi következmények

Amikor a felhasználó a Rendszer térképfelületét betölti, a böngésző közvetlenül az OpenStreetMap tile-szervereihez kapcsolódik a csempék letöltése érdekében. E kapcsolódás során az OpenStreetMap szerverei a böngésző IP-címét és a kért csempe koordinátáit rögzíthetik. E körülményekre az OpenStreetMap saját adatvédelmi tájékoztatója irányadó (openstreetmap.org/privacy), amely felett az Adatkezelőnek nincs befolyása.

Az Adatkezelő felelőssége az OpenStreetMap-csempék betöltéséhez kapcsolódó adatkezelésre nem terjed ki; a felhasználó az OSM tile-szervereinek igénybevételével közvetlen adatkezelési kapcsolatba lép az OpenStreetMap Foundationnel.

16.4.3 Anonimizálási lehetőség

Az OpenStreetMap tile-szerverekre irányuló kérések csempekoordinátákat tartalmaznak, amelyek önmagukban személyes adatnak nem minősülnek, azonban az IP-cím és a csempe azonosítója kombinálva közvetett helymeghatározásra alkalmas lehet. Amennyiben a felhasználónak ez aggodalomra ad okot, tájékoztatásképpen megjegyzendő, hogy a Cloudflare CDN-infrastruktúra (ha az Adatkezelő azt az OSM-csempék proxyzálására is alkalmazza) az ilyen IP-alapú nyomon követés kockázatát csökkentheti.

---

16.5 CDN-könyvtárszolgáltatók — nem adatfeldolgozói státusz

A Rendszer egyes nyílt forráskódú JavaScript- és CSS-könyvtárakat CDN (Content Delivery Network) szolgáltatókon keresztül tölt be (pl. jsDelivr, cdnjs, unpkg). E szolgáltatók:

• Nem adatfeldolgozók: Az Adatkezelő nem kötött velük adatfeldolgozói megállapodást, és nem továbbít nekik személyes adatokat; a CDN-könyvtárak statikus erőforrásokat (JavaScript-fájlok, betűkészletek, stíluslapok) biztosítanak, és ezek betöltése során az érintett CDN-szolgáltató kizárólag a böngésző IP-címét és a kért erőforrás URL-jét látja.
• Önálló adatkezelők a saját naplózásuk vonatkozásában: A CDN-szolgáltatók a saját adatvédelmi tájékoztatójuk alapján kezelik a kérési naplóikat; ez az Adatkezelő felelőssége körébe nem tartozik.
• Minimális adatvédelmi kockázat: A statikus erőforrások betöltéséhez kapcsolódó, CDN felé irányuló adatátvitel az Adatkezelő által kezelt személyes adatokat nem tartalmaz; a kockázat mértéke elhanyagolható.

Az Adatkezelő törekszik arra, hogy hosszú távon a CDN-könyvtárakat a saját infrastruktúráján (pl. Cloudflare R2-ben) tárolja, csökkentve ezzel a harmadik fél CDN-szolgáltatókra való külső függőséget.

---

16.6 Külső FTP-szerverek — az Adatkezelő felelősségének korlátai

16.6.1 A külső FTP-szerverek jogállása

A Rendszer FTP-importálási funkciója lehetővé teszi, hogy a Rendszergazda és Szerkesztő szerepkörű felhasználók külső FTP-szerverekről (amelyek nem az Adatkezelő infrastruktúrájához tartoznak) geodata-fájlokat töltsenek be közvetlenül a Rendszerbe. E külső FTP-szerverek:

• Nem az Adatkezelő adatfeldolgozói, és nem állnak az Adatkezelő irányítása alatt;
• Az Adatkezelővel adatfeldolgozói megállapodás nincs érvényben közöttük;
• Az FTP-szerveren tárolt adatok kezelésének felelőssége és adatvédelmi megfelelősége kizárólag az FTP-szerver üzemeltetőjét terheli.

16.6.2 Az Adatkezelő felelősségének korlátai FTP-import esetén

Az FTP-importálás során az Adatkezelő felelőssége az alábbiak szerint korlátozott:

• Az Adatkezelő felelős azért, hogy az FTP-ről importált és a Rendszerbe (Cloudflare R2-be) kerülő adatok kezelése a jelen Szabályzatban és az Adatvédelmi Tájékoztatóban foglaltaknak megfelelően történjen.
• Az Adatkezelő nem felelős az FTP-szerveren tárolt adatok sérülékenységéért, az FTP-szerver üzemeltetőjének adatvédelmi gyakorlatáért, illetőleg az FTP-kapcsolat során a szerveren bekövetkező eseményekért.
• A titkosítatlan FTP-kapcsolat kockázatairól a felhasználót a Szabályzat 7.4.1 pontja figyelmezteti; az ebből fakadó esetleges adatszivárgásért az Adatkezelő nem vállal felelősséget, amennyiben a felhasználó a figyelmeztetés ellenére titkosítatlan FTP-protokollt alkalmazott.

16.6.3 A felhasználó kötelezettségei FTP-import esetén

FTP-importálás megkezdése előtt a felhasználó köteles:

• Meggyőződni arról, hogy az érintett FTP-szerveren tárolt adatok megismerésére jogosult;
• Lehetőség szerint FTPS vagy SFTP protokollt alkalmazni titkosítatlan FTP helyett (ld. 7.4.2 pont);
• Felmérni, hogy az FTP-szerverről importálandó fájlok tartalmaznak-e személyes adatot, és ha igen, meggyőződni arról, hogy az adat Rendszerbe való bevitelét az Adatkezelő adatkezelési jogalapja fedezi;
• Az FTP-hitelesítési adatokat (felhasználónév, jelszó) bizalmasan kezelni, azokat a Rendszeren kívül nem tárolni és harmadik féllel nem megosztani.

---

VI. RÉSZ – KÉPZÉS, TUDATOSSÁG ÉS SZANKCIÓK

---

17. Képzési és tudatosságnövelési kötelezettségek

17.1 A képzési kötelezettség általános kerete és célja

A GDPR 5. cikk (2) bekezdésében rögzített elszámoltathatóság elvéből és a GDPR 32. cikke szerinti szervezeti biztonságintézkedési kötelezettségből fakadóan az Adatkezelő köteles gondoskodni arról, hogy a Georto Vision Rendszer valamennyi felhasználója rendelkezzen az alábbi ismeretekkel:

• a Rendszerben kezelt személyes adatok köre és az alkalmazandó adatvédelmi elvek;
• a felhasználó szerepköréhez igazodó jogosultságok és kötelezettségek;
• a biztonsági előírások és a helyes jelszó- és munkamenet-kezelési gyakorlat;
• az adatvédelmi incidensek azonosítása, bejelentése és az incidenskezelési eljárásrend ismerete;
• az érintetti jogok és azok gyakorlásának módjai.

A képzési és tudatosságnövelési kötelezettség célja, hogy az adatvédelmi és biztonsági ismeretek ne csupán papíron meglévő szabályok legyenek, hanem a napi munka szerves részévé váljanak. Az Adatkezelő tudatában van annak, hogy a személyes adatok biztonságát fenyegető kockázatok jelentős hányada emberi tényezőkre — gondatlanságra, tájékozatlanságra vagy rossz döntésre — vezethető vissza; a képzési program célja e kockázatok tudatos csökkentése.

---

17.2 Kötelező belső képzés új felhasználók számára — beléptetési folyamat tájékoztatás

17.2.1 A beléptetési folyamat tájékoztatás tartalma és formája

Minden új felhasználó a Rendszerhez való hozzáférés megadása előtt, illetőleg legkésőbb az első bejelentkezés alkalmával köteles elvégezni az Adatkezelő által szervezett belső beléptetési folyamat tájékoztatást. E tájékoztatás elvégzése az első belépés feltétele — a Rendszergazda kizárólag ezt követően aktiválja a felhasználói fiókot, vagy a tájékoztatás elvégzéséig a fiók korlátozott üzemmódban marad.

A beléptetési folyamat tájékoztatás az alábbi kötelező tartalmi elemeket foglalja magában:

17.2.2 A beléptetési folyamat tájékoztatás dokumentálása

A beléptetési folyamat tájékoztatás elvégzése és a Szabályzat megismerésének tényét a felhasználó az 1. melléklet szerinti Felhasználói hozzáférési kérelem és beléptetési folyamat-ellenőrzőlista aláírásával dokumentálja. Az aláírt checklist az adatvédelmi kapcsolattartónál kerül megőrzésre, a GDPR elszámoltathatósági kötelezettségének teljesítése érdekében.

A beléptetési folyamat tájékoztatás elvégzése nélkül teljes körű hozzáférés nem adható; a Rendszergazda az aktiválás előtt köteles meggyőződni arról, hogy a beléptetési folyamat-ellenőrzőlista kitöltve és aláírva az adatvédelmi kapcsolattartóhoz beérkezett.

17.2.3 A tájékoztatás formátuma

A beléptetési folyamat tájékoztatás az alábbi formátumok egyikében tartható meg, az Adatkezelő döntésétől függően:

• Személyes tájékoztatás: A Rendszergazda vagy az adatvédelmi kapcsolattartó személyesen tájékoztatja az új felhasználót, és válaszol a felmerülő kérdésekre. Ez a forma különösen Rendszergazda szerepkörű új munkatárs esetén kötelező.
• Írásbeli önálló tájékoztatás: A felhasználó a Szabályzat (BFSZ) és az Adatvédelmi Tájékoztató egyidejű elolvasásával tesz eleget a tájékoztatási kötelezettségnek. E formátum esetén a felhasználó az olvasás befejezésekor aláírásával igazolja, hogy a dokumentumokat elolvasta és azok tartalmát megértette.
• Hibrid formátum: Az írásbeli önálló tájékoztatást rövid, személyes konzultáció egészíti ki.

---

17.3 Rendszergazdák rendszeres felfrissítő tájékoztatója

17.3.1 A Rendszergazdára vonatkozó fokozott képzési követelmény

A Rendszergazda szerepkör — a 4.2.2 pontban részletezett fokozott felelőssége okán — az általános felhasználói beléptetési folyamat tájékoztatáson túlmenő, rendszeres felfrissítő képzési kötelezettséggel is jár. Ennek keretében a Rendszergazda köteles:

• Évente legalább egyszer részt venni az Adatkezelő által szervezett belső felfrissítő tájékoztatón, amelynek középpontjában az elmúlt időszak incidenseinek, a Rendszer technikai változásainak, az adatfeldolgozói platformok biztonsági közleményeinek, illetőleg az újonnan kiadott NAIH/EDPB iránymutatásoknak az áttekintése áll.
• A Cloudflare és a Supabase platformokon bekövetkező, a Rendszer biztonságát érintő változásokkal (pl. API-változások, biztonsági közlemények, adatvédelmi tájékoztatók módosítása) folyamatosan naprakész ismereteket fenntartani.
• Az általa felügyelt felhasználók körében adatvédelmi tudatosságnövelő kommunikációt folytatni, és szükség esetén jelezni az adatvédelmi kapcsolattartónak, ha a felhasználók körében a Szabályzat nem megfelelő ismerete vagy alkalmazása tapasztalható.

17.3.2 A Rendszergazda felfrissítő tájékoztatójának dokumentálása

A Rendszergazda által elvégzett felfrissítő tájékoztatók tényét és tartalmát az adatvédelmi kapcsolattartó dokumentálja és archiválja. A dokumentálás az elszámoltathatósági kötelezettség (GDPR 5. cikk (2) bekezdés) teljesítésének részét képezi, és hatósági ellenőrzés esetén igazolható kell legyen.

---

17.4 A Szabályzat módosítása esetén esedékes tájékoztatás

17.4.1 A módosításokról való tájékoztatás kötelezettsége

Ha a jelen Szabályzat tartalma az éves felülvizsgálat vagy soron kívüli módosítás keretében megváltozik, az Adatkezelő köteles a hatályos felhasználói kört a módosításokról tájékoztatni. A tájékoztatás módját és csatornáit a Szabályzat 19.3 pontja tartalmazza; jelen pont kizárólag a képzési és befogadási kötelezettségre fókuszál:

• Kisebb módosítások esetén (eljárásrendi pontosítások, elérhetőségi adatok frissítése, adatfeldolgozói adatok változása): A Rendszerbeli értesítés vagy e-mail elegendő; a felhasználóktól külön aláírás nem szükséges, azonban javasolt az értesítés olvasottságának technikai úton való nyomon követése.
• Lényeges módosítások esetén (új tilalmak, kibővített bejelentési kötelezettségek, új adatkezelési célok, szerepköri jogosultságok változása): A felhasználóktól a módosítás tudomásulvételét és elfogadását írásos nyilatkozattal kell rögzíteni, amelynek formátuma az 1. melléklet alapján alakítható ki; a Rendszerben e kötelezettség teljesítésének technikai eszköze a verziófrissítéshez kapcsolódó kötelező elektronikus újraelfogadás a sikeres bejelentkezést követően felugró ablakban (ld. 3.2.3, 20.3.3 pont).
• A Rendszer technikai architektúráját vagy az adatfeldolgozókat érintő lényeges módosítások esetén: Kötelező rövid felfrissítő tájékoztató megtartása, különösen a Rendszergazda számára.

17.4.2 A módosítások hatályba lépése és a képzési kötelezettség teljesítésének határideje

A Szabályzat módosított verziója a tájékoztatástól számított 8 napon belül kötelezővé válik valamennyi felhasználó számára. E határidőn belül a felhasználóknak lehetőségük van a módosításokat megismerni és kérdéseiket az adatvédelmi kapcsolattartóhoz intézni. A 8 napos türelmi időszak elteltével a módosított Szabályzat szerinti kötelezettségek teljes körűen érvényesek, és a nem ismert módosításra hivatkozás a felelősség alól nem mentesít.

---

17.5 Tudatossági szempontok — incidensjelek felismerése és helyes reagálás

E pont célja, hogy a felhasználók számára a napi munkavégzés kontextusában alkalmazható, gyakorlati tudatossági szempontokat fogalmazzon meg. Az alábbi útmutató nem pótol, hanem kiegészít az incidenskezelési 13–14. fejezetben foglalt részletes rendelkezések megértéséhez.

17.5.1 A leggyakoribb incidensjelek és azok felismerése

A felhasználónak fokozott figyelmet kell fordítania az alábbi jelekre, amelyek adatvédelmi incidens lehetséges előjelei lehetnek:

17.5.2 A „ha kétséges, jelentsd be" elve

A felhasználónak nem kell teljes bizonyossággal megállapítania, hogy adatvédelmi incidens történt-e. A kétség esetén mindig be kell jelenteni elve alkalmazandó: ha a felhasználó bizonytalanságban van, hogy egy esemény incidensnek minősül-e, a bejelentés terhét vállalja, ne a hallgatás kockázatát. Az indokolatlannak bizonyuló bejelentés nem von maga után következményt; a bejelentési kötelezettség elmulasztása azonban a 18. fejezetben rögzített szankciókat alapozza meg.

17.5.3 Adatminimalizálás a napi munkában

A felhasználó a napi munkavégzés során törekedjen arra, hogy:

• Kizárólag a munkafeladat elvégzéséhez ténylegesen szükséges adatokat töltse fel a Rendszerbe (ne töltsön fel olyan geodata-fájlokat, amelyek szükségtelen személyes adatokat tartalmaznak);
• A Rendszerben tárolt, feladathoz már nem szükséges fájlokat haladéktalanul törölje (a Szabályzat 9. fejezetének törlési szabályaival összhangban);
• GPS-helymeghatározást kizárólag akkor engedélyezzen, ha a helymeghatározási funkciót ténylegesen igénybe kívánja venni;
• Profilképet kizárólag saját döntése alapján, igény szerint töltsön fel.

---

18. A Szabályzat megsértésének következményei

18.1 A szankcionálási rendszer általános kerete és arányossági elve

A Szabályzat megsértése esetén alkalmazandó következmények az arányosság elvén alapulnak: a szankció súlya arányos a jogsértés jellegével, súlyával, szándékosságával, az okozott kárral, valamint a felhasználó magatartásával a jogsértés felismerése és a kárelhárítás tekintetében. Az Adatkezelő nem alkalmaz automatikus, mérlegelés nélküli szankciókat; minden esetben egyedi vizsgálat előzi meg a következmény meghatározását.

A következmények alkalmazásáról az adatvédelmi kapcsolattartó véleményének kikérése után az ügyvezető dönt. A hozzáférési jogosultság azonnali visszavonása (ld. 18.4 pont) tekintetében a Rendszergazda önállóan is jogosult intézkedni, ha a késedelem aránytalanul nagy kockázatot hordoz — erről azonban az ügyvezetőt és az adatvédelmi kapcsolattartót haladéktalanul tájékoztatja.

A következmények egymástól függetlenül is, illetőleg egymással párhuzamosan is alkalmazhatók: a munkajogi szankció nem zárja ki a polgári jogi kártérítési igényt, és egyik sem előfeltétele az adatvédelmi jogi következménynek.

---

18.2 Munkajogi felelősség

18.2.1 A munkajogi szankcionálás jogalapja és kerete

A Szabályzat a Munka Törvénykönyvéről szóló 2012. évi I. törvény (Mt.) alapján munkaviszonyban álló személyek tekintetében munkaszerződéses kötelezettséget keletkeztet. A felhasználó a Szabályzatot a beléptetési folyamat tájékoztatás keretében megismeri, és az 1. melléklet szerinti checklist aláírásával magára nézve kötelezőnek ismeri el. E kötelezettségvállalás munkajogi szempontból a munkaszerződés részévé válik, illetőleg a munkaszerződéshez kapcsolódó belső szabályzati kötelezettségként kötelező erővel bír.

18.2.2 Munkajogi következmények — a szankciók köre

A Szabályzat megsértése az alábbi munkajogi következményeket vonhatja maga után, a jogsértés súlyától függően:

Az Mt. 78. §-a alapján a munkáltató rendkívüli felmondással élhet, ha a munkavállaló a munkaviszonyból származó lényeges kötelezettségét szándékosan vagy súlyos gondatlansággal jelentős mértékben megszegi. A jelen Szabályzatban foglalt kötelezettségek — különösen a jogosulatlan hozzáférés tilalma, a titoktartási kötelezettség és a bizonyítékmegőrzési kötelezettség — az Mt. 78. §-a értelmében lényeges kötelezettségeknek minősülnek.

18.2.3 A munkajogi eljárás menete

Minden munkajogi szankció alkalmazása előtt az Adatkezelő:

1. Megvizsgálja a jogsértés körülményeit (tényállás-feltárás);
2. Meghallgatja az érintett felhasználót (az Mt. 56. §-a szerinti meghallgatás);
3. Az adatvédelmi kapcsolattartó véleményét kikéri;
4. Az arányosság elvét szem előtt tartva meghatározza az alkalmazandó szankciót.

Az eljárás során az érintett felhasználó jogosult álláspontját kifejteni, bizonyítékokat benyújtani, és jogi képviselőt igénybe venni.

---

18.3 Személyes GDPR-felelősség súlyos szabályszegés esetén

18.3.1 Az érintett természetes személyek közvetlen GDPR-felelőssége

A GDPR a személyes adatok védelmét elsődlegesen az Adatkezelőre és az adatfeldolgozóra telepíti; az adatkezelési jogsértések miatti bírságok és kártérítési kötelezettségek főszabály szerint az Adatkezelőt terhelik. Ugyanakkor a Szabályzat megsértése bizonyos körülmények között a felhasználó személyes jogi felelősségét is megalapozhatja.

18.3.2 A személyes GDPR-felelősség feltételei

A felhasználó személyes GDPR-felelőssége az alábbi esetekben merülhet fel:

a) Súlyos, szándékos jogsértés esetén: Ha a felhasználó szándékosan megkerüli a RBAC-mechanizmust, más felhasználó személyes adatait jogosulatlanul megismeri vagy továbbítja, illetőleg adatokat szándékosan töröl vagy meghamisít — és ezzel harmadik személyeknek kárt okoz —, a GDPR 82. cikke alapján közvetlen polgári jogi kártérítési felelősség terhelheti, amennyiben bizonyítható, hogy a kár kizárólag vagy döntően az ő magatartásának következménye.

b) Hatósági eljárás esetén: A NAIH hatósági vizsgálata során az érintett felhasználó tanúként vagy — súlyos esetben — eljárás alá vont személyként is szerepelhet. Bár a GDPR bírságok elsősorban az Adatkezelőt sújtják, a hatóság a vizsgálat körét kiterjesztheti az egyedi kötelezettségszegés elkövetőjére.

c) Büntetőjogi felelősség esetén: A személyes adatok jogosulatlan megszerzése, megváltoztatása, felhasználása, nyilvánosságra hozatala, illetőleg az adatkezelő rendszerbe való jogosulatlan behatolás a Büntető Törvénykönyvről szóló 2012. évi C. törvény (Btk.) szerinti információs rendszer vagy adat megsértése (Btk. 423. §), illetőleg a személyes adattal visszaélés (Btk. 219. §) tényállásait valósíthatja meg, amelyek szabadságvesztéssel is büntethetők.

18.3.3 Különösen súlyos szabályszegések — kiemelten veszélyes magatartások

Az alábbi magatartások az Adatkezelő megítélése szerint különösen súlyosak, és valamennyi elérhető jogkövetkezményt — munkajogi, polgári jogi és büntetőjogi — párhuzamosan megalapozhatják:

• Más felhasználó fiókjába való szándékos belépés vagy annak megkísérlése;
• Más felhasználó JWT tokenjének jogosulatlan megszerzése és felhasználása;
• A Rendszer adatbázisába irányuló SQL-injekciós vagy egyéb jogosulatlan adathozzáférési kísérlet;
• Az adatvédelmi incidenssel összefüggő bizonyítékok szándékos megsemmisítése;
• A titoktartási kötelezettség szándékos megsértése, különösen ha ez az érintetteknek vagy az Adatkezelőnek kárt okoz;
• A Rendszer erőforrásainak szándékos, DoS-jellegű terhelése.

---

18.4 Az Adatkezelő kárfelelőssége és regressz igénye

18.4.1 Az Adatkezelő külső felelőssége

A GDPR 82. cikke értelmében az Adatkezelő felelős az olyan kárért, amelyet a GDPR megsértésével végzett adatkezelés az érintetteknek okoz. Ha az Adatkezelőt hatósági bírság, bírósági ítélet alapján kártérítési kötelezettség, illetőleg egyéb anyagi hátrány terheli, amelynek bekövetkezéséhez a felhasználó Szabályzatba ütköző magatartása hozzájárult, az Adatkezelő regressz igénnyel élhet a felelős felhasználóval szemben.

18.4.2 A regressz igény feltételei

A regressz igény érvényesítésének feltételei:

1. Az Adatkezelőt ténylegesen kártérítési kötelezettség, bírság vagy egyéb vagyoni hátrány érte;
2. A vagyoni hátrány és a felhasználó magatartása között okozati összefüggés áll fenn;
3. A felhasználó a Szabályzatba ütköző magatartást szándékosan vagy súlyos gondatlansággal követte el;
4. A felhasználó magatartása nem minősíthető az Adatkezelő utasítására vagy hibájára visszavezethető kötelezettségteljesítésnek.

18.4.3 A regressz igény korlátai

Gondatlan — nem szándékos — szabályszegés esetén az Mt. 179. §-a alapján a regressz igény mértéke a felhasználó munkaviszonyban álló személyek esetén főszabály szerint a négyhavi távolléti díj összegéig terjedhet. Szándékos károkozás esetén a teljes kár megtérítése követelhető. A regressz igény érvényesítése a munkajogi szankcióktól független, és azokkal párhuzamosan alkalmazható.

---

18.5 A hozzáférési jogosultság azonnali visszavonásának joga

18.5.1 Az azonnali visszavonás feltételei

Az Adatkezelő — a Rendszergazda útján — jogosult a felhasználó hozzáférési jogosultságát azonnali hatállyal, előzetes értesítés nélkül visszavonni, ha:

• Megalapozottan feltételezhető, hogy a felhasználó fiókja kompromittálódott (I-01–I-05 kategóriájú incidens gyanúja);
• A felhasználó jogosulatlan hozzáférési kísérletet hajt végre, vagy annak gyanúja merül fel;
• A felhasználó a Szabályzat olyan súlyos megsértését valósítja meg, amely azonnali kárelhárítást tesz szükségessé;
• A felhasználó munkaviszonya megszűnt vagy felfüggesztésre került, és ez az Adatkezelő tudomására jutott;
• A felhasználó a hozzáférési adatait elveszítette, kompromittálta, vagy ezekre nézve segítségkérés érkezett az adott felhasználótól;
• Incidenskezelési eljárás során a Rendszergazda vagy az adatvédelmi kapcsolattartó a visszavonást az incidens elhárítása érdekében szükségesnek ítéli.

18.5.2 Az azonnali visszavonás műszaki megvalósítása

A hozzáférési jogosultság visszavonása a Rendszergazda által a Supabase Admin felületen végrehajtott fiókzárolással, illetőleg — ha a tokénjogosultság azonnali érvénytelenítése szükséges — a Supabase Auth szintjén az összes aktív munkamenet érvénytelenítésével valósul meg. A visszavonás hatályba lépésekor:

• A felhasználó nem tud bejelentkezni a Rendszerbe;
• Aktív munkamenetei automatikusan megszűnnek (a következő API-kérés hitelesítési hibával tér vissza);
• A felhasználó által tárolt JWT tokenek érvénytelenek lesznek.

18.5.3 Az azonnali visszavonást követő eljárás

Az azonnali visszavonás nem végleges döntés, hanem biztonsági intézkedés. A visszavonást követően:

1. A Rendszergazda haladéktalanul tájékoztatja az ügyvezetőt és az adatvédelmi kapcsolattartót a visszavonás okáról;
2. Az adatvédelmi kapcsolattartó és az ügyvezető dönt arról, hogy a hozzáférés visszaállítása lehetséges-e, és ha igen, milyen feltételek mellett;
3. Ha a visszavonásra incidensgyanú miatt került sor, és a vizsgálat azt nem igazolja, a hozzáférés visszaállítható;
4. Ha a visszavonásra munkajogi, fegyelmi vagy büntetőeljárás kapcsán kerül sor, a hozzáférés visszaállításáról az eljárás eredményének ismeretében döntenek.

Az érintett felhasználót a visszavonás okáról — amennyiben ez az incidenskezelési eljárást vagy folyamatban lévő vizsgálatot nem veszélyezteti — az Adatkezelő haladéktalanul tájékoztatja.

---

VII. RÉSZ – A SZABÁLYZAT KARBANTARTÁSA

---

19. A Szabályzat felülvizsgálata és karbantartása

19.1 A rendszeres (éves) felülvizsgálat kötelezettsége

19.1.1 A felülvizsgálati kötelezettség jogalapja és célja

A GDPR 5. cikk (2) bekezdésében rögzített elszámoltathatóság elvéből, illetőleg a GDPR 24. cikke szerinti megfelelő technikai és szervezési intézkedések fenntartásának kötelezettségéből fakadóan az Adatkezelő köteles gondoskodni arról, hogy a jelen Szabályzat tartalma időszerű, pontos és a hatályos jogszabályi, technikai és szervezeti körülményekkel összhangban lévő maradjon.

Ennek érdekében az Adatkezelő legalább évente egy alkalommal kötelező felülvizsgálatot végez, amelynek keretében az adatvédelmi kapcsolattartó és a Rendszergazda közösen áttekintik a Szabályzat teljes tartalmát.

19.1.2 Az éves felülvizsgálat időpontja és folyamata

Az éves felülvizsgálat a Szabályzat hatályba lépésének évfordulójától számított 30 napon belül elvégzendő. A felülvizsgálat folyamata:

1. Az adatvédelmi kapcsolattartó összegyűjti az elmúlt egy évben bekövetkezett, a Szabályzat tartalmát potenciálisan érintő eseményeket: incidensek tanulságai, jogszabályváltozások, NAIH/EDPB iránymutatások, adatfeldolgozói változások, szervezeti átalakulások.
2. A Rendszergazda áttekinti a Rendszer technikai architektúrájában és az alkalmazott biztonsági megoldásokban bekövetkezett változásokat, és jelzi, ha a Szabályzat műszaki leírásai pontosítást igényelnek.
3. Közös felülvizsgálati ülés keretében az adatvédelmi kapcsolattartó és a Rendszergazda értékeli, hogy a Szabályzat egyes rendelkezései módosításra szorulnak-e.
4. A módosítási javaslatok rögzítésre kerülnek, és az adatvédelmi kapcsolattartó elkészíti a módosított Szabályzat tervezetét.
5. Az ügyvezető jóváhagyja a módosított Szabályzatot, amely ezt követően kiadásra kerül.
6. A felhasználók értesítése a 19.3 pontban meghatározott csatornákon keresztül megtörténik.

19.1.3 Az éves felülvizsgálat dokumentálása

Az éves felülvizsgálat elvégzéséről — annak eredményétől függetlenül (azaz akkor is, ha módosítás nem szükséges) — felülvizsgálati feljegyzés készül, amelyet az adatvédelmi kapcsolattartó archiválja. A feljegyzés tartalmazza:

• a felülvizsgálat elvégzésének dátumát;
• a felülvizsgálatban részt vevő személyek nevét és beosztását;
• az áttekintett szempontokat és forrásokat;
• a felülvizsgálat eredményét (módosítás szükséges / nem szükséges);
• módosítás esetén a változtatások összefoglalóját és azok indokát.

A felülvizsgálati feljegyzés a GDPR elszámoltathatósági kötelezettségének teljesítését igazoló dokumentumként hatósági ellenőrzés esetén bemutatható.

---

19.2 Soron kívüli felülvizsgálat esetei

A tervezett éves felülvizsgálaton túlmenően az Adatkezelő soron kívüli felülvizsgálatot köteles elvégezni, ha az alábbi — tételesen nevesített — körülmények bármelyike bekövetkezik. A soron kívüli felülvizsgálatot az azt kiváltó eseménytől számított 30 napon belül el kell végezni; sürgős esetben (pl. hatályos jogszabályi kötelezettség azonnali megváltozása) a határidő lerövidíthető.

19.2.1 A Rendszer technikai változása

Soron kívüli felülvizsgálatot igénylő technikai változások különösen:

• Új adatkezelési funkció bevezetése a Rendszerbe (pl. új adat beviteli mező, új naplózási mechanizmus, új exportálási lehetőség);
• Meglévő funkció megszüntetése, amely az adatkezelés körét vagy módját érinti (pl. GPS-funkció eltávolítása, FTP-importálás megszüntetése);
• Az alkalmazott biztonsági mechanizmusok lényeges megváltozása (pl. JWT helyett más hitelesítési megoldás bevezetése, MFA kötelezővé tétele);
• Az adatmegőrzési logika megváltozása (pl. automatikus törlési határidők módosítása);
• Új böngészős tárolási mechanizmus bevezetése vagy a localStorage helyett más megoldásra való áttérés.

Minden tervezett Rendszer-fejlesztés előtt a Rendszergazda köteles az adatvédelmi kapcsolattartót előzetesen tájékoztatni, hogy az adatvédelmi vonzatok felmérhetők és a Szabályzat szükség esetén időben módosítható legyen.

19.2.2 Jogszabályi változás

Soron kívüli felülvizsgálatot igénylő jogszabályi változások különösen:

• A GDPR módosítása vagy az Európai Bíróság olyan ítélete, amely a Rendszer adatkezelési gyakorlatát közvetlenül érinti;
• Az információs önrendelkezési jogról és az információszabadságról szóló 2011. évi CXII. törvény (Infotv.) módosítása;
• A NAIH kötelező határozata, állásfoglalása vagy ajánlása, amely a Rendszer adatkezelési gyakorlatát érinti;
• Az Európai Adatvédelmi Testület (EDPB) irányelveinek, iránymutatásainak vagy véleményeinek megjelenése, amelyek a Rendszerben alkalmazott technológiákra (pl. JWT tokenek, cookie-k, helymeghatározás) vonatkoznak;
• Az Európai Bíróság vagy a Kúria olyan ítélete, amely az Adatkezelő adatkezelési jogalapjait vagy az adatfeldolgozói jogviszonyt közvetlenül érinti.

19.2.3 Incidens bekövetkezése utáni tanulságok alapján

Minden dokumentált adatvédelmi incidens lezárását követően az adatvédelmi kapcsolattartó kötelező jelleggel megvizsgálja, hogy az incidens tanulságai szükségessé teszik-e a Szabályzat módosítását. Soron kívüli felülvizsgálat szükséges különösen, ha:

• Az incidens olyan forgatókönyv szerint következett be, amelyet a Szabályzat nem nevesített, és amelynek felvétele a felhasználói tudatosságot növelné;
• Az incidens rámutatott, hogy a Szabályzat valamely rendelkezése nem egyértelmű, vagy az érintett felhasználók azt tévesen értelmezték;
• Az incidenskezelési eljárásrend valamely eleme nem működött megfelelően, és a Szabályzat módosítása az eljárásrend javítását szolgálná;
• A NAIH hatósági vizsgálat során olyan hiányosságra mutatott rá, amely a Szabályzatban rögzítést igényel.

19.2.4 Adatfeldolgozó változása

Soron kívüli felülvizsgálat szükséges, ha az Adatkezelő:

• Új adatfeldolgozót vesz igénybe, amelynek tevékenysége a Rendszerben kezelt személyes adatokat érinti (pl. a Supabase vagy a Cloudflare helyett más platformra való migráció);
• Meglévő adatfeldolgozójával megszünteti a jogviszonyt;
• Valamely adatfeldolgozó adatvédelmi tájékoztatóját, szerződési feltételeit vagy biztonsági tanúsítványait lényegesen módosítja;
• Az adatfeldolgozó szubfeldolgozót vesz igénybe, amely a személyes adatok tárolásának helyét vagy kezelési módját érinti.

19.2.5 Szervezeti változás

Soron kívüli felülvizsgálat szükséges, ha az Adatkezelő szervezetében olyan változás következik be, amely a Szabályzat személyi hatályát, az érintetti körök meghatározását vagy a felelősi struktúrát érinti. Ilyen különösen:

• Az adatvédelmi kapcsolattartó személyének megváltozása;
• A Rendszergazda személyének megváltozása;
• Új szervezeti egység létrehozása, amelynek tagjai a Rendszerhez hozzáférést kapnak;
• Átszervezés, amelynek eredményeként a Rendszer felhasználói köre lényegesen megváltozik;
• Cégcsoporton belüli strukturális változás, amely az Adatkezelő jogállását érinti.

---

19.3 Módosítások közlésének módja és csatornái

19.3.1 A módosítások közlésének kötelezettsége

Az Adatkezelő köteles minden felhasználót a Szabályzat módosításáról értesíteni, mielőtt a módosítás hatályba lép. Az értesítés a módosítás jellegétől függően az alábbi csatornákon keresztül történhet:

A módosított Szabályzat hatályba lépésének határidejére a 17.4.2 pont rendelkezései irányadók: a módosított verzió a tájékoztatástól számított 8 napon belül kötelezővé válik.

19.3.2 A Rendszerbeli üzenet (system message) mint értesítési csatorna

A Rendszer rendszerüzenet-funkciója lehetővé teszi, hogy az Adatkezelő az összes felhasználónak — vagy meghatározott felhasználói körnek — belső értesítést küldjön a Rendszeren belül. A rendszerüzenet a felhasználó következő bejelentkezésekor jelenik meg (GET /messages), és az olvasottságot a Cloudflare Worker POST /messages/seen API-végpontján keresztül a user_messages táblában rögzíti (ld. 6.5.4 pont).

A Szabályzat módosítására vonatkozó rendszerüzenetek kötelező tartalma:

• a módosítás rövid összefoglalója (mi változott és miért);
• az érintett fejezetek és pontok megjelölése;
• a módosítás hatályba lépésének dátuma;
• hivatkozás a módosított Szabályzat elérési helyére (belső dokumentumtár vagy a Rendszeren kívüli megosztott drive);
• a felhasználótól elvárt teendők (pl. checklist aláírása, felugró ablakban történő újraelfogadás).

A rendszerüzenet tájékoztató jellegű; önmagában nem minősül a módosított Szabályzat jogi elfogadásának. A verziófrissítéshez kapcsolódó kötelező elfogadást a sikeres bejelentkezést követően felugró ablak biztosítja (ld. 3.2.3 pont).

19.3.3 Az e-mailes értesítés tartalma

Az e-mailes értesítés a Rendszerbe regisztrált e-mail-cím alapján kerül kiküldésre, és az alábbi elemeket tartalmazza:

• Tárgy: „[BFSZ] A Belső Felhasználási Szabályzat módosítása – 2026. június 28.”;
• A módosítás összefoglalója;
• A módosított Szabályzat elérési helye;
• A módosítás hatályba lépésének dátuma és a tudomásulvételi határidő.

---

19.4 Verziózás és archiválás rendje

19.4.1 A Szabályzat verziószámozási rendszere

A jelen Szabályzat verziószáma fő.al-verzió formátumban kerül feltüntetésre a dokumentum fejlécében:

Minden kiadott verzió tartalmazza a következő metaadatokat a dokumentum fejlécében:

• Dokumentum azonosítója: BFSZ-GOTC-001
• Hatályos: 2026. június 28-tól
• Verzió: 1.0
• Utolsó felülvizsgálat: 2026. június 28.
• Következő tervezett felülvizsgálat: 2027. június 28.
• Felelős / jóváhagyta: Svercsok Nándor, ügyvezető (egyben adatvédelmi kapcsolattartó)

A Szabályzat verziószámának emelése esetén a Rendszer a felhasználó következő sikeres bejelentkezésekor ellenőrzi, hogy az érintett az aktuális, hatályos verziót elfogadta-e; szükség esetén felugró ablakban kéri az újraelfogadást (ld. 3.2.3, 20.3.3 pont). Ha az érintett hosszabb ideig nem használja a Rendszert, és ezen időszak alatt több verzióváltás is történik, kizárólag a legutolsó, jelenleg hatályos verzió elfogadása kötelező.

19.4.2 Az archiválás rendje

Az adatvédelmi kapcsolattartó köteles a Szabályzat valamennyi korábbi verzióját archiválni és az archívumot legalább 5 évig megőrizni. Az archiválás célja:

• hatósági ellenőrzés esetén annak igazolása, hogy a Szabályzat adott időpontban milyen tartalommal bírt;
• polgári jogi eljárásban annak bizonyítása, hogy a felhasználó adott időpontban milyen kötelezettségek teljesítésére volt köteles;
• a Szabályzat fejlődésének nyomon követése és az elszámoltathatóság dokumentálása.

Az archívum a korábbi verziók teljes szövegét, a kiadás dátumát, a verzióváltás indokát és az azt jóváhagyó személy nevét tartalmazza.

---

19.5 Irányadó jogszabályok összefoglalója

A jelen Szabályzat elkészítése és alkalmazása során az alábbi jogszabályok, rendeletek és iránymutatások irányadók:

Az Adatkezelő az éves felülvizsgálat keretében köteles ellenőrizni, hogy a felsorolt jogforrásokban bekövetkezett-e olyan változás, amely a Szabályzat módosítását teszi szükségessé.

---

20. Záró rendelkezések

20.1 A Szabályzat összefüggése más belső dokumentumokkal

20.1.1 Dokumentumhierarchia és koherencia

A jelen Szabályzat az Adatkezelő belső adatvédelmi dokumentációs rendszerének szerves részét képezi. A dokumentumok hierarchiája és az egymáshoz való viszonyuk az alábbiak szerint alakul:

20.1.2 Ütközési szabály

Amennyiben a jelen Szabályzat és valamely más belső dokumentum között látszólagos ellentmondás merül fel, a következő sorrendű értelmezési elvet kell alkalmazni:

1. A GDPR és az Infotv. kötelező rendelkezései minden belső dokumentumon felül állnak, és azokkal ellentétes belső rendelkezés nem alkalmazható.
2. A jelen Szabályzat adatvédelmi és biztonsági rendelkezései a munkaszerződések és más belső szabályzatok felett álló, kötelező normákat alkotnak a Rendszer használatára vonatkozóan.
3. Tényleges ellentmondás észlelése esetén az érintett felhasználó köteles az adatvédelmi kapcsolattartóhoz fordulni; addig a GDPR-kompatibilis értelmezést kell alkalmazni.

---

20.2 Elválaszthatósági klauzula

Ha a jelen Szabályzat valamely rendelkezése érvénytelen, hatálytalan vagy végrehajthatatlanná válik — különösen jogszabályváltozás vagy hatósági/bírósági döntés következtében —, ez az érintett rendelkezés érvénytelenségét nem terjeszti ki a Szabályzat többi rendelkezésére. A Szabályzat fennmaradó rendelkezései változatlan erővel hatályban maradnak.

Az érvénytelen, hatálytalan vagy végrehajthatatlanná vált rendelkezés helyébe — az éves felülvizsgálaton vagy soron kívüli felülvizsgálaton belül — olyan új rendelkezés lép, amely az érvénytelen rendelkezés eredeti céljához a lehető legközelebb áll, és a hatályos joggal összhangban van. Az adatvédelmi kapcsolattartó a részleges érvénytelenség észlelésekor soron kívüli felülvizsgálatot kezdeményez (ld. 19.2 pont).

---

20.3 Jóváhagyás és aláírás

20.3.1 A Szabályzat hatályba lépése

Jelen Szabályzat az ügyvezető aláírásával lép hatályba, és ettől az időponttól fogva kötelező erővel bír a Rendszer valamennyi, hatálya alá tartozó felhasználójára nézve. A hatályba lépés napján a korábbi, esetlegesen létező, a Rendszer használatára vonatkozó belső irányelvek és szabályzati rendelkezések helyébe lép jelen Szabályzat, amelynek rendelkezései azokat hatályon kívül helyezik.

20.3.2 A Szabályzat megismerésének és elfogadásának rögzítése

A felhasználó az 1. melléklet szerinti Felhasználói hozzáférési kérelem és beléptetési folyamat-ellenőrzőlista aláírásával nyilatkozik arról, hogy:

• a jelen Szabályzatot elolvasta és tartalmát megértette;
• a Szabályzatban foglalt kötelezettségeket magára nézve kötelezőnek ismeri el;
• tudomásul vette, hogy a Szabályzat megsértése a 18. fejezetben meghatározott következményeket vonhatja maga után;
• hozzájárult ahhoz, hogy az Adatkezelő a Rendszer keretein belül a Szabályzatban meghatározott célokból személyes adatait kezelje.

20.3.3 Elektronikus elfogadás és automatikus rögzítés

A fiókaktiválás során, valamint a Szabályzat vagy a kapcsolódó jogi dokumentumok verziófrissítése esetén a Rendszer webes felületén elhelyezett jelölőnégyzetek kipipálásával a felhasználó elektronikus úton elfogadja a jelen Szabályzatot (és — ahogy az adott esemény megkívánja — a kapcsolódó jogi dokumentumokat). Ez az aktus a papíralapú (20.3.2 pont szerinti) nyilatkozattal egyenrangú elfogadást jelent; a Rendszerben a megismerés és elfogadás tényét hiteles, utólag igazolható formában rögzíti.

A Rendszer a jelen Szabályzat és a kapcsolódó jogi dokumentumok elfogadásának tényét és körülményeit az alábbi esetekben rögzíti automatikusan az adatbázisában:

• Fiókaktiválás: a felhasználói fiók létrehozásakor, a fiókaktiváló felületen a „Fiók aktiválása" gomb megnyomásakor (ld. 3.2.2 pont);
• Verziófrissítés: a dokumentumok módosítása esetén, a soron következő sikeres bejelentkezést követően felugró ablakban az „Elfogadom" gomb megnyomásakor (ld. 3.2.3 pont).

A Rendszer minden elfogadási eseményt külön rekordként rögzít az eseménynaplóként működő user_consents táblában. Egy rekord egységesen tartalmazza a három kötelező jogi dokumentum — a jelen Belső Felhasználási Szabályzat (BFSZ), az Adatvédelmi Tájékoztató és a Titoktartási Nyilatkozat (NDA) — elfogadásának adatait. A felhasználó aktuális elfogadási státuszát mindig a legutolsó elfogadási rekord határozza meg. A rögzítés a Cloudflare Worker POST /consents API-végpontján keresztül történik; a korábbi rekordok utólag nem módosíthatók és a Rendszeren keresztül nem törölhetők (kivéve a fióktörlést).

Az elfogadási eseményekhez rendelt időbélyegek magyarországi helyi idő szerint kerülnek rögzítésre. Amennyiben egy újabb elfogadás (verziófrissítés) során valamely dokumentum verziója a korábbi elfogadás óta nem változott, a változatlan dokumentum tekintetében a korábbi elfogadási időbélyeg megmarad az új rekordban is.

Az elektronikus elfogadás az eIDAS rendelet (910/2014/EU) 3. cikk 10. pontja szerinti egyszerű elektronikus aláírásnak minősül, és a Ptk. 6:4. §-a alapján joghatályos egyoldalú kötelezettségvállalásnak tekintendő.

Az elfogadási rekord megőrzési ideje, integritása (eseménynapló, RLS, adatbázis-triggerek, kaszkád törlés, adatbázis-szintű titkosítás) és hozzáférési szabályai tekintetében az Adatvédelmi Tájékoztató 2.11 pontja és a Titoktartási Nyilatkozat 8. fejezete az irányadó; az érdemi részletek utóbbiban találhatók.

20.3.4 Jóváhagyó aláírás

 

Kelt: Bezedek, 2026. június 28.

 

Az Adatkezelő képviseletében / adatvédelmi kapcsolattartó:
_________
Svercsok Nándor
ügyvezető / cégvezető (egyben adatvédelmi kapcsolattartó)
Cadway Szolgáltató Korlátolt Felelősségű Társaság

 

---

---

MELLÉKLETEK

---

1. melléklet – Felhasználói hozzáférési kérelem és beléptetési folyamat-ellenőrzőlista

Dokumentum azonosítója: BFSZ-GOTC-001 / 1. melléklet Verzió: 1.0

---

A) Felhasználói adatok

Mező	Kitöltendő
Teljes név
E-mail cím (a Rendszerbe regisztrált)
Munkakör / beosztás
Szervezeti egység
Kért szerepkör	☐ Felhasználó    ☐ Szerkesztő    ☐ Rendszergazda
Hozzáférés kezdete (tervezett)
Kérelem dátuma

---

B) Beléptetési folyamat-ellenőrzőlista — kötelező tájékoztató elemek

Az alábbi tematikai egységek megismerését a felhasználó az adott sor melletti aláírásával igazolja. A checklist valamennyi sorának kitöltése a hozzáférés aktiválásának előfeltétele.

#	Tematikai egység	Megismerés módja	Felhasználó parafája
1	A Rendszer rendeltetése és a megengedett használat szabályai (BFSZ 5. fejezet)	☐ Személyes tájékoztató   ☐ Önálló olvasás
2	Hozzáférési szabályok — meghívóalapú rendszer, fiók személyes jellege (BFSZ 3. fejezet)	☐ Személyes tájékoztató   ☐ Önálló olvasás
3	Saját szerepkör jogosultságai és korlátai (BFSZ 4. fejezet)	☐ Személyes tájékoztató   ☐ Önálló olvasás
4	Jelszókezelési és munkamenet-biztonsági kötelezettségek (BFSZ 10–11. fejezet)	☐ Személyes tájékoztató   ☐ Önálló olvasás
5	Adatkezelési elvek és a kezelt adatok köre (BFSZ 6. fejezet)	☐ Személyes tájékoztató   ☐ Önálló olvasás
6	Fájlkezelési és geodata-szabályok (BFSZ 7. fejezet)	☐ Személyes tájékoztató   ☐ Önálló olvasás
7	Incidensek felismerése és a 2 órás bejelentési kötelezettség (BFSZ 13. fejezet)	☐ Személyes tájékoztató   ☐ Önálló olvasás
8	Incidenskezelési eljárásrend és titoktartási kötelezettség (BFSZ 14. fejezet)	☐ Személyes tájékoztató   ☐ Önálló olvasás
9	Érintetti jogok és gyakorlásuk módjai (BFSZ 15. fejezet)	☐ Személyes tájékoztató   ☐ Önálló olvasás
10	A Szabályzat megsértésének következményei (BFSZ 18. fejezet)	☐ Személyes tájékoztató   ☐ Önálló olvasás

---

C) Felhasználói nyilatkozat

Alulírott kijelentem, hogy:

1. A Belső Felhasználási Szabályzatot (BFSZ-GOTC-001, 1.0 verzió, 2026. június 28.) teljes egészében elolvastam és tartalmát megértettem.
2. A Szabályzatban foglalt kötelezettségeket magamra nézve kötelezőnek ismerem el.
3. Tudomásul vettem, hogy a Szabályzat megsértése a 18. fejezetben meghatározott munkajogi, polgári jogi és adatvédelmi következményeket vonhat maga után.
4. Hozzájárultam ahhoz, hogy az Adatkezelő a Rendszer keretein belül a Szabályzatban és az Adatvédelmi Tájékoztatóban meghatározott célokból személyes adataimat kezelje.
5. Tudomásul vettem, hogy a Szabályzat módosítása esetén az Adatkezelő értesítést küld, és a módosított Szabályzat megismerése az értesítéstől számított 8 napon belül kötelező.

 

Kelt: ________________, ________________ (dátum)

 

---

Felhasználó aláírása Név: __________________________

---

D) Adatkezelői oldali rögzítés (Rendszergazda tölti ki)

Mező	Kitöltendő
Fiók aktiválásának dátuma
Kiosztott szerepkör
Meghívó kiküldésének dátuma
Beléptetési folyamat tájékoztató formátuma	☐ Személyes    ☐ Írásbeli önálló    ☐ Hibrid
Tájékoztatást elvégezte
Checklist beérkezett az adatvédelmi kapcsolattartóhoz	☐ Igen, dátum: _________

 

---

Rendszergazda aláírása

---

2. melléklet – Szerepköri jogosultságmátrix

Dokumentum azonosítója: BFSZ-GOTC-001 / 2. melléklet Verzió: 1.0

Ez a melléklet összefoglaló táblázatos formában tartalmazza a három felhasználói szerepkör (Rendszergazda, Szerkesztő, Felhasználó) jogosultságait a Rendszer valamennyi funkciójára vonatkozóan. A részletes szabályokat a BFSZ 4. fejezete tartalmazza.

Jelölések: ✅ Engedélyezett  |  ❌ Tiltott  |  ⚠️ Korlátozott (feltétel vagy korlátozás fennáll)

---

A) Hozzáférési és fiókkezelési műveletek

Funkció	Rendszergazda	Szerkesztő	Felhasználó
Bejelentkezés a Rendszerbe	✅	✅	✅
Saját profil megtekintése	✅	✅	✅
Saját vezetéknév, keresztnév módosítása	✅	✅	✅
Saját jelszó megváltoztatása	✅	✅	✅
Saját profilkép feltöltése / cseréje / törlése	✅	✅	✅
Más felhasználó profiljának megtekintése	✅	⚠️ Névmegjelenítéshez szükséges mértékben	⚠️ Névmegjelenítéshez szükséges mértékben
Más felhasználó profiljának módosítása	✅	❌	❌
Meghívó kiküldése új felhasználónak	✅	❌	❌
Felhasználói fiók zárolása / törlése	✅	❌	❌
Szerepkör módosítása	✅	❌	❌
Ideiglenes jelszó generálása más felhasználónak	✅	❌	❌

---

B) Fájlkezelési műveletek

Funkció	Rendszergazda	Szerkesztő	Felhasználó
Saját fájl feltöltése	✅	✅	❌
Más felhasználó fájljának megtekintése	✅	✅	✅
Saját fájl átnevezése / törlése	✅	✅	❌
Más felhasználó fájljának átnevezése	✅	✅	❌
Más felhasználó fájljának törlése	✅	✅	❌
FTP-importálás indítása	✅	✅	❌
Fájl metaadatainak megtekintése	✅	✅	❌

---

C) Térképkonfiguráció-kezelés

Funkció	Rendszergazda	Szerkesztő	Felhasználó
Saját térképkonfiguráció létrehozása	✅	✅	✅
Saját térképkonfiguráció mentése / módosítása	✅	✅	✅
Saját térképkonfiguráció törlése	✅	✅	✅
Más felhasználóval megosztott konfiguráció megtekintése	✅	✅	✅
Megosztás visszavonása	✅	⚠️ Csak saját konfiguráció esetén	⚠️ Csak saját konfiguráció esetén
Más felhasználó konfigurációjának törlése	✅	❌	❌

---

D) Rendszer-adminisztrációs műveletek

Funkció	Rendszergazda	Szerkesztő	Felhasználó
Tevékenységi napló (audit log) megtekintése	✅ Teljes napló	❌	❌
Rendszerüzenet küldése	✅	❌	❌
GPS-koordináta-adatok megtekintése (más felhasználóé)	✅ Admin célra	❌	❌
Cloudflare R2 tárban lévő fájlok közvetlen kezelése	✅	❌	❌
Rate limit státuszának megtekintése	✅	❌	❌
API-naplók megtekintése (Cloudflare dashboard)	✅	❌	❌
Supabase Auth adminisztrációs műveletek	✅	❌	❌

---

E) GPS-helymeghatározás

Funkció	Rendszergazda	Szerkesztő	Felhasználó
GPS-hozzájárulás megadása (saját)	✅	✅	✅
GPS-helymeghatározás igénybevétele	✅	✅	✅
GPS-hozzájárulás visszavonása (saját)	✅	✅	✅
Más felhasználó GPS-adatainak megtekintése	✅ Admin célra	❌	❌

---

3. melléklet – FTP-kapcsolat biztonsági figyelmeztetési adatlap

Dokumentum azonosítója: BFSZ-GOTC-001 / 3. melléklet Verzió: 1.0 Vonatkozó BFSZ-pontok: 7.4, 16.6

---

A) Figyelmeztetés — titkosítatlan FTP-kapcsolat kockázatai

⚠️ FONTOS BIZTONSÁGI FIGYELMEZTETÉS — KÉRJÜK, FIGYELMESEN OLVASSA EL

A Georto Vision Rendszer FTP-importálási funkciójának igénybevétele előtt a felhasználónak az alábbi biztonsági kockázatokkal tisztában kell lennie:

A titkosítatlan FTP-protokoll (FTP, nem FTPS/SFTP) az alábbi biztonsági kockázatokat hordozza:

Kockázat	Leírás	Súlyosság
Hitelesítési adatok lehallgatása	Az FTP felhasználónév és jelszó titkosítás nélkül, nyílt szövegként kerül továbbításra a hálózaton; man-in-the-middle pozícióban lévő támadó azokat megszerezheti	Magas
Adattartalom lehallgatása	Az átvitt fájlok tartalma (beleértve az esetleges személyes adatokat is) titkosítás nélkül olvasható a hálózaton	Magas
FTP-hitelesítési adatok kompromittálódása	A megszerzett FTP-hitelesítési adatok felhasználhatók az FTP-szerver jogosulatlan elérésére, ami az I-07 kategóriájú incidenst valósíthat meg	Magas
Közbeékelődéses (MITM) támadás	Titkosítatlan kapcsolat esetén a továbbított fájlok tartalma az átvitel során módosítható	Közepes–Magas

---

B) Ajánlott biztonságos alternatívák

Protokoll	Titkosítás	Ajánlottság
SFTP (SSH File Transfer Protocol)	SSH-alapú, teljes titkosítás	✅ Erősen ajánlott
FTPS (FTP over SSL/TLS, Explicit)	TLS-alapú titkosítás	✅ Ajánlott
FTPS (Implicit)	TLS-alapú titkosítás, dedikált port	✅ Ajánlott
FTP (titkosítatlan)	Nincs titkosítás	⚠️ Csak akkor alkalmazható, ha biztonságos, zárt hálózaton belüli kapcsolatról van szó, és a kockázatokat a felhasználó tudatosan vállalja

---

C) Felhasználói nyilatkozat FTP-importálás megkezdése előtt

Az alábbiakat kérjük minden FTP-importálás megkezdése előtt ellenőrizni és aláírással igazolni (egyszeri aláírás elegendő, ha a felhasználó rendszeresen, ugyanazon FTP-szerverrel dolgozik; új FTP-szerver esetén új nyilatkozat szükséges):

☐ Meggyőződtem arról, hogy az érintett FTP-szerveren tárolt adatok megismerésére jogosult vagyok.

☐ Felmértem, hogy az importálandó fájlok tartalmaznak-e személyes adatot, és meggyőződtem arról, hogy azok Rendszerbe való bevitelét az Adatkezelő adatkezelési jogalapja fedezi.

☐ Lehetőség szerint SFTP vagy FTPS protokollt alkalmazok. Ha ez nem lehetséges, az alábbiakban megjelölöm az okát:

Indokolás (kötelező, ha titkosítatlan FTP-t alkalmazok): _________________________________________

☐ Tudomásul vettem, hogy titkosítatlan FTP-kapcsolat alkalmazása esetén az esetleges adatszivárgásért az Adatkezelő felelőssége korlátozott (BFSZ 16.6.2 pont).

☐ Az FTP-hitelesítési adatokat bizalmasan kezelem, és azokat a Rendszeren kívül sehol sem tárolom.

 

Kelt: ________________, ________________ (dátum)

---

Felhasználó aláírása — Név: ___________________

---

D) Az érintett FTP-kapcsolat adatai (nyomkövetési célból)

Mező	Kitöltendő
FTP-szerver neve / IP-címe
Alkalmazott protokoll	☐ SFTP    ☐ FTPS (Explicit)    ☐ FTPS (Implicit)    ☐ FTP (titkosítatlan)
Az importált fájlok típusa
Személyes adatot tartalmaz-e?	☐ Igen    ☐ Nem    ☐ Bizonytalan
Importálás dátuma

---

4. melléklet – Incidensbejelentő lap (belső, felhasználói szintű)

Dokumentum azonosítója: BFSZ-GOTC-001 / 4. melléklet Verzió: 1.0 Vonatkozó BFSZ-pontok: 13.4, 14.1.1

ℹ️ Útmutató: Ezt a lapot az incidens észlelésétől számított 2 órán belül kell kitölteni és eljuttatni a Rendszergazdának ÉS az adatvédelmi kapcsolattartónak. Ha a Rendszer nem érhető el, a lapot e-mailben, telefonon vagy személyesen kell benyújtani. Az adatokat legjobb tudása szerint töltse ki — a tökéletesség ne késleltesse a bejelentést.

---

A) A bejelentő adatai

Mező	Kitöltendő
Bejelentő neve
E-mail cím
Szerepkör	☐ Rendszergazda    ☐ Szerkesztő    ☐ Felhasználó
Bejelentés dátuma és időpontja
Incidens észlelésének dátuma és időpontja

---

B) Az incidens leírása

Mező	Kitöltendő
Az esemény rövid leírása (mit észlelt, hol, mikor, milyen körülmények között)
Érintett rendszerkomponens(ek)	☐ Bejelentkezési felület   ☐ Profilkezelés   ☐ Fájlkezelés   ☐ Térképfunkció   ☐ FTP-importálás   ☐ Rendszerbeli üzenetek   ☐ Egyéb: _________
Incidenstípus (feltételezett)	☐ Bizalmassági    ☐ Integritási    ☐ Rendelkezésre állási    ☐ Nem meghatározható
Incidenskategória (ha beazonosítható)	☐ I-01 ☐ I-02 ☐ I-03 ☐ I-04 ☐ I-05 ☐ I-06 ☐ I-07 ☐ I-08 ☐ I-09 ☐ I-10 ☐ I-11 ☐ I-12 ☐ I-13 ☐ I-14 ☐ Nem beazonosítható
Érintett személyek köre (ha ismert)
Érintett adatok köre (ha ismert)

---

C) A bejelentő által eddig megtett lépések

☐ Képernyőfelvételt készítettem (csatolva: ☐ Igen   ☐ Nem)

☐ Az érintett böngészőkonzol-kimenetet rögzítettem (csatolva: ☐ Igen   ☐ Nem)

☐ Gyanús e-mailt / üzenetet megőriztem és csatoltam (csatolva: ☐ Igen   ☐ Nem)

☐ Semmit nem töröltem az incidenssel összefüggő adatokból

☐ Megváltoztattam a jelszavamat (ha az incidens ezt indokolta)

☐ Egyéb: _________________________________________

---

D) Csatolt bizonyítékok listája

#	Bizonyíték megnevezése	Típus	Fájlnév / Leírás
1		☐ Képernyőfelvétel   ☐ E-mail   ☐ Napló   ☐ Egyéb
2		☐ Képernyőfelvétel   ☐ E-mail   ☐ Napló   ☐ Egyéb
3		☐ Képernyőfelvétel   ☐ E-mail   ☐ Napló   ☐ Egyéb

---

E) Nyilatkozat

Nyilatkozom, hogy a fenti adatokat legjobb tudomásom szerint, valósághűen adtam meg, és az incidenssel összefüggő adatokat, bizonyítékokat nem töröltem, illetve azokon nem változtattam.

 

Kelt: ________________, ________________ (dátum)

---

Bejelentő aláírása

---

F) Rendszergazdai átvétel (Rendszergazda tölti ki)

Mező	Kitöltendő
Bejelentés kézhezvételének időpontja
Kézhezvételtől az észlelésig eltelt idő
2 órás határidő betartva?	☐ Igen    ☐ Nem, késedelem oka: _________
Incidens regiszterbe felvéve	☐ Igen, iktatószám: _________
Azonnali intézkedések elrendelve

---

Rendszergazda aláírása

---

5. melléklet – Adatmegőrzési idők összefoglaló táblázata

Dokumentum azonosítója: BFSZ-GOTC-001 / 5. melléklet Verzió: 1.0 Vonatkozó BFSZ-pontok: 6.5, 9.1, 9.4

Ez a melléklet összefoglaló áttekintést nyújt a Georto Vision Rendszerben kezelt személyes adatok megőrzési idejéről a felhasználó szempontjából. A részletes szabályok a Rendszer Adatvédelmi Tájékoztatójában, illetőleg a BFSZ 9. fejezetében találhatók.

---

A) Felhasználói profiladatok

Adatkategória	Tárolási helyszín	Megőrzési idő	Törlés módja
E-mail cím + bcrypt jelszóhash	Supabase Auth (auth.users)	Munkaviszony / hozzáférési jogviszony fennállásáig	Profilpanel → Fiók törlése (DELETE /user/{userId}) vagy Rendszergazda; írásbeli kérelem esetén legkésőbb 30 napon belül (ld. 9.2.4)
Vezetéknév, keresztnév, szerepkör	Supabase DB (profiles tábla)	A fiók aktív fennállásáig	Profilpanel → Fiók törlése (DELETE /user/{userId}) vagy Rendszergazda
Profilkép	Supabase Storage (avatars/{userId}/)	Képcsere, felhasználói törlés vagy fióktörlésig	Felhasználó saját maga törölheti (profilpanel); fióktörléskor automatikusan törlődik
Dokumentum-elfogadások	Supabase DB (user_consents tábla)	Munkaviszony / hozzáférési jogviszony fennállásáig (fiók fennállásáig)	Fióktörléskor automatikusan törlődik (adatbázis-szintű kaszkád törlés; ld. 20.3.3)

---

B) Munkamenet- és hitelesítési adatok

Adatkategória	Tárolási helyszín	Megőrzési idő	Törlés módja
JWT hozzáférési token	Böngésző localStorage	Lejáratig (jellemzően 1 óra)	Lejáratkor automatikusan érvénytelen; kijelentkezéskor eltávolítandó
JWT refresh token	Supabase Auth + böngésző localStorage	Lejáratig (jellemzően 7 nap)	Lejáratkor automatikusan érvénytelen; jelszócsere vagy Rendszergazdai érvénytelenítés hatására azonnali érvénytelenítés
Fiók létrehozásának időpontja	Supabase Auth (auth.users.created_at)	Munkaviszony / hozzáférési jogviszony fennállásáig	Fióktörléskor törlődik (DELETE /user/{userId})
Utolsó bejelentkezés időpontja	Supabase Auth (auth.users.last_sign_in_at)	Munkaviszony / hozzáférési jogviszony fennállásáig	Fióktörléskor törlődik (DELETE /user/{userId})

---

C) Munkafeladat-specifikus adatok

Adatkategória	Tárolási helyszín	Megőrzési idő	Törlés módja
Feltöltött geodata-fájlok (.fgb, .pmtiles)	Cloudflare R2 (georto-vision-r2)	Szakmai szükségességig / felhasználó általi törlésig	Szerkesztő / Rendszergazda törölheti (DELETE /files/{filename}); fióktörléskor nem törlődnek automatikusan
Fájlok metaadatai (méret, feltöltés ideje)	Cloudflare R2 (a feltöltött fájl objektum metaadatai; lekérdezés: POST /files/metadata)	Az érintett fájl R2-ben való fennállásáig	Geodata-fájl törlésekor automatikusan megszűnik
FTP hostnév és felhasználónév	Böngésző localStorage (ftp-saved-host, ftp-saved-user)	Érintett manuális törléséig	Böngésző localStorage törlése (a Rendszerben külön törlés gomb nincs)
FTP jelszó	Cloudflare Worker memória (aktív FTP-kérés idejére)	Nem tárolódik tartósan	Kérés befejeztével automatikusan törlődik (ld. 9.4.4)
Térképkonfigurációk (fájlok listája, láthatósági beállítások, aktív térkép, megosztási jelző)	Cloudflare R2 (app_data/maps_{userId}.json)	Felhasználói törlésig vagy fióktörlésig	Saját térkép törlése a térképpanelen; fióktörléskor (érintett vagy Rendszergazda) a maps_{userId}.json fájl automatikusan törlődik

---

D) Automatikusan keletkező adatok

Adatkategória	Tárolási helyszín	Megőrzési idő	Törlés módja
Tevékenységi (audit) napló	Cloudflare R2 (app_data/file_log_{timestamp}.json; API alias: GET/DELETE /files/app_data/file_log.json)	Max. 1 év (ajánlott; a Rendszer nem érvényesíti automatikusan)	Rendszergazda manuális törlés; fiók-törléskor a felhasználónevet tartalmazó mezők anonimizálása („Törölt felhasználó”)
GPS-koordináta-adatok	Kizárólag az érintett böngészőjében (helyi feldolgozás)	Aktív helymeghatározás ideje alatt; nem kerülnek szerverre	A funkció kikapcsolásakor vagy a lap bezárásakor megszűnnek (ld. 6.3.2 és 9.4.3 pont)
Rendszerüzenetek olvasottsági adatai	Supabase DB (user_messages tábla)	Fióktörlésig	Fióktörléskor automatikusan törlődik (DELETE /user/{userId})
Megosztási adatok (a megosztás ténye, időpontja, a megosztó neve, megosztott térkép azonosítója)	Cloudflare R2 (app_data/maps_{userId}.json) + böngésző sessionStorage (pendingSharedMap, ideiglenes átirányítás)	A megosztás visszavonásáig / fióktörlésig	Megosztás visszavonása a térképpanelen; fióktörléskor a maps_{userId}.json fájl automatikusan törlődik

---

E) Cloudflare Workers által átmenetileg kezelt adatok

Adatkategória	Tárolási helyszín	Megőrzési idő	Megjegyzés
API-kérési naplók (request logs)	Cloudflare Workers naplók	Cloudflare platform szabályzata szerint (jellemzően 7 nap)	Az Adatkezelő Cloudflare dashboard-on tekintheti meg; nem tartós tárolás
Rate limiting számlálók	Cloudflare KV (rate-limit:{ip})	60 másodperc (TTL)	Automatikus lejárat; személyes adat nem tárolódik (csak kérésszámláló)

---

6. melléklet – Érintetti joggyakorlási kérelem sablonja

Dokumentum azonosítója: BFSZ-GOTC-001 / 6. melléklet Verzió: 1.0 Vonatkozó BFSZ-pontok: 15.3, 15.4

ℹ️ Útmutató: Ezt a sablont akkor kell alkalmazni, amikor az érintett a GDPR 15–21. cikke szerinti jogát az adatvédelmi kapcsolattartóhoz benyújtott kérelem útján kívánja érvényesíteni. A kitöltött kérelmet az alábbi e-mail-címre kell megküldeni: nandor.svercsok@gmail.com.

---

Tárgy: Érintetti joggyakorlási kérelem — Georto Vision

Keltezés: ________________

---

A) A kérelmező adatai

Mező	Kitöltendő
Teljes név
E-mail cím (a Rendszerbe regisztrált)
Kapcsolattartási e-mail (ha eltér a fentitől)
Szerepkör a Rendszerben

---

B) A kérelem tárgya

Kérjük, jelölje meg az érvényesíteni kívánt jogot (több is megjelölhető):

☐ Hozzáférési jog (GDPR 15. cikk) — Tájékoztatást kérek a rólam kezelt személyes adatokról és az adatkezelés körülményeiről.

☐ Helyesbítéshez való jog (GDPR 16. cikk) — Az alábbi pontatlan / hiányos adatok helyesbítését / kiegészítését kérem:

_____________________________________________________

☐ Törléshez való jog (GDPR 17. cikk) — Az alábbi adatok törlését kérem:

_____________________________________________________

☐ Az adatkezelés korlátozásához való jog (GDPR 18. cikk) — Az alábbi adatok kezelésének korlátozását kérem az alábbi okból:

_____________________________________________________

☐ Adathordozhatósághoz való jog (GDPR 20. cikk) — Az alábbi adatok géppel olvasható formátumban való kiadását kérem:

_____________________________________________________

☐ Tiltakozáshoz való jog (GDPR 21. cikk) — A következő adatkezelési tevékenység ellen tiltakozom, az alábbi indokból:

_____________________________________________________

☐ Hozzájárulás visszavonása (GDPR 7. cikk (3) bekezdés) — Az alábbi hozzájáruláson alapuló adatkezeléshez való hozzájárulásomat visszavonom:

☐ Profilkép tárolása    ☐ GPS-helymeghatározás    ☐ Egyéb: ________________

---

C) A kérelem indokolása (opcionális, de segíti a gyors ügyintézést)

_____________________________________________________________________________________

---

D) Kézbesítési preferencia

☐ E-mailben, a fent megadott kapcsolattartási e-mail-címre

☐ Személyesen, az Adatkezelő székhelyén (előzetes időpont-egyeztetést követően)

---

E) Aláírás

Nyilatkozom, hogy az általam megadott adatok valósak, és a kérelmet a saját nevemben nyújtom be.

 

Kelt: ________________ (dátum)

---

Kérelmező aláírása / elektronikus azonosítása

---

F) Adatvédelmi kapcsolattartói kitöltés (adatvédelmi kapcsolattartó tölti ki)

Mező	Kitöltendő
Kérelem beérkezésének időpontja
Azonosítás elvégezve	☐ Igen    ☐ Nem (pótlás szükséges)
GDPR 12. cikk szerinti határidő	Beérkezéstől számított 1 hónap: _________
Hosszabbítás szükséges?	☐ Nem    ☐ Igen, legkésőbb: _________ (értesítés elküldve: _________)
Válasz elküldve	☐ Igen, dátum: _________
Kérelem teljesítve / részben teljesítve / elutasítva	☐ Teljesítve    ☐ Részben    ☐ Elutasítva, indok: _________

---

Adatvédelmi kapcsolattartó aláírása

---

7. melléklet – A NAIH elérhetőségei és a jogorvoslati útvonal összefoglalója

Dokumentum azonosítója: BFSZ-GOTC-001 / 7. melléklet Verzió: 1.0 Vonatkozó BFSZ-pontok: 15.5

---

A) A Nemzeti Adatvédelmi és Információszabadság Hatóság (NAIH) elérhetőségei

Mező	Adat
Teljes név	Nemzeti Adatvédelmi és Információszabadság Hatóság
Rövidítés	NAIH
Székhely	1055 Budapest, Falk Miksa utca 9–11.
Postacím	1363 Budapest, Pf. 9.
Telefon	+36 (1) 391-1400
E-mail (ügyfélszolgálat)	ugyfelszolgalat@naih.hu
Weboldal	www.naih.hu
Online panaszbeadás	www.naih.hu/online-ugyinditas
Ügyfélszolgálati nyitvatartás	Hétfő–csütörtök: 9:00–16:00; Péntek: 9:00–14:00

---

B) A NAIH-hoz benyújtható panasz feltételei és tartalma

A GDPR 77. cikke alapján az érintett panaszt nyújthat be a NAIH-hoz, ha úgy ítéli meg, hogy személyes adatainak kezelése megsérti a GDPR rendelkezéseit.

A panasz benyújtásának feltételei:

• Az érintett természetes személy;
• A panasz az érintett személyes adatainak kezelésére vonatkozik;
• Az érintett szokásos tartózkodási helye, munkahelye vagy az állítólagos jogsértés helye Magyarországon van.

A panasz ajánlott tartalma:

1. A panaszos személyes adatai (neve, elérhetősége);
2. Az Adatkezelő azonosító adatai (cégnév, székhely, e-mail);
3. A sérelmezett adatkezelési tevékenység pontos leírása;
4. Az érintett által érvényesíteni kívánt jog és annak megtagadásának körülményei (ha az Adatkezelő a kérelmet elutasította);
5. Az Adatkezelőhöz benyújtott korábbi kérelem másolata és az arra adott válasz (ha van);
6. A panasz benyújtásának dátuma és a panaszos aláírása.

---

C) A jogorvoslati útvonal — ajánlott sorrendiség

┌─────────────────────────────────────────────────────────┐
│  1. lépés: Önkiszolgáló megoldás (BFSZ 15.1)            │
│     → Profiladatok módosítása, jelszócsere, profilkép   │
│       törlése a Rendszer felületén                       │
└───────────────────────────┬─────────────────────────────┘
                            │ Ha nem megoldható
                            ▼
┌─────────────────────────────────────────────────────────┐
│  2. lépés: Rendszergazdához benyújtott kérelem          │
│     (BFSZ 15.2) — 5 munkanapos válaszhatáridő           │
│     → Szerepkör-módosítás, fióktörlési kérelem          │
└───────────────────────────┬─────────────────────────────┘
                            │ Ha nem megoldható / jogi kérdés
                            ▼
┌─────────────────────────────────────────────────────────┐
│  3. lépés: Adatvédelmi kapcsolattartóhoz benyújtott     │
│     kérelem (BFSZ 15.3, 6. melléklet)                   │
│     — 1 hónapos GDPR-válaszhatáridő                     │
│     → GDPR 15–21. cikk szerinti érintetti jogok         │
└───────────────────────────┬─────────────────────────────┘
                            │ Ha az Adatkezelő nem teljesíti / elutasítja
                            ▼
┌─────────────────────────────────────────────────────────┐
│  4/a lépés: NAIH-panasz (BFSZ 15.5.1)                  │
│     → Hatósági vizsgálat és kötelező határozat          │
│     → Párhuzamosan: bírósági út is igénybe vehető       │
└─────────────────────────────────────────────────────────┘
                       VAGY
┌─────────────────────────────────────────────────────────┐
│  4/b lépés: Bírósági jogorvoslat (BFSZ 15.5.2)         │
│     → Törvényszék hatásköre                             │
│     → Párhuzamosan: NAIH-panasz is benyújtható          │
└─────────────────────────────────────────────────────────┘

Fontos: A NAIH-hoz benyújtott panasz és a bírósági eljárás egymástól független, párhuzamosan is igénybe vehetők. Az Adatkezelőhöz benyújtott előzetes kérelem nem kötelező előfeltétele a NAIH-panasznak, de annak megkísérlése gyorsabb és egyszerűbb megoldást eredményezhet.

---

8. melléklet – Adatfeldolgozói adatlap

Dokumentum azonosítója: BFSZ-GOTC-001 / 8. melléklet Verzió: 1.0 Vonatkozó BFSZ-pontok: 16.2, 16.3

---

A) Supabase, Inc.

Az adatfeldolgozó által végzett adatkezelési tevékenységek:

Adatfeldolgozói megállapodás megkötésének dátuma: ____________

Az Adatkezelő kapcsolattartója a Supabase-szel: Svercsok Nándor — nandor.svercsok@gmail.com

Supabase biztonsági incidensbejelentési e-mail: security@supabase.io

---

B) Cloudflare, Inc.

Az adatfeldolgozó által végzett adatkezelési tevékenységek:

Adatfeldolgozói megállapodás megkötésének dátuma: ____________

Az Adatkezelő kapcsolattartója a Cloudflare-rel: Svercsok Nándor — nandor.svercsok@gmail.com

Cloudflare biztonsági incidensbejelentési e-mail: securityincidents@cloudflare.com

---

C) Adatfeldolgozói változások nyilvántartása

---

A jelen Belső Felhasználási Szabályzat (BFSZ-GOTC-001) és valamennyi melléklete ezzel teljes és egységes dokumentumot alkot.

---

Kelt: Bezedek, 2026. június 28.

 

---

Svercsok Nándor ügyvezető / cégvezető Cadway Szolgáltató Korlátolt Felelősségű Társaság mint Adatkezelő