Дослідження методів захисту інформації в автоматизованих системах

Крутіков, Микола Олексійович
Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/6328
Full metadata record
DC Field	Value	Language
dc.contributor.advisor	Нечипоренко, Ольга Володимирівна	-
dc.contributor.author	Крутіков, Микола Олексійович	-
dc.date.accessioned	2022-01-17T13:25:48Z	-
dc.date.available	2022-01-17T13:25:48Z	-
dc.date.issued	2022-01	-
dc.identifier.uri	https://er.chdtu.edu.ua/handle/ChSTU/6328	-
dc.description.abstract	Предмет роботи – впровадження багаторівневих моделей безпеки у сучасних системах та застосування сучасних методів інформаційної безпеки та методів безпеки інформації. Мета роботи – створити та описати методи моделювання різних підходів до багаторівневої безпеки, які дозволяють проаналізувати властивості цих підходів. За результатами роботи представлене дослідження із застосуванням змодельованих систем з багаторівневою безпекою БД. Проведено аналіз сучасних методів захисту АІС. Досліджено методи захисту в системі з багаторівневим захистом. Створено проект в якому реалізовано сучасні методи захисту. Результати роботи показали що найпростіші та найкращі моделі багаторівневого захисту є моделі Smith-Winslett та Multilevel Relational. Вони підходять для застосування сучасних систем із багаторівневою безпекою, в тому числі для систем спеціального призначення.	uk_UA
dc.language.iso	uk	uk_UA
dc.title	Дослідження методів захисту інформації в автоматизованих системах	uk_UA
dc.type	Master Thesis	uk_UA
Appears in Collections:	174 Автоматизація, комп'ютерно-інтегровані технології та робототехніка (Автоматизація та комп'ютерно-інтегровані системи та компоненти)
Files in This Item:
File	Description	Size	Format
М_151_2021_Крутіков.pdf Restricted Access		844.49 kB	Adobe PDF	View/Open Request a copy
Show simple item record
Extracted text
 
 
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
 ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ 
КАФЕДРА РОБОТОТЕХНІКИ ТА СПЕЦІАЛІЗОВАНИХ КОМП’ЮТЕРНИХ 
СИСТЕМ 
Пояснювальна записка 
до кваліфікаційної роботи 
освітнього ступеня «магістр» 
на тему: ДОСЛІДЖЕННЯ МЕТОДІВ ЗАХИСТУ ІНФОРМАЦІЇ В 
АВТОМАТИЗОВАНИХ СИСТЕМАХ 
 
 
 
 
 Виконав: студент 2 курсу, групи МАКІТ-2009 
 спеціальності 151 Автоматизація та 
ком’ютерно-інтегровані технології 
(освітня програма «Ком’ютерно-
інтегровані  технологічні процеси і 
виробництва») 
 Крутіков М.О. 
 (прізвище та ініціали) 
Керівник Нечипоренко О.В. 
 (прізвище та ініціали) 
Рецензент . 
 (прізвище та ініціали) 
 
 
 
 
Черкаси 2021 року 
2 
 
ЗМІСТ 
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, ОДИНИЦЬ, СКОРОЧЕНЬ І 
ТЕРМІНІВ .................................................................................................................... 3 
ВСТУП ......................................................................................................................... 4 
РОЗДІЛ 1 СТАН ПРЕДМЕТУ ДОСЛІДЖЕННЯ ТА ФОРМУЛЮВАННЯ 
ЗАДАЧ .......................................................................................................................... 7 
1.1 Основні поняття інформаційної безпеки ......................................................... 7 
1.2 Методи захисту АІС .......................................................................................... 9 
1.3 Типи контролю доступу АІС .......................................................................... 10 
1.4 Формулювання проблемних задач дослідження .......................................... 14 
Висновки ................................................................................................................. 15 
РОЗДІЛ 2 АНАЛІЗ МОДЕЛЕЙ БАГАТОРІВНЕВОЇ БЕЗПЕКИ ......................... 16 
2.1 Огляд моделей із багаторівневою безпекою ................................................. 19 
2.2 Алгоритми операцій для впровадження моделей ......................................... 23 
2.3 Недоліки моделей багаторівневої безпеки .................................................... 39 
2.4 Дослідження продуктивності використання багаторівневих моделей 
захисту АІС ............................................................................................................. 40 
Висновки ................................................................................................................. 43 
РОЗДІЛ 3 ДОСЛІДЖЕННЯ ТЕХНОЛОГІЙ БАГАТОРІВНЕВОГО ЗАХИСТУ 
ІНФОРМАЦІЇ В АІС ................................................................................................. 45 
3.1 Складові проекту .............................................................................................. 45 
3.2. Стек технологій ............................................................................................... 45 
3.3 Процес взаємодії з АІС .................................................................................... 63 
Висновки ................................................................................................................. 66 
ВИСНОВКИ ............................................................................................................... 68 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ................................................................. 69 
ДОДАТОК А .............................................................................................................. 72 
 
  
3 
 
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, ОДИНИЦЬ, 
СКОРОЧЕНЬ І ТЕРМІНІВ 
DAC – Discretory Access Control – дискреційне управління доступом; 
DBA – Database Administrator – адміністратор баз даних; 
MAC – Mandatory Access Control – мандатне управління доступом; 
MLR – Multilevel Relational – багаторівнева реляційна (модель); 
MLS – Multilevel Security – багаторівнева безпека; 
RBAC – Role based Access Control – рольове управління доступом; 
RDB – Relational Databases  – реляційні бази даних; 
RDBMS – Relational Databases Management System – система управління 
реляційними базами даних; 
SQL – Structured Query Language – мова структурованих запитів; 
TC – Тuple classifier – класифікатор запису – рівень безпеки запису. 
АІС – автоматизована інформаційна система 
ІТ – інформаційні технології 
СУБД – системи управлінням бази даних; 
  
4 
 
ВСТУП 
На сьогоднішній день існує багато компаній, які мають власні 
автоматизовані інформаційні системи, а більшість державних органів мають 
складні системи реєстрації та обліку та продовжують активно працювати над 
створенням електронних сховищ даних, аналітичних та звітних систем, тому 
кількість баз даних, що містять конфіденційну інформацію, постійно зростає. 
Потреба в захисті інформації є завжди, незалежно від того, чи це база даних з 
персональними даними клієнтів чи інформаційна система банку. Тому питання 
безпеки інформації є досить актуальним. 
У більшості випадків в сучасних АІС відсутній належний захист 
конфіденційної інформації в інформаційних системах, оскільки для цього 
необхідний підхід, що дозволяє більш гнучко розмежовувати доступ для 
працівників різних професій. Тому необхідно впроваджувати багаторівневі 
системи безпеки АІС.  
Безпечне управління конфіденційними даними є важливою проблемою в 
сучасних організаціях. Багаторівневі системи пропонують єдиний підхід до 
безпеки, який передбачає різні рівні безпеки даних у базах даних АІС.  
Метою АІС є обмін даними з різними рівнями безпеки та запобігання 
несанкціонованому доступу до них. Багаторівневі моделі безпеки зберігають 
інформацію на різних рівнях безпеки окремо, щоб запобігти несанкціонованому 
доступу до даних користувачів на різних рівнях.  
У даній роботі розглядаються моделі багаторівневої безпеки та сучасні 
методи захисту інформації в АІС. 
Мета дослідження: створити та описати методи моделювання різних 
підходів до багаторівневої безпеки, які дозволяють проаналізувати властивості 
цих підходів.  
Були поставлені такі завдання: 
проаналізувати сучасні методи захисту АІС; 
провести дослідження продуктивності використання багаторівневих 
моделей захисту АІС; 
5 
 
виявити сильні та слабкі сторони багаторівневих моделей захисту АІС; 
дослідити методи захисту в системі з багаторівневим захистом; 
Об'єкт дослідження: багаторівневі моделі безпеки та сучасні методи 
безпеки інформації. 
Предмет дослідження: впровадження багаторівневих моделей безпеки у 
сучасних системах та застосування сучасних методів інформаційної безпеки.  
Для розв’язання поставлених завдань були використані теорії аналізу 
та синтезу, моделювання та формалізації.  
Наукова новизна одержаних результатів: 
1) зроблений порівняльний аналіз продуктивності використання моделей 
багаторівневого захисту; 
2) спроектовано складові проекту дослідження багаторівневого захисту 
та реалізовано його. 
Практичне значення одержаних результатів. 
Практична цінність виконання поставлених задач полягає в можливому 
подальшому застосуванні їх для моделей багаторівневої безпеки АІС 
загального та спеціального призначення. Зроблений порівняльний аналіз 
продуктивності використання моделей багаторівневого захисту показує яка 
модель краща для застосування в майбутніх АІС. 
Апробація результатів роботи. 
Результати роботи доповідалися й обговорювалися на студентських і 
наукових конференціях: 
− дні студентської науки ЧДТУ, 27-30 квітня, м. Черкаси, Україна, 2020; 
− дні студентської науки ЧДТУ, 19-22 квітня, м. Черкаси, Україна, 2021; 
− ІV Всеукраїнська науково-практична інтернет-конференція «Сучасні 
технології в енергетиці, електромеханіці, системах управління та 
машинобудуванні», 25-26 листопада, м. Бахмут, Україна, 2021. 
  
6 
 
Публікації. 
Результати досліджень опубліковані в тезах доповідей: 
1. Крутіков М. О. Дослідження автоматизованих систем управління 
ресурсами підприємства / М. О. Крутіков, О. В. Нечипоренко, С. А. Міценко // 
Збірник тез доповідей студентської науковопрактичної конференції ЧДТУ: 19–
22 квітня 2021 р. [Електронний ресурс] / [упоряд. Мельник І.В.]; Мво освіти і 
науки України, Черкас. держ. технол. унт. – Черкаси : ЧДТУ, 2021. – C. 126-
127. 
2. Нечипоренко О. В. Дослідження методів захисту інформації в 
автоматизованих системах / О. В. Нечипоренко, М. О. Крутіков // Сучасні 
технології в енергетиці, електромеханіці, системах управління та 
машинобудуванні: Матеріали ІV Всеукраїнської науково-практичної інтернет-
конференції (м. Бахмут, 25-26 листопада 2021 р.) / Навчально-науковий 
професійно-педагогічний інститут Української інженерно-педагогічної академії 
[упоряд. П.О. Чикунов]. – Бахмут: ННППІ УІПА, 2021. – С. 122-123. 
Структура та обсяг кваліфікаційної роботи.  
Кваліфікаційна робота магістра складається з вступу, 3 розділів, 
висновків та списку використаних джерел та додатку. Робота викладена на 
71 сторінці. Ілюстрована 22 рисунками та має  6 таблиць. Список використаних 
джерел містить 24 найменування. Робота має один додаток викладений на 33 
сторінках. 
   
7 
 
РОЗДІЛ 1 СТАН ПРЕДМЕТУ ДОСЛІДЖЕННЯ ТА 
ФОРМУЛЮВАННЯ ЗАДАЧ 
1.1 Основні поняття інформаційної безпеки 
 
1.1.1 Політика безпеки 
Політика безпеки - це документ, який описує, як захистити організацію 
від загроз, включаючи загрози комп’ютерній безпеці, і як поводитися в 
ситуаціях, коли вони виникають. Політика безпеки повинна виявити всі активи 
підприємства, а також будь-які потенційні загрози цим активам. 
Політика безпеки окреслює ключові елементи в організації, які необхідно 
захистити. До цього можна віднести мережу підприємтсва, її фізичну будівлю 
тощо. Вона також повинна підкреслити потенційні загрози для цих елементів.  
Якщо документ зосереджується на кібербезпеці, загрози можуть включати в  
себе також можливість загрози зсередини, наприклад, незадоволені  
співробітники викрадуть важливу інформацію або запустять внутрішній вірус у  
мережі компанії. Ззовні організації хакери можуть проникнути в систему і 
спричинити втрату даних, зміни або їх викрадення. Нарешті, можуть виникнути 
фізичні пошкодження комп'ютерних систем. 
Політика безпеки інформаційних технологій (ІТ) встановлює правила та 
процедури для всіх осіб, які мають доступ до ІТ та ресурсів організації. Таким 
чином, ефективна політика безпеки ІТ – це унікальний для кожної організації 
документ, створений відповідно до ризику втрати чи витоку інформації, що 
зберігається і передається, а також відповідно до цінності інформації. [18] 
 
1.1.2 Властивості безпеки інформації 
Метою політики безпеки ІТ є збереження основних властивостей безпеки 
інформації, якими є: 
• Конфіденційність передбачає захист активів від несанкціонованого 
доступу;  
8 
 
• Цілісність гарантує, що зміна активів здійснюється у визначеному та 
уповноваженому порядку; 
• Доступність - це стан системи, в якій уповноважені користувачі мають 
постійний доступ до цих активів; 
• Спостережність - підтримка спостережності ресурсів, систем, що 
дозволяє встановлювати суб'єкти, що проводять дії над об’єктами, а 
також оперативно  реагувати на всі дії з метою мінімізації втрат. 
 
1.1.3 Контроль доступу 
Контроль доступу - це фундаментальна концепція безпеки, яка регулює, 
хто або що може переглядати або використовувати ресурси в обчислювальному 
середовищі, щоб мінімізувати ризики для бізнесу або організації. 
Існує два види контролю доступу: фізичний і логічний. Фізичний 
контроль доступу обмежує доступ до кампусів, будівель, приміщень та 
фізичних ІТ-активів. Логічне управління визначає підключення до системних 
даних і файлів, комп'ютерних мереж та інших логічних ресурсів комп'ютера. 
Щоб захистити дані, організації використовують електронні процедури 
контролю доступу, які використовують зчитувачі карток доступу, облікові дані 
користувачів, аудит і звіти для відстеження доступу співробітників до певних 
приміщень і будівель, таких як центри обробки даних. Більшість систем 
контролю доступу використовують панелі контролю доступу для обмеження 
доступу до будівель і приміщень, а також можливості блокування та 
сигналізації для обмеження несанкціонованих транзакцій або доступу. 
Системи контролю доступу використовують аутентифікацію та 
авторизацію користувачів та організацій, оцінюючи необхідні облікові дані, які 
можуть включати паролі, персональні ідентифікаційні номери (PIN), 
біометричні сканування, маркери безпеки або інші фактори аутентифікації. 
Багатофакторна аутентифікація, яка вимагає двох або більше факторів 
аутентифікації, часто є важливою частиною багаторівневого захисту для 
захисту систем контролю доступу[16]. 
9 
 
Системи контролю доступу працюють шляхом ідентифікації 
співробітника або організації, перевірки того, що працівник або додаток 
ідентифікуються, і дозволу на виконання набору дій і рівнів доступу, 
пов’язаних з обліковими даними. Протоколи та служби каталогів, такі як 
протокол доступу до локального каталогу (LDAP), пропонують механізми 
контролю доступу за допомогою авторизації та аутентифікації окремих осіб і 
співробітників. Крім того, системи контролю доступу дозволяють користувачам 
використовувати організаційні ресурси, такі як веб-сервери та розподілені 
програми. 
 
1.2 Методи захисту АІС 
Серед сучасних методів захисту АІС виявляють: 
• Аутентифікація може визначатись як концепція перевірки ідентичності 
користувача, який повинен мати доступ до реляційної бази даних. 
Кожен користувач повинен ідентифікувати себе перед тим, як мати 
доступ до даних, що зберігаються в системі реляційної бази даних.  
Автентифікація відбувається на різних рівнях, наприклад, 
автентифікація може виконуватися самою реляційною базою даних 
або іншим зовнішнім методам автентифікації користувачів. 
• Керування доступом (авторизація) можна визначити як правила, які 
визначають, чи має користувач доступ до даних у відповідній базі 
даних. Правила авторизації керують зміною даних у реляційній базі 
даних. Управління доступом - це процедури, які визначаються для 
керування авторизацією даних у реляційній базі даних. 
• Шифрування – перетворення даних в шифровану форму, з метою 
приховування інформації  
• Логування – дозволяє встановити користувача, який проводив 
маніпуляції з інформацією в БД: 
 
  
10 
 
