Biztonság és megfelelőség
Hitelesítés
Szekció neve “Hitelesítés”- A hozzáférési tokenek rövid élettartamú JWT-k (15 perc), amelyeket az API-átjáró ellenőriz; a frissítési tokenek tétlenség esetén 30 napig, legfeljebb 90 napig élnek, minden használatkor cserélődnek, és HttpOnly, Secure, SameSite sütiben tárolódnak. Egy lecserélt frissítési token újrafelhasználása a teljes láncot visszavonja.
- Az aláíró kulcsok 90 naponként cserélődnek átfedéssel; a nyilvános kulcsok a
/.well-known/jwks.jsoncímen érhetők el. - A jogosultságok nincsenek beágyazva a tokenekbe: minden kérésnél beolvassuk őket, így egy szerepkör-módosítás azonnal érvénybe lép, és bármely munkamenet központilag visszavonható.
- A kétlépcsős hitelesítés (TOTP) lehet opcionális, kötelező a Tulajdonosoknak és Adminisztrátoroknak, vagy kötelező mindenkinek. Az egyszeri bejelentkezés Google Workspace és Apple használatával minden csomagban elérhető. A SAML 2.0, a passkey-k és a SCIM-alapú felhasználókiosztás tervben vannak, és egyelőre nem érhetők el.
- Az API-kulcsok egyszer jelennek meg, SHA-256 hash-ként tárolódnak, hatókörüket egy zárt katalógusból választjuk, a tulajdonosuk jogosultságai korlátozzák őket, és azonnal visszavonhatók. Lásd: Hitelesítés.
- A bejelentkezés IP-címenként és e-mail-címenként sebességkorlátos; tíz sikertelen kísérlet 30 percre zárolja a fiókot; az egy IP-címről érkező sikertelen kísérleteket megszámoljuk és rögzítjük, de az adott címet alapértelmezés szerint nem tiltjuk le. Minden bejelentkezés, sikertelen kísérlet, frissítés, jogosultság-módosítás és adminisztrátori művelet bekerül az auditnaplóba.
Bérlői elkülönítés
Szekció neve “Bérlői elkülönítés”Minden szolgáltatás minden sora tartalmazza azt a fiókot, amelyhez tartozik, és minden lekérdezés automatikusan eszerint szűr; a szűrő kikapcsolásához kifejezett, engedélyezési listán szereplő hívás szükséges, amelyet csak a bérlők közötti munkatársi műveletek használnak, és tesztek fednek le. A webhelyenkénti szerepkörök ezen felül webhelyszűrőt is alkalmaznak. Egy másik fiók erőforrására irányuló kérés 404, soha nem 403 választ kap, így az azonosítók nem sorolhatók fel. Minden író végpont szigorú mező-engedélyezési listát használ. Minden új végponthoz kötelező a fiókok közötti hozzáférés tesztje.
Minden kérés X-Account-Id fejlécét összevetjük a tokennel, így egy klienshiba vagy egy visszajátszott token soha nem olvashatja csendben egy másik bérlő adatait.
Titkosítás
Szekció neve “Titkosítás”TLS 1.2 vagy újabb minden nyilvános végponton, kölcsönös TLS a szolgáltatások között, TLS minden adattárhoz, titkosított kötetek nyugalmi állapotban, valamint fiókonkénti borítéktitkosítás az érzékeny mezőkhöz. A nyilvános tanúsítványok kiállítása és megújítása automatikus; a belső tanúsítványok rövid élettartamúak.
Titkos kulcsok
Szekció neve “Titkos kulcsok”Minden titkos kulcs, beleértve a saját AI-szolgáltatói (BYOK) kulcsaidat és a webhook titkos kulcsokat, egy dedikált titokkezelőben tárolódik, titkosítva, szolgáltatásonként korlátozva és auditálva. Semmi sincs a verziókezelőben (ezt minden commit előtti szkennelés kényszeríti ki), sem a konténerképekben (a CI ellenőrzi). A fejlesztők alapértelmezés szerint nem férnek hozzá az éles titkos kulcsokhoz; a vészhelyzeti hozzáférés két jóváhagyást igényel, rövid ideig érvényes, és egy el nem némítható csatornára naplózódik.
Webhookok
Szekció neve “Webhookok”A kimenő kézbesítések HMAC-SHA256 aláírással rendelkeznek az időbélyeg és a nyers törzs felett, nonce-t és eseményazonosítót hordoznak, az ötperces időablakon kívül elutasításra kerülnek, és visszalépéses újrapróbálkozás után a kézbesíthetetlen üzenetek várólistájára kerülnek. A titkos kulcsok átfedési időablakkal cserélődnek, és azonnal visszavonhatók. A szolgáltatóktól érkező bejövő webhookokat bármilyen feldolgozás előtt az adott szolgáltató sémájával ellenőrizzük. Részletek: Webhookok.
Sebességkorlátozás
Szekció neve “Sebességkorlátozás”Négy réteg: DDoS- és botvédelem a peremhálózaton, IP-címenkénti korlátok a fordított proxyn, fiókonkénti és identitásonkénti tokenvödrök az API-átjárón, valamint tartománykorlátok a szolgáltatásokon belül. A korlátok az API áttekintés oldalon találhatók.
Audit
Szekció neve “Audit”Minden módosítás egy csak hozzáfűzhető, hash-láncolt auditnaplóba íródik, két megőrzési osztállyal: általános események és megfelelőségi események (érintetti kérelmek, adatvédelmi incidensek, alvállalkozói adatfeldolgozók és KYC-rekordok). Az osztályt a bejegyzés írásakor kapja meg; a naplót senki nem szerkesztheti és nem törölheti, az osztályok szerinti automatikus tisztítás pedig még nem működik. A Tulajdonosok és Adminisztrátorok szűrhetik és exportálhatják. Jelszavak, tokenek és kulcsok soha nem kerülnek naplózásra; a naplózási réteg kitakarja az ismerten érzékeny kulcsokat.
Adatvédelem
Szekció neve “Adatvédelem”- A GDPR, az UK GDPR, a CCPA és az LGPD szerinti érintetti kérelmeket (hozzáférés, exportálás, törlés) a megfelelőségi konzolban fogadjuk és követjük határidőkkel. A törlést a RolChat munkatársai végzik, és a kérelem csak akkor zárul le, ha ők ezt megerősítik; az összes modulra kiterjedő automatikus törlés még nem érhető el.
- Adattárolás helye: az adatok az EU-ban tárolódnak. A régiót regisztrációkor nem ország alapján választják; a fiókbeállításokban lévő régióbeállítást csak rögzítjük, adatot még nem helyez át.
- Megőrzés a csomag szerint: 1, 2 vagy 3 év. Egy beszélgetés vagy névjegy törlése a határidő végéig elrejti azt; a fiók törlése egy kérelem 30 napos visszavonási határidővel, utána a munkatársak törlik az adatokat; a ki nem fizetett fiókot 90 napig őrizzük, majd töröljük. Az ezeket a határidőket betartató automatikus tisztítás bevezetés alatt áll.
- Az Adatfeldolgozási megállapodás, az alvállalkozói adatfeldolgozók listája, az adatvédelmi irányelvek és a sütiszabályzat a rolchat.com oldalon érhető el; az Adatfeldolgozási megállapodást a regisztrációkor fogadod el.
- Adatvédelmi incidens bejelentése 72 órán belül, a GDPR 33. cikkének megfelelően.
Sebezhetőségkezelés
Szekció neve “Sebezhetőségkezelés”A függőségeket folyamatosan figyeljük; a lock fájlok a verziókezelőben vannak; az alapképek digest alapján rögzítettek; a CI-műveletek commit alapján rögzítettek. A bétától kezdve évente külső behatolásteszt készül, amely lefedi az API-t, a widgetet és a nyilvános oldalakat, valamint egy feltételezett betörésen alapuló belső forgatókönyvet. Az általános elérhetőséggel egy privát hibavadász-program indul. A biztonsági problémákat a security@rolchat.com címre jelentsd.
Rendelkezésre állás
Szekció neve “Rendelkezésre állás”A platform több csomóponton fut, az állapotmentes szolgáltatásoknál automatikus átállással, az adatbázisoknál felügyelt replikációval. A csomagonkénti rendelkezésreállási célokat a szerződésed tartalmazza.
Incidenskezelés
Szekció neve “Incidenskezelés”Futtatási útmutatók minden szolgáltatáshoz, ügyeleti beosztás, egy külső riasztórendszer, amely akkor is működik, ha a saját infrastruktúránk nem, valamint a folyamatba beépített ügyfél-értesítési kötelezettségek.