Biztonság

Minden szervezet adata adatbázis-szinten van elzárva a többitől (PostgreSQL row-level security). A böngésződből induló lekérdezéseknél nem az alkalmazás dönti el, ki mit lát: a jogosultság a lekérdezés szintjén dől el, így ott egy alkalmazáshiba sem tud másik szervezet adatát visszaadni.

Ameddig ez a garancia tart: a szerver-oldali útvonalaink (mind a 20) szolgáltatói kulccsal dolgoznak, az pedig az adatbázisban megkerüli a sor-szintű védelmet. Azokon az útvonalakon a jogosultságot az alkalmazás kódja dönti el — ezért futtatjuk ellenük a lenti támadási készletet, és ezért naplózunk minden írást.

Az elkülönítést automatizált támadási tesztkészlettel ellenőrizzük: 41 kísérlet fut egy idegen szervezet adatai ellen — olvasás 21 táblán, írás 8 táblába, 4 szolgáltatás-belső tábla olvasása, 3 kísérlet a bizonyíték-tároló ellen (a fájl közvetlen letöltése, aláírt (időkorlátos) URL kérése rá, a szervezet bizonyíték-mappájának kilistázása), valamint 5 nevesített kísérlet: idegen szervezet nevének átírása; idegen kérdőív átírása; 'system' (rendszer által tanúsított) naplóbejegyzés írása kliensből; a naplózott szerző nevének meghamisítása; idegen EIR törlése. Minden kísérletnek el kell buknia.

Amink nincs: a próba lefuttatása nem gépi kiadási kapu. Nincs folyamatos integrációnk és nincs telepített verziókezelő-horog, ami a telepítést megállítaná — a készletet a kiadás előtt kézzel futtatjuk (npm run prerelease). Külső fél által végzett behatolási vizsgálatunk sincs; a fenti szám a saját mérésünk.

A napló hash-láncolt: minden bejegyzés tartalmazza az előző ujjlenyomatát. Ha bárki utólag módosítana vagy kivenne egyet, a lánc megszakad, és ez kimutatható. A bejegyzések nem módosíthatók és nem törölhetők — adatbázis-szintű trigger tiltja; a javítás is új, önálló bejegyzésként kerül a láncba. A napló végérőlvaló csonkolást önmagában a lánc nem mutatná meg (a maradék lánc ép volna), ezért a bejegyzésszámot és az utolsó ujjlenyomatot a naplón kívül, külön horgonyban is rögzítjük, és a napi ellenőrzés ezt is összeveti.

A tiltásnak két, szándékos kivétele van — jobb, ha tőlünk tudod meg. A fiók törlésekor a bejegyzésből kiürül a szerző azonosítója (a szerző neve szövegesen megmarad, és minden más mező érintetlen); mivel az ujjlenyomat az azonosítót nem tartalmazza, ezt a lánc nem is jelezné. A másik: a szervezet teljes törlésekor a naplója is megszűnik — élő szervezetnél viszont egyetlen bejegyzés sem törölhető. Minden más módosítás és törlés elutasításra kerül.

AMIT NEM BIZONYÍT. A horgony ugyanabban az adatbázisban él, mint maga a napló: az adatbázis rendszergazdai jelszavával (superuser) a bejegyzések és a horgony is átírható. Ez a horgony tehát NEM külső tanú, hanem a szolgáltatói kulcstól elzárt második példány; valódi külső tanú csak másik bizalmi tartományban (más szolgáltatónál vagy időbélyeg-szolgáltatásnál) volna, ilyet ma nem üzemeltetünk. A trigger tiltásának két szándékos kivétele is van: a fiók törlésekor a bejegyzésből kiürül a szerző azonosítója (a neve szövegesen megmarad, és ezt a lánc nem is jelezné, mert az ujjlenyomat az azonosítót nem tartalmazza), a szervezet teljes törlésekor pedig a naplója is megszűnik. Amit tehát vállalunk: a beavatkozás nem marad észrevétlen — nem az, hogy lehetetlen.

