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

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

 Пасивний об'єкт переходить в стан об'єкта-користувача, коли iндивiд (фізична особа-користувач) «входить» в систему. Цей об'єкт-користувач виступає для КЗЗ як образ фізичного користувача. Звичайно, за цим процесом іде активізація об'єкта-процесу за ініціативою користувача. Цей об'єкт-процес є керуючим для пасивних об'єктів всередині домену користувача. Об'єкти-користувачі, об'єкти-процеси і пасивні об'єкти далі позначаються просто як користувачі, процеси і об'єкти, відповідно.

 Взаємодія двох об'єктів КС (звернення активного об'єкта до пасивного з метою одержання певного виду доступу) приводить до появи потоку інформації між об'єктами і/або зміни стану системи. Як потік інформації розглядається будь-яка порція інформації, що передається між об'єктами КС.

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

 До основних способів НСД відносяться:

 - безпосереднє звертання до об'єктів з метою одержання певного виду доступу;

 - створення програмно-апаратних засобів, що виконують звертання до об'єктів в обхід засобів захисту;

 - модифікація засобів захисту, що дозволяє здійснити НСД;

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

 Під захистом від НСД, звичайно, слід розуміти діяльність, спрямовану на забезпечення додержання ПРД шляхом створення і підтримки в дієздатному станi системи заходів із ахисту інформації. Поняття (термін) захист від НСД є сталим і тому використовується в цьому НД і документах, що на ньому базуються. Проте зміст даного поняття дещо вужчий, ніж коло питань, що розглядаються. Так, політика безпеки КС може містити вимоги щодо забезпечення доступності інформації, які, наприклад, регламентують, що КС має бути стійка до відмов окремих компонентів. Цю вимогу не можна віднести до ПРД, проте її реалізація здійснюється засобами, що входять до складу КЗЗ. Тому система НД щодо захисту інформації в КС від НСД охоплює коло питань, пов'язаних з створенням і підтримкою в дієздатному станi системи заходів, що спрямовані на забезпечення додержання вимог політики безпеки інформації під час її обробки в КС.

 Як порушник розглядається особа, яка може одержати доступ до роботи з включеними до складу КС засобами. Порушники класифікуються за рівнем можливостей, що надаються їм штатними засобами КС. Виділяються чотири рівні цих можливостей. Класифікація є iєрархічною, тобто кожний наступний рівень включає в себе функціональні можливості попереднього:

 - перший рівень визначає найнижчий рівень можливостей проведення діалогу з КС — можливість запуску фіксованого набору завдань (програм), що реалізують заздалегідь передбачені функції обробки інформації;

 - другий рівень визначається можливістю створення і запуску власних програм з новими функціями обробки iнформації;

 - третій рівень визначається можливістю управління функціонуванням КС, тобто впливом на базове програмне забезпечення системи і на склад і конфігурацію її устаткування;

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

 Припускається, що в своєму рівні порушник — це фахівець вищої кваліфікації, який має повну інформацію про КС і КЗЗ.

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

 Основні принципи забезпечення захисту інформації полягають в наступ-ному [21]:

 1. Планування захисту і керування системою захисту

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

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

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

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

 2. Основні принципи керування доступом

 2.1 Безперервний захист

 Захист інформації повинен забезпечуватись протягом всього періоду її існування. З моменту створення об'єкта КС або його імпорту до системи і аж до його знищення або експорту з системи всі запити на доступ до об'єкта і об'єкта на доступ до інших об'єктів мають контролюватися КЗЗ.

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

 Другим аспектом є те, що особливе значення набуває визначення діючих за умовчанням правил, які визначають початкові умови, за яких починається існування об'єкта всередині КС.

 2.2 Атрибути доступу

 Для реалізації політики безпеки КЗЗ повинен забезпечити ізоляцію об'єктів всередині сфери управління і гарантувати розмежування запитів доступу і керування потоками інформації між об'єктами. Для цього з об'єктами КС має бути пов'язана інформація, що дозволяла б КЗЗ iдентифікувати об'єкти і перевіряти легальність запитів доступу. Як така інформація є атрибути доступу.

 Кожний об'єкт КС повинен мати певний набір атрибутів доступу, який включає унікальний iдентифікатор та іншу інформацію, що визначає його права доступу і/або права доступу до нього. Атрибут доступу — термін, що використовується для опису будь-якої інформації, яка використовується при керуванні доступом і зв'язана з користувачами, процесами або пасивними об'єктами. Відповідність атрибутів доступу і об'єкта може бути як явною, так і неявною. Атрибути доступу об'єкта є частиною його подання в КС.

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

 Для відображення функціональностi КС у простір, в якому не розглядаються права власності, використовується концепція матриці доступу. Матриця доступу являє собою таблицю, уздовж кожного виміру якої відкладені iдентифікатори об'єктів КС, а в якості елементів матриці виступають дозволені або заборонені режими доступу. Матриця доступу може бути двомірною (наприклад, користувачі/пасивні об'єкти або процеси/пасивні об'єкти) або тримірною (користувачі/процеси/пасивні об'єкти). Матриця доступу може бути повною, тобто містити вздовж кожної з осей iдентифікатори всіх існуючих на даний час об'єктів КС даного типу, або частковою. Повна тримірна матриця доступу дозволяє точно описати, хто (iдентифікатор користувача), через що (iдентифікатор процесу), до чого (iдентифікатор пасивного об'єкта), який вид доступу може одержати.

 2.3 Довірче і адміністративне керування доступом

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

 Адміністративне керуванням доступом — це таке керування, при якому засоби захисту дозволяють управляти потоками інформації між користувачами і об'єктами тільки спеціально авторизованим користувачам. Прикладом реалізації адміністративного керуванням доступом може служити механізм, коли у вигляді атрибутів доступу використовуються мітки, що відображають міру конфіденційності інформації (об'єкта) і рівень допуску користувача. Таким чином, КЗЗ на підставі порівняння міток об'єкта і користувача може визначити, чи є користувач, що запитує інформацію, авторизованим користувачем.

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

 Створення додаткових потоків інформації може бути зумовлене: модифікацією атрибутів доступу користувача, процесу або пасивного об'єкта; створенням нових об'єктів (включаючи копіювання існуючих); експортом або імпортом об'єктів.

 Сталість атрибутів доступу

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

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

 Створення нових об'єктів

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

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

 Експорт і імпорт об'єктів

 Якщо система реалізує адміністративне керування доступом, то атрибути доступу об'єкта мають зберігатись під час його експорту на зовнішній носiй. Додатково повинні існувати правила для присвоєння атрибутів доступу імпортованому об'єкту.

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

 2.4 Забезпечення персональної відповідальності

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

 Однак, коли користувач працює з КС, то система розглядає його не як фізичну особу, а як об'єкт, якому притаманні певні атрибути і поводження. Для забезпечення ефективності організаційних заходів необхiдна підтримка з боку програмно-аппаратних засобів. Комплекс засобів захисту КС повинен забезпечувати реєстрацію дій об'єктів-користувачів щодо використання ресурсів системи, а також інших дій і подій, які так або інакше можуть вплинути на дотри-мання реалізованої КС політики безпеки.

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

 3. Послуги безпеки

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

 Існує певний перелік послуг, які на підставі практичного досвіду визнані “корисними” для забезпечення безпеки інформації. Вимоги до реалізації даних послуг наведені в НД ТЗІ 2.5-004-99. Вимоги до функціональних послуг розбиті на чотири групи, кожна з яких описує вимоги до послуг, що забезпечують за-хист від загроз одного з чотирьох основних типів: конфіденційності, цілісності, доступності та спостереженостi.

 Згідно з Критеріями, кожна послуга може включати декілька рівнів. Чим вище рівень послуги, тим повніше забезпечується захист від певного виду заг-роз. Для кожної послуги повинна бути розроблена політика безпеки, яка буде реалізована КС. Політика безпеки має визначати, до яких об'єктів застосову-ється послуга. Ця визначена підмножина об'єктів називається захищеними об'єктами відносно даної послуги.

 4. Гарантії

 Крім функціональних критеріїв, що дозволяють оцінити наявність послуг безпеки в КС, Критерії містять критерії гарантій, які дозволяють оцінити корек-тність реалізації послуг. Критерії гарантій включають вимоги до архітектури КЗЗ, середовища розробки, послідовностi розробки, випробування КЗЗ, сере-довища функціонування і експлуатаційної документації. В Критеріях вводиться сім рівнів гарантій, які є iєрархічними. Iєрархiя рівнів гарантій відбиває посту-пово наростаючу міру упевненості в тому, що послуги, які надаються, дозволя-ють протистояти певним загрозам, а механізми, що їх реалізують, в свою чергу, коректно реалізовані, і можуть забезпечити очікуваний споживачем рівень захищеності інформації під час експлуатації КС.

 Гарантії забезпечуються як в процесі розробки, так і в процесі оцінки. В процесі розробки гарантії забезпечуються діями розробника щодо забезпечення правильності (коректностi) розробки. В процесі оцінки гарантії забезпечуються шляхом перевірки додержання розробником вимог Критеріїв, аналізу докумен-тації, процедур розробки і постачання, а також іншими діями експертів, які проводять оцінку.

 Основні принципи реалізації програмно-технічних засобів захисту інфор-мації полягають в наступному [21]:

 1. Функції і механізми захисту

 Основними завданнями засобів захисту є ізоляція об'єктів КС всередині сфери керування, перевірка всіх запитів доступу до об'єктів і реєстрація запитів і результатів їх перевірки і/або виконання. З одного боку, будь-яка елементарна функція будь-якої з послуг, що реалізуються засобами захисту, може бути віднесена до функцій ізоляції, перевірки або реєстрації. З іншого боку, будь-яка з функцій, що реалізуються засобами захисту, може бути віднесена до функцій забезпечення конфіденційності, цілісності і доступності інформації або керованостi КС і спостереженостi дій користувачів.

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

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

 Для реалізації певних послуг можуть використовуватись засоби крипто-графічного захисту. Криптографічні перетворення можуть використовуватись безпосередньо для захисту певної інформації (наприклад, при реалізації послуг конфіденційності) або підтримувати реалізацію послуги (наприклад, при реалі-зації послуги iдентифікації і автентифікації). Згідно із аконодавством створення переліку вимог, сертифікація і атестація систем шифрування покладається на відповідний уповноважений орган виконавчої влади. Ця діяльність регламентується “Положенням про порядок здійснення криптографічного захисту інформації в Україні”.

 2. Реалізація комплексу засобів захисту

 До реалізації КЗЗ пред'являється ряд вимог.

 По-перше, КЗЗ повинен забезпечувати безперервний захист об'єктів КС. Не повинно існувати можливості одержати доступ до об'єктів КС в обхід КЗЗ. КЗЗ, що реалізує політику безпеки, має бути безперервно захищений від злому і несанкціонованої модифікацiї. Жодна КС, що реалізує функції захисту, не може вважатись такою, якщо базові апаратні і програмні механізми, що реалізують політику безпеки, самі є суб'єктами для несанкціонованої модифікації або заміни.

 По-друге, КЗЗ повинен мати модульну структуру. На рівні розгляду архітектури КС "модульність" означає, що КЗЗ має бути реалізований як набір відносно незалежних частин. Кожна з цих частин повинна взаємодіяти з іншими тільки через добре визначені iнтерфейси. На рівні розгляду архітектури КЗЗ "модульність" означає, що КЗЗ має бути спроектовано як набір логічних груп програмного і апаратного забезпечення так, щоб кожна група вирішувала певні завдання. Для ПЗ, наприклад, в простішому випадку під цим слід розуміти, що подібні функції мають бути зосереджені в певних вихідних файлах. Під жорсткiшими вимогами слід розуміти використання приховання даних, iнкапсуляцiї та інших механізмів, що дозволяють мати впевненість, що кожний модуль вирішує єдине завдання і що всі дані, якими він оперує, або визначені всередині і доступні як локальні, або передаються як параметри або схожим чином. Будь-яка взаємодія між компонентами повинна здійснюватись тільки через відомі і описані канали (iнтерфейси). Оскільки не в усіх випадках це можливо, то за умови забезпечення відповідних гарантій реалізації використання глобальних змінних допускається, хоч і не рекомендується. Посилення вимог до модульностi КЗЗ приводить до необхідності побудови КЗЗ відповідно до принципів пошарової архітектури: КЗЗ має бути спроектовано як набір груп функцій (шарів), що взаємодіють тільки з сусідніми нижнім і верхнім шарами.

 3. Концепція диспетчера доступу

 При реалізації КЗЗ використовується концепція диспетчера доступу. Ця концепція не єдино можливий метод, проте є найбільш опрацьованою теоретично і перевіреною на практиці.

 Диспетчер доступу характеризується трьома атрибутами:

 - забезпечує безперервний і повний захист;

 - достовірний (захищений від модифікації);

 - має невеликі розміри.

 Це означає, що диспетчер доступу має бути завжди активним і повинен контролювати всі запити на доступ до будь-якого захищеного об'єкта, який піддається впливу. Диспетчер доступу має бути захищений від модифікацiї, що для програмної реалізації звичайно вважається ізоляцією домену КЗЗ від доменів інших процесів. І, нарешті, диспетчер доступу повинен мати невеликі розміри, щоб код (реалізація) був зрозумілим і його можна було перевірити в процесі оцінки. Термін "невеликий" (або "мiнiмiзований ") є відносним. На практиці це означає, що диспетчер доступу не повинен складати весь КЗЗ, а повинен включати мінімально необхідний набір механізмів, що безпосередньо реалізують перевірку легальностi запитів на доступ і, можливо, реєстрацію цих запитів.

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

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

 Узагальненням концепції диспетчера доступу є ідея герметизації, коли кожний об'єкт як би герметизовано диспетчером доступу, що утворює навкруги нього непрониклу оболонку. Кількість захищених (що знаходяться всередині оболонки) об'єктів може вар’юватись від одного об'єкта до всіх об'єктів системи. Таке подання є розширенням класичного підходу для розподілених і об'єктно-орієнтованих систем.

 Методи реалізації концепції диспетчера доступу можуть бути різними. Незалежно від реалізації диспетчер доступу повинен забезпечити неможливість доступу до об'єкта в обхід механізмів захисту, перевірку наявності у користувача і/або процесу прав доступу до об'єкта і реєстрації подій, що відбуваються. Найбільш широке розповсюдження одержала реалізація класичного погляду на диспетчер доступу, яка називається "ядром захисту".

 Специфічні практичні вимоги до організації систем захисту інформації в автоматизованих банківських системах (АБС) висунуті НБУ в „Положенні про організацію операційної діяльності в банках України” [16]:

 1. Заходи контролю за системою автоматизації обліку мають передбачати перевіряння:

 - відповідності програмно-технічних комплексів вимогам нормативно-правових актів Національного банку;

 - виконання вимог розробників програмно-технічних комплексів щодо технічного та технологічного забезпечення;

 - виконання вимог щодо організації захисту інформації під час користування програмно-технічними комплексами згідно з нормативно-правовими актами Національного банку та вимогами розробників систем захисту інформації.

 2. Банки мають забезпечувати контроль за системою автоматизації обліку та перевіряти відповідність програмно-технічних засобів вимогам нормативно-правових актів Національного банку.

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

 3. За допомогою програмно-технічних засобів має забезпечуватися:

 - хронологічне та систематичне відображення всіх операцій на аналітичних рахунках бухгалтерського обліку на підставі первинних документів;

 - своєчасне та повне відображення всіх операцій відділення банку (філії) на балансі цього банку;

 - дотримання правил складання і подання фінансової та статистичної звітності банків;

 - взаємозв'язок даних синтетичного та аналітичного обліку;

 - накопичення та систематизація даних обліку в розрізі економічних показників, потрібних для складання звітності;

 - автоматизований розрахунок економічних показників, що визначені відповідними методиками Національного банку;

 - можливість оперативного аналізу фінансової діяльності банку в розрізі структурних підрозділів;

 - інтегрованість з електронними системами інформаційного обміну Національного банку;

 - інтегрованість з іншими складовими системи автоматизації банку, можливість отримувати інформацію про здійснені операції в будь-якому розрізі;

 - уніфікація програмно-технічних рішень та технологій для структурних підрозділів банку;

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

 4. Під час застосування програмно-технічних засобів має передбачатися таке:

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

 - доступ з робочого місця працівника лише до тієї інформації, що потрібна користувачу для безпосереднього виконання його обов'язків;

 - можливість докладного попереднього аналізу всієї вхідної інформації до часу її відображення в обліку;

 - реалізація правила "двох рук" (операція не може бути ініційована та виконана одним користувачем системи), за винятком операцій, що здійснюються платіжними та іншими автоматизованими системами;

 - реалізація банківського продукту згідно із затвердженою технологією оброблення інформації;

 - надання користувачам повідомлення про наявність викривленої та/або суперечливої інформації;

 - можливість автоматичного визначення джерела надходження суперечливої інформації та термінового інформування відповідних працівників банку про це і блокування роботи користувачів чи робочих місць до часу надання їм дозволу на проведення подальшої роботи;

 - прийняття користувачами правильного рішення про те, яке з джерел інформації слід вважати сумнівним, а яке - достовірним;

 - неможливість ігнорування інформації, що надійшла з будь-якого джерела;

 - автоматичне присвоєння протягом одного операційного дня кожній операції певного ідентифікатора (номера). Цей ідентифікатор (номер) має вноситися до відповідного електронного документа;

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

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

 - архівація - регламентна або позапланова (у разі потреби).

 5. Програмне забезпечення банку має відповідати таким вимогам інформаційної безпеки:

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

 - забезпечення належного захисту інформації під час її передавання між різними підсистемами формування та оброблення інформації;

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

 - автентифікація користувача на кожному робочому місці та під час здійснення будь-яких операцій;

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

 - наявність безперервного технологічного контролю за цілісністю інформації та накладання/перевіряння цифрового підпису на всіх банківських документах на всіх етапах їх оброблення;

 - передавання електронних банківських документів, втрата або несанкціоноване ознайомлення з якими може завдати збитків банку, його відокремленим підрозділам або клієнту банку, відповідними каналами зв'язку електронною поштою або в режимі on-line лише зашифрованими з обов'язковим наданням підтвердження про їх отримання;

 - обов'язкова реєстрація всіх спроб доступу, усіх операцій та інших дій, їх фіксація в автоматизованій системі в захищеному від модифікації електронному журналі з постійним контролем його цілісності.

 Крім того, банкам слід:

 - суворо дотримуватися і перевіряти виконання вимог щодо технічного та технологічного забезпечення їх діяльності, зокрема розміщення програмно-апаратних комплексів на таких комп'ютерах, що мають забезпечити їх надійне функціонування;

 - уживати заходів для забезпечення безперебійного електроживлення та наявності резервних каналів зв'язку;

 - перевіряти виконання вимог щодо організації захисту інформації в програмно-технічних комплексах згідно з нормативно-правовими актами Національного банку та вимогами розробників систем захисту інформації.

 До приміщень банків, в яких обробляється банківська інформації НЬУ висунуті специфічні вимоги, викладені в „Правилах з технічного захисту інформації для приміщень банків, у яких обробляються електронні банківські документи” [12]:

 1. Приміщення з обмеженим доступом - приміщення, у яких розташовані робочі місця з комп'ютерною технікою, обробляються електронні банківські документи, що містять відомості з грифом "Банківська таємниця", та інша електронна інформація, доступ до якої обмежений банком;

 2. Комутаційні кімнати - приміщення, у яких розташовано телекомуніка-ційне обладнання, що забезпечує функціонування локальних і корпоративних мереж банку, а також зв'язок з іншими установами та мережами загального користування;

 3. Серверні приміщення - приміщення, у яких розташовані сервери баз даних, сервери прикладних програм, файлові сервери тощо, на яких обробляються та зберігаються електронні банківські документи і бази даних.

 До систем «електронної пошти» та „електронних банківських платежів” між комерційними банками та Національним банком України висунуті вимоги застосування апаратного та програмного криптографічного захисту файлової інформації згідно „Правил організації захисту електронних банківських документів з використанням засобів захисту інформації Національного банку України” [11]:

 1. У тексті Правил скорочення вживаються в такому значенні:

 АКЗІ - апаратура криптографічного захисту інформації;

 АРМ - автоматизоване робоче місце;

 АРМ бухгалтера САБ - автоматизоване робоче місце САБ, на якому здійснюється формування файлів / онлайнових пакетів, які містять початкові платежі СЕП;

 АРМ-СЕП - автоматизоване робоче місце АРМ-НБУ з програмними та апаратними засобами захисту інформації, яке призначене для роботи в СЕП;

 АРМ-НБУ - автоматизоване робоче місце АРМ-НБУ-інформаційний з програмними засобами захисту інформації, яке призначене для роботи в інформаційних задачах Національного банку;

 АС - автоматизована система;

 ВК - відкритий ключ;

 ГМД - гнучкий магнітний диск;

 ЕЦП - електронний цифровий підпис;

 засоби захисту - засоби захисту інформації Національного банку;

 інформаційні задачі - програмно-технічні комплекси, які забезпечують оброблення та передавання інформації, що не належить до платіжних документів СЕП, з використанням засобів захисту інформації Національного банку між банками України, Національним банком, органами державної влади і небанківськими організаціями;

 ПЕОМ - персональна електронна обчислювальна машина;

 ПМГК - програмний модуль генерації ключів;

 ТК - таємний ключ;

 САБ - система автоматизації банку;

 СЕП - система електронних платежів;

 СК - смарт-картка;

 ТВК - таблиця відкритих ключів.

 2. Правила регламентують порядок отримання, обліку, передавання, використання та зберігання засобів захисту, виконання вимог щодо правил інформаційної безпеки в банках України, їх філіях, органах державної влади, небанківських установах, які є безпосередніми учасниками системи електронних платежів (далі - СЕП) та/або інформаційних задач (далі - організація), які згідно з договором з Національним банком отримали засоби захисту.

 3. Організації отримують засоби захисту для використання в СЕП та/або інформаційних задачах Національного банку в територіальних управліннях Національного банку за місцем їх знаходження незалежно від моделі обслуговування кореспондентського рахунку в СЕП.

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

 5. Система захисту електронних банківських документів охоплює всі етапи розроблення, упровадження й експлуатації програмно-технічного забезпечення СЕП та інформаційних задач автоматизації банківської діяльності. Ця система визначає чіткий розподіл відповідальності на кожному етапі підготовки, оброблення та виконання електронних банківських документів на всіх рівнях.

 6. Організація, яка використовує засоби захисту, зобов'язана мати приміщення, у яких обробляються електронні банківські документи, використовуються та зберігаються в неробочий час засоби захисту, які відповідають вимогам НБУ.

 Принципи побудови захисту електронних банківських документів в СЕП НБУ [ ]:

 1. Система захисту електронних банківських документів (далі - система захисту) забезпечує:

 а) захист від несанкціонованої модифікації та несанкціонованого ознайомлення зі змістом електронних банківських документів на будь-якому етапі їх оброблення;

 б) автоматичне ведення захищеного від несанкціонованої модифікації протоколу оброблення електронних банківських документів з метою визначення причин появи порушень роботи програмно-технічних комплексів у СЕП;

 в) захист від технічних порушень роботи апаратури (у тому числі від псування апаратних і програмних засобів, перешкод у каналах зв'язку);

 г) умови для роботи програмно-технічних комплексів у СЕП, за яких фахівці банків - учасників СЕП і Національного банку не можуть утручатися в оброблення електронних банківських документів після їх формування, та автоматичний контроль на кожному етапі їх оброблення.

 2. Система захисту:

 а) охоплює всі етапи розроблення, упровадження та експлуатації програмно-технічного забезпечення в банках (філіях);

 б) уключає технологічні, апаратні, програмні засоби та організаційні заходи захисту;

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

 3. Технологічні засоби безпеки в СЕП

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

 3.2. Технологічні засоби контролю включають:

 механізм обміну квитанціями, який дає змогу однозначно ідентифікувати отримання адресатом будь-якого файла або пакета електронних банківських документів у СЕП і забезпечує можливість контролю отриманої в ньому інформації;

 механізм інформування банку - учасника СЕП щодо поточного стану його кореспондентського рахунку за підсумками циклів оброблення платежів у ЦОСЕП;

 механізм надання банку - учаснику СЕП інформації щодо поточного стану його технічного рахунку;

 взаємообмін між банком і ЦОСЕП технологічною інформацією за підсумками банківського дня з переліком відображених за технічним рахунком міжбанківських електронних розрахункових документів, які оброблені засобами СЕП у файловому режимі та режимі реального часу, що дає змогу здійснювати їх програмне звіряння як у ЦОСЕП, так і в банку;

 програмний комплекс самодіагностики, який дає змогу виявляти порушення цілісності баз даних програмного забезпечення ЦОСЕП, псування яких може виникнути внаслідок порушень функціонування системи, спроб несанкціонованого доступу або фізичного псування баз даних;

 автоматичний механізм контролю за несанкціонованим модифікуванням робочих модулів;

 механізм резервування для забезпечення швидкого відновлення роботи ЦОСЕП з мінімальними втратами інформації.

 Технологічні засоби контролю, убудовані в програмне забезпечення, не можуть бути відключені. У разі виникнення нестандартної ситуації або підозри щодо несанкціонованого доступу ЦОСЕП автоматично формує повідомлення для оперативного реагування ЦРП.

 До засобів контролю включають також:

 технологічну інформацію ЦОСЕП про стан технічних рахунків і стан функціонування СЕП за підсумками банківського дня;

 засоби аналізу причин невідповідності балансу.

 4. Криптографічний захист інформації

 4.1. Апаратно-програмні засоби криптографічного захисту інформації в СЕП забезпечують автентифікацію відправника та отримувача електронних банківських документів і службових повідомлень СЕП, гарантують їх достовірність та цілісність, неможливість підроблення або викривлення документів у шифрованому вигляді та за наявності ЕЦП.

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

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

 4.2. Для здійснення суворої автентифікації банків (філій), які є учасниками СЕП, застосовується система ідентифікації користувачів, яка є основою системи розподілу ключів криптографічного захисту.

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

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

 Ідентифікатори ключів записуються в апаратуру криптографічного захисту інформації (далі - АКЗІ), яка надається учасникам СЕП і забезпечує апаратне формування (перевірку) ЕЦП та апаратне шифрування (розшифрування) на АРМ-СЕП.

 4.3. Для забезпечення захисту інформації від модифікації з одночасною суворою автентифікацією та безперервного захисту електронних банківських документів з часу їх формування система захисту СЕП уключає механізми формування (перевірки) ЕЦП на базі несиметричних алгоритмів RSA та ДСТУ 4145. Для забезпечення роботи алгоритму RSA учасник СЕП отримує від територіального управління персональний генератор ключів з убудованим ідентифікатором учасника СЕП. За допомогою цього генератора ключів учасник СЕП має змогу генерувати ключі для всіх робочих місць, де працюють з електронними банківськими документами. Кожен таємний ключ робочого місця обов'язково має бути захищений особистим паролем відповідальної особи, яка працює з цим ключем. Для забезпечення захисту ключової інформації (а саме відкритих ключів) від несанкціонованої модифікації відкриті ключі ЕЦП мають надсилатися до Департаменту інформатизації для сертифікації (крім відкритих ключів для робочих місць операціоністів, що використовуються лише в САБ).

 Генерація ключів для АКЗІ здійснюється на комп'ютері, де розміщується програмно-технічний комплекс АРМ-СЕП, за допомогою генератора, убудованого в АРМ-СЕП. Для забезпечення безперебійної роботи АРМ-СЕП з апаратурою захисту під час генерації ключа АКЗІ згенерований ключ повинен записуватися на дві смарт-картки (основну та резервну).

 Учасник СЕП зобов'язаний забезпечити дотримання механізму накладання (перевірки) ЕЦП згідно з вимогами цієї глави, які унеможливлюють формування та відсилання електронного банківського документа однією службовою особою.

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

 Технологія оброблення платежів у САБ учасника СЕП забезпечує надійний розподіл доступу під час оброблення електронних банківських документів і захист цих документів від модифікації в локальній мережі банку. Виконання технології використання ЕЦП на всіх етапах оброблення електронних банківських документів є обов'язковою вимогою для всіх типів САБ, які працюють у банках (філіях), незалежно від моделі обслуговування консолідованого кореспондентського рахунку.

 4.4. Для забезпечення конфіденційності інформація СЕП обробляється АРМ-СЕП, яке включає вбудовані засоби захисту інформації та забезпечує апаратне і програмне шифрування (розшифрування) інформації.

 Основним засобом шифрування файлів (пакетів) СЕП є АКЗІ. Робота АКЗІ контролюється вбудованими в АРМ-СЕП програмними засобами захисту інформації і забезпечує апаратне шифрування (розшифрування) інформації за стандартом ГОСТ 28147.

 Як резервний засіб шифрування в СЕП використовується вбудована в АРМ-СЕП функція програмного шифрування. Для кожного файла (пакета) СЕП, що обробляється АРМ-СЕП, генерується одноразовий ключ шифрування для алгоритму ГОСТ 28147-89, який обробляється відповідно до стандарту ISO 11166-94 і додається до повідомлення в зашифрованому вигляді. Такий спосіб передавання повідомлень забезпечує, що лише дійсний отримувач повідомлення має змогу виконати його розшифрування.

 Засоби шифрування АРМ-СЕП (як АКЗІ, так і програмне шифрування) забезпечують сувору автентифікацію відправника та отримувача електронного банківського документа, цілісність кожного документа в результаті неможливості його підроблення або несанкціонованого модифікування в шифрованому вигляді.

 АРМ-СЕП в режимі реального часу забезпечує додаткову сувору взаємну автентифікацію АРМ-СЕП учасника СЕП та ЦОСЕП під час встановлення сеансу зв'язку.

 Під час роботи АРМ-СЕП створює шифровані архіви оброблених електронних банківських документів та захищений від модифікації протокол роботи АРМ-СЕП, у якому фіксуються всі дії, що ним виконуються, із зазначенням дати та часу оброблення електронних банківських документів. Наприкінці банківського дня шифровані архіви та протокол роботи АРМ-СЕП підлягають обов'язковому збереженню в архіві. Цей архів використовується для надання Національним банком інформаційних послуг відповідно до глави 6 цього розділу.

 4.5. Основою криптографічного захисту є ключова інформація та ключі.

 Ключова інформація містить ключі асиметричного криптографічного алгоритму, що генеруються учасником СЕП за допомогою наданих генераторів ключів та АРМ-СЕП для АКЗІ, а також ключів, що використовуються для апаратного шифрування у формі захищених записів на смарт-картках АКЗІ. Ключова інформація під час роботи АКЗІ використовується виключно всередині смарт-картки, що унеможливлює підроблення та перехоплення ключової інформації. Департамент інформатизації виготовляє АКЗІ та смарт-картки для кожного учасника СЕП на замовлення територіального управління, яке надає їх учасникам СЕП відповідно до умов договору.

 Ключова інформація для програмного шифрування та для ЕЦП має генеруватися безпосередньо відповідальною особою банку (філії) у присутності адміністратора захисту інформації банку (філії) за допомогою генератора ключів, який надається учаснику СЕП територіальним управлінням. Генератори ключів є персональними для кожного учасника СЕП, мають убудований унікальний ідентифікатор учасника СЕП, який не може бути вилучений або змінений. Генератори мають змогу запису таємного ключа на носії двох видів - на дискету або на Touch Memory, у якому додатково вбудований захист від копіювання ключової інформації з одного носія на інший. Таємні ключі, які зберігаються на дискетах, обов'язково мають бути захищені паролем, що забезпечує додатковий захист від спроб несанкціонованого використання скопійованих таємних ключів. Довжина пароля становить шість символів і не може бути зменшена.

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

 В національних системах платежів за допомогою пластикових карток НБУ висунув вимоги до організації захисту інформації, викладені в „ Положенні про захист інформації в Національній системі масових електронних плате-жів” [13]:

 1. Вимоги Положення регламентують порядок отримання, обліку, використання, зберігання та виводу з обігу апаратно-програмних засобів захисту інформації Національної системи масових електронних платежів (далі - засоби захисту НСМЕП) та виконання правил інформаційної безпеки членами та учасниками НСМЕП.

 2. У цьому Положенні вживається наступна специфічна термінологія:

 АКС - автоматизована карткова система;

 АРМ - автоматизоване робоче місце;

 БПЦ - банківський процесинговий центр;

 БТ - банківська таємниця;

 БЦГКІ - банківський центр генерації ключової інформації;

 ГПЦ - головний процесинговий центр;

 ЗПЦ - "зовнішній" процесинговий центр (ЦОМП, студентський ПЦ тощо), не є процесинговим центром НСМЕП, але потребує обміну інформацією з РПЦ/ГПЦ;

Страницы: 1, 2, 3, 4, 5, 6, 7, 8