Műszaki és szervezési intézkedések

Ez a dokumentum több nyelven jelenik meg. A nyelvi változatok közötti bármilyen eltérés esetén a lengyel változat az irányadó.

1.1 verzió · Utolsó frissítés: 2026. október 22.

A GDPR 32. cikke szerinti intézkedések, amelyekkel az LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Lengyelország, védi a formexposed szolgáltatást. Ez az oldal az Adatfeldolgozási szerződés részét képezi annak 2. mellékleteként.

1. Hatály és alapelv

Az intézkedések a szolgáltatás által kezelt valamennyi adatra vonatkoznak: az Ügyfeleink nevében kezelt adatokra (az Adatfeldolgozási szerződésben leírtak szerint), valamint azokra az adatokra, amelyek tekintetében mi magunk vagyunk az adatkezelő, például az ügyfélfiókokra és naplókra. A két körre nem alkalmazunk különböző védelmi szinteket; ami a fiókot védi, az az adatfeldolgozóként kezelt adatokat is védi.

Felépítés a GDPR 32. cikkének (1) bekezdése szerint. Az álnevesítést és titkosítást (a) pont) a 4. szakasz tárgyalja; a rendszerek folyamatos bizalmas jellegét, integritását, rendelkezésre állását és ellenálló képességét (b) pont) a 3., 5., 6. és 7. szakasz; az incidens utáni rendelkezésre állás kellő időben történő helyreállításának képességét (c) pont) a 7.1 szakasz; a hatékonyság rendszeres tesztelésére, felmérésére és értékelésére szolgáló eljárást (d) pont) a 9. szakasz. Az intézkedéseket az Adatvédelmi hatásvizsgálatunkban leírt kockázatok alapján választottuk ki, figyelembe véve a tudomány és technológia állását és a megvalósítás költségeit.

Alapelv: a megvalósult állapotot mutatjuk be, nem a szándékot. Itt csak az szerepel, amit a kódban vagy az üzemeltetésben ténylegesen megvalósítottunk. A tervezett, de még meg nem valósított intézkedéseket a 10. szakasz kifejezetten „tervezettként” sorolja fel. Az itt nem szereplő intézkedés megléte nem feltételezhető hallgatólagosan.

A gépek nevét, belső címeket, portokat, felhasználóneveket és szoftververziókat szándékosan nem közöljük. Ezek senkinek nem segítenek az intézkedések értékelésében, viszont segítenek annak, aki meg akarja kerülni őket. Akinek az Adatfeldolgozási szerződés szerinti audithoz szüksége van rájuk, az az audit keretében, titoktartás mellett megkapja őket, az audithoz szükséges mértékben.

2. A szolgáltatás felépítése

A szolgáltatás a szolgáltató két saját, Lengyelországban található szerverén fut, amelyek ugyanabban a belső hálózatban vannak:

Webszerver adatbázissal. Kiszolgálja az alkalmazást, tárolja az adatbázist, értesítéseket küld és biztonsági mentést készít az adatokról. Kizárólag ez van úgy beállítva, hogy az internetről érkező kéréseket fogadjon.
Vizsgálati szerver. Böngészőben végzi a harmadik felek és a saját weboldalak ellenőrzését, és futtatja azt a nyelvi modellt, amely egyes űrlapokat osztályoz és kódot egészít ki a „Fix it for me” funkcióban. Nincs úgy beállítva, hogy az internetről kéréseket fogadjon; ehelyett maga kéri le feladatait a webszerverről, és oda küldi vissza az eredményeket.

Az üzemeltetésben nem vesz részt tárhely-, adatközpont- vagy felhőszolgáltató, és semmi nem kerül külső MI-szolgáltatáshoz. Azt, hogy mely harmadik felek kapnak adatokat, a További adatfeldolgozók oldal ismerteti.

3. Bizalmas jelleg

3.1 Fizikai hozzáférés ellenőrzése

A szerverek a szolgáltató Lengyelországban található, nyilvánosság számára nem hozzáférhető helyiségeiben vannak. Csak a tulajdonos fér hozzájuk (az üzemeltető közlése szerint). A helyszín pontos címét itt szándékosan nem adjuk meg.

3.2 Hozzáférés ellenőrzése: bejelentkezés a szolgáltatásba