1.3 Типи контролю доступу АІС 
Механізм контролю доступу забезпечує конфіденційність даних. Перш 
ніж сутність спробує отримати доступ до об’єкта даних, механізм контролю 
доступу перевіряє права користувача на набір авторизації, який зазвичай 
вказується адміністратором безпеки. Контроль доступу гарантує, що весь 
прямий доступ до об'єктів бази даних буде здійснюватися тільки відповідно до 
правил, що регулюють політику безпеки. 
Запобігання несанкціонованому доступу до реляційної бази даних AIS є 
основною метою впровадження безпечної системи керування 
автоматизованими системами. 
Більшості користувачів автоматизованих інформаційних систем для 
виконання своїх завдань потрібен лише спеціальний дозвіл на деякі частини 
реляційної бази даних. Не бажано надавати доступ до частин баз даних, де 
зберігається конфіденційна інформація. Тому політика безпеки повинна бути 
ефективною, щоб дозволити групі користувачів отримати доступ лише до 
необхідних частин бази даних. 
Після того, як політика безпеки була розроблена, її необхідно реалізувати 
для досягнення необхідного рівня безпеки. Три основні підходи в СУБД до 
контролю доступу – це дискреційний контроль доступу, контроль доступу на 
основі мандатів і контроль доступу на основі ролей. 
Підходи для здійснення контролю доступу в реляційних базах даних 
описані наступним чином: 
• Керування доступом на основі представлень: відношення - це фізична 
локація в реляційній базі даних, яка зберігає дані в реляційній базі 
даних. 
Представлення - це логічний набір збережених запитів до бази даних. На 
відміну від фізичної таблиці реляційної бази даних, представлення — це 
логічна таблиця, яка динамічно створюється з даних у реляційній базі даних під 
час запиту. 
11 
 
• Модифікація запитів: запит, записаний користувачем, змінюється, щоб 
включати обмеження, визначені привілеями користувача. 
Наприклад, DBA дає користувачеві A можливість вибирати з таблиці 
співробітників тільки співробітників, які перебувають у відділі краєзнавства. 
Коли А робить запит до таблиці, він отримує інформацію лише про дані, які 
стосуються працівників цього відділу. 
 
1.3.1 Дискреційний контроль доступу 
Дискреційний контроль доступу (DAC) заснований на наданні та 
відкликанні привілеїв на використання системних об’єктів (представлень, 
стовпців тощо). Привілеї надаються (або скасовуються) кожному об’єкту 
(користувачу, обліковому запису, програмі) окремо. 
Дискреційні політики контролю доступу дозволяють розподіляти права 
доступу від одного об’єкта до іншого. Це називається дискреційним у тому 
сенсі, що власник даних має повне право надавати/відкликати доступ до своїх 
даних. У DAC надання або скасування привілеїв може виконуватися 
адміністратором бази даних (DBA). [12] 
Типи привілеїв DAC описані таким чином: 
• Привілеї облікового запису: Кожен користувач має привілеї, які не 
залежать від відношень у базі даних. Наприклад, DBA надає / 
відкликає привілеї користувачеві для CREATE TABLE, CREATE 
VIEW, DROP і ALTER. 
• Привілеї відношення: адміністратор баз даних може вказати привілей 
для зміни кожного окремого співвідношення у реляційній базі даних. 
Наприклад, DBA надає/відкликає привілеї SELECT/MODIFY/ 
REFERENCE на конкретне відношення R. 
• Дискреційні контролі доступу можуть надаватися багатьом об'єктам у 
системі реляційної бази даних, таким як база даних, група відношень, 
одне відношення, набір атрибутів одного відношення і група записів 
одного відношення. 
12 
 
DAC має деякі недоліки при застосуванні до реляційної бази даних: 
• Застосування політики безпеки: використання DAC залежить від 
концепції володіння даними в підприємстві. В DAC користувач, який 
створює об'єкт у реляційній базі даних, є власником цього об'єкта і 
може надавати доступ іншим користувачам до цього об'єкта. Недолік 
цього полягає в тому, що підприємство не може забезпечувати 
виконання своїх вимог щодо безпеки, бо не може контролювати дії 
всіх користувачів, які створюють об'єкти в реляційній базі даних та 
надають дозволи на них. 
• Каскадна авторизація: розглянемо ситуацію, коли є три користувачі: 
U1, U2 і U3. Користувач U2 має привілей на об'єкт O від U1 і надає цей 
привілей U3. Пізніше U1 надає привілей U3 на об'єкт O, але U2 з 
певних причин відкликає привілей від привілеїв U3. В результаті цих 
операцій U3 все ще має права доступу (від U1) до об'єкта O, хоча U2 
скасував йому можливість отримання доступу 
• Атаки троянських коней: Троянський кінь може використовуватися 
для надання певного привілею користувача об'єкту іншому 
користувачеві, не маючи жодної інформації про цього користувача. 
• Проблеми оновлення: У DAC захист на основі представлення є 
логічним запитом, який не має фізичних даних у реляційній базі даних. 
Недоліком захисту на основі представлення є те, що не всі дані 
оновлюються. 
 
1.3.2 Мандатний контроль доступу 
Мандатний контроль доступу (MAC) – це метод обмеження доступу 
користувача до об’єктів, які містять певну конфіденційну інформацію. 
MAC залежить від рівня безпеки, пов’язаного з кожним об’єктом у 
відповідній базі даних і кожним користувачем. Рівень безпеки на об'єкті 
визначається як класифікація безпеки, а рівень безпеки для користувача 
визначається як дозвіл безпеки. Реалізація MAC є багаторівневою безпекою 
13 
 
(MLS), яка була розроблена в основному для комп’ютерних систем і систем баз 
даних в державних організаціях, таких як розвідувальні служби або 
Міністерство оборони. 
Контроль доступу наказу оцінює взаємозв’язок домінування між мітками 
безпеки користувача та мітками безпеки об’єктів і визначає, чи дозволяти певні 
дії на основі певних правил: 
• Якщо мітка захисту користувача домінує над міткою безпеки об'єкта, 
користувач може читати об'єкт. 
• Якщо мітка захисту користувача і мітка захисту об'єкта є 
еквівалентними, користувач може читати об'єкт і записувати в нього. 
• Якщо мітка захисту користувача домінує над міткою безпеки об'єкта, 
користувач не може записати об'єкт. 
• Якщо мітка захисту користувача не порівняна з міткою безпеки 
об'єкта, користувач не може читати або записувати в цей об'єкт. 
Ієрархічні рівні безпеки використовуються як основа для прийняття 
рішень у повноваженому контролі доступу. При визначенні рівня безпеки 
об’єкта визначається ступінь «чутливості» цього об’єкта. Рівні безпеки 
захищають певну функцію безпеки від доступу користувачів нижнього рівня. 
[18] 
 
1.3.3 Контроль доступу на основі ролей 
Основною метою для управління доступом на основі ролей (RBAC) є 
необхідність моделювання структури природної політики для безпеки 
організації. RBAC заснований на ролях користувачів. Ролі подібні до ролей 
груп користувачів у контролі доступу. 
У RBAC роль визначається як група дій та обов’язків, пов’язаних із 
певною діяльністю. Роль може представляти роботу користувача (наприклад, 
покупця) або може визначати дію, яку користувач повинен виконати 
(наприклад, замовити матеріал). Замість того, щоб встановлювати всі дозволи 
для кожного користувача, який виконує те саме завдання, ви можете визначити 
14 
 
дозволи об’єкта для ролей. Користувач, якому призначена роль, може 
виконувати всі дії, на які він має дозвіл. Компоненти RBAC можна описати 
наступним чином [16]: 
• Відношення роль-дозвіл: цей компонент керує наданням/відкликанням 
дозволу на певну роль. 
• Відношення користувач–роль: цей компонент визначає, як призначити 
користувачів певній ролі. 
• Відношення роль-роль: цей компонент визначає, як зробити роль 
членом іншої ролі. 
RBAC має три принципи безпеки: 
• Найменший привілей: RBAC дозволяє користувачеві отримувати 
доступ до об'єктів з найменшим привілеєм, необхідним для певного 
завдання, яке необхідно виконати. Це мінімізує атаку троянських 
коней. 
• Розподіл обов'язків: RBAC гарантує, що жоден користувач не має 
достатньо привілеїв для самостійного використання системи. 
• Абстракція даних: Це підтримується за допомогою абстрактних 
привілеїв, таких як кредит і дебет рахунку. 
 
1.4 Формулювання проблемних задач дослідження 
1) проаналізувати сучасні методи захисту АІС такі як: аутентифікація, 
керування доступом, легування та шифрування; 
2) провести дослідження продуктивності використання багаторівневих 
моделей захисту АІС залежності часу відповіді від: кількості записів, 
кількості рівнів безпеки та кількості атрибутів 
3) виявити сильні та слабкі сторони багаторівневих моделей захисту АІС; 
4) дослідити методи захисту в системі з багаторівневим захистом; 
 
  
15 
 
Висновки 
У цьому розділі наведено огляд безпеки реляційних баз даних і контролю 
доступу в них, а також недоліки типів контролю доступу при застосуванні до 
реляційної бази даних. Виявлено, що дискреційний контроль доступу не 
підходить для реалізації системи, оскільки має суттєві недоліки у застосуванні 
до баз даних у сучасних системах. Завдяки аналізу існуючих підходів та 
механізмів захисту від несанкціонованого доступу до реляційної бази даних 
визначено необхідні компоненти для подальшого розвитку багаторівневої 
системи безпеки АІС. Такі системи є реалізацією обов'язкового контролю 
доступу, що дозволяє надійно і гнучко диференціювати доступ до об'єктів 
різної важливості. 
  
16 
 
РОЗДІЛ 2 АНАЛІЗ МОДЕЛЕЙ БАГАТОРІВНЕВОЇ БЕЗПЕКИ 
Багаторівнева безпека – це політика безпеки, яка дозволяє класифікувати 
об’єкти та користувачів на основі системи ієрархічних рівнів безпеки та 
системи неієрархічних категорій безпеки [12]. 
Багаторівневий захист забезпечує можливість запобігання доступу 
неавторизованих користувачів до інформації вищої класифікації, ніж їхня 
авторизація. 
Багаторівнева охорона була створена в США для військового 
використання. Розглянемо таку ситуацію: припустимо, що існує база даних, яка 
містить деяку конфіденційну інформацію. Конфіденційні дані класифікуються 
за різними рівнями безпеки і повинні оброблятися в спеціалізованих системах, 
які не надають доступ користувачам за межами необхідного рівня безпеки. 
Основні обмеження для такої системи можна описати таким чином: 
• Резервні бази даних: Для зберігання даних у реляційній базі даних на 
різних рівнях безпеки слід створювати іншу базу даних для кожного 
рівня безпеки. 
• Резервні робочі станції: для отримання кожного типу даних необхідно 
мати різні робочі станції. 
• Висока вартість ІТ-інфраструктури: існує ризик спільного 
використання мережевих ресурсів. 
• Неефективність: Користувачі повинні отримати привілеї на декількох 
системах реляційних баз даних для виконання своїх обов'язків. 
Багаторівнева безпека — чудове рішення для забезпечення належного 
захисту конфіденційної інформації. MLS надає доступ до даних з різними 
рівнями класифікації безпеки користувачам, які мають різні рівні безпеки. У 
багаторівневій безпеці кожен елемент даних визначається як об’єкт і має рівень 
класу безпеки, кожен користувач визначається як суб’єкт, а також має свій 
власний рівень класу безпеки. Рівень безпеки об'єкта або суб'єкта A називається 
міткою і позначається як L (A). 
17 
 
Контроль доступу в багаторівневій безпеці базується на моделі Белла-
ЛаПадули[19], яка має такі властивості(формули 2.1, 2.2, 2.3 відповідно): 
• Проста властивість безпеки: користувачеві s дозволяється доступ для 
читання об'єкта o, тільки якщо рівень суб’єкта L(s) вище або дорівнює 
рівню об’єкта L(o). 
∀ ���� ∈  ����,∀ ���� ∈  ����, ���������������� ∈  ����[����, ����]  →  ����(����)  ≥  ����(����)   (2.1) 
• Властивість * : користувачеві s дозволяється доступ до запису об'єкта 
o, тільки якщо L(s) нижче або дорівнює L(o). 
∀ s ∈  S,∀ o ∈  O, write ∈  A[s, o] →  L(s) ≤  L(o)  (2.2) 
• Властивість strong *: користувачеві s дозволяється доступ до запису 
об'єкта o, тільки якщо рівень суб’єкта L(s) дорівнює рівню об’єкта 
L(o). 
∀ s ∈  S,∀ o ∈  O, write ∈  A[s, o]  →  L(s)  =  L(o)  (2.3) 
В формулах 2.1 – 2.3: S – множина суб’єктів, О – множина об’єктів, A[s,o] 
– матриця доступу, L(s) – рівень безпеки суб’єкту, L(o) – рівень безпеки 
об’єкту. 
Багаторівнева безпека пропонує наступні переваги: 
• Багаторівневе забезпечення безпеки є обов'язковим і автоматичним. 
• Багаторівнева безпека може використовувати методи, які важко 
виражати через традиційні SQL-представлення або запити. 
• Багаторівнева безпека не покладається на спеціальні представлення 
або змінні бази даних для забезпечення контролю безпеки на рівні 
рядків. 
• Багаторівневі засоби безпеки узгоджені та інтегровані по всій системі, 
так що ви можете уникнути визначення користувачів і дозволів більше 
одного разу. 
• Багаторівнева безпека не дозволяє користувачам розсекречувати 
інформацію. 
В багаторівневій моделі реляційної БД кожен елемент даних позначається 
власним класифікатором безпеки. Ієрархія багаторівневої безпеки має чотири 
18 
 
рівні підвищення «чутливості». Ці рівні, від найнижчого до найвищого, - 
некласифікований(U), конфіденційний(C), секретний(S) і цілком секретний(TS). 
Для отримання доступу до даних користувачі повинні мати відповідний 
класифікатор безпеки. 
Багаторівнева безпека обмежує доступ до об'єкта або запису на основі 
мітки захисту об'єкта або запису і мітки захисту користувача.  
Для локальних підключень мітка захисту користувача - це мітка захисту, 
вказана користувачем під час входу. Якщо під час входу не вказано мітку 
захисту, мітка захисту за замовчуванням є міткою захисту користувача. 
Для звичайних з'єднань TCP/IP мітку безпеки користувача може 
визначати зона безпеки. IP-адреси зазвичай згруповані в зони безпеки на 
сервері. Для надійних підключень TCP/IP мітка захисту користувача є міткою 
захисту, встановленою в довіреному контексті. 
Для з'єднань SNA замість мітки захисту, з якою користувач увійшов, 
використовується мітка захисту за замовчуванням для користувача.  
Шляхом встановлення надійного з'єднання в довіреному контексті 
користувачеві  можуть бути призначені мітки безпеки. Визначення надійного 
контексту визначає мітку захисту, пов'язану з користувачем у надійному 
з'єднанні. 
В багаторівневій моделі реляційної бази даних відношення буває 
багатозначне – коли воно містить два або більше записів з однаковими 
значеннями первинного ключа. Багатозначність(polyinstantiation) виникає в 
наступних двох ситуаціях[8]: 
• Невидима багатозначність може відбуватися, коли користувач з 
низьким рівнем безпеки вставляє дані в атрибут, який вже містить дані 
з більш високим рівнем безпеки. 
• Видима багатозначність може відбутися, коли користувач з високим 
рівнем безпеки вставляє дані в атрибут, який вже містить дані на 
нижчому рівні безпеки. Існує два різних типи багатозначності: 
• Багатозначність сутності: 
19 
 
У багаторівневій реляційній базі даних багатозначність сутності може 
виникнути, коли відношення містить більше одного запису з однаковими 
значеннями первинного ключа, але з різними значеннями класу доступу для 
первинного ключа. Наприклад, є два записи з одним і тим же первинним 
ключем, але з двома різними класами безпеки. 
• Багатозначність атрибуту: 
У багаторівневій реляційній базі даних багатозначність атрибуту може 
відбуватися, коли відношення містить два або більше записів з ідентичним 
первинним ключем і його значеннями рівня безпеки, але з різними значеннями 
для одного або декількох залишилися атрибутів. [10] 
 
