Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
основи Інформаційної безпеки 2.doc
Скачиваний:
26
Добавлен:
01.05.2019
Размер:
1.13 Mб
Скачать

2.4. Недоліки традиційного підходу до інформаційної безпеки з об'єктної точки зору

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

По-перше, в об'єктному підході пасивних об'єктів немає. Можна вважати, що всі об'єкти активні одночасно й при необхідності викликають методи один одного. Як реалізовані ці методи (і, зокрема, як організований доступ до змінних і їхній значень) - власна справа викликаного об'єкта; деталі реалізації приховані, інкапсульовані. Зухвалому об'єкту доступний тільки надаваний інтерфейс. По-друге, не можна сказати, що якісь програми (методи) виконуються від імені користувача. Реалізації об'єктів складні, так що останні не можна розглядатилише як інструменти виконання волі користувачів. Можна вважати, щокористувач так чи інакше, на свій страх і ризик, "просить" деякий об'єкт проконкретну інформаційну послугу. Коли активізується викликуваний метод, об'єктдіє скоріше від імені (у всякому разі, з волі) свого творця, ніж від імені його користувача, який його викликав. Можна вважати, що об'єкти мають достатню"силу волі", щоб виконувати дії, про які користувач не тільки не просив, але навіть не здогадується про їхні можливості. Особливо це справедливо в мережевому середовищі й для програмного забезпечення (ПЗ), отриманого через Internet, але може буди придатним і для комерційного ПЗ, закупленого за всіма правилами всолідній фірмі.

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

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

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

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

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

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

Це важливо, але безпека такими заходами не вичерпується. Далі мирозглянемо підхід до побудови програмно-технічного рівня ІБ у вигляді сукупності сервісів безпеки.

Розділ 3. Найпоширеніші загрози