Biztonság és adatkezelés

1. Rendszerarchitektúra és használt technológiák

A rendszer biztonság szempontjából releváns főbb technikai jellemzőit az alábbiak foglalják össze. A bemutatás a külsőleg releváns működésre korlátozódik, a belső forráskód és adatszerkezet részletei nélkül.

1.1. A rendszer jellege és elérése

A QlickCRM webalapú, többbérlős (multi-tenant) SaaS megoldás, amely böngészőből és programozott interfészen (API) keresztül érhető el. Minden ügyfél adatai logikailag elkülönített, saját adatbázisban tárolódnak. A rendszer kizárólag titkosított HTTPS-kapcsolaton érhető el; az adatbázis és a belső szolgáltatások nem nyilvánosan elérhetők, fordított proxy (reverse proxy) mögött működnek.

1.2. Üzemeltetési környezet

A rendszer a DigitalOcean menedzselt felhőszolgáltató környezetében üzemel, amelynek infrastruktúráját az üzemeltetést végző külső szolgáltató kezeli.

1.3. Hálózati protokollok és portok

A biztonság szempontjából releváns hálózati kommunikáció főbb jellemzői:

• Felhasználói és API-forgalom: HTTPS protokollon (TLS 1.2 vagy újabb), a 443-as porton, ez a rendszer egyetlen nyilvános belépési pontja.
• Kimenő e-mail: SMTP protokollon, dedikált e-mail-küldő szolgáltatáson keresztül.
• Bejövő e-mail: titkosított IMAP kapcsolaton, az ügyfél által beállított postafiókok esetén.
• Külső szolgáltatások elérése: kimenő HTTPS-hívásokkal.

A belső komponensek (adatbázis, üzenetsor, fájltároló) privát hálózaton, nyilvános port nélkül működnek.

1.4. Programozott interfészek

A rendszer az alábbi hitelesített interfészeken keresztül érhető el programozottan:

• Belső (tenant) REST API: token alapú (Bearer) hitelesítéssel.
• Publikus API v2: API-kulcs alapú hitelesítéssel; a kulcsok kizárólag hash-elt formában tárolódnak.
• Webhook-fogadók: külső rendszerek felé, ahol a partner támogatja, aláírás-ellenőrzéssel.
• Aláírt, időkorlátos (signed) URL-ek: a fájlok biztonságos kiszolgálásához.

1.5. Külső szolgáltatások

Az alapinfrastruktúra részeként, az adatfeldolgozási láncban folyamatosan közreműködő szolgáltatások: tárhely és üzemeltetés (DigitalOcean), kimenő e-mail-küldés, alkalmazásszintű hibakövetés (Sentry) és fájltárolás (AWS S3).

Az ügyfél által igény szerint aktiválható, csak bekapcsolásuk esetén adatot továbbító integrációk többek között: számlázás (Számlázz.hu, Billingo), naptár (Google Calendar), mesterséges intelligencia (OpenAI), SMS-küldés (BIP), céginformáció (Cégjelző), árfolyamadatok (MNB), valamint webshop-, foglalási és automatizációs integrációk (például Unas, Shoprenter, WooCommerce, Booked4us, Deliveo, Zapier).

2. Fejlesztési életciklus és minőségbiztosítás

A QlickCRM-et strukturált fejlesztési életciklus keretében fejlesztjük és tartjuk karban, amelyben a biztonsági szempontok a folyamat egészén végigvonulnak, nem utólagos kiegészítésként jelennek meg.

2.1. Fejlesztési módszertan és verziókövetés

A fejlesztés iteratív, jegyalapú folyamatban zajlik: minden módosítás egy jegykezelő rendszerben nyilvántartott feladathoz és külön fejlesztői ághoz kötött, így a változások egyértelműen visszakövethetők. A teljes forráskód verziókövetés alatt áll.

2.2. Kódellenőrzés és jóváhagyás

A változások az integrációs, illetve kiadási ágba kizárólag fejlesztői kódellenőrzést (code review) követően, jóváhagyás után kerülnek be. Ez biztosítja, hogy a módosításokat a kiadás előtt egy másik fejlesztő is áttekintse, mind funkcionális, mind biztonsági szempontból.

2.3. Környezetek és kiadáskezelés

Elkülönített fejlesztői, teszt (staging) és éles (production) környezetet üzemeltetünk. A változások az éles bevezetés előtt teszt környezetben kerülnek ellenőrzésre; a teszt környezet anonimizált adatokon működik, így a valós ügyféladatok nem kerülnek fejlesztési-tesztelési célú felhasználásra. A kiadások ütemezett kiadási folyamat keretében történnek.