2.1 Огляд моделей із багаторівневою безпекою 
Існує кілька багаторівневих моделей безпеки для реляційних баз даних, 
наприклад SeaView і Sandhu-Jajodia, Smith-Winslett тощо. Розглянемо 
застосування різних моделей багаторівневої безпеки в таблиці, що містить дані 
користувача. (табл. 2.1) 
Таблиця 2.1 
Початкова таблиця 
Працівник 
Відділ Зарплата 
(Primary Key 
Крутіков 
SMM (U) 8000 (U) 
Микола (U) 
Крутіков 
Sales (S) 20000 (S) 
Микола (S) 
 
2.1.1 Модель SeaView 
У моделі безпечних представлень даних рівні безпеки призначаються 
кожному елементу даних для кожного атрибута запису стосовно, як показано в 
таблиці 2.1. У моделі SeaView дані зберігаються в наборі однорівневих 
20 
 
фрагментів, а багаторівневі зв’язки реалізуються як представлення цих 
однорівневих зв’язків. 
В реалізації моделі SeaView використовуються два алгоритми: 
• Алгоритм декомпозиції розділяє багаторівневе відношення на одно 
рівневі фрагменти. 
• Алгоритм відновлення відновлює початкове багаторівневе 
відношення. 
Застосовуючи цю модель до таблиці 2.1, отримуємо дані у вигляді 5 
однорівневих фрагментів - один первинний ключ і 4 групи відносин (табл. 2.2). 
Таблиця 2.2 
Застосування моделі SeaView 
Працівник  Працівник 
Відділ Зарплата 
(Primary Key) (Primary Key) 
Крутіков Микола  Крутіков 
SMM (U) 8000 (U) 
(U) Микола (U) 
     
Працівник  Працівник 
Відділ Зарплата 
(Primary Key) (Primary Key 
Крутіков Микола  Крутіков 
Sales (S) 20000 (S) 
(S) Микола (S) 
 
2.1.2 Модель Jajodia–Sandhu 
Модель Jajodia – Sandhu є модифікацією моделі SeaView. Ця модель має 
модифікований алгоритм, який розкладає багаторівневі відносини на фрагменти 
з одним рівнем, а також модифікує алгоритм відновлення, який відновлює 
вихідні багаторівневі відносини. 
У моделі Jajodia – Sandhu алгоритм декомпозиції використовує лише 
горизонтальну фрагментацію, оскільки вертикальна фрагментація не потрібна. 
Це покращує алгоритм відновлення, оскільки можна відновити багаторівневі 
21 
 
відносини без виконання операцій з’єднання, а для відновлення багаторівневого 
зв’язку потрібні лише операції злиття. (union)[13]. 
Наприклад, відношення з Таблиці 2.1 буде розкладено на два 
однорівневих фрагмента(Таблиця 2.3). 
 
Таблиця 2.3 
Застосування моделі Jajodia–Sandhu 
Працівник 
Рівень безпеки Відділ Зарплата 
(Primary Key) 
U Крутіков Микола  SMM 8000 
    
Працівник 
Рівень безпеки Відділ Зарплата 
(Primary Key) 
S Крутіков Микола  Sales 20000 
 
2.1.3 Модель Smith–Winslett 
У моделі Smith – Winslett багаторівнева реляційна база даних 
розглядається як набір звичайних реляційних баз даних, де всі бази даних 
мають однакову схему. Ця модель не підтримує безпеку на рівні кожного 
окремого атрибута. Рівень безпеки можна призначити лише атрибутам 
первинного ключа та запису в цілому. У цій моделі користувач може бачити 
записи з рівнем безпеки, який не перевищує його власний. 
Багаторівнева реляційна схема задається як R (TC, APK, CPK, A1 ..., An), 
де APK є атрибутом первинного ключа, CPK є атрибутом класифікатора 
первинного ключа, який містить рівень безпеки первинного ключа, набір A1 ... 
An позначається атрибутами даних, а TC є атрибутом класифікатора цього 
запису, який містить його рівень безпеки. Використовуючи цю модель, зв’язок 
у таблиці 2.1 буде інтерпретовано як зв’язок у таблиці 2.4. 
  
22 
 
Таблиця 2.4 
Застосування моделі Smith–Winslett 
Працівник 
Рівень безпеки Відділ Зарплата 
(Primary Key) 
U Крутіков Микола  SMM 8000 
S Крутіков Микола  Sales 20000 
 
Модифікація BD (вставка, видалення та оновлення) може 
використовуватися лише користувачем на рівні безпеки користувача. Запит від 
користувачів на рівні безпеки L може отримати доступ до самих даних із тих 
баз даних, рівня об’єктів, які не підвищують рівень L. 
Модель Smith – Winslett також повідомляється як модель семантики, 
заснованої на переконаннях. Він також представив концепцію базового поїзда. 
Базовий кортеж — це найнижчий рівень безпеки записів бази даних, де існує 
безпека сутності. Таким чином, процедура оновлення усуває проблеми в моделі 
Jajodia-Sandhu, але обмежує обсяг оновлення однією сутністю. 
 
2.1.4 Модель Multilevel Relational 
Багаторівнева реляційна модель являє собою концепцію цілісності даних, 
яка забезпечує висхідний потік інформації. Зміни даних із нижчим захистом 
можуть бути автоматично перенесені на вищі рівні безпеки, які потребують 
запозичення цих даних. 
Ця модель пов’язана з усуненням семантичної проблеми неоднозначності 
в моделі Джаджодії – Сандху. Користувач із рівнем безпеки може отримувати 
дані, які складаються з двох частин: даних, які мають той самий рівень безпеки, 
і даних, які запозичені у користувачів із нижчим рівнем безпеки. Дані, які може 
побачити суб’єкт, це ті, які отримують суб’єкти на рівні даних або на рівнях 
нижче. 
Багаторівнева реляційна схема задається як R (TC, APK, CPK, A1 ... An ,, 
C1 ... Сn), де APK позначається атрибутом первинного ключа зв'язку, CPK - 
23 
 
атрибутом-класифікатором. первинного ключа, який містить його рівень 
безпеки, встановити A1 ... An - атрибути відносин, C1 ... Сn - класифікатори для 
атрибутів, що містять їх рівень безпеки, і TC - атрибут-класифікатор запису, що 
містить його рівень безпеки . 
Модель даних MLR має кілька властивостей цілісності, з яких цілісність 
сутності та цілісність зовнішнього ключа взяті з оригінальної моделі SeaView, а 
цілісність неоднозначності та цілісність посилання істотно переписані 
авторами. Також вперше запроваджено цілісність запозичених даних (data-
borrow). Зокрема, властивість множинності цілісності, наведена в цій моделі, є 
більш загальною, ніж у моделі SeaView або Jajodia-Sandhu, оскільки вона також 
відповідає за неоднозначність елементів. Переглянута довідкова властивість 
цілісності також вирішує деякі нові довідкові проблеми, які виникають 
внаслідок запозичення даних. [3] 
У таблиці 2.5 можна бачити, як користувач із рівнем безпеки S 
використовував команду UPLEVEL, щоб вказати, що він довіряє інформації з 
першого запису. Для цього він вставляє другий ідентичний запис, тільки з 
класифікатором безпеки запису на рівні S. 
Таблиця 2.5 
Застосування моделі MLR 
Працівник 
Рівень безпеки Відділ Зарплата 
(Primary Key) 
U Крутіков Микола  SMM 8000 
S Крутіков Микола  SMM 8000 
 
2.2 Алгоритми операцій для впровадження моделей 
Розглянемо алгоритми операцій з даними, що використовуються для 
впровадження моделей багаторівневої безпеки БД. 
 
  
24 
 
2.2.1 Операція SELECT 
• Модель SeaView 
Операція вибірки в моделі SeaView реалізується наступним чиноми (рис. 
2.1): 
Визначення рівня юзера
Створення представлення шляхом об’єднання і 
приєднання однорівневих відношень
Отримання першого запису з 
представлення
Перехід до -
наступного Рівень запису <= рівень юзера
+
Показати запис
-
Кінець
 
Рис. 2.1. Операція Select в моделі SeaView 
 
Спочатку визначте рівень безпеки користувача, який виконує операцію. 
Далі з даних, що зберігаються у вигляді однорівневих відносин, створюється 
уявлення шляхом виконання операції зв’язку між вертикальними відносинами 
та комбінування між горизонтальними однорівневими відносинами. В 
результаті користувач отримує дані з цього представлення, рівень безпеки 
первинного ключа якого нижчий або дорівнює рівню користувача. 
25 
 
• Модель Jajodia–Sandhu 
Алгоритм операції вибірки в цій моделі наведено на блок-схемі на рис. 
2.2. Після того, як користувач виконує операцію з певним рівнем безпеки, 
подання створюється з горизонтальних однорівневих зв’язків шляхом 
об’єднання. Користувач отримає набір рядків з цього представлення, рівень 
первинного ключа якого не перевищує його власного. 
• Моделі Smith–Winslett та MLR 
Алгоритм реалізації операції вибірки в цих моделях, як і в інших, 
починається з визначення рівня безпеки користувача. На відміну від попередніх 
моделей, ця не вимагає формування уявлення, оскільки дані не поділяються на 
однорівневі відносини. Існує також відмінність у тому, що операція вибірки в 
цій моделі заснована на класифікаторі записів. Тобто користувач отримає набір 
рядків, рівень безпеки яких не перевищує його власний. 
Отримання рівня безпеки 
користувача
Створення представлення шляхом об’єднання 
однорівневих відношень
Отримання запису з представлення
Отримання -
наступного Рівень запису <= рівень юзера
+
Показати запис
-
Кінець
 
Рис. 2.2. Операція Select в моделі Jajodia-Sandhu 
26 
 
Алгоритм операції вибірки в моделях Smith–Winslett та MLR 
продемонстровано на блок-схемі на рис. 2.3. 
Отримання рівня безпеки 
користувача L
Set i = l
Отримуємо рядки ti, Що задовольняють 
умову
Отримання 
наступного
-
ti [TC] = L (user)
+
Показати ti
-
Кінець
 
Рис. 2.3. Операція Select в моделі Smith-Winslett та MLR 
 
2.2.2 Операція INSERT 
• Моделі SeaView та Jajodia-Sandhu 
Операція вставки виконується наступним чином (рис. 2.4): перевіряють 
рівень безпеки користувача, який виконує операцію, та наявність атрибута в 
списку атрибутів, які з’являються в операції. Рівень безпеки цих атрибутів буде 
встановлено на рівні безпеки користувача. Далі в однорівневому зв’язку вставте 
значення, які відповідають атрибутам цих однорівневих зв’язків, і призначте їм 
рівень, рівний рівню користувача. 
27 
 
Визначаємо L(user)
Set i = l
ti [TACi ]∈ = R L[ A(ui]ser)
i = i + l - +
Ai = null Ai = ai
Сi = L(user)
Встановлюємо запис
-
Кінець
 
Рис. 2.4. Операція Insert в моделях SeaView та Jajodia-Sandhu 
 
• Модель Smith–Winslett 
У цій моделі запис буде вставлено у багаторівневі відносини, а рівень 
безпеки первинного ключа встановлюється на рівні безпеки користувача, який 
28 
 
виконує операцію. Алгоритм виконання операції вставки в цій моделі наведено 
на блок-схемі на рис. 2.5. 
Визначаємо L(user)
Set i = l
Ai ∈ R[Ai]
i = i + l - +
Ai = null Ai = ai
СРК = L(user)
Встановлюємо запис
-
Кінець
 
Рис. 2.5. Операція Insert в моделі Smith-Winslett 
 
• Модель MLR 
У цій моделі запис буде вставлено у багаторівневий зв’язок, а рівень 
безпеки всіх атрибутів встановлюється на рівні безпеки користувача, який 
29 
 
виконує операцію. Алгоритм виконання операції вставки в цій моделі наведено 
на блок-схемі на рис. 2.6. 
Визначаємо L(user)
Set i = l
ti [TACi ]∈ = R L[ A(ui]ser)
i = i + l - +
Ai = null Ai = ai
Сi = L(user)
Вставляємо
-
Кінець
 
Рис. 2.6. Операція Insert в моделі MLR 
 
2.2.3 Операція UPDATE 
• Моделі SeaView та Jajodia–Sandhu 
Алгоритм операції оновлення в цих моделях наведено на рис. 2.7. 
Спочатку ми перевіряємо рівень безпеки користувача, який виконує операцію, і 
30 
 
вибираємо рядки, які задовольняють умові оновлення та мають рівень безпеки, 
який не перевищує рівень безпеки користувача. 
Визначаємо L(user)
Set i = l
Отримуємо t(Ai), що задовольняють 
умову
СРК = L(user)
i = i + l - +
Оновлюємо t(Ai) СРК = L(user)
+ -
Мультиреалізація t(Ai)
-
Кінець
Рис. 2.7. Операція оновлення в моделях SeaView та Jajodia–Sandhu 
 
31 
 
Далі розділимо отримані рядки на ті, рівень безпеки первинного ключа 
яких дорівнює рівню користувача, і ті, чий рівень менший. Для рядків з 
однаковим рівнем дані у відношенні будуть оновлені, а для рядків з нижчим 
рівнем – рівень безпеки в однорівневих відносинах із зазначеними атрибутами 
збільшується до рівня безпеки користувача, а записи додаються до відносини, 
тобто є неоднозначність. 
• Модель Smith–Winslett 
Алгоритм операції оновлення в цій моделі (рис. 2.8) відрізняється від 
алгоритму для попередніх моделей. 
Як і в операції вибору, перевірка рівня безпеки базується на перевірці 
класифікатора записів. Коли користувач із певним рівнем безпеки виконує цю 
операцію, оновлюватимуться лише ті записи, які відповідають умові та чий 
класифікатор дорівнює рівню безпеки користувача. 
Визначаємо L(user)
Set i = l
Вибираємо ti, що задовольняють умову
i = i + l 
-
ti [TC] = L (user)
+
Оновлюємо ti
-
Кінець
 
Рис. 2.8. Операція оновлення в моделі Smith-Winslett 
32 
 
• Модель MLR 
Алгоритм виконання операції оновлення в даній моделі 
продемонстровано на блок-схемі на рис. 2.9. 
Операція оновлення в даній моделі виконується наступним чином: 
Визначаємо L(user)
Set i = l
ti [RK] ∈ [Ai]
i = i + l
-
+
Оновлюємо ti
ti [RK] ∈ [Ai]
+ -
Оновлюємо t' i
Видаляємо ti
-
Кінець
 
Рис. 2.9. Операція оновлення в моделі MLR 
33 
 
По-перше, за умови, що атрибут первинного ключа не міститься в SET, 
усі записи оновлюються у багаторівневому зв’язку, який задовольняє умову 
оновлення та має класифікатор записів, що дорівнює рівню безпеки 
користувача. Крім того, усі запозичені записи користувачів верхнього рівня, які 
відповідають умові оновлення, також будуть оновлені. 
Далі перевірте, що якщо якийсь атрибут первинного ключа знаходиться в 
SET, то всі записи оновлюються у багаторівневому зв’язку, який задовольняє 
умову оновлення P і має класифікатор записів, що дорівнює рівню безпеки 
користувача. При цьому видаляються всі записи, запозичені користувачами 
верхнього рівня, які відповідають умові оновлення. 
 
2.2.4 Операція DELETE 
• Моделі SeaView та Jajodia–Sandhu 
Коли користувач виконує операцію видалення, спочатку визначається 
його рівень безпеки. Далі всі записи, які задовольняють умові, зазначеній в 
операції, і мають рівень безпеки первинного ключа, рівний рівню користувача, 
видаляються з однорівневого зв’язку. 
Алгоритм виконання операції видалення в даних моделях 
продемонстровано на блок-схемі на рис. 2.10. 
• Модель Smith–Winslett 
Як і інші операції в цій моделі, операція видалення заснована на перевірці 
класифікатора рядків. Алгоритм виконання операції видалення в цій моделі 
наведено на блок-схемі на рис. 2.11. Коли користувач виконує операцію 
видалення, визначається його рівень безпеки. Крім того, з багаторівневого 
зв’язку видаляються лише ті записи, які задовольняють зазначеній умові та 
мають класифікатор записів, що дорівнює рівню безпеки користувача. 
 
34 
 
Визначаємо L(user)
Set i = l
Отримуємо t(Ai), що задовольняють 
умову
i = i + l
-
СРК = L (user)
+
Видаляємо t(Ai)
-
Кінець
 
Рис. 2.10. Алгоритм видалення в моделях SeaView та Jajodia–Sandhu 
 
35 
 
Визначаємо L(user)
Set i = l
Беремо ti, що задовольняють умову
i = i + l
-
ti [TC] = L (user)
+
Видаляємо ti
-
Кінець
 
Рис. 2.11. Алгоритм видалення в моделі Smith–Winslett 
 
• Модель MLR 
Алгоритм виконання операції видалення в даній моделі 
продемонстровано на блок-схемі на рис. 2.12. 
 
36 
 
Визначаємо L(user)
Set i = l
ti [TC] = L(user)
i = i + l
+ -
Видаляємо ti ti [TC] > L(user) and
ti [СРК] = L(user)
+ -
Позначено для видалення
-
Кінець
Рис. 2.12. Алгоритм видалення в моделі MLR 
 
По-перше, усі записи видаляються з багаторівневого відношення, яке 
задовольняє умові видалення та має класифікатор безпеки запису, рівний рівню 
користувача. 
37 
 
Якщо є запис, який задовольняє умові видалення та запозичений 
користувачем високого рівня (тобто рівень безпеки первинного ключа дорівнює 
рівню користувача, а класифікатор безпеки запису вищий за рівень 
користувача), користувач високого рівня отримає повідомлення про 
виключення або попередження. позичений запис. 
 
2.2.5 Операція UPLEVEL 
З усіх представлених моделей лише модель MLR має операцію Uplevel, 
що має наступний вигляд: 
«UPLEVEL R 
GET [A1, A2, ... , An] FROM [C1, C2, ... , Cn] 
WHERE P», 
де R - відношення MLS, A1, A2, ..., An - атрибути з R, C1, C2, ... , Cn – це 
класифікатори безпеки A1, A2, ..., An, P - умова, що визначає записи, які 
підлягають підвищенню рівня безпеки. 
Користувач із рівнем безпеки L виконує операцію UPLEVEL, щоб 
вказати, що він довіряє записам нижчого рівня. Для цього з багаторівневого 
коефіцієнта спочатку виберіть усі записи, які задовольняють умові P і мають 
класифікатор безпеки запису, який не перевищує користувацького рівня. 
Алгоритм операції підвищення рівня наведено на рис. 2.13. 
Далі для кожного запису r ′ вибраного будується запис r користувача 
наступним чином: значення первинного ключа запису r і його рівня безпеки 
встановлюються такими ж, як і первинний ключ запису r. ′. 
Для кожного атрибута не первинного ключа в GET значення атрибута 
запису r і його рівень безпеки будуть дорівнювати значенню цього атрибута 
запису r ′ і його рівню безпеки. Якщо атрибут відсутній у GET, атрибут запису r 
буде нульовим, а його рівень безпеки буде дорівнювати рівню безпеки 
користувача. 
 
38 
 
Визначаємо L(user)
Set i = l
i = i + l r  [TC] = L(user) r [PK] = ri [PK],
i
+ r [CPK] = ri [CPK]
-
Set j = l
ri [TC] = L(user)
+ -
r [Aj] = ri [Ai], r [Aj] = null,
r [Cj] = r  [Cj] r [C ] = L(user) j =  j + l
i j
r [PK] = r’ [PK] and
r [CPK] = r’ [CPK] and
r [TC] = r’ [TC]
Запис r’ буде 
замінено на r Вставляємо запис r
Кінець
 
Рис. 2.13. Алгоритм підвищення рівня в моделі MLR 
 
Якщо є запис із первинним ключем і класифікатором запису, що дорівнює 
первинному ключу та класифікатору запису користувача r відповідно, цей запис 
39 
 
буде замінено записом користувача r. Якщо такого запису немає, запис r 
вставляється в багаторівневе відношення. 
 
2.3 Недоліки моделей багаторівневої безпеки 
Проаналізувавши представлені в роботі моделі, можна зробити 
припущення про недоліки та проблеми, які виникають при їх використанні. 
Наприклад, модель SeaView має багато проблем через алгоритми розкладання 
та відновлення. Ці проблеми можуть бути такими: 
• Повторні об’єднання: 
Завдяки використанню вертикальної декомпозиції в моделі SeaView 
запит, який містить кілька атрибутів, використовуватиме багато повторюваних 
лівих зовнішніх з’єднань між кількома однорівневими зв’язками для отримання 
результуючого набору даних. 
• Паразитні записи: 
Коли алгоритм відновлення SeaView застосовується до однорівневих 
зв’язків, додаткові записи вставляються до вихідного зв’язку. Ці додаткові 
записи називаються паразитарними записами і є результатом возз'єднання між 
однорівневими відносинами. 
• Неповнота: 
Алгоритм декомпозиції SeaView обмежує дані в базі даних. Тому в 
моделі SeaView неможливо реалізувати деякі відносини, які мають реальні та 
корисні інтерпретації в реальному житті. 
Основні проблеми моделі Jajodia–Sandhu: 
• Семантична неоднозначність: 
Припустимо, що щодо рівнів безпеки U і S є 2 записи, і немає запису з 
рівнем безпеки TS. Якщо користувачеві з рівнем безпеки TS потрібно отримати 
інформацію від зв’язку, він не може вирішити, яка інформація є правильною, 
оскільки запит призведе до різних значень із записів рівня U та S. 
• Оперативна неповнота: 
40 
 
Припустимо, що існують два непорівнянні рівні безпеки, M1 і M2, 
мінімальна верхня межа яких — рівень безпеки S, а найвища нижня межа — 
рівень безпеки U. Користувач на рівні безпеки S не зможе вставити записи, які 
містять атрибути з рівнями безпеки. на U , M1 і M2. 
Модель Сміта – Вінслетта також відома як модель семантики, заснованої 
на переконаннях, але вона додатково вводить поняття базової нотації. Завдяки 
цьому операція оновлення усуває проблеми в моделі Jajodia – Sandhu, але в той 
же час обмежує область оновлення однією сутністю. 
 
2.4 Дослідження продуктивності використання багаторівневих 
моделей захисту АІС 
Для порівняння моделей багаторівневої безпеки АІС було проведено 
дослідження продуктивності системи. Для цього була створена база даних, яка 
складається з 4 відносин. Кожна з моделей - SeaView, Jajodia-Sandhu, 
SmithWinslett і MLR - була реалізована для цієї бази даних. Дослідження 
продуктивності проводилося в 3 етапи: вивчення впливу на продуктивність 
кількості записів у зв'язку, кількості атрибутів зв'язку та кількості рівнів 
безпеки. 
 
2.4.1 Вплив зміни кількості записів 
Експеримент був розроблений, щоб визначити, як вартість обробки різної 
кількості записів впливає на продуктивність багаторівневих моделей баз даних. 
Цей крок є основним, оскільки розмір бази даних базується на кількості записів, 
а кількість записів, оброблених під час кожної транзакції, є фактором, який 
визначає, скільки часу потрібно, щоб повернути відповідь користувачеві. 
Дослідження проводилося з різним обсягом вмісту бази даних. Результати 
цього етапу експерименту наведені на рис. 2.14. 
41 
 
 
Рис. 2.14. Графік залежності часу відповіді від кількості записів 
 
З графіку видно що, за залежності часу відповіді від кількості записів 
більш продуктивною моделю є Smith – Winslett з затримкою відповіді при 2000 
запитів приблизно 0.6 секунд, потім менш продуктивна модель MLR з 
затримкою 1секунда. Моделі Jajodia – Sandlhu та SeaView порівнюючи з 
першими моделями є оутсайдерами по залежності швидкості відвовіді від 
кількості запитів. 
 
2.4.2 Вплив зміни кількості атрибутів відношення 
Цей етап експерименту був проведений для того, щоб визначити, чи буде 
вартість обробки різної кількості атрибутів по відношенню до продуктивності 
багаторівневої моделі баз даних. Як і на попередньому етапі, дослідження 
42 
 
проводилося з вимірюванням часу відповіді на запит. Результати цього етапу 
експерименту наведено на рис. 2.15. 
 
 
Рис. 2.15. Графік залежності часу відповіді від кількості атрибутів 
 
Як видно з результатів порівняльного графіку залежності часу на 
відповідь від кількості атрибутів модель Smith – Winslett знову попереду з 
затримкою на відповідь при наявності 6 атрибутів приблизно 0.8 секунд, після 
неї йде модель МLR, затримка якої складає 0.9 секунд і моделі Jajodia – Sandhu 
та SeaView займають 3 та 4 місце відповідно. Модель SeaView є найменш 
продуктивною серед усіх, її затримка складає аж 7 секунд. 
 
  
43 
 
2.4.3 Вплив зміни кількості рівнів безпеки 
Останній етап експерименту було проведено, щоб визначити, чи 
впливають і як витрати на обробку різної кількості визначених рівнів безпеки 
на продуктивність багаторівневих моделей баз даних. Як і на попередніх 
етапах, дослідження проводилося з вимірюванням часу відповіді на запит. 
Результати експерименту наведено на рис. 2.16. 
 
Рис. 2.16. Графік залежності часу відповіді від кількості рівнів безпеки 
 
Завершальний етап експерименту показав що й в залежності часу на 
відповідь від кількості рівнів безпеки модель Smith – Winslett є 
найпродуктивнішою, при 6 рівнях безпеки, затримка на відповідь дорівнює 
всього 0.4с, тоді як модель SeaView з затримкою аж 2.4с є найменш 
продуктивною.  
 
Висновки 
В даному розділі було представлене дослідження із застосуванням 
змодельованих систем з багаторівневою безпекою БД. Результати 
44 
 
порівняльного дослідження дають змогу пояснити сильні та слабкі сторони 
кожної моделі. 
Очевидна перевага моделей MLR та Smith-Winslett пов’язана з тим, що 
дані в них не піддавались декомпозиції, тож не зберігаються у вигляді 
однорівневих відношень. Продуктивність моделі Smith-Winslett є найвищою, 
оскільки вона не підтримує класифікацію безпеки на рівні кожного окремого 
атрибута; рівні доступу можуть бути призначені тільки для ключових атрибутів 
і для записів в цілому. Модель MLR пропонує меншу продуктивність, ніж 
модель SmithWinslett, оскільки вона підтримує класифікацію на рівні кожного 
окремого атрибута. Модель Jajodia–Sandhu працює набагато гірше за моделі 
MLR та SmithWinslett через вплив операції об'єднання між однорівневими 
відношеннями в алгоритмі відновлення. Модель SeaView є найменш 
ефективною з усіх через вплив операцій з'єднання між вертикальними 
однорівневими відношеннями та об'єднання між горизонтальними 
однорівневими відношеннями в алгоритмі відновлення. 
 
  
45 
 
РОЗДІЛ 3 ДОСЛІДЖЕННЯ ТЕХНОЛОГІЙ БАГАТОРІВНЕВОГО 
ЗАХИСТУ ІНФОРМАЦІЇ В АІС 
3.1 Складові проекту 
• База даних, що складається з реалізованої моделі багаторівневої 
безпеки – Smith – Winslett.  Дані шифруються за допомогою bcrypt.  
• Додаток Angular 10, який виконує запити до бази даних, в якому: 
− Сторінка реєстрації 
− Сторінка входу 
− Дані форми будуть перевірені інтерфейсом перед відправленням на 
сервер. 
− Залежно від ролей користувача (адміністратор, модератор, користувач) 
панель навігації автоматично змінює свої елементи. 
− Сервіси містять методи надсилання HTTP-запитів та отримання 
відповідей 
• Для забезпечення належного рівня захисту АІС взаємодії з базою 
даних для звичайних користувачів здійснюється через JWT.  
 
3.2. Стек технологій 
Проект вирішено розробляти на фреймворку Angular, так як він пропонує 
зручну, швидку розробку Web-додатків через Angular CLI та багато 
можливостей “з коробки”. Має високу продуктивність за рахунок ієрархічної 
залежності та Ivy renderer. Використовує TypeScript, що дозволяє писати більш 
структурований та типізований код в ООП-стилі. Також має потужний набір 
інструментів для роботи з асинхронним кодом RxJS та запитами. І 
найголовніше – гарну підтримку PWA, Service Worker та оффлайн. 
Для СУБД вирішено використовувати PostgreSQL тому що це вільна 
об'єктно-реляційна система управління базами даних. Вона існує в реалізаціях 
для багатьох UNIX-подібних платформ, включаючи AIX, різні BSD-системи, 
HP-UX, IRIX, Linux, macOS, Solaris/OpenSolaris, Tru64, QNX, а також для 
Microsoft Windows. 
46 
 
PostgreSQL базується на мові SQL і підтримує багато можливостей 
стандарту SQL:2011 
 
3.2.1. Node.js 
Node.js — це платформа, створена на середовищі виконання Chrome 
JavaScript для легкого створення швидких і масштабних мережевих програм. 
Node.js використовує керовану подію, неблокуючу модель вводу-виводу, що 
робить його легким та ефективним, ідеальним для додатків реального часу з 
інтенсивним використанням даних, які працюють на розподілених пристроях. 
Node.j — це кросплатформне кодове середовище виконання з відкритим 
вихідним для розробки серверних і мережевих додатків. Програми Node.js 
написані на JavaScript і можуть запуститися в середовищі виконання Node.js в 
OS X, Microsoft Windows і Linux. 
Node.js також дає багату бібліотеку різних модулів JavaScript, що 
значною мірою розробляє веб-додатків за допомогою Node.js. 
Node.js = Runtime Environment + JavaScript Library 
Нижче наведено деякі з важливих функцій, які створюють Node.js 
першим вибором архітекторів програмного забезпечення. 
Асинхронний і керований подіями — усі бібліотеки API Node.js 
асинхронні, тобто не блокують. По суті, це означає, що сервер на основі Node.j 
ніколи не чекає, поки API повернеться. Сервер переходить до наступного API 
після його виклику, механізм сповіщення про подію Node.j отримує відповідь 
від API виклику. 
Дуже швидка. бібліотека Node.js, створена на движку JavaScript V8 від 
Google Chrome, дуже швидко виконує код. 
Однопотоковий, але високомасштабований — Node.js використовує 
однопотокову модель з циклом подій. Механізм, який є основним сервером, 
реагує недійсним способом і робить сервер дуже масштабним на прикладі 
традиційних серверів, які створюють обмежені потоки для обробки запитів. 
Node.j використовує одну потокову програму, і та сама може надавати 
47 
 
обслуговування більшої кількості запитів, крім традиційних серверів, таких як 
Apache HTTP Server. 
Без буферизації – програми Node.js ніколи не буферизують. Ці програми 
просто виводять фрагменти. 
 
3.2.2. Express.js 
Express - це мінімалістичний та гнучкий веб-фреймворк для програм 
Node.js, що надає широкий набір функцій для мобільних та веб-додатків. 
Маючи у своєму розпорядженні безліч службових методів HTTP та проміжних 
обробників, створити надійний API можна швидко та легко. 
Express надає тонкий шар фундаментальних функцій веб-застосунків, які 
не заважають вам працювати з давно знайомими та улюбленими вами 
функціями Node.js.  
ExpressJS вважається як мінімальним, так і гнучким середовищем веб-
застосунків Node.js, що надає надійні функції для використання як веб, так і 
мобільних додатків. ExpressJS також розглядається як середовище з відкритим 
вихідним кодом, і воно було розроблено та підтримується фондом NodeJS. 
Це також дає мінімальний інтерфейс, щоб зробити наші програми. Крім 
того, ExpressJS надає нам інструменти, необхідні для створення програми. 
ExpressJS також є гнучким, оскільки існують різні модулі, які доступні на npm, 
і які можуть бути безпосередньо підключені до нього, тобто Express. 
 
3.2.3. Angular 
Angular – це платформа та основа для побудови односторінкових 
клієнтських додатків за допомогою HTML та TypeScript. Angular пишеться в 
TypeScript. Він реалізує основну та додаткову функціональність як набір 
бібліотек TypeScript, які можна імпортувати у додатки. 
 Архітектура програми Angular спирається на певні фундаментальні 
концепції. Основними будівельними блоками є NgModules, які забезпечують 
контекст компіляції компонентів. NgModules збирають відповідний код у 
48 
 
функціональні набори; Angular додаток визначається набором NgModules. У 
додатку завжди є принаймні кореневий модуль, який дозволяє завантажувати, і, 
як правило, має ще багато функціональних модулів. 
Компоненти визначають представлення даних, що представляють собою 
набори елементів екрану, які можна вибирати та змінювати відповідно до 
логіки та даних вашої програми. 
Компоненти використовують сервіси, які надають певні функціональні 
можливості, безпосередньо не пов'язані з представленнями. Постачальники 
послуг можуть бути введені в компоненти як залежності, що робить ваш код 
модульним, багаторазовим та ефективним. 
І компоненти, і сервіси – це просто класи, в яких є декоратори, які 
позначають їх тип та надають метадані, які вказують Angular, як ними 
користуватися. 
 Метадані класу компонентів асоціюють його з шаблоном, який 
визначає представлення. Шаблон поєднує звичайний HTML з Angular 
директивами та розміткою, що дозволяють Angular змінювати HTML, перш ніж 
відображати його для користувача.  
Метадані для класу надають інформацію, яку Angular потребує, щоб 
зробити її доступною для компонентів через введення залежності (DI). 
 Компоненти програми зазвичай визначають багато представлень, 
розташованих ієрархічно. Angular надає послугу маршрутизатора, щоб 
допомогти визначити шляхи навігації серед представлень. Маршрутизатор 
забезпечує складні навігаційні можливості в браузері [2]. 
Переваги Angular: 
Висока продуктивність 
Прискорення відбувається за рахунок декількох факторів. Основний 
приріст забезпечується за допомогою ієрархічної ін'єкції залежності та 
підтримки Angular Universal. 
Введення ієрархічної залежності. Angular використовує покращену 
ієрархічну ін'єкційну залежність порівняно з AngularJS. Метод відокремлює 
49 
 
фактичні компоненти від їх залежностей, проводячи їх паралельно один 
одному. Angular будує окреме дерево залежностей, яке можна змінити без 
перенастроювання компонентів. Отже, класи не мають залежностей самі по 
собі, але споживають їх із зовнішнього джерела. 
Angular Universal – це послуга, яка дозволяє візуалізувати програми на 
сервері замість браузера клієнтів. Google надає набір інструментів для 
попереднього відтворення вашої програми або для повторної рендерингу для 
кожного запиту користувача. В даний час набір інструментів підходить під 
рамки на сервері Node.JS і підтримує ASP.NET Core. Google заявляє, що 
збирається додати підтримку PHP, Python та Java. 
Ivy rendering. Angular компоненти та шаблони записуються у TypeScript 
та HTML, але власне HTML не використовується безпосередньо у браузері. Це 
робить додатковий крок, коли HTML та TypeScript інтерпретуються в інструкції 
JavaScript. Renderer – це двигун, який перекладає шаблони та компоненти в 
JavaScript та HTML, які браузери можуть розуміти та відображати.  
 Диференціальне навантаження було додано в Angular 8 як інша 
методика оптимізації. Диференціальне завантаження – це спосіб завантаження 
вмісту та оптимізації розміру пакету. Насправді це дозволяє створити два 
різних пакети для застарілих браузерів та нових. Angular використовує останній 
синтаксис та поліфіли для нових браузерів, створюючи окремий пакет із 
стабільним синтаксисом для застарілих браузерів. Таким чином, 
диференціальне завантаження зменшує розмір пакету та швидкість 
завантаження для нових та старих браузерів, покращуючи загальну 
продуктивність  [2]. 
TypeScript: кращий інструментарій, чистіший код та більша 
масштабованість.  
 У Angular компоненти написані за допомогою TypeScript, шаблони в 
HTML, доповнені за допомогою Angular. Так працює більшість фреймворків JS. 
Потім шаблони HTML будуть компільовані в інструкції JavaScript, тому 
50 
 
TypeScript – це головний інструмент для роботи в Angular. TypeScript має кращі 
функції з навігації, автодоповнення та рефакторингу.  
RxJS: ефективне, асинхронне програмування 
RxJS – це бібліотека, яка зазвичай використовується з Angular для 
обробки асинхронних викликів даних. Вона дозволяє самостійно обробляти 
події паралельно та продовжувати виконання, не чекаючи того, що відбудеться 
подія, і не залишати Web-сторінку без відповіді. RxJS працює як конвеєр, де 
виконання розбивається на окремі та взаємозамінні частини, а не прив'язується 
до однієї людини [1]. 
Потужність Angular CLI 
− Можливість створення кількох додатків та бібліотек за допомогою 
однієї команди.  
− Підтримка створення шаблонів. 
− Підтримка створення сутностей Angular (компонент, модуль, 
директива). 
− Підтримка декількох мов від ng xi18n. 
− Підтримка тестів. 
− Підтримка правопису. 
− Можливість легкої міграції версій. 
Недоліки Angular: 
Надлишковість. 
 Архітектуру на основі компонентів є основною перевагою Angular, 
але спосіб управління компонентами є надто складним. Наприклад, може 
знадобитися до п'яти файлів для одного компонента в Angular, потрібно 
вводити залежності та оголошувати інтерфейси життєвого циклу компонентів. 
Крута крива навчання 
Для новачків знайомих з JavaScript, щоб вивчити та використовувати 
новий Angular, знадобиться більше часу порівняно з React або Vue. Масив тем 
та аспектів, які слід висвітлити, великий: модулі, введення залежності, 
51 
 
компоненти, послуги, шаблони тощо. Також для багатьох розробників 
складним є синтаксис Angular, який схиляє до написання коду в ООП стилі. 
Ще один бар’єр – RxJS, реактивна бібліотека програмування для 
асинхронного програмування. ЇЇ вивчення, принаймні на базовому рівні, є 
обов'язковим для використання Angular. 
 
3.2.4. PostgreSQL 
PostgreSQL – вільна об'єктно-реляційна система управління базами даних 
(СУБД). Існує в реалізаціях для багатьох UNIX-подібних платформ, включаючи 
AIX, різні BSD-системи, HP-UX, IRIX, Linux, macOS, Solaris/OpenSolaris, Tru64, 
QNX, а також для Microsoft Windows. 
PostgreSQL базується на мові SQL і підтримує багато можливостей 
стандарту SQL:2011 
У PostgreSQL версії 12 є обмеження, що вказані в таблиці 3.1 
 
Таблиця 3.1  
Обмеження PostgreSQL версії 12 
Максимальний розмір бази даних Немає обмежень 
Максимальний розмір таблиці 32 Тбайт 
Максимальний розмір поля 1 Гбайт 
Максимум записів у таблиці Обмежено розмірами таблиці 
Максимум полів у записі 250-1600, залежно від типів полів 
Максимум індексів у таблиці Немає обмежень 
 
Сильними сторонами PostgreSQL вважаються: 
• високопродуктивні та надійні механізми транзакцій та реплікації; 
• система вбудованих мов програмування, що розширюється: у 
стандартній поставці підтримуються PL/pgSQL, PL/Perl, PL/Python і 
PL/Tcl; додатково можна використовувати PL/Java, PL/PHP, PL/Py, 
52 
 
PL/R, PL/Ruby, PL/Scheme, PL/sh та PL/V8, а також є підтримка 
завантаження модулів розширення мовою C; 
• успадкування; 
• можливість індексування геометричних (зокрема, географічних) 
об'єктів і наявність розширення PostGIS, що на ній базується; 
• вбудована підтримка слабоструктурованих даних у форматі JSON з 
можливістю їхньої індексації; 
• розширюваність (можливість створювати нові типи даних, типи 
індексів, мови програмування, модулі розширення, підключати будь-
які зовнішні джерела даних). 
Функції PostgreSQL 
Функції — це блоки коду, які виконуються на сервері, а не на клієнті бази 
даних. Хоча вони можуть бути написані на чистому SQL, реалізація додаткової 
логіки, наприклад, умовних переходів і циклів, виходить за рамки SQL і 
вимагає деяких мовних розширень. Функції можна написати однією з 
наступних мов: 
• Вбудована процедурна мова PL / pgSQL, схожа на мову PL / SQL, що 
використовується в СУБД Oracle; 
• Мови скриптів - PL / Lua, PL / LOLCODE, PL / Perl, PL / PHP, PL / 
Python, PL / Ruby, PL / sh, PL / Tcl, PL / Scheme, PL / v8 (Javascript); 
• Класичні мови - C, C++, Java (через модуль PL/Java); 
• Статистична мова R (через модуль PL/R). 
PostgreSQL дозволяє використовувати функції, які повертають набір 
записів, які потім можна використовувати так само, як і результат звичайного 
запиту. 
Функції можуть виконуватися як з правами їх розробника, так і з правами 
поточного користувача. 
Функції іноді ототожнюються із збереженими процедурами, але між ними 
є різниця. З дев’ятої версії є можливість писати окремі блоки, які дозволяють 
53 
 
виконувати код процедурними мовами без запису функцій, безпосередньо в 
клієнті. 
Тригери PostgreSQL 
Тригери визначаються як функції, які запускаються операціями DML. 
Наприклад, операція INSERT може запустити тригер, який перевіряє доданий 
запис, якщо виконуються певні умови. При написанні функцій для тригерів 
можна використовувати різні мови програмування (див. вище). 
Тригери пов'язані з таблицями. Кілька тригерів виконуються в 
алфавітному порядку. 
Правила та представлення 
Механізм правил — це механізм створення користувацьких обробників 
не тільки для операцій DML, але й для операцій вибору. Основна відмінність 
від тригерного механізму полягає в тому, що правила спрацьовують на етапі 
розбору запиту, перед вибором оптимального плану виконання та самого 
процесу виконання. Правила дозволяють змінити поведінку системи під час 
виконання операції SQL над таблицею. 
Хорошим прикладом є реалізація механізму перегляду: під час створення 
представлення створюється правило, яке вказує, що замість виконання операції 
вибору над представленням, система повинна виконати операцію вибору над 
базовою таблицею / таблицями, враховуючи умови вибору, що лежать в основі 
визначення представлення. Щоб створити представлення даних, які 
підтримують операції оновлення, правила для операцій вставки, оновлення та 
видалення мають бути визначені користувачем.[13] 
Індекси PostgreSQL 
PostgreSQL підтримує такі типи індексів: B-tree, hash, GiST, GIN, BRIN, 
Bloom. За потреби можна створювати нові типи індексів. Індекси PostgreSQL 
мають такі властивості: 
• можна сканувати індекс не тільки в прямому, а й у зворотному 
порядку - немає необхідності створювати окремий індекс для роботи 
конструкції ORDER BY ... DESC; 
54 
 
• можна створити індекс за кількома стовпцями таблиці, у тому числі 
над стовпцями різних типів даних; 
• індекси можуть бути функціональними, тобто їх можна будувати не на 
основі набору значень певного стовпця/стовпців, а на основі набору 
значень функції з набору значень; 
• індекси можуть бути частковими, тобто їх можна будувати лише на 
частині таблиці (за деякими її проекціями); в деяких випадках це 
допомагає створити набагато компактніші індекси або досягти 
підвищення продуктивності за допомогою використання різних типів 
індексів для різних (наприклад, з точки зору частоти оновлення) 
частин таблиці; 
• планувальник запитів може використовувати кілька індексів 
одночасно для виконання складних запитів. 
Багатоверсійність PostgreSQL 
PostgreSQL підтримує одночасну модифікацію бази даних декількома 
користувачами за допомогою механізму багатоверсійного контролю 
паралельності (MVCC). Це забезпечує відповідність ACID і практично усуває 
необхідність блокування зчитування.[13] 
Типи даних PostgreSQL 
PostgreSQL підтримує великий набір вбудованих типів даних: 
• Числові типи 
1) Цілий 
2) Фіксована точка 
3) Плаваюча кома 
4) Грошовий тип (він має спеціальний формат виведення, але в 
іншому схожий на числа з фіксованою точкою з двома знаками 
після коми) 
• Типи символів довільної довжини 
• Двійкові типи (включаючи BLOB) 
55 
 
