Biztonság és adatok
Hol vannak az adatok, hogyan utaznak, ki fér hozzájuk, és mi kerül naplóba.
Kié az adat abban a rendszerben, amit nekünk építetek?
A tiéd. Azért kezeljük, hogy a megrendelt szolgáltatás működjön, semmi másért. Nem kerül közös kupacba egy másik ügyfél adatával, nem adjuk el, és nem használjuk arra, hogy a felhasználóidnak hirdessünk. Ha véget ér az együttműködés, az adatot viszed magaddal.
Hogyan védettek az adatok útközben?
A kapcsolatok HTTP/3-on futnak, a domain pedig rajta van a böngészők előre betöltött HSTS-listáján — a böngésző tehát már a legelső látogatáskor sem hajlandó titkosítatlanul beszélni, még mielőtt bármilyen átirányítást el lehetne téríteni. A kulcscsere posztkvantum: X25519 ML-KEM-768-cal kombinálva, úgy megválasztva, hogy a ma rögzített forgalom akkor is ellenálljon, amikor egy kvantumszámítógép már támadni tudja.
Hogyan tároljátok a jelszavakat, kulcsokat és API-hozzáféréseket?
Soha nem a forráskódban — ezt a build kényszeríti ki, nem a fegyelem: a kódba égetett titkot tartalmazó változtatást visszautasítja, mielőtt beolvadhatna. A titkok titkosítva egy beállítástárban élnek, és futásidőben csak ott fejtődnek vissza, ahol tényleg kellenek. Egy kulcs cseréje így egyetlen helyen egyetlen módosítás, nem keresgélés az egész kódbázisban.
Mi kerül naplóba, és kiderül, ki változtatott meg valamit?
Igen. Az alkalmazásesemények, a hibák és az adminisztrátori műveletek az adatbázisba kerülnek, nem szervereken szétszórt szövegfájlokba, így tényleg kereshetők. Az adminisztratív változtatások rögzítik, ki járt el, mit módosított és mikor. A „ki írta át ezt az árat múlt hónapban” kérdésre válasz van, nem találgatás.
Hogyan kezelitek a sütiket és a hozzájárulást?
A nem feltétlenül szükséges sütik csak a látogató hozzájárulása után kerülnek ki, a döntést rögzítjük, és minden általunk épített oldalon van hely, ahol később módosítható vagy visszavonható. Az elutasítás egy kattintás, nem vadászat egy beállítási menüben — aki pedig elutasít, ugyanúgy működő oldalt kap.