Biztonság és bizalom
Ellenőrizhető biztonság — nem csak ígéret.
Az OPEREX szabályozott, folyamatos üzemű üzemeknek készül, ahol az üzemeltetési nyilvántartásnak ki kell állnia egy auditot. Itt van, ami MA védi az adataidat — mérve, nem vágyakozva —, és ugyanilyen nyíltan az is, amit még NEM állítunk.
Ami ma védi az adataidat
Hozzáférés és azonosítás
- Meghívásos hozzáférés — nincs nyilvános önregisztráció; minden fiók a tenantjával és szerepével együtt jön létre.
- Kétfaktoros hitelesítés (TOTP) minden felhasználónak bekapcsolható, a platform-adminoknak kötelező. A minimumot az OPEREX tenantonként állítja (senki · a rendszergazdák · mindenki — minden új tenantnál alapból a rendszergazdák), a szervezet ennél szigorúbbat maga is beállíthat, gyengébbet nem. A kényszer minden kérésre hat (űrlap-beküldésre is), egy kód kétszer nem használható, a kikapcsoláshoz, a helyreállító kódok cseréjéhez, a szabály leengedéséhez és egy kolléga kétfaktorának visszaállításához friss második faktor kell. A kikapcsolásról és a visszaállításról a fiók gazdája e-mailes értesítést kap, a visszaállítás pedig minden munkamenetét is lezárja.
- Szerep-alapú jogosultság, fail-closed — még a super-admin sem léphet át tenant-határt (teszttel igazolva).
- A modulokhoz való hozzáférés szerepenként dől el: modul-hozzáférés nélkül a szerep a modul egyetlen funkcióját sem használhatja, bármilyen egyedi jog van beállítva. A delegált adminisztráció plafonja a delegált saját szintje — aki meghívhat vagy telephelyet oszthat, csak a sajátjánál nem tágabb szerepet és csak a számára is elérhető telephelyet adhat (teszttel igazolva).
- Szerver-oldali token-ellenőrzés minden kérésnél; a szerep és a tenant az adatbázisból jön, sosem kliens-mezőből.
- Egy munkamenet annyi ideig él, amennyit a szervezet beállít — alapból 8, legfeljebb 13 óra (12 órás műszak + átadás); az idő a belépéskor indul, a használat nem hosszabbítja. A hosszabbításhoz a rendszergazdától friss második faktor kell. A jelszócsere vagy -visszaállítás minden MÁS bejelentkezett munkamenetet azonnal lezár — a munkamenetek a szerveren vonódnak vissza, nem csak kifutnak.
- Rate-limit a belépésen, a jelszó-reseten és a feltöltéseken (alkalmazás-szinten), az éles kiszolgálón a hálózati élen is.
- Kilépéskor deaktiválás — a hozzáférés megszűnik, az auditnyom sértetlen marad.
Tenant-izoláció — két független réteg
- Minden tenant-scoped lekérdezés az alkalmazás kódjában is EXPLICIT módon a tenantra szűr.
- Adatbázis-szintű Row-Level Security (FORCE RLS), futásidőben egy BYPASSRLS nélküli szerepen kikényszerítve — egy kihagyott szűrőt is elfog az adatbázis, és az állapot-ellenőrzés az élő kapcsolaton is méri ezt a szerepet.
- A fedettséget minden deploy kapuzza: egy RLS nélküli tábla — vagy egy bérlő-policy, ami nem pontosan a saját tenantra szűr — megállítja a deployt.
- A cross-tenant izoláció két valódi tenanttal mérve, és a CI minden tenant-scoped táblán megkísérel egy idegen bérlőbe írást (mutációval igazolva).
- Az auditnyom append-only, és a módosítását/törlését az adatbázis MINDEN szerepkörnek megtagadja — annak a tulajdonosi fióknak is, amivel mi üzemeltetünk. A jogszerű, szerződés szerinti törlés kimondott, naplózott eljárás, nem egy csendes UPDATE.
- Naponta az előző nap auditnyomának — valamint a munkavégzési engedélyek és a karbantartási munkalapok aláírásainak — bérlőnkénti ujjlenyomata láncolva, a szerveren kívül tárolódik, így egy már rögzített nap utólagos módosítása, akár tulajdonosi joggal az adatbázison belül, kimutatható. Minden aláírás-lánc feje a rekordon is áll, így a lánc végéről levágott aláírás is kiderül.
- Éjszakánként és minden összevonási kérésnél automatikus dinamikus vizsgálat (OWASP ZAP) fut az alkalmazás produkciós buildje ellen, azt mérve, amit a böngésző ténylegesen megkap: biztonsági fejlécek, süti-jelzők, cache-direktívák, információ-szivárgás. Egy találat megállítja az összevonási kérést, és minden elfogadott kivétel mellett ott az írásos indok.
Adat és rezidencia
- Az éles üzem saját, dedikált kiszolgálón fut, a demó- és teszt-környezettől teljesen elválasztva — külön gép, külön titkok, külön titkosított kötet.
- Önhosztolt adatbázis és objektumtár EU (Hetzner) infrastruktúrán — nincs harmadik-fél adatbázis-szolgáltatás közted és az adatod között.
- Az elsődleges tárolási hely az EU (Németország). A tranzakciós e-maileket egy USA-beli szolgáltató (Resend) kézbesíti, az off-szerver mentést a Cloudflare tárolja — mindkettő az EU–USA Adatvédelmi Keret (DPF) alatt.
- Az éles kiszolgálón az adatbázis, a fájltár és a helyi mentések is titkosított köteten (LUKS) vannak; a jelszavak mindenhol hash-eltek, a kétfaktoros kulcsok titkosítottak.
- Off-szerver mentés 6 óránként, SHA-256 visszaolvasással ön-verifikálva, 90 napos heti szinttel. Az éles kiszolgáló mentése EU-joghatóságú tárolóba megy; a megosztott demó/teszt környezeté nem.
- 2026. szeptember 25. óta az off-szerver adatbázis-mentést, a heti szintet, a log-pillanatképeket és a konfigurációs csomagot még a saját kiszolgálónkon titkosítjuk a feltöltés előtt (age): ott csak a publikus kulcsok vannak, a privát kulcs a kiszolgálón kívül, jelszókezelőben és lepecsételt offline példányban áll — a tároló szolgáltató ezeket a mentéseket nem tudja elolvasni. Két kimondott kivétel: a fájltár-tükör objektumonként szinkronizálódik, ott továbbra is a szolgáltatói titkosítás véd, az ezt megelőzően feltöltött másolatok pedig a 30/90 napos megőrzés lejártáig szintén azon állnak.
- A visszaállítást mérjük, nem feltételezzük: 2026. szeptember 9-én egy adatbázis-mentést az off-szerver másolatból egy külön példányba állítottunk vissza — mind a 124 tábla visszajött, a forrással azonos sorszámmal; szeptember 20-án az adatbázis és a fájltár off-szerver másolatát letöltöttük és integritásra ellenőriztük. Szeptember 25-én az éles kiszolgáló saját, titkosított mentését az off-szerver tárolóból letöltöttük és a privát kulcsunkkal visszafejtettük — érvényes adatbázis-mentés jött ki; ez volt az első próba éles adaton. A teljes, tábláról táblára egyeztető visszaállítást eddig csak a megosztott környezeten gyakoroltuk.
- On-premise / air-gapped telepítés enterprise-nek CSOMAGOLVA (telepítő, konténer-compose, vendor-lock nélkül) — az adat el sem hagyja a telephelyet.
Alkalmazás-megkeményítés
- Nincs SQL-injection, tárolt XSS, CSRF, open-redirect, mass-assignment, CSV-injection vagy SSRF — statikus audittal és a javításaival igazolva.
- Minden alkalmazás-oldal Content-Security-Policy-t kap per-kérés nonce-szal (nincs inline szkript), HSTS-t, X-Frame-Options DENY-t (az egyetlen kivétel: az a szervezet, amelynél a nyilvános lakossági bejelentő fokozat be van kapcsolva, a bejelentő űrlapot beágyaztathatja egy weboldalba — csak az általa megnevezett https weboldalakba, legfeljebb tízbe, felső szintű doménre szóló helyettesítő nélkül, és kizárólag arra az egy űrlapra; a státusz-, megerősítő és leiratkozó lap soha nem ágyazható be), nosniff-et, szigorú referrer-szabályt és egy szűkre húzott Permissions-Policy-t, ami kikapcsolja a kamera-, mikrofon-, helymeghatározás- és fizetés-hozzáférést (két kivétel: a mikrofon diktáláshoz — a bejelentkezett alkalmazásban csak ha a szervezet használja a diktálást (az adminja bekapcsolja, alapból KI, vagy a Munkanapló diktálás-beállítása BE), a QR-címkéről elérhető nyilvános terepi bejelentő űrlapon pedig csak bekapcsolt diktálásnál; hibaoldalon soha, a böngésző a felhasználótól külön engedélyt kér, a felismerést a böngésző beépített szolgáltatása végzi, hang hozzánk nem jut; és a karbantartás oldala használhatja a kamerát QR-címke beolvasásához, csak bejelentkezett felhasználónak és csak a böngésző saját engedélykérése után — erre az egy oldalra a szabály a tartalék QR-dekóder miatt a WebAssembly-fordítást is engedi, amelyet a saját kiszolgálónkról töltünk).
- A hitelesített oldalak sosem cache-elődnek (no-store); az alkalmazás ki van zárva a kereső-indexelésből.
- A képfeltöltés szerver-oldalon újrakódolva (WebP, EXIF-strip), méret- és dekompressziós-bomba korláttal.
- Megkeményített infrastruktúra — a belső szolgáltatások localhostra kötve, a publikus tár csak letöltésre, a privát tár csak hitelesített proxyn át érhető el.
- Az elérhetőséget külső felügyeleti szolgáltatás figyeli, öt percenként, riasztással — az alkalmazás állapot-ellenőrzésén át, ami valódi adatbázis-lekérdezést futtat. A felügyelet nem redundancia: lásd lent az „Amin még dolgozunk” szekciót.
Hordozhatóság és adatszuverenitás
- Egy CI-ben kikényszerített tiltólista tartja vendor-semlegesen a kódot — vanilla Postgresen és objektumtáron fut, air-gapped, kód-újraírás nélkül. Az azonosítás ugyanazon adapter-határ mögött van, így egy vállalati azonosító-szolgáltató az üzleti logika érintése nélkül illeszthető be.
- A titkok sosem élnek a repóban; a szerveren generálódnak és ott is maradnak.
Megfelelés, átadás és kilépés
- Adatfeldolgozási megállapodás, amely a 32. cikk szerinti intézkedéseket tételesen felsorolja — nem sablonszöveg.
- Írott incidenskezelési terv súlyossági osztályokkal és 24 órás értesítési vállalással, hogy a te NIS2 23. cikk szerinti határidőid (24 óra korai előrejelzés / 72 óra jelentés) tarthatók maradjanak.
- Az üzemeltetés nem egyetlen emberen múlik: a kijelölt második vészhozzáférő a helyreállításhoz szükséges minden hozzáféréshez hozzáfér — megerősített vészhozzáféréssel beállított jelszószéfen át, sürgős esetben lepecsételt borítékkal —, és írott helyreállítási útmutató szerint jár el. Az eljárást félévente próbáljuk.
- NIS2 beszállítói adatlap: a 21. cikk (2) mind a tíz intézkedésének leképezése arra, amit a termék ténylegesen csinál — a korlátokkal együtt.
- ISO 45001 rekord-kezelés (§7.5) és eseménykivizsgálás (§10.2) támogatása. A szoftver a te megfelelésed eszköze, nem maga a tanúsítvány.
- Kilépéskor teljes adatátadás: minden bérlői adattábla gépi olvasható (NDJSON) és táblázatkezelős (CSV) formában, és maguk a tárolt fájlok (fotók, dokumentumok) is — egyetlen zip-csomagban, fájl-leltárral és fájlonkénti SHA-256 ellenőrzőösszeggel; a leltár néven nevezi azt is, ami szándékosan kimarad, indokkal. A csomagot lejáró, letöltés-számra korlátozott linkkel küldjük az általad megadott címre (7 nap, legfeljebb 5 letöltés), és minden lépést — küldés, megnyitás, letöltés — naplózunk. A csomag a bérlőddel együtt törlődik a szervereinkről.
- Kérésre törlés, igazolással: mit töröltünk, utólag ellenőrizve, és annak az exportnak az ellenőrzőösszegével, amit előtte átadtunk.
- Egy személy törlési kérelme: a te utasításodra álnevesítjük a fiókot (e-mail, utolsó belépés, második faktor titka, belépési adatok — és ha így döntesz, a név is), utólag visszamérjük, és igazolást adunk. Az önkiszolgálóan törölt fiók 30 nap után automatikusan álnevesül; a név a rekordok szerzőjeként marad, hacsak másként nem utasítasz.
Beszállítóként mérsz fel minket a NIS2 miatt?Ha a szervezeted a NIS2 (nálunk: 2024. évi LXIX. tv., Kiberbiztonsági tv.) hatálya alá esik, fel kell mérned az IKT-beszállítóidat. Végigvezettük, hogy az OPEREX mit csinál a 21. cikk (2) tíz intézkedésével szemben, kimondtuk a korlátokat is, és egy lapra tettük — letölthető beszállítói adatlappal.NIS2 beszállítói megfelelés →Hogyan bizonyítjuk, hogy egy aláírt engedélyt nem írtak át?A digitális ujjlenyomat, az aláírás-lánc, a napi, szerveren kívüli rögzítés és a papír élő QR-kódja — egy rövid műszaki összefoglalóban, a határokkal együtt.Digitális ujjlenyomat — hogyan működik →
Amin még dolgozunk
Kimondjuk, hogy egy biztonsági kérdőíven se érjen meglepetés. A részletes válaszokat — kompenzáló kontrollokkal és ütemezéssel — a kérdőív-csomagunk tartalmazza, kérésre.
- Külső penetrációs teszt az első enterprise-bevezetés elé ütemezve.
- ISO 27001 tanúsítvány nincs — az írott, auditálható megfelelői a fenti dobozban.
- Automatikus átállás (failover) még nincs; ma a 6 óránkénti, próbával igazolt mentés véd.
- A fájltár-tükör saját kulccsal az adatbázis-, log- és konfigurációs mentés 2026. szeptember 25. óta kliens-oldalon titkosított; a fájltár-tükör objektumonként szinkronizálódik, ott még a szolgáltató kulcsa véd.
- Vállalati SSO (Entra ID) a következő lépés; az adapter-határ készen áll.
Sérülékenység bejelentése
Biztonsági hibát vagy sérülékenységet találtál az OPEREX-ben? Írj a security@operex.eu címre. A gépi olvasásra szánt kapcsolat: /.well-known/security.txt (RFC 9116).
Mit vállalunk
- Visszaigazolás 3 munkanapon belül.
- Jóhiszemű bejelentés ellen nem lépünk fel jogi úton.
- A javítás után — ha kéred — nevesítünk.
Amit kérünk
- Ne érj hozzá más ügyfelek adataihoz, és ne rongálj adatot.
- Ne futtass terheléses (DoS) tesztet.
- Adj ésszerű időt a javításra a nyilvánosságra hozatal előtt.
Mennyire naprakész ez az oldal
Ez az oldal a rendszer MAI állapotát írja le — nem tervet. Minden állítás mögött kódbeli fedezet áll, és a buildünk elbukik, ha egy fent felsorolt hiányosság közben megszűnt, de ez a szöveg nem frissült vele.
Jogi és adatvédelem
Az oldalon szereplő állítások mögötti hivatalos dokumentumok:
Van biztonsági kérdés, amit itt nem válaszoltunk meg?
Írj nekünkIndítsunk egy pilotot
Mutatjuk az OPEREX-et a saját műszaki folyamataitokon — kötöttség nélkül.
Demó kérése