• Типи дати/часу (повна підтримка різних форматів, точності, 
вихідних форматів, включаючи останні зміни часових поясів) 
• Булевий тип 
• Перерахування 
• Геометричні примітиви 
• Інтервали (RANGE) 
• Мережеві типи 
1) IP- та IPv6-адреси 
2) Формат CIDR 
3) MAC-адреса 
• UUID-ідентифікатор 
• XML-дані 
• Масиви 
• JSON 
• Ідентифікатори об'єктів БД 
• Псевдотипи 
Крім того, користувач може самостійно створювати нові потрібні йому 
типи та програмувати механізми індексації для них за допомогою GiST. 
Об'єкти користувача 
PostgreSQL може бути розширений користувачем для власних потреб 
практично в будь-якому аспекті. Можна додати свої власні: 
• Перетворення типу 
• Типи даних 
• Домени (користувацькі типи з початково накладеними обмеженнями) 
• Функції (включаючи агрегатні) 
• Індекси 
• Оператори (включаючи заміну існуючих) 
• Процедурні мови 
 
56 
 
Спадкування та поділ 
Таблиці можуть успадковувати характеристики та набори полів від інших 
таблиць (батьківських). У цьому випадку дані, додані в створену таблицю, 
автоматично братимуть участь (якщо вони не вказані окремо) у запитах до 
батьківської таблиці. 
У PostgreSQL 10 додано механізм поділу таблиці. Розбиття призначене 
для поділу однієї таблиці на кілька, так званих розділів. Розбиття подібне до 
успадкування, але має більш зручний синтаксис і суворіші обмеження, що 
дозволяє додатково оптимізувати планування запитів. 
 
