Безбедност и усогласеност

Автентикација

Access токените се краткотрајни JWT (15 минути), проверени на API портата; refresh токените траат 30 дена без активност и најмногу 90 дена, се ротираат при секоја употреба и се чуваат во HttpOnly, Secure, SameSite колаче. Повторната употреба на ротиран refresh токен го отповикува целиот синџир.
Клучевите за потпишување се ротираат на секои 90 дена со преклопување; јавните клучеви се објавени на /.well-known/jwks.json.
Дозволите не се вградени во токените: се читаат при секое барање, па промената на улогата важи веднаш, а секоја сесија може централно да се отповика.
Двофакторската автентикација (TOTP) може да биде незадолжителна, задолжителна за сопствениците и администраторите или задолжителна за сите. Единствена најава (SSO) со Google Workspace и Apple е достапна во секој план. SAML 2.0, passkeys и SCIM обезбедувањето се планирани и засега не се достапни.
API клучевите се прикажуваат еднаш, се чуваат како SHA-256 хаш, нивните опсези се избираат од затворен каталог, ограничени се со дозволите на сопственикот и може веднаш да се отповикаат. Погледнете Автентикација.
Најавата е ограничена по IP и по е-пошта; десет неуспешни обиди ја заклучуваат сметката 30 минути; неуспешните обиди од една IP-адреса се бројат и се запишуваат, но стандардно таа адреса не се блокира. Секоја најава, неуспех, освежување, промена на дозволи и администраторска акција оди во дневникот за ревизија.

Изолација на клиентите

Секој ред во секој сервис ја носи сметката на која ѝ припаѓа, а секое барање автоматски се филтрира според неа; исклучувањето на филтерот бара експлицитен повик од листата на дозволени, што се користи само за операции на персоналот меѓу клиенти и е покриен со тестови. Улогите по сајт додаваат и филтер по сајт. Барање за ресурс на друга сметка враќа 404, никогаш 403, за ID-ата да не можат да се набројуваат. Секоја крајна точка за запишување користи строга листа на дозволени полиња. Тест за пристап меѓу сметки е задолжителен за секоја нова крајна точка.

Заглавието X-Account-Id во секое барање се проверува според токенот, па грешка во клиентот или повторно испратен токен никогаш не можат тивко да прочитаат податоци на друг клиент.

Шифрирање

TLS 1.2 или понов до секоја јавна крајна точка, взаемен TLS меѓу сервисите, TLS до секое складиште на податоци, шифрирани томови во мирување и envelope шифрирање по сметка за чувствителните полиња. Јавните сертификати се издаваат и обновуваат автоматски; внатрешните сертификати се краткотрајни.

Тајни

Сите тајни, вклучувајќи ги вашите BYOK клучеви за провајдери и тајните за вебхукови, живеат во посебен менаџер за тајни, шифрирани, ограничени по сервис и под ревизија. Ништо не е во контролата на изворниот код (се спроведува со скенирање пред секој commit) ниту во сликите на контејнерите (се проверува во CI). Програмерите стандардно немаат пристап до продукциските тајни; итниот пристап бара две одобрувања, краткотраен е и се евидентира во канал што не може да се занеми.

Вебхукови

Одлезните испораки се потпишани со HMAC-SHA256 врз временската ознака и суровото тело, носат nonce и ID на настан, се одбиваат надвор од прозорец од пет минути и се повторуваат со одложување до редица за неиспорачани пораки. Тајните се ротираат со период на преклопување и може веднаш да се отповикаат. Дојдовните вебхукови од провајдерите се проверуваат според шемата на секој провајдер пред да се обработи што било. Детали: Вебхукови.

Ограничување на барањата

Четири нивоа: заштита од DDoS и ботови на мрежата на работ, ограничувања по IP на обратниот прокси, token bucket по сметка и по идентитет на API портата и доменски ограничувања во сервисите. Ограничувањата се наведени во прегледот на API.

Ревизија

Секоја промена се запишува во дневник за ревизија само за додавање, поврзан со хаш-синџир, со две класи на чување: општи настани и настани за усогласеност (барања на субјекти на податоци, повреди, подобработувачи, KYC записи). Класата се доделува при запишувањето; дневникот никој не може да го уредува или брише, а автоматско чистење по класи засега нема. Сопствениците и администраторите можат да го филтрираат и извезуваат. Лозинките, токените и клучевите никогаш не се запишуваат во логовите; слојот за логирање ги прикрива познатите чувствителни клучеви.

Заштита на податоците

Барањата на субјектите на податоци според GDPR, UK GDPR, CCPA и LGPD (пристап, извоз, бришење) се примаат и следат во конзолата за усогласеност со рокови. Бришењето го вршат вработените во RolChat, а барањето се затвора дури по нивна потврда; автоматско бришење низ сите модули засега нема.
Локација на податоците: податоците се чуваат во ЕУ. Регионот не се избира според државата при регистрација; поставката за регион во поставките на сметката само се запишува и сè уште не ги преместува податоците.
Чување според планот: 1, 2 или 3 години. Бришењето на разговор или контакт го крие до крајот на тој рок; бришењето на сметка е барање со 30 дена за откажување, по што вработените ги бришат податоците; неплатена сметка се чува 90 дена, а потоа се брише. Автоматското чистење што ги обезбедува овие рокови се воведува.
Договор за обработка на податоци (DPA), листа на подобработувачи, политика за приватност и политика за колачиња се објавени на rolchat.com; DPA се прифаќа при регистрацијата.
Известување за повреда во рок од 72 часа, како што бара член 33 од GDPR.

Управување со ранливости

Зависностите се следат постојано; lock-датотеките се внесени во репозиториумот; основните слики се фиксирани според digest; CI акциите се фиксирани според commit. Пенетрациски тест од трета страна е закажан секоја година почнувајќи од бета-фазата, опфаќајќи ги API, виџетот и јавните страници, плус внатрешно сценарио со претпоставен упад. Приватна програма за наградување пронајдени грешки следува со општата достапност. Пријавувајте безбедносни проблеми на security@rolchat.com.

Достапност

Платформата работи на повеќе јазли со автоматско префрлање при дефект за сервисите без состојба и управувана репликација за базите на податоци. Целните показатели за достапност по план се наведени во вашиот договор.

Одговор на инциденти

Упатства за постапување за секој сервис, дежурна ротација, надворешен систем за повикување што работи и кога нашата инфраструктура не работи и обврски за известување на клиентите вградени во процесот.