Центр довіри
Огляд безпеки
Матриця контролів для безпекових перевірок — із тим, на чому стоїть кожен статус, — і технічні та організаційні заходи, що стоять за платформою.
- Статус
- Чинний
- Версія
- 1.0
- Чинний з
- 8 вересня 2026
Sintoralabs OÜ · Реєстраційний код 17456201
Цей текст є перекладом, наданим виключно для зручності. Автентичною версією цього документа є англомовна. У разі будь-яких розбіжностей між перекладом і англомовною версією переважає англомовна версія.
1. Матриця контролів
Контролі, про які питає безпекова перевірка, — кожен зі статусом і з тим, на чому цей статус стоїть. Пояснення — під таблицею; відповідь — сама таблиця.
Статус ніколи не ставиться автоматично. Якщо доказу немає ні в коді, ні в конфігурації, ні в документі, статус — «потребує підтвердження», а не «підтверджено» через те, що контроль є звичним, і не через те, що так написано на іншій сторінці. Тому більшість рядків лишається відкритою: цей сайт може показати вам сайт, а платформа — окрема система.
Таблиця оцінює те, чи можете ви перевірити контроль за публічним доказом, а не те, чи ми його виконуємо. Більшість цих контролів — наші зобовʼязання за Annex 3 угоди про обробку даних, тобто за договором; договір — це зобовʼязання, а не доказ. Відкритий рядок — це не контроль, якого в нас немає. Це контроль, який вам довелося б прийняти на наше слово, і рядок каже, на яке саме.
14 контролів: 1 підтверджено доказом, 10 потребують підтвердження, 3 не впроваджено.
- Підтверджено
- Є доказ, на який ми можемо вказати, і він названий у рядку.
- Потребує підтвердження
- Контроль заявлений, і публічного доказу, який ви могли б перевірити самі, немає. Це не означає, що контролю немає: частина з них — зобов’язання за Annex 3 нашої угоди про обробку даних, і рядок називає це. Що саме бракує — теж у рядку.
- Не впроваджено
- Сьогодні цього немає. У рядку названо, що це означає для перевірки.
| Контроль | Статус | На чому це стоїть |
|---|---|---|
| Шифрування в русі | Підтверджено | Для цього сайту сервер вимагає HTTPS: він надсилає HSTS на рік із піддоменами, а політика безпеки контенту підвищує будь-який HTTP-підресурс до HTTPS.
|
| Шифрування на спокої | Потребує підтвердження | Дані клієнта шифруються на спокої засобами шифрування сховища, які надає інфраструктура, а секрети й облікові дані зберігаються в керованому сховищі секретів, а не в коді чи файлах конфігурації.
|
| Ізоляція тенантів | Потребує підтвердження | Платформа мультитенантна: кожен клієнт — окремий тенант, і дані сегреговані так, що один тенант не читає й не змінює дані іншого. Галузеві рішення ставляться модулями всередині тенанта клієнта, а не окремими інсталяціями.
На тарифі Advanced продукту Sintora Meetings обчислювальний ресурс, на якому працює Meetings вашої організації, виділений і розміщений у межах вашого ж тенанта: тенант, модель даних, права доступу та журнал дій лишаються ті самі, що й для решти платформи. На тарифах Lite і Standard Meetings працює на спільному обчислювальному ресурсі.
|
| Рольовий доступ | Потребує підтвердження | Права всередині продукту гранульовані — призначаються на дію, а не на екран — і можуть бути обмежені мережею, обʼєктом або окремою командою. Доступ до продакшн-систем побудований за принципом найменших привілеїв, через іменні акаунти, з періодичним переглядом.
Доступ до зустрічей у Sintora Meetings визначають ті самі ролі й дозволи вашої організації, що й для решти платформи: Meetings працює всередині вашого тенанта, а не як окремий продукт із власною моделлю доступу.
|
| MFA для привілейованого доступу | Потребує підтвердження | Привілейований доступ до продакшн-систем захищений багатофакторною автентифікацією. Усередині продукту MFA доступна вашим користувачам, і адміністратор може зробити її обовʼязковою.
|
| Журнали аудиту | Потребує підтвердження | Журнал аудиту значущих дій усередині тенанта доступний на всіх платних тарифах, і ваші адміністратори можуть його вивантажити. Адміністративні дії з нашого боку журналюються.
Значущі дії в Sintora Meetings потрапляють у журнал усередині вашого тенанта — той самий, що й для решти платформи, на всіх платних тарифах.
|
| Резервне копіювання й відновлення | Потребує підтвердження | Дані клієнтів резервуються регулярно, копії шифруються і зберігаються окремо від продакшну; є плани безперервності й відновлення.
|
| Моніторинг інфраструктури | Потребує підтвердження | Ми збираємо журнали застосунку, інфраструктури й безпеки, стежимо за доступністю та частотою помилок і реагуємо на аномалії. Доступ до журналів обмежений.
|
| Керування вразливостями | Потребує підтвердження | Ми оновлюємо системи за ризик-орієнтованим графіком, пріоритезуючи вразливості за критичністю й доступністю ззовні, і ведемо знахідки до усунення.
|
| Безпечний SDLC | Потребує підтвердження | Зміни проходять через контроль версій, рев’ю й автоматичні перевірки перед релізом. Середовища розділені, а продакшн-дані не використовуються для розробки чи тестування. Погодження релізів фіксуються в системі контролю версій, а не в окремій системі керування змінами.
|
| Навчання персоналу з безпеки | Потребує підтвердження | Кожен, хто має доступ до даних клієнтів, проходить навчання з обізнаності щодо захисту даних при приєднанні та щороку після цього.
|
| Незалежний тест на проникнення | Не впроваджено | Незалежного тесту на проникнення ми не замовляли. Що це означає: Коли такий тест буде проведено, підсумок надаватимемо за NDA. Цільових строків усунення за рівнями критичності ми публічно не заявляємо — вони погоджуються в підписаній формі замовлення. |
| ISO/IEC 27001 | Не впроваджено | Сертифіката ISO/IEC 27001 ми не маємо. Що це означає: Сертифікації від зовнішнього аудитора в нас немає в жодній формі, і ми її не заявляємо. Якщо сертифікат є жорсткою вимогою вашої закупівлі, скажіть про це на початку. |
| SOC 2 | Не впроваджено | Звіту SOC 2 — ні Type I, ні Type II — у нас немає. Що це означає: Аудит SOC 2 не проводився. Для закупівельної перевірки ми надаємо угоду про обробку даних, перелік субпроцесорів і заповнену анкету з безпеки. |
Кожен рядок звірено з кодом цього сайту і з опублікованими документами; найдавнішу звірку зроблено 3 вересня 2026, найсвіжішу — 12 вересня 2026. Рядок піднімається до «Підтверджено» лише разом із доказом, названим тут-таки, — і ніколи тому, що контроль виглядає звичним.
2. Наш підхід
Sintora тримає операційне ядро бізнесу — клієнтів, договори, комунікацію, гроші. Ця концентрація і є сенсом платформи, і саме тому безпека є частиною того, як продукт побудований, а не шаром, доданим згодом.
Цей огляд описує заходи, які ми застосовуємо. Він написаний для покупців, фахівців з безпеки та відділів закупівель, яким потрібно зрозуміти нашу позицію до детальної оцінки.
3. Відповідність вимогам
Наша позиція щодо сертифікації — у таблиці вище: сертифікації від зовнішнього аудитора в нас немає в жодній формі, і ми її не заявляємо.
- GDPR — ми зареєстровані в Європейському Союзі й обробляємо персональні дані згідно з GDPR: як контролер щодо власних даних і як процесор щодо даних клієнтів.
- Визнані галузеві фреймворки слугують орієнтиром для того, як ми будуємо контроль доступу, управління змінами та реагування на інциденти, — як робоча модель, а не як пройдена сертифікація.
- Договірні зобовʼязання — усе, що важливо для вас, міститься в угоді про обробку даних, яку ми готові підписати.
Якщо сертифікація є жорсткою вимогою вашого процесу закупівлі, скажіть про це на початку перевірки.
4. Інфраструктура та розміщення даних
Платформа працює на керованій хмарній інфраструктурі. Cloudflare залучений для DNS, доставки контенту, WAF, захисту від DDoS і від ботів; які саме з цих функцій увімкнені перед конкретним ресурсом, підлягає підтвердженню, а те, на що ми можемо вказати сьогодні, — це перевірка Turnstile на наших формах.
Якщо якийсь компонент або субпроцесор працює поза ЄЕЗ, передача спирається на механізм, визнаний главою V GDPR.
Провайдерів, яких ми залучаємо для обчислень, зберігання й резервних копій, залучено для майданчиків у межах Європейського економічного простору, і їх названо в переліку субпроцесорів. Конкретні регіони й зони доступності не підтверджені, і перелік позначає це поруч із кожним значенням. Окремого розміщення даних для конкретного клієнта за межами ЄЕЗ сьогодні немає, і якщо воно вам потрібне — це питання підписаного договору.
5. Чого ми не публікуємо
Наведене нижче ми надаємо на запит — під NDA там, де це доречно, — а не публікуємо тут. Точна конфігурація на публічній сторінці є відправною точкою для будь-кого, хто її зондує, а опублікований номер версії застаріває.
- Версія TLS, що застосовується примусово, політика шифрів і підхід до керування ключами та їх ротації.
- Технічна модель ізоляції — як саме розділені середовища тенантів.
- Конкретний інструментарій для статичного аналізу, сканування залежностей і пошуку секретів.
- Періодичність і строк зберігання резервних копій, цілі відновлення й дата останнього тесту відновлення.
Ми не публікуємо цільову точку відновлення чи цільовий час відновлення як зобов’язання: опублікована ціль — це обіцянка, а обіцянці про відновлення місце в підписаному договорі, де її можна обмежити рамками.
Виділені однотенантні розгортання не входять до стандартних тарифів; вони можливі за підписаним договором.
6. Строки зберігання журналів
Журнали сайту й сервера зберігаються 30 днів.
7. Реагування на інциденти
Ми підтримуємо процес реагування на інциденти, що охоплює виявлення, сортування, локалізацію, усунення, відновлення та розбір після інциденту. Ролі та шляхи ескалації визначені наперед, щоб реагування не залежало від імпровізації.
Коли ми виступаємо контролером, ми повідомляємо естонську Інспекцію із захисту даних протягом 72 годин, якщо інцидент підлягає повідомленню, і самих осіб — якщо ризик високий.
Якщо порушення захисту персональних даних стосується даних клієнта, ми повідомляємо цього клієнта без невиправданої затримки й у будь-якому разі протягом 72 годин з моменту, коли дізналися, — це те саме зобовʼязання, що й в угоді про обробку даних, яка нас і зобовʼязує. Повідомлення йде на адміністративний контакт вашого акаунта електронною поштою; публічної сторінки статусу ми сьогодні не ведемо.
8. Субпроцесори та постачальники
Ми оцінюємо постачальників до залучення й укладаємо з кожним угоду про обробку даних із зобовʼязаннями щодо конфіденційності та безпеки, не менш захисними за наші власні. Постачальників періодично переглядають, а про суттєві зміни в переліку субпроцесорів повідомляють клієнтів, щоб ті могли скористатися своїми правами за угодою про обробку даних.
Чинний перелік субпроцесорів — це Annex 2 Угоди про обробку даних, опублікованої на цьому сайті. Про нового субпроцесора ми повідомляємо до того, як він почне обробку, і ви можете заперечити; якщо ми не зможемо владнати заперечення, ви можете припинити відповідну частину сервісу. Тривалість цього попередження підлягає підтвердженню й буде названа в угоді про обробку даних — саме вона нас зв’язує.
9. Люди
Кожен, хто має доступ до даних клієнтів, звʼязаний зобовʼязаннями конфіденційності. Перевірок кандидатів через третіх осіб ми не проводимо.
Навчання з обізнаності щодо захисту даних при приєднанні та щороку після цього — це наше зобовʼязання за Annex 3 угоди про обробку даних. Це рядок таблиці вище зі статусом, який він справді має: запису про проходження, який ви могли б перевірити, у нас немає, тож це каже рядок, а не цей абзац, який раніше стверджував періодичність як факт.
10. Що контролюєте ви
Безпека — спільна. Ролі й права, журнал аудиту всередині вашого тенанта та багатофакторна автентифікація — це рядки таблиці вище, зі статусом, який кожен із них справді має. Решта того, чим керуєте ви, — тут.
- Вивантаження ваших даних у стандартних форматах, зокрема CSV і PDF.
- Адміністрування власних користувачів — створення, зміна ролей і видалення.
Єдиний вхід через SAML або OIDC доступний для корпоративних розгортань через власний рівень ідентичності платформи: ваші люди автентифікуються у вашого корпоративного провайдера ідентичності — Microsoft Entra ID, Google Workspace, Okta — і отримують доступ до кожного сьюта, включно з Command Center, без окремого пароля Sintora. Це можливість платформи, а не функція якогось одного продукту.
Обмеження доступу за списком IP і налаштовувана політика сесій сьогодні недоступні; вони в дорожній карті.
11. Повідомлення про вразливість
Якщо ви вважаєте, що знайшли вразливість, повідомте нас, перш ніж розкривати її публічно. Надішліть деталі, зокрема кроки відтворення та proof-of-concept, — і ми згадаємо вас як автора знахідки, якщо ви цього захочете.
Будь ласка, не отримуйте доступ до чужих даних, не змінюйте й не видаляйте їх, не погіршуйте роботу сервісу та не запускайте автоматичне сканування, що впливає на доступність, під час тестування.
Про підозру на вразливість повідомляйте на info@sintora.ai зі словом «security» у темі. Ми підтверджуємо отримання й скажемо вам, що знайшли й коли це виправлено. Як швидко ми підтверджуємо — підлягає підтвердженню й не публікується як зобовʼязання, поки цього не станеться, — так само, як із тривалістю попередження про субпроцесора вище, і з тієї самої причини: час відповіді на цій сторінці — це обіцянка, а жоден підписаний нами документ її не несе. Ми не ведемо програми bug bounty й не пропонуємо винагороди, і ми не переслідуватимемо нікого, хто повідомляє сумлінно, не отримує доступу до чужих даних і дає нам розумну можливість усунути проблему до публікації.
12. Документація для перевіряючих
Для закупівель і безпекових перевірок ми можемо надати — під NDA там, де це доречно: нашу угоду про обробку даних, перелік субпроцесорів, заповнені анкети з безпеки і, де такі є, підсумки тестів на проникнення. Щоб розпочати перевірку, пишіть на info@sintora.ai.