3.2.5. RESTful API 
REST (від англ. Representational State Transfer - "передача 
репрезентативного стану" або "передача "самоописуваного" стану") - 
архітектурний стиль взаємодії компонентів розподіленого додатка в мережі. 
Інакше кажучи, REST — це набір правил у тому, як програмісту організувати 
написання коду серверного докладання, щоб усі системи легко обмінювалися 
даними і додаток можна було масштабировать. REST є узгодженим набором 
обмежень, що враховуються при проектуванні розподіленої гіпермедіа-системи. 
У певних випадках (інтернет-магазини, пошукові системи, інші системи, 
засновані на даних) це призводить до підвищення продуктивності та спрощення 
архітектури. У широкому значенні [уточнити] компоненти в REST взаємодіють 
на кшталт взаємодії клієнтів та серверів у Всесвітньому павутинні. REST є 
альтернативою RPC. 
У мережі Інтернет виклик віддаленої процедури може бути звичайним 
HTTP-запитом (зазвичай GET або POST; такий запит називають «REST-
запит»), а необхідні дані передаються як параметри запиту. 
Для веб-служб, побудованих з урахуванням REST (тобто не порушують 
обмежень, що накладаються ним), застосовують термін «RESTful». 
На відміну від веб-сервісів (веб-служб) на основі SOAP, немає 
«офіційного» стандарту для RESTful веб-API. Справа в тому, що REST є 
57 
 
архітектурним стилем, тоді як SOAP є протоколом. Незважаючи на те, що 
REST не є стандартом сам по собі, більшість RESTful-реалізацій 
використовують такі стандарти як HTTP, URL, JSON і, рідше, XML. 
 
3.2.6. JWT 
JSON Web Token (JWT) — це відкритий стандарт ( RFC 7519 ), який 
визначає компактний і автономний спосіб безпечної передачі інформації між 
сторонами як об’єкт JSON. Цю інформацію можна перевірити й довіряти, 
оскільки вона має цифровий підпис. JWT можна підписати за допомогою 
секретного (за допомогою алгоритму HMAC ) або пари відкритих і закритих 
ключів за допомогою RSA або ECDSA . 
Хоча JWT можна зашифрувати, щоб також забезпечити секретність між 
сторонами, ми зосередимося на підписаних токенах. Підписані маркери можуть 
перевірити цілісність заяв, що містяться в них, тоді як зашифровані 
токени приховують ці претензії від інших сторін. Коли токени підписуються за 
допомогою пар відкритих/приватних ключів, підпис також засвідчує, що 
підписала його лише сторона, яка володіє приватним ключем. 
Ось кілька сценаріїв, у яких веб-токени JSON корисні: 
• Авторизація : це найпоширеніший сценарій використання 
JWT. Щойно користувач увійде в систему, кожен наступний запит 
включатиме JWT, що дозволить користувачеві отримати доступ до 
маршрутів, служб і ресурсів, які дозволені цим маркером. Єдиний вхід 
– це функція, яка сьогодні широко використовує JWT через невеликі 
накладні витрати та здатність легко використовуватися в різних 
доменах. 
• Обмін інформацією : веб-токени JSON є хорошим способом безпечної 
передачі інформації між сторонами. Оскільки JWT можна підписати, 
наприклад, за допомогою пар відкритих і приватних ключів, ви можете 
бути впевнені, що відправники є тими, за кого себе видають. Крім 
того, оскільки підпис обчислюється за допомогою заголовка та 
58 
 
корисного навантаження, ви також можете переконатися, що вміст не 
підроблено. 
У своїй компактній формі веб-токени JSON складаються з трьох частин, 
розділених крапками ( .), які: 
• Заголовок 
• Корисне навантаження 
• Підпис 
Тому JWT зазвичай виглядає наступним чином. 
xxxxx.yyyyy.zzzzz 
Давайте розберемо різні частини: 
1) Заголовок зазвичай складається з двох частин: типу токена, яким є 
JWT, і використовуваного алгоритму підписання, наприклад HMAC 
SHA256 або RSA. Потім цей JSON кодується Base64Url, щоб утворити 
першу частину JWT. 
2) Корисне навантаження - друга частина токена, яка містить вимоги. 
Претензії — це заяви про сутність (як правило, користувача) та 
додаткові дані. Існує три види позовів: зареєстровані , публічні та 
приватні позови. 
• Зареєстровані претензії : це набір попередньо визначених заяв, які 
не є обов’язковими, але рекомендованими, щоб забезпечити набір 
корисних, сумісних заяв. Деякі з них: iss (емітент), exp (час 
закінчення), sub (предмет), aud (аудиторія) та інші . 
• Публічні претензії : вони можуть бути визначені за бажанням тими, 
хто використовує JWT. Але щоб уникнути колізій, їх слід 
визначити в реєстрі веб-токенів IANA JSON або визначити як URI, 
що містить простір імен, стійкий до зіткнень. 
• Приватні претензії : це спеціальні претензії, створені для обміну 
інформацією між сторонами, які погоджуються їх 
використовувати, і не є ні зареєстрованими, ні публічними 
претензіями. 
59 
 
