Інформаційна безпека банківських безготівкових платежів. Частина 2 — Типова IT-інфраструктура банку


Рис. 1.

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

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

Disclaimer
Стаття не містить конфіденційної інформації. Всі використані матеріали публічно доступні в Інтернеті.
Розділ 1. Загальний опис ІТ-інфраструктури

Основні терміни

У 90-х роках минулого століття в ГОСТах і нормативних документах ФСТЕК Росії (тоді ще Держтехкомісії при Президентові РФ) часто вживався термін — автоматизована система. «ГОСТ 34.003-90 Інформаційна технологія (ІТ). Комплекс стандартів на автоматизовані системи. Автоматизовані системи. Терміни та визначення» дає наступне визначення даного терміну:
автоматизована система; AC: Система, що складається з персоналу і комплексу засобів автоматизації його діяльності, що реалізує інформаційну технологію виконання установлених функцій.
Через деякий час, в ужиток увійшов новий термін — інформаційна система. В п. 3 ст. 2 Федерального закону від 27.07.2006 N 149-ФЗ «Про інформацію, інформаційні технології і про захист інформації» даний термін визначається наступним чином:
інформаційна система — сукупність міститься в базах даних інформації та забезпечують її обробку інформаційних технологій і технічних засобів;
В рамках даного дослідження будуть використовуватися обидва терміни як синоніми.

Справедливість такого підходу можна довести тим, що в Наказі ФСТЕК Росії від 11.02.2013 N 17 «Про затвердження Вимог щодо захисту інформації, яка не становить державну таємницю, міститься в державних інформаційних системах» для захисту інформаційних систем держрегулятор наказує керуватися ГОСТами по автоматизованим системам.

