Аудит безпеки

Назва Критичність

SC-01. RBAC (Role Based Access Control) на моделі даних

Висока

SC-02. RLS (Row Level Security) на моделі даних

Висока

SC-03. Персональні дані

Висока

SC-04. Налаштування ролей для доступу до бізнес-процесів

Висока

При розробці регламенту реєстру глобально моделювальник може впливати на 2 аспекти з безпеки:

  • Збереження певної інформації в системі

  • Надання прав доступу то певної інформації в системі

Сервіси, в які може бути збережена інформація і яка залежить від дій та рішень розробника регламенту:

  • Підсистема управління даними реєстру - безпосередньо дані реєстру, схема яких визначається в моделі даних. Зміна даних відбувається через виконання бізнес-процесів у Сервісі виконання бізнес-процесів. Читання даних може відбуватися:

    • Через бізнес-процеси у Сервісі виконання бізнес-процесів

    • Через кабінети користувача для інтеграції з компонентами Select у користувацьких формах. Як наслідок будь-який автентифікований користувач в кабінеті може виконати запит на АПІ реєстру через браузер і отримати доступ до даних з критерію пошуку чи таблиці до яких має доступ навіть, якщо це не передбачено наявністю форму і відповідного компонента

    • Через Підсистему зовнішніх інтеграцій:

      • Через використання шини безпечного обміну "Трембіта" як захищеного транспорту.

      • Через налаштування прямих інтеграцій з зовнішніми системами, які не є учасниками інформаційного обміну СЕВДЕІР "Трембіта".

      • Через налаштування прямих інтеграцій з реєстрами, які розгорнуті на одному екземплярі Платформи Реєстрів.

      • Через публічно-доступний API

  • Підсистема управління користувачами та ролями - збереження в атрибутах користувача певної інформації

  • Сервіс виконання бізнес-процесів - збереження в сталих (persistent) змінних бізнес-процесів певної інформації

  • Підсистема журналювання подій - логування в скриптових задачах бізнес-процесу певної інформації

Права доступу можуть і повинні бути налаштовані на рівні:

  • Бізнес-процесів. Надання певним ролям доступу до певних бізнес-процесів

  • Моделі даних

    • RBAC. Надання певним ролям прав на виконання певних операцій над даними таблиць, колонок та критеріїв пошуку

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

При моделюванні слід керуватися наступними принципами:

  • Принцип найменших привілеїв

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

  • Мінімізація ролей з розширеними правами

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

  • Принцип розділення обов’язків

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

  • Мінімізація інформації, яка необхідна для функціонування реєстру

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

SC-01. RBAC (Role Based Access Control) на моделі даних

Критичність: висока
Опис

Для забезпечення безпеки даних та гранулярності доступу до даних використовувати механізм RBAC (Role Based Access Control) на рівні моделі даних. RBAC дозволяє обмежити доступ до певних таблиць, критеріїв пошуку та атрибутів сутності (колонок таблиці) залежно від ролі користувача.

Вплив

  • Зменшення ризику несанкціонованого доступу. Дані мають додатковий рівень захисту:

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

    • На рівні бізнес-процесу у разі зловживань або помилок виконуються додаткові перевірки доступності операції.

  • Несанкціонована зміна даних: Можливість надання користувачу доступ тільки на читання на рівні дата моделі зменшує шанс несанкціонованої зміни даних.

Рекомендації

  • Створити матрицю контролю доступу ролей до даних реєстру на рівні таблиць, критеріїв пошуку та колонок. Тобто для кожної ролі повинен бути визначений перелік даних реєстру, до якої можливий доступ

  • Переглянути, чи всі ролі мають мінімальний необхідний доступ до даних. За необхідністю, розділити ролі на більш гранулярні для зменшення прав

  • Застосувати RBAC правила на рівні моделі даних за допомогою відповідних тегів відповідно матриці контролю доступу ролей

SC-02. RLS (Row Level Security) на моделі даних

Критичність: висока
Опис

Для забезпечення гранулярного доступу до даних слід використовувати механізм RLS (Row Level Security). RLS дозволяє обмежити доступ для читання до певних рядків (сутностей) на основі зазначеного атрибута користувача. Наприклад, розділити доступ до даних за підрозділом організації, до якого належить користувач.

