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

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

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

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

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

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

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

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

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

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

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