Към съдържанието

Сигурност и съответствие

  • Access токените са краткотрайни JWT (15 минути), проверявани в API шлюза; refresh токените са валидни 30 дни при неактивност и най-много 90 дни, сменят се при всяка употреба и се съхраняват в HttpOnly, Secure, SameSite бисквитка. Повторната употреба на сменен refresh токен отменя цялата верига.
  • Ключовете за подписване се сменят на всеки 90 дни с припокриване; публичните ключове се публикуват на /.well-known/jwks.json.
  • Разрешенията не се вграждат в токените: те се четат при всяка заявка, така че промяната на роля влиза в сила веднага, а всяка сесия може да бъде отменена централно.
  • Двуфакторното удостоверяване (TOTP) може да е по избор, задължително за собствениците и администраторите или задължително за всички. Единен вход с 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 към всяко хранилище за данни, криптирани томове в покой и пликово криптиране на чувствителните полета за всеки акаунт. Публичните сертификати се издават и подновяват автоматично; вътрешните сертификати са краткотрайни.

Всички тайни, включително ключовете на вашите доставчици по модела BYOK и тайните на уебхуковете, се съхраняват в отделен мениджър на тайни, криптирани, ограничени по услуги и одитирани. Нищо не попада в системата за контрол на версиите (гарантира се чрез сканиране преди всеки commit) или в образите на контейнерите (проверява се в CI). По подразбиране разработчиците нямат достъп до тайните в продукционна среда; аварийният достъп изисква две одобрения, е краткотраен и се записва в канал, който не може да бъде заглушен.

Изходящите доставки се подписват с HMAC-SHA256 върху времевия печат и суровото тяло, носят nonce и ID на събитието, отхвърлят се извън петминутен прозорец и се повтарят с нарастващо забавяне до опашка за недоставени съобщения. Тайните се сменят с прозорец на припокриване и могат да бъдат отменени мигновено. Входящите уебхукове от доставчици се проверяват по схемата на всеки доставчик, преди да се обработи каквото и да е. Подробности: Уебхукове.

Ограничаване на заявките

Раздел „Ограничаване на заявките“

Четири нива: защита от DDoS и ботове в периферната мрежа, лимити по IP в обратния прокси, кофи с токени по акаунт и по идентичност в API шлюза и лимити по домейн вътре в услугите. Лимитите са в общия преглед на API.

Всяка промяна се записва в одитен журнал само за добавяне, свързан с верига от хешове, с два класа на съхранение: общи събития и събития за съответствие (искания на субекти на данни, нарушения, подизпълнители и KYC записи). Класът се определя при записването на вписването; никой не може да редактира или изтрива журнала, а автоматично почистване по класове все още не работи. Собствениците и администраторите могат да го филтрират и експортират. Пароли, токени и ключове никога не се записват в логовете; слоят за логване скрива известните чувствителни ключове.

  • Исканията на субекти на данни по GDPR, UK GDPR, CCPA и LGPD (достъп, експорт, изтриване) се получават и проследяват в конзолата за съответствие със срокове. Изтриването се извършва от служители на RolChat и искането се затваря едва след тяхното потвърждение; автоматично изтриване във всички модули все още не е налично.
  • Местоположение на данните: данните се съхраняват в ЕС. Регионът не се избира по държава при регистрация; настройката за регион в настройките на акаунта само се записва и все още не премества данни.
  • Съхранение по план: 1, 2 или 3 години. Изтриването на разговор или контакт го скрива до края на този срок; изтриването на акаунт е заявка с 30 дни за отказ, след което служителите изтриват данните; неплатен акаунт се пази 90 дни и после се изтрива. Автоматичното почистване, което налага тези срокове, се внедрява.
  • Споразумение за обработка на данни (DPA), списък на подизпълнителите, политика за поверителност и политика за бисквитките са публикувани на rolchat.com; DPA се приема при регистрация.
  • Уведомяване за нарушение до 72 часа, както изисква член 33 от GDPR.

Управление на уязвимости

Раздел „Управление на уязвимости“

Зависимостите се наблюдават непрекъснато; lock файловете се записват в хранилището; базовите образи са фиксирани по дайджест; действията в CI са фиксирани по commit. Ежегоден тест за проникване от трета страна е планиран от бета версията нататък и обхваща API, уиджета и публичните страници, както и вътрешен сценарий с предполагаем пробив. При общата наличност ще последва частна програма bug bounty. Съобщавайте за проблеми със сигурността на security@rolchat.com.

Платформата работи на множество възли с автоматично превключване при отказ за услугите без състояние и управлявана репликация за базите данни. Целевите показатели за наличност по план са посочени във вашия договор.

Реакция при инциденти

Раздел „Реакция при инциденти“

Наръчници за всяка услуга, дежурства на смени, външна система за известяване, която работи, когато нашата собствена инфраструктура не работи, и задължения за уведомяване на клиентите, вградени в процеса.