A tényt állító bejegyzéseket (állapotváltás, bizonyíték-feltöltés, átminősítés) kizárólag a szerver állíthatja elő, a tényleges adatírás mellékhatásaként — a felhasználó közvetlenül nem tud ilyet beírni. Egy adat és a hozzá tartozó naplóbejegyzés egyetlen tranzakcióban születik, tehát nem válhat szét.

A lánc épsége bármikor, egy kattintással ellenőrizhető a felületen — az ügyfél és a meghívott auditor is le tudja futtatni. Emellett naponta automatikusan is ellenőrizzük.

Kétlépcsős azonosítás (TOTP) minden fiókhoz. Ha a felhasználó bekapcsolta, a kód megadása nélkül az adatbázis szintjén sem olvashat és nem írhat szervezeti adatot — nem csak a felületen van letiltva. Ez a kapu ma 20 táblán ül: a böngészőből egyáltalán elérhető táblák közül mindegyiken, amelyben ügyféladat van. A két kivétel globális tartalom (a kontroll-könyvtár és a jogszabályi jogcím-katalógus), amelyet minden szervezet ugyanúgy olvas. A lefedettséget nem névsor őrzi, hanem a jogosultságokból számolt határ: ha egy új tábla elérhetővé válik a böngésző számára, a kapu automatikusan ráül, és a kimaradás külön próbát buktat.

Az auditor szerepkör csak olvasni tud, szintén adatbázis-szinten kikényszerítve. A jelszavakat a hitelesítési szolgáltató nem tárolja: csak a bcrypt-hasításukat — ez egyirányú hasítófüggvény, nem titkosítás, nincs hozzá visszafejtő kulcs. Mi magunk sosem látjuk őket. A jelszó legalább 8 karakter; ezt a felület kényszeríti ki mindhárom helyen, ahol jelszó állítható (regisztráció, jelszócsere, helyreállítás). Összetettségi követelményt (nagybetű, szám, jel) nem írunk elő.

A hozzáférés visszavonása csak naplózva lehetséges: a nyers törlési útvonal le van zárva, a bejegyzés pedig a szerverről olvasott nevet és szerepkört rögzíti, nem a kliens által küldött szöveget. A bejelentkezéseket, a 2FA ki- és bekapcsolását, valamint a jelszócserét naplózzuk.

A sikertelen belépésekről — pontosan: a saját belépőlapunkon történő próbálkozásokat jelezzük, és küszöb felett riasztunk (IP-nként és összesítve is). Ez a jelzés viszont a böngészőből érkezik, hitelesítés nélkül: önmagában nem bizonyítja, hogy a kísérlet megtörtént — és aki közvetlenül a hitelesítési szolgáltató felületének próbálgat jelszavakat, azt mi nem látjuk. Ellene a szolgáltató saját, szerver-oldali sebességkorlátja véd, és az ő auth-naplójában látszik. A saját ütemkorlátaink példányon belüli memóriában élnek, tehát több párhuzamos szerver-példány esetén példányonként számolnak.

A feltöltött bizonyítékok privát tárolóba kerülnek, szervezetenként elkülönítve. A korlátokat a tároló maga kényszeríti ki, nem a böngésző: fájlonként legfeljebb 15 MB, és csak engedélyezett típusok (kép, PDF, Word, Excel, PowerPoint, szöveg).

Feltöltéskor a böngésződ SHA-256 ujjlenyomatot számol a fájlról, és ez a lenyomat kerül a naplón keresztül a hash-láncba. Ez a lenyomat a feltöltés pillanatában rögzített állapotot tanúsítja. A szerver ezen felül maga is megméri: letölti a fájlt a tárolóból, újraszámolja a SHA-256-ot, és összeveti a bejelentettel — az eredmény (egyezik vagy nem egyezik) külön, a rendszer által írt naplóbejegyzésbe kerül. Emellett a szerver a fájl méretét és a tároló által számolt eTag/MD5 értékét is rögzíti; a bejelentett és a ténylegesen tárolt méret eltérése esetén a rögzítés elutasításra kerül.

