Кадрова система охоронної компанії — цивільний сценарій із високими вимогами до контролю доступу до окремих полів. Не кожен HR-спеціаліст має бачити всі дані про всіх працівників. Адреси, контакти родичів, графіки постів, прив’язка до об’єктів, результати внутрішніх перевірок та дисциплінарна історія — окремі права, оцінювані для кожного поля.
§ 01 — Тип системи
Система персонального обліку та кадрового діловодства. Функції:
- Персональний облік працівників (ПІБ, посада, документи, контактні дані, кваліфікації)
- Штатно-посадовий облік (структура підрозділів, штатні розписи, графіки постів, табелі)
- Ведення наказів і розпоряджень кадрового характеру
- Підбір і розстановка кадрів, кадровий резерв
- Підбір кандидатів на вакансії, фіксація етапів перевірки
- Підготовка статистичної та управлінської звітності
- Облік навчання, сертифікацій, медоглядів і допусків до об’єктів
- Планування змін, резервних груп і чергувань
Класифікація АС — від АС-2 для більшості функцій до АС-3, якщо система одночасно обробляє дані різних рівнів обмеженого доступу. Користувачів — від HR-фахівців центрального офісу до регіональних координаторів, менеджерів об’єктів і служби контролю.
§ 02 — Виклики та модель загроз
Специфічні класи загроз для кадрової системи охоронної компанії:
- Інсайдер з комерційною мотивацією. Кадрова інформація, графіки постів, прив’язка працівників до об’єктів та контактні дані — чутливі дані для конкурента або злочинної групи.
- Інсайдер з ширшим за необхідне доступом. Класична помилка: один HR-спеціаліст має повний доступ до всіх записів, включно з об’єктами, перевірками та внутрішніми інцидентами.
- Загроза «копіювання у разі переходу». Звільнення працівника або менеджера може супроводжуватися спробою скопіювати значний обсяг кадрових даних.
- Атаки на доступність у кризовий період. DDoS або ransomware можуть зірвати оперативне планування змін і доступ до кадрових документів.
- Адміністративні загрози посилюються. Адміністратор кадрової бази — критична позиція. Потребує особливих процедур контролю.
§ 03 — Вимоги нормативів
- НД ТЗІ 2.5-004-99 — АС-2 для основних функцій, АС-3 для частини з державною таємницею або різними грифами доступу
- Закон України «Про захист персональних даних»
- ДСТУ 4145 — підпис кадрових документів
- Внутрішні політики контролю доступу, комплаєнсу та роботи з об’єктами
- КМУ № 712 (2025) — для авторизації системи
§ 04 — Архітектура рішення на UnityBaseDefense
Кадрова система охоронної компанії — це «прискіпливий» цивільний сценарій для гранулярного контролю доступу. UBD спроектована саме для таких задач.
Контури системи
Залежно від рівня доступу до інформації, система може будуватися у двох контурах:
- Основний контур (АС-2): більшість функцій кадрового діловодства — працівники, посади, графіки, звіти. Інтернет-канали з шифруванням.
- Окремий контур (АС-3): за потреби — дані з вищим рівнем обмеженого доступу: внутрішні перевірки, інциденти, прив’язка до критичних об’єктів, матеріали служби контролю. Фізично ізольована мережа або повний відрив через cross-domain gateway.
Обмін між контурами — через контрольований шлюз з зворотним інспекційним проходом всієї інформації. Це окрема референсна архітектура (див. Cross-domain integration gateway).
Гранулярна модель прав
Тут UBD дає ключову перевагу. На прикладі особистої справи працівника охоронної компанії:
- HR-фахівець свого регіону бачить: ПІБ, дату народження, посаду, освіту, контактні дані, попередні посади
- Безпосередній керівник бачить додатково: оцінки атестацій, рекомендації, дисциплінарну історію, планові зміни
- HR центрального офісу бачить додатково: рекомендації до підвищення, кадровий резерв, плани переміщень
- Служба контролю бачить додатково: статус перевірок, матеріали інцидентів, внутрішні ризикові позначки
- Менеджер об’єкта бачить тільки свою команду та графік свого об’єкта — обмеження «по горизонталі»
Кожне з цих прав — окремо декларується у конструкторі форм UBD, без додаткового програмування. Оцінюється на кожен запит з контекстом (хто запитує, з якого підрозділу, у якому статусі знаходиться запит — стандартний перегляд чи перевірка).
Журналювання
Кожен перегляд кадрової картки — у журнал. Зміни — окремо. Запити служби контролю — у спеціальний журнал з обмеженим доступом. Спроби доступу до даних поза межами повноважень — у журнал інцидентів з негайним сповіщенням.
Підпис кадрових документів
Накази про призначення, переведення, звільнення, нагородження, дисциплінарні стягнення — підписуються ЕЦП. Юридично значимі дії — без виключень. Окреме питання — підпис документів керівника установи, що часто потребує організаційного супроводу (наявність керівника, перевірка ситуації).
§ 05 — Mapping відповідності
| Контроль | Норматив | Реалізація на UBD |
|---|---|---|
| Профіль захисту АС-2 / АС-3 | НД ТЗІ 2.5-004-99 | Г-3 для базової частини |
| Гранулярна авторизація до поля | NIST 800-207 Tenet 4 | Стандартна можливість |
| Захист персональних даних | GDPR Art. 32 + UA закон | Реалізовано |
| Журнал перегляду чутливих полів | NIST 800-53 AU-2 | Окремий журнал |
| Сегрегація обов'язків | NIST 800-53 AC-5 | У конструкторі форм |
| Контроль доступу адміністратора | Best practice | Окремий журнал для адмінів |
| Підтримка cross-domain | NIST 800-160 | Через окрему компоненту |
| Робота у air-gapped контурі | — | Стандартна можливість |
§ 06 — Що НЕ робимо у цій архітектурі
- Не biometric authentication через camera. Біометричні системи розпізнавання обличчя у кадровому контурі — окремий клас рішень з власними сертифікаційними вимогами. UBD інтегрується з ними через API, але не реалізує самі алгоритми розпізнавання.
- Не AI-аналітика особистих даних. Жодних spurious correlations на персональних даних. Платформа технічно дозволяє підключити ML-модель, але для кадрових даних це має проходити окрему правову та безпекову оцінку.
- Не публічний API для перевірки кадрового статусу. Усі запити — через автентифікованих користувачів з пройденими процедурами допуску. Інтеграції з зовнішніми системами — лише через спеціально верифіковані шлюзи.
§ 07 — Орієнтовний обсяг проекту
Кадрова система охоронної компанії на UBD — складніший проект ніж загальний документообіг через специфіку моделі прав. Типові терміни:
- Обстеження, моделювання прав, ТЗ — 6-12 тижнів
- Архітектура з урахуванням контурів, підготовка КСЗІ — 8-16 тижнів
- Розробка прикладного рішення — 9-15 місяців
- Міграція даних з існуючих систем — 3-6 місяців (паралельно)
- Розгортання — 6-12 тижнів
- Експертиза прикладної системи — 4-9 місяців
- Поетапна промислова експлуатація — 6-12 місяців
Загальний термін проекту — від 18 до 36 місяців. Бюджет — індивідуально, від кількох десятків мільйонів грн для типових випадків.