МЕНЮ


Фестивали и конкурсы
Семинары
Издания
О МОДНТ
Приглашения
Поздравляем

НАУЧНЫЕ РАБОТЫ


  • Инновационный менеджмент
  • Инвестиции
  • ИГП
  • Земельное право
  • Журналистика
  • Жилищное право
  • Радиоэлектроника
  • Психология
  • Программирование и комп-ры
  • Предпринимательство
  • Право
  • Политология
  • Полиграфия
  • Педагогика
  • Оккультизм и уфология
  • Начертательная геометрия
  • Бухучет управленчучет
  • Биология
  • Бизнес-план
  • Безопасность жизнедеятельности
  • Банковское дело
  • АХД экпред финансы предприятий
  • Аудит
  • Ветеринария
  • Валютные отношения
  • Бухгалтерский учет и аудит
  • Ботаника и сельское хозяйство
  • Биржевое дело
  • Банковское дело
  • Астрономия
  • Архитектура
  • Арбитражный процесс
  • Безопасность жизнедеятельности
  • Административное право
  • Авиация и космонавтика
  • Кулинария
  • Наука и техника
  • Криминология
  • Криминалистика
  • Косметология
  • Коммуникации и связь
  • Кибернетика
  • Исторические личности
  • Информатика
  • Инвестиции
  • по Зоология
  • Журналистика
  • Карта сайта
  • Моделювання ефективності комплексної системи захисту автоматизованих інформаційних ресурсів комерційного банку

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

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

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

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

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

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

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

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

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

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

     Якщо система реалізує адміністративне керування доступом, то атрибути доступу об'єкта мають зберігатись під час його експорту на зовнішній нос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 лише зашифрованими з обов'язковим наданням підтвердження про їх отримання;

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


    Приглашения

    09.12.2013 - 16.12.2013

    Международный конкурс хореографического искусства в рамках Международного фестиваля искусств «РОЖДЕСТВЕНСКАЯ АНДОРРА»

    09.12.2013 - 16.12.2013

    Международный конкурс хорового искусства в АНДОРРЕ «РОЖДЕСТВЕНСКАЯ АНДОРРА»




    Copyright © 2012 г.
    При использовании материалов - ссылка на сайт обязательна.