A szerver mérése a feltöltés után, külön lépésben fut, ezért késhet, sőt a feltöltéshez kapcsolt indítása el is maradhat (hálózati hiba, idő előtt bezárt lap). Ilyenkor a bizonyíték érvényesen rögzül, de „még nem ellenőrzött” állapotban marad. Ezt nem hagyjuk így: a napi önellenőrzés a szerverről is elvégzi a mérést minden olyan bizonyítékon, amelynél egy órán belül nem történt meg — futásonként legfeljebb 20 fájlon, a legrégebbivel kezdve. A korábban, még a szerver-oldali mérés bevezetése előtt feltöltött bizonyítékokat is ez a söprés méri be; a naplóbejegyzésük nem íródik át, az eredmény önálló, új bejegyzésként kerül a láncba.

Amit ez nem jelent: a „24 órán belül megmérjük” feltételes ígéret. Attól függ, hogy a napi önellenőrzés lefut-e, hogy a fájl letölthető-e a tárolóból, és hogy a várakozó sorok száma befér-e a napi keretbe. Ha bármelyik nem teljesül, a bizonyíték „még nem ellenőrzött” marad — de nem csendben: a sikertelen mérés, illetve a 48 óránál régebb óta mérés nélkül álló bizonyíték egyaránt nevesített hibaként megy ki az üzemeltetőnek. Ilyenkor a lenyomat kizárólag a feltöltő böngészőjének mérése, szerver-oldali tanúsítás nélkül.

Így az auditor bármikor maga is ellenőrizheti: letölti a fájlt, újraszámolja a SHA-256-ot, és összeveti a naplóban szereplő — utólag nem módosítható — lenyomattal. Egy feltöltött fájlhoz csak egy bizonyíték-bejegyzés tartozhat. Bizonyítékot törölni és felülírni nem lehet: a tároló és az adatbázis is tiltja.

Az adatbázis és a fájltár az Európai Unióban (Írország), a szerver-oldali futtatás Frankfurtban. Ezt bárki ellenőrizheti: a válasz x-vercel-id fejlécében a fra1 jelöli a frankfurti régiót.

A titkosított átvitelt HSTS kényszeríti ki: két éves érvényességgel, az aldomainekre is. A fejléc a preload jelzőt is viseli, de a böngészők előbetöltési listáján a domain ma nincs rajta — a benyújtás feltételei teljesülnek, maga a benyújtás még nem történt meg. Ezt bárki ellenőrizheti a hstspreload.org oldalán. A böngészőben futó kódot szigorú tartalombiztonsági szabály (CSP) korlátozza, és a beágyazás tiltott. Ezek a fejlécek minden válaszban ott vannak — ellenőrizhetők.

Az alvállalkozóinkat (tárhely, adatbázis, levélküldés) névvel, szerepkörrel, a szerződő fél joghatóságával és az adattovábbítás garanciájával tesszük közzé — itt és az adatfeldolgozási megállapodásban. Új alvállalkozó bevonását előre bejelentjük.

A rendszer naponta önellenőrzést futtat: ellenőrzi az adatbázis elérhetőségét, a levélküldést, a határidő-emlékeztető tényleges lefutását és minden napló-lánc épségét, elvégzi az elmaradt bizonyíték-lenyomat méréseket, és magát a riasztási láncot is kipróbálja — így nem csak akkor derül ki, hogy a figyelő elromlott, amikor épp szólnia kellene. Bármelyik hiba azonnali riasztást küld az üzemeltetőnek. Minden kezeletlen szerverhiba is riasztást vált ki.

Rendszeres biztonsági mentés készül, amely a napló-láncok állapotát is rögzíti — így a visszaállított napló épsége utólag is igazolható. A mentés nem adatközpontban, hanem az üzemeltető saját, teljes lemeztitkosítással védett eszközén, Magyarországon tárolódik, tehát az EU-n belül; harmadik fél nem fér hozzá.