Вплив

  • Зменшення ризику витоку даних: Для отримання доступу до всіх даних необхідно широка площа атаки на всіх користувачів.

  • Підвищення контролю доступу: Кількість отриманих даних примусово обмежується за атрибутами користувача, які були йому надані у Підсистемі управління користувачами та ролями

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

    • На рівні бізнес-процесу у разі зловживань або помилок виконуються додаткові перевірки доступності даних.

Рекомендації

  • Визначити таблиці та критерії пошуку, інформація з яких не повинна бути цілком доступна для коректного функціонування системи. Іншими словами, користувач повинен мати доступ тільки до обмеженої підмножини рядків (1 чи декілька). Для прикладу:

    • Користувачу треба мати можливість працювати зі своїми персональними даними. Для цього випадку слід налаштувати RLS правило за атрибутом, який ідентифікує такого користувача. Наприклад, ДРФО

    • Користувачу треба мати можливість працювати з даними своєї організації. Для цього випадку слід налаштувати RLS правило за атрибутом, який ідентифікує організацію. Наприклад, ЄДРПОУ чи КАТОТТГ

  • Застосувати RLS правила на рівні моделі даних за допомогою відповідних тегів

SC-03. Персональні дані

Критичність: висока
Опис

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

Вплив

  • Ризик витоку даних: Збільшується ймовірність витоку персональних даних, якщо база даних буде скомпрометована.

  • Збільшення цілей для атак: Збільшена кількість персональних даних у системі робить її більш цінною ціллю для зловмисників.

  • Ускладнення відновлення: У випадку втрати даних буде важче відновити систему без ризику для персональної інформації.

  • Недотримання законодавчих та нормативних вимог: Збільшення ймовірності виникнення проблеми з дотриманням вимог законодавства щодо захисту персональних даних.

Рекомендації

  • Ідентифікація даних: Визначити, яка інформація, що зберігається в реєстрі, може вважатися персональною. Наприклад:

    • Ідентифікаційні дані: ім’я, прізвище, по батькові, дата народження, ідентифікаційний код, номер паспорта.

    • Контактні дані: адреса проживання, номер телефону, електронна пошта.

    • Фінансові дані: номери банківських рахунків, кредитних карток, інформація про доходи, податкові дані.

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

    • Онлайн-дані: IP-адреси, файли cookie, історія браузера, дані акаунтів у соціальних мережах.

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

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

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

  • Уникнення персистентних змінних: Не зберігати персональну інформацію в персистентних змінних Сервісу виконання бізнес-процесів. Це допоможе запобігти випадковому зберіганню даних у місцях, де вони можуть стати доступними для сторонніх осіб.

  • Логування: Уникати логування персональних даних у скриптових задачах Сервісу виконання бізнес-процесів. Якщо логування необхідне, слід забезпечити, щоб дані були анонімізовані або зашифровані.

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

    • На рівні бізнес-процесів. Визначити, які бізнес-процеси працюють з персональними даними й обмежити по максимуму перелік ролей, які повинні мати змогу запускати й мати участь у таких бізнес-процесах

    • RBAC на рівні моделі даних. Визначити, які критерії пошуку та таблиці містять персональні дані й додати RBAC правила до відповідних ролей (SC-01. RBAC (Role Based Access Control) на моделі даних)

    • RLS на рівні критеріїв пошуку та роботи з таблицями. Обмежити кількість записів, які можуть бути отримані в критерії пошуку за допомогою RLS (SC-02. RLS (Row Level Security) на моделі даних)

SC-04. Налаштування ролей для доступу до бізнес-процесів

Критичність: висока
Опис

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

Вплив

  • Збільшення ризику несанкціонованого доступу: Якщо ролі надаються занадто широкі права, користувачі можуть отримати доступ до інформації або функцій, які повинні бути обмежені.

  • Несанкціонована зміна даних: Користувачі можуть внести зміни в дані або конфігурацію, що може призвести до неправильної роботи регламенту.

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

Рекомендації

  • Необхідно розробити та поставити процес регулярного огляду налаштувань прав доступу, щоб гарантувати, що кожна роль має лише відповідні права.

  • Завжди надавати ролям мінімум необхідних прав