2.4. Biztonsági szempontok a fejlesztésben

Biztonság-tudatos, alapértelmezetten védő (secure-by-default) keretrendszerre építünk, a kódolási irányelvek és a lentebb részletezett védelmi mechanizmusok mentén. Az éles működést folyamatos hibamonitorozás kíséri, amelynek észlelései visszacsatolnak a fejlesztési és javítási folyamatba.

3. Hozzáférés-védelem és kétfaktoros azonosítás

A felhasználói fiókok védelmének megerősítése érdekében a rendszer kötelező kétfaktoros azonosítást (2FA) alkalmaz. A bejelentkezés során a felhasználói azonosító (e-mail cím) és a hozzá tartozó jelszó megadása mellett minden esetben egyszer használatos hitelesítő kódot is megkövetelünk.

A hitelesítő kód a felhasználói fiókhoz rendelt, a rendszerben rögzített e-mail címre érkezik. Ennek köszönhetően a sikeres belépéshez nem elegendő pusztán a jelszó ismerete, hanem az adott e-mail postafiók feletti rendelkezés is szükséges. Így a jelszó esetleges illetéktelen megszerzése esetén is megakadályozható a fiókhoz történő jogosulatlan hozzáférés.

4. Naplózás

A rendszer üzemeltetése és működése során több, egymástól funkcionálisan és hozzáférés-szempontból elkülönülő naplózási réteget alkalmazunk. Az egyes naplók eltérő célt szolgálnak, ennek megfelelően a hozzáférési jogosultságok és a tárolási környezetek is külön-külön szabályozottak.

4.1. Szerverüzemeltetési naplózás

A kiszolgáló infrastruktúra szintjén keletkező naplóbejegyzések (különösen az operációs rendszer-, webszerver-, adatbázis-szerver- és hálózati eseménynaplók) az üzemeltetést végző külső szolgáltató környezetében keletkeznek és tárolódnak. Ezekhez kizárólag a szerverüzemeltetést végző szolgáltató arra jogosult személyzete fér hozzá, az infrastruktúra felügyeletéhez és üzemszerű karbantartásához szükséges mértékben.

4.2. Alkalmazásszintű hibanaplózás

Az alkalmazási rétegben jelentkező hibákat és figyelmeztetéseket a Sentry (sentry.io) valós idejű hibakövető szolgáltatásán keresztül rögzítjük. Az így keletkező naplóbejegyzések a hibák azonosítását, reprodukálását és kijavítását teszik lehetővé, ezzel támogatva a rendszer folyamatos minőségbiztosítását. Ezen adatokhoz a fejlesztésben részt vevő munkatársaink, valamint a titoktartási kötelezettséggel terhelt alvállalkozóink férhetnek hozzá.

4.3. Felhasználói tevékenységnapló

Az ügyfél saját QlickCRM-fiókján belül zajló felhasználói tevékenység meghatározott körét naplózzuk. Ezek a bejegyzések közvetlenül az ügyfélhez tartozó, elkülönített adatbázisban tárolódnak, biztosítva a többbérlős (multi-tenant) környezetben az adatok ügyfelek közötti elkülönítését. A tevékenységnaplóhoz két csatornán keresztül lehet hozzáférni:

• Ügyféloldalról: a rendszerben erre a célra kialakított felületen, jogosultsághoz kötött módon. Az ügyfél saját szervezetén belül szabályozhatja, hogy mely felhasználói körök férhetnek hozzá a naplóbejegyzésekhez.
• Szolgáltatói oldalról: kizárólag a kiszolgáló oldali (backend) felületeken, arra felhatalmazott munkatársaink, illetve titoktartással terhelt alvállalkozóink részére, üzemeltetési vagy hibakeresési célból.

5. Titkosítás

Az adatok bizalmas jellegének és sértetlenségének biztosítása érdekében több rétegben alkalmazunk titkosítási eljárásokat. Az adatok mind a hálózati átvitel során, mind a háttértáron tárolt (nyugalmi) állapotban titkosítva vannak.

5.1. Adatátvitel titkosítása

A kliens (böngésző, mobilalkalmazás vagy API-kliens) és a szervereink közötti teljes adatforgalom TLS 1.2 vagy újabb verziójú protokollon (HTTPS) zajlik. A titkosítás kiterjed a felhasználói bemenetekre, a megjelenített tartalomra és az API-hívásokra egyaránt, kizárva ezzel a hálózati szintű lehallgatás, valamint a továbbított adatok illetéktelen módosításának (man-in-the-middle típusú támadások) lehetőségét.

