Jogi dokumentum – előzetes változat
Biztonsági nyilatkozat
A RavSolutions szolgáltatást védő technikai és szervezési intézkedések – átvitel, bejelentkezés, munkamenetek, munkaterületek elkülönítése, fájlok, visszaélés elleni védelem, naplózás és incidenskezelés –, valamint ugyanilyen nyíltan az, amivel nem rendelkezünk.
- Utolsó módosítás
- 2026-08-04
- Verzió
- 1.0.0
- Olvasási idő
- 12 perc
1. Miről szól ez a nyilatkozat
Ez a nyilatkozat azokat a technikai és szervezési intézkedéseket írja le, amelyek a RavSolutions szolgáltatást és a benne tárolt adatokat védik. Úgy készült, hogy ellenőrizhető legyen: olyan intézkedéseket nevez meg, amelyek ténylegesen megvalósultak, a 15. pont pedig ugyanilyen nyíltan sorolja fel azt, amivel nem rendelkezünk.
Nem szavatosság, és nem keletkeztet rendelkezésre állási vállalást; a szerződéses feltételeket az Általános Szerződési Feltételek tartalmazzák. Ahol ugyanaz az intézkedés a GDPR tájékoztatóban vagy az adatfeldolgozási tájékoztatóban is szerepel, ott tartalmilag ugyanazt kell mondania.
Az általunk üzemeltetett szolgáltatásra vonatkozik. Az előfizető saját munkaterületén lévő fiókok, eszközök és jelszavak biztonságáért az előfizető felel; az itt leírt intézkedések egyike sem véd meg egy olyan munkaterületet, amelynek belépési adatait megosztották vagy máshol is használják.
2. Hogyan épül fel a szolgáltatás
A szolgáltatás három felületből – a weboldalból, az alkalmazásból és az ügyfélportálból –, egyetlen API-ból, egy PostgreSQL adatbázisból, egy Redis példányból és objektumtárolóból áll. A felületek kizárólag HTTPS-en keresztül érik el az API-t.
Az objektumtároló kivételével minden fordított proxy mögött, a RackForest Zrt. infrastruktúráján fut itt: Hungary (EU). Az adatbázis és a Redis kizárólag belső hálózatra csatlakozik, és egyik sem tesz közzé portot, így az internet felől nem érhetők el; csak az API tud velük kommunikálni.
A feltöltött fájlok nem az alkalmazáskiszolgálókon, hanem a Cloudflare R2 objektumtárolóban vannak, European Union beállítással. A tároló zárt: nincs nyilvános hozzáférése és nincs elé kapcsolt saját domain, minden fájl az API által aláírt hivatkozáson keresztül jut el a felhasználóhoz.
A titkok – adatbázis-jelszavak, aláíró kulcsok, szolgáltatói API-kulcsok – a telepítéskor a környezeti változókból származnak, és soha nem kerülnek be a forráskódtárba.
3. Az átvitel biztonsága
A weboldal, az alkalmazás, a portál és az API teljes forgalma HTTPS-en keresztül zajlik. A tanúsítványokat a Let's Encrypt állítja ki és újítja meg automatikusan, a titkosítatlan HTTP kéréseket pedig átirányítjuk HTTPS-re.
A fordított proxy egyéves érvényességű HTTP Strict Transport Security fejlécet küld, az aldomainekre kiterjedően és előbetöltéssel, így az a böngésző, amely egyszer már járt az oldalon, nem tér vissza titkosítatlan kapcsolatra.
A válaszok X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, strict-origin-when-cross-origin hivatkozói szabály és a kamerát, mikrofont, helymeghatározást tiltó jogosultsági szabály fejléceket tartalmaznak. A kiszolgálót és a keretrendszert azonosító fejléceket eltávolítjuk. Az API kizárólag az alkalmazás és a portál eredetéről fogad el keresztforrású kérést.
A weboldalt, az alkalmazást és a portált Content Security Policy fejléccel szolgáljuk ki. Szkript csak magától a szolgáltatástól tölthető be, az alkalmazásban ezen felül a Google-bejelentkezéshez használt Google Identity Services-től; a weboldal és a portál semmilyen harmadik féltől származó szkriptet nem enged. A keretbe ágyazást, a bővítménytartalmat és a dokumentum alap-hivatkozásának átírását elutasítjuk, az API pedig olyan szabállyal válaszol, amely semmit sem enged meg.
4. Bejelentkezés és jelszavak
A jelszó legalább nyolc karakter, és tartalmaznia kell nagybetűt, kisbetűt és számjegyet. A jelszavakat kizárólag az ASP.NET Core Identity jelszókezelője által előállított, sózott kriptográfiai lenyomatként tároljuk; visszaolvasható formában soha, ezért elfelejtett jelszót nem tudunk visszaadni, csak új beállítását elindítani.
Tíz sikertelen bejelentkezési kísérlet után a fiók tizenöt percre zárolódik. A számlálás a fiókhoz, nem a hívóhoz tartozik, így a sok címre szétosztott próbálkozás is megáll, noha külön-külön minden cím a hívónkénti korlát alatt marad.
Google-fiókkal is be lehet jelentkezni. A Google által kiállított azonosító tokent a munkamenet létrehozása előtt a Google-nál ellenőrizzük, és a Google-jelszót soha nem kapjuk meg.
A regisztráció megerősítő üzenetet küld a megadott címre, és a cím a benne lévő hivatkozás használatakor válik megerősítetté. Az elfelejtett jelszót a nyilvántartott címre küldött egyszer használatos hivatkozáson keresztül lehet újra beállítani; a sikeres beállítás a fennálló zárolást is feloldja, mert rendszerint épp a zárolás miatt kerül rá sor.
5. Munkamenetek és tokenek
A hozzáférési tokenek tizenöt percig érvényes JSON Web Tokenek. Minden kérésnél ellenőrizzük a kibocsátót, a címzettet, az aláírást és a lejáratot, óraeltérés engedélyezése nélkül.
A frissítő token hatvannégy bájt kriptográfiai véletlengenerátorból. Az adatbázis csak a SHA-256 lenyomatát tárolja, így magát a tokent az adatbázis egy másolatából nem lehet kiolvasni.
Minden frissítés cseréli a tokent: a korábbit visszavonjuk, és újat állítunk ki. A frissítő tokenek harminc nap után lejárnak, a kijelentkezés pedig azonnal visszavonja a tokent.
A frissítést elutasítjuk, ha a felhasználót inaktívvá tették, vagy a munkaterület inaktív lett, így egy hozzáférés visszavonása legkésőbb az érvényben lévő hozzáférési token lejártakor érvényesül.
6. Jogosultságkezelés és a munkaterületek elkülönítése
Minden felhasználónak szerepköre van a munkaterületen, és a végpontok ezt ellenőrzik. A csomagfüggő funkciókat ezen felül saját engedélyezési szabályok védik, így az előfizetett csomagon kívüli funkciót az API utasítja el, nem pusztán a felület rejti el.
A munkaterületek adatszinten különülnek el: minden rekord hordozza annak a munkaterületnek az azonosítóját, amelyhez tartozik, és minden lekérdezés a hívó munkaterületére korlátozódik. A másik munkaterülethez tartozó rekord nem elrejtve kerül ki a találatból – be sem kerül oda.
A munkaterületet az aláírt hozzáférési token egyik állításából vesszük, és a kiszolgálón oldjuk fel. A kliens által küldött munkaterület-azonosítóban semmilyen célból nem bízunk meg.
A valós idejű kapcsolatok ugyanazt a hitelesítést használják, mint az API többi része; érvényes token nélküli kapcsolatot elutasítunk, a beérkező üzenet mérete korlátozott, részletes hibainformációt pedig csak fejlesztői környezetben adunk vissza.
7. Hozzáférés az ügyfélportálhoz
Az ügyfél olyan hivatkozást kap, amely véletlenszerűen előállított, egyetlen munkához tartozó, lejárati idővel rendelkező tokent tartalmaz. A token azt az egy munkát nyitja meg, és a munkaterületen semmi mást.
A munka megjelenítése előtt a látogatónak meg kell erősítenie az ügyfélhez rögzített e-mail címet vagy telefonszámot. A sikeres megerősítés tizenkét órán át érvényes igazolást ad, amelyet HMAC-cel írunk alá a kiszolgáló aláíró titkából származtatott, de attól kriptográfiailag független kulccsal, és állandó idejű összehasonlítással ellenőrzünk.
A megerősítési kísérleteket hívónként korlátozzuk, szándékosan nem tokenenként: a tokenenkénti korlátozás lehetővé tenné, hogy bárki kizárja az ügyfelet a saját munkájából pusztán azzal, hogy elhasználja a keretét.
8. Feltöltött fájlok
A feltöltés rögzített fájltípus-listára – JPEG, PNG, WebP, PDF, DOCX, XLSX és egyszerű szöveg – és az előfizetett csomagtól függő legnagyobb méretre korlátozódik. A képeket a kiszolgáló tárolás előtt újrakódolja.
A fájlokat az API által előállított, rövid élettartamú aláírt hivatkozásokon keresztül szolgáljuk ki. Mivel maga a tároló zárt, egy lejárt vagy módosított hivatkozás semmit nem nyit meg.
A feltöltésre és a letöltésre külön hívónkénti korlát vonatkozik, így egy kiszivárgott hivatkozással vagy egy elszabadult klienssel nem lehet korlátlanul tárhelyet és sávszélességet felemészteni.
A tárolt fájlokat a tárolószolgáltató nyugalmi állapotban titkosítva őrzi.
9. Védekezés a visszaélés ellen
Az API hívónként particionált korlátokat alkalmaz: ahol van token, a benne lévő munkaterület és felhasználó szerint, egyébként a hívó címe szerint. A bejelentkezés, a Google-bejelentkezés, a jelszó-visszaállítás és a portálmegerősítés percenként tíz kísérletre, a regisztráció ötre korlátozódik.
A korlátozók a hívó valódi címét a proxy továbbító fejléceiből olvassák, és ezek beállítására csak magát a proxyt tekintjük hitelesnek. E beállítás nélkül minden kérés úgy látszana, mintha a proxytól érkezne, és egyetlen keretet osztana mindenki – ez a védelmet üzemszünetté változtatná.
A fordított proxy az alkalmazás előtt további összesített forgalomkorlátot alkalmaz, így a forgalom már azelőtt korlátozódik, hogy elérné az API-t.
A beérkező adatokat a kiszolgáló az üzleti logika elérése előtt ellenőrzi, a hibákat pedig szerkesztett üzenetként adjuk vissza: hívási verem, adatbázisüzenet és belső elérési út nem jut el a klienshez.
10. Nyugalmi állapotban lévő adatok
Az adatbázis és a Redis kizárólag a belső hálózaton található, és csak az API-tól fogad kapcsolatot; egyik sincs kitéve az internetnek.
Az objektumtároló a tárolt fájlokat nyugalmi állapotban titkosítja, a tároló pedig nyilvánosan nem olvasható.
Rendszeresen készítünk mentéseket, és a visszaállításukat teszteljük. Az előfizetés végén törölt adat a mentésekből azok szokásos rotáció szerinti lejáratával tűnik el, addig pedig más célra nem használjuk fel őket.
11. Naplózás és visszakövethetőség
Az alkalmazás kiszolgálónaplókat ír, és minden munkaterülethez tevékenységnaplót vezet arról, melyik felhasználó mit és mikor változtatott. A napló az alkalmazáson belül az előfizető számára látható.
A kiszolgálói, alkalmazás- és biztonsági naplókat 90 napig őrizzük meg, kivéve, ha egy adott bejegyzést folyamatban lévő biztonsági vizsgálat miatt tovább kell tartanunk.
A naplók a szolgáltatás üzemeltetését és az incidensek kivizsgálását szolgálják. Jelszót, munkamenet-tokent és bankkártyaadatot nem naplózunk.
12. Üzemeltetés
Az éles rendszerekhez és az éles adatokhoz csak azok a munkatársak férnek hozzá, akiknek erre az üzemeltetéshez vagy a támogatáshoz szükségük van, a legszűkebb szükséges jogosultság elve szerint és titoktartási kötelezettség mellett, amely a jogviszony megszűnése után is fennmarad.
A külső függőségek verziói rögzítettek és központilag kezeltek, így egy verzió egy helyen módosul; a platform és a függőségei biztonsági frissítéseit a megjelenésüket követően alkalmazzuk.
Az adatbázis sémaváltozásait verziózott migrációkként, a szolgáltatás indulásakor alkalmazzuk, így az éles séma mindig megegyezik a rajta futó kóddal.
13. Szolgáltatók
Azokat a szolgáltatókat, amelyek a nevünkben adatot kezelnek – tárhely, objektumtároló, e-mail kézbesítés, fizetés és számlázás –, szerepükkel és régiójukkal együtt a GDPR tájékoztató 5. pontja és az adatfeldolgozási tájékoztató 8. pontja nevezi meg.
Új szolgáltató igénybevételét legalább 30 nappal az adatkezelés megkezdése előtt bejelentjük, hogy a kifogást emelő előfizetőnek legyen ideje lépni.
14. Incidenskezelés
Az adatvédelmi incidensekről belső nyilvántartást vezetünk, és az észlelést, értékelést, elhárítást és bejelentést lefedő eljárásrendet követünk.
Ha az incidens valószínűsíthetően kockázattal jár a természetes személyek jogaira és szabadságaira nézve, indokolatlan késedelem nélkül, és ha lehetséges, a tudomásszerzéstől számított 72 órán belül értesítjük az illetékes felügyeleti hatóságot (GDPR 33. cikk); magas kockázat esetén az érintetteket is közérthető nyelven tájékoztatjuk (GDPR 34. cikk).
Amikor adatfeldolgozóként járunk el, a tudomásszerzést követően indokolatlan késedelem nélkül értesítjük az adatkezelőként eljáró előfizetőt, és segítjük a saját bejelentési kötelezettségei teljesítésében.
15. Amivel nem rendelkezünk
Online szolgáltatás nem tehető teljesen biztonságossá. Ez az oldal intézkedéseket ír le, nem garanciákat, és az Általános Szerződési Feltételek sem rendelkezésre állási, sem szolgáltatásszintű vállalást nem tartalmaznak.
Nem rendelkezünk ISO/IEC 27001 tanúsítvánnyal és SOC 2 jelentéssel, és a szolgáltatás nem esett át független behatolásvizsgálaton. Ha ezek bármelyike megváltozik, azt ebben a pontban fogjuk közölni.
A felhasználói fiókokhoz kétfaktoros hitelesítés egyelőre nem érhető el. A fiók biztonsága ezért a jelszó erősségén, a fiókzároláson és a fent leírt forgalomkorlátokon nyugszik – ezért kérjük, hogy a jelszó máshol ne legyen használatban.
A szolgáltatás egyetlen régióban fut, régiók közötti átállás nélkül: ha ez a régió kiesik, a szolgáltatás a helyreállásáig nem érhető el. Azért nevezzük meg, mert az a biztonsági nyilatkozat, amely csak az erősségeket sorolja, döntés megalapozására alkalmatlan.
16. Sebezhetőség bejelentése
Ha sebezhetőséget talál, kérjük, írjon a info@ravsolutions.eu címre a leírással, a reprodukálás lépéseivel és az érintett címmel. A beérkezést visszaigazoljuk, és megírjuk, hogyan kívánjuk kezelni.
Kérjük, adjon ésszerű lehetőséget a hiba javítására a nyilvánosságra hozatal előtt. A vizsgálat során ne férjen hozzá, ne módosítson és ne töröljön olyan adatot, amely nem az Öné, ne rontsa mások szolgáltatását, és ne alkalmazzon megtévesztésen alapuló módszereket a munkatársainkkal vagy a szolgáltatóinkkal szemben.
Fizetett hibavadász programot nem működtetünk. A jóhiszeműen és a fenti kereteken belül eljáró bejelentővel szemben nem lépünk fel.
17. A nyilatkozat változásai
Ezt a nyilatkozatot a szolgáltatással együtt tartjuk naprakészen. Az oldal tetején szereplő verziószám és hatálybalépési dátum mutatja, melyik szöveg van hatályban; a korábbi változatok kérésre elérhetők.
Ha az itt leírt intézkedések valamelyike megváltozik, ez az oldal is változik vele. A tartalommal kapcsolatos kérdéseket a info@ravsolutions.eu címre lehet küldeni.