A jelszavakat kizárólag hash formájában, a PHP szabványos módszerével (bcrypt) tároljuk. Ha a szabványos módszer változik, a hash a következő bejelentkezéskor megújul. Ismeretlen címmel végzett bejelentkezési kísérletnél a szerver szintén kiszámít egy hash-t, hogy a válaszidő ne árulja el, létezik-e a fiók. Hasonlóképpen a jelszó-visszaállítási kérelemre adott válasz sem a megfogalmazásával, sem az időtartamával nem árulja el, létezik-e a fiók; ugyanarra a címre óránként legfeljebb három visszaállítási e-mailt küldünk. Az új jelszónak legalább tíz karakter hosszúnak kell lennie, és nem haladhatja meg a 72 bájtot (UTF-8), mert a bcrypt ennél több bájtot nem vesz figyelembe. A jelszó megváltoztatása minden más eszközt kijelentkeztet; a hivatkozáson keresztüli visszaállítása minden eszközt kijelentkeztet, és a hivatkozás csak egyszer érvényes.
Zárolás sikertelen kísérletek után. A sikertelen bejelentkezéseket IP-címenként számoljuk; ha rövid időn belül túl sok történik (jelenleg nyolc 15 perc alatt), az adott címről történő bejelentkezést ideiglenesen letiltjuk. A sikeres bejelentkezés nullázza ezt a számlálót. A kísérleteket hét nap után töröljük. Emellett minden jelszóellenőrzés előtt fiókonként (ismeretlen cím esetén a megadott címenként) és IP-címenként egy kísérletet számolunk, a sikeres kísérleteket is beleértve: jelenleg legfeljebb nyolcat fiókonként ugyanarról az IP-címről, és 80-at IP-címenként 15 perc alatt; az elosztott találgatás ellen fiókonként az összes címre együttesen lényegesen magasabb korlát érvényes. Egy másik címről érkező sikertelen kísérletek ezért már nem zárják ki a tulajdonost a fiókjából. E számlálók csak egy HMAC-kulcsot tartalmaznak, olvasható e-mail- vagy IP-címet nem, és az időablakukkal együtt lejárnak. Ha a számlálók tárolója nem érhető el, a bejelentkezést elutasítjuk, nem engedjük át. Ugyanilyen jellegű korlátozás vonatkozik a jelszó megerősítésére jelszó- vagy címváltoztatás, a második tényező be- vagy kikapcsolása, munkaterület átadása, adatexport és fióktörlés előtt (öt kísérlet fiókonként 15 perc alatt), a regisztrációkra (tíz IP-címenként óránként), valamint az ügyfélportálok jelszavaira (tíz kísérlet portálonként és IP-címenként, 50 portálonként 15 perc alatt).
Második tényező. Minden fiók bekapcsolhatja az RFC 6238 (TOTP) szerinti egyszer használatos kóddal történő bejelentkezést. Az ehhez tartozó titkot titkosítva tároljuk az adatbázisban; a kulcsot nem az adatbázisban tároljuk, így egy adatbázis-kivonat önmagában nem elegendő. Egy elfogadott kód másodszor már nem érvényes. Tíz helyreállítási kódot kizárólag hash formájában tárolunk. Az egyszer használatos és helyreállítási kódokra fiókonként tíz kísérletes korlát vonatkozik 15 perc alatt, a beállítás során is.
Adminisztrációs felület csak második tényezővel. Az üzemeltető adminisztrációs felülete csak olyan fiókok számára nyílik meg, amelyeknél a második tényező be van kapcsolva. A beállítási ellenőrzőlista minden második tényező nélküli rendszergazdai fiókot jelez.
Munkamenetek. A munkamenetsütit szkriptek nem olvashatják (HttpOnly), csak HTTPS-en továbbítjuk (Secure), és nem küldjük el harmadik felek oldalairól érkező, módosítást végrehajtani képes kérésekkel (SameSite=Lax). Bejelentkezéskor új munkamenet-azonosító jön létre, így egy korábban elhelyezett azonosító már nem érvényes; a szerver nem fogad el olyan munkamenet-azonosítót, amelyet nem maga adott ki. Minden fiók látja a bejelentkezett eszközeit, és egyenként kijelentkeztetheti őket.
A „Maradjak bejelentkezve” lehetőség választható, és 30 napig érvényes, de nem használható rendszergazdai jogosultságú fiókoknál; ezek mindig jelszóval és második tényezővel jelentkeznek be. A token két részből áll; az ellenőrző részt az adatbázisban csak hash formájában tároljuk. Minden használat újra cseréli, és egyidejű kérések esetén is minden token csak egyszer érvényes, így egy ellopott token legkésőbb a következő valódi látogatáskor észlelhető.
E-mailben küldött hivatkozások. A cím megerősítésére és a jelszó visszaállítására szolgáló hivatkozásokat az adatbázisban csak hash formájában tároljuk. A visszaállítási hivatkozás egy óráig, a regisztráció megerősítésére szolgáló hivatkozás 72 óráig, a megváltoztatott cím megerősítésére szolgáló hivatkozás 24 óráig érvényes. Ha az e-mail-cím megváltozik, egy még nyitott visszaállítási hivatkozás érvénytelenné válik.
Interfészek. Az API-kulcsokat, a bővítmények kapcsolódási kódjait és a bevezetési kódokat kizárólag hash formájában tároljuk. Az API-kulcsok percenként csak korlátozott számú alkalommal használhatók; a bővítmények kapcsolódási kódjai 15 percig és csak egyszer érvényesek.
Botvédelem a nyilvános űrlapokon (regisztráció, bejelentkezés, jelszó, ellenőrzés, fejléc-eszköz, kizárás, ügyfélszolgálat és kapcsolatfelvétel): Google reCAPTCHA, amely csak beküldéskor töltődik be. Csak a Google érvényes, megfelelő pontszámú, pontosan az űrlap műveletéhez tartozó válaszát fogadjuk el; ha a Google három másodpercen belül nem válaszol, a beküldést elutasítjuk. A részleteket az Adatvédelmi tájékoztató tartalmazza.