5.2. Érzékeny adatok kriptográfiai védelme

A felhasználói jelszavakat semmilyen körülmények között nem tároljuk eredeti, visszafejthető (plaintext) formában. A jelszavak Bcrypt egyirányú jelszó-hash algoritmussal kerülnek tárolásra, amelynek beépített „salt” mechanizmusa és állítható számítási költsége ellenállóvá teszi az algoritmust a tömeges, szótár- és szivárványtábla-alapú támadásokkal szemben. Az alkalmazás-szinten kezelt API-kulcsok és hozzáférési tokenek SHA-256 hash-eléssel tárolódnak, így azok eredeti értéke a tárolt adatból szintén nem visszafejthető.

5.3. Adatbázis nyugalmi titkosítása

Az adatbázis egy menedzselt felhőszolgáltató környezetében működik, amely a tárolt adatok teljes körű, blokk-szintű, nyugalmi (at-rest) titkosítását biztosítja. Ennek köszönhetően a háttértár fizikai vagy logikai szintjén keletkező adatállományok, valamint a háttérben automatikusan készülő mentések és állapotképek (snapshotok) is titkosított formában találhatók meg.

6. Konfiguráció- és változáskezelés

A rendszer konfigurációját és változásait a teljes életciklus során kontrollált, visszakövethető módon kezeljük.

6.1. Változások nyilvántartása és nyomon követése

Minden módosítás verziókövetés alatt és nyilvántartott feladathoz (jegyhez) kötve történik. Az adatbázis szerkezetét érintő változások verziózott migrációkként dokumentáltak, így a változások a tervezéstől az éles bevezetésig végponttól végpontig visszakövethetők.

6.2. Szoftverelemek sértetlensége

A forráskód teljes egészében verziókövetés alatt áll, a felhasznált külső függőségek pedig rögzített verziókra vannak kötve, biztosítva a szoftverelemek sértetlenségét és reprodukálhatóságát. Az éles környezetbe kizárólag a kontrollált forrásból, a kiadási folyamaton keresztül kerül kód; eseti, kézi módosítás az éles rendszeren nem történik.

6.3. Változások hatásának kezelése és tájékoztatás

A változások biztonsági hatását a bevezetés előtt mérlegeljük. A rutinszerű fejlesztések és karbantartások kontrollált, ütemezett kiadások keretében jelennek meg. Ha egy tervezett változtatás a rendszer biztonságos működését vagy a szolgáltatott funkcionalitást érdemben, negatív irányban érintené, a bevezetés előtt előzetes tájékoztatást nyújtunk az érintett ügyfeleknek a vonatkozó biztonsági hatás bemutatásával.

7. Biztonsági tesztelés és sebezhetőség-kezelés

A rendszer biztonságának fenntartását nem egyszeri tesztelési feladatként, hanem a fejlesztési és üzemeltetési folyamatok szerves részeként kezeljük. A védelmi mechanizmusok kialakítása során kiemelt figyelmet fordítunk az OWASP Top 10 listán szereplő, legelterjedtebb webalkalmazás-sebezhetőségek elleni védekezésre.

7.1. Keretrendszer- és kódszintű védelmi mechanizmusok

A rendszer alapját képező Laravel keretrendszer számos OWASP Top 10 típusú sebezhetőség elleni védelmet keretrendszer-szinten biztosít, amelyeket kódolási irányelveink és a fejlesztői ellenőrzések (code review) tovább erősítenek. A főbb védelmi rétegek:

• SQL injection elleni védelem: kizárólag paraméterezett (prepared) adatbázis-lekérdezések használata, az SQL-utasítások közvetlen szövegszintű összefűzésének tiltása.
• Cross-site scripting (XSS) elleni védelem: a felhasználói bemenetek és a megjelenített tartalom konzekvens output escape-elése a sablonmotor szintjén.
• Cross-site request forgery (CSRF) elleni védelem: munkamenethez kötött CSRF-tokenek automatikus alkalmazása valamennyi állapotváltozást eredményező kérésnél.
• Jogosultság-kezelési hibák megelőzése: az API-végpontok szintjén minden hívásnál explicit jogosultság-ellenőrzés történik, megakadályozva mind a horizontális (másik ügyfél adataihoz), mind a vertikális (magasabb jogosultsági szinthez tartozó funkciókhoz) jogosulatlan hozzáférési kísérleteket.
• Érzékeny adatok védelme: kriptográfiailag aláírt (signed) URL-ek alkalmazása a manipulálható erőforrás-azonosítók helyett, valamint az érzékeny adatok titkosított csatornán és titkosított formában történő kezelése.
• Visszaélések és túlterheléses kísérletek korlátozása: rate limiting a kritikus végpontokon (különösen a bejelentkezés, a jelszó-helyreállítás és a nyilvános API-felületek esetében), amely érdemben megnehezíti a brute force jellegű támadásokat.

