Безпека та відповідність

Автентифікація

• Access-токени - це короткоживучі JWT (15 хвилин), які перевіряються на API-шлюзі; refresh-токени діють 30 днів у разі простою і не більше 90 днів, змінюються під час кожного використання та зберігаються в cookie з прапорцями HttpOnly, Secure і SameSite. Повторне використання заміненого refresh-токена відкликає весь ланцюжок.
• Ключі підпису змінюються кожні 90 днів із перекриттям; відкриті ключі публікуються на /.well-known/jwks.json.
• Дозволи не вбудовуються в токени: вони зчитуються під час кожного запиту, тому зміна ролі діє негайно, а будь-яку сесію можна відкликати централізовано.
• Двофакторна автентифікація (TOTP) може бути необов’язковою, обов’язковою для власників і адміністраторів або обов’язковою для всіх. Єдиний вхід через Google Workspace і Apple доступний на кожному плані. SAML 2.0, ключі доступу (passkeys) і провізіонування через SCIM заплановано, поки що вони недоступні.
• API-ключі показуються один раз, зберігаються як хеш SHA-256, отримують області доступу із закритого каталогу, обмежені дозволами свого власника та відкликаються миттєво. Див. Автентифікація.
• Вхід обмежено за IP і за e-mail; десять невдалих спроб блокують акаунт на 30 хвилин; невдалі спроби з однієї IP-адреси підраховуються й записуються, але за замовчуванням цю адресу не блокують. Кожен вхід, невдала спроба, оновлення токена, зміна дозволів і дія адміністратора записуються в журнал аудиту.

Ізоляція клієнтів

Кожен рядок у кожному сервісі містить акаунт, якому він належить, і кожен запит автоматично фільтрується за ним; вимкнення фільтра потребує явного виклику зі списку дозволених, який використовується лише для міжклієнтських операцій співробітників і покритий тестами. Ролі на рівні сайтів додають згори фільтр за сайтом. Запит ресурсу іншого акаунта повертає 404, а не 403, щоб ID не можна було перебрати. Кожен ендпоінт запису використовує суворий список дозволених полів. Тест доступу між акаунтами обов’язковий для кожного нового ендпоінта.

Заголовок X-Account-Id у кожному запиті звіряється з токеном, тому помилка в клієнті чи повторно використаний токен ніколи не можуть непомітно прочитати дані іншого клієнта.

Шифрування

TLS 1.2 або новіший для кожного публічного ендпоінта, взаємний TLS між сервісами, TLS до кожного сховища даних, зашифровані томи в стані спокою та конвертне шифрування чутливих полів для кожного акаунта. Публічні сертифікати випускаються й поновлюються автоматично; внутрішні сертифікати короткоживучі.

Секрети

Усі секрети, зокрема ключі ваших провайдерів за моделлю BYOK і секрети вебхуків, зберігаються в окремому менеджері секретів - зашифрованими, з обмеженням за сервісами та з аудитом. Нічого не потрапляє до системи контролю версій (це забезпечує сканування перед кожним комітом) чи в образи контейнерів (перевіряється в CI). За замовчуванням розробники не мають доступу до секретів продакшену; екстрений доступ потребує двох схвалень, надається ненадовго й записується в канал, який неможливо заглушити.

Вебхуки

Вихідні доставки підписуються HMAC-SHA256 за міткою часу й сирим тілом, містять nonce і ID події, відхиляються поза п’ятихвилинним вікном і повторюються зі зростаючою затримкою аж до черги недоставлених повідомлень. Секрети змінюються з вікном перекриття й можуть бути відкликані миттєво. Вхідні вебхуки провайдерів перевіряються за схемою кожного провайдера до будь-якої обробки. Докладніше: Вебхуки.

Обмеження запитів

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

Аудит

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

Захист даних

• Запити суб’єктів даних за GDPR, UK GDPR, CCPA і LGPD (доступ, експорт, видалення) приймаються й відстежуються в консолі відповідності з термінами. Видалення виконують співробітники RolChat, і запит закривається лише після їхнього підтвердження; автоматичного видалення в усіх модулях поки немає.
• Розміщення даних: дані зберігаються в ЄС. Регіон не вибирається за країною під час реєстрації; налаштування регіону в налаштуваннях облікового запису лише записується й поки що не переносить дані.
• Зберігання за планом: 1, 2 або 3 роки. Видалена розмова чи контакт приховуються до кінця цього строку; видалення акаунта - це запит із 30 днями на скасування, після чого співробітники стирають дані; неоплачений акаунт зберігається 90 днів, а потім стирається. Автоматичне очищення, яке забезпечує ці строки, впроваджується поступово.
• Угоду про обробку даних (DPA), список субпідрядників, політику конфіденційності та політику cookie опубліковано на rolchat.com; DPA приймається під час реєстрації.
• Повідомлення про витік протягом 72 годин, як того вимагає стаття 33 GDPR.

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

Залежності відстежуються безперервно; lock-файли фіксуються в репозиторії; базові образи закріплено за дайджестом; дії CI закріплено за комітом. Щорічний сторонній тест на проникнення заплановано починаючи з бети; він охоплює API, віджет і публічні сторінки, а також внутрішній сценарій із припущеним зламом. Із виходом загальної доступності з’явиться закрита програма bug bounty. Повідомляйте про проблеми безпеки на security@rolchat.com.

Доступність сервісу

Платформа працює на кількох вузлах з автоматичним перемиканням у разі відмови для сервісів без стану та керованою реплікацією для баз даних. Цільові показники часу безвідмовної роботи за планами вказано у вашому договорі.

Реагування на інциденти

Регламенти для кожного сервісу, графік чергувань, зовнішня система сповіщень, яка працює, навіть коли не працює наша власна інфраструктура, та зобов’язання щодо сповіщення клієнтів, вбудовані в процес.