3.3 Hozzáférés ellenőrzése: szerveradminisztráció

Az internetről elérhető szerver csomagszűrővel csak az általa kínált szolgáltatásokat engedélyezi, és a szerveradminisztrációba történő ismételt sikertelen bejelentkezések után automatikusan letiltja a címeket.
A szerverek közötti automatizált folyamatok saját, szűken korlátozott jogosultságú kulcsokat használnak. Az a kulcs, amellyel a webszerver a vizsgáló új verzióit továbbítja, a vizsgálati szerveren csak rögzített parancslistát hajthat végre, és csak a vizsgáló könyvtárába másolhat, kizárólag írási hozzáféréssel; interaktív bejelentkezés nem lehetséges vele, és minden elutasított parancsot naplózunk. Hasonlóképpen a vizsgálati szerver csak a webszerver egy meghatározott könyvtárába írhat képernyőképeket.
A weboldalt kiszolgáló folyamatnak nincs sem írási hozzáférése az éles telepítéshez, sem kulcsa a vizsgálati szerverhez. Az adminisztrációs felületen indított telepítés csak egy feladatot rögzít, amelyet egy külön futás hajt végre.
Az olyan titkokat, mint az adatbázis hozzáférési adatai és a kulcsok, a kiszolgált könyvtáron kívüli konfigurációs fájlokban tartjuk, és telepítéskor nem másoljuk át őket. A webszerver konfigurációját nem terjesztjük a webes felületen keresztül.

3.4 Jogosultság-ellenőrzés: jogosultságok a szolgáltatáson belül

Szerepkörök. Minden munkaterületen tulajdonos, rendszergazda és olvasó szerepkör van. Módosítást, törlést, meghívást és hozzáférési adatok tárolását csak tulajdonosok és rendszergazdák végezhetnek; szerepköröket csak a tulajdonos módosíthat, és tagokat is csak ő távolíthat el. A meghívás csak addig érvényes, amíg a küldője továbbra is tulajdonos vagy rendszergazda. Az olvasók a webhookok és csevegőcsatornák címét csak a gazdagép nevére rövidítve látják, mert a cím önmagában lehetővé teszi a csatornába történő üzenetküldést. Az ellenőrzés a szerveren történik, nem pusztán a felületen.
Munkaterülethez kötés. A domainek és beállítások csak a munkaterület tagjai számára érhetők el. A Szolgáltatás minden ellenőrzéshez egy véletlenszerű, nem kitalálható hivatkozás alatt jelentést hoz létre; az ellenőrzés eredményei és képernyőképei e hivatkozáson keresztül bejelentkezés nélkül elérhetők, a képernyőképek csak a jelentésük hivatkozásával együtt. A hivatkozás a fiókban és a riasztásokban jelenik meg; aki továbbadja, az a jelentést is továbbadja.
Az állapotot módosító kérésekhez munkamenetenkénti biztonsági token szükséges (CSRF-védelem), amelyet állandó időben hasonlítunk össze.
„Megtekintés ügyfélként”. Ügyfélszolgálati célból az üzemeltető úgy láthatja az alkalmazást, ahogyan azt az Ügyfél látja. A nézet egy óra után véget ér, letiltja a jelszó, cím, második tényező, eszközök és előfizetés módosítását, az exportot és a törlést, közben bezárja az adminisztrációs felületet, és naplózásra kerül. A befejezése teljesen kijelentkezteti az üzemeltetőt; az üzemeltető csak jelszóval és második tényezővel történő újbóli bejelentkezés után térhet vissza az adminisztrációs felületre. Az Ügyfél ezt az adatexportjában láthatja.
Adminisztráció. Csak néhány, kifejezetten feljogosított fiók rendelkezik rendszergazdai jogosultsággal; a második tényező minden adminisztrátori visszaállítását naplózzuk.

3.5 Elkülönítés ellenőrzése