7.2. Ismert sebezhető komponensek kezelése

A használt szoftverkomponenseket és külső függőségeket rendszeresen frissítjük, és sebezhetőség-szkennernek vetjük alá. A felfedezett, magas vagy kritikus súlyosságú sebezhetőségek 7 napon belül javításra kerülnek; ha az érintett komponens cseréje szükséges, az a fejlesztési folyamatba ütemezetten kerül beillesztésre, így a rendszer biztonsági állapota folyamatosan fenntartható.

7.3. Időszakos penetrációs tesztelés

A keretrendszer- és kódszintű védelem kiegészítéseként időszakos penetrációs teszteléssel ellenőrizzük a rendszer biztonsági állapotát. A penetrációs tesztek célja a valós támadási vektorok, különösen az üzleti logikán alapuló sebezhetőségek, a jogosultság-bypass kísérletek és a munkamenet-kezeléssel összefüggő problémák feltárása, amelyek automatizált eszközökkel önmagukban nem mindig kimutathatók.

7.4. Tesztelési terv és az eredmények dokumentálása

A keretrendszer- és kódszintű védelem, a függőségek sebezhetőség-vizsgálata és az időszakos penetrációs tesztelés együttesen alkotják a tervezett, többrétegű biztonsági tesztelési megközelítésünket. A vizsgálatok eredményeit dokumentáljuk, az azonosított sérülékenységeket súlyosság szerint osztályozzuk, és az alábbi javítási határidőkön belül kezeljük.

8. Hibakezelés, sérülékenység-jelentés és támogatás

A bejelentett hibákat és sérülékenységeket kontrollált, nyomon követhető és auditálható folyamatban kezeljük.

8.1. Bejelentés, követés és validálás

A hibák és sérülékenységek a kapcsolattartási, illetve támogatási csatornáinkon keresztül jelenthetők be. Minden bejelentést nyilvántartásba veszünk, a javítást a megoldásig nyomon követjük, és a javítás éles bevezetése előtt annak helyességét ellenőrizzük (validáljuk). A folyamat a változáskezeléssel összhangban dokumentált és utólag ellenőrizhető (auditálható).

8.2. Javítási határidők

A bejelentett és az azonosított sérülékenységek súlyossági besorolását minden esetben mi végezzük. A besorolt sérülékenységek javítását az alábbi határidőkön belül végezzük el:

8.3. Támogatás

A támogatás (support) elérhetőségére, válaszidőire és rendelkezésre állására vonatkozó feltételeket az Általános Szerződési Feltételek tartalmazzák.

9. Kritikussági elemzés

A rendszer biztonság szempontjából kritikus elemeit, különösen a hitelesítést, a bérlők közötti adatizolációt, a titkosítást és a jogosultságkezelést az életciklus során, a releváns döntési pontokon (tervezés, jelentős változások, kiadások) azonosítjuk és értékeljük. Ez a kritikussági mérlegelés a változások hatásvizsgálatának és a biztonsági tesztelésnek a részeként valósul meg.

A kritikussági értékelés belső folyamataink része; a kapcsolódó elemzések és megállapítások belső felhasználásúak. Az érintett ügyfelet akkor tájékoztatjuk a vonatkozó információkról, ha egy konkrét ügy, különösen a biztonságos működést érdemben érintő változás, ezt indokolttá teszi.

10. Technikai változások és tájékoztatás

Folyamatosan fejlesztjük a rendszert működtető technikai paramétereket annak érdekében, hogy a szolgáltatás minőségét, stabilitását és biztonságát javítsuk. A rutinszerű technikai változtatásokról nem minden esetben adunk előzetes tájékoztatást; ha azonban egy tervezett módosítás a rendszer stabilitását vagy biztonságos működését érdemben, negatív irányban érintené, a bevezetés előtt tájékoztatjuk az érintett ügyfeleket.

Ez az oldal a kiadás napján legjobb tudomásunk szerint hűen tükrözi a QlickCRM technikai és informatikai biztonsági paramétereit, és az Általános Szerződési Feltételekkel együtt értelmezendő.