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

FinDay OS — Operating System фінансового дня. Це означає, що безпека не може бути “додатковою опцією”. Вона має бути вбудованою в архітектуру: у доступи, у дисципліну змін, у відновлюваність, у прозорість дій. Ця сторінка фіксує принципи і практики, які ми застосовуємо, щоб захищати дані клієнтів і забезпечувати передбачувану роботу сервісу.

Тут немає “маркетингових обіцянок”. Є рамка: що саме ми робимо, як ми мислимо ризиками і які механізми вважаємо базовими. Частина деталей може змінюватися з розвитком інфраструктури, але принципи залишаються незмінними: мінімізувати доступ, фіксувати критичні події, контролювати зміни, мати план відновлення і реагувати на інциденти прозоро.

1. Модель безпеки

Наша модель безпеки побудована на простому правилі: у фінансовій системі не має бути “сліпих зон”. Тому ми проектуємо FinDay OS так, щоб будь-яка критична дія мала автора, контекст і слід у журналі.

Ми застосовуємо принцип мінімальних прав (least privilege): користувачі отримують рівно ті доступи, які потрібні для їхніх задач, і не більше. Адміністративні права обмежуються і використовуються тільки за необхідності.

Ми застосовуємо сегментацію на рівні доступів і середовищ: дані різних клієнтів ізольовані логічно (і, за потреби, технічно), а внутрішні середовища (розробка/тест/продакшн) відділені, щоб знижувати ризик помилок і витоків.

Ми підтримуємо журналювання та доказовість: система фіксує значущі події, щоб можна було відновити послідовність дій і приймати рішення не “по відчуттях”, а по фактах.

Ми застосовуємо контроль змін: оновлення і зміни в системі проходять керований цикл (перевірки, деплой, моніторинг), щоб не ламати робочі сценарії клієнтів і не відкривати нові ризики.

2. Захист даних

Ми захищаємо дані на двох ключових рівнях: під час передачі і під час зберігання.

Дані “в дорозі” (in transit) передаються через захищені канали зв’язку. Це знижує ризики перехоплення трафіку або підміни даних між браузером користувача і сервісом.

Дані “на диску” (at rest) зберігаються із застосуванням механізмів шифрування або еквівалентних безпекових засобів на рівні інфраструктури. Конкретна реалізація може залежати від хостингу та архітектури, але принцип незмінний: дані не повинні бути “відкритими” у сховищі.

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

3. Доступ і аутентифікація

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

Політика паролів: ми підтримуємо вимоги до надійності паролів і не зберігаємо паролі у відкритому вигляді. Доступи мають бути персональними, а не “на всю команду”.

2FA (двофакторна автентифікація) може бути доступною як опція, а для критичних ролей (адміністратор/фінанс) — рекомендованою або обов’язковою залежно від політики та конфігурації. Це суттєво знижує ризики захоплення акаунта.

Сесії та керування входами: ми використовуємо механізми сесій, які мінімізують ризик викрадення або повторного використання доступу, і фіксуємо події входу для подальшого аудиту.

IP-обмеження: якщо така функція планується або доступна в окремих тарифах/для корпоративних клієнтів, вона може використовуватись як додатковий рівень контролю доступу (наприклад, дозволити вхід тільки з корпоративних мереж). Якщо IP-обмеження ще не увімкнені як функціонал, ми не декларуємо їх як гарантію, а розглядаємо як опцію для roadmap або enterprise-конфігурацій.

4. Логи і аудит

FinDay OS — це система, де “хто зробив” інколи важливіше, ніж “що змінилося”. Тому ми підтримуємо аудит і логи як базову частину операційної дисципліни.

Ми фіксуємо журнал входів: події авторизації, базові технічні атрибути сесії, а також підозрілі сценарії (наприклад, серії невдалих входів).

Ми фіксуємо журнал дій (audit trail) для ключових операцій: створення/зміна/проведення документів, зміни довідників, редагування критичних налаштувань і політик.

Ми виділяємо критичні події, які потребують підвищеної уваги та можуть впливати на безпеку або цілісність обліку, зокрема: зміни прав доступу, додавання/видалення користувачів, операції експорту, операції видалення, зміни ролей, зміни важливих параметрів компанії.

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

5. Резервні копії та відновлення

Операційна система повинна бути відновлюваною. Тому ми підтримуємо резервне копіювання як стандартну практику.

Ми виконуємо регулярні резервні копії даних і конфігурацій у рамках стандартного циклу. Частота та глибина резервування можуть залежати від архітектури, але наша мета — забезпечити відновлення при інцидентах, помилках або аваріях.

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

Ми, наскільки це практично, проводимо тестування відновлення (recovery tests) — щоб резервні копії були не “для галочки”, а реально придатні для відновлення.

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

6. Вразливості та оновлення

Ми підтримуємо регулярну гігієну безпеки: оновлення, патчі, контроль залежностей і усунення вразливостей є частиною нормальної експлуатації сервісу.

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

Ми можемо використовувати сканування або перевірки на рівні коду/залежностей/інфраструктури як частину процесу, але деталі інструментів не є публічною гарантією. Важливий принцип: ризики мають відслідковуватися, а виправлення — робитися швидко.

Відповідальне розкриття (Responsible Disclosure): якщо ви знайшли потенційну вразливість, ми просимо повідомити про це відповідально, не публікуючи деталі до нашого виправлення. Для цього ми можемо мати окремий контакт: support@finday-os.com. У повідомленні важливо вказати кроки відтворення, потенційний вплив і ваші контакти для уточнень.

7. Інцидент-менеджмент

Інциденти — це не питання “чи буде”, а питання “як ми діємо”. Ми маємо процес фіксації, реагування та комунікації.

Ми реєструємо інциденти, локалізуємо їх, оцінюємо вплив, відновлюємо сервіс і робимо висновки, щоб знизити повторюваність. Для клієнта важливо два аспекти: швидкість реакції і прозорість наслідків.

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

8. Відповідність (опційно)

Ми не декларуємо сертифікації, яких у нас немає. Якщо на момент публікації FinDay OS не має SOC 2, ISO 27001 або інших формальних атестацій — ми так і кажемо: ми працюємо за практиками, але не заявляємо формальної сертифікації.

Якщо ви плануєте шлях до SOC 2 / ISO 27001, цей розділ може описувати “напрямок”: впровадження політик, контроль доступів, аудит змін, ризик-менеджмент, навчання персоналу, управління постачальниками. Але без дат, “гарантій отримання” і без формулювань, які виглядають як обіцянка сертифікації.

Для корпоративних клієнтів ми можемо надавати: опис технічних та організаційних заходів, відповіді на security questionnaire, підтвердження політик і DPA — як практичний інструмент комплаєнсу без “порожніх значків”.