Az Ügyfelek adatai munkaterületenként logikailag elkülönülnek. A bejelentkezés utáni terület minden olvasási és írási útvonala érvényesíti ezt a hozzárendelést; a jelentések ezenfelül a hivatkozásukon keresztül is elérhetők (3.4 szakasz).
A fejlesztés és az üzemeltetés külön telepítésekben, külön adatbázisokkal és külön adatbázis-felhasználókkal működik. A fejlesztői felhasználó nem fér hozzá az éles adatbázishoz. Valódi ügyféladatokat nem másolunk a fejlesztési környezetbe; ott generált mintaadatokkal dolgozunk.
A vizsgáló minden környezethez saját hozzáférési adatokkal rendelkezik, kizárólag a feladataihoz szükséges adatokhoz való jogosultsággal. Fiókokat, számlázási adatokat és naplókat nem olvashat.
Ugyanezen szolgáltató más szolgáltatásai is futnak a webszerveren. Ezek saját adatbázisokkal és saját adatbázis-felhasználókkal rendelkeznek, e szolgáltatás adataihoz való hozzáférés nélkül.

4. Titkosítás, álnevesítés és adattakarékosság

4.1 Hozzáférési adatok a bejelentkezés mögötti vizsgálathoz

Ehhez a funkcióhoz az Ügyfél egy tesztfiók felhasználónevét és jelszavát tárolja. Ezek a szolgáltatás legérzékenyebb adatai, ezért minden mástól eltérő védelemben részesülnek:

Tároláskor a webszerver a vizsgálati szerver nyilvános kulcsával titkosítja őket (ECIES: X25519 rekordonként egyszeri kulccsal, HKDF-SHA256, AES-256-GCM). A privát kulcs csak a vizsgálati szerveren létezik. A webszerver, az adatbázis és a biztonsági mentések kizárólag titkosított szöveget tartalmaznak; ott mi sem tudjuk elolvasni azt.
Minden rekord kriptográfiailag a domainjéhez van kötve. Másik domainhez áthelyezve a visszafejtés sikertelen.
Vizsgálatkor a titkosított szöveget a feladathoz csatoljuk. A vizsgálati szerver visszafejti, és a hozzáférési adatokat kizárólag a szabványos bemeneten keresztül adja át az ellenőrző konténernek, soha nem a folyamatlistákban látható parancssori argumentumként. Amint a vizsgálati szerver beolvasta, a titkosított szöveget töröljük a feladatból; az esetleges maradványokat egy futás legkésőbb egy óra múlva eltakarítja.
A hozzáférési adatokat soha nem jelenítjük meg, nem naplózzuk, nem adjuk ki az API-n keresztül, és nem exportáljuk. A felület csak a felhasználónév első karakterét és hosszát mutatja. Eltávolításukkor a titkosított szöveget felülírjuk.
Bejelentkezés mögött a vizsgáló csak olvas: nincs beküldés, aktív teszt, képernyőkép, illetve kijelentkezésre, törlésre vagy lemondásra szolgáló oldal.

4.2 További titkosítás és hash-ek

A jelszavakat, helyreállítási kódokat, ügyfélportál-jelszavakat, API-kulcsokat, kapcsolódási és bevezetési kódokat, „Maradjak bejelentkezve” tokeneket, az eszközlistában szereplő munkamenet-azonosítókat, valamint a megerősítő és visszaállítási hivatkozásokat kizárólag hash formájában tároljuk.
A második tényező titkait titkosítva tároljuk (3.2 szakasz).
Nem állítjuk, hogy a teljes adatbázis nyugalmi állapotban titkosított. Az érzékeny értékeket egyenként védjük a fent leírtak szerint.

4.3 Beépített adattakarékosság

