Увійти

Безпека даних

Актуально на квітень 2026 року

Ця сторінка пояснює, як DiLegal CRM ставиться до безпеки інформації вашої Практики та її користувачів. Мета — дати зрозумілу картину без зайвих технічних деталей, якими можна скористатися зловмисникам. Юридичні умови обробки даних викладені в Політиці конфіденційності; правила користування сервісом — у Умовах використання.

Інформаційний документ Фокус на захисті Хмарний сервіс
Розділ 1

Про цю сторінку

  • Текст носить описовий характер і доповнює, а не замінює, Політику конфіденційності та Умови використання.
  • Ми не публікуємо внутрішні схеми мережі, точні конфігурації серверів, назви службових облікових записів, ключі, ліміти спрацьовування захисту в числовому вигляді та інші відомості, які полегшили б атаку на інфраструктуру.
  • Окремі технічні рішення можуть змінюватися без оновлення цього тексту, якщо рівень захисту не погіршується.
Розділ 2

Наші принципи

  • Мінімізація ризику. Проєктування й супровід сервісу з урахуванням типових загроз для веб-додатків і юридичних даних.
  • Розмежування доступу. Користувач бачить лише те, що дозволено роллю та належністю до вашої Практики.
  • Прозорість для клієнта. Ви маєте знати, у чому суть захисту, без «магічних» обіцянок абсолютної безпеки.
  • Законність. Обробка даних відбувається відповідно до чинного законодавства України та документів, з якими ви погоджуєтеся.
Розділ 3

Зв’язок між браузером і сервером

Для роботи веб-інтерфейсу використовується захищений канал (сучасний протокол HTTPS): дані між вашим браузером і платформою передаються у зашифрованому вигляді. На стороні сервера застосовуються поширені практики жорсткості каналу (наприклад, примусове використання HTTPS і політики, що ускладнюють підміну сторінки).

  • Додаткові заголовки безпеки зменшують ризик підміни контенту, некоректного кешування та витоку метаданих через реферер там, де це доречно.
  • Для HTML-сторінок застосовується політика безпеки контенту (CSP) — обмеження джерел скриптів і ресурсів, щоб ускладнити впровадження шкідливого коду.
Детальні параметри TLS, списки шифрів і внутрішні правила балансування нами не розкриваються — це частина захисту «глибини оборони».
Розділ 4

Паролі та вхід до системи

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

Сесія, файли cookie та форми

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

Детальніше про cookie та LocalStorage — у розділі відповідної Політики конфіденційності.

Розділ 6

Доступ за ролями та межі Практики

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

Журнали, аудит і запити до даних

  • Фіксуються дії користувачів, необхідні для безпеки, розслідування інцидентів і відповідності внутрішнім процедурам (зокрема контекст звернення до сервера в обмеженому обсязі).
  • Запити до бази даних формуються через параметризовані механізми, що знижує ризик ін'єкційних атак.
  • Службові журнали веб-сервера та додатків зберігаються з обмеженим доступом і використовуються для діагностики та безпеки.
Розділ 8

Зберігання файлів і чутливі зони

  • Файли, які ви завантажуєте до системи, зберігаються в окремому сховищі з розмежуванням доступу на рівні застосунку.
  • Службові каталоги, конфігураційні файли та технічна документація API не відкриваються для анонімного доступу з інтернету.
  • Шифрування даних на носіях (диски в дата-центрі) залежить від налаштувань інфраструктурного провайдера; ми обираємо надійних партнерів і дотримуємося домовленостей щодо конфіденційності.
Розділ 9

Сервісні інтеграції

  • Окремі функції (наприклад, push-сповіщення або синхронізація з календарем) можуть залучати перевірених технічних партнерів. У такому разі передається лише мінімум даних, потрібний для роботи функції.
  • Увімкнення інтеграцій, де потрібна ваша згода, здійснюється через стандартні механізми авторизації постачальника інтеграції (на кшталт OAuth), без передачі паролю DiLegal стороннім сервісам.
  • Ми не продаємо персональні дані й не передаємо їх для сторонньої реклами; деталі виключень (закон, суд, захист прав) — у Політиці конфіденційності.
Розділ 10

Резервні копії та доступність

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

Оновлення та усунення вразливостей

  • Компоненти платформи (системне програмне забезпечення, бібліотеки, фреймворки) регулярно оновлюються у міру виходу виправлень безпеки.
  • Критичні оновлення можуть вводитися позапланово; ми намагаємося мінімізувати простої для користувачів.
  • Якщо ви виявили потенційну вразливість, повідомте нас через контакт нижче; відповідальне розкриття (без публічного тиску до усунення) прискорює виправлення.
Розділ 12

Інциденти та обмеження

  • Жодна система не гарантує абсолютний захист; ризик залишається ненульовим, зокрема через фактори поза нашим контролем (зламаний пристрій користувача, витік паролю тощо).
  • У разі інциденту, що суттєво стосується ваших даних, ми діємо відповідно до законодавства та Політики конфіденційності, зокрема щодо повідомлення адміністратора Практики.
  • У публічних повідомленнях про інциденти ми не розкриваємо внутрішніх деталей розслідування, які могли б допомогти атакуючим.
Розділ 13

Що ви можете зробити для безпеки

  • Використовуйте унікальний надійний пароль для DiLegal і не повторюйте його на інших сайтах.
  • Завжди виходьте з сесії на спільних або чужих комп’ютерах.
  • Обмежуйте коло адміністраторів і своєчасно деактивуйте облікові записи колег, які припинили роботу.
  • Не пересилайте посилання з авторизацією, скріншоти з токенами та службові листи з кодами доступу третім особам.
  • Повідомляйте адміністратора Практики про підозрілу активність (незнайомі входи, зміни даних без відома).
Розділ 14

Пов’язані документи та контакти

Ознайомтеся також із:

Запитання щодо безпеки та захисту даних:

Організація ТОВ «Софтингер»
Адреса 04071, м. Київ, пров. Ярославський, буд. 7/9, оф. 3