• Зареєстровані претензії : це набір попередньо визначених заяв, які 
не є обов’язковими, але рекомендованими, щоб забезпечити набір 
корисних, сумісних заяв. Деякі з них: iss (емітент), exp (час 
закінчення), sub (предмет), aud (аудиторія) та інші . 
Корисне навантаження потім кодується Base64Url для формування другої 
частини веб-токена JSON. 
3) Підпис – третя частина, що використовується для перевірки того, що 
повідомлення не було змінено в дорозі, і, у випадку маркерів, 
підписаних за допомогою приватного ключа, він також може 
підтвердити, що відправник JWT є тим, хто він це каже. 
Вихідними є три рядки Base64-URL, розділені крапками, які можна легко 
передати в середовищах HTML і HTTP, при цьому вони більш компактні в 
порівнянні зі стандартами на основі XML, такими як SAML. 
Як працюють веб-токени JSON 
Під час аутентифікації, коли користувач успішно входить у систему, 
використовуючи свої облікові дані, буде повернуто веб-токен JSON. Оскільки 
токени є обліковими даними, потрібно бути дуже обережними, щоб запобігти 
проблемам безпеки. Загалом, ви не повинні зберігати маркери довше, ніж 
потрібно. 
Неможна зберігати конфіденційні дані сеансу в сховищі браузера через 
відсутність безпеки . 
Щоразу, коли користувач хоче отримати доступ до захищеного маршруту 
або ресурсу, користувальницький агент повинен надіслати JWT, як правило, у 
заголовку авторизації, використовуючи схему Bearer. Вміст заголовка має 
такий вигляд: 
Authorization: Bearer <token> 
 
У деяких випадках це може бути механізм авторизації без громадянства. 
Захищені маршрути сервера перевірятимуть дійсний JWT у 
Authorizationзаголовку, і якщо він присутній, користувачеві буде дозволено 
60 
 
отримати доступ до захищених ресурсів. Якщо JWT містить необхідні дані, 
потреба в запиті бази даних для певних операцій може зменшитися, хоча це 
може бути не завжди. 
Якщо маркер надіслано в Authorizationзаголовку, спільне використання 
ресурсів між джерелами (CORS) не буде проблемою, оскільки він не 
використовує файли cookie. 
 
3.2.7. Вcrypt 
Bcrypt — це функція хешування паролів, розроблена Нільсом Провосом і 
Девідом Мазьєром, заснована на шифрі Blowfish і представлена на USENIX у 
1999 році. Крім того, що він містить сіль для захисту від атак на райдужні 
таблиці, bcrypt є адаптивною функцією: з часом, кількість ітерацій можна 
збільшити, щоб зробити його повільнішим, тому він залишається стійким до 
атак грубого пошуку навіть із збільшенням обчислювальної потужності. 
Bcrypt здатний пом’якшити атаки, поєднуючи дорогу фазу налаштування 
ключа Blowfish із змінною кількістю ітерацій, щоб збільшити робоче 
навантаження та тривалість обчислень хешування. Найбільша перевага bcrypt 
полягає в тому, що з часом кількість ітерацій можна збільшити, щоб зробити 
його повільніше, дозволяючи bcrypt масштабувати з обчислювальною 
потужністю. Можна зменшити будь-які переваги, які зловмисники можуть 
отримати від швидшого обладнання, збільшивши кількість ітерацій, щоб 
зробити bcrypt повільніше. 
Вcrypt був розроблений для хешування паролів, тому це повільний 
алгоритм. Це добре для хешування паролів, оскільки зменшує кількість паролів 
посекундно, які зловмисник може хешувати під час створення атаки на 
словник. 
Ще одна перевага bcrypt полягає в тому, що для цього за замовчуванням 
потрібна сіль. Давайте глибше розглянемо, як працює ця функція хешування! 
61 
 
"bcrypt змушує вас дотримуватися найкращих методів безпеки, оскільки 
для цього потрібна сіль як частина процесу хешування. Хешування в поєднанні 
з солями захищає вас від атак на райдужні таблиці! 
Алгоритм bcrypt є результатом шифрування тексту 
"OrpheanBeholderScryDoubt" 64 рази за допомогою Blowfish . У bcrypt звичайна 
функція налаштування ключа Blowfish замінена функцією дорогого 
налаштування ключа (EksBlowfishSetup) 
Прово і Мазьєр, розробники bcrypt, використали дорогу фазу 
налаштування ключа шифру Blowfish, щоб розробити новий алгоритм 
налаштування ключа для Blowfish під назвою «eksblowfish», що означає 
«дорогий розклад ключа Blowfish». 
Що таке "налаштування ключа"? За словами Ієна Хоусона , інженера-
програміста NVIDIA: «Більшість шифрів складаються з етапу налаштування 
ключа та етапу роботи. Під час налаштування ключа внутрішній стан 
ініціалізується. Під час роботи введений зашифрований або відкритий текст 
шифрується або розшифровується. Тільки налаштування ключа потрібно 
виконати один раз для кожного ключа, який використовується" bcrypt 
виконується в два етапи : 
Фаза 1: 
Викликана функція EksBlowfishSetup встановлюється з використанням 
бажаної вартості, солі та пароля для ініціалізації стану eksblowfish. Потім bcrypt 
витрачає багато часу на виконання дорогого розкладу ключів, який складається 
з виконання виведення ключа, де ми отримуємо набір підключів з первинного 
ключа. Тут пароль використовується як первинний ключ. У випадку, якщо 
користувач вибрав неправильний або короткий пароль, ми розтягуємо цей 
пароль/ключ на довший пароль/ключ. Вищезгадана практика також відома як 
розтягування ключів . 
Те, що ми проходимо на цьому першому етапі, — це сприяти посиленню 
ключів, щоб уповільнити обчислення, які, у свою чергу, також уповільнюють 
зловмисників. 
62 
 
Фаза 2: 
Магічне значення — це 192-бітове значення OrpheanBeholderScryDoubt. 
Це значення шифрується 64 рази, використовуючи eksblowfish в режимі ECB >) 
стан із попереднього етапу. Результатом цієї фази є вартість і 128-бітове 
значення солі, об’єднане з результатом циклу шифрування. 
Алгоритм, який показує дві фази, які складають реалізацію bcrypt: 
berypt (cost, salt, pwd) 
state ← EksBlowfishSetup (cost, salt, key) 
ctext ← “OrpheanBeholderScryDoubt” 
repeat (64) 
ctext ← EncryptECB (state, ctext) 
return Concatenate (cost, salt, ctext) 
В результаті хеш з префіксом , або . Префікси додаються, щоб позначити 
використання та його версію. 
Результат bcrypt досягає основних властивостей функції захищеного 
пароля, як визначено її розробниками: 
• Він стійкий до прообразу. 
• Соляний простір достатньо великий, щоб пом’якшити атаки 
попередніх обчислень, наприклад, райдужні таблиці. 
• Він має адаптивну вартість. 
Дизайнери bcrypt вважають, що функція збереже свою силу і цінність 
протягом багатьох років. Його математичний дизайн дає впевненість 
криптографам у його стійкості до атак. 
Щодо адаптивної вартості, ми можемо сказати, що bcrypt це адаптивна 
хеш-функція, оскільки ми можемо збільшити кількість ітерацій, виконуваних 
функцією, на основі переданого ключового фактора — вартості. Ця 
адаптивність дозволяє нам компенсувати збільшення потужності комп’ютера, 
але це пов’язано з альтернативною вартістю. 
Спрощення керування паролями за допомогою Auth0 
Основна ідея перевірки пароля полягає в тому, щоб порівняти два хеші та 
визначити, чи відповідають вони один одному. Процес дуже складний. Надійна 
63 
 
стратегія ідентифікації вимагає від організації тримати в курсі криптографічних 
досягнень, розробляти процес поступового відмови від застарілих або 
вразливих алгоритмів, забезпечувати тестування ручками, інвестувати у 
фізичну та мережеву безпеку серед багатьох інших. З огляду на всі фактори, це 
непросто чи недорого. 
Ви можете мінімізувати накладні витрати на хешування, розсіювання та 
керування паролями за допомогою Auth0 . Ми вирішуємо найскладніші 
випадки використання ідентифікаційної інформації за допомогою 
розширюваної та легкої в інтеграції платформи, яка забезпечує мільярди логінів 
щомісяця. 
Auth0 допомагає запобігти потраплянню критичних даних у чужі руки. 
Ми ніколи не зберігаємо паролі у відкритому тексті. Паролі завжди хешуються 
та підсолюються за допомогою bcrypt . Ми вбудували в наш продукт 
найсучасніші засоби безпеки, щоб захистити ваш бізнес і користувачів. 
 
3.3 Процес взаємодії з АІС 
Для входу в АІС використовуються облікові дані, що після реєстрації 
містяться в файлах системи. Для початку потрібно зареєструватись, для цього 
необхідно натиснути на поле «Sing Up» і у відкритій формі реєстрації ввести 
ім'я користувача, пошту і пароль(Рис. 3.1).  
 
Рис. 3.1. Форма реєстрації 
64 
 
Після введення даних і натисненні на кнопку «Sing Up» користувача буде 
зареєстровано і на екрані відобразить повідомлення про реестрацію(Рис 3.2). 
 
Рис. 3.2. Повідомлення про реестрацію 
Для входу потрібно натиснути на вкладку «Login», де після вводу своїх 
даних користувач проходить автентифікацію та може надсилати запити до БД 
АІС(Рис. 3.3). 
 
Рис. 3.3. Форма входу 
 
Після успішного входу користувач отримає повідомлення про вхід (Рис. 
3.4). 
65 
 
 
Рис. 3.4. Повідомлення про вхід 
 
Новий користувач буде мати роль «Cor». Роль можна переглянути на 
сторінці профілю(Рис 3.5). 
 
Рис. 3.5. Сторінка профілю користувача 
66 
 
Вікно профілю адміністратора та модератора, нічим майже не 
відрізняється від профілю звичайного користувача, за винятком рівня 
допуску(Rol). Для адміністратора існує додаткову вкладнку «Admin Board», 
доступ до якої є тільки в адміністратора. (Рис 3.6). 
Звичайний користувач, не буде бачити цю вкладнику, в нього буде 
відображатися лише ті функції, які дозволяє рівень допуску користувача. 
 
 
Рис. 3.6. Сторінка профілю адміністратора 
Висновки 
В даному розділі було представлене дослідження методів захисту в 
системі з багаторівневою безпекою. Було визначено складові проекту, та 
розглянуто стек технологій використовуваних для його реалізації. 
За основу для побудови проекту було використано Angular – це 
платформа та основа для побудови односторінкових клієнтських додатків за 
допомогою HTML та TypeScript. Angular реалізує основну та додаткову 
функціональність як набір бібліотек TypeScript, які можна імпортувати у 
додатки. 
67 
 
У проекті було застосовано сучасні методи захисту АІС, такі як: 
− Аутентифікація 
− Авторизація 
− Керування доступом 
− Логування 
− Шифрування 
 
  
68 
 
ВИСНОВКИ 
Захист конфіденційної інформації в АІС загального та спеціального 
призначення завжди залишиться важливим питанням, тому для збільшення 
захисту інформаціїї треба застосовувати багаторівний захист. 
В роботі розглянуто концепцію багаторівого захисту АІС, знайдені 
переваги та недоліки застосування різноманітних типів керування дступом та 
проведено аналіз концепції багаторівневого захисту. Розроблено алгоритми 
здійснення операцій реляційної алгебри в системах з застосуванням 
багаторівого захисту. Було розглянуто та використано в проекті сучасні методи 
безпеки АІС. 
Проведене в роботі дослідження показало, що кращими для застосування 
є моделі Smith-Winslett та MLR. Обидві моделі показали себе добре, тому є сенс 
використовувати саме їх, обераючи більш підходящу модель. Щодо моделі 
Jajodia– Sandhu, то вона є не ефективною, а також не зручною для застосування 
для систем з великим вмістом інформації. Модель SeaView в порівнянні з 
іншими моделями морально застаріла і не підходить для використання на 
сьогодні.  
Найбільш простими для впровадження на сьогодні є моделі Smith-
Winslett та Multilevel Relational. Вони відходять для застосування сучасних 
систем із багаторівневою безпекою, в тому числі для систем спеціального 
призначення. 
  
69 
 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
1. Angular | Введение и начало работы [Електронний ресурс] – Режим 
доступу до ресурсу https://metanit.com/web/angular2/1.1.php 
2. Angular Medium / angular.medium.com [Електронний ресурс] – 2020. – 
Режим доступу до ресурсу: https://blog.angular.io/. 
3. Bertino E. Database security - Concepts, approaches, and challenges. IEEE 
Transactions on Dependable and Secure Computing 2 / E. Bertino, R. Sandhu, 
2005. – 2–19. 
4. Connolly T. Database Systems. A Practical Approach to Design, 
Implementation, and Management / T. Connolly, C. Begg, 2015. – (6), 168-
180. 
5. Express - фреймворк веб-приложений Node.js [Електронний ресурс] – 
Режим доступу до ресурсу: https://expressjs.com/ru/ 
6. Hellerstein J.M. Architecture of a database system. Foundations and Trends in 
Databases: J. M. Hellerstein, Michael Stonebraker, James Hamilton, 2007. – 
141–259 с. 
7. Library of free on-line IT books [Електронний ресурс] – Режим доступу до 
ресурсу: https://www.techotopia.com. 
8. Mikko T.S. Database security and the problem of polyinstantiation: A moral 
scrutiny / T.S. Mikko. – Australian Journal of Information Systems 10 (1), 
2002. – 41–49. 
9. Multilevel security for relational databases / S. Osama, M. El-Sayed, S. Hala та 
ін. – CRC Press, 2014. – 35–53. 
10. Nelson D. Using polyinstantiation to develop an MLS application / D. Nelson, 
C. Paradise. – Computer Security Applications Conference, 1991. – 12–22. 
11. Node.js [Електронний ресурс] – Режим доступу до ресурсу: 
https://ru.m.wikipedia.org/wiki/Node.js 
12. Pierangela S. Access control: Policies, models, and mechanisms. In 
Foundations of security analysis and design / S. Pierangela, D. Sabrina. – 
Berlin: Springer, 2001. – 137–196. 
70 
 
13. PostgreSQL [Електронний ресурс] – Режим доступу до ресурсу 
https://ru.m.wikipedia.org/wiki/PostgreSQL 
14. REST [Електронний ресурс] – Режим доступу до ресурсу 
https://ru.m.wikipedia.org/wiki/REST 
15. RxJS library / rxjs-dev.firebaseapp.com [Електронний ресурс] – 2020. – 
Режим доступу до ресурсу: https://rxjs-dev.firebaseapp.com/guide/overview. 
16. SearchSecurity [Електронний ресурс] – Режим доступу до ресурсу: 
https://searchsecurity.techtarget.com/. 
17. The Multilevel Relational (MLR) Data Model [Електронний ресурс] – 
Режим доступу до ресурсу: 
https://profsandhu.com/journals/tissec/t98mlr.pdf. 
18. Walid R. A multi-purpose implementation of mandatory access control in 
relational database management systems / R. Walid, P. Bird. – Toronto, 2004. 
– 1010–1020. 
19. Xu L. Study on methods for data confidentiality and data integrity in relational 
databases : L. Xu, D. Sun, D. Liu. – ICCSIT, 2010. – 292–295. 
20. Документація IBM [Електронний ресурс] – Режим доступу до ресурсу: 
https://www.ibm.com/support/knowledgecenter. 
21. Документація Microsoft SQL Server [Електронний ресурс] – Режим 
доступу до ресурса: https://docs.microsoft.com/en-us/sql/sql-server/sql-
servertechnical-documentation. 
22. Документація Microsoft Visual Studio [Електронний ресурс] – Режим 
доступу до ресурса: https://docs.microsoft.com/en-us/visualstudio/ 
23. Крутіков М. О. Дослідження автоматизованих систем управління 
ресурсами підприємства / М. О. Крутіков, О. В. Нечипоренко, С. А. 
Міценко // Збірник тез доповідей студентської науковопрактичної 
конференції ЧДТУ: 19–22 квітня 2021 р. [Електронний ресурс] / [упоряд. 
Мельник І.В.]; Мво освіти і науки України, Черкас. держ. технол. унт. – 
Черкаси : ЧДТУ, 2021. – C. 126-127. 
71 
 
24. Нечипоренко О. В. Дослідження методів захисту інформації в 
автоматизованих системах / О. В. Нечипоренко, М. О. Крутіков // Сучасні 
технології в енергетиці, електромеханіці, системах управління та 
машинобудуванні: Матеріали ІV Всеукраїнської науково-практичної 
інтернет-конференції (м. Бахмут, 25-26 листопада 2021 р.) / Навчально-
науковий професійно-педагогічний інститут Української інженерно-
педагогічної академії [упоряд. П.О. Чикунов]. – Бахмут: ННППІ УІПА, 
2021. – С. 122-123. 
 
  
72 
 