Kézbesítés ellenőrzése: Csak a fejléceket és a szöveg legfeljebb első 8 KB-ját olvassuk be. Az adatbázisba csak az időpont, a hozzárendelés, adott esetben a tesztbeküldés azonosítója, valamint a hitelesség-ellenőrzés eredménye (SPF, DKIM, DMARC) kerül, a tartalom vagy a teljes feladói cím soha. A legutóbbi e-mail hitelességi eredményét a domainhez tároljuk, és a következő felülírja; ez tartalmazza a kézbesítő levelezőszerver IP-címét és a feladó e-mail-domainjét. Sikeres feldolgozás után az e-mailt töröljük a postafiókból; ha a lekérés vagy a törlés sikertelen, erre a következő sikeres futáskor kerül sor.
Ellenőrzések: Az űrlapok szerkezetét mezőnevekkel, típusokkal és címkékkel, kötelezőségi és láthatósági attribútumokkal tároljuk, értékek nélkül; az előre kitöltött rejtett mezők elejét (legfeljebb 24 karaktert) és az adatattribútumok elejét (legfeljebb 60 karaktert) a vizsgáló csak az ellenőrzés során olvassa, és nem tárolja. A teljes ellenőrzés képernyőképein nem takarunk ki adatokat; csak a böngészős ellenőrzések takarják ki a beviteli mezőket. Az űrlapok címzettjeinek címét csak domainként tároljuk. Az aktív tesztbeküldések csak megjelölt tesztszövegeket tartalmaznak, személyes adatok nélkül.
A WordPress- és TYPO3-bővítmények csak napi számadatokat és olyan jellemzőket továbbítanak, mint a telepített bővítmények listája, csatlakoztatott WordPress-bővítmény esetén pedig a blokkolt üzenetek hivatkozásainak domainjeit is a rajvédelemhez (alapértelmezetten bekapcsolva); más tartalmat, a látogatók nevét, címét vagy IP-címét nem. Az opcionális űrlap- és mezőhibaszámlálók alapértelmezetten ki vannak kapcsolva.
„Fix it for me”: A beillesztett kódot csak a kérés időtartama alatt dolgozzuk fel, és nem tároljuk.
Jelvény: Az ügyfélweboldalakon megjelenő jelvénykép nem állít be sütit és nem indít munkamenetet.
Az üzemeltetési értesítések az üzemeltető telefonjára rögzített, változók nélküli szövegek, tehát nem tartalmaznak neveket, címeket vagy tartalmat. Az üzemeltetőnek e-mailben küldött hibaértesítések a hibaüzenet nyers, nem tisztított, 400 karakterre rövidített szövegét tartalmazzák; ez egyes esetekben címeket vagy hivatkozásokat is tartalmazhat.
Rajvédelem: Az Ügyfelek bővítményei között csak a blokkolt spamben lévő hivatkozások domainjeit osztjuk meg; az IP-hálózatok cseréje ki van kapcsolva.
Helymeghatározás: Az IP-címhez tartozó országot helyi adatbázisfájlból állapítjuk meg; semmilyen cím nem kerül földrajzi helymeghatározó szolgáltatáshoz.

5. Védelem a vizsgálóval való visszaélés ellen

A vizsgáló valódi böngészővel tölti be harmadik felek oldalait. Védelem nélkül olyan eszköz lenne, amellyel egy kívülálló elérhetné belső hálózatunkat vagy más, nem nyilvános célpontokat (szerveroldali kéréshamisítás). Ezért két független védelmi réteget és minden egyes futás elkülönítését alkalmazzuk.

5.1 Elkülönített futás

Minden ellenőrzés saját konténerben fut, amelyet utána eltávolítunk. Rendszergazdai jogosultság, további operációsrendszer-képességek és jogosultságnövelési lehetőség nélkül működik. Fájlrendszere kis, átmeneti tárolóterületek kivételével csak olvasható.
A memória, a folyamatok száma és a futási idő korlátozott; az időkeretet túllépő futást leállítjuk.

5.2 Hálózat: két réteg

Első réteg, a vizsgálóban: A vizsgálat előtt, majd a böngésző minden egyes kérésénél, beleértve az átirányításokat és a beágyazott tartalmakat, ellenőrizzük, hogy a cím milyen címre oldódik fel. A privát, helyi, fenntartott és dokumentációs hálózatokat (IPv4 és IPv6), valamint a weben szokásostól eltérő portokat elutasítjuk. A böngésző nem engedélyez service workereket, a WebSocket-kapcsolatokat pedig lezárjuk, mert mindkettő megkerülhetné ezt az ellenőrzést.
Második réteg, a hálózatban: A konténerek saját hálózatban futnak. A tűzfalszabályok innen az internetre csak webes portokon engedélyeznek kapcsolatot; a privát hálózatokba, így a webszervert és adatbázist tartalmazó belső hálózatunkba irányuló kapcsolatok blokkolva vannak. A magához az ellenőrzési futáshoz szükséges kivételek a szükséges mértékre korlátozódnak, és belső dokumentációnkban szerepelnek. Ez a réteg akkor is érvényesül, ha egy név csak az első ellenőrzés után oldódik fel más címre.

5.3 A webszerver által indított kérések

Amikor maga a webszerver kér le harmadik felekhez tartozó címeket – a domain feletti rendelkezés igazolásához, a fejléc-eszközhöz, a védtelen fájlok kereséséhez, a pulse-kérésekhez, RDAP-lekérdezésekhez és tanúsítványok ellenőrzéséhez, webhookokhoz és csevegési riasztásokhoz, valamint az opcionális második ellenőrzési ponthoz –, ugyanazok a szabályok érvényesek: kizárólag webes protokollok a szokásos webes portokon (webhookok és csevegési riasztások csak HTTPS-en, az alapértelmezett porton), csak nyilvános címek, kapcsolat kizárólag az előzetesen ellenőrzött pontos címhez, hogy egy nevet utólag ne lehessen belső célpontra átirányítani, az átirányításokat vagy egyáltalán nem követjük, vagy csak kézzel, minden alkalommal újraellenőrizve, rövid időkorlátokkal; a domain feletti rendelkezés igazolásánál, a pulse-kéréseknél és a böngészős ellenőrzések második ellenőrzési pontjánál a válasz mérete is korlátozott.

