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

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

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

 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. За допомогою програмно-технічних засобів має забезпечуватися:

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

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

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

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

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

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

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20