ДОДАТОК А 
Лістинг проекту 
1 Код package.json 
{ 
  "name": "node-js-jwt-auth-mongodb", 
  "version": "1.0.0", 
  "description": "Node.js + MongoDB: JWT Authentication & 
Authorization", 
  "main": "server.js", 
  "scripts": { 
    "test": "echo \"Error: no test specified\" && exit 1" 
  }, 
  "keywords": [ 
    "node.js", 
    "express", 
    "jwt", 
    "authentication", 
    "mongodb" 
  ], 
  "author": "koder", 
  "license": "ISC", 
  "dependencies": { 
    "bcryptjs": "^2.4.3", 
    "body-parser": "^1.19.0", 
    "cors": "^2.8.5", 
    "express": "^4.17.1", 
    "jsonwebtoken": "^8.5.1", 
    "mongoose": "^5.9.1" 
  } 
} 
 
2. Створення server.js 
const express = require("express"); 
const bParser = require("body-parser"); 
const cors = require("cors"); 
 
73 
 
const app = express(); 
 
var corsOptions = { 
  origin: "http://localhost:8081" 
}; 
 
app.use(cors(corsOptions)); 
 
// parse requests of content-type - application/json 
app.use(bParser.json()); 
 
// parse requests of content-type - application/x-www-form-
urlencoded 
app.use(bParser.urlencoded({ extended: true })); 
 
// simple route 
app.get("/", (req, res) => { 
  res.json({ message: "Welcome to koder application." }); 
}); 
 
// set port, listen for requests 
const PORT = process.env.PORT || 8080; 
app.listen(PORT, () => { 
  console.log(`Server is running on port ${PORT}.`); 
}); 
 
3. Створення db.config.js 
module.exports = { 
  HOST: "localhost", 
  PORT: 27017, 
  DB: "koder_db" 
}; 
 
4. Створення role.model.js 
const mg = require("mongoose"); 
 
74 
 
const Role = mg.model( 
  "Role", 
  new mg.Schema({ 
    name: String 
  }) 
); 
 
module.exports = Role; 
 
5. Створення Cor.model.js 
const mg = require("mongoose"); 
 
const Cor = mg.model( 
  " Cor ", 
  new mg.Schema({ 
    Username: String, 
    email: String, 
    password: String, 
    Rol: [ 
      { 
        type: mg.Schema.Types.ObjectId, 
        ref: "Role" 
      } 
    ] 
  }) 
); 
 
module.exports = Cor; 
 
6. Створення index.js 
const mg = require('mongoose'); 
mg.Promise = global.Promise; 
 
const db = {}; 
 
75 
 
db.mg = mg; 
 
db.cor = require("./cor.model"); 
db.role = require("./role.model"); 
 
db.ROL= ["cor", "admin", "moderator"]; 
 
module.exports = db; 
 
7. Відкриття з'єднання з БД в server.js 
... 
const app = express(); 
app.use(...); 
 
const db = require("./app/models"); 
const Role = db.role; 
 
db.mg 
  
.connect(`mongodb://${dbConfig.HOST}:${dbConfig.PORT}/${dbConfig.D
B}`, { 
    useNewUrlParser: true, 
    useUnifiedTopology: true 
  }) 
  .then(() => { 
    console.log("Successfully connect to MongoDB."); 
    initial(); 
  }) 
  .catch(err => { 
    console.error("Connection error", err); 
    process.exit(); 
  }); 
 
... 
function initial() { 
  Role.estimatedDocumentCount((err, count) => { 
    if (!err && count === 0) { 
76 
 
      new Role({ 
        name: "cor" 
      }).save(err => { 
        if (err) { 
          console.log("error", err); 
        } 
 
        console.log("added 'cor' to Rolcollection"); 
      }); 
 
      new Role({ 
        name: "moderator" 
      }).save(err => { 
        if (err) { 
          console.log("error", err); 
        } 
 
        console.log("added 'moderator' to Rolcollection"); 
      }); 
 
      new Role({ 
        name: "admin" 
      }).save(err => { 
        if (err) { 
          console.log("error", err); 
        } 
 
        console.log("added 'admin' to Rolcollection"); 
      }); 
    } 
  }); 
} 
 
8. Створення auth.config.js 
module.exports = { 
  secret: "koder-secret-key" 
77 
 
}; 
9.Створення функції перевірки дії реєстрації в VSU.js  
const db = require("../models"); 
const ROL= db.ROL; 
const Cor = db.cor; 
 
checkDuplicateUsernameOrEmail = (req, res, next) => { 
  // Username 
  Cor.findOne({ 
    Username: req.body.Username 
  }).exec((err, cor) => { 
    if (err) { 
      res.status(500).send({ message: err }); 
      return; 
    } 
 
    if (cor) { 
      res.status(400).send({ message: "Failed! Username is already 
in use!" }); 
      return; 
    } 
 
    // Email 
    Cor.findOne({ 
      email: req.body.email 
    }).exec((err, cor) => { 
      if (err) { 
        res.status(500).send({ message: err }); 
        return; 
      } 
 
      if (cor) { 
        res.status(400).send({ message: "Failed! Email is already 
in use!" }); 
        return; 
      } 
 
78 
 
      next(); 
    }); 
  }); 
}; 
 
checkRolExisted = (req, res, next) => { 
  if (req.body.Rol) { 
    for (let i = 0; i < req.body.Rol.length; i++) { 
      if (!ROL.includes(req.body.Rol[i])) { 
        res.status(400).send({ 
          message: `Failed! Role ${req.body.Rol[i]} does not 
exist!` 
        }); 
        return; 
      } 
    } 
  } 
 
  next(); 
}; 
 
const VSU = { 
  checkDuplicateUsernameOrEmail, 
  checkRolExisted 
}; 
 
module.exports = VSU; 
 
10. Створення обробки аутентифікації та авторизації в jwtAuth.js 
const mjwt = require("jsonwebtoken"); 
const config = require("../config/auth.config.js"); 
const db = require("../models"); 
const Cor = db.cor; 
const Role = db.role; 
 
verifyToken = (req, res, next) => { 
  let token = req.headers["x-access-token"]; 
79 
 
 
  if (!token) { 
    return res.status(403).send({ message: "No token provided!" 
}); 
  } 
 
  jwt.verify(token, config.secret, (err, decoded) => { 
    if (err) { 
      return res.status(401).send({ message: "Unauthorized!" }); 
    } 
    req.corId = decoded.id; 
    next(); 
  }); 
}; 
 
isAdmin = (req, res, next) => { 
  Cor.findById(req.corId).exec((err, cor) => { 
    if (err) { 
      res.status(500).send({ message: err }); 
      return; 
    } 
 
    Role.find( 
      { 
        _id: { $in: cor.Rol} 
      }, 
      (err, Rol) => { 
        if (err) { 
          res.status(500).send({ message: err }); 
          return; 
        } 
 
        for (let i = 0; i < Rol.length; i++) { 
          if (Rol[i].name === "admin") { 
            next(); 
            return; 
          } 
80 
 
        } 
 
        res.status(403).send({ message: "Require Admin Role!" }); 
        return; 
      } 
    ); 
  }); 
}; 
 
isModerator = (req, res, next) => { 
  Cor.findById(req.corId).exec((err, cor) => { 
    if (err) { 
      res.status(500).send({ message: err }); 
      return; 
    } 
 
    Role.find( 
      { 
        _id: { $in: cor.Rol} 
      }, 
      (err, Rol) => { 
        if (err) { 
          res.status(500).send({ message: err }); 
          return; 
        } 
 
        for (let i = 0; i < Rol.length; i++) { 
          if (Rol[i].name === "moderator") { 
            next(); 
            return; 
          } 
        } 
 
        res.status(403).send({ message: "Require Moderator Role!" 
}); 
        return; 
      } 
81 
 
    ); 
  }); 
}; 
 
const jwtAuth = { 
  verifyToken, 
  isAdmin, 
  isModerator 
}; 
module.exports = jwtAuth; 
 
11. Створення контролера для аутентифікації в auth.contr.js 
const config = require("../config/auth.config"); 
const db = require("../models"); 
const Cor = db.cor; 
const Role = db.role; 
 
var jwt = require("jsonwebtoken"); 
var bcrypt = require("bcryptjs"); 
 
exports.signup = (req, res) => { 
  const Cor = new Cor({ 
    Username: req.body.Username, 
    email: req.body.email, 
    password: bcrypt.hashSync(req.body.password, 8) 
  }); 
 
  cor.save((err, cor) => { 
    if (err) { 
      res.status(500).send({ message: err }); 
      return; 
    } 
 
    if (req.body.Rol) { 
      Role.find( 
        { 
82 
 
          name: { $in: req.body.Rol} 
        }, 
        (err, Rol) => { 
          if (err) { 
            res.status(500).send({ message: err }); 
            return; 
          } 
 
          cor.Rol= Rol.map(role => role._id); 
          cor.save(err => { 
            if (err) { 
              res.status(500).send({ message: err }); 
              return; 
            } 
 
            res.send({ message: "Cor was registered successfully!" 
}); 
          }); 
        } 
      ); 
    } else { 
      Role.findOne({ name: "cor" }, (err, role) => { 
        if (err) { 
          res.status(500).send({ message: err }); 
          return; 
        } 
 
        cor.Rol= [role._id]; 
        cor.save(err => { 
          if (err) { 
            res.status(500).send({ message: err }); 
            return; 
          } 
 
          res.send({ message: "Cor was registered successfully!" 
}); 
        }); 
      }); 
83 
 
    } 
  }); 
}; 
 
exports.signin = (req, res) => { 
  Cor.findOne({ 
    Username: req.body.Username 
  }) 
    .populate("Rol", "-__v") 
    .exec((err, cor) => { 
      if (err) { 
        res.status(500).send({ message: err }); 
        return; 
      } 
 
      if (!cor) { 
        return res.status(404).send({ message: "Cor Not found." 
}); 
      } 
 
      var passwordIsValid = bcrypt.compareSync( 
        req.body.password, 
        Cor.password 
      ); 
 
      if (!passwordIsValid) { 
        return res.status(401).send({ 
          accessToken: null, 
          message: "Invalid Password!" 
        }); 
      } 
 
      var token = jwt.sign({ id: Cor.id }, config.secret, { 
        expiresIn: 86400 // 24 hours 
      }); 
 
      var authorities = []; 
84 
 
 
      for (let i = 0; i < Cor.Rol.length; i++) { 
        authorities.push("ROLE_" + Cor.Rol[i].name.toUpperCase()); 
      } 
      res.status(200).send({ 
        id: Cor._id, 
        Username: Cor.Username, 
        email: Cor.email, 
        Rol: authorities, 
        accessToken: token 
      }); 
    }); 
}; 
 
12.Створення контролера для авторизації в Cor.contr.js 
exports.allAccess = (req, res) => { 
  res.status(200).send("Public Content."); 
}; 
 
exports.CorBoard = (req, res) => { 
  res.status(200).send("Cor Content."); 
}; 
 
exports.adminBoard = (req, res) => { 
  res.status(200).send("Admin Content."); 
}; 
 
exports.moderatorBoard = (req, res) => { 
  res.status(200).send("Moderator Content."); 
}; 
 
13. Створення маршрутизації для аутентифікації в auth.routes.js 
const { VSU } = require("../middlewares"); 
const contr = require("../contrs/auth.contr"); 
 
85 
 
module.exports = function(app) { 
  app.use(function(req, res, next) { 
    res.header( 
      "Access-Control-Allow-Headers", 
      "x-access-token, Origin, Content-Type, Accept" 
    ); 
    next(); 
  }); 
 
  app.post( 
    "/api/auth/signup", 
    [ 
      VSU.checkDuplicateUsernameOrEmail, 
      VSU.checkRolExisted 
    ], 
    contr.signup 
  ); 
 
  app.post("/api/auth/signin", contr.signin); 
}; 
 
14. Створення маршрутизації для авторизації в Cor.routes.js 
const { jwtAuth } = require("../middlewares"); 
const contr = require("../contrs/Cor.contr"); 
 
module.exports = function(app) { 
  app.use(function(req, res, next) { 
    res.header( 
      "Access-Control-Allow-Headers", 
      "x-access-token, Origin, Content-Type, Accept" 
    ); 
    next(); 
  }); 
 
  app.get("/api/test/all", contr.allAccess); 
 
86 
 
  app.get("/api/test/Cor", [jwtAuth.verifyToken], contr.CorBoard); 
 
  app.get( 
    "/api/test/mod", 
    [jwtAuth.verifyToken, jwtAuth.isModerator], 
    contr.moderatorBoard 
  ); 
 
  app.get( 
    "/api/test/admin", 
    [jwtAuth.verifyToken, jwtAuth.isAdmin], 
    contr.adminBoard 
  ); 
}; 
 
15. Внесення маршрутів в server.js 
... 
// routes 
require('./app/routes/auth.routes')(app); 
require('./app/routes/Cor.routes')(app); 
 
// set port, listen for requests 
... 
 
16. Імпорт FormsModule та HttpClientModule в app.module.ts 
import { BrowserModule } from '@angular/platform-browser'; 
import { NgModule } from '@angular/core'; 
 
import { AppRoutingModule } from './app-routing.module'; 
import { FormsModule } from '@angular/forms'; 
import { HttpClientModule } from '@angular/common/http'; 
 
import { AppComponent } from './app.component'; 
import { LoginComponent } from './login/login.component'; 
import { RegisterComponent } from './register/register.component'; 
import { HomeComponent } from './home/home.component'; 
87 
 
import { ProfileComponent } from './profile/profile.component'; 
import { BoardAdminComponent } from './board-admin/board-
admin.component'; 
import { BoardModeratorComponent } from './board-moderator/board-
moderator.component'; 
import { BoardCorComponent } from './board-Cor/board-
Cor.component'; 
 
import { authInterceptorProviders } from 
'./_helpers/auth.interceptor'; 
 
@NgModule({ 
  declarations: [ 
    AppComponent, 
    LoginComponent, 
    RegisterComponent, 
    HomeComponent, 
    ProfileComponent, 
    BoardAdminComponent, 
    BoardModeratorComponent, 
    BoardCorComponent 
  ], 
  imports: [ 
    BrowserModule, 
    AppRoutingModule, 
    FormsModule, 
    HttpClientModule 
  ], 
  providers: [authInterceptorProviders], 
  bootstrap: [AppComponent] 
}) 
export class AppModule { } 
 
17. Служба аутентифікації в auth.service.ts 
import { Injectable } from '@angular/core'; 
import { HttpClient, HttpHeaders } from '@angular/common/http'; 
import { Observable } from 'rxjs'; 
88 
 
 
const AUTH_API = 'http://localhost:8080/api/auth/'; 
 
const httpOptions = { 
  headers: new HttpHeaders({ 'Content-Type': 'application/json' }) 
}; 
 
@Injectable({ 
  providedIn: 'root' 
}) 
export class AuthService { 
 
  constructor(private http: HttpClient) { } 
 
  login(credentials): Observable<any> { 
    return this.http.post(AUTH_API + 'signin', { 
      Username: credentials.Username, 
      password: credentials.password 
    }, httpOptions); 
  } 
 
  register(Cor): Observable<any> { 
    return this.http.post(AUTH_API + 'signup', { 
      Username: Cor.Username, 
      email: Cor.email, 
      password: Cor.password 
    }, httpOptions); 
  } 
} 
 
18. Служба зберігання токенів в token-storage.service.ts 
import { Injectable } from '@angular/core'; 
 
const KEYTOKEN = 'auth-token'; 
const KEYCOR = 'auth-Cor'; 
 
89 
 
@Injectable({ 
  providedIn: 'root' 
}) 
export class TokenStorageService { 
 
  constructor() { } 
 
  signOut(): void { 
    window.sessionStorage.clear(); 
  } 
 
  public saveToken(token: string): void { 
    window.sessionStorage.removeItem(KEYTOKEN); 
    window.sessionStorage.setItem(KEYTOKEN, token); 
  } 
 
  public getToken(): string { 
    return sessionStorage.getItem(KEYTOKEN); 
  } 
 
  public saveCor(Cor): void { 
    window.sessionStorage.removeItem(KEYCOR); 
    window.sessionStorage.setItem(KEYCOR, JSON.stringify(Cor)); 
  } 
 
  public getCor(): any { 
    return JSON.parse(sessionStorage.getItem(KEYCOR)); 
  } 
} 
 
19. Служба даних  в Cor.service.ts 
import { Injectable } from '@angular/core'; 
import { HttpClient } from '@angular/common/http'; 
import { Observable } from 'rxjs'; 
 
const AURL = 'http://localhost:8080/api/test/'; 
90 
 
 
@Injectable({ 
  providedIn: 'root' 
}) 
export class CorService { 
 
  constructor(private http: HttpClient) { } 
 
  getPublicContent(): Observable<any> { 
    return this.http.get(AURL + 'all', { responseType: 'text' }); 
  } 
 
  getCorBoard(): Observable<any> { 
    return this.http.get(AURL + 'Cor', { responseType: 'text' }); 
  } 
 
  getModeratorBoard(): Observable<any> { 
    return this.http.get(AURL + 'mod', { responseType: 'text' }); 
  } 
 
  getAdminBoard(): Observable<any> { 
    return this.http.get(AURL + 'admin', { responseType: 'text' 
}); 
  } 
} 
 
20. Перехоплювач HTTP в auth.interceptor.ts 
import { HTTP_INTERCEPTORS, HttpEvent } from 
'@angular/common/http'; 
import { Injectable } from '@angular/core'; 
import { HttpInterceptor, HttpHandler, HttpRequest } from 
'@angular/common/http'; 
 
import { TokenStorageService } from '../_services/token-
storage.service'; 
import { Observable } from 'rxjs'; 
 
91 
 
const KEYTOKENHEADER = 'Authorization'; 
 
@Injectable() 
export class AuthInterceptor implements HttpInterceptor { 
  constructor(private token: TokenStorageService) { } 
 
  intercept(req: HttpRequest<any>, next: HttpHandler): 
Observable<HttpEvent<any>> { 
    let authReq = req; 
    const token = this.token.getToken(); 
    if (token != null) { 
      authReq = req.clone({ headers: 
req.headers.set(KEYTOKENHEADER, 'Bearer ' + token) }); 
    } 
    return next.handle(authReq); 
  } 
} 
 
export const authInterceptorProviders = [ 
  { provide: HTTP_INTERCEPTORS, useClass: AuthInterceptor, multi: 
true } 
]; 
 
21. Імпорт Bootstrap в index.html 
<!DOCTYPE html> 
<html lang="en"> 
  <head> 
    ... 
    <link 
      rel="stylesheet" 
      
href="https://stackpath.bootstrapcdn.com/bootstrap/4.4.1/css/boots
trap.min.css" 
      integrity="sha384-
Vkoo8x4CGsO3+Hhxv8T/Q5PaXtkKtu6ug5TOeNV6gBiFeWPGFN9MuhOf23Q9Ifjh" 
      crossorigin="anonymous" 
    /> 
  </head> 
92 
 
  <body> 
    <app-root></app-root> 
  </body> 
</html> 
 
22. Створення компонентів для аутентифікації в register.component.ts 
import { Component, OnInit } from '@angular/core'; 
import { AuthService } from '../_services/auth.service'; 
 
@Component({ 
  selector: 'app-register', 
  templateUrl: './register.component.html', 
  styleUrls: ['./register.component.css'] 
}) 
export class RegisterComponent implements OnInit { 
 
  form: any = {}; 
  isSuccessful = false; 
  isSignUpFailed = false; 
  errorMessage = ''; 
 
  constructor(private authService: AuthService) { } 
 
  ngOnInit(): void { 
  } 
 
  onSubmit(): void { 
    this.authService.register(this.form).subscribe( 
      data => { 
        console.log(data); 
        this.isSuccessful = true; 
        this.isSignUpFailed = false; 
      }, 
      err => { 
        this.errorMessage = err.error.message; 
        this.isSignUpFailed = true; 
93 
 
      } 
    ); 
  } 
 
} 
 
23. Перевірка форми в register.component.html 
<div class="col-md-12"> 
  <div class="card card-container"> 
    <img 
      id="profile-img" 
      src="//ssl.gstatic.com/accounts/ui/avatar_2x.png" 
      class="profile-img-card" 
    /> 
    <form 
      *ngIf="!isSuccessful" 
      name="form" 
      (ngSubmit)="f.form.valid && onSubmit()" 
      #f="ngForm" 
      novalidate 
    > 
      <div class="form-group"> 
        <label for="Username">Username</label> 
        <input 
          type="text" 
          class="form-control" 
          name="Username" 
          [(ngModel)]="form.Username" 
          required 
          minlength="3" 
          maxlength="20" 
          #Username="ngModel" 
        /> 
        <div class="alert-danger" *ngIf="f.submitted && 
Username.invalid"> 
          <div *ngIf="Username.errors.required">Username is 
required</div> 
94 
 
          <div *ngIf="Username.errors.minlength"> 
            Username must be at least 3 characters 
          </div> 
          <div *ngIf="Username.errors.maxlength"> 
            Username must be at most 20 characters 
          </div> 
        </div> 
      </div> 
      <div class="form-group"> 
        <label for="email">Email</label> 
        <input 
          type="email" 
          class="form-control" 
          name="email" 
          [(ngModel)]="form.email" 
          required 
          email 
          #email="ngModel" 
        /> 
        <div class="alert-danger" *ngIf="f.submitted && 
email.invalid"> 
          <div *ngIf="email.errors.required">Email is 
required</div> 
          <div *ngIf="email.errors.email"> 
            Email must be a valid email address 
          </div> 
        </div> 
      </div> 
      <div class="form-group"> 
        <label for="password">Password</label> 
        <input 
          type="password" 
          class="form-control" 
          name="password" 
          [(ngModel)]="form.password" 
          required 
          minlength="6" 
          #password="ngModel" 
95 
 
        /> 
        <div class="alert-danger" *ngIf="f.submitted && 
password.invalid"> 
          <div *ngIf="password.errors.required">Password is 
required</div> 
          <div *ngIf="password.errors.minlength"> 
            Password must be at least 6 characters 
          </div> 
        </div> 
      </div> 
      <div class="form-group"> 
        <button class="btn btn-primary btn-block">Sign Up</button> 
      </div> 
 
      <div class="alert alert-warning" *ngIf="f.submitted && 
isSignUpFailed"> 
        Signup failed!<br />{{ errorMessage }} 
      </div> 
    </form> 
 
    <div class="alert alert-success" *ngIf="isSuccessful"> 
      Your registration is successful! 
    </div> 
  </div> 
</div> 
 
24. Компонент входу в login.component.ts 
import { Component, OnInit } from '@angular/core'; 
import { AuthService } from '../_services/auth.service'; 
import { TokenStorageService } from '../_services/token-
storage.service'; 
 
@Component({ 
  selector: 'app-login', 
  templateUrl: './login.component.html', 
  styleUrls: ['./login.component.css'] 
}) 
96 
 
export class LoginComponent implements OnInit { 
 
  form: any = {}; 
  isLoggedIn = false; 
  isLoginFailed = false; 
  errorMessage = ''; 
  Rol: string[] = []; 
 
  constructor(private authService: AuthService, private 
tokenStorage: TokenStorageService) { } 
 
  ngOnInit(): void { 
    if (this.tokenStorage.getToken()) { 
      this.isLoggedIn = true; 
      this.Rol= this.tokenStorage.getCor().Rol; 
    } 
  } 
 
  onSubmit(): void { 
    this.authService.login(this.form).subscribe( 
      data => { 
        this.tokenStorage.saveToken(data.accessToken); 
        this.tokenStorage.saveCor(data); 
 
        this.isLoginFailed = false; 
        this.isLoggedIn = true; 
        this.Rol= this.tokenStorage.getCor().Rol; 
        this.reloadPage(); 
      }, 
      err => { 
        this.errorMessage = err.error.message; 
        this.isLoginFailed = true; 
      } 
    ); 
  } 
 
  reloadPage(): void { 
97 
 
    window.location.reload(); 
  } 
 
} 
 
25. Підтвердження даних  в формі login.component.html 
<div class="col-md-12"> 
  <div class="card card-container"> 
    <img 
      id="profile-img" 
      src="//ssl.gstatic.com/accounts/ui/avatar_2x.png" 
      class="profile-img-card" 
    /> 
    <form 
      *ngIf="!isLoggedIn" 
      name="form" 
      (ngSubmit)="f.form.valid && onSubmit()" 
      #f="ngForm" 
      novalidate 
    > 
      <div class="form-group"> 
        <label for="Username">Username</label> 
        <input 
          type="text" 
          class="form-control" 
          name="Username" 
          [(ngModel)]="form.Username" 
          required 
          #Username="ngModel" 
        /> 
        <div 
          class="alert alert-danger" 
          role="alert" 
          *ngIf="f.submitted && Username.invalid" 
        > 
          Username is required! 
98 
 
        </div> 
      </div> 
      <div class="form-group"> 
        <label for="password">Password</label> 
        <input 
          type="password" 
          class="form-control" 
          name="password" 
          [(ngModel)]="form.password" 
          required 
          minlength="6" 
          #password="ngModel" 
        /> 
        <div 
          class="alert alert-danger" 
          role="alert" 
          *ngIf="f.submitted && password.invalid" 
        > 
          <div *ngIf="password.errors.required">Password is 
required</div> 
          <div *ngIf="password.errors.minlength"> 
            Password must be at least 6 characters 
          </div> 
        </div> 
      </div> 
      <div class="form-group"> 
        <button class="btn btn-primary btn-block"> 
          Login 
        </button> 
      </div> 
      <div class="form-group"> 
        <div 
          class="alert alert-danger" 
          role="alert" 
          *ngIf="f.submitted && isLoginFailed" 
        > 
          Login failed: {{ errorMessage }} 
99 
 
        </div> 
      </div> 
    </form> 
 
    <div class="alert alert-success" *ngIf="isLoggedIn"> 
      Logged in as {{ Rol}}. 
    </div> 
  </div> 
</div> 
 
26. Компонент профілю profile.component.ts 
import { Component, OnInit } from '@angular/core'; 
import { TokenStorageService } from '../_services/token-
storage.service'; 
 
@Component({ 
  selector: 'app-profile', 
  templateUrl: './profile.component.html', 
  styleUrls: ['./profile.component.css'] 
}) 
export class ProfileComponent implements OnInit { 
 
  currentCor: any; 
 
  constructor(private token: TokenStorageService) { } 
 
  ngOnInit(): void { 
    this.currentCor = this.token.getCor(); 
  } 
 
} 
 
27. Компонент профілю profile.component.html 
<div class="container" *ngIf="currentCor; else loggedOut"> 
  <header class="jumbotron"> 
    <h3> 
100 
 
      <strong>{{ currentCor.Username }}</strong> Profile 
    </h3> 
  </header> 
  <p> 
    <strong>Token:</strong> 
    {{ currentCor.accessToken.substring(0, 20) }} ... 
    {{ currentCor.accessToken.substr(currentCor.accessToken.length 
- 20) }} 
  </p> 
  <p> 
    <strong>Email:</strong> 
    {{ currentCor.email }} 
  </p> 
  <strong>Rol:</strong> 
  <ul> 
    <li *ngFor="let role of currentCor.Rol"> 
      {{ role }} 
    </li> 
  </ul> 
</div> 
 
<ng-template #loggedOut> 
  Please login. 
</ng-template> 
 
28. Створення компонентів на основі ролей home.component.ts 
import { Component, OnInit } from '@angular/core'; 
import { CorService } from '../_services/Cor.service'; 
 
@Component({ 
  selector: 'app-home', 
  templateUrl: './home.component.html', 
  styleUrls: ['./home.component.css'] 
}) 
export class HomeComponent implements OnInit { 
 
  content: string; 
101 
 
 
  constructor(private CorService: CorService) { } 
 
  ngOnInit(): void { 
    this.CorService.getPublicContent().subscribe( 
      data => { 
        this.content = data; 
      }, 
      err => { 
        this.content = JSON.parse(err.error).message; 
      } 
    ); 
  } 
 
} 
 
29. Створення компонентів на основі ролей  home.component.html 
<div class="container"> 
  <header class="jumbotron"> 
    <p>{{ content }}</p> 
  </header> 
</div> 
 
30. Захищення компонентів board-admin.component.ts 
import { Component, OnInit } from '@angular/core'; 
import { CorService } from '../_services/Cor.service'; 
 
@Component({ 
  selector: 'app-board-admin', 
  templateUrl: './board-admin.component.html', 
  styleUrls: ['./board-admin.component.css'] 
}) 
export class BoardAdminComponent implements OnInit { 
 
  content: string; 
102 
 
 
  constructor(private CorService: CorService) { } 
 
  ngOnInit(): void { 
    this.CorService.getAdminBoard().subscribe( 
      data => { 
        this.content = data; 
      }, 
      err => { 
        this.content = JSON.parse(err.error).message; 
      } 
    ); 
  } 
 
} 
 
31. Захищення компонентів board-admin.component.html 
<div class="container"> 
  <header class="jumbotron"> 
    <p>{{ content }}</p> 
  </header> 
</div> 
 
32. Модуль маршрутизації додатків app-routing.module.ts . 
import { NgModule } from '@angular/core'; 
import { Routes, RouterModule } from '@angular/router'; 
 
import { RegisterComponent } from './register/register.component'; 
import { LoginComponent } from './login/login.component'; 
import { HomeComponent } from './home/home.component'; 
import { ProfileComponent } from './profile/profile.component'; 
import { BoardCorComponent } from './board-Cor/board-
Cor.component'; 
import { BoardModeratorComponent } from './board-moderator/board-
moderator.component'; 
103 
 
import { BoardAdminComponent } from './board-admin/board-
admin.component'; 
 
const routes: Routes = [ 
  { path: 'home', component: HomeComponent }, 
  { path: 'login', component: LoginComponent }, 
  { path: 'register', component: RegisterComponent }, 
  { path: 'profile', component: ProfileComponent }, 
  { path: 'Cor', component: BoardCorComponent }, 
  { path: 'mod', component: BoardModeratorComponent }, 
  { path: 'admin', component: BoardAdminComponent }, 
  { path: '', redirectTo: 'home', pathMatch: 'full' } 
]; 
 
@NgModule({ 
  imports: [RouterModule.forRoot(routes)], 
  exports: [RouterModule] 
}) 
export class AppRoutingModule { } 
 
33. Корневий компонент програми в app.component.ts 
import { Component, OnInit } from '@angular/core'; 
import { TokenStorageService } from './_services/token-
storage.service'; 
 
@Component({ 
  selector: 'app-root', 
  templateUrl: './app.component.html', 
  styleUrls: ['./app.component.css'] 
}) 
export class AppComponent implements OnInit { 
  private Rol: string[]; 
  isLoggedIn = false; 
  showAdminBoard = false; 
  showModeratorBoard = false; 
  Username: string; 
 
104 
 
  constructor(private tokenStorageService: TokenStorageService) { 
} 
 
  ngOnInit(): void { 
    this.isLoggedIn = !!this.tokenStorageService.getToken(); 
 
    if (this.isLoggedIn) { 
      const Cor = this.tokenStorageService.getCor(); 
      this.Rol= Cor.Rol; 
 
      this.showAdminBoard = this.Rol.includes('ROLE_ADMIN'); 
      this.showModeratorBoard = 
this.Rol.includes('ROLE_MODERATOR'); 
 
      this.Username = Cor.Username; 
    } 
  } 
 
  logout(): void { 
    this.tokenStorageService.signOut(); 
    window.location.reload(); 
  } 
} 
. 
34. Корневий компонент програми в app.component.html 
<div id="app"> 
  <nav class="navbar navbar-expand navbar-dark bg-dark"> 
    <a href="#" class="navbar-brand">Koder</a> 
    <ul class="navbar-nav mr-auto" routerLinkActive="active"> 
      <li class="nav-item"> 
        <a href="/home" class="nav-link" routerLink="home">Home 
</a> 
      </li> 
      <li class="nav-item" *ngIf="showAdminBoard"> 
        <a href="/admin" class="nav-link" routerLink="admin">Admin 
Board</a> 
      </li> 
105 
 
      <li class="nav-item" *ngIf="showModeratorBoard"> 
        <a href="/mod" class="nav-link" routerLink="mod">Moderator 
Board</a> 
      </li> 
      <li class="nav-item"> 
        <a href="/Cor" class="nav-link" *ngIf="isLoggedIn" 
routerLink="Cor">Cor</a> 
      </li> 
    </ul> 
 
    <ul class="navbar-nav ml-auto" *ngIf="!isLoggedIn"> 
      <li class="nav-item"> 
        <a href="/register" class="nav-link" 
routerLink="register">Sign Up</a> 
      </li> 
      <li class="nav-item"> 
        <a href="/login" class="nav-link" 
routerLink="login">Login</a> 
      </li> 
    </ul> 
 
    <ul class="navbar-nav ml-auto" *ngIf="isLoggedIn"> 
      <li class="nav-item"> 
        <a href="/profile" class="nav-link" 
routerLink="profile">{{ Username }}</a> 
      </li> 
      <li class="nav-item"> 
        <a href class="nav-link" (click)="logout()">LogOut</a> 
      </li> 
    </ul> 
  </nav> 
 
  <div class="container"> 
    <router-outlet></router-outlet> 
  </div> 
</div>
ChSTU repository

ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
