Об'єктно-орієнтований підхід та інформаційна безпека

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

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

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

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

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

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

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

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

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

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

Переваги, властиві об'єктно-орієнтованому підходу:

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

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

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

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

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

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

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

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

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

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

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

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

Очевидно, для всіх виділених, відносно незалежних граней діє принцип інкапсуляції (це і означає, що грані "відносно незалежні").

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

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

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

 

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

 

Подібна точка зору може показатися неспроможною, але це не так.

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

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

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

На програмно-технічному рівні можуть бути визначені переважні апаратно-програмні платформи тощо.

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

 

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

 

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

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

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

 

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

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

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

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

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

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

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

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