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

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

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

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

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

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

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

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

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

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

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