Материал: 7_ua_

2 Розповсюдження об’єктно-орієнтованого підходу на інформаційну безпеку.

2.1 Про необхідність об’єктно-орієнтованого підходу до інформаційної безпеки

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

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

Об’єктно-орієнтований підхід є основою сучасної технології програмування, випробуваним методом боротьби з складністю систем. Представляється природним і, більш того, необхідним, прагнення розповсюдити цей підхід і на системи інформаційної безпеки, для яких, як і для програмування в цілому, має місце згадана проблема складності.

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

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

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

2.2 Основні поняття об’єктно-орієнтованого підходу

Об’єктно-орієнтований підхід використовує об’єктну декомпозицію, тобто поведінка системи описується в термінах взаємодії об’єктів.

Що ж розуміється під об’єктом і які інші основоположні поняття даного підходу?

Перш за все, введемо поняття класу. Клас – це абстракція безлічі єств реального миру, з’єднаних спільністю структури і поведінки.

Об’єкт – це елемент класу, тобто абстракція певного єства.

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

До активності об’єктів ми ще повернемося.

Наступну групу найважливіших понять об’єктного підходу складають інкапсуляція, спадкоємство і поліморфізм.

Основним інструментом боротьби з складністю в об’єктно-орієнтованому підході є Основним інструментом боротьби з складністю в об’єктно-орієнтованому підході є інкапсуляція - заховання реалізації об’єктів (їх внутрішньої структури і деталей реалізації методів) з наданням зовні тільки строго певних інтерфейсів.

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

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

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

Ми ще повернемося до механізму спадкоємства при розгляді ролевого управління доступом. Поповнимо розглянутий вище класичний набір понять об’єктно-орієнтованого підходу ще двома поняттями: грані об’єкту і рівня деталізації.

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

Поняття рівня деталізації важливе не тільки для візуалізації об’єктів, але і для систематичного розгляду складних систем, представлених в ієрархічному вигляді. Саме по собі воно дуже просте: якщо черговий рівень ієрархії розглядається з рівнем деталізації n > 0, то наступний - з рівнем (n - 1). Об’єкт з рівнем деталізації 0 вважається атомарним.

Поняття рівня деталізації показу дозволяє розглядати ієрархії з потенційно нескінченною висотою, варіювати деталізацію як об’єктів в цілому, так і їх граней.

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

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

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

Компонентні об’єктні середовища володіють всіма достоїнствами, властивими об’єктно-орієнтованому підходу:

• інкапсуляція об’єктних компонентів приховує складність реалізації, роблячи видимим інтерфейс, що тільки надається зовні;

• спадкоємство дозволяє розвивати створені раніше компоненти, не порушуючи цілісність об’єктної оболонки;

• поліморфізм по суті дає можливість групувати об’єкти, характеристики яких з деякої точки зору можна вважати схожими.

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

На цьому ми завершуємо опис основних понять об’єктно-орієнтованого підходу.

2.3 Вживання об’єктно-орієнтованого підходу до розгляду систем, що захищаються

Спробуємо застосувати об’єктно-орієнтований підхід до питань інформаційної безпеки.

Проблема забезпечення інформаційної безпеки - комплексна, захищати доводиться складні системи, і самі захисні засоби теж складні, тому нам знадобляться всі введені поняття. Почнемо з поняття грані.

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

Таким чином, ми структурували нашу мету. Тепер потрібно структурувати засоби її досягнення. Введемо наступні грані:

• законодавчі заходи забезпечення інформаційної безпеки;

• адміністративні заходи (накази і інші дії керівництва організацій, пов’язаних з інформаційними системами, що захищаються);

• процедурні заходи (заходи безпеки, орієнтовані на людей);

• програмно-технічні заходи.

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

Очевидно, для всіх виділених, відносно незалежних граней діє принцип інкапсуляції (це і значить, що грані "відносно незалежні"). Більш того, ці дві сукупності граней можна назвати ортогональними, оскільки для фіксованої грані в одній сукупності (наприклад, доступності) грані в іншій сукупності повинні пробігати всю безліч можливих значень (потрібно розглянути законодавчі, адміністративні, процедурні і програмно-технічні заходи). Ортогональних совокупностей не повинне бути багато; думається, двох совокупностей з числом елементів, відповідно, 3 і 4 вже достатньо, оскільки вони дають 12 комбінацій.

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

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

При погляді з нульовим рівнем деталізації ми побачимо лише те, що у організації є інформаційна система (див. рис. 1).

Рисунок 1. ІС при розгляді з рівнем деталізації 0.

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

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

Рисунок 2. ІС при розгляді з рівнем деталізації 1.

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

На другому рівні деталізації ми побачимо наступне (див. рис. 3).

Рисунок 3. ІС при розгляді з рівнем деталізації 2.

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

Знаходячись на рівні деталізації 2, ми повинні враховувати закони, застосовні до організацій, ІС яких забезпечені зовнішніми підключеннями. Йдеться про допустимість такого підключення, про його захист, про відповідальність користувачів, що звертаються до зовнішніх сервісів, і про відповідальність організацій, що відкривають свої сервіси для зовнішнього доступу. Конкретизація аналогічної спрямованості, з урахуванням наявності зовнішнього підключення, повинна бути виконана на адміністративному, процедурному і програмно-технічному рівнях.

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

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

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

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

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

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

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

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

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

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

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

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