5.4 Amit a vizsgáló nem végez harmadik felek oldalain

Aktív tesztbeküldések (ellenőrzésenként legfeljebb öt) az Ügyfelek számára csak olyan domaineknél érhetők el, amelyek felett a rendelkezést igazolták (DNS, meta címke, fájl vagy bővítmény); az egyetlen kivételt saját teszt- és demó-domainjeink belső ellenőrzései jelentik. Az igazolt domain gazdagépneve nem módosítható, így az igazolás nem száll át másik gazdagépre. Minden más passzív: az oldalak olvasása úgy, ahogyan egy látogató tenné.
A böngészős ellenőrzések a beküldés előtti pontig haladnak, és nem indítanak rendelést, fizetést vagy beküldést.
A kizárási listán szereplő domaineket nem ellenőrizzük; a folyamatos felügyelet a következő ütemezett ellenőrzéskor megszűnik.

6. Integritás: továbbítás és bevitel

6.1 Adatátvitel

Az alkalmazás az internetről csak HTTPS-en érhető el; a böngésző utasítást kap arra, hogy egy évig kizárólag HTTPS-t használjon (HSTS). A tanúsítványok automatikusan megújulnak.
További fejlécek korlátozzák az alkalmazás harmadik felek oldalaiba ágyazását, a fájltípusok találgatását és az űrlapok harmadik felek célpontjaira történő beküldését. A tartalombiztonsági házirend csak olyan szkriptek futását engedi az alkalmazásban, amelyeket a szerver az adott válaszban engedélyez; a korszerű böngészők nem hajtják végre a HTML-be befecskendezett szkripteket vagy eseménykezelőket.
A kézbesítés-ellenőrzési postafiókot titkosított kapcsolaton keresztül, tanúsítvány-ellenőrzéssel kérjük le.
A webhookokat az Ügyfél titkával lehet aláírni (HMAC-SHA256 időbélyeggel), hogy a címzett ellenőrizhesse az eredetet és az integritást. Az opcionális második ellenőrzési ponthoz intézett kéréseket, böngészős ellenőrzéseknél pedig a válaszaikat is aláírjuk.
Nyíltan közöljük: A belső hálózatunkon belüli kapcsolatok nem mindenhol titkosítottak. A bejelentkezés mögötti vizsgálat hozzáférési adatai mindvégig titkosítva maradnak (4.1 szakasz).

6.2 Bevitel ellenőrzése és naplók

A fiókokban és munkaterületeken végzett fontos műveleteket (például bejelentkezés, domainek, riasztási célok és jogosultságok módosítása, törlések, ügyfélszolgálati hozzáférés) a tevékenységnaplóban rögzítjük a fiókkal, időponttal, IP-címmel és országgal együtt, és 365 nap után töröljük.
A biztonsági és visszaélés-megelőzési célból tárolt oldalelérési bejegyzéseket 60 nap, a hibanaplókat 90 nap, az elküldött e-mailek tartalmát 30 nap után töröljük. A lekért címekben és hivatkozó címekben szereplő hozzáférési tokenek, például a jelentés- vagy portálhivatkozások tokenjei, az oldalelérési bejegyzésekben csak maszkolva jelennek meg.
A szerződéses dokumentumok elfogadását a megjelenített verzióval, annak ellenőrzőösszegével, az időponttal, IP-címmel és böngészőazonosítóval együtt tároljuk.
A bizonyítéknaplók külső időbélyeg-szolgáltató időbélyegével láthatók el; ehhez csak a tartalom ellenőrzőösszege kerül, maga a tartalom nem.

7. Rendelkezésre állás és ellenálló képesség

7.1 Biztonsági mentés