Крім інформаційних систем в IT-інфраструктурі банку можна виділити ще один тип елементів — інформаційні сервіси, або, як їх часто називають, роботи.

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

  1. Інформаційний сервіс набагато простіше інформаційної системи, але водночас його не можна назвати компонентом останньої, оскільки результатами його роботи можуть користуватися одночасно кілька інформаційних систем.
  2. Інформаційні сервіси призначені для автоматизації простих, рутинних завдань.
  3. Інформаційні сервіси не містять у своєму складі бази даних.
  4. Інформаційні сервіси працюють в автоматичному режимі без участі (або з мінімальною участю людини.

 

Автоматизована банківська система

Ядром інформаційної інфраструктури будь-якого банку є автоматизована банківська система або скорочено АБС.

Стандарт Банку Росії СТО БР ІББС-1.0-2014 «Забезпечення інформаційної безпеки організацій банківської системи Російської Федерації. Загальні положення» визначає АБС наступним чином:
автоматизована система, що реалізує банківський технологічний процес.

Дане визначення дозволяє підвести під нього практично будь-яку IT-систему в банку. В той же час звичайні банківські службовці називають АБС ту систему, яка займається урахуванням банківських рахунків, провідник між ними (рухом грошових коштів) та залишків. Друге визначення не суперечить першому і більш чітко його деталізує, їм і будемо користуватися далі.

У сучасних Російських банках найбільш поширеними є наступні АБС :

  • Diasoft FA#,
  • Інверсія XXI століття,
  • RS-Bank,
  • ЦФТ-Банк.

Деякі, особливо великі банки використовують не тиражні, а спеціально розроблені під них АБС. Але такі випадки поодинокі, власне як і особливо великі банки.

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

Прикладні інформаційні системи

Незважаючи на те, що АБС автоматизує досить велику кількість завдань, вона не покриває всі потреби банку. Є завдання, які АБС не робить або робить не так, як хоче того банк. Тому до АБС підключаються (інтегруються) інші інформаційні системи, що автоматизують окремі бізнес-процеси. Надалі подібні інформаційні системи будемо називати — прикладними інформаційними системами.

Прикладами прикладних інформаційних систем можуть бути:

  • системи дистанційного банківського обслуговування Інтернет Клієнт-Банк,
  • процесинг платіжних карток ,
  • системи автоматизації контакт-центрів (наприклад, Avaya Call Center, Cisco Unified Contact Center),
  • системи автоматичного скорингу позичальників (наприклад, FICO),
  • та ін.

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

Інфраструктурні інформаційні системи

Крім АБС і прикладних інформаційних систем, що автоматизують основні бізнес-процеси, в банках також присутня значна кількість допоміжних інфраструктурних інформаційних систем. Прикладами такими системами можуть бути:

  • служба каталогів Active Directory,
  • служба доменних імен (DNS),
  • корпоративна електронна пошта,
  • служби надання доступу працівників до Інтернет;
  • системи контролю та управління доступом (СКУД) приміщення;
  • IP-відеоспостереження;
  • IP-телефонія;
  • і багато іншого.

 

Інформаційні сервіси

У банках використовується гігантська кількість різних інформаційних сервісів, які виконують прості, рутинні функції, наприклад, завантаження довідників БИК і ФІАС, публікація курсів валют на офіційному сайті і т. д.

Читайте також  Віконце з кнопками на JavaFX:

Клієнтські частини сторонніх інформаційних систем

Окремої згадки варті клієнтські частини зовнішніх по відношенню до банку інформаційних систем. В якості прикладів наведу:

  • модулі інтеграції з державними інформаційними системами: ГІС ГМП, ДВС ЖКГ;
  • клієнтські частини зовнішніх платіжних систем;
  • біржові торговельні термінали;
  • і так далі.

 

Типові способи інтеграції інформаційних систем

Для інтеграції інформаційних систем зазвичай застосовуються наступні механізми:

  1. Інтеграція через API (наприклад, Web-сервіси).
  2. Інтеграція через СУБД:
    • шляхом надання доступу лише до збережених процедур;
    • шляхом надання доступу до збережених процедур і таблиць баз даних.
  3. Файловий обмін:
    • через комп’ютерну мережу;
    • через відчужувані машинні носії інформації (ОМНІ, наприклад – флешки).
  4. Реалізація сервіс-орієнтованої архітектури (SoA).

 

Модулі інтеграції

Під модулем інтеграції будемо розуміти віртуальний елемент IT-інфраструктури, що реалізує інтеграцію інших елементів IT-інфраструктури.

Цей елемент ми назвали віртуальним, тому що його функціонал може бути реалізований як у вигляді окремого спеціалізованого елемента ІТ-інфраструктури (наприклад, інформаційного сервісу), так і у вигляді компонентів інтегрованих інформаційних систем. Більш того, в якості модуля інтеграції може виступати навіть людина, «вручну» переносить інформацію між інтегрованими інформаційними системами.

Приклад ІТ-інфраструктури банку

На Рис.1 можна побачити фрагмент типової інформаційної інфраструктури банку, що містить розглянуті вище типи елементів.

Розділ 2. Інфраструктура безготівкових розрахунків
Якщо подивитися на цю схему (Рис.1) з точки зору здійснення безготівкових розрахунків, то можна побачити, що банк реалізує їх за допомогою:

  • прямих кореспондентських відносин з банком-партнером,
  • міжнародної платіжної системи (МПС) (наприклад, VISA, MasterCard).
  • кореспондентських відносин з Банком Росії.

Технічно прямі кореспондентські відносини з банками-партнерами можуть бути організовані з допомогою:

  • звичайних систем ДБО ІКБ, що застосовуються банками для обслуговування юридичних осіб (у розглянутому прикладі (Рис.1) використовується саме цей спосіб);
  • міжбанківських платіжних систем (наприклад, SWIFT);
  • спеціалізованих систем обміну платіжними повідомленнями (наприклад, REX400, TELEX);
  • спеціалізованого ПЗ, розробленого одним із взаємодіючих банків.

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

Для успішного функціонування банк зобов’язаний забезпечувати в себе інформаційну безпеку всіх перерахованих способів здійснення платежів. Розглянути їх у рамках однієї, навіть великої дослідження вельми проблематично, і тому ми зосередимося тільки на одному найбільш критичне, з точки зору можливих втрат, напрямку — платіжної взаємодії банку з Банком Росії.

Інфраструктура забезпечення платіжної взаємодії з Банком Росії


Рис. 2.
IT-інфраструктуру платіжного взаємодії банку з Банком Росії будемо розглядати на прикладі виконання платежу, надісланого на адресу клієнта іншого банку.

Як ми пам’ятаємо з першої частини, спочатку клієнт повинен передати в банк платіжне доручення. Зробити це він може двома способами:

  1. З’явитися особисто до відділення банку та передати завірене платіжне розпорядження на паперовому носії.
  2. Направити платіжне розпорядження через систему ДБО ІКБ.

Тут важливо відзначити, що системи ДБО ІКБ — це лише системи, що забезпечують юридично значимий електронний документообіг між клієнтом і банком, самостійно вони платежі не проводять. Саме тому, коли клієнт відкриває розрахунковий рахунок у банку, він зазвичай укладає два договори. Перший – договір обслуговування банківського рахунку, другий – договір на здійснення електронного документообігу за допомогою системи ДБО ІКБ. Якщо другий договір укладено не буде, то клієнт все одно зможе користуватися своїм рахунком, але тільки при особистому візиті до відділення банку.

Якщо клієнт передав платіжне доручення на паперовому носії, то працівник банку на його підставі робить електронне платіжне доручення в АБС. Якщо розпорядження було подано через ДБО ІКБ, то через модуль інтеграції воно потрапляє в АБС автоматично.

Доказом того, що саме клієнт зробив розпорядження про переказ грошових коштів, у першому випадку є особисто підписаний ним паперовий документ, а в другому, електронний документ у ДБО ІКБ, засвідчений у відповідності з договором.

Зазвичай для завірення електронних документів клієнтів — юридичних осіб в ДБО ІКБ застосовують криптографічну електронний підпис, а для документів клієнтів — фізичних осіб коди SMS-підтверджень. З юридичної точки зору для завірення електронних документів в обох випадках банки зазвичай застосовують правовий режим аналога власноручного підпису (АСП).

Потрапивши в АБС, платіжне доручення у відповідності з внутрішніми регламентами банку проходить контроль і передається для виконання в платіжну систему Банку Росії.

Технічні засоби взаємодії з платіжною системою Банку Росії

Технічні засоби (програмне забезпечення), які використовуються для взаємодії з платіжною системою Банку Росії можуть змінюватись в залежності від територіальної установи Банку Росії, обслуговуючого кор. рахунок банку.

Читайте також  Нове в SObjectizer-5.5.23: виконання бажань чи скринька Пандори?

Для банків, що обслуговуються в Московському регіоні, застосовується наступне:

  • АРМ КБР – автоматизоване робоче місце клієнта Банку Росії;
  • УТА – спеціальне програмне забезпечення файлового взаємодії клієнта Банку Росії (універсальний транспортний адаптер);
  • СКАД Сигнатура — засіб криптографічного захисту інформації (СКЗІ) «Апаратно-програмний комплекс Сигнатура-клієнт» версія 5, сертифікати ФСБ Росії – СФ/114-2680 (рівень криптозахисту КС1), для рівня криптозахисту КС2 – СФ/124-2681 (рівень криптозахисту КС2). СКАД розшифровується як система криптографічної аутентифікації документів.

 

АРМ КБР

АРМ КБР – це, з допомогою якого уповноважені працівники банку здійснюють шифрування і електронний підпис вихідних платіжних документів, а також розшифровку і перевірку електронного підпису платіжних документів, що надходять з Банку Росії. Але, якщо бути більш точним, то АРМ КБР у своїй роботі оперує не платіжними документами, а електронними повідомленнями (ЕС), які бувають двох типів:

  • електронні платіжні повідомлення (ЕПС), наприклад, ED101 «Платіжне доручення»;
  • електронні службово-інформаційні повідомлення (ЕСІМ), наприклад, ED201 «Повідомлення про результати контролю ЕС».

Перелік і формати електронних повідомлень встановлює Банк Росії, шляхом випуску Альбому уніфікованих форматів електронних банківських повідомлень (УФЭБС).

Для того щоб АРМ КБР міг обробити платіж, він повинен бути перетворений в файл, що містить електронне платіжне повідомлення формату УФЭБС. За подібне перетворення відповідає модуль інтеграції АБС з платіжною системою Банку Росії. З технічної точки зору подібні перетворення досить прості, оскільки формат УФЭБС заснований на XML.

Файли електронних повідомлень залишають модуль інтеграції АБС у відкритому вигляді і поміщаються у спеціальну папку файлової системи (зазвичай це папка), яка налаштована АРМ КБР для електронних повідомлень, що мають статус «Введені». На раніше поданій схемі (Рис. 2.) ця папка позначена як «Папка 1».

Потім в процесі обробки електронні повідомлення змінюють свої статуси на «Контрольовані», «Надіслані» і т. д., що технічно реалізується шляхом переміщення файлу з електронним повідомленням в відповідні папки, які налаштовані в АРМ КБР. На схемі (Рис. 2.) ці папки позначені як «Папка 2».

У певний момент технологічної обробки (встановлений внутрішніми регламентами банку) вихідних електронних повідомлень вони шифруються і підписуються електронним підписом з допомогою СКАД Сигнатура і закритих криптографічних ключів відповідальних працівників.

СКАД Сигнатура

СКАД Сигнатура, це ЗКЗІ, розроблене компанією ТОВ «Валидата» на замовлення Банку Росії і призначене для захисту інформації в платіжній системі Банку Росії. Цього ЗКЗІ немає у відкритому доступі (крім документації, розміщеної на сайті ЦБ РФ), і воно поширюється Банком Росії тільки серед його учасників платіжної системи. До відмітним особливостям даного ЗКЗІ можна віднести:

  1. Дане ЗКЗІ, на відміну від інших поширених в ділових колах Росії ЗКЗІ (наприклад, як Крипто-ПРО CSP, VIPNET CSP і ін), реалізує власну, ізольований від операційної системи інфраструктуру відкритих ключів (PKI). Це проявляється в тому, що довідник відкритих ключів, що містить сертифікати, список довірених сертифікатів, список відкликаних сертифікатів, і т. д. криптографічно захищений на закритому ключі користувача, що не дозволяє зловмисникові внести у нього зміни, наприклад, встановити надійний сертифікат без відома користувача.
    Примітка. ЗКЗІ Верба-OW реалізує схожу ключову модель.
  2. Наступна особливість випливає з попередньої. У СКЗІ для того, щоб зробити робочі ключі, необхідно спочатку створити довідник сертифікатів з допомогою спеціальних ключів реєстрації. Після закінчення терміну дії робочих ключів генеруються нові, але для того, щоб їх створити, потрібно володіти діючими попередніми робочими ключами. Ключі створюються за децентралізованій схемі з участю Банку Росії в якості Центру Сертифікації.
  3. ЗКЗІ підтримує роботу з функціонально-ключовими носіями (vdToken), які виконують функції електронного підпису та шифрування у себе на борту, без передачі закритих ключів у пам’ять ЕОМ.
  4. Криптографічні ключі, які використовуються для взаємодії з платіжною системою Банку Росії, бувають двох видів:
    • «Тільки шифрування» – дозволяють зашифровувати / розшифровувати електронні повідомлення.
    • «Шифрування і підпис» – роблять те ж саме, що і в першому випадку, а також дозволяють підписувати електронні повідомлення.

 

УТА

Зашифровані і підписані електронні повідомлення поміщаються в спеціальну папку, на схемі (Рис. 2.) це «Папка 3». УТА безперервно моніторить цю папку і, якщо він бачить там нові файли, передає їх в ЦБ РФ одним з наступних способів:

  • «Інтернет», хоча насправді це не зовсім так. Замість Інтернет використовується спеціалізований оператор зв’язку, який надає виділені канали зв’язку до ЦБ РФ, але оскільки мережа IP-адресується то кажуть, що відправка йде через Інтернет.
  • «По модему». На випадок аварії першого виду зв’язку є резерв у вигляді модемного з’єднання по телефонній мережі загального користування.
  • На випадок виходу з ладу всіх каналів зв’язку передбачена доставка електронних повідомлень на ОМНІ (відчужуваний машинний носій інформації) за допомогою кур’єра. До речі кажучи, це один із способів, за допомогою якого банки з відкликаною ліцензією проводять платежі під час своєї ліквідації.
Читайте також  Швидкий старт з ARM Mbed: розробка на сучасних мікроконтролерах для початківців

Достукавшись до ЦП (першим або другим способом), УТА передає електронні повідомлення через публікується ЦБ API. Під час сеансів зв’язку УТА також отримує з ЦП вхідні електронні повідомлення.

Слід зазначити, що всі електронні повідомлення, з якими працює УТА, зашифровані і підписані електронним підписом.

Отримавши зашифроване повідомлення, УТА перекладає його в теку з вхідними зашифрованими повідомленнями. Уповноважений працівник з допомогою своїх криптоключів і АРМ КБР перевіряє електронний підпис і розшифровує повідомлення.

Далі обробка проводиться в залежності від типу електронного повідомлення. Якщо це платіжне повідомлення, то воно через модуль інтеграції передається в АБС, де на його підставі формуються бухгалтерські проводки, які змінюють залишки на рахунках. Важливо відзначити, що при взаємодії АБС (модуля інтеграції) та АРМ КБР використовуються файли стандартного формату у відкритому вигляді.

У процесі функціонування АРМ КБР веде журнал своєї роботи, який може бути реалізований у вигляді текстових файлів або за допомогою БД, що працюють під управлінням СУБД.

Альтернативні схеми обробки

Ми розглянули «класичну» схему роботи системи. У реальності існує безліч її різновидів. Розглянемо деякі з них.

Різновид 1. Поділ контурів відправки і прийому повідомлень
Реалізується схема з двома АРМ КБР. Перший працює з участю людини і виконує тільки відправку повідомлень, другий працює в автоматичному режимі і виконує тільки прийом повідомлень.

Різновид 2. Повний автомат
АРМ КБР налаштовується на роботу повністю в автоматичному режимі без участі людини

Різновид 3. Ізольований АРМ КБР
АРМ КБР функціонує як виділений комп’ютер, не підключений до мережі банку. Електронні повідомлення передаються на нього людиною-оператором за допомогою ОМНІ.

Перенесення електронного підпису з АРМ КБР в АБС

Банк Росії планує перейти на нову технологічну схему обробки платежів, при якій електронні повідомлення будуть підписуватися не в АРМ КБР, як було раніше, а в АБС (точніше в модулі інтеграції АБС — АРМ КБР).

Для реалізації даного підходу випущена нова версія АРМ КБР, яка стала називатися АРМ КБР-Н (нова). Всі основні зміни можна побачити, якщо порівняти схеми інформаційних потоків, що проходять через АРМ КБР старої і нової версії.

Розглянемо схему інформаційних потоків в класичному АРМ КБР. Джерело схеми – офіційна документація на АРМ КБР «АВТОМАТИЗОВАНЕ РОБОЧЕ МІСЦЕ КЛІЄНТА БАНКУ РОСІЇ. Керівництво програміста. ЦБРФ.61209-04 33 01».


Рис. 3.
Примітки.

  • Умовне позначення «АС КБР» (автоматизована система клієнта Банку Росії) відповідає умовному позначенню АБС на попередніх схемах.
  • Умовне позначення «СПО СВК» відповідає умовному позначенню УТА на попередніх схемах.
  • КА – код аутентифікації (електронний підпис) електронного повідомлення.
  • ЗК – код ще один вид електронного підпису, але на відміну від КА, який формується вихідним повідомленням без змін, ЗК формується тільки під значущими даними без урахування розмітки. Більш докладно про технічні нюанси КА і ЗК, можна почитати в документації УФЭБС «Захист електронних повідомлень (Пакетів ЕС)». З юридичної точки зору ЗК – технологічна міра захисту інформації, в той час як КА, згідно з договорами і правилами платіжної системи Банку Росії, визнається електронним підписом.

Тепер поглянемо на аналогічну схему для нового АРМ КБР-Н. Джерело «АВТОМАТИЗОВАНЕ РОБОЧЕ МІСЦЕ КЛІЄНТА БАНКУ РОСІЇ НОВЕ. Керівництво програміста. ЦБРФ.61289-01 33 01»


Рис. 4.

З точки зору криптографії АРМ КБР-Н відповідає за шифрування / розшифрування електронних повідомлень, а також за перевірку електронних підписів на них. Формування електронних підписів перенесено в модуль інтеграції АБС.

Логічно припустити, що даний модуль також повинен буде перевіряти підписи під повідомленнями, отриманими з АРМ КБР-Н. З технічної точки зору це не є обов’язковим, але з точки зору безпеки має критичне значення, оскільки забезпечує цілісність повідомлень, що передаються між АБС і АРМ КБР-Н.

Крім файлового інтерфейсу взаємодії між АБС, АРМ КБР-Н і УТА додано інтерфейс IBM WebSphere MQ, що дозволяє будувати сервіс-орієнтовану ІТ-інфраструктуру банку та вирішити проблему старої схеми з організацією одночасної роботи декількох операторів, відповідальних за відправлення платежів.

Висновок

Ми розглянули внутрішнюсхему платіжної ІТ-інфраструктури банку. У наступних частинах розглянемо загрози інформаційної безпеки, які тут виникають.

Степан Лютий

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

You may also like...

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *