2018-02-13
181
Виходячи з основних положень об'єктно-орієнтованого підходу, слід в першу чергу визнати застарілим традиційний поділ на активні і пасивні сутності (суб'єкти та об'єкти у звичній для дооб'єктної ІБ термінології). Подібний розподіл застарілий, принаймні, з двох причин.
По-перше, в об'єктному підході пасивних об'єктів немає. Можна вважати, що всі об'єкти активні одночасно і при необхідності викликають методи один одного. Як реалізовані ці методи (і, зокрема, як організований доступ до змінних і їх значенням) - внутрішня справа викликається об'єкта; деталі реалізації приховані, інкапсульовані. Зухвалому об'єкту доступний тільки надається інтерфейс.
По-друге, не можна сказати, що якісь програми (методи) виконуються від імені користувача. Реалізації об'єктів складні, так що останні не можна розглядати лише як інструменти виконання волі користувачів. Швидше можна вважати, що користувач прямо або (як правило) побічно, на свій страх і ризик, "просить" деякий об'єкт про певну інформаційної послуги. Коли активізується викликається метод, об'єкт діє скоріше від імені (в усякому разі, з волі) свого творця, ніж від імені викликав його користувача. Можна вважати, що об'єкти мають достатньої "свободою волі", щоб виконувати дії, про які користувач не тільки не просив, але навіть не здогадується про їх можливості. Особливо це справедливо у мережевому середовищі і для програмного забезпечення (ПЗ), отриманого через Internet, але може виявитися вірним і для комерційного ПЗ, закупленого за всіма правилами у солідної фірми.
Для ілюстрації наведемо наступний гіпотетичний приклад. Банк, ІС якого має з'єднання з Internet, придбав за кордоном автоматизовану банківську систему (АБС). Тільки через деякий час у банку вирішили, що зовнішнє з'єднання потребує захисту, і встановили міжмережевий екран.
Вивчення реєстраційної інформації екрану показало, що час від часу за рубіж відправляються IP-пакети, що містять якісь незрозумілі дані (напевно, зашифровані, вирішили в банку). Стали розбиратися, куди ж пакети направляються, і виявилося, що йдуть вони у фірму, розробила АБС. Виникла підозра, що в АБС вбудована закладка, щоб отримувати інформацію про діяльність банку. Зв'язалися з фірмою;там дуже здивувалися, спочатку все заперечували, але врешті-решт з'ясували, що один з програмістів не прибрав з поставленого в банк варіанту налагоджувальну видачу, яка була організована через мережу (як передача IP-пакетів специфічного виду,з явно заданим IP-адресою робочого місця цього програміста).Таким чином, ніякого злого наміру не було, проте деякий час інформація про платежі вільно гуляла по мережам.
У подальшій частині курсу, в лекції, присвяченій розмежування доступу, ми обговоримо, як можна кардинальним чином вирішити подібні проблеми. Тут відзначимо лише, що при визначенні допустимості доступу важливо не тільки (і не стільки), хто звернувся до об'єкта, але і те, яка семантика дії. Без залучення семантики не можна визначити так звані "троянські програми", що виконують, крім декларованих, деякі приховані (зазвичай негативні) дії.
Мабуть, слід визнати застарілим і положення про те, що розмежування доступу направлена на захист від зловмисників. Наведений вище приклад показує, що внутрішні помилки розподілених ІС представляють не меншу небезпеку, а гарантувати їх відсутність у складних системах сучасна технологія програмування не дозволяє.
У дооб'єктній ІБ одним з найважливіших вимог є безпека повторного використання пасивних сутностей (таких, наприклад, як динамічно виділяються області пам'яті). Очевидно, подібна вимога вступає в конфлікт з таким фундаментальним принципом, як інкапсуляція. Об’єкт не можна очистити зовнішнім образом (заповнити нулями або випадковою послідовністю біт), якщо тільки він сам не надає відповідний метод. При наявності такого методу надійність очищення залежить від коректності його реалізації і виклику.
Одним з найміцніших стереотипів серед фахівців з ІБ є трактування операційної системи як домінуючого засобу безпеки. На розробку захищених ОС виділяються значні кошти, часто на шкоду решті напрямів захисту і, отже, на шкоду реальної безпеки. У сучасних ІС, збудованих в багаторівневій архітектурі клієнт / сервер, ОС не контролює об'єкти, з якими працюють користувачі, так само як і дії самих користувачів, які реєструються і враховуються прикладними засобами. Основною функцією безпеки ОС стає захист можливостей, що надаються привілейованим користувачам, від атак користувачів звичайних.
Це важливо, але безпека такими заходами не вичерпується. Далі ми розглянемо підхід до побудови програмно-технічного рівня ІБ у вигляді сукупності сервісів безпеки.