Az adatbázisról minden éjjel biztonsági mentés készül. A mentés csak a tartalma ellenőrzése után kapja meg végleges nevét: a mentőprogram sikeres befejezése, legalább egy rekord, az adatbáziséval megegyező számú tábla és a teljes futás zárósora szükséges. A régebbi mentéseket csak sikeres új mentés után távolítjuk el.
Minden mentést 14 nap után törlünk. A tárolási hely minden kiszolgált könyvtáron kívül van; a projekten belüli helyet elutasítjuk.
Visszaállítási teszt: Hetente egyszer a legutóbbi mentést egy ideiglenes adatbázisba töltjük, táblánként összehasonlítjuk az éles adatbázissal, majd ismét töröljük. Az eredményt tároljuk.
Ha egy mentés vagy teszt sikertelen, értesítést küldünk e-mailben és az üzemeltető telefonjára.
Helyreállítás incidens után: Ha az adatbázis meghibásodik vagy az adatok megsérülnek, visszaállítjuk a legutóbbi tesztelt mentést. Az azóta végzett módosítások, rendszerint legfeljebb egy nap módosításai, ennek során elveszhetnek; ha egy mentés sikertelen volt, ennek megfelelően több is. Ezután újra végrehajtjuk az ismert későbbi törlési kérelmeket (8. szakasz). Meghatározott helyreállítási időt nem vállalunk.
Korlát, nyíltan közölve: A mentéseket jelenleg az adatbázissal azonos helyszínen tároljuk, és nincsenek külön titkosítva. Kezelési hibák, hibás módosítások és adatsérülés ellen védenek, magának a szervernek az elvesztése ellen nem. Második helyszínen tárolt titkosított másolat készítését tervezzük (10. szakasz).
A bejelentkezés mögötti vizsgálat hozzáférési adatai a mentésekben csak titkosított szövegként szerepelnek; a második tényező titka csak titkosított formában, az adatbázison kívül tárolt kulccsal.

7.2 Felügyelet

Egy állapotellenőrző futás ötpercenként ellenőrzi a szolgáltatás összetevőit, beleértve az adatbázist, a várólistát és a vizsgáló életjelét, amelyet a vizsgáló tétlen állapotban is rendszeresen kiír. Ha egy összetevő kiesik, értesítést küldünk; ha helyreáll, feloldó értesítést.
Kölcsönös felügyelet: Egy állapotellenőrző futás nem tudja jelezni annak a gépnek a kiesését, amelyen fut. Ezért a vizsgálati szerver percenként ellenőrzi, hogy az alkalmazás válaszol-e, és több egymást követő sikertelenség után rögzített szöveggel értesíti az üzemeltető telefonját. Fordítva a webszerver figyeli a vizsgáló életjelét; a beállítási ellenőrzőlista mutatja, hogy működik-e a kölcsönös felügyelet.
Hibariasztás: Egy korábban még nem előfordult hibatípust egyszer azonnal jelentünk; a hibák halmozódása csak egyetlen jelzést vált ki az üzemeltető telefonjára; naponta egyszer összefoglalót küldünk. Így nem egy Ügyféltől értesülünk először a hibáról.
Korlát, nyíltan közölve: Mindkét szerver ugyanazon a helyszínen van. A teljes helyszín kiesését, például áram- vagy internetkimaradást, semmilyen riasztási mechanizmus nem jelzi, hanem ember észleli.

7.3 Módosítások és telepítés

Az új verziókat először az elkülönített fejlesztési környezetben állítjuk össze és teszteljük. A telepítés az első fájl írása előtt ellenőriz minden előfeltételt, elvégzi az adatbázisséma módosításait, és a vizsgáló újraindítása előtt hagyja szabályosan befejeződni a folyamatban lévő ellenőrzéseket.
Az új Ügyfél által bejárt folyamatra valódi HTTP-n keresztüli alapműködési teszt áll rendelkezésre, amelyet átállások után futtatunk. Nem állítjuk, hogy minden egyes telepítés előtt automatizált tesztcsomagot futtatunk.

8. Törlés és megőrzési idők

Egy éjszakánkénti törlési futás érvényesíti az Adatvédelmi tájékoztatóban és az Adatfeldolgozási szerződésben megadott határidőket. Ugyanazokat a beállításokat olvassa, amelyekből a szövegekben szereplő számadatok származnak; e határidők tekintetében ezért a szöveg és a működés nem tér el egymástól.
Az ellenőrzési eredményeket a képernyőképekkel együtt 13 hónap után töröljük (domainenként a legutóbbi megmarad), a bővítmények számadatait 13 hónap, a riasztások kézbesítési naplóit 90 nap, az ügyfélszolgálati megkereséseket 24 hónap után.
Egy domain eltávolítása törli annak adatait, beleértve az ellenőrzéseket, űrlapokat, megállapításokat, képernyőképeket, jelentéseket, feladatokat, riasztási célokat és naplókat, incidenseket, kézbesítési adatokat, a bejelentkezés mögötti vizsgálat hozzáférési adatait és a bizonyítékokat.
A fiók törlése azonnal megtörténik; a további tagok nélküli munkaterületeket adataikkal együtt töröljük, a további tagokkal rendelkező munkaterületek pedig egy másik taghoz kerülnek, elsőként a rendszergazdákhoz, közülük pedig a legrégebbi taghoz. Saját megőrzési idejük lejártáig megmaradnak: a naplók, amelyek bejegyzései megtartják a régi, már nem létező fiókra hivatkozó fiókszámot, beleértve a törlési bejegyzést is, továbbá az elküldött e-mailek, a szerződés megkötésének igazolása, az ügyfélszolgálati megkeresések, az érdeklődők ellenőrzéseiről készült jelentések (legfeljebb 90 napig) és a Stripe-nál tárolt számlázási adatok; a részleteket az Adatvédelmi tájékoztató tartalmazza.
A törölt adatok a biztonsági mentésekben azok 14 nap utáni lejártáig megmaradnak. A mentésen belül célzott törlés nem történik; ha egy mentést visszaállítunk, az ismert későbbi törlési kérelmeket kézzel ismét végrehajtjuk.

