загрузка...
загрузка...
На головну

На інформаційну безпеку

  1. Громадянське суспільство, держава і соціальна безпека.
  2. Пожежна безпека.
  3. Електробезпека.
  4. Енергобезпеки. ШЛЯХИ РОЗВИТКУ ЕНЕРГЕТИКИ

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

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

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

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

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

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

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

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

об'єкт - Це елемент класу, тобто абстракція певної сутності.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Застосування об'єктно-орієнтованого підходу до розгляду захищаються систем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мал. 2.1. ІС при розгляді з рівнем деталізації 1.

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

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

Мал. 2.2. ІС при розгляді з рівнем деталізації 2.

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

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

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

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

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

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

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

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

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





Введення в дисципліну. | Предметні напрямки ЗІ. | Види загроз І. Б. | Тема 4. Види заходів забезпечення інформаційної безпеки. | Технічні заходи захисту інформації. | Захист від збоїв в електроживленні | Захист від збоїв пристроїв для зберігання інформації. | Захист від витоків інформації електромагнітних випромінювань. | Тема 5. Адміністративний рівень захисту інформації. | Політика безпеки |

загрузка...
© um.co.ua - учбові матеріали та реферати