Tovább a tartalomhoz

Biztonság és megfelelőség

  • 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.json cí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.

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.

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.

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.

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.

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.

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.

  • 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.

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.

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.

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.