Реферат: Основи інформаційної безпеки
За якими критеріями проводити декомпозицію ІС - в значній мірі справа смаку. Вважатимемо, що на першому рівні деталізації робляться видимими сервіси і користувачі, точніше, поділ на клієнтську і серверну частину (рис. 1.3).
Рисунок 1.3 - ІС при розгляді з рівнем деталізації 1
На цьому рівні слід сформулювати вимоги до сервісів (до самого їх наявності, до доступності, цілісності і конфіденційності інформаційних послуг, що надаються), викласти способи виконання цих вимог, визначити загальні правила поведінки користувачів, необхідний рівень їх попередньої підготовки, методи контролю їх поведінки, порядок заохочення і покарання тощо. Можуть бути сформульовані вимоги і переваги по відношенню до серверних і клієнтських платформ.
На другому рівні деталізації ми побачимо наступне (див. рис. 1.4).
Рисунок 1.4 - ІС при розгляді з рівнем деталізації 2
На цьому рівні нас все ще не цікавить внутрішня структура ІС організації, рівно як і деталі Internet. Констатується тільки існування зв'язку між цими мережами, наявність в них користувачів, а також внутрішніх та зовнішніх сервісів. Що це за сервіси, поки неважливо.
Знаходячись на рівні деталізації 2, ми повинні враховувати закони, застосовні до організацій, ІС яких забезпечені зовнішніми підключеннями. Йдеться про допустимість такого підключення, про його захист, про відповідальність користувачів, що звертаються до зовнішніх сервісів, і про відповідальність організацій, що відкривають свої сервіси для зовнішнього доступу. Конкретизація аналогічної спрямованості, з урахуванням наявності зовнішнього підключення, повинна бути виконана на адміністративному, процедурному і програмно-технічному рівнях.
Збільшуючи рівень деталізації, можна розгледіти два рознесені виробничі майданчики і канали зв'язку між ними, розподіл сервісів і користувачів за цими майданчиками і засоби забезпечення безпеки внутрішніх комунікацій, специфіку окремих сервісів, різні категорії користувачів тощо. Ми, проте, на цьому зупинимося.
Для ілюстрації переваг об'єктно-орієнтованого підходу приведемо наступний, вже традиційний, приклад. Банк, ІС якого має з'єднання з Internet, придбав за кордоном автоматизовану банківську систему. Тільки через деякий час в банку вирішили, що зовнішнє з'єднання потребує захисту, і встановили міжмережевий екран.
Вивчення реєстраційної інформації екрану показало, що час від часу за рубіж відправляються IP-пакети, що містять якісь незрозумілі дані (напевно, зашифровані, вирішили в банку). Стали розбиратися, куди ж пакети прямують, і виявилось, що йдуть вони у фірму, що розробила автоматизовану банківську систему. Виникла підозра, що в систему вбудована закладка, щоб одержувати інформацію про діяльність банку. Зв'язалися з фірмою; там дуже здивувалися, спочатку всі заперечували, але врешті-решт з'ясували, що один з програмістів не прибрав з поставленого в банк варіанту налагоджувальну видачу, яка була організована через мережу. Таким чином, ніякого злого наміру не було, проте якийсь час інформація про платежі вільно гуляла по мережам.
Внутрішні помилки розподілених ІС представляють не меншу небезпеку, а гарантувати їх відсутність в складних системах сучасна технологія програмування не дозволяє.
Одним з найміцніших стереотипів серед фахівців по ІБ є трактування операційної системи як домінуючого засобу безпеки. На розробку захищених ОС виділяються значні кошти, часто в збиток решті напрямів захисту і, отже, втрати реальної безпеки. У сучасних ІС, збудованих в багаторівневій архітектурі клієнт/сервер, ОС не контролює об'єкти, з якими працюють користувачі, рівно як і дії самих користувачів, які реєструються і враховуються прикладними засобами. Основною функцією безпеки ОС стає захист можливостей, що надаються привілейованим користувачам, від атак користувачів звичайних.
Це важливо, але безпека такими заходами не вичерпується. Далі ми розглянемо підхід до побудови програмно-технічного рівня ІБ у вигляді сукупності сервісів безпеки.