9. Szervezet és felülvizsgálat

Személyek: A szolgáltatást jelenleg maga a tulajdonos üzemelteti. További személyek csak titoktartási kötelezettség vállalása után és csak a szükséges mértékben kapnak hozzáférést, és adatokat kizárólag az utasításaink alapján kezelnek (a GDPR 29. cikke és 32. cikkének (4) bekezdése).
További adatfeldolgozók: Csak a garanciáik felülvizsgálata után, a GDPR 28. cikkének (4) bekezdése szerinti szerződés alapján vesszük igénybe őket, és felsoroljuk őket a További adatfeldolgozók oldalon; a részleteket az Adatfeldolgozási szerződés szabályozza.
Adatvédelmi incidensek: Ha egy adatvédelmi incidens adatfeldolgozóként kezelt adatokat érint, indokolatlan késedelem nélkül, lehetőség szerint 48 órán belül értesítjük az Ügyfelet; a részleteket az Adatfeldolgozási szerződés szabályozza.
Sérülékenységek bejelentése: Bejelentéseket a Biztonság oldalon és a /.well-known/security.txt fájlon keresztül fogadunk.
Beállítási és indulási ellenőrzőlista: Az adminisztrációs felületen egy ellenőrzőlista méri a biztonsági szempontból lényeges beállítások állapotát, például a biztonsági mentést, a második tényező nélküli rendszergazdákat, a levelezési beállításokat és az életjelet, és jelzi az eltéréseket.
Ezen intézkedések felülvizsgálata (a GDPR 32. cikke (1) bekezdésének d) pontja): a szolgáltatás minden jelentős változásakor, minden biztonsági incidens után, egyébként pedig legalább évente egyszer. Ennek során értékeljük, hogy az intézkedések hatékonyak-e és továbbra is megfelelnek-e a kockázatoknak, az eredményt pedig ezen oldal új verziójában rögzítjük, vagy ha nincs változás, a felülvizsgálat dátumával a 11. szakaszban. A beállítási és indulási ellenőrzőlista folyamatosan méri az általa lefedett beállítások állapotát.
Külső auditok: Jelenleg nem rendelünk meg külső behatolási teszteket, és nincsenek biztonsági tanúsítások. Ezt azért közöljük itt, hogy senki ne feltételezze a meglétüket.

10. Tervezett, még meg nem valósított intézkedések

E pontok mindaddig nem minősülnek vállalt intézkedéseknek, amíg egy új verzióban megvalósítottként nem szerepelnek itt:

Biztonsági mentés második helyszínen: az éjszakai mentés titkosított másolata a szerveren kívül, hogy a szerver teljes elvesztése se vezessen adatvesztéshez.
Második ellenőrzési pont: A böngészős ellenőrzések második helyszínről történő független megerősítése a szolgáltatásban elő van készítve, de nincs beállítva. Enélkül nincs második helyszínről származó megerősítés.
A szerveradminisztráció biztonságának megerősítése: Ez folyamatosan zajlik. Az 1. szakaszban ismertetett okokból részleteket nem teszünk közzé.

11. Állapot és verzió

1.1 verzió · Utolsó frissítés: 2026. október 22. · a nyelvi változatok közötti eltérés esetén a német helyett a lengyel változat az irányadó; más változás nincs.
1.0 verzió · Utolsó frissítés: 2026. október 11. · első változat önálló oldalként; korábban az Adatfeldolgozási szerződés 2. melléklete. Az előző melléklethez képest javítva: a visszaállítási teszt hetente fut, a mentések ugyanazon a szerveren vannak, nem fut automatizált tesztcsomag minden telepítés előtt, a belső hálózat kapcsolatai nem mindenhol titkosítottak. Újonnan ismertetve: a bejelentkezés mögötti vizsgálat hozzáférési adatainak titkosítása, a vizsgáló elkülönítése, kölcsönös felügyelet és hibariasztás.
A módosításokat új verziószámmal itt és a Szerződéses dokumentumok módosításai áttekintésben tesszük közzé; az intézkedések bármely gyengítésére az Adatfeldolgozási szerződés szerinti értesítési határidő vonatkozik.
A nyelvi változatok közötti eltérés esetén a lengyel változat az irányadó.

Miben segíthetünk?