Megőrzés — pontosan: a mentőszkript a legutolsó 8 mentés-mappát tartja meg, és a régebbieket törli. A korlát tehát darabszám, nem naptári hét: ha egy héten többször fut, a visszanyúlás rövidebb. Mérve 2026-08-18-án: 8 mappa, közülük hat ugyanarról a napról — a tényleges lefedettség 2026-08-04-től 2026-08-17-ig tartott. A törlési kérelem a mentésekből ennek megfelelően legkésőbb 8 mentés alatt fut ki (adatfeldolgozási megállapodás 5. és 7. pont).

Amit a mentésről tudni kell: egyetlen személy, egyetlen gépen készíti — nincs második másolat és nincs helyettes. A mentés szándékosan nem tartalmaz jelszó-hasht, ezért egy visszaállítás után minden felhasználónak új jelszót kell kérnie. A mentés akkor számít teljesnek, ha a napló-lánc ép volt és minden bizonyítékfájl letöltődött; ha nem, a szkript ezt kiírja és hibával lép ki.

Biztonsági incidens esetén írott eljárásrend szerint járunk el, és az érintett előfizetőket a tudomásszerzéstől számított 72 órán belül értesítjük (adatfeldolgozási megállapodás 6. pont).

Harmadik feles behatolási teszt: még nem volt. Saját, automatizált támadási tesztkészletet futtatunk minden kiadás előtt; független tesztet az első ügyfelek után rendelünk. Ha ez a bevezetés feltétele, mondd el — beütemezzük.

Rendelkezésre állási garancia (SLA): nem vállalunk százalékos garanciát, és ezt az ÁSZF is kimondja. Támogatási válaszidőre sem vállalunk garanciát: a bejelentéseket munkanapokon fogadjuk, és arra törekszünk, hogy a visszaigazolás 1 munkanapon belül megtörténjen (ÁSZF 7.1.) — de ezt nem mérjük órával, és nem kötbérezzük. Amit ezzel szemben fenntartás nélkül vállalunk: az adataid bármikor, önállóan exportálhatók, gépi feldolgozásra alkalmas formában is.

A 90 napos végleges törlés gépi — de előzetes értesítés után. Az előfizetés lezárása után 90 nappal a napi önellenőrzés bejelenti a végleges törlést, és erről a szervezet minden tagja levelet kap: mi fog törlődni, mikor, és hogyan lehet megállítani. A törlés csak a levél kiküldése után 14 nappal hajtódik végre — addig bármikor leáll, ha új előfizetést igényeltek. Levél nélkül a rendszer szándékosan nem töröl: az értesítés hiánya megállítja a végrehajtást, nem elnézi. Ugyanez a mechanizmus viszi végbe az érintetti törlési kérelmet (ÁSZF 5.5.5.) is — egyetlen végrehajtó, egyetlen adatbázis-tranzakció, nyugtával. A futásonkénti darabszám felülről korlátozott: tömeges, váratlan törlés helyett a rendszer megáll és riaszt.

ISO 27001 tanúsítás: a Certandónak magának nincs. A termék segít az ügyfeleinknek a felkészülésben, de nem tanúsítunk, és a tanúsítás sikerét nem garantáljuk.

A jogi dokumentumaink jelenleg „piszkozat” jelöléssel futnak: ügyvédi véglegesítés alatt állnak. A jelölést csak akkor vesszük le, ha a véglegesítés megtörtént.

Ha az átvilágításodhoz kérdőívet, technikai és szervezési intézkedések mellékletet vagy egyedi adatfeldolgozói szerződést kérsz, írj a hello@certando.com címre. A vonatkozó dokumentumok: ÁSZF, adatfeldolgozási megállapodás, adatkezelési tájékoztató, nyílt forráskódú licencek.