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

КАШУБА, Орина
Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/9417
Title:	Дослідження методів застосування безсерверних обчислень для токенізації банківських даних
Authors:	БАБЕНКО, Віра КАШУБА, Орина
Issue Date:	2022
Abstract:	Темою даної кваліфікаційної роботи магістра є дослідження методів застосування безсерверних обчислень для токенізації банківських даних. Ця тема є важливою через те, що банківська система повинна працювати безвідказно, швидко та стабільно. Ці вимоги особливо важливі при обробці транзакцій в реальному часі. Для досягнення цього сучасні банківські системи використовують великі сервери, які часто знаходяться в різних куточках країни для забезпечення максимальної безвідказності системи. Але навіть цього може бути недостатньо при обробці великої кількості транзакцій та при непередбачуваних умовах, наприклад, за довготривалої відсутності електроенергії. Метою кваліфікаційної роботи магістра є дослідження методів застосування безсерверних обчислень для токенізації банківських даних та реалізація одного з таких методів за допомогою розробки способу поєднання усіх компонентів системи, що реалізує розроблений метод. Об’єкт дослідження - методи оптимізації роботи банківської системи за допомогою безсерверних обчислень. Предмет дослідження - програмне забезпечення та алгоритм обробки транзакцій в реальному часі за допомогою безсерверних обчислень. Наукова новизна одержаних результатів полягає у реалізації рішення, що забезпечуватиме виконання базових функцій, подібно до наявності фізичних серверів, але не буде вимагати їх. Новизна одержаних результатів підтверджується результатами тестування створеної системи та уже існуючих систем. Практична цінність результатів полягає в тому, що така система стає повністю безвідмовною, при цьому зберігається високий рівень швидкодії при однаковому навантаженні. У першому розділі проведено аналіз предметної області, а саме розглянуто хмарні обчислення їх особливості, види моделей, а також проаналізовано безсерверні обчислення їх переваги та недоліки. Наведено опис провайдерів для serverless обчислень, таких як: AWS, Azure, Google cloud. У даному розділі здійснено вибір напрямку дослідження та більш детально пояснено, що таке банк, яка його робота, що таке банківська транзакції та для чого потрібна токенізація в цій сфері діяльності. Поставлено задачі до магістерської роботи. У другому розділі проведено огляд існуючих технологій, таких як: AWS Lambda functions, Google Serverless, Azure Serverless їх можливості та переваги. Також було обрано технології, які будуть використовуватися для реалізації системи на базі безсерверних технологій, а саме: мова програмування Node.js, що має досить простий синтаксис та дає можливості створювати масимально прості скрипти; база даних, яка найкраще підходить для цього MySQL; технології AWS Amazon Lambda, що є найголовнішим. У третьому розділі описується структура системи, функції, які вона виконує, реалізується захист інформації. Крім того, визначаються вимоги для роботи із системою, мінімальні потреби для забезпечення коректної роботи системи, наводиться оцінка ефективності. Висновки включають в себе основні результати роботи. У додатках наведено специфікацію, текст програми та інструкцію користувача. Загальний обсяг роботи становить 92 сторінки. У кваліфікаційній роботі магістра 18 рисунків, 2 таблиці, 3 додатки. Для виконання роботи використано 20 літературних джерел.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/9417
Appears in Collections:	123 Комп’ютерна інженерія (Системне програмування)
Files in This Item:
File	Description	Size	Format
1_Титулка_Кашуба-merged.pdf Restricted Access		3.26 MB	Adobe PDF	View/Open Request a copy
Show full item record
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ
КАФЕДРА ІНФОРМАЦІЙНОЇ БЕЗПЕКИ ТА КОМП’ЮТЕРНОЇ
ІНЖЕНЕРІЇ
Пояснювальна записка
до кваліфікаційної роботи магістра
на тему: «Дослідження методів застосування
безсерверних обчислень для токенізації банківських
даних»
ЧДТУ.222291.003 ПЗ
Виконала: студентка 2 курсу, групи МСП-2106
спеціальності 123 – Комп’ютерна інженерія
за освітньою програмою – Системне
програмування
Орина КАШУБА
Керівник
д.т.н., професор
Віра БАБЕНКО
Н. контроль
Світлана ГРЕСЬКО
Рецензент
Начальник відділу персоналу, к.т.н., доцент
Віталій ЗАЖОМА
«ЗАХИСТ ДОЗВОЛЯЮ»
Завідувач кафедри ІБ та КІ
д.т.н., професор _______ Володимир РУДНИЦЬКИЙ
Черкаси 2022 року
Черкаський державний технологічний університет
Факультет інформаційних технологій і систем
Кафедра інформаційної безпеки та комп‘ютерної інженерії
Освітньо-кваліфікаційний рівень магістр
Спеціальність 123 – Комп’ютерна інженерія
Освітня програма Системне програмування
«ЗАТВЕРДЖУЮ»
Завідувач кафедри _____ Володимир РУДНИЦЬКИЙ
«20» жовтня 2022 року
ЗАВДАННЯ
на кваліфікаційну роботу магістра студенту
Кашубі Орині Ігорівні
(прізвище, ім‘я, по батькові)
1. Тема роботи Дослідження методів застосування безсерверних обчислень
для токенізації банківських даних
Керівник роботи Бабенко Віра Григорівна, д.т.н., професор
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені наказом університету від «14» жовтня 2022 р. № 275/04
2. Строк подання студентом роботи
3. Вихідні дані до роботи:
методи оптимізації, serverless, токенізація,
банківська система, безсерверні обчислення, Lambda functions, Amazon Web Services.
4. Зміст розрахунково-пояснювальної записки (перелік питань, що їх належить розробити):
Вступ
Розділ 1 Аналіз предметної області та постановка задачі дослідження
Розділ 2 Вибір технології та інструментальних засобів розробки системи
Розділ 3 Реалізація методів застосування безсерверних обчислень для токенізації
банківських даних
Висновки
Перелік скорочень та умовних позначень
Список використаних джерел
Додатки
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових креслень, плакатів):
Додаток А Специфікація
Додаток Б Текст програм
Додаток В Інструкція користувача
6. Консультанти розділів роботи
Підпис, дата
Розділ Прізвище, ініціали та
посада завдання видав завдання прийняв
консультанта
7. Дата видачі завдання 20 жовтня 2022 року
КАЛЕНДАРНИЙ ПЛАН
№ з/п Назва етапів кваліфікаційної роботи магістра Строк виконання
етапів роботи Примітка
1 Збір матеріалу 21.10 – 25.10 виконано
2 Обробка матеріалу 26.10 – 29.10 виконано
3 Обґрунтування актуальності виконання
досліджень 29.10 – 05.11 виконано
4 Оцінка стану проблеми, виокремлення
дослідницьких задач, постановка задачі 06.11 – 10.11 виконано
дослідження
5 Викладення сутності і результатів дослідження 11.11– 16.11 виконано
6 Практичне застосування результатів
дослідження 16.11 – 20.11 виконано
7 Оформлення результатів в пояснювальну записку 21.11 – 27.11 виконано
8 Подання роботи на відгук та рецензування 28.11.22 виконано
Студент-магістрант ____________________________ Орина КАШУБА
(підпис)
Керівник роботи ____________________________ Віра БАБЕНКО
(підпис)
АНОТАЦІЯ
Темою даної кваліфікаційної роботи магістра є дослідження методів
застосування безсерверних обчислень для токенізації банківських даних. Ця
тема є важливою через те, що банківська система повинна працювати
безвідказно, швидко та стабільно. Ці вимоги особливо важливі при обробці
транзакцій в реальному часі. Для досягнення цього сучасні банківські
системи використовують великі сервери, які часто знаходяться в різних
куточках країни для забезпечення максимальної безвідказності системи. Але
навіть цього може бути недостатньо при обробці великої кількості транзакцій
та при непередбачуваних умовах, наприклад, за довготривалої відсутності
електроенергії.
Метою кваліфікаційної роботи магістра є дослідження методів
застосування безсерверних обчислень для токенізації банківських даних та
реалізація одного з таких методів за допомогою розробки способу поєднання
усіх компонентів системи, що реалізує розроблений метод.
Об’єкт дослідження - методи оптимізації роботи банківської системи
за допомогою безсерверних обчислень.
Предмет дослідження - програмне забезпечення та алгоритм обробки
транзакцій в реальному часі за допомогою безсерверних обчислень.
Наукова новизна одержаних результатів полягає у реалізації рішення,
що забезпечуватиме виконання базових функцій, подібно до наявності
фізичних серверів, але не буде вимагати їх. Новизна одержаних результатів
підтверджується результатами тестування створеної системи та уже
існуючих систем.
Практична цінність результатів полягає в тому, що така система стає
повністю безвідмовною, при цьому зберігається високий рівень швидкодії
при однаковому навантаженні.
У першому розділі проведено аналіз предметної області, а саме
розглянуто хмарні обчислення їх особливості, види моделей, а також
проаналізовано безсерверні обчислення їх переваги та недоліки. Наведено
опис провайдерів для serverless обчислень, таких як: AWS, Azure, Google
cloud. У даному розділі здійснено вибір напрямку дослідження та більш
детально пояснено, що таке банк, яка його робота, що таке банківська
транзакції та для чого потрібна токенізація в цій сфері діяльності. Поставлено
задачі до магістерської роботи.
У другому розділі проведено огляд існуючих технологій, таких як:
AWS Lambda functions, Google Serverless, Azure Serverless їх можливості та
переваги. Також було обрано технології, які будуть використовуватися для
реалізації системи на базі безсерверних технологій, а саме: мова
програмування Node.js, що має досить простий синтаксис та дає можливості
створювати масимально прості скрипти; база даних, яка найкраще підходить
для цього MySQL; технології AWS Amazon Lambda, що є найголовнішим.
У третьому розділі описується структура системи, функції, які вона
виконує, реалізується захист інформації. Крім того, визначаються вимоги для
роботи із системою, мінімальні потреби для забезпечення коректної роботи
системи, наводиться оцінка ефективності.
Висновки включають в себе основні результати роботи. У додатках
наведено специфікацію, текст програми та інструкцію користувача.
Загальний обсяг роботи становить 92 сторінки. У кваліфікаційній роботі
магістра 18 рисунків, 2 таблиці, 3 додатки. Для виконання роботи
використано 20 літературних джерел.
ANOTATION
The topic of this Master's thesis is the research of methods of using
serverless computing for tokenization of bank data. This topic is important because
the banking system must work reliably, quickly and stably.
These requirements are especially important when processing transactions in
real time. To achieve this, modern banking systems use large servers, which are
often located in different parts of the country to ensure maximum system
reliability. But this may not be enough when processing a large number of
transactions and under unpredictable conditions.
The purpose of this master's thesis is to develop a method that can
significantly simplify the work of the banking system, which will perform the same
functions, but at the same time will not require the presence of physical servers.
The object of research is methods of optimizing the operation of the
banking system using serverless computing.
The subject of research is software and an algorithm for processing
transactions in real time using serverless computing.
The scientific novelty of the obtained results lies in the solution, which will
perform the same functions as in the presence of physical servers, but will not
require them. The novelty of the obtained results is confirmed by the results of
testing the created system and already existing systems
The practical value of the results is that such a system becomes completely
fail-safe, while maintaining a high level of speed at the same load.
In the first section, the types of calculations are considered, and what
serverless is. Serverless computing providers were also investigated: AWS, Google
cloud and Azure. The direction of research was chosen and it was described what
the banking system is, how it works, what tokenization is and its use in the banking
system. Tasks for the master's thesis have been set.
The second section provides an overview of existing development
technologies such as: AWS Lambda functions, Google Serverless and Azure
Serverless. And they described the selection of technologies that were chosen for
the qualification work.
The third chapter describes the structure of the system, describes the
functions it performs, and develops information protection. Requirements for
working with the system, minimum requirements for work are determined. At the
end, an evaluation of efficiency is provided.
The conclusions include the main results of the work. Appendices include
specification, program text, and user manual. The total volume of work is 94
pages. There are 18 figures, 2 tables, and 3 appendices in the Master's thesis. 20
literary sources were used to perform the work.
3
ВСТУП………………………………………………………………………… 4
РОЗДІЛ 1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ ТА ПОСТАНОВКА
ЗАДАЧІ ДОСЛІДЖЕННЯ…………………………………………………..... 7
1.1 Аналіз предметної області………………………………………… 7
1.2 Вибір напрямку дослідження……………………………………... 19
1.3 Постановка задачі………………………………………………….. 22
1.4 Висновки до розділу 1…………………………………………….. 26
РОЗДІЛ 2 ВИБІР ТЕХНОЛОГІЇ ТА ІНСТРУМЕНТАЛЬНИХ ЗАСОБІВ
РОЗРОБКИ СИСТЕМИ………………………………………………………. 27
2.1 Огляд існуючих технологій розробки……………………………. 27
2.2 Вибір технологій…………………………………………………... 35
2.3 Висновки до розділу 2…………………………………………….. 45
РОЗДІЛ 3 РЕАЛІЗАЦІЯ МЕТОДІВ ЗАСТОСУВАННЯ БЕЗСЕРВЕРНИХ
ОБЧИСЛЕНЬ ДЛЯ ТОКЕНІЗАЦІЇ БАНКІВСЬКИХ ДАНИХ…………….. 46
3.1 Структура системи……………………………………………….... 46
3.2 Опис функцій системи…………………………………………….. 55
3.3 Забезпечення захисту інформації при роботі з створеною
системою ………………………………………………………………. 60
3.4 Технічні вимоги для роботи з системою………………………..... 63
3.5 Оцінка ефективності методів застосування безсерверних
обчислень………………………………………………………………. 65
3.6 Висновки до розділу 3…………………………………………….. 67
ВИСНОВКИ…………………………………………………………………... 68
ПЕРЕЛІК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ………………….... 70
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ…………………………………….. 71
ДОДАТКИ:
4
А – 482.ЧДТУ.22291-01 Дослідження методів застосування
безсерверних обчислень для токенізації банківських даних
5
ВСТУП
Актуальність теми дослідження. Сучасні банківські системи повинні
завжди працювати злагоджено та без упину. Тому для цього використовують
великі сервери, що розміщуються у різних куточках країни, для забезпечення
цілодобової роботи. Але в сучасному світі, можуть виникати проблеми, що
стануть загрозою. Наприклад відключення електроенергії, пожежі або інші
явища.
Для того, щоб уникнути таких ситуацій та значно спростити роботу
банківської системи, буде розроблено рішення, що виконуватиме ті самі
функції, але не вимагатиме фізичних серверів. Що дасть змогу працювати
системі цілодобово та без ризику пошкоджень.
Метою кваліфікаційної роботи магістра є дослідження методів
застосування безсерверних обчислень для токенізації банківських даних та
реалізація одного з таких методів за допомогою розробки способу поєднання
усіх компонентів системи, що реалізує розроблений метод. Запропонований
для реалізації метод повинен значно спростити роботу банківської системи
шляхом забезпечення виконання тих самих основних функцій, наприклад,
обробки транзакцій в реальному часі, що є дуже важливим та критичним.
Тому використання безсерверних обчислень є корисним, так як користувачам
такої платформи не треба мати справу з налаштуванням серверів для запуску
коду: усі серверні налаштування, планування обчислювальних ресурсів
цілком приховані від користувачів і керуються платформою.
Для досягнення сформульованої мети необхідно вирішити такі задачі:
1. Провести аналіз існуючих технологій.
2. Обґрунтувати доцільність розробки нового методу безсерверних
обчислень для токенізації банківських даних.
6
3. Сформувати та обрати технології, що будуть використовуватися при
розробці даного методу.
4. Розробити спосіб поєднання усіх компонентів системи, що реалізує
розроблений метод.
5. Оптимізувати систему та здійснити її налаштування.
6. Оцінити складність реалізації запропонованого методу.
На даний момент існує не багато джерел інформації, в яких автори
описують різноманітні способи розробки та вдосконалення. Наприклад Jason
Katzer в своїй книзі «Learning Serverless: Design, Develop, and Deploy with
Confidence. 1st Ed.» розповідає незалежно від того, чи розглядає ваша
компанія безсерверні обчислення чи вже прийняла рішення прийняти цю
модель, показує розробникам, що потрібно для створення та доставки
придатних для обслуговування та масштабованих служб за допомогою цієї
моделі. Також дізнаєтеся, як створити сучасну виробничу систему в хмарі,
розглядаючи її крізь призму безсерверних обчислень. У даній роботі описано
як безсерверний режим може звільнити вас від виснажливого завдання
налаштування та обслуговування систем у робочому стані.
Об'єкт дослідження – методи оптимізації роботи банківської системи
за допомогою безсерверних обчислень.
Предмет дослідження – програмне забезпечення та алгоритм обробки
транзакцій в реальному часі за допомогою безсерверних обчислень.
Наукова новизна одержаних результатів полягає у реалізації рішення,
що забезпечуватиме виконання базових функцій, подібно до наявності
фізичних серверів, але не буде вимагати їх. Новизна одержаних результатів
підтверджується результатами тестування створеної системи та уже
існуючих систем.
Одержані в кваліфікаційній роботі результати мають практичне
значення, яке саме полягає в тому, що така система стає повністю
безвідмовною, при цьому зберігається високий рівень швидкодії при
7
однаковому навантаженні.
Кваліфікаційна робота складається з 3-х розділів, в яких подається
інформація про:
 обрану предметну область дослідження та про постановку проблеми;
 вибір існуючих технологій та вибір обчислень , за допомогою яких
