--- title: Механізми безпеки даних description: Єдина система автентифікації та авторизації, шифрування й хешування даних, а також підсистеми аудиту та моніторингу, що захищають дані в межах усієї платформи. section: Concepts weight: 2 related: - security/security-mechanisms - security - rest-api - eu-compliance --- ## Єдина система автентифікації та авторизації Єдина система автентифікації та авторизації — це ключовий компонент захисту даних, що забезпечує безпечний доступ до ресурсів системи. Вона дає змогу керувати користувачами, їхніми правами та доступом до даних на загальносистемному рівні. Нагадаємо: - **Автентифікація** — це процес перевірки особи користувача (наприклад, за іменем користувача та паролем). - **Авторизація** — це процес перевірки прав користувача на виконання певних дій (наприклад, доступ до даних або системних функцій). ### Компоненти системи #### Автентифікація - **Логін і пароль**: традиційний спосіб автентифікації. Під час входу користувач спершу має ідентифікувати себе за іменем користувача та паролем. - **Багатофакторна автентифікація** (MFA): використання кількох факторів (наприклад, програмного токена, що динамічно оновлюється, для вебінтерфейсу API). Автентифікація на основі токенів спрощує процес для постійних користувачів. Щоб розпочати роботу, користувач надсилає на сервер запит з іменем користувача та паролем. Сервер звіряє їх зі значеннями, зареєстрованими у своїй базі даних облікових записів. Якщо особу підтверджено, сервер повертає токен автентифікації (який також зберігається в базі даних). Коли той самий користувач згодом запитує доступ до захищених ресурсів, ці запити можна авторизувати за допомогою токена автентифікації замість імені користувача та пароля. Сервер звіряє токен із зареєстрованим у базі даних і надає доступ. #### Авторизація - **Ролі та права**: користувачам призначаються ролі (наприклад, адміністратор доступу, користувач), які визначають їхні права. - **ACL** (Access Control Lists): списки, що визначають, хто має доступ до яких ресурсів. - **RBAC** (Role-Based Access Control): керування доступом на основі ролей. - **ABAC** (Attribute-Based Access Control): керування доступом на основі атрибутів (наприклад, за часом доби або місцезнаходженням). #### Зберігання даних користувачів - **База даних користувачів**: зберігає інформацію про користувачів, їхні ролі та права в єдиній базі даних. #### Безпека - **Шифрування**: захищає дані під час передавання та зберігання. - **Токени доступу**: програмні токени, що динамічно оновлюються та використовуються для керування сеансами. - **Аудит**: журналювання всіх дій користувачів для подальшого аналізу. ### Реалізація системи Платформа використовує процес автентифікації на основі токенів. Користувач входить за логіном і паролем, система перевіряє їх і повертає токен доступу, після чого цей токен надсилається з кожним наступним запитом для авторизації доступу до захищених ресурсів. Як логін використовується адреса електронної пошти користувача. Приклад запиту у форматі `Curl`: ```bash title="Request example" curl -i --header "Content-Type: application/json" \ --request POST \ --data '{"email":"api@local.net","password":"Str0ngPas$"}'\ https://server123/api/v1/auth/sign_in ``` У відповідь ми отримуємо таке повідомлення: ```bash title="Response example" HTTP/1.1 200 OK X-Frame-Options: SAMEORIGIN X-XSS-Protection: 1; mode=block X-Content-Type-Options: nosniff X-Download-Options: noopen X-Permitted-Cross-Domain-Policies: none Referrer-Policy: strict-origin-when-cross-origin Content-Type: application/json; charset=utf-8 access-token: tgervk9_9xicJYpmSsnnNA token-type: Bearer client: D-Uv3ER53873olhnNLjL9w expiry: 1615227012 uid: api@local.net ETag: W/"5b9bcc76f7223b72b79d9f2d31ff0fd5" Cache-Control: max-age=0, private, must-revalidate X-Request-Id: c18e06b4-e5bd-40b5-875d-7ac958e2fbb5 X-Runtime: 0.391069 Transfer-Encoding: chunked {"data":{"id":6,"email":"api@local. net","provider":"email","uid":"api@local.net","name":"API user"}} ``` У цій відповіді нас цікавить параметр `access_token`. Значення цього заголовка використовується як пароль для кожного запиту і змінюється з кожним запитом. Ось приклад запиту, у якому використовується токен із попередньої відповіді: ```bash title="Request example with token" curl -i --header "access-token: tgervk9_9xicJYpmSsnnNA" \ --header "token-type: Bearer" \ --header "client: D-Uv3ER53873olhnNLjL9w" \ --header "uid: api@local.net" \ --request GET \ --header "Content-Type: application/json" \ --data '{"page":"2"}' \ https://server123/api/v1/stations ``` У відповідь ми отримуємо таке повідомлення: ```bash title="Response example" HTTP/1.1 200 OK X-Frame-Options: SAMEORIGIN X-XSS-Protection: 1; mode=block X-Content-Type-Options: nosniff X-Download-Options: noopen X-Permitted-Cross-Domain-Policies: none Referrer-Policy: strict-origin-when-cross-origin Content-Type: application/json; charset=utf-8 access-token: Bmh2GVrxr6aW0Hngor4gPw token-type: Bearer client: D-Uv3ER53873olhnNLjL9w expiry: 1615311367 uid: api@local.net ETag: W/"ba0df406b647bd92f0bf3a18916714c1" Cache-Control: max-age=0, private, must-revalidate X-Request-Id: 35a26441-ae78-48fa-8b2e-e92d2605133b X-Runtime: 0.167748 Transfer-Encoding: chunked {"data": [ {"id":1,"name":"865293041101853","equipment_brand_name":"Corrector BK","phone":"","equipment_id":1},... ], "total_pages":7, "current_page":2 } ``` Щоб завершити сеанс, можна скористатися процедурою `SignOut` або зберегти необхідні заголовки з останнього запиту й повторно використати їх наступного разу, якщо термін дії токена ще не минув. Зверніть увагу: без завершення сеансу останній токен залишається дійсним протягом певного часу, залежно від системних налаштувань сервера. ### Переваги системи Єдина система автентифікації та авторизації — це потужний інструмент захисту даних і контролю доступу. Вона забезпечує такі переваги: - **Централізоване керування**: спрощує керування користувачами та їхніми правами. - **Безпека**: захищає дані від несанкціонованого доступу. - **Узгодженість**: усі застосунки та системи використовують єдиний механізм автентифікації та авторизації. - **Масштабованість**: дає змогу легко додавати нові застосунки та користувачів. ## Шифрування даних Для захисту критично важливої інформації система використовує шифрування (перетворення інформації у форму, яку неможливо прочитати без відповідного ключа) і хешування (перетворення даних на унікальний рядок фіксованої довжини — хеш). Це один із ключових механізмів захисту даних, що забезпечує конфіденційність, цілісність і безпеку інформації як під час зберігання, так і під час передавання. Система використовує різні алгоритми шифрування та хешування даних. ### Застосування шифрування в системі #### Шифрування під час зберігання - **Бази даних**: шифрування окремих полів бази даних. - **Файли**: шифрування файлів перед збереженням на диск. #### Шифрування даних під час передавання - **HTTPS**: використання SSL/TLS для шифрування даних під час передавання мережею. - **VPN**: створення захищеного тунелю для передавання даних. #### Шифрування паролів Зберігання хешів паролів замість самих паролів. ### Приклади шифрування та розшифрування даних Розгляньмо приклади шифрування та розшифрування системних конфігураційних файлів. #### Шифрування даних ```ruby title="example.config" mkdir_p(encrypted_dir_path) encrypted = Rails.application.encrypted(encrypted_file_path, key_path: 'config/system.key') encrypted.write(File.read(decrypted_file_path)) File.delete(decrypted_file_path) ``` #### Розшифрування даних ```ruby title="example.config" mkdir_p(decrypted_dir_path) File.write(decrypted_file_path, Rails.application.encrypted(encrypted_file_path, key_path: 'config/system.key').read ) ``` ### Переваги шифрування даних - **Конфіденційність**: захист даних від несанкціонованого доступу. - **Цілісність**: гарантія того, що дані не були змінені. - **Автентичність**: підтвердження джерела даних. - **Відповідність вимогам**: дотримання нормативних вимог. ## Аудит і моніторинг Кілька підсистем відстежують активність користувачів і системи, виявляють підозрілу поведінку та забезпечують дотримання вимог безпеки. Разом вони: - збирають, аналізують і зберігають інформацію про активність користувачів і системи для забезпечення підзвітності та відповідності; - безперервно відстежують систему та обладнання в реальному часі для виявлення інцидентів і реагування на них. ### Завдання - **Підзвітність**: гарантія того, що вся активність користувачів і системи реєструється. - **Безпека**: виявлення та запобігання несанкціонованій активності. - **Виявлення проблем**: виявлення апаратних проблем та аномалій і вжиття коригувальних заходів. - **Оптимізація продуктивності**: аналіз продуктивності системи та пошук вузьких місць, що потребують оптимізації. - **Прогнозування та планування**: збір даних для прогнозування майбутніх навантажень і планування ресурсів. - **Відповідність**: забезпечення дотримання нормативних вимог. - **Аналіз інцидентів**: аналіз інцидентів, що сталися, для запобігання майбутнім. ### Компоненти аудиту та моніторингу #### Збір даних - **Журнали**: записи про дії користувачів і системи на всіх рівнях. - **Метрики**: дані про продуктивність системи (наприклад, завантаження процесора, використання пам'яті). #### Зберігання даних - **Сховище журналів**: збір даних із різних джерел із розподіленим зберіганням журналів і метрик, упорядкованих за тематичними напрямами. - **Ротація журналів**: автоматичне видалення старих журналів для економії місця. #### Аналіз даних - **Пошук і фільтрація**: можливість пошуку та фільтрації журналів за різними критеріями. - **Аналітика**: використання інструментів аналізу даних (наприклад, Zabbix). #### Сповіщення - **Сповіщення**: надсилання повідомлень про підозрілу активність і надзвичайні ситуації (наприклад, електронною поштою або в чат Telegram). - **Автоматичні дії**: автоматичне реагування на інциденти (наприклад, блокування користувача). ### Приклад реалізації #### Журналювання Використання бібліотеки для журналювання в застосунку. ```ruby title="Ruby on Rails" # Logs all changes to models gem "audited" # Logging settings Audited.config do |config| config.audit_class = CustomAudit end class CustomAudit < Audited::Audit default_scope { order(created_at: :desc) } ACTION_NAME = { 'Create' => 'create', 'Update' => 'update', 'Destroy' => 'destroy' }.freeze end # Metering device class Equipment < ApplicationRecord audited except: [:password] ... end ``` #### Збір помилок у даних від лічильників ```ruby title="Ruby on Rails" # data model for error collection class ErrorLog < ApplicationRecord enum message: { invalid_equipment_serial_number: 0, invalid_equipment_software_version: 1, ... } belongs_to :loggable, polymorphic: true belongs_to :loggable_equipment, class_name: 'Equipment', foreign_key: :loggable_id, optional: true validates :loggable_type, :loggable_id, :message, presence: true end # Event log unless valid_value?(serial_number) message_params = {equipment: equipment, new_serial_number: serial_number} message2logger(loggable_obj: equipment, message: :invalid_equipment_serial_number, params: message_params) end ``` #### Зберігання журналів Використання централізованого сховища для журналів. ##### Таблиця `audits` У цій таблиці зберігається інформація про журналювання даних. | Поле | Тип | Опис | | ----------------- | -------------------------------- | -------------------------------------------------------------------- | | `id` | `integer` | Унікальний ідентифікатор запису (первинний ключ). | | `auditable_id` | `integer` | Посилання на аудитований об'єкт (`equipment.id`, `stations.id` ...). | | `auditable_type` | `character varying` | Аудитований об'єкт (`equipment`, `stations` ...). | | `user_id` | `integer` | Посилання на ідентифікатор користувача (`users.id`) | | `action` | `character varying` | Дія | | `audited_changes` | `jsonb` | Аудитовані зміни | | `version` | `integer` | Версія змін | | `remote_address` | `character varying` | Віддалена адреса | | `request_uuid` | `character varying` | Ідентифікатор події. | | `created_at` | `timestamp(6) without time zone` | Дата/час зміни. | ##### Таблиця `error_logs` У цій таблиці зберігається інформація про помилки в даних, що надходять від лічильників. | Поле | Тип | Опис | | --------------- | -------------------------------- | -------------------------------------------------------- | | `id` | `integer` | Унікальний ідентифікатор запису (первинний ключ). | | `loggable_id` | `integer` | Посилання на зареєстрований об'єкт (`equipment.id` ...). | | `loggable_type` | `character varying` | Зареєстрований об'єкт (`equipment` ...). | | `message` | `integer` | Посилання на ідентифікатор помилки. | | `params` | `jsonb` | Характеристики помилки. | | `created_at` | `timestamp(6) without time zone` | Дата/час зміни. | #### Аналіз журналів Інструменти, що використовуються для аналізу журналів: - Налаштування вебформ для візуалізації та аналізу журналів. - Створення інформаційних панелей для моніторингу активності користувачів. #### Сповіщення Налаштовані сповіщення про підозрілу активність: - Налаштування сповіщень у Zabbix для моніторингу метрик. - Надсилання повідомлень електронною поштою або в чат Telegram про аварійні події. #### Переваги аудиту та моніторингу Аудит і моніторинг — це потужні інструменти захисту даних, що дають змогу відстежувати активність користувачів і системи, виявляти підозрілу поведінку та забезпечувати дотримання вимог безпеки. Вони дають змогу: - забезпечити підзвітність і безпеку даних; - виявляти інциденти та запобігати їм; - дотримуватися нормативних вимог.