CC BY
29
DOI: 10.15587/2312-8372.2018.134981
ДОСЛ1ДЖЕННЯ МОДЕЛЕЙ РОЗГОРТАННЯ ХМАРНИХ ТЕХНОЛОГ1Й ДЛЯ БАНКШСЬКИХ 1НФОРМАЦ1ЙНИХ СИСТЕМ
Баглай Р. О.
1. Вступ
В силу особливостей дiяльностi, регуляторних вимог та побудови 6i3Hec процешв системнi ушверсальш банки оперують великими обсягами даних та мають комплексш iнформацiйнi технологii (надалi IT) ландшафту. Застосування хмарних технологiй дозволяе значно тдвищити ефективнiсть IT в цтому. Крiм цього, пiдвишyеться вiдомовостiйкiсть, гнучюсть та масштабованiсть банкiвських IT, а також показник швидкостi виводу продукпв на ринок (вiд англ. time to market, надаш ТТМ). Разом i3 тим iснyють значнi регуляторш обмеження щодо перемiшення даних до хмари. В ходi дослiдження буде обгрунтовано можливiсть отримання цих переваг хмарних технологiй без порушення регуляторних вимог.
Тому актуальним е дослщження моцелi розгортання Public Cloud, адже така модель дозволяе отримати найкрашд цiновi пропозицii щодо вартостi сервюу, оскiльки датацентри постачальникiв розташовуються у регюнах з мiнiмальною вартiстю ресуршв.
2. Об'ект досл1дження та його технолопчний аудит
Об'ектом дослгдження е банювсью iнформацiйнi технологii.
В контекст Gвроiнтеграцii yкраiнськi системнi банки мають бути готовими до радикальноi модершзацп клiентських, операцiйних та звiтних систем. Впровадження Свропейських регуляторних вимог е складною проблемою для служб IT будь-якого украшського банку. Виршення проблеми лежить в плошинi застосування новптах IT технологiй, зокрема побудови арх^ектури IT банку, якi базуються на хмарних сервюах.
Основна цiннiсть банку - це даш. Володiння киентськими даними накладае цiлy низку регуляторних обмежень, таких як Ушфшоване положення щодо захисту даних (англ. General Data Protection Regulation, надал GDPR), та шших. Це породжуе юридичш та операцiйнi ризики, пов'язанi з тим, що банк у будь-який момент часу повинен контролювати киентськ данi та забезпечувати !'х конфщенцшнють, цiлiснiсть та достyпнiсть. Автор вважае, що саме з цим пов'язано бшьшють регуляторних обмежень та заборон щодо переходу на хмарш технологи в рiзних правових системах.
3. Мета та задач1 досл1дження
Метою даног роботи е дослщження перспективних напрямiв застосування хмарних технологш на рiзних рiвнях IT ландшафту для банювських IC, для скорочення витрат та тдвищення ефективностi пiдтримки IT для бiзнес-процесiв банку.
Для досягнення поставлено!' мети необхщно виконати таю задача
1. власти B^0K0piBHeBy apxiTeKTypHy схему шформацшних технологiй ландшафту банку.
2. Згрупувати системи, визначити !х фyнкцiональне призначення, проанаизувати кiлькiснi та якiснi показники.
4. Дослщження iснуючих р1шень проблеми
Проблеми застосування хмарних технологш в рiзних сощально-економiчних сферах дослщжувались у роботi [1].
Серед основних напрямкiв вирiшення проблеми застосування моделей розгортання Public Cloud та Hybrid Cloud, виявлених в ресурсах свггово! науково! перiодики, можуть бути видтеш пyблiкацii [2-4]. У цих публжащях враховано специфiкy забезпечення захисту шформацп, що становить банкiвськy таемницю, але не мiститься пропозицiй щодо деперсонашзацп даних. Зокрема, робота [5] присвячена виршенню проблеми конфiденцiйностi даних шляхом шифрування, але це накладае ютотш обмеження щодо обробки даних.
Пращ шших наyковцiв [5-7] не враховують в повнiй мiрi специфiкy забезпечення безпеки 1Т для банкiвських установ.
Роботи [8-10] мютять пропозицii щодо використання хмарних технологш, але не мютять комплексного анаизу щодо архггектури банювських iнформацiйних систем (надалi 1С) на основi хмарних технологiй з урахуванням регуляторних обмежень.
Таким чином, результати анашзу дозволяють зробити висновок про те, що впровадження хмарних технологiй в 1Т ландшафт банкiв Украши, мае вщповщати регуляторним вимогам. Зокрема, нормативно-правовим актам Нащонального банку Украши [11], Свропейського центрального банку [12], Базельського комггету з банкiвського нагляду, Ради стандарт безпеки платiжних карт, та шших установ. Таю особливостi зумовлюють специфiкy побудови архiтектyри 1Т та оргашзацп системи безпеки, що визначае необхщнють вивчення механiзмiв забезпечення операцшно! ефективностi та захисту вiд загроз безпеки 1Т для банкiв.
5. Методи дослщжень
При дослiдженнi були використаш настyпнi наyковi методи:
- графiчний метод - при вивчеш архiтектyрних схем 1С;
- метод класифжацп систем - при визначенш прiоритетних напрямiв застосування рiзних моделей розгортань хмарних технологш;
- метод кшькюного анаизу - при вивченш нефyнкцiональних вимог до банкiвських 1С;
- метод синтезу - при формуванш вибiрки систем, якi несуть найбшьше навантаження i е критичними щодо безперервност бiзнесy.
6. Результати дослщження
Зпдно роз'яснень Нацiонального Банку Украши (надалi НБУ), застосування хмарних технологш в дiяльностi банкiвських установ Украши можливе за умови розта ^ва ня даних на серверах, що знаходяться на територii Украши. Це
вщповщае моделi розгортання Private Cloud. Розглянемо моделi розгортань On-Premise, Private Cloud, Public Cloud. Hybrid Cloud бшьш докладно.
Public Cloud. За тако! моделi розгортань постачальник хмарних сервiсiв, наприклад, Amazon Web Services (AWS) або Microsoft Azure, володiе обчислювальними ресурсами та пiдтримyе !х, надаючи доступ клiентам через мережу штернет. Ресурси спiльно використовуються та розподшяються мiж всiма користувачами. Така модель також вщома як орендне середовище багатьох користyвачiв (англ. multi-tenant environment). За рахунок економп масштабiв розташування дата центрiв в мюцях з мiнiмальною вартiстю ресyрсiв, постачальники хмарних сервiсiв мають змогу надавати ресурси за набагато нижчою цшою, нiж вартiсть пiдтримки власно! шфраструктури.
Private Cloud. За тако! моделi розгортань банк створюе та тдтримуе хмарну iнфрастрyктyрy у власному дата цен^ або на орендованих потужностях. Основна вiдмiннiсть вiд Public Cloud полягае в тому, що банк - це единий користувач, який володiе i використовуе ресурси приватно! хмари. Така модель розгортань вщома як орендне середовище одного користувача (вщ англ. single-tenant environment). Private Cloud не мае таких переваг щодо економп витрат як Public Cloud, але все ж дозволяе використовувати функцюнальш переваги хмарних сервiсiв для тдвищення ефективност бiзнес-процесiв банку.
Hybrid Cloud. За пбридно! моделi розгортань поеднуються хмарш технологii. Public та Private Cloud для отримання переваг обох моделей. Автор вважае, що саме така модель дозволить максимально убезпечити даш, водночас отримавши переваги економiчноi ефективност Public Cloud.
On-Premise - модель розгортання, при якш шформацшш активи (данi, програмне забезпечення, процеси), розмiщyються на власних фiзичних серверах банку. При цш моделi банк несе максимальнi витрати - капiтальнi iнвестицii, операцiйнi витрати на шдтримку та комyнальнi платеж^ амортизацiя. Така модельне передбачае отримання функцюнальних переваг хмарних сервiсiв.
Розглянемо основш типи архiтектyрних ландшафтiв банювських 1С:
Монолгтна архитектура - комплексне ршення 1Т, що включае в себе фронт енд, автоматизовану банювську систему, головну бухгалтерську книгу, тдсистеми налаштування банкiвських продyктiв та сховище даних вщ одного постачальника. Зазвичай призводить до тотально! залежност вщ постачальника (вiд англ. Vendor lock in situation) зменшення гнучкост у задоволенш потреб банку та попршення ТТМ.
Модульна архтектура - ршення 1Т, що базуеться на великш кiлькостi програмних модyлiв вiд рiзних постачальникiв та внyтрiшнiх розробникiв, яю iнтегрованi мiж собою через корпоративш шини даних (вiд. англ. Enterprise serial bus) з дотриманням принцитв сервiсно-орiентованоi архiтектyри (вiд англ. Service Oriented Architecture). Недолжом тако! архггектури зазвичай е високi витрати ресуршв для пiдтримки та розвитку складного штегрованого ландшафту 1Т, що сповшьнюе ТТМ. Крiм того це породжуе необхщшсть створення та розвитку внутршшх центрiв компетенцii, якi здiйснюють змши на рiвнi корпоративно! шини даних.
Мжросервгсна архгтектура базуеться на мшро сервюах, що використовують поди, якi породжуються програмними додатками, перетворюючи 1х в процеси, що забезпечують виконання сценарпв бiзнес логiки, шляхом застосування стандартизованих меxанiзмiв та API функцiй. Така арxiтектура е найбiльш iнновацiйною, адже дозволяе в повнш мiрi використати потенщал хмарних теxнологiй, значно зменшуючи показник ТТМ для банкiвськиx установ.
Запропоновано розглянути умовний банк, в арх^ектурному ландшафт якого поеднуються другий i третiй тип арxiтектури. З метою визначення кшьюсних та яюсних параметрiв, якi будуть взятi за основу для визначення функщональних та нефункщональних вимог до банкiвськиx 1С пропонуеться наступний сценарш:
- банк мае лщензш НБУ та здшснюе дiяльнiсть у всix клiентськиx сегментах бiзнесу - обслуговування фiзичниx та юридичних осiб, мiжнародниx корпорацiй, державного сектору, надае казначейськ послуги;
- киентська база налiчуе до 15 млн. кменлв;
- кiлькiсть вщдшень 2 тис. (до 10 пращвниюв одночасно працюючих на одне вщдшення в годину пiк);
- кшьюсть операцiй до 50 млн. в день, половину в годину тк;
- кшьюсть клiентськиx раxункiв 25 млн.
Високорiвнева арxiтектурна схема 1Т ландшафту банку (рис. 1) складаеться з наступних функцiональниx блокiв програмних додатюв:
1. Клiентськi IС/програмно-апаратнi комплекси публiчного доступу (aнгл. Public channels).
2. Системи управлшня вiдносинами з киентом (англ. Customer Relationship Management, надаи CRM).
3. Забезпечення мiжсистемноl взаемодп, iнтеграцiйний шар (aнгл. Integration layer).
4. Операцшш банкiвськi системи (англ. Back end systems).
5. Системи управлшня даними (англ. Enterprise data management).
Рис. 1. Високорiвнева архггектурна схема шформацшних техно логш
ландшафту банку
Розглянемо щ блоки бшьш докладно:
1. RnieumchKÎ 1С/програмно-апаратш комплекси публiчного доступу включають в себе програмш додатки та апаратш засоби для взаемодп з кшентами банку, фiзичними та юридичними особами. Цi системи несуть велике навантаження з точки зору кшькост користувачiв, що одночасно використовують функцiонал (кiлькiсть активних сесiй користувачiв). Крiм того доступ з публiчних мереж збiльшуе ризик порушення цшсност внаслiдок зовнiшнiх атак. Для шдтвердження автентичностi платiжних транзакцiй мае використовуватися електронний цифровий шдпис (надалi ЕЦП). Доступнiсть цих систем напряму випливае на безперервшсть бiзнесу, тому час вщновлення цих систем мае бути мтмальним.
2. Системи управлшня eidHOCUHaMU з клгентом включають в себе програмш додатки для введення, обробки та анаизу кшентських даних, що здшснюеться прашвниками банку. Цi системи несуть значно менше навантаження, з точки зору кшькост користувачiв i зазвичай не мають iнтерфейсiв для доступу з публiчних мереж. Для шдтвердження автентичностi платiжних транзакцiй мае використовуватися ЕЦП. Доступшсть цих систем мае менший вплив на безперервшсть бiзнесу ому рiвень сервiсу з вщновлення (вiд англ. Service Level Agreement, надаш SLA) може передбачати бшьший час вiдновлення, нiж для систем з функцюнального блоку № 1 i № 3.
3. Забезпечення мiжсистемноï взаемодп, штеграцтний шар включае в себе системи, як забезпечують можливють обмiну та трансформацп даних мiж програмними додатками. Ц системи несуть велике навантаження з точки зору кшькосл транзакцiй, що обробляються в режимi он-лайн (вщ англ. Online Transaction Processing, надал OLTP) вiд iнтегрованих мiж собою систем, часто вщграючи роль транспорту або джерела даних для вшх шших систем. В окремих випадках може бути передбачено доступ з публiчних мереж, що збiльшуе ризик порушення цшсност внаслiдок зовнiшнiх атак. Доступшсть цих систем безпосередньо випливае на безперервшсть бiзнесу, тому час вщновлення цих систем мае бути мтмальним.
4. ОперацШш баншвсъш системи включають в себе системи обробки докуменлв для облшу та формування звггност за операшями банку, обробки подш, якi генеруються системами функцюнальних блокiв № 1-3 та вщображення результату цих подiй в баланс банку. Окремi системи, зокрема автоматизований операцiйний день банку (вiд англ. Core Banking System, надалi CBS), несуть велике шкове навантаження шд час оперативно!' аналiтичноï обробки даних (вщ англ. Online Analytical Processing, надал OLAP) для виконання регламентних розрахункових процешв закриття операцiйного дня i формування щоденноï' звiтностi. В окремих випадках може бути передбачено доступ з публiчних мереж, що збшьшуе ризик порушення цшсност внаслщок зовнiшнiх атак. Доступнiсть цих систем значною мiрою впливае на безперервшсть бiзнесу, тому час вiдновлення цих систем мае бути близьким до мшмального.
5. Системи управлшня даними включають в себе сховища структурованих (вщ англ. Data Warehouse, надаш DWH) i неструктурованих
даних (вщ англ. Data Lake) та шструменти перетворення та анаизу даних (вщ. англ. Business Intelligence Tools, надалi BI tools) для аналiзу, вiзуалiзацii даних для формування регуляторноi i управлiнськоi звiтностi та прийняття ршень. Доступ з публiчних мереж не надаеться. Доступнiсть цих систем не вливае на безперервнiсть бiзнесу, тому SLA з вiдновлення може передбачати бшьший час вiдновлення шж для систем з функцiонального блоку № 1-4. Однак, варто зазначити, що щ системи часто е джерелом для формування регуляторно1' звггност^ зокрема зпдно Мiжнародних стандартiв фiнансовоi звiтностi, тому ix недоступнiсть бшьше доби вплине на своечаснiсть надання звiтностi до НБУ та Свропейських регуляторiв.
Функщональне призначення банювських 1С. Дамо коротке визначення функцюнального призначення кожно!' iз систем, якi входять до зазначених вище функцiональниx блоюв.
1. Клгентськг 1С/програмно-апаратш комплекси публичного доступу (eid англ. Public channels):
1.1. Веб сторшка банку/Контакт центр (вщ англ. Web site). Призначена для розмщення структурованого контенту щодо продуклв банку з можливютю штерактивного чату з працiвниками контакт центру для кменлв банку.
1.2. 1нтернет банкiнг для фiзичниx осiб (Private individuals Internet banking, PIIB). Призначена для управлшня власними рахунками та картками для киенпв банку, фiзичниx осiб.
1.3. 1нтернет банкiнг для юридичних осiб (Legal Enteties Internet Banking, LEIB). Призначена для управлшня власними рахунками, кредитними лтями, зарплатними проектами для кменлв банку, юридичних ошб.
1.4. Бакомати, POS термшали (вщ англ. Automated teller machine, Point of sale terminal, ATM, POS). Призначеш для здшснення розрахункових операцш з платiжними картками для киенпв банку.
1.5. Портали партнерiв (вiд англ. Portals). Призначенi для надання плалжних сервiсiв для кменив банку.
2. Система управлшня вiдносинами з Тентом (CRM) призначена для комплексного обслуговування киенпв, аналiзу киентських даних i розробки рiшень щодо пропозицш продуктiв банку, що вщповщають потребам клiентiв, на основi анаизу профiлю клiента, рейтингу ризику, полггик банку.
2.1.1. Автоматизоване робоче мюце (вiд англ. Branch work station, BWS) пращвника вiддiлення. Призначене для вщкриття раxункiв, видачi та облшу платiжниx карток, касових платiжниx операцш, валютобмшних операцп, ведення анкети кшента, фiнансовий монiторинг.
2.1.2. Автоматизоване робоче мюце - мобшьний додаток (вщ англ. Branch work station, BWS). Призначена для оформлення зарплатних проеклв, споживчих кредщ^в управлiння електронною чергою вiддiлення для мобiльниx банкiрiв, заведення киентських кредитних заявок.
2.1.3. Система анаизу клiентськиx даних та прийняття ршень (вiд англ. Customer relationship management, analytics). Призначена для анаизу профшю клiента, на основi рейтингу ризику, розрахунюв кредитних лiмiтiв пропозицп щодо ере..ресного продажу продуктiв для киенлв банку.
2.1.4. Система управлшня заставним майном (вщ англ. Collateral management, CM). Призначена для реестрацп та збереження даних фото фксацп i оцшки заставного майна для шдроздшв ризик менеджменту банку.
2.1.5. Система управлшня заборгованютю киенлв (вщ англ. Days past due system, DPDS). Призначена для автоматичного розрахунку дшв прострочено1' заборгованост для пiдроздiлiв ризик менеджменту банку.
2.1.6. Кредитне бюро (вщ англ. Credit burea, CB) - база даних проблемних позичальниюв для шдроздшв ризик менеджменту банку.
2.2. Система автоматизованоï доставки повщомлень клiентам (вщ англ. Short message system, SMS). Призначена для доставки шформацшних повщомлень щодо кампанiй акцiйних пропозицiï, шдивщуальних умов обслуговування для клiентiв банку.
3. Забезпечення мiжсистемноï взаемодИ', штеграцтний шар:
3.1. Корпоративна шина даних (вщ англ. Enterprise service bus, ESB) призначена для забезпечення мiжсистемноï штеграцп i взаемодп банювських 1С.
3.2. Система управлшня API (вщ англ. Application programming interface) призначена для надання вщкритих API для штеграцп з зовшшшми системами в тому чи^ порталами, що надають платг Ti сервюи клiентам.
3.3. Система перетворення та реплшацп даних (вщ англ. Extract, Transform, Load, ETL) призначена для забезпечення синхрошзацп великих масивiв даних довiдникiв для 1С банку.
3.4. Система еталонних киентських даних (вiд англ. Master data management, MDM) призначення слугувати единим джерелом еталонних даних щодо кшенлв банку та он-лайн синхрошзацп з шшими системами банку, в яких мютяться киентсью данi.
3.5. Система управлiння облшовими даними та доступом користувачiв (вщ англ. Identity and Access Management, IAM) призначена для забезпечення сильноï автентифiкацiï для зовнiшнiх i внутршшх користувачiв банкiвських 1С, динамiчного управлiння 1'х правами доступу.
3.6. Система управлшня бiзнес-процесами (вiд англ. Business process management, BPM) призначена для управлшня, автоматизацп та роботизацп внутршшх процесiв банку для шдроздшв операцшного сервiсу.
4. ОперацШш банювсъю системи:
4.1. Продуктовий каталог (вщ англ. Product catalog system, PCS) призначений слугувати единим джерелом еталонних даних щодо продуклв банку та синхрошзацп з шшими системами банку, в яких мютяться продукти банку.
4.2. Автоматизований операцшний день банку (CBS) призначений для виконання функцп головно!' бухгалтерсько!' книги, виступаючи джерелом даних щодо активiв та пасивiв та щоденного балансу банку для НБУ.
4.3. Система управлшня людськими ресурсами (вщ англ. Human Resources System) призначена для управлшня режимом роботи та оплатою праш для прашвниюв вщдшу кадрiв банку.
4.4. Система облшу господарських операцш банку (вщ англ. Enterprise Resource Planning, ERP) призначена для управлшня облшом основних засобiв,
малощнних та швидкозношуваних предмепв та шших aктивiв банку для пiдроздiлiв фшансово1' вертикaлi банку.
4.5. Електронний документообш (вiд англ. Electronic Document flow, ED) призначений для збершання, обробки та затвердження електронних документа киенлв банку.
4.6. Процесинг оперaцiй з плалжними картками (вiд англ. Card management system, CMS) призначений для управлшня мережею POS термшаив та юосюв, банкомат, розрахунку комiсiй та покриття, yпрaвлiння життевим циклом пластикових карток для пращвниюв оперaцiйного сервюу банку.
4.7. Iншi окремi продyктовi системи (other) признaченi для облжу оперaцiй казначейства, документарних послуг, кaстодiaльниx оперaцiй, оренди депозитних скриньок, продажу монет та дорогощнних метaлiв, тощо.
5. CucmeMU у^авлтня даними:
5.1. Cxовище даних призначене для збер^ання структурованих даних з систем джерел даних i збагачення даних для формування бухгалтерской управлшсько1', статистично1' i оперативно!' звггносп. Kористyвaчi - тдроздши aнaлiзy даних банку.
5.2. Data Lake - сховище, яке призначене для збер^ання як структурованих так i не структурованих даних (зображення, електронш листи, вщео-, аудю-даш та iн.) для yпрaвлiння даними банку в широкому розумшш, вщ фшансово1' звiтностi до маркетингових кампанш.
5.3. Iнстрyменти перетворення та анаизу даних (BI tools) признaченi для анаизу, перетворення, вiзyaлiзaцiï даних для формування регуляторно1' i yпрaвлiнськоï звггност та прийняття рiшень.
Нeфункцiоналънi вимоги до банювсъких IC. Автор пропонуе роздтити нефyнкцiонaльнi вимоги на блоки, яю вiдповiдaють наступним якостям шформаци:
- конфiденцiйнiсть даних;
- цшснють даних;
- aвтентичнiсть;
- доступнють даних (в тому числi продуктившсть IC).
Kонфiденцiйнiсть означае, що даш, особливо тi, якi становлять банювську
таемницю мають бути захищеними вщ несaнкцiоновaного розкриття. GDPR регламентуе вимоги щодо захисту персональних даних та забезпечення можливост ïx видалення з ytix систем банку, на вимогу киента [7]. В умовах розгортання за моделлю Public Cloud банк не володie i не розпоряджаеться ресурсами, ^м того ресурси, яю використовуються для збершання, обробки та передaчi даних клieнтa розподiленi мiж iншими користувачами. Це вступае в конфлшт з зазначеними вимогами.
Для виршення цieï проблеми дaнi, що розмщуються у xмaрi, необxiдно максимально де персонаизувати. Деперсонaлiзaцiю даних можливо забезпечити шляхом розмiщення всix даних, що становлять банювську таемницю, застосувавши модель розгортання Private Cloud, а при мiжсистемнiй взаемодп з Public Cloud обмшюватись виключно yнiкaльним секретним щентифжатором клieнтa. Taкий iдентифiкaтор може бути прив'язаний до
мiжнародного номеру банювського рахунку (вiд англ. International Bank Account Number, надал IBAN) у поеднанш з ушкальним iдентифiкатором клiента системи еталонних кшентських даних (вiд англ. Master Data Management, надаи MDM).
Такий шдхщ також дозволить виключити ризик несанкцюнованого використання даних постачальниками хмарних сервiсiв. Адже iснуе гiпотеза про те, що глобальш 1Т корпорацiï, заволодiвши даними клiентiв банкiв та отримавши лiцензiï на фiнансову дiяльнiсть, можуть становити загрозу для юнування фшансових iнституцiй. Останнi не зможуть конкурувати з ними в технолопчному аспект. Цiлiснiсть означае, що активи 1Т можуть бути змiненi тiльки уповноваженими сторонами в дозволений спошб, що стосуеться даних, програмного та апаратного забезпечення. Зокрема для захисту «сеансового р1вня» взаемодп вщкритих iнформацiйних систем НБУ регламентовано використання криптографiчного протоколу захисту на транспортному рiвнi версп 1.2 (Trasport Layer Security, надаи TLS) для забезпечення контролю цшсност та конфiденцiйностi iнформацiï [6].
Автентичшсть - означае, що виключно уповноважеш користувачi можуть отримати доступ до шформацшних ресуршв i функцiональних можливостей систем. Управлiння облiковими даними та доступом користувачiв на базi хмарних сервiсiв (вiд англ. Identity as a Service, IDaaS) забезпечуе сильну автентифкацш користувачiв i мiнiмiзуе ризики, пов'язаш з атаками, направленими на втручання в сесiю i кращжку облiкових даних. На ринку 1Т наявнi комплекснi рiшення вiд провщних постачальникiв. Такi рiшення включають в себе - двофакторну автентифiкацiю користувачiв, динамiчне управлiння доступом користувачiв на базi шаблонно-рольово1' моделi, федеративнi сценарп для рiзних доменiв безпеки, аудит подш доступу та iншi можливост. Функцiональнi можливостi здатнi повнiстю забезпечити потреби банкiвських установ.
Доступнiсть означае властивють системи забезпечувати вхiд авторизованого користувача та безперебiйну роботу функцюнальност згiдно його потреб.
Для досягнення максимального економiчного ефекту хмарнi сервюи доцтьно застосовувати до систем з великим навантаженням. Серед критерпв: кшьюсть операцiй одночасно працюючих користувачiв або велике ткове навантаження пiд час оперативно1' аналiтичноï обробки даних, що вимагае велико1' обчислювально1' потужностi. Хмарш технологи також дозволяють досягти максимального рiвня доступностi обчислювальних ресурсiв (тобто вщсутност збо1'в, якi спричиняють зупинку бiзнес-процесу) для систем, зупинка в робот яких е найбшьш небезпечною з точки зору операцiйних ризиюв банку.
Для визначення таких систем автор пропонуе застосувати наступш параметри (табл. 1) в контекст доступности
Доступшсть 24/7 - значення параметру так/ш, означае можливють цiлодобового доступу для киентв банку до 1С банку в режимi он-лайн.
- RPO (вщ англ. Recovery point objective) - означае точку у чаш, на яку можливо вщновити даш у випадку зупинки бiзнес-процесу в наслiдок збою в робот 1С, в хвилинах.
- RTO (вщ англ. Recovery time objective) - це SLA з вщновлення 6i3Hec-процесу пiсля зупинки внаслщок збою в робот 1С, в хвилинах.
В контекст продуктивности
- DB size - вщ англ. Data Base size - обсяг бази даних 1С в терабайтах.
- OLTP1 - юльюсть активних киентських сесш, тобто одночасно працюючих користувачiв в режимi онлайн в тисячах.
- OLTP2 - юльюсть запипв в тисячах одиниць до системи i вiдповiдей вщ iнших 1С, що обробляються за годину.
- OLAP - штервал оновлення даних системи даними шших систем в хвилинах.
Таблиця 1
Системи банку з максимальним шковим навантаженням_
№ системи 24/7 RPO RTO DB size OLTP 1 OLTP 2 OLAP
3.1 Так 0 60 <1 1 5000 -
3.5 Так 240 60 200 5000 240
1.2 Так 5 60 2-4 50 1500 240
1.5 Так 5 60 <1 50 1500 240
3.2 Так 0 60 <1 <1 1500 -
3.4 Так 5 60 >10 10 1000 240
4.6 Так 5 60 2-4 50 1000 240
1.3 Так 5 60 2-4 10 300 240
Виходячи з анаизу вибiрки, приведено!' в табл. 1, автор вважае, що наступнi системи несуть найбшьше навантаження i е критичними щодо безперервност бiзнесу та SLA по вщновленню роботи:
3.1. Корпоративна шина даних.
3.5. Системи управлшня облшовими даними та доступом користувачiв.
1.2. 1нтернет банкiнг для фiзичних осiб.
1.5. Портали партнерiв.
3.2. Система управлiння API.
3.4. Система еталонних клiентських даних.
4.6. Процесинг операцш з плалжними картками.
1.3. 1нтернет банкiнг для юридичних ошб.
7. SWOT-аналiз результатiв дослщжень
Strengths. Застосування моделi розгортання Public Cloud дозволило б досягти максимального ефекту щодо економiчноï ефективностi, скорочення витрат та операцшноï' стабiльностi. Адже забезпечення таких параметрiв вимагае значних швестицш в ресурси апаратного забезпечення, яю банк несе при застосуванш моделей Public Cloud та On-Premise.
Weaknesses. Окремi системи, зокрема, автоматизований операцшний день банку (на архггектурнш схемi 4.2. CBS), несуть велике ткове OLAP навантаження пiд час виконання регламентних розрахункових процешв
закриття операцшного дня i формування щоденно1' звггност. При цьому, в денний час ресурси апаратного забезпечення фактично недоутилiзованi, та використовуються неефективно.
Opportunities. Одним з найперспектившших напрямiв застосування Hybrid Cloud та Public Cloud е автоматизований операцшний день банку. Розгортання двох примiрникiв ще1' системи - Private Cloud для киентських даних та Public cloud для деперсонаизованих киентських даних.
Деперсоналiзацiю даних можливо забезпечити шляхом розмщення всiх даних, що становлять банювську таемницю, застосувавши модель розгортання Private Cloud, а при мiжсистемнiй взаемодп з Public Cloud обмшюватись виключно унiкальним секретним щентифжатором клiента. Такий iдентифiкатор може бути прив'язаний до мiжнародного номеру банювського рахунку IBAN в поеднаннi з ушкальним iдентифiкатором клiента системи MDM.
Результати дослiдження можуть бути використаш в банкiвськiй системi будь-яко1' краши свiту.
Threats. Застосування моделi Public Cloud без деперсонашзацп даних неможливе з огляду на те, що це порушуе вимоги GDPR та НБУ. Деперсоналiзувати данi i застосувати модель Public Cloud для складних процесiв онлайн взаемодп е дуже складним завданням для практично1' реашзацп
8. Висновки
1. Складено високорiвневу архiтектурну схему 1Т ландшафту банку та визначено функцюнальш блоки програмних додатюв, з яких вона складаеться. Для кожного з блокiв узагальнено вимоги щодо конфiденцiйностi, цiлiсностi та автентичност даних. Це лягло в основу для визначення прюритетних напрямiв застосування рiзних моделей розгортань хмарних технологш.
2. Визначено функцiональне призначення кожно1' з основних систем 1Т ландшафту банку, 1'х функцiональне призначення, проанаизовано кiлькiснi та якiснi показники, зокрема, щодо нефункцюнальних вимог до банювських 1С.
Отриманий результат в кшьюсному вираженнi показникiв навантаження на систему дозволяе знайти додатковi резерви для оптимiзацiï часу обробки шформацп i пiдвищення економiчноï ефективностi за рахунок застосування Public Cloud. Найбшьшого ефекту можливо досягти, застосувавши цю модель до автоматизованого операцшного дня банку (вщ англ. Core Banking System). Для дотримання вимог та урахування обмежень щодо розмщення киентських даних в робот запропонований мехашзм деперсонаизацп.
Лiтература
1. Zissis D., Lekkas D. Addressing cloud computing security issues // Future Generation Computer Systems. 2012. Vol. 28, No. 3. P. 583-592. doi: http://doi.org/10.1016/i.future.2010.12.0Q6
2. Apostu A., Rednic E., Puican F. Modeling Cloud Architecture in Banking Systems // Procedia Economics and Finance. 2012. Vol. 3. P. 543-548. doi: http://doi.org/10.1016/s2212-5671(12)00193-1
3. Nagaty K. A Framework for Secure Online Bank System Based on Hybrid Cloud Architecture // Journal of Electronic Banking Systems. 2015. Vol. 1-13. doi: http://doi.org/10.5171/2015.614386
4. Rahman M., Qi X. Core Banking SofWare(CBS) Implementation Challenges of e-Banking: An Exploratory Study on Bangladeshi Banks // Journal of Administrative and Business Studies. 2016. Vol. 2, No. 4. P. 208-215. doi: http://doi.org/10.20474/jabs-2A6
5. Ambodo B. S., Suryanto R., Sofyani H. Testing of Technology Acceptance Model on Core Banking System: A Perspective on Mandatory Use // Jurnal Dinamika Akuntansi. 2018. Vol. 9, No. 1. P. 11-22. doi: http://doi.org/10.15294/jda.v9i1.12006
6. Reeshma K. Challenges of Core Banking Systems // Mediterranean Journal of Social Sciences. 2015. Vol. 6, No. 5. P. 24-27. doi: http://doi.org/10.5901/mjss.2015.v6n5p24
7. Personalized Security Approaches in E-banking Employing Flask Architecture over Cloud Environment / Hamidi N. A. et al. // Procedia Computer Science. 2013. Vol. 21. P. 18-24. doi: http://doi.org/10.1016/j.procs.2013.09.005
8. Karthigainathan M. Cloud Computing for Rural Banking // International Journal Of Engineering And Computer Science. 2016. Vol. 5, No. 9. P. 17880-17884. doi: http://doi.org/10.18535/ijecs/v5i9.15
9. Grivas S., Schurch R., Giovanoli C. How Cloud Will Transform the Retail Banking Industry // Proceedings of the 6th International Conference on Cloud Computing and Services Science. 2016. Vol. 1. P. 302-309. doi: http://doi.org/10.5220/0005910903020309
10. Bobyl V. V., Dron M. A. «Khmarni» tekkhnolohii yak faktor zbilshennia operatsiinoho ryzyku banku // Bankivska sprava. 2014. No. 11-12. P. 47-62. URL: http://lib.sumdu.edu.ua/library/DocDescription?doc_id=441341 (Last accessed: 24.12.2017).
11. Polozhennia pro orhanizatsiiu zakhodiv iz zabezpechennia informatsiinoi bezpeky v bankivskii systemi Ukrainy: Resolution of the Board of the National Bank of Ukraine No. 95 from 28.09.2017 // Baza danykh «Zakonodavstvo Ukrainy» VR Ukrainy. URL: http://zakon2.rada. gov.ua/laws/show/v0095500-17 (Last accessed: 24.12.2017).
12. General Data Protection Regulation: Directive of European Parliament and of the Council of 27.04.2016 No. 95/46 // European Union Law data base. URL: http://eur-lex.europaeMegal-content/EN/TXT/?uri=CELEX:32016R0679 (Last accessed: 24.12.2017).