можна реалізувати подібну систему та обґрунтування вибору тієї чи
іншої технології;
 дослідження методів застосування безсерверних обчислень для
токенізації банківських даних та реалізація запропонованого методу.
Використана література, під час написання кваліфікаційної роботи,
досить добре розкриває тему та відображає потреби для аналізу.
7
РОЗДІЛ 1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ ТА ПОСТАНОВКА
ЗАДАЧІ ДОСЛІДЖЕННЯ
1.1 Аналіз предметної області
Види обчислень та їх характеристики бувають різні, але ми розглянемо
найпопулярніші.
Хмарні обчислення. Хмарні обчислення (від англ. Cloud Computing)
— це модель забезпечення повсюдного та зручного доступу на вимогу, через
мережу до спільного пулу обчислювальних ресурсів, що підлягають
налаштуванню (наприклад, до комунікаційних мереж, серверів, засобів
збереження даних, прикладних програм та сервісів), і які можуть бути
оперативно надані та звільненні з мінімальними управлінськими витратами
та зверненнями до провайдера. Інакше кажучи хмарні обчислення являють
собою концепцію надання ІТ ресурсів у вигляді послуг:
● Інфраструктура, як послуга
● Платформа, як послуга
● Програмне забезпечення, як послуга
● Сховище, як послуга
● Робоче місце, як послуга
● Резервне копіювання, як послуга
● Аварійне відновлення, як послуга
Основна теза — оренда замість купівлі, тобто послуга, замість
придбання товару. Провайдери хмарних рішень дозволяють орендувати через
інтернет обчислювальні потужності, дисковий простір, ліцензії та інше.
Переваги такого підходу — ефективність та швидкість (користувач платить
лише за ті ресурси, які йому потрібні і отримує їх за запитом у термін пари
годин) а також можливість гнучкого масштабування і зростання. "Хмара"
відкриває новий підхід до обчислень, при якому між бізнесом та ІТ відділом
8
компанії запроваджується сервіс-орієнтований підхід завдяки якому ІТ
набуває більшої здатності відповідати вимогам сучасних швидкоплинних
бізнес-реалій. Хмарні обчислення – це сучасні багатофункціональні рішення,
але вони залишаються лише інструментом у руках ІТ спеціалістів [1]. Хмарні
технології дозволяють швидше і точніше викроїти ІТ інфраструктуру під
вимоги бізнесу.
Зручність і універсальність доступу забезпечується широкою
доступністю послуг і підтримкою різного класу термінальних пристроїв
(персональних комп'ютерів, мобільних телефонів, інтернет-планшетів).
Модель обслуговування визначає рівень автоматизації ІТ процесів
інфраструктури. Виділяють наступні моделі надання послуг за допомогою
хмари:
Програмне забезпечення як послуга (SaaS). Прикладами
програмного забезпечення як послуги, що працює на основі обчислювальної
хмари, є сервіси Gmail та Google docs. Програмне забезпечення як послуга
(SaaS) — це модель ліцензування та доставки програмного забезпечення, за
якої сторонній постачальник надає клієнту доступ до програмного
забезпечення через Інтернет. На відміну від локальної моделі
розповсюдження додатків, рішення SaaS розміщуються в хмарі та керуються
через нього, що дозволяє клієнтам усунути або зменшити потребу в
розміщенні на місці та обслуговуванні інфраструктури додатків, як-от
серверів і баз даних.
Також важливо зазначити, що модель ціноутворення в SaaS найчастіше
базується на підписці, що означає, що замість одного великого авансового
платежу за отримання фізичного продукту з клієнтів стягується менша
місячна плата за фактичне використання програмного забезпечення в SaaS.
модель.
Більше того, будь-які проблеми з техобслуговуванням і усуненням
несправностей, пов’язані з базовою інфраструктурою, залишаються
виключною відповідальністю постачальника програмного забезпечення як
9
послуги, залишаючи клієнту більше часу та зосередженість на суто бізнес-
питаннях. Інша важлива річ, яку слід пам’ятати про продукти моделі SaaS,
полягає в тому, що вони постійно розвиваються та періодично оновлюються.
Платформа як послуга (PaaS). Наприклад, Google Apps надає
застосунки для бізнесу в режимі онлайн, доступ до яких відбувається за
допомогою Інтернет-браузера тоді як ПЗ і дані зберігаються на серверах
Google. PaaS об’єднує проміжне програмне забезпечення, операційні
системи, розробку та розгортання в абстрактному середовищі, окремому від
інфраструктури організації. Це дає компаніям можливість легше переносити
наявні власні програми в хмару, що робить процес збільшення ресурсів
швидшим і простішим у міру зростання бази користувачів. Це також дає
змогу організації розробляти та розгортати налаштовані додатки в дуже
спрощений спосіб.
PaaS дозволяє організаціям швидко та впевнено розробляти, розгортати
та ітерувати бізнес-додатки та інтеграції без необхідності купувати та
підтримувати допоміжну інфраструктуру. Для невеликих підприємств це
надає їм доступ до новітніх технологій без необхідності робити великі
початкові інвестиції в ресурси. Більші підприємства можуть швидко
додавати нових користувачів і ресурси в міру розвитку потреб бізнесу,
минаючи тривалі процеси закупівель. Організаціям будь-якого розміру PaaS
дозволяє зосередитися на своїй основній діяльності, не турбуючись про
підтримку та оновлення базової технологічної інфраструктури.
Використовуючи PaaS, бізнес може скористатися такими перевагами:
 швидка масштабованість
 менші витрати
 більша гнучкість
 підвищення можливостей робочої сили
 доступ до бізнес-аналітики
 коротші терміни розробки
 підтримка командної співпраці
10
 оптимізоване управління життєвим циклом програми.
Рішення PaaS зазвичай масштабуються автоматично, щоб задовольнити
попит і прискорити процеси за допомогою автоматизації та стандартизації
завдань розробки та розгортання. Кілька людей можуть одночасно
використовувати ту саму програму розробки, що дозволяє розробникам
працювати над проектом, а зацікавленим сторонам – взаємодіяти з командою
розробників. Системи PaaS також часто мають вбудовану безпеку та захист
даних. Крім того, коли справа доходить до розгортання програм із кількох
систем як у мережі, так і в Інтернеті речей, PaaS пропонує компоненти
інтеграції та агрегації, які спрощують цю діяльність.
Інфраструктура як послуга (IaaS).
Інфраструктура як послуга (IaaS) — це система хмарних обчислень, яка
надає віртуальні обчислювальні ресурси через Інтернет. IaaS є однією з трьох
основних категорій послуг хмарних обчислень разом із програмним
забезпеченням як послугою (SaaS) і платформою як послугою (PaaS).
IaaS швидко збільшується або зменшується відповідно до попиту та
допомагає уникнути необхідності придбання фізичних серверів та іншої
інфраструктури центру обробки даних; кожен ресурс пропонується як
окремий компонент служби. Постачальник послуг хмарних обчислень керує
інфраструктурою, тоді як користувач встановлює, налаштовує та керує
програмним забезпеченням, включаючи програми, проміжне програмне
забезпечення та операційні системи.
Найбільшими гравцями на ринку інфраструктури, як послуги є Amazon,
Microsoft, VMWare, Rackspace та Red Hat [2]. Хоча деякі з них пропонують
більше, ніж просто інфраструктуру, їх об’єднує мета продавати базові
обчислювальні ресурси. В таблиці 1.1 зображено моделі обслуговування та їх
характеристики.
11
Таблиця 1.1 — Моделі обслуговування
Моделі розгортання. Обчислювальна хмара може бути розгорнута як:
приватна, публічна, громадська або гібридна.
Приватна хмара (англ. private cloud) — це хмарна інфраструктура, яка
призначена для використання виключно однією організацією, що включає
декілька користувачів (наприклад, підрозділів) [3]. Приватна хмара може
12
перебувати у власності, керуванні та експлуатації як самої організації, так і
третьої сторони (чи деякої їх комбінації), наприклад колокейшн у ДЦ. Така
хмара може фізично знаходитись як в, так і поза юрисдикцією власника,
приклад приватної хмари на рисунку 1.1.
Рисунок 1.1 — Приклад приватної хмари
Публічна хмара (англ. public cloud) — це хмарна інфраструктура, яка
призначена для вільного використання широким загалом. Публічна хмара
може перебувати у власності, керуванні та експлуатації комерційних,
академічних (освітніх та наукових) або державних організацій (чи будь-якої
їх комбінації). Публічна хмара перебуває в юрисдикції постачальника
хмарних послуг, зображено на рисунку 1.2.
13
Рисунок 1.2 — Приклад публічної хмари
Гібридна хмара (англ. hybrid cloud) — це хмарна інфраструктура, що
складається з двох або більше різних хмарних інфраструктур (приватних,
громадських або публічних), які залишаються унікальними сутностями, але
з’єднанні між собою стандартизованими або приватними технологіями, що
уможливлюють переносимість даних та прикладних програм (наприклад,
використання ресурсів публічної хмари для балансування навантаження між
хмарами), зображено на рисунку 1.2.
14
Рисунок 1.3 — Приклад гібридної хмари
Рішення для гібридних хмар дозволяють будувати, управляти
змішаною інфраструктурою між приватною та кількома публічними
провайдерами, а також мігрувати сервіси між ними.
Безсерверні обчислення (англ. serverless computing) — модель
хмарних обчислень для яких платформа динамічно керує виділенням
машинних ресурсів. Іноді безсерверні обчислення також іменують «Функція
як послуга» (англ. Function as a Service, FaaS), тому що одиницею коду є
функція, яка виконується платформою [4]. По суті для виконання одного
запиту створюється окремий контейнер, який знищується після виконання.
Звісно безсерверні обчислення потребують апаратне забезпечення і цей
термін не варто розуміти буквально. Ця назва використовується тому, що
користувачам такої платформи не треба мати справу з налаштуванням
серверів для запуску коду: усі серверні налаштування, планування
15
обчислювальних ресурсів цілком приховані від користувачів і керуються
платформою [5]. Безсерверний код може бути частиною застосунка
побудованого на традиційній архітектурі, наприклад, на мікросервісах.
Розглянемо більш детально Serverless. Ви не керуєте сервером, на
якому запускається програма. Ви взагалі про нього нічого не знаєте, всі
нюанси операційної системи, оновлень, мережевих налаштувань та іншого
заховані від вас. Це зроблено для того, щоб ви могли зосередитись на
розробці корисної функціональності, а не на адмініструванні серверів.
Провайдер Serverless послуги автоматично надає вам більше або менше
обчислювальних ресурсів, залежно від того, наскільки велике навантаження
припадає на вашу програму. Якщо ваш додаток простоює – ви нічого не
платите, т.к. воно на цей момент не використовує обчислювальних
ресурсів[6]. Оплата ж відбувається лише за час, який ваш додаток реально
працює.
Обмежений життєвий цикл. Ваша програма запускається в контейнері,
і через короткий час, від десятка хвилин до декількох годин, сервіс
автоматично його зупиняє. Звичайно ж, якщо додаток знову повинен бути
викликаний, новий контейнер буде запущений.
У деяких припущеннях, Serverless модель може бути використана будь-
де. Однак є ряд випадків, з яких простіше та безпечніше розпочати її
застосування. Це випадки відкладених або фонових завдань. Наприклад:
● створення додаткових копій зображення після завантаження на
сайт;
● створення бекапу за розкладом;
● асинхронне надсилання повідомлення користувачу (push, email,
sms);
● різні експорти та імпорти.
Всі ці приклади або виконуються за розкладом, або не мають на увазі
миттєвої відповіді користувачеві. Це пов'язано з тим, що програми (функції)
в Serverless моделі не працюють постійно, а запускаються при необхідності і
16
у разі невикористання автоматично відключаються [7]. Це призводить до
того, що на запуск функції потрібно час, іноді до декількох секунд.
Однак, це не означає, що Serverless не можна використовувати в
частинах програми, з якими взаємодіє користувач, і для яких важливим є час
відповіді [8]. Навпаки, Serverless функції широко застосовуються для,
наприклад:
● чат ботів;
● бекендів для IoT додатків;
● маніпуляції запитів до вашого основного бекенду (наприклад, для
ідентифікації користувача за User-Agent, IP та іншими даними, або
для отримання інформації про його геопозицію з IP);
● навіть як цілком самостійні API endpoint.
Переваги Serverless.
● Максимальна еластичність. Швидке масштабування від нуля до
тисяч функцій, що паралельно працюють.
● Повна абстракція від операційної системи або будь-якого софту, що
використовується для виконання програми.
● При правильному проектуванні функцій легше побудувати слабо-
пов'язану архітектуру, коли помилка в одній функції не позначиться
на працездатності всього докладання.
● Нижче поріг входу. Зрозуміти "наносервіс" зі 100-500 рядків для
нового розробника в команді набагато простіше, ніж зрозуміти
проект із мільйоном рядків та складних зв'язків.
Недоліки Serverless.
● Необхідно завжди дбати про збереження зворотної сумісності, адже
від вашого інтерфейсу чи бізнес-логіки потенційно може залежати
інший сервіс/функція.
● Схема взаємодії у класичному монолітному додатку та у
розподіленій системі дуже сильно відрізняються. Необхідно думати
17
про асинхронну взаємодію, можливі затримки, моніторинг окремих
частин програми.
● Хоча ваші функції та ізольовані, неправильна архітектура все одно
може призвести до cascade failure — коли помилка в одній із них
призведе до непрацездатності великої кількості інших.
● Ціна чудової масштабованості - це те, що поки ваша функція не
викликається, вона і не запущена. І коли її потрібно запустити — це
може зайняти до декількох секунд, що може бути критично для
вашого бізнесу.
● Коли запит від клієнта проходить через десяток функцій, стає дуже
складно бити можливу причину помилки, якщо така трапляється.
Таким чином, Serverless можна використовувати там, де доводиться не
надто часто, але інтенсивно обробляти велику кількість запитів. У цьому
випадку запускати кілька функцій на 15 хвилин вигідніше, ніж весь час
тримати віртуальну машину чи сервер [9].
AWS Lambda – це безсерверний, керований подіями обчислювальний
сервіс, який дозволяє виконувати код практично для необмеженого типу
програми або сервісу без надання серверів та їх обслуговування. Ви можете
включити Lambda з понад 200 сервісів і програм, що надаються за моделлю
ПЗ як послуга (SaaS), оплачуючи тільки ті ресурси, які ви використовуєте.
Можливості AWS Lambda:
● Розширить можливості сервісів AWS за допомогою власного
програмного коду.
● Створення власних серверних сервісів.
● Використання власного коду.
● Повністю автоматизоване адміністрування.
● Вбудована відмовостійкість.
● Пакування та розгортання функцій як образів контейнерів.
● Автоматичне масштабування.
● Підключення до реляційних баз даних.
18
● Точний контроль за продуктивністю.
● Підключення до загальних файлових систем.
● Запуск коду у відповідь на запити Amazon CloudFront.
● Оркестрація безлічі функцій.
● Інтегрована модель безпеки.
● Засоби контролю довіри та цілісності.
● Оплата за фактом використання.
● Гнучка модель розподілу ресурсів.
● Інтеграція Lambda зі звичними робочими інструментами.
AWS Lambda можна використовувати для розширення можливостей
інших сервісів AWS за допомогою спеціальної логіки або для створення
власних серверних сервісів із застосуванням можливостей масштабування,
продуктивності та безпеки AWS. AWS Lambda автоматично запускає
програмний код у відповідь на різні події, такі як HTTP-запити через Amazon
API Gateway, зміна об'єктів у кошиках Amazon Simple Storage Service
(Amazon S3), оновлення таблиць у Amazon DynamoDB або зміна станів у
AWS Step Functions.
Інші провайдери Serverless обчислень. Microsoft Azure є другим на
ринку хмарних рішень. Вони надають широкии ̆ сет інтрументів для побудови
serviceless додатків. Azure може бути наи ̆кращим вибором, якщо організація
чи компанія вже використовує значну кількість програмного забезпечення
від Microsoft.
Google Cloud. Він також має велику кількість пропозиціи ̆ для побудови
serverless застосунків. Ми можемо визначити три три наи ̆більш популярні
випадки використання. Google serverless applications:
● Web app з компонентами: Browser -> App Engine -> Datastore.
● Мікросервіс з компонентами: Мікросервіс -> Хмарна функція ->
Datastore.
● ETL з компонентами: File -> Cloud Dataflow -> BigQuery
19
Для кращої розробки краще робіть швидше, пишучи та запускаючи
невеликі фрагменти коду, які реагують на події. Використовуйте Cloud
Functions для підключення до Google Cloud або сторонніх хмарних служб за
допомогою тригерів, щоб спростити складні проблеми. Виконуйте функції в
кількох середовищах (локальне середовище розробки, локальне, Cloud Run та
інші безсерверні середовища на основі Knative) і запобігайте блокуванню.
1.2 Вибір напрямку дослідження
Банк – це юридична особа, яка має державну ліцензію на залучення
коштів на депозити і використовує їх з метою отримання прибутку. Банк
надає найбільший перелік фінансових послуг, основні з них – розміщення
коштів на депозити, кредити, грошові взаєморозрахунки та перекази,
банківські сейфи, рахунки в цінних паперах, платіжні картки, тощо. Робота
банка виглядає так банки акумулюють кошти фізичних та юридичних осіб на
депозити, і залучають їх на ринку грошей, після чого використовують їх для
своєї комерційної діяльності, зображено на рисунку 1.4. Основні джерела
доходів банків – проценти від кредитування бізнесу та населення, і комісії за
грошові перекази всіх видів.
Рисунок 1.4 — Схема роботи банків
20
Банківська транзакція, або трансакція (англ. bank transaction, від лат.
transactio — угоду, договір), — в загальному будь-яка операція з
використанням банківського рахунку. Розрізняють послідовні (звичайні),
паралельні і розподілені транзакції. Розподілені транзакції вбачають
використання більш ніж однієї транзакційної системи і потребують просто
більшої складної логіки (наприклад, двофазний комміт — двофазний
протокол фіксації транзакцій). Також, в деяких системах реалізовані
автономні транзакції, або під-транзакції, які є автономною частиною
батьківської транзакції.
Інтернет розрахунки стали дуже популярними та розвинулися дуже
швидко. Але так само зростає і кіберзлочинність, тому онлайн-сервіси все
частіше впроваджують протоколи захисту та ідентифікації користувачів.
Найбільш популярна технологія захисту є токенізація.
Токенізація – це різновид шифрування. В онлайн-транзакціях вона
використовується для захисту даних банківських карток. Наприклад, коли ви
хочете розрахуватися у вибраному інтернет-магазині, чи оплачуєте рахунки,
то у відведеному віконці вводите номер своєї картки, її термін дії та CVV. У
цей момент ви повідомляєте інформацію про картку сторонньому ресурсу,
який може зберігати її. А ще гірше – зберігати інформацію недостатньо добре
захищеною, що погано для вас, та добре для зловмисників [10].
Наприклад, у здійсненні покупки в інтернеті є три дійові особи. Ви –
покупець, сервіс онлайн-платежів та інтернет-магазин, який продає корм для
вашого кота. Цей магазин є партнером сервісу онлайн-розрахунків.
Якщо цей сервіс онлайн-транзакцій використовує токенізацію, вам
нічого боятися. Під час такої операції інформація щодо вашої банківської
картки подається через захищений мережевий шлюз та спеціальний пристрій,
який шифрує дані в унікальний токен. І лише потім сервіс передає цей шифр
далі для здійснення транзакції, приклад роботи зображено на рисунку 1.5
21
Рисунок 1.5 — Принцип роботи
Тобто інтернет-магазин, де ви здійснюєте покупки, не має доступу до
даних вашої картки. Йому відомий лише токен. Навіть, якщо токеном,
унікальним для кожної транзакції, заволодіють треті особи – вони не зможуть
здійснити з ним жодних операцій.
Токени створюються без використання математичних операціи ̆
внаслідок чого між токеном і оригінальними конфіденціи ̆ними даними
відсутніи ̆ прямии ̆ зв'язок, що унеможливлює використання токену
зловмисниками. Підвищення інтересу до токенізаціі ̈ пов'язано, перш за все, з
тим, що вона дозволяє забезпечити високии ̆ рівень захисту конфіденціи ̆них
даних користувача при потенціи ̆но низьких витратах.
Токенізація стала незамінною технологією. Підприємствам дедалі
більше потрібні передові платіжні системи, які дозволяють їм безпечно
зберігати дані, а також здійснювати платежі в майбутньому.
У цьому контексті є кілька надійних платіжних постачальників, які
дають їм можливість зробити рішучий крок і вирівняти свій бізнес за
допомогою цієї технології за короткий час.
Токен — це ідентифікатор, який не має значення для хакерів.
22
З одного боку, регулювання принесло нову реальність в електронну
комерцію з кількох причин.
Досі щоразу, коли клієнт робив онлайн-покупку, емітент картки мав
запитувати певну інформацію, щоб він міг підтвердити платіж.
Використовуючи код автентифікації (OTP) або навіть SMS.
З новою технологією цей метод більше не є надійним, але для
дотримання автентифікації потрібна подвійна перевірка. Однак ця вимога
безпосередньо не впливає на електронну комерцію, оскільки емітенти,
присутні в платіжних системах, є або банками, або постачальниками.
Компанії електронної комерції повинні будуть переконатися, що всі способи
оплати, які вони пропонують, відповідають стандартам PSD2 SCA. Якщо це
не так, вони ризикують втратити довіру користувача.
Ці зміни — це більше, ніж просто коригування. Вони представляють
шлях вперед для електронної комерції, щоб створити системи онлайн-
платежів, які є безпечнішими та вигіднішими для всіх. Крім того, вони є
поштовхом зменшити основні больові кути вашого бізнесу.
Детокенізація є протилежним процесом токенізації. Він складається з
отримання всіх точних даних, пов’язаних із карткою, яка була введена
спочатку. Як правило, це можна зробити лише за допомогою оригінальної
системи, тієї, яка використовується для токенізації.
Але це також можливо зробити за допомогою певних програм,
авторизованих для виконання детокенізації в комерційних цілях.
1.3 Постановка задачі
У розглянутій предметній області є одна велика проблема, яка значно
знижує відмовостійкість системи та завʼязує обробку банківських транзакцій
на певних серверах - це проблема використання статичних серверів.
Відмовостійкість або поступова деградація (англ. graceful degradation),
або поступове скорочення можливостей, або поступовий вихід із роботи, або
23
плавне зниження ефективності це властивість системи (часто комп'ютерної),
що дозволяє їй продовжувати правильно діяти у випадку помилки або
декількох помилок в деяких її частинах. Якщо при цьому падає якість
експлуатації, то це відбувається пропорціонально до серйозності помилки, на
відміну від наївно спроектованих систем, в яких навіть маленька помилка
спричиняє загальну відмову. Відмовостійкість особливо популярна у високо
доступних та життєво критичних системах.
Для банківської системи це критично важливий показник правильної
роботи системи. Наприклад, при виникненні надзвичайної ситуації мільйони
клієнтів не можуть зробити транзакцію в магазинах чи на онлайн
платформах, що створить великі проблеми для населення в цілому.
Щоб уникнути такої ситуації потрібно відмовлятися від використання
статичних серверів та серверних та переходити до хмарних серверів. Але чи
допоможить це значно покращити ситуацію? Розглянемо принципи роботи
хмарних серверів.
Ринок «хмарних» обчислень сьогодні величезний. За даними компанії
Deloitte, в 2009 році тільки в США цей напрямок бізнесу приніс $ 55 млрд.
доходу. До кінця 2022 року очікується вже $ 70 млрд. Новий сервіс особливо
цінний у корпоративному секторі, і в минулому році в США «хмарні»
технології підтримали на державному рівні, запустивши веб-сайт Apps.gov.
Цей ресурс пропонує організаціям держсектора послуги хостингу та схвалені
урядом онлайн-додатки. Вперше на державному рівні була задіяна технологія
«хмарних» обчислень, що дозволила адміністрації президента США
заощадити кошти на закупівлю і настройку серверів і придбання програм.
Згідно з документом IEEE, опублікованим в 2008 році, «хмарна»
обробка даних – це парадигма, в рамках якої інформація постійно
зберігається на серверах в Інтернеті і тимчасово кешується на клієнтській
стороні, наприклад, на персональних комп’ютерах, ігрових приставках,
ноутбуках, смартфонах і т. д. Парадигма «хмарної» обробки даних являє
собою черговий етап розвитку розподілених обчислень. Її попередниками є
24
такі концепції, як «мейнфрейм», grid і «клієнт-сервер». Модель «хмарних»
обчислень складається з п’яти рівнів: клієнт, додаток, платформа,
інфраструктура, сервер.
Для «хмарних» обчислень характерною рисою є нерівномірність
запитів ресурсів з боку користувачів. Щоб згладити ситуацію, для надання
сервісу між серверами і ПО проміжного рівня (англ. – middleware) міститься
ще один шар – віртуалізовані сервери. Це дозволяє здійснювати
балансування навантаження як засобами ПЗ, так і шляхом розподілу
віртуальних серверів за реальними системам.
Але як видно з наведеної інформації, хмарний сервіс це сервіс, який
знаходиться на стороні компанії, яка підтримує його працездатність і такий
підхід спросить для банку підтримку поточного рішення але не можна
сказати, що це повністю вирішить проблему відмовостійкості системи.
Порівняно нещодавно, в 2014 році, компанія Amazon представила
рішення, яке отримало назву “безсервених обчислень”. Це рішення дає
можливість винести обчислення даних на новий рівень, де розробник
програмного забезпечення фокусується на створенню додатку, а компанія,
яка надає серверні послуги вирішує проблему відказостійкості.
Для реалізації системи, яка дасть можливість банку проводити
токенізації транзакції, потрібно щоб виконувалися наступні умови:
- серверне рішення повинно бути відмовостійким, тобто повинно
працювати 24/7 без навіть теоретичної можливості виходу з ладу;
- серверне рішення повинно витримувати високе навантаження на
системи;
- серверне рішення повинно давати можливість виконувати задачі
асинхронно.
Асинхронність - це процес обробки введення/виводу, що дозволяє
продовжити обробку інших завдань, не чекаючи завершення попереднього
завдання. Комп'ютерні програми часто мають справу з тривалими процесами.
Наприклад, отримання даних з бази даних або виконання складних
25
обчислень. Поки виконується одна операція, можна було б завершити ще
кілька. А бездіяльність призводить до зниження продуктивності. Асинхронне
програмування збільшує ефективність, тому що не дозволяє блокувати
основний потік виконання.
При виборі рішення також потрібно враховувати такий показник, як
UpTime. Аптайм обчислювальної системи - час безперервної роботи
обчислювальної системи або її частини. Вимірюється з моменту
завантаження і до моменту припинення роботи (зависання,
перезавантаження, вимкнення, припинення роботи аналізованого
застосунку). У випадку, якщо система все ще функціонує на момент
обговорення, аптайм рахується з моменту завантаження до поточного
моменту.
Крім прямого значення (час безперервної роботи), термін «аптайм»
інколи описує середній час роботи системи та вимірюється у відсотках від
загального часу вимірювання. В цьому випадку протилежним «аптайму» є
«даунтайм» (від англ. downtime) — час, коли система не працює. 99%
аптайму відповідає приблизно 15-хвилинному даунтайму в день (8 годин на
місяць), 99,9% — 50 хвилинам на місяць, 99,99% — 50 хвилинам на рік (4
хвилинам на місяць).
Тому, виходячи з вищеперечисленого можна зробити висновок, що для
проектування подібної системи можна використовувати безсервенні
обчислення, які в теорії повинні забезпечити максимальну відмовостійкість
та повинні дозволити системі працювати з максимальною обчислювальної
продуктивністю.
Обчислювальна потужність системи (продуктивність серверу) — це
кількісна характеристика швидкості виконання певних операцій сервером
(обчислювальним пристроєм). Найчастіше обчислювальна потужність
вимірюється в Флопс (кількості операцій з числа з рухомою комою в
секунду), а також похідними від цієї величини. На даний момент прийнято
зараховувати до суперкомп'ютерів системи з обчислювальною потужністю
26
більше 10 терафлопс (10 12 або десять трильйонів флопс; для порівняння
середньостатистичний сучасний персональний комп'ютер має продуктивність
порядку 0.1 терафлопс). Найпотужніша з існуючих комп'ютерних систем —
японський K computer — має швидкодію, що перевищує 10,5 петафлопс.
Тобто ціль даної магістерської роботи - це досліти можливість
використання безсервених обчислень при роботі з високонавантаженим
банківським програмним забезпеченням, а саме при токенізації транзакцій
1.4 Висновки до розділу 1
У першому розділі проведено аналіз предметної області, а саме
розглянуто хмарні обчислення їх особливості, види моделей, а також
проаналізовано безсерверні обчислення їх переваги та недоліки. Наведено
опис провайдерів для serverless обчислень, таких як: AWS, Azure, Google
cloud.
У даному розділі здійснено вибір напрямку дослідження та більш
детально пояснено, що таке банк, яка його робота, що таке банківська
транзакції та для чого потрібна токенізація в цій сфері діяльності.
Для реалізації системи, яка дасть можливість банку проводити
токенізації транзакції, потрібно щоб виконувалися наступні умови:
- серверне рішення повинно бути відмовостійким, тобто повинно
працювати 24/7 без навіть теоретичної можливості виходу з ладу;
- серверне рішення повинно витримувати високе навантаження на
системи;
- серверне рішення повинно давати можливість виконувати задачі
асинхронно.
Даний розділ містить постановку задачі дослідження кваліфікаційної
роботи магістра.
27
РОЗДІЛ 2 ВИБІР ТЕХНОЛОГІЇ ТА ІНСТРУМЕНТАЛЬНИХ ЗАСОБІВ
РОЗРОБКИ СИСТЕМИ
2.1 Огляд існуючих технологій розробки
AWS Lambda functions. Це безсерверний обчислювальний сервіс, який
надається Amazon Web Services (AWS). Користувачі AWS Lambda
створюють функції, самодостатні програми, написані однією з
підтримуваних мов і середовищ виконання, і завантажують їх в AWS
Lambda, яка виконує ці функції ефективним і гнучким способом.
Функції Lambda можуть виконувати будь-які обчислювальні завдання,
від обслуговування веб-сторінок і обробки потоків даних до виклику API та
інтеграції з іншими службами AWS.
Концепція «безсерверних» обчислень означає відсутність необхідності
підтримувати власні сервери для виконання цих функцій. AWS Lambda — це
повністю керований сервіс, який піклується про всю інфраструктуру за вас. І
тому «без серверів» не означає, що серверів немає: це просто означає, що про
сервери, операційні системи, мережевий рівень та решту інфраструктури вже
подбали, тож ви можете зосередитися на написанні код програми[11].
Як працює AWS Lambda. Кожна лямбда-функція виконується у
власному контейнері. Коли функція створюється, Lambda пакує її в новий
контейнер, а потім виконує цей контейнер на мультитенантному кластері
машин, яким керує AWS. Перед тим, як функції почнуть працювати,
контейнеру кожної функції виділяється необхідна оперативна пам’ять і
потужність ЦП. Після завершення роботи функцій оперативна пам’ять,
виділена на початку, множиться на кількість часу, витраченого
функцією [12]. Тоді клієнти стягують плату на основі виділеної пам’яті та
часу виконання функції.
28
А оскільки послуга повністю керована, використання AWS Lambda
може заощадити ваш час на виконання операційних завдань. Коли немає
інфраструктури для підтримки, ви можете витрачати більше часу на роботу
над кодом програми, навіть якщо це також означає, що ви відмовляєтесь від
гнучкості керування власною інфраструктурою. Приклад безсерверної
архітектури з використанням AWS Lambda зображено на рисунку 2.1.
Рисунок 2.1 — Приклад архітектури
Тут ми бачимо, що статичні елементи програми розміщені в S3. Це не
безсерверний режим.
Однак під час обробки служб, для яких потрібні дані додатків, ключі
API або ідентифікатори, Lambda запускатиме екземпляри зображених служб
за запитом – це без сервера.
Користувачеві в цьому прикладі не потрібно буде керувати/надавати
Cognito, STS або Dynamo.
29
Одна з відмінних архітектурних властивостей AWS Lambda полягає в
тому, що багато екземплярів однієї функції або різних функцій з одного
облікового запису AWS можуть виконуватися одночасно. Крім того,
паралелізм може змінюватися залежно від часу доби або дня тижня, і така
зміна не має значення для Lambda — ви платите лише за обчислення, які
використовують ваші функції. Завдяки цьому AWS Lambda добре підходить
для розгортання хмарних обчислювальних рішень із високою
масштабованістю.
Увесь рівень інфраструктури AWS Lambda управляється AWS. Клієнти
не мають особливого уявлення про те, як працює система, але їм також не
потрібно турбуватися про оновлення основних машин, уникнення конфліктів
у мережі тощо — AWS подбає про це самостійно.
Чому AWS Lambda є важливою частиною безсерверної
архітектури? При створенні безсерверних додатків AWS Lambda є одним із
основних кандидатів для запуску коду додатків. Як правило, щоб завершити
безсерверний стек, вам знадобиться:
● обчислювальний сервіс;
● служба бази даних;
● служба шлюзу HTTP.
Lambda виконує основну роль обчислювальної служби на AWS. Він
також інтегрується з багатьма іншими службами AWS і разом із API Gateway,
DynamoDB і RDS формує основу для безсерверних рішень для тих, хто
використовує AWS. Lambda підтримує багато найпопулярніших мов і
середовищ виконання, тому добре підходить для широкого кола
безсерверних розробників.
Завдяки архітектурі Lambda вона може надати значні переваги
порівняно з традиційними налаштуваннями хмарних обчислень для програм,
де:
● окремі завдання виконуються короткочасно;
● кожне завдання, як правило, є самодостатнім;
30
● існує велика різниця між найнижчим і найвищим рівнями в
робочому навантаженні програми.
Деякі з найпоширеніших варіантів використання AWS Lambda, які
відповідають цим критеріям:
Масштабовані API. Під час створення API за допомогою AWS Lambda
одне виконання функції Lambda може обслуговувати один запит HTTP. Різні
частини API можна направляти до різних функцій Lambda через Amazon API
Gateway. AWS Lambda автоматично масштабує окремі функції відповідно до
попиту на них, тому різні частини вашого API можуть масштабуватися по-
різному відповідно до поточного рівня використання. Це забезпечує
рентабельні та гнучкі налаштування API.
Обробка даних. Лямбда-функції оптимізовані для обробки даних на
основі подій. Легко інтегрувати AWS Lambda з джерелами даних, такими як
Amazon DynamoDB, і запускати функцію Lambda для певних типів подій
даних. Наприклад, ви можете використати Lambda для виконання певної
роботи кожного разу, коли створюється або оновлюється елемент у
DynamoDB, що робить його придатним для таких речей, як сповіщення,
лічильники та аналітика.
Автоматизація завдань. Завдяки моделі, керованій подіями, і
гнучкості, AWS Lambda чудово підходить для автоматизації різноманітних
бізнес-завдань, для яких не потрібен увесь сервер. Це може включати
виконання запланованих завдань, які виконують очищення у вашій
інфраструктурі, обробку даних із форм, надісланих на вашому веб-сайті, або
переміщення даних між різними сховищами даних на вимогу.
Підтримувані мови та середовища виконання. На даний момент
AWS Lambda підтримує не всі мови програмування, але підтримує кілька
найпопулярніших мов і середовищ виконання.
Обмеження AWS Lambda. Хоча AWS Lambda має багато переваг, є
кілька речей, які ви повинні знати, перш ніж використовувати його у
виробництві.
31
Час холодного старту. Коли функція запускається у відповідь на подію,
між подією та виконанням функції може бути невелика затримка. Якщо ваша
функція не використовувалася протягом останніх 15 хвилин, затримка може
сягати 5-10 секунд, що ускладнює покладатися на Lambda для критичних до
затримки програм. Є способи обійти це, зокрема метод, про який ми писали в
нашому блозі.
Функціональні межі. Для лямбда-функцій застосовано кілька
обмежень:
Час виконання/час роботи. Функція Lambda закінчиться після 15
хвилин роботи. Цей ліміт неможливо змінити. Якщо виконання вашої
функції зазвичай займає більше 15 хвилин, AWS Lambda може не підійти для
вашого завдання.
Пам'ять, доступна для функції. Варіанти обсягу оперативної пам’яті,
доступної для функцій Lambda, коливаються від 128 МБ до 3008 МБ з
кроком 64 МБ.
Розмір упаковки коду. Заархівований пакет лямбда-коду не має
перевищувати 50 МБ, а розархівована версія не має перевищувати 250 МБ.
Паралелізм. За замовчуванням одночасне виконання всіх функцій AWS
Lambda в одному обліковому записі AWS обмежено 1000. (Ви можете подати
запит на збільшення ліміту для цієї кількості, звернувшись до служби
підтримки AWS.)
Будь-які лямбда-виконання, ініційовані вище вашого ліміту
паралельності, будуть придушені та будуть змушені чекати, доки інші
функції не завершать роботу.
Розмір корисного навантаження. Під час використання Amazon API
Gateway для запуску функцій Lambda у відповідь на HTTP-запити (тобто під
час створення веб-програми) максимальний розмір корисного навантаження,
який може обробляти API Gateway, становить 10 МБ.
Не завжди рентабельно. На AWS Lambda ви платите лише за
використаний час виконання функції (плюс будь-які пов’язані збори, як-от
32
мережевий трафік). Це може призвести до значної економії коштів для
певних моделей використання, наприклад, із завданнями cron або іншими
завданнями на вимогу. Однак, коли навантаження на вашу програму зростає,
вартість AWS Lambda зростає пропорційно та може виявитися вищою за
вартість подібної інфраструктури на AWS EC2 чи інших хмарних
постачальниках.
Обмежена кількість підтримуваних середовищ виконання. Незважаючи
на те, що AWS Lambda дозволяє додавати користувальницькі середовища
виконання, їх створення може бути складним завданням. Отже, якщо версія
мови програмування, яку ви використовуєте, не підтримується на Lambda,
можливо, вам краще скористатися AWS EC2 або іншим постачальником
хмарних послуг.
Google Serverless. Надає можливість створювати програми улюбленою
мовою, залежностями та інструментами та розгортає їх за лічені секунди.
Cloud Run абстрагує все керування інфраструктурою шляхом автоматичного
збільшення та зменшення масштабу від нуля майже миттєво — залежно від
трафіку [13]. Cloud Run стягує плату лише за ті ресурси, які ви
використовуєте.
Хмарні функції. Дає можливість розробляти швидше, пишучи та
запускаючи невеликі фрагменти коду, які реагують на події.
Використовувати Cloud Functions для підключення до Google Cloud або
сторонніх хмарних служб за допомогою тригерів, щоб спростити складні
проблеми оркестровки. Виконує функції в кількох середовищах (локальне
середовище розробки, локальне, Cloud Run та інші безсерверні середовища
на основі Knative) і запобігайте блокуванню. Постійно зростаюча
популярність AWS Lambda та Google Cloud Functions змушує багатьох
вважати, що FaaS (функція як послуга) є синонімом безсерверних обчислень.
Платформи FaaS беруть функцію від розробників, вбудовують її в додаток і
розгортають у хмарі; він підтримує цілком особливий шаблон для розробки
додатків, де додаток розбивається на набір функцій, згрупованих (керованим)
33
шлюзом, і доступ до яких здійснюється користувачами через статичні файли
HTML, які обслуговуються онлайн, зображно на рисунку 2.2.
Рисунок 2.2 — Приклад шаблону
Ефективно перетворюючи бекенд на службу API, ця фірмова
архітектура користується всіма перевагами безсерверних обчислень (відсутнє
керування сервером, масштабованість, низька вартість) і забезпечує
командну співпрацю на іншому рівні (наприклад, дизайн інтерфейсу
користувача тепер відокремлений); члени команди можуть працювати над
власними функціями на відміну від повної програми).
Azure serverless — це безсерверна пропозиція від Microsoft. Функцію
Azure можна створити за допомогою кількох мов, таких як NodeJS, C#, F#,
Java, Python, PHP або будь-якого виконуваного файлу, і її можна запустити
через Timer, Http, Github Webhook, Blob, Queue і CosmosDB. Ви можете
використовувати функцію Azure двома способами:
1. На основі споживання – це типовий безсерверний обчислювальний
спосіб хостингу, тут Azure автоматично обробляти розподіл ресурсів
34
2. За планом обслуговування додатків – це план PaaS, де, якщо ви вже
маєте обліковий запис, і він не використовується повністю, ви можете
розмістити свою функцію Azure у попередньо зазначеному плані. Існує
обмеження на час роботи в плані споживання, коли функція може працювати
лише до 10 хвилин, тому ваша логіка має бути завершена протягом цього
максимального часу виконання 10 хвилин. У плані App Service ваша функція
працює на виділеній віртуальній машині, і ви не маєте обмежень на час
виконання [14].
У плані споживання контролер масштабу переконається, що достатньо
екземплярів функції доступно для задоволення динамічних вимог. Одиницею
масштабу є додаток функції, а екземпляри функції стають нульовими у
додатку функції, якщо не знайдено подальшого тригера/запиту. На рисунку
2.3 можна розглянути, що функція Azure може прослуховувати різні
події/тригери, а потім може з’єднуватися з чергами обміну повідомленнями
та ресурсами зберігання, щоб завершити наскрізний потік бізнес-логіки.
35
Рисунок 2.3 — Принцип роботи
Інтеграція сервісу. Під час інтеграції служб дуже легко запровадити
тісний зв’язок, який з часом стає крихким, повільним і його важко
налагодити.
Можна створювати свій веб-сайт за допомогою Cloud Run,
використовуючи свою улюблену мову чи фреймворк (Go, Python, Java,
Node.js, .NET тощо), та отримати доступ до своєї бази даних SQL у Cloud
SQL і відтворювати динамічні HTML-сторінки [15].
2.2 Вибір технологій
Для реалізації системи по токенізації банківських транзакцій потрібно
обрати такі рішення та технології, які допоможуть просто та зручно керувати
високонавантаженими програмними додатками, при цьому будуть просто
масштабуватися та будуть мати гарні характеристики відмовостійкості. Для
реалізації цієї задачі краще всього підходять безсерверні обчислення, тому
що:
- простий запуск додатку (додаток ділиться на велику кількість простих
скриптів);
- проста підтримка додатку, моніторинг, логування (всі відомі рішення
за замовчуванням мають цю функціональність);
- додавання нової функціональності не викликає проблем;
- легкість у розгортанні застосунку.
Для того щоб обрати сервіс, який буде використовуватися для
дослідження, потрібно враховувати наступні показники:
- Підтримка потрібної мови програмування;
- Кількість серверів, наявних у компанії по цілому світу;
- Популярність сервісу.
36
Тому перед тим, як обирати потрібний сервіс, необхідно визначитися з
мовою програмування та обрати таку, за допомогою якої можна буде
реалізувати поставлені завдання.
Мова програмування — це система позначень для опису алгоритмів і
структур даних, певна штучна формальна система, засобами якої можна
виражати алгоритми. Мову програмування визначає набір лексичних,
синтаксичних і семантичних правил, що задають зовнішній вигляд програми
та дії, які виконує виконавець (комп'ютер) під її управлінням. З часу
створення перших програмованих машин було створено понад дві з
половиною тисячі мов програмування. Щороку до них додаються нові.
Деякими мовами вміє користуватись тільки невелике число їхніх
розробників, інші стають відомі мільйонам людей. Професійні програмісти
зазвичай застосовують у своїй роботі декілька мов програмування.
Вибір мови програмування є пріоритетною частиною розробки любого
продукту, тому що помилка в цій частині роботи ставить під питання
майбутнє всього рішення, а головне гроші, які потрібно буде витратити при
неправильному виборі. Розглянемо популярні мови програмування в 2022
році.
Найпопулярнішою мовою серед українських розробників залишається
JavaScript (18,8%). На другому місці C#, у неї другий рік поспіль позитивна
динаміка. Можна припустити, що завдяки активному зростанню геймдев-
індустрії. Далі йде Java, частка якої з 2017 року стабільно зменшується.
JavaScript (JS) — динамічна, об'єктно-орієнтована прототипна мова
програмування. Реалізація стандарту ECMAScript. Найчастіше
використовується для створення сценаріїв вебсторінок, що надає можливість
на боці клієнта (пристрої кінцевого користувача) взаємодіяти з користувачем,
керувати браузером, асинхронно обмінюватися даними з сервером,
змінювати структуру та зовнішній вигляд вебсторінки. JavaScript
класифікують як прототипну (підмножина об'єктно-орієнтованої), скриптову
мову програмування з динамічною типізацією. Окрім прототипної, JavaScript
37
також частково підтримує інші парадигми програмування (імперативну та
частково функціональну) і деякі відповідні архітектурні властивості, зокрема:
динамічна та слабка типізація, автоматичне керування пам'яттю, прототипне
наслідування, функції як об'єкти першого класу [16].
Рисунок 2.4 — Рейтинг мов програмування
Node.js — платформа з відкритим кодом для виконання
високопродуктивних мережевих застосунків, написаних мовою JavaScript.
Засновником платформи є Раян Дал. Якщо раніше JavaScript застосовувався
для обробки даних в браузері користувача, то node.js надав можливість
виконувати JavaScript-скрипти на сервері та відправляти користувачеві
результат їхнього виконання. Платформа Node.js перетворила JavaScript на
мову загального використання з великою спільнотою розробників. Node.js
має наступні властивості:
- асинхронна одно-нитева модель виконання запитів;
- неблокуючий ввід/вивід;
- система модулів CommonJS;
- рушій JavaScript Google V8;
C# — об'єктно-орієнтована мова програмування з безпечною системою
типізації для платформи .NET. Розроблена Андерсом Гейлсбергом, Скотом
Вілтамутом та Пітером Гольде під егідою Microsoft Research (належить
38
Microsoft). Синтаксис C# близький до С++ і Java. Мова має строгу статичну
типізацію, підтримує поліморфізм, перевантаження операторів, вказівники на
функції-члени класів, атрибути, події, властивості, винятки, коментарі у
форматі XML. Перейнявши багато від своїх попередників — мов С++, Object
Pascal, Модула і Smalltalk — С#, спираючись на практику їхнього
використання, виключає деякі моделі, що зарекомендували себе як
проблематичні при розробці програмних систем, наприклад, мова С#, на
відміну від C++, не передбачає множинне успадкування класів.
Хоча визначення мови C# і CLI стандартизовані ISO та Ecma, що
забезпечує розумний і недискримінаційний ліцензійний захист від патентних
позовів, Microsoft використовує C# і CLI у своїй бібліотеці Base Class Library
(BCL), яка є фундаментом їхньої власницької платформи .NET framework, і
яка надає низку нестандартизованих класів (розширений I/O, GUI Windows
Forms, вебслужби тощо).
У деяких випадках, де патенти Microsoft відносяться до стандартів,
використаних у .NET framework, документовані Microsoft, і застосовані
патенти доступні через інші RAND умови або через Обітницю Відкритої
Специфікації Microsoft (Microsoft's Open Specification Promise, OSP), які
випускають патентні права публічно. Але є деякі застереження і обговорення
про те, що існують додаткові аспекти, патентовані Microsoft, що не покриті,
які можуть утримувати незалежних реалізаторів повного фреймворку [17].
Java — об'єктно-орієнтована мова програмування, випущена 1995 року
компанією «Sun Microsystems» як основний компонент платформи Java. З
2009 року мовою займається компанія «Oracle», яка того року придбала «Sun
Microsystems». В офіційній реалізації Java-програми компілюються у байт-
код, який при виконанні інтерпретується віртуальною машиною для
конкретної платформи.
«Oracle» надає компілятор Java та віртуальну машину Java, які
задовольняють специфікації Java Community Process, під ліцензією GNU
General Public License.
39
Мова значно запозичила синтаксис із C і C++. Зокрема, взято за основу
об'єктну модель С++, проте її модифіковано. Усунуто можливість появи
деяких конфліктних ситуацій, що могли виникнути через помилки
програміста та полегшено сам процес розроблення об'єктно-орієнтованих
програм. Ряд дій, які в С/C++ повинні здійснювати програмісти, доручено
віртуальній машині. Передусім Java розроблялась як платформо-незалежна
мова, тому вона має менше низькорівневих можливостей для роботи з
апаратним забезпеченням, що в порівнянні, наприклад, з C++ зменшує
швидкість роботи програм. За необхідності таких дій Java дозволяє
викликати підпрограми, написані іншими мовами програмування.
Python (найчастіше вживане прочитання — запозичено назву з
британського шоу Монті Пайтон) — інтерпретована об'єктно-орієнтована
мова програмування високого рівня зі строгою динамічною типізацією.[8]
Розроблена в 1990 році Гвідо ван Россумом. Структури даних високого рівня
разом із динамічною семантикою та динамічним зв'язуванням роблять її
привабливою для швидкої розробки програм, а також як засіб поєднування
наявних компонентів. Python підтримує модулі та пакети модулів, що сприяє
модульності та повторному використанню коду. Інтерпретатор Python та
стандартні бібліотеки доступні як у скомпільованій, так і у вихідній формі на
всіх основних платформах. В мові програмування Python підтримується
кілька парадигм програмування, зокрема: об'єктно-орієнтована, процедурна,
функціональна та аспектно-орієнтована.
Серед основних її переваг можна назвати такі:
- чистий синтаксис (для виділення блоків слід використовувати
відступи);
- переносимість програм (що властиве більшості інтерпретованих
мов);
- стандартний дистрибутив має велику кількість корисних модулів
(включно з модулем для розробки графічного інтерфейсу);
40
- можливість використання Python в діалоговому режимі (дуже
корисне для експериментування та розв'язання простих задач);
- стандартний дистрибутив має просте, але разом із тим досить
потужне середовище розробки, яке зветься IDLE і яке написане
мовою Python;
- зручний для розв'язання математичних проблем (має засоби
роботи з комплексними числами, може оперувати з цілими
числами довільної величини, у діалоговому режимі може
використовуватися як потужний калькулятор);
- відкритий код (можливість редагувати його іншими
користувачами).
Python має ефективні структури даних високого рівня та простий, але
ефективний підхід до об'єктно-орієнтованого програмування. Елегантний
синтаксис Python, динамічна обробка типів, а також те, що це інтерпретована
мова, роблять її ідеальною для написання скриптів та швидкої розробки
прикладних програм у багатьох галузях на більшості платформ.
Ознайомившись з мовами програмування можна зробити висновок що
більшість з популярних мов програмування базуються на C/C++ синтаксисі,
що значно спрощує пошук спеціалістів при подальшій роботі над рішенням.
Також слід зазначити що JS, а саме Node.js має самий простий синтаксис та
дає нам можливість створювати максимально прості скрипти при
використанні безсерверних рішень.
Але мова програмування не є основною при виборі сервіс провайдера.
Також треба враховувати, що любий програмний додаток потребує базу
даних, в якій ми можемо зберігати дані про транзакції і про результати
токенізації. Розглянемо види баз даних та популярні рішення.
База даних – сукупність даних, організованих відповідно до концепції,
яка описує характеристику цих даних і взаємозв'язки між їх елементами; ця
сукупність підтримує щонайменше одну з областей застосування (за
стандартом ISO/IEC 2382:2015). В загальному випадку база даних містить
41
схеми, таблиці, подання, збережені процедури та інші об'єкти. Дані у базі
організовують відповідно до моделі організації даних. Таким чином, сучасна
база даних, крім самих даних, містить їх опис та може містити засоби для їх
обробки. Бази даних класифікують за різними критеріями:
- За моделлю організації даних розрізняють такі бази даних:
● Ієрархічна. Ієрархічна база даних може бути представлена як
дерево, що складається з об'єктів різних рівнів. Між об'єктами
існують зв'язки типу «предок-нащадок». При цьому можлива
ситуація, коли об'єкт не має нащадків або має їх декілька, тоді як
у об'єкта-нащадка обов'язково тільки один предок.
● Мережна. Така база даних подібна до ієрархічної, за винятком
того, що кожен об'єкт може мати більше одного предка.
● Реляційна. Реляційна база даних зберігає дані у вигляді таблиць.
Найуживаніші СКБД використовують реляційну модель даних.
● Об'єктно-орієнтована. У базі даних цього виду дані оформляють
у вигляді моделей об'єктів.
- За розміщенням даних виділяють такі види баз:
● Локальна, або централізована. Така база даних підтримується на
одному комп'ютері.
● Розподілена. Частини такої бази даних розміщують на різних
комп'ютерах мережі.
- За технологією фізичного зберігання виділяють:
● БД у вторинній пам'яті (традиційні).
● БД в оперативній пам'яті (in-memory database).
● БД у третинній пам'яті (tertiary database).s
Система управління базами даних (СУБД, СКБД англ. Database
Management System, DBMS) — набір взаємопов'язаних даних (база даних) і
програм для доступу до цих даних. Надає можливості створення, збереження,
оновлення та пошуку інформації в базах даних з контролем доступу до
даних.
42
Вибір СУБД, як і вибір мови програмування є однією з основних
частин початку роботи над проектом. Рейтинг СУБД зображено на рисунку
2.5.
Рисунок 2.5 — Рейтинг СУБД
MySQL — вільна система керування реляційними базами даних, яка
була розроблена компанією «ТсХ» для підвищення швидкодії обробки
великих баз даних. Ця система керування базами даних (СКБД) з відкритим
кодом була створена як альтернатива комерційним системам. MySQL з
самого початку була дуже схожою на mSQL, проте з часом вона все
розширювалася і зараз MySQL — одна з найпоширеніших систем керування
базами даних. Вона використовується, в першу чергу, для створення
динамічних вебсторінок, оскільки має чудову підтримку з боку
різноманітних мов програмування.
MySQL має подвійне ліцензування. MySQL може розповсюджуватися
відповідно до умов ліцензії GPL. Але за умовами GPL, якщо якась програма
використовує бібліотеки MySQL, то вона теж повинна розповсюджуватись за
ліцензією GPL. Проте це може розходитися з планами розробників, які не
бажають відкривати сирцеві тексти своїх програм. Для таких випадків
передбачена комерційна ліцензія компанії Oracle, яка також забезпечує
якісну сервісну підтримку [18]. В разі використання та розповсюдження
43
програмного забезпечення з іншими вільними ліцензіями, такими як BSD,
Apache, MIT та інші, MySQL дозволяє використання бібліотек MySQL за
ліцензією GPL.
PostgreSQL — об'єктно-реляційна система керування базами даних
(СКБД). Є альтернативою як комерційним СКБД (Oracle Database, Microsoft
SQL Server, IBM DB2 та інші), так і СКБД з відкритим кодом (MySQL,
Firebird, SQLite).
Порівняно з іншими проектами з відкритим кодом, такими як Apache,
FreeBSD або MySQL, PostgreSQL не контролюється якоюсь однією
компанією, її розробка можлива завдяки співпраці багатьох людей та
компаній, які хочуть використовувати цю СКБД та впроваджувати у неї
найновіші досягнення.
Сервер PostgreSQL написаний на мові C. Зазвичай розповсюджується у
вигляді набору текстових файлів із сирцевим кодом. Для інсталяції необхідно
відкомпілювати файли на своєму комп'ютері і скопіювати в деякий каталог.
Весь процес детально описаний в документації.
MongoDB - документо-орієнтована система керування базами даних
(СКБД) з відкритим вихідним кодом, яка не потребує опису схеми таблиць.
MongoDB займає нішу між швидкими і масштабованими системами, що
оперують даними у форматі ключ/значення, і реляційними СКБД,
функціональними і зручними у формуванні запитів.
Код MongoDB написаний на мові C++ і поширюється в рамках ліцензії
AGPLv3.
MongoDB підтримує зберігання документів в JSON-подібному форматі,
має досить гнучку мову для формування запитів, може створювати індекси
для різних збережених атрибутів, ефективно забезпечує зберігання великих
бінарних об'єктів, підтримує журналювання операцій зі зміни і додавання
даних в БД, може працювати відповідно до парадигми Map/Reduce,
підтримує реплікацію і побудову відмовостійких конфігурацій. У MongoDB є
вбудовані засоби із забезпечення шардінгу (розподіл набору даних по
44
серверах на основі певного ключа), комбінуючи який з реплікацією даних
можна побудувати горизонтально масштабований кластер зберігання, в
якому відсутня єдина точка відмови (збій будь-якого вузла не позначається
на роботі БД), підтримується автоматичне відновлення після збою і
перенесення навантаження з вузла, який вийшов з ладу. Розширення кластера
або перетворення одного сервера на кластер проводиться без зупинки роботи
БД простим додаванням нових машин.
Для того, щоб обрати систему управління базою даних потрібно
враховувати наступні умови:
- СУБД повинна бути популярною у світі розробки, щоб у майбутньому
не було проблем з пошуком спеціалістів;
- СУБД повинна мати підтримку в мові програмування, щоб можна було
без проблем створювати програмні застосунки за допомогою цієї бази
даних;
- СУБД повинна бути реляційна, того що в системі, яка буде створена
буде чіткий звʼязок між транзакціями і токенами, які будуть отримані в
процесі токенізації.
Виходячи з усього вищесказаного можна зробити висновок, що система
управління базою даних MySQL краще всього підходить для виконання
завдання даної роботи.
Обравши мову програмуванні і СУБД, дослідивши існуючі рішення
можна зробити висновок, що AWS рішення ідеально підходить для
виконання даного завдання [19].
Технологія AWS базується на серверних кластерах (фермах),
розташованих по всьому світі. Плата за користування базується на комбінації
використання апаратних засобів/ОС/програмного забезпечення/мережевих
функцій, вибраних користувачем, а також вимог до доступності,
надлишковості, безпеки та додаткових параметрів. Виходячи з того, що
користувач потребує і оплачує, він може зарезервувати один віртуальний
комп'ютер, кластер віртуальних комп'ютерів, фізичний комп'ютер,
45
призначений для його виняткового використання, або навіть кластер
фізичних комп'ютерів. Компанія Amazon зобов'язується керувати та
оновлювати програмне та апаратне забезпечення для дотримання необхідних
стандартів безпеки. AWS працює в багатьох географічних регіонах, у тому
числі в Канаді, Німеччині, Ірландії, Сінгапурі, Токіо, Сіднеї, Пекіні, Лондоні
і т. д.
У 2016 році AWS надавав більш ніж 70 сервісів, що охоплюють
широкий спектр, включаючи обчислення та зберігання даних, їхню передачу
по мережі, аналітику, мобільні застосунки, інструменти для розробників і т.
д. Найпопулярніші з них є Amazon Elastic Compute Cloud (EC2) і Amazon
Simple Storage Service (S3). Більшість служб не надаються безпосередньо
кінцевим користувачам, але замість цього пропонуються функціональні
можливості через API, які розробники можуть використовувати в своїх
програмах. Пропозиції Amazon Web Services доступні через HTTP,
використовуючи архітектурний стиль REST та протокол SOAP [20].
Рішення AWS дає можливість використовувати безсервені обчислення,
за допомогою продукту Amazon Lambda, при цьому оплати буде
нараховуватися тільки під час використання даних обчислень. Також це
рішення підтримує обрану мову програмування Node.js та СУБД MySQL за
допомогою рішення Amazon RDS.
2.3 Висновки до розділу 2
У другому розділі проведено огляд існуючих технологій, таких як:
AWS Lambda functions, Google Serverless, Azure Serverless їх можливості та
переваги. Також було обрано технології, які будуть використовуватися для
реалізації системи на базі безсерверних технологій, а саме: мова
програмування Node.js, що має досить простий синтаксис та дає можливості
створювати масимально прості скрипти; база даних, яка найкраще підходить
для цього MySQL; технології AWS Amazon Lambda, що є найголовнішим.
46
РОЗДІЛ 3 РЕАЛІЗАЦІЯ МЕТОДІВ ЗАСТОСУВАННЯ БЕЗСЕРВЕРНИХ
ОБЧИСЛЕНЬ ДЛЯ ТОКЕНІЗАЦІЇ БАНКІВСЬКИХ ДАНИХ
3.1 Структура системи
Для дослідження методів застосування безсерверних обчислень було
створено програмне забезпечення, яке виконує токенізацію банківських
даних за допомогою рішення AWS Lambda. Розроблена система складається
з наступних модулів, що зображено на рисунку 3.1:
1. Програмне забезпечення банківського POS терміналу.
2. Модуль отримання інформації від терміналу.
3. Модуль обробки транзакції.
4. Модуль передачі токену між системою та банком.
Рисунок 3.1 — Структура системи
47
Розглянемо кожен з цих модулів детально. І почнемо з головного, який
отримує дані від користувача та передає їх в розроблену системи. Але перед
тим, як розглядати даний модуль, потрібно вияснити, що таке POS термінал.
Платіжний термінал (англ. Payment terminal) або POS-термінал (від
англ. Point Of Sale — точка продажу) — це електронний пристрій, що зчитує
дані пластикової картки з магнітної смуги або чипу, розташованого на
пластиковій картці, або зі смартфону з функцією NFC та встановленого
відповідного ПЗ із внесеними реквізитами платіжної картки, і зв'язується з
банком по електронних каналах зв'язку. Сума операції вводиться з клавіатури
(якщо це POS-термінал, інтегрований до каси, то сума береться з даних каси
до оплати). Всі дані операції друкуються на чеку терміналом.
Наявність POS-терміналу дозволяє приймати до оплати всі типи
міжнародних банківських карток, включаючи як найпоширеніші електронні
картки «Visa» та «Mastercard», так і менш поширені у нашій країні China
UnionPay та інші, що значно прискорює проведення операції оплати і
скорочує термін відшкодування грошових коштів по проведених операціях.
Тобто за допомогою POS терміналу продавець може прийняти
транзакцію від покупця. Далі цей термінал повинен передати інформацію до
банку, для подальшої обробки і токенізації.
Банківська транзакція, або трансакція (англ. bank transaction, від лат.
transactio — угоду, договір), — в загальному будь-яка операція з
використанням банківського рахунку. Розрізняють онлайн-транзакції, що
виконуються в режимі реального часу між усіма зацікавленими сторонами, і
оффлайн-транзакції. Як підсумкова частина банківської операції, транзакція
може бути ініційована подачею письмового розпорядження в банк,
електронним розпорядженням через системи інтернет-банкінгу або інші
комунікаційні системи, а також за допомогою якого-небудь платіжного
інструменту.
48
Для того щоб передати цю інформацію зазвичай подібні термінали
використовують HTTP/HTTPS з’єднання, через яке передається інформацію
про карту покупця до банку.
HTTP — протокол передачі даних, що використовується в
комп'ютерних мережах. Назва скорочена від HyperText Transfer Protocol,
протокол передачі гіпертекстових документів. HTTP — протокол
прикладного рівня, схожими на нього є FTP і SMTP. Обмін повідомленнями
йде за звичайною схемою «запит-відповідь». Для ідентифікації ресурсів
HTTP використовує глобальні URI. На відміну від багатьох інших
протоколів, HTTP не зберігає свого стану. Це означає відсутність збереження
проміжного стану між парами «запит-відповідь». Компоненти, що
використовують HTTP, можуть самостійно здійснювати збереження
інформації про стан, пов'язаний з останніми запитами та відповідями.
Браузер, який відправляє запити, може відстежувати затримки відповідей.
Сервер може зберігати IP-адреси та заголовки запитів останніх клієнтів.
Проте, згідно з протоколом, клієнт та сервер не мають бути обізнаними з
попередніми запитами та відповідями, у протоколі не передбачена внутрішня
підтримка стану й він не ставить таких вимог до клієнта та сервера.
Для забезпечення захисту відправки даних зазвичай використовують
кілька методів, серед яких шифрування контенту за допомогою SSL
сертифікату.
SSL (англ. Secure Sockets Layer — рівень захищених сокетів) —
криптографічний протокол, який забезпечує встановлення безпечного
з'єднання між клієнтом і сервером. SSL спочатку розроблений компанією
Netscape Communications . Згодом на підставі протоколу SSL 3.0 був
розроблений і прийнятий стандарт RFC, що отримав ім'я TLS.
Також вважається гарною практикою використовувати додаткове
шифрування, так як інформація про карту клієнта є досить конфіденційною
інформацією і втрата цих даних при передачі з терміналу на систему є вкрай
не бажаною. Для додаткового шифрування було використано алгоритм AES.
49
Advanced Encryption Standard (AES), також відомий під назвою Rijndael
— симетричний алгоритм блочного шифрування (розмір блока 128 біт, ключ
128/192/256 біт), фіналіст конкурсу AES і прийнятий як американський
стандарт шифрування урядом США. Вибір припав на AES з розрахуванням
на широке використання та активний аналіз алгоритму, як це було із його
попередником, DES. Державний інститут стандартів і технологій (англ.
National Institute of Standards and Technology, NIST) США опублікував
попередню специфікацію AES 26 жовтня 2001 року, після п'ятилітньої
підготовки. 26 травня 2002 року AES оголошено стандартом шифрування.
Станом на 2009 рік AES є одним із найпоширеніших алгоритмів
симетричного шифрування.
Після шифрування та відправки даних з POS-терміналу система
отримує інформацію на вхід до сервіс провайдеру AWS. Як розглядалося у
попередніх розділах, AWS надає можливість виконувати безсервенні
обчислення за допомогою продукту Amazon Lambda. Коли ми говоримо про
«безсерверні» обчислення, багато хто припускає, що в цій моделі немає
сервера для полегшення виконання коду та інших завдань розробки. Це
звичайна помилка.
Під безсерверними обчисленнями розуміється те, що немає виділеного
сервера під роботу розробленого додатку, але існує велика кількість серверів,
які можуть у будь-який момент часу виконати потрібний код. Причому, у
цьому випадку ресурси серверу виділяють динамічно, за необхідності.
Тобто у нашому випадку, після відправки даних до AWS, система
автоматично визначає, який сервер буде виконувати обробку інформації. Для
того щоб AWS розумів, в який момент треба виконати той чи інший код, в
AWS Lambda існує система тригерів, які налаштовуються користувачем
системи (зображено на рисунку 3.2).
50
Рисунок 3.2 — Система тригерів AWS Lambdas
Lambda тригер - це подія, після якої повинна бути запущена в роботу
лямбда функція. Наприклад якщо в систему AWS надходить HTTP запит і у
цей момент часу нам потрібно виконати певні дії, це й буде тригером для
коду системи для початку роботи.
Після того, як AWS отримала запит, даний сервіс провайдер запустить
виконання розробленого коду програми в дію.
Наступний модуль програми відповідає за збереження інформації до
проміжної бази даних перед токенізацією даних. Це потрібно для того, щоб
запобігти навантаженню на Lambda функцію. Тобто отримавши дані від
терміналу, ми спочатку зберігаємо їх до бази даних а потім, коли буде
завершено HTTP запит, система починає виконання токенізації банківської
інформації. Під проміжною базою даних розуміється звичайна MySQL база
даних, ціль якої зберегти отримані дані в системі та поставити ці дані в чергу
для обробки наступною вільною Lambda функцією.
Черга (англ. queue) в програмуванні — динамічна структура даних, що
працює за принципом «перший прийшов — перший пішов» (англ. FIFO —
first in, first out). У черги є голова та хвіст. Елемент, що додається до черги,
51
опиняється в її хвості. Елемент, що видаляється з черги, знаходиться в її
голові. Така черга повністю аналогічна звичній «базарній» черзі, у якій
спочатку обслуговують того, хто прийшов першим, потім наступного і так
далі.
Після того як система отримали дані з терміналу, поточне HTTP
зʼєднання між терміналом і AWS завершується. Термінал не буде очікувати
результат токенізації і відповіді банку. Це значно збільшує рівень безпеки
системи. Після завершення зʼєднання з AWS термінал отримає унікальний
ідентифікатор транзакції, по якому від зможе почати опитування для
отримання інформації про транзакцію. Для цієї цілі зазвичай
використовується підхід під назвою “Long Polling”.
Тривале опитування (Long polling) – це найпростіший спосіб
реалізувати постійне з’єднання із сервером, без використання спеціального
протоколу, такого як WebSocket або Server Side Events. Будучи дуже простим
у реалізації, він також достатньо хороший у багатьох випадках.
Найпростіший спосіб отримати нову інформацію з сервера –
періодичне опитування. Тобто регулярні запити до сервера: “Привіт, я тут, у
вас є якась інформація для мене?”. Наприклад, раз на 10 секунд.У відповідь
сервер спочатку помічає собі, що клієнт онлайн, а по-друге – надсилає пакет
повідомлень, які він отримав до цього моменту.
Таким чином термінал в подальшому матиме можливість отримати
інформацію про результат опрацювання поточної транзакції.
Далі, відправивши дані про карту клієнта в розроблену систему ми
почнемо процес токенізації даних.
Токенізація – технологія, що дозволяє забезпечити електронні платежі
за допомогою системи шифрування даних. Токенізація дозволяє здійснювати
платежі не розголошуючи дані карти/рахунку користувача. Інформація про
карту (номер карти/cvv-код і ін.) замінюється унікальними цифровими
ідентифікаторами – токенам.
52
Токени захищають персональну інформацію та фінансові операції
передаючи дані карти у зашифрованому вигляді. Токени створюються через
математичні формули або випадкові буквено-цифрові генератори і не можуть
бути використані зловмисниками, так як не несуть в собі ніякої цінності.
Токенізація виводить безпеку платежів та фінансових операцій на
найвищий рівень, а також полегшує безконтактні способи оплати (наприклад,
оплата смартфоном). Легкість оплати, безпека та надійність – головні
переваги токенізаціі.
Тобто розроблена система виконує токенізацію отриманих даних і
відправляє її в банку вже у вигляді токену. Далі банк працює з цим токен і
вірогідність того, що хтось отримає доступ до інформації карти стає
мінімальним.
Розглянемо принцип переведення даних карти з читаємого формату до
токену. Після збереження даних до бази даних перша lambda функція
перестає працювати. Далі дані очікують запуску наступної функції, яка
автоматично буде запущена системою AWS після додавання цих даних до
бази даних.
Дані з бази автоматично зчитуються додатковою lambda функцією 1
раз з секунду. 1 запис з бази опрацьовується окремою lambda функцією. Для
збільшення рівня стійкості захисту використовується декілька алгоритмів
шифрування. Для стабільної роботи lambda функції потрібно обрати
правильні налаштування. Розглянемо приклад налаштування lambda функції
для роботи з шифруванням даних.
53
Рисунок 3.3 — Налаштування AWS Lambdas
Важливо правильно налаштувати функцію для роботи з очікуємим
алгоритмом, тому що у випадку неправильних налаштувань токен не буде
отримано, і це призведе до втрат в часі при обробці транзакцій. Розглянемо
кожне налаштування детально.
Оперативна пам'ять (англ. Random Access Memory, дослівно - пам'ять з
довільним доступом, ПДД, первинна пам'ять) - пам'ять ЕОМ, призначена для
зберігання коду та даних програм під час їхнього виконання. У сучасних
комп'ютерах оперативна пам'ять переважно представлена динамічною
пам'яттю з довільним доступом DRAM.
54
Треба зазначити що стандартний показник у 128 МБ є не достатнім для
роботи з шифруванням, тому цей параметр було змінено на 512МБ. Треба
розуміти що збільшення стандартних показників функції веде до збільшення
кінцевої вартості продукту.
Ephemeral storage - це памʼять, яка виділяється AWS для опрацювання
коду програми. AWS працює з контейнерами, в яких запускається програма.
Тому за замовчуванням 512 МБ повинно вистачити для виконання
програмного коду.
Timeout - кількість часу, за який lambda функція повинна завершити
виконання заданого коду. У випадку, якщо за вказаний час не буде отримано
фінального результату, функція завершить роботу і спробує ще раз виконати
цей запит повторно. Повторні спроби вкрай не рекомендовані, тому що це
призведе до збільшення часу виконання програми.
Для створення правильного токену було використано 3 різні алгоритми
шифрування з різною стійкість до злому.
Криптографічна стійкість - здатність криптографічного алгоритму
протистояти криптоаналізу. Стійким вважається алгоритм, який для успішної
атаки вимагає від противника недосяжних обчислювальних ресурсів,
недосяжного обсягу перехоплених відкритих і зашифрованих повідомлень чи
ж такого часу розкриття, що по його закінченню захищена інформація буде
вже не актуальна, і т. д. У більшості випадків крипостійкість не можна
математично довести, можна тільки довести уразливості криптографічного
алгоритму.
Кожен алгоритм шифрування виконується окремою lambda функцією
паралельно, не блокуючи інші потоки. В цьому і заключається перевага
даного підходу. Є необмежена кількість серверів, які можуть опрацювати
даний запит.
Після проходження всіх етапів шифрування отримується токен. Токени
(від англ. token) - непрозоре повідомлення, яке посилається на етапі
встановлення з'єднання чи в механізмі передачі захищеного повідомлення.
55
Токен не зберігається проміжною системою (розробленою в рамках
даної роботи) для більшої безпеки користувацьких даних. Даний токен, після
отримання, автоматично надсилається банку і банк далі продовжить роботу з
даною транзакцією. Після завершення роботи з даними, вони видаляються з
проміжної таблиці і всі подальші маніпуляції з цією транзакцією
відбуваються тільки за допомогою токену. Токен також дає можливість
банку робити додаткові транзакції по карті клієнта, якщо це необхідно. При
цьому банку не потрібно знати дані клієнтської карти, так як вони вже
збережені в даний токен.
Передача даних між розробленою системою та сервером банку
відбувається через таке саме HTTPS зʼєднання, як і у випадку комунікації
терміналу з системою. У цьому випадку дані, які передаються, будуть
захищені від перехоплення, тому банк може вільно оперувати цими даними
при передачі їх до платіжної системи чи до додаткових банківських сервісів.
3.2 Опис функцій системи
Так як розроблена система являється фоновим процесом, користувач
навіть знати не бути, що відбувається з його транзакцією. Фонове завдання
(фоновий процес) - процес, який працює у фоні, на стороні серверу. Для
користувача, токенізація його карти - це всього навсього процес проведення
банківської транзакції. Але для нас, це додатковий сервіс, який має своє
призначення та виконує токенізацію вхідних даних.
Розглянемо роботу створеного сервісу в рамках всього процесу роботи
з транзакцією в банківській системі.
56
Рисунок 3.4 — Принцип роботи банківської системи
Після вибору товару в магазині, користувач зазвичай має вибір при
оплаті товару: оплатити готівкою чи використати платіжну карту.
Платіжна ка́ртка (іноді банківська платіжна картка — БПК) —
виготовлена згідно зі стандартом ISO/IEC 7810 ID-1 формату із спеціального
стійкого до механічних пошкоджень пластику пластина стандартних розмірів
54x86x0,76 мм, яка використовується для ідентифікації її користувача
(держателя), для способу фіксації інформації і як аналог платіжних засобів.
Ідентифікування забезпечується нанесенням на картку її номера (відповідно
ISO/IEC 7812 стандартизованої нумерації), строку дії, прізвища, ім'я і зразка
підпису власника картки та/або інших ідентифікаційних даних (магнітна
смуга, чип, RFID-мітка тощо).
Зазвичай платіжна карта видана банком та всі транзакції проходять
через цей банк. Тільки банк має право опрацьовувати дану транзакцію і для
цього йому потрібні дані карти. Під даними карти мається на увазі наступна
інформація:
- Номер банківської карти;
- Дата закінчення терміну дії карти;
- Імʼя та прізвище власника карти;
- Секретный код CVV2.
57
CVV2 (англ. Card Verification Value 2) - тризначний код перевірки
дійсності картки платіжної системи Visa. Інші платіжні системи мають схожі
технології, наприклад, аналогічний код для карток MasterCard носить назву
Card Validation Code 2 (CVC2). Наноситься на смузі для підпису держателя
після номера картки або після останніх 4 цифр номера картки способом
індент-друку. Використовується як захисний елемент при проведенні
трансакцій в середовищі CNP (card not present). Наприклад — e-commerce (в
інтернеті), MO/TO (Mail order/Telephone order — замовлення поштою чи
телефоном).
Для того щоб магазин зміг зняти кошти з людини за допомогою карти,
використовується платіжний термінал, який автоматично зчитує дані карти
та передає ці дані до банку, який видав дану карту.
Передача цих даних відображена на рисунку 3.4. Спочатку дані
передаються від терміналу до банку, який видав даний термінал. Після
отримання цих даних, банк звертається до платіжної системи, для отримання
інформації про банк, який видав карту. І тільки після цього відбувається
відправка коштів між банком, який видав термінал до банку, який видав
карту клієнту.
Платіжна система - платіжна організація, члени платіжної системи та
сукупність відносин, що виникають між ними при проведенні переказу
коштів. Проведення переказу коштів є обов'язковою функцією, що має
виконувати платіжна система.
Таким чином ми можемо побачити велику кількість елементів в
банківській системі, яким потрібно відправити інформацію про карту. Для
того, щоб забезпечити безпеку передачі даних між усіма елементами
банківської системи ввели таке поняття, як токенізація.
Токенізація забезпечує переведення банківської інформації (у нашому
випадку - даних карти) з звичайного тексту в спеціальний токен, який не
може бути прочитаний сторонньою особою і тільки банк має право отримати
інформацію до цих даних.
58
Процес отримання токена є досить важливим етапом роботи з
транзакцією. Якщо цей токен не буде отримано, термінал не зможе
відправити його до банку і тим самим транзакція буде відхилена. Тому
важлимо щоб сервіс, який займається токенізацією мав високий рівень
продуктивності, а також був максимально відмовостійкий. Для цих цілей
було обрано безсерверні обчислення, які дають можливість виконувати
велику кількість запитів при цьому не є завʼязаними на одному сервері.
Виконання даних запитів може бути виконано на одному з тисячі серверів по
всьому світі.
При виконанні даної роботи було розроблено сервіс, який отримує
інформацію з терміналу та трансформує її в токен за допомогою
безсерверних обчислень. Даний сервіс виконує шифрування даних за
наступними алгоритмами:
1. DES-алгоритм симетричного шифрування
2. Алгоритм асимметричного шифрування RSA
3. Алгоритм симетричного шифрування AES
DES (англ. Data Encryption Standard) — це симетричний алгоритм
шифрування певних даних , стандарт шифрування прийнятий урядом США із
1976 до кінця 1990-х, з часом набув міжнародного застосування. Ще з часу
свого розроблення алгоритм викликав неоднозначні відгуки. Оскільки DES
містив засекречені елементи своєї структури, породжувались побоювання
щодо можливості контролю з боку Національного Агентства Безпеки США
(англ. National Security Agency). Алгоритм піддавався критиці за малу
довжину ключа, що, врешті, після бурхливих обговорень та контролю
академічної громадськості, не завадило йому стати загальноприйнятим
стандартом. DES дав поштовх сучасним уявленням про блочні алгоритми
шифрування та криптоаналіз.
Зараз DES вважається ненадійним в основному через малу довжину
ключа (56 біт) та розмір блоку (64 біти). У 1999 ключ DES було публічно
дешифровано за 22 години 15 хвилин. Вважається, що алгоритм достатньо
59
надійний для застосування у модифікації 3-DES, хоча існують розроблені
теоретичні атаки. DES поступово витісняється алгоритмом AES, що з 2002
року є стандартом США.
RSA (абревіатура від прізвищ Rivest, Shamir та Adleman) —
криптографічний алгоритм з відкритим ключем, що базується на
обчислювальній складності задачі факторизації великих цілих чисел. RSA
став першим алгоритмом такого типу, придатним і для шифрування, і для
цифрового підпису. Алгоритм застосовується до великої кількості
криптографічних застосунків.
Алгоритм RSA складається з 4 етапів: генерації ключів, шифрування,
розшифрування та розповсюдження ключів. Безпека алгоритму RSA
побудована на принципі складності факторизації цілих чисел. Алгоритм
використовує два ключі — відкритий (public) і секретний (private), разом
відкритий і відповідний йому секретний ключі утворюють пари ключів
(keypair). Відкритий ключ не потрібно зберігати в таємниці, він
використовується для шифрування даних. Якщо повідомлення було
зашифровано відкритим ключем, то розшифрувати його можна тільки
відповідним секретним ключем.
Advanced Encryption Standard (AES), також відомий, як Rijndael -
симетричний алгоритм блокового шифрування (розмір блоку 128 біт, ключ
128/192/256 біт), фіналіст конкурсу AES і прийнятий як американський
стандарт шифрування урядом США. Вибір був зроблений з розрахунком на
повсюдне використання і активний аналіз алгоритму, як це було з його
попередником, DES. За станом на 2006 рік AES є одним з найпоширеніших
алгоритмів симетричного шифрування.
Цей алгоритм є симетричним блоковим шифром, який працює з
блоками даних завдовжки 128 біт і використовує ключі завдовжки 128, 192 і
256 біт (версії AES-28; AES-192 і AES-256). Сам алгоритм може працювати і
з іншими довжинами блоків даних і ключів, але ця можливість до стандарту
не увійшла.
60
Алгоритми шифрування даних встановлюються банківською системою
та можуть відрізнятися.
Після шифрування даних за допомогою 3-х різних алгоритмів, дані
передаються до банку. Всі проміжні результати видаляються і система очікує
наступну інформацію від терміналу.
Отримавши токен, банк починає робити запити до платіжної системи,
для отримання інформації про банк, який випустив карту. При цьому банк
використовує тільки токен. Те, як отримати інформацію з цього токену, знає
як платіжна система, так і банк, який надав клієнту карту.
3.3 Забезпечення захисту інформації при роботі з створеною
системою
Захист інформації - це зв’язок між збором і розповсюдженням даних,
технологіями, суспільними очікуваннями щодо конфіденційності,
контекстуальними інформаційними нормами та правовими та політичними
питаннями, що їх оточують. Захист інформації також відомий як
конфіденційність даних або захист даних.
Конфіденційність даних є складним процесом, оскільки намагається
використовувати дані, одночасно захищаючи налаштування
конфіденційності та особисту інформацію людини. Сфери комп’ютерної
безпеки, безпеки даних та безпеки інформації розробляють і використовують
програмне забезпечення, апаратне забезпечення та людські ресурси для
вирішення цієї проблеми.
При роботі з банківською системою особливо важливо виконувати
рекомендації по захисту інформації, тому що на кону кошти людини чи
підприємства.
Для надійної передачі даних між терміналом і клієнтом
використовується надійний TCP-IP зʼєднання, яке дає можливість
61
зашифрувати дані, які відправляються між клієнтом і сервером за допомогою
протоколу HTTPS.
Стек протоколів TCP/IP, TCP/IP-модель - набір протоколів мережі
Інтернет. Назва походить від назви стрижневих протоколів мережі Інтернет -
IP (англ. Internet Protocol - «міжмережевий протокол») і TCP (англ.
Transmission Control Protocol - «протокол керування передаванням»).
Фактично це систематизований стек протоколів, що поділяється на чотири
рівні, які корелюються з еталонною моделлю OSI.
HTTPS (інші назви: HTTP over TLS, HTTP over SSL, і HTTP Secure) —
схема URI, що синтаксично ідентична http: схемі, яка зазвичай
використовується для доступу до ресурсів Інтернет. Використання https: URL
вказує, що протокол HTTP має використовуватися, але з іншим портом за
замовчуванням (443) і додатковим шаром шифрування/автентифікації між
HTTP і TCP. Ця схема була винайдена у компанії Netscape Communications
Corporation для забезпечення автентифікації та шифрування комунікацій і
широко використовується в Інтернеті у програмному забезпеченні, в якому
важлива безпека комунікацій, наприклад, у платіжних системах та
корпоративних логінах.
Оскільки HTTPS це фактично HTTP, який передається через SSL або
TLS, то майже всі його основні елементи шифруються: URL-запити,
включаючи шлях та назву ресурсу (сторінки), параметри запиту, заголовки та
кукі, які часто містять ідентифікаційні дані про користувача. Не
шифруються: назва або адреса хоста (вебсайту) та порт, оскільки вони
використовуються транспортним протоколом TCP/IP для встановлення
з'єднання. Шифрування гарантує помірний захист від підслуховування та від
нападу «людина посередині» (man-in-the-middle), за умови це коректних
налаштувань та підпису сертифікату авторизованим центром сертифікації.
TCP портом за замовчуванням для HTTPS є 443, для HTTP — 80.
62
Під час використання безсерверних обчислень також потрібно
враховувати безпеку даних. Але у цьому випадку, сервіс провайдер бере всі
ризики роботи з системою на себе.
Модель спільної відповідальності AWS стосується захисту даних в
AWS Lambda. Як описано в цій моделі, AWS відповідає за захист глобальної
інфраструктури, на якій працює вся хмара AWS. Ви несете відповідальність
за збереження контролю над своїм вмістом, розміщеним у цій
інфраструктурі. Цей вміст включає конфігурацію безпеки та завдання
керування для служб AWS, які ви використовуєте.
З метою захисту даних AWS рекомендує захистити облікові дані
облікового запису AWS і налаштувати індивідуальні облікові записи
користувачів за допомогою AWS Identity and Access Management (IAM).
Таким чином кожному користувачеві надаються лише дозволи, необхідні для
виконання його службових обов’язків. Також рекомендується захистити свої
дані такими способами:
- Використовувати багатофакторну автентифікацію (MFA) для кожного
облікового запису;
- Використовувати SSL/TLS для зв’язку з ресурсами AWS. Також
рекомендується TLS 1.2 або новішу версію;
- Налаштувати API та журнал активності користувачів за допомогою
AWS CloudTrail;
- Використовувати рішення шифрування AWS разом із усіма
елементами безпеки за замовчуванням у службах AWS;
- Використовувати розширені керовані служби безпеки, такі як Amazon
Macie, які допомагають виявляти та захищати особисті дані, які
зберігаються в Amazon S3;
- Якщо під час доступу до AWS через інтерфейс командного рядка або
API потрібні перевірені криптографічні модулі FIPS 140-2, потрібно
використовувати кінцеву точку FIPS.
63
Виходячи з усього вищеперечисленого більшість проблем безпеки буде
вирішено за допомогою рішень AWS, які вже входять в оплату послуг робити
безсерверних обчислень. Питання захисту передачі даних між системою та
банківськими рішеннями вирішено за допомогою SSL зʼєднання.
3.4 Технічні вимоги для роботи з системою
При роботі з створеною системою потрібно слідувати певним
технічним правилам (вимогам), які допоможуть адміністратору системи
правильно налаштувати програмне забезпечення для роботи в банківській
системі.
Технічні вимоги - стале поняття, яке використовується для опису
характеристик, яким повинен відповідати цифровий пристрій (ПК, гральна
консоль, мобільний телефон тощо) для коректної роботи певного
програмного забезпечення. Ці вимоги можуть описувати, як апаратне
забезпечення, так і програмне забезпечення (необхідні драйвери, операційна
система тощо). Розрізняють мінімальні та рекомендовані системні вимоги.
Якщо мінімальні системні вимоги показують, яка конфігурація системи
цілковито необхідна для запуску ПЗ, то рекомендовані системні вимоги
показують, яка конфігурація здатна забезпечити максимально комфортні
умови роботи ПЗ. Також інколи виділяють максимальні системні вимоги, при
яких забезпечується повна функціональність і можливість користуватись
усіма послугами потрібної програми. Оскільки серед поширених програмних
продуктів найбільш технічно вимогливими є відеоігри, то для них відомості
про системні вимоги є дуже бажаними.
Типи технічних вимог:
- Мінімальні технічні вимоги - це набір умов, необхідних для
можливості запуску та роботи програмного продукту. Однак,
наявність мінімальних системних вимог не скасовує можливість
64
запуску ПЗ на комп'ютерах, які за характеристиками слабші за
мінімальні;
- Рекомендовані системні вимоги - набір характеристик, що мають
на увазі оптимальну роботу більшої частини можливостей
продукту. Однак, навіть якщо комп'ютер і підходить під
рекомендовані системні вимоги, це не означає високої
продуктивності.
Для роботи з створеним продуктом необхідно використовувати один із
сервіс провайдерів, який підтримує мову програмування Node.js, а саме:
- AWS;
- Google Cloud;
- Microsoft Azure.
Рекомендованою системою буде AWS, тому що дана система
розроблялась під дану платформу та включає в себе інструкцію користувача,
в якій описаний детальний запуск програмного продукту самі під цю
платформу.
Для коректної роботи програми слід використовувати Node.js не нижче
14-ї версії, так як використання більше старіших версій продукту не може
гарантувати правильність роботи програми.
Для доступу до бази даних слід використовувати систему управління
базою даних (СУБД) MySQL версії 8 або новішої. Останні версії СУБД
включають в себе оновлення безпеки користування базою даних та
аккаунтами користувачів, що дозволяє знизити ризик втрати даних через
неправомірні дії 3-х сторін.
Також рекомендується використовувати стандарт передачі даних
HTTP(S) 2.0. HTTP/2 — друга, На відміну від HTTP 1.1 HTTP/2 бінарний.
Також зазнали зміни способи розбиття даних на фрагменти і їх
транспортування між сервером і клієнтом. В HTTP/2 сервер може відіслати
дані, які ще не були запитані клієнтом, але знадобляться клієнту для
65
конкретної побудови сторінок. Запропонованим наступником HTTP/2 є
протокол HTTP/3, означений у RFC 9000.
3.5 Оцінка ефективності методів застосування безсерверних
обчислень
Основною метою дослідження даної роботи була розробка системи на
базі безсерверних обчислень, яка повинна покращити показники
відмовостійкості та при цьому не зменшити показники швидкодії в існуючих
системах.
Відмовостійкість - це властивість, яка дозволяє системі продовжувати
функціонувати в разі виходу з ладу одного або декількох її компонентів.
Швидкодія - це кількісна характеристика швидкості виконання певних
операцій комп'ютером (обчислювальним пристроєм). Найчастіше
обчислювальна потужність вимірюється в Флопс (кількості операцій з числа
з рухомою комою в секунду), а також похідними від цієї величини.
Для порівняння характеристик ефективності розробленої системи на
базі методів застосування безсерпених обчислень потрібно порівняти
наступні рішення:
- Використання безсерверних систем
- Використання хмарних систем
- Використання серверів, які знаходяться на базі підприємства або
установи.
Таблиця 3.1 — Порівняння різних видів обчислень
Безсерверні Хмарні Сервер
Кількість серверів 100-1000 1-10 1-10
Паралельні обчислення 100-1000 4-40 4-40
Швидкодія 1.28 секунд 1.26 секунд 1.3 секунд
Відмовостійкість >99.999% >99.80 >96.00
66
Розглянемо отримані результати в різних видах обчислень. Для
порівняння хмарних обчислень та обчислень на локальному сервері
використовувалися схожі за конфігурацією системи на базі процесора Intel
Core i5 7400. При цьому при порівнянні безсерверних технологій цією
інформацією можна нехтувати, так як система AWS автоматично підбирає
потрібний сервер.
Для отримання інформації про швидкодію використовувалося
розроблене програмне забезпечення та порівнюється час виконання
розробленого ПО в однопоточному режимі.
Для отримання інформації по відмовостійкості системи було
використано публічну інформацію з мережі UptimeRobot, яка може надати
більш актуальну інформацію по різним видам обчислень.
Як видно з таблиці 3.1 розроблене програмне забезпечення працює
майже однаково швидко на різних видах обчислення, при цьому обраний
метод реалізації системи значно ефективніший при великій кількості
обчислень. Через те, що безсерверні обчислення не зав'язані на фізичних
серверах, у даного рішення є велика кількість потоків, які можна
використовувати для обробки запитів. Також відмовостійкість системи
показує, що таке рішення повністю задовольняє поставлену задачу.
Через велику кількість серверів, які теоретично можуть обробити
запит, система стає повністю відмовостійкою, так як у любому випадку
знайдеться сервер, який матиме змогу обробити даний запит.
З отриманих вище результатів можна зробити висновок, що розроблена
система та використані при цьому методи реалізації такої системи повністю
задовольняють умову даного дослідження та поставлене завдання було
виконане.
67
3.6 Висновки до розділу 3
У третьому розділі для реалізації системи було створено модулі, що є
компонентами, з яких складається система, а саме: це програмне
забезпечення банківського POS терміналу; модуль отримання інформації від
терміналу, модуль обробки транзакції, модуль передачі токену між системою
та банком.
У розділі здійснено опис функцій, які будуть застосовані в системі, та
вибір алгоритмів шифрування даних.
Для забезпечення коректної роботи системи були визначено та
встановлені вимоги, яких потрібно дотримуватися, і які допоможуть
адміністратору системи правильно налаштувати програмне забезпечення для
роботи в банківській системі.
У розділі проведено оцінку ефективності методів застосування
безсервених обчислень.
68
ВИСНОВКИ
У результаті виконання кваліфікаційної роботи було виконано аналіз,
збір та огляд існуючих методів безсерверних обчислень та було
запропоновано дослідити можливість використання безсервених обчислень
при роботі з високонавантаженим банківським програмним забезпеченням, а
саме при токенізації транзакцій. На підготовчому етапі було проведено аналіз
предметноі ̈ галузі та актуальність задач дослідження.
Після порівняння вже існуючих методів, які схожі за тематикою, була
сформована постановка задач та обрано модулі, з яких буде складатися
система, а саме:
● Програмне забезпечення банківського POS терміналу.
● Модуль отримання інформації від терміналу.
● Модуль обробки транзакції.
У роботі реалізовано алгоритм шифрування, як сервіс, який отримує
інформацію з терміналу та трансформує її в токен за допомогою
безсерверних обчислень для досягнення необхідного рівня захисту даних.
Для виконання поставленої задачі нами обрано мову програмування та
базу даних. Проаналізувавши переваги та недоліки, а також рейтинг мов
програмування за 2022 рік, наш вибір був зупинений на Node.js, що має
досить простий синтаксис та дає нам можливість створювати максимально
прості скрипти при використанні безсерверних рішень. А управління базою
даних здійснюватися буде на основі MySQL. Основним вибором для
реалізації системи є вибір технології на основі якої буде реалізований метод
безсервені обчислення. Для цього нами запропоновано рішення AWS, що дає
можливість використовувати безсервені обчислення за допомогою продукту
Amazon Lambda. У роботі описано функції системи та принцип їх роботи,
розроблені рекомендації для реалізації захисту даних. Детально описали
вимоги, які допоможуть адміністратору системи правильно налаштувати
69
програмне забезпечення для роботи в банківській системі.
Для порівняння характеристик ефективності розробленої системи на
базі методів застосування безсерверних обчислень здійснено порівнянння
наступних рішень:
 Використання безсерверних систем.
 Використання хмарних систем.
 Використання серверів, які знаходяться на базі підприємства або
установи.
З отриманих вище результатів можна зробити висновок, що розроблена
система та використані при цьому методи реалізації такої системи повністю
задовольняють умову даного дослідження та поставлене завдання було
виконане повністю.
70
ПЕРЕЛІК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ
Serverless – безсерверні обчислення, модель хмарних обчислень для яких
платформа динамічно керує виділенням машинних ресурсів.
FaaS – (Function as a Service) – у даніи ̆ роботі синонім Serverless.
BaaS – (Backend as a Service) – модель для надання розробникам веб-
додатків і мобільних додатків способу пов’язати своі ̈ додатки з
резервним хмарним сховищем та API, а також надає такі функціі ̈,
як управління користувачами, push-сповіщення та інтеграція із
службами соціальних мереж.
IaaS – (Infrastructure as a service) – це модель обслуговування, в межах
якої споживачу надається можливість керувати засобами обробки
та збереження, комунікаційними мережами, та іншими
фундаментальними обчислювальними ресурсами, на базі яких
споживач може розгортати та виконувати довільне програмне
забезпечення, до складу якого можуть входити операційні
системи та прикладні програми.
PaaS – (Platform as a Service) – модель надання хмарних обчислень, при
якіи ̆ споживач отримує доступ до використання інформаціи ̆но-
технологічних платформ: операціи ̆них систем,систем управління
базами даних,зв'язного програмного забезпечення, засобів
розробкиі тестуваннярозміщених у хмарних проваид̆ ерах.
AWS – (Amazon Web Services) – є дочірньою компанією Amazon.com,
що надає платформу хмарних обчислень в оренду приватним
особам, компаніям та урядам на основі платної підписки.
API – (Application Programming Interface) – набір визначень
підпрограм, протоколів взаємодіі ̈ та засобів для створення
програмного забезпечення.
71
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Demchenko Y. Defining inter-cloud architecture for interoperability and
integration / Y. Demchenko, C. Ngo, M.X. Makkes, R. Strijkers, C. de Laat
// Proceeding of the 3rd International Conference on Cloud Computing,
GRIDs and Virtualization, Nice, France,. - pp. 174-180
2. Malik N.A. Threat modeling in pervasive computing paradigm / N.A.
Malik, M.Y. Javed, U. Mahmud // Proceedings of the Mobility and
Security, New Technologies, Tangier, November 5-7, 2008. - pp. 1-5
3. McRee R. PTA: Practical threat analysis / R. McRee // Proceedings
of the Information Systems Security Association, London, September 1516,
2008. - pp. 37-40
4. Jehangir A. Securing inter-cluster communication in personal networks / A.
Jehangir // Proceedings o f the 4th Annual Internationa
5. Conference on Mobile and Ubiquitous Systems: Networking and Services,
Philadelphia, August 6-10, 2007. - pp. 1-6
6. Bertino E. L. Security for Web Services and Service-Oriented Architectures
/ E. L. Bertino // Proceedings of the 2th Annual International Conference on
Information Security, New York, USA., September 2-7, 2012 . - pp. 35-69
7. Soares L.F.B. Secure user authentication in cloud computing management
interfaces / L.F.B. Soares // Proceedings of the IEEE 32nd International
Performance Computing and Communications Conference, San Diego, CA,
December 6-8, 2013. - pp. 1-2.
8. Hamza Y.A. Cloud computing security: Abuse and nefarious use of cloud
computing / Y.A. Hamza - Int. J. Comput. Eng. Res, 2013 - 53 p.
72
9. Fuentes V.T. Enforcing database security on cloud using a trusted third party
based model / V.T. Fuentes // 2438, Theses and Dissertations,
ScholarWorks@UARK, 2017. - 50 p.
10.The tokenization of assets is disrupting the financial industry. Are you
ready? [Електроннии ̆ ресурс] / P.Laurent, T. Chollet, M. Burke, T. Seers. –
2018. – The Tokenization of Assets is Disrupting the Financial Industry. Are
you Ready?
11.What is AWS Lambda? [Електроннии ̆ ресурс]/- What is AWS Lambda? -
AWS Lambda
12.“Introducing AWS Lambda”. Available [Електроннии ̆ ресурс] /
from:https://aws.amazon.com/ru/about-aws/whats-
new/2014/11/13/introducing-aws-lambda.–Retrieved March 1. 2019.
13.Google Cloud Functions. [Електроннии ̆ ресурс] // Режим доступу: Cloud
Functions.
14.Azure Functions triggers and bindings concepts. In Microsoft Azure
documentation.[Електроннии ̆ ресурс] // Режим доступу: Triggers and
bindings in Azure Functions | Microsoft Learn.
15.Eizinger T. API Design in Distributed Systems. A Comparison between
GraphQL and REST. [Електроннии ̆ ресурс] / Thomas Eizinger // Master
thesis. University of Applied Sciences Technikum Wien. – 2017. – Режим
доступу до ресурсу: https://eizinger.io/assets/Master-Thesis.pdf.
16.R. T. Fielding, Architectural Styles and the Design of Network-based
Software Architectures // University of California Irvine – 2000 – ISBN : 0-
599-87118-0.
17.D. E. Perry and A. L. Wolf, Foundations for the Study of Software
Architecture [Електроннии ̆ ресурс] // ACM SIGSOFT Software
Engineering Notes, vol. 17, no. 4 – 1992 – ст. 40-52 – Режим доступу:
https://doi.org/10.1145/141874.141884.
73
18.Baldini, I., Castro, P., Chang, K., Cheng, P., Fink, S., Ishakian, V. & Suter,
P “Serverless computing: Current trends and open problems.” In Research
Advances in Cloud Computing. Publ.Springer, Singapore: 2017.p.1–20.
19.Geng, X., Ma, O., Pei, Y., Xu, Z., Zeng, W. & Zou, J. “Research on Early
Warning System of Pow-er Network Overloading Under Serverless
Architecture”.In 2018 2-nd IEEE Conference on Energy Internet and Energy
System Integration (EI2). October2018.p. 1–6.IEEE.
20.Rosenbaum, S. “Serverless computing in Azure with. NET”. Packt
Publishing.2017. 468 p.
ДОДАТОК А
«ЗАТВЕРДЖУЮ»
Завідувач кафедри ІБ та КІ
д.т.н., професор Володимир РУДНИЦЬКИЙ
___________________
«___» _____________ 2022р.
Дослідження методів застосування безсерверних обчислень для
токенізації банківських даних
Специфікація
482.ЧДТУ.22291-01
Листів 2
Розробник _______________ Орина КАШУБА
Керівник _______________ Віра БАБЕНКО
Черкаси 2022
2
482.ЧДТУ.22291-01
Позначення Найменування Примітка
Документація
482.ЧДТУ.22291-01 12 01 Текст програми
482.ЧДТУ.22291-01 34 01 Інструкція користувача
ДОДАТОК Б
Дослідження методів застосування безсерверних обчислень для
токенізації банківських даних
Текс програми
482.ЧДТУ.22291-01 12 01
Листів 13
Розробник _______________ Орина КАШУБА
Черкаси 2022
2
482.ЧДТУ.22291-01 12 01
@Injectable()
export class TxnService {
constructor(
@InjectRepository(TxnRepository)
private txnRepository: TxnRepository,
private healthCheckerService: HealthCheckerService,
@Inject(forwardRef(() => ActionService))
private actionService: ActionService
) {}
async findTxnsByRelatedEntity(
userUuid: string,
locationUuid: string,
note: string
): Promise<Txn[]> {
const txnsWithEntity = await this.txnRepository
.createQueryBuilder('txn')
.leftJoinAndSelect('txn.location', 'location')
.leftJoinAndSelect('txn.users', 'user');
if (userUuid) {
txnsWithEntity.andWhere('user.uuid = :userUuid', {
userUuid: userUuid
});
}
if (locationUuid) {
txnsWithEntity.andWhere('location.uuid = :locationUuid', {
locationUuid: locationUuid
});
}
if (note) {
txnsWithEntity.andWhere('txn.note like :note', {
note: `%${note}%`
});
}
return await txnsWithEntity.getMany();
}
3
482.ЧДТУ.22291-01 12 01
async paginate(
options: IPaginationOptions<IPaginationMeta>,
search?: string,
locationId?: string,
userId?: string
): Promise<Pagination<Txn>> {
const validUserUuid = userId ? userId.trim() : '';
const validNote = search ? search.trim() : '';
const validLocationUuid = locationId ? locationId.trim() : '';
const filteredTxns = await this.findTxnsByRelatedEntity(
validUserUuid,
validLocationUuid,
validNote
);
const txnsWithPagination = await paginate<Txn>(
this.txnRepository,
filteredTxns.length ? options : { page: 0, limit: 0 },
{
where: filteredTxns
.map((txn) => txn.uuid)
.map((uuid) => ({ uuid: uuid })),
relations: ['location'],
order: { id: 'DESC' }
}
);
txnsWithPagination.meta.totalPages
? txnsWithPagination.meta.totalPages
: (txnsWithPagination.meta.totalPages = 0);
return txnsWithPagination;
}
async getTxnByNote(
note: string
): Promise<TxnInterface> {
return await this.txnRepository.findByNote(note);
}
4
482.ЧДТУ.22291-01 12 01
async getTxnByUuid(id: string): Promise<Txn> {
const txn = await this.txnRepository.findByUuid(id);
if (!txn) {
throw new NotFoundException('Txn not found');
}
return txn;
}
getTxnWithRelations(uuid: string, relations: string[]): Promise<Txn> {
const txn = this.txnRepository.findOne({
where: { uuid },
relations
});
if (!txn) {
throw new NotFoundException('Txn not found');
}
return txn;
}
async createTxn(
txn: Partial<TxnInterface>
): Promise<TxnInterface | never> {
const existTxn = await this.txnRepository.findByNote(
txn.note
);
if (existTxn) {
throw new ConflictException('Txn already exists');
}
return this.txnRepository.save({
uuid: uuid(),
note: txn.note,
ip: txn.ip,
location: txn.location
});
}
5
482.ЧДТУ.22291-01 12 01
async updateTxn(
id: string,
txn: Partial<TxnInterface>
): Promise<TxnInterface | undefined> {
const existTxn = await this.txnRepository.findByNote(
txn.note
);
if (existTxn && existTxn.uuid !== id) {
throw new ConflictException('Txn already exists');
}
const result = await this.txnRepository.update({ uuid: id }, txn);
if (!result.affected) {
throw new NotFoundException('Txn not found');
}
return this.txnRepository.findByUuid(id);
}
async deleteTxn(id: string): Promise<void> {
const txn = await this.txnRepository.findTxnUsersAndSubscribersByUuid(
id
);
if (!txn) {
throw new NotFoundException('Txn not found');
}
if (txn.users.length > 0 || txn.subscribers.length > 0) {
throw new ConflictException('Txn user or subscriber exist');
}
const where: FindConditions<Partial<TxnInterface>> = { uuid: id };
await this.txnRepository.update(where, {
deletedToken: uuid(),
deletedAt: new Date()
});
6
482.ЧДТУ.22291-01 12 01
}
async getLastStatus(
txn: Partial<TxnInterface>
): Promise<TxnStatusEnum | null> {
const lastActionType = await this.actionService.getLastTypeOfTypes(
txn.id,
[
ActionMessagesEnum.REFUND,
ActionMessagesEnum.DECLINED,
ActionMessagesEnum.CAPTURE,
ActionMessagesEnum.AUTH,
ActionMessagesEnum.VOID
]
);
switch (lastActionType) {
case ActionMessagesEnum.CAPTURE:
return TxnStatusEnum.CAPTURE;
case ActionMessagesEnum.AUTH:
return TxnStatusEnum.AUTH;
case ActionMessagesEnum.VOID:
return TxnStatusEnum.VOID;
default:
return null;
}
}
async checkStatusTxns() {
const txnsList = await this.txnRepository.findInactiveTxns();
for (const txn of txnsList) {
const getHealthStatus = await this.healthCheckerService.checkTxnHealth(
txn.ip
);
txn.isOnLine = false;
this.updateTxn(txn.uuid, { isOnLine: false });
const action = {
7
482.ЧДТУ.22291-01 12 01
type: ActionMessagesEnum[getHealthStatus],
txn: txn
};
await this.actionService.create(action);
}
}
}
export class DuplicateEntryException extends HttpException {
constructor(message: string) {
const indexKey = message.split(' ').pop();
const fieldname = indexKey
.slice(1, -1)
.split('_')
.pop();
super(
{
statusCode: 409,
error: 'Conflict',
message: 'Duplicate Entity',
field: fieldname
},
HttpStatus.CONFLICT
);
}
}
export class ValidationPipe implements PipeTransform {
async transform(value, { metatype }: ArgumentMetadata) {
if (!metatype || !this.toValidate(metatype)) {
return value;
}
const object = plainToClass(metatype, value);
const errors = await validate(object);
if (errors.length > 0) {
const messages: string[] = this.getMessages(errors);
throw new HttpException(
{
status: HttpStatus.UNPROCESSABLE_ENTITY,
8
482.ЧДТУ.22291-01 12 01
error: 'Unprocessable Entity',
message: messages.length === 1 ? messages[0] : undefined,
messages: messages.length > 1 ? this.getMessages(errors) : undefined
},
HttpStatus.UNPROCESSABLE_ENTITY
);
}
return value;
}
private getMessages(errors: ValidationError[] = []): string[] {
let messages: string[] = [];
errors.forEach((error) => {
messages = messages.concat(Object.values(error.constraints));
});
return messages;
}
private toValidate(metaType): boolean {
const types = [String, Boolean, Number, Array, Object];
return !types.includes(metaType);
}
}
export class RemoteCommandService {
constructor(
@InjectRepository(RemoteCommandRepository)
private remoteCommandRepository: RemoteCommandRepository
) {}
async paginate(
options: IPaginationOptions<IPaginationMeta>,
deviceId
): Promise<Pagination<RemoteCommand>> {
return paginate<RemoteCommand>(this.remoteCommandRepository, options, {
where: {
device: deviceId
},
order: { id: 'DESC' }
9
482.ЧДТУ.22291-01 12 01
});
}
async createCommand(
remoteCommand: Partial<RemoteCommandInterface>
): Promise<RemoteCommandInterface> {
return this.remoteCommandRepository.save({
uuid: uuidv4(),
command: remoteCommand.command,
device: remoteCommand.device
});
}
async deleteCommand(uuid: string): Promise<void> {
const command = await this.remoteCommandRepository.findByUuid(uuid);
if (!command) {
throw new NotFoundException('Command not found');
}
this.remoteCommandRepository.delete(command);
}
async removeRemoteCommands(deviceId: number):
Promise<RemoteCommand[]> {
const commands = await this.remoteCommandRepository.findByDeviceId(
deviceId
);
this.remoteCommandRepository.remove(commands);
return commands;
}
async hasRemoteCommands(deviceId: number): Promise<boolean> {
const commandsCount = await
this.remoteCommandRepository.countByDeviceId(
deviceId
);
return commandsCount > 0;
}
10
482.ЧДТУ.22291-01 12 01
}
export class WaitingTxnService {
constructor(
@InjectRepository(WaitingTxnRepository)
private waitingTxnRepository: WaitingTxnRepository
) {}
async paginate(
options: IPaginationOptions<IPaginationMeta>,
showAll: boolean
): Promise<Pagination<WaitingTxn>> {
return paginate<WaitingTxn>(
this.waitingTxnRepository,
options,
showAll
? {
order: { id: 'DESC' }
}
: {
where: {
isRejected: false
},
order: { id: 'DESC' }
}
);
}
getTxnById(id: string): Promise<WaitingTxn> {
return this.waitingTxnRepository.findById(id);
}
async createTxn(
txn: Partial<WaitingTxnInterface>
): Promise<WaitingTxnInterface> {
const existingTxn = await this.waitingTxnRepository.findById(
txn.id
);
if (existingTxn) {
throw new ConflictException('Txn already exists');
11
482.ЧДТУ.22291-01 12 01
}
return this.waitingTxnRepository.save({
uuid: uuid(),
id: txn.id,
isRejected: false
});
}
async updateTxn(
uuid: string,
txn: Partial<WaitingTxnInterface>
): Promise<WaitingTxnInterface> {
const where: FindConditions<Partial<WaitingTxnInterface>> = { uuid };
const updatedTxn = await this.waitingTxnRepository.findByUuid(uuid);
if (!updatedTxn) {
throw new NotFoundException('Txn not found');
}
await this.waitingTxnRepository.update(where, {
isRejected: txn.isRejected
});
return this.waitingTxnRepository.findByUuid(uuid);
}
async deleteTxn(id: string): Promise<void> {
const txn = await this.waitingTxnRepository.findById(
id
);
if (!txn) {
throw new NotFoundException('Txn not found');
}
await this.waitingTxnRepository.delete({ id });
}
}
12
482.ЧДТУ.22291-01 12 01
@Injectable()
export class AuthService {
private saltOrRounds: string;
constructor(
@Inject(Logger) private readonly logger: LoggerService,
private jwtService: JwtService,
private configService: ConfigService
) {}
onModuleInit() {
this.saltOrRounds = this.configService.get<string>('BCRYPT_SECRET_KEY');
}
async getHash(password: string): Promise<string> {
return await bcrypt.hash(password, this.saltOrRounds);
}
getTokenUser(jwtPayloadUser: JwtPayloadUser): string {
return this.jwtService.sign(jwtPayloadUser, { expiresIn: '3600s' });
}
getAccessTokenDevice(jwtPayloadDevice: JwtPayloadDevice): string {
return this.jwtService.sign(jwtPayloadDevice, {
secret: this.configService.get('JWT_DEVICE_SECRET_KEY_ACCESS'),
expiresIn: '3600s'
});
}
getRefreshTokenDevice(jwtPayloadDevice: JwtPayloadDevice): string {
return this.jwtService.sign(jwtPayloadDevice, {
secret: this.configService.get('JWT_DEVICE_SECRET_KEY_REFRESH'),
expiresIn: '86400s'
});
}
async validateRefreshToken(refreshToken: string): Promise<JwtPayloadDevice>
{
let result;
try {
13
482.ЧДТУ.22291-01 12 01
result = await this.jwtService.verify(refreshToken, {
secret: this.configService.get('JWT_DEVICE_SECRET_KEY_REFRESH')
});
} catch (error) {
this.logger.error(error);
}
return result;
}
}
ДОДАТОК В
Дослідження методів застосування безсерверних обчислень для
токенізації банківських даних
Інструкція користувача
482.ЧДТУ.22291-01 34 01
Листів 5
Розробник _______________ Орина КАШУБА
Черкаси 2022
2
482.ЧДТУ.22291-01 34 01
Для правильної роботи програми адміністратору системи потрібно
виконати наступні дії:
- Налаштувати AWS Lambda функції для роботи з розробленим
програмним забезпеченням;
- Створити базу даних в AWS RDS та створити потрібні таблиці в даній
базі даних;
- Налаштувати банківський термінал для роботи з створеною системою
по токенізації банківської інформації.
Щоб створити нову Lambda функцію в системі AWS потрібно відкрити
AWS Dashboard та в меню користувача зайти в розділ Lambda. У даному
розділі у адміністратора буде можливість створити нову функцію
(рисунок В.1).
Рисунок В.1 – Створення нової функції
3
482.ЧДТУ.22291-01 34 01
При створенні функції рекомендовано обрати Runtime мову виконання
Node.js версії 14. Також можна обирати й більш нові версії. Слід
враховувати, що система тестувалася на 14-й версії і немає гарантії, що всі
функції системи будуть працювати правильно на більш нових версіях.
Розроблена система працює на архітектурі x86-64, так як її можна
використовувати також і на звичайних серверах.
Після створення функції потрібно змінити налаштування за
замовчуванням для RAM та таймауту (рисунок В.2).
Рисунок В.2 – Налаштування Lambda функції
4
482.ЧДТУ.22291-01 34 01
Для роботи з розробленим програмним забезпеченням потрібно
створити 2 Lambda функції, які будуть виконувати наступні дії:
- Отримувати транзакцію від терміналу та зберігати інформацію до бази;
- Виконувати токенізацію для отриманої транзакції.
Для того, щоб створити нову базу даних в системі AWS потрібно
знайти розділ RDS в меню користувача та натиснути кнопку “Створити”
(рисунок В.3).
Рисунок В.3 – Створення бази даних
5
482.ЧДТУ.22291-01 34 01
При створенні бази даних потрібно вибрати MySQL версії 8 або вище.
Розроблена система не тестувалася на версіях, менших за вказану у вимогах.
В коді програми обовʼязково потрібно вказати логін і пароль до бази
даних. Дані налаштування знаходяться в файлі .env розробленої програми
(рисунок В.4).
Рисунок В.4 – Налаштування доступу до бази
Після завершення налаштувань платформи AWS потрібно звернутися
до банку, для якого розроблене дане рішення для налаштування доступу з
терміналу до розробленої системи.
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
