- •Основні теоретичні поняття криптології План
- •Основні терміни, визначення та предмет науки «криптологія»
- •Криптоаналіз
- •1 Основні терміни, визначення та предмет науки «криптологія»
- •2 Криптоаналіз
- •Контрольні запитання
- •Список літератури
- •Шифри перестановки План
- •2 Таблиці для шифрування
- •2.1 Таблиці для шифрування. Проста перестановка
- •2.2 Таблиці для шифрування. Одиночна перестановка по ключу
- •2.3 Таблиці для шифрування. Подвійна перестановка
- •2.4 Застосування магічних квадратів
- •Список літератури
- •Шифри простої заміни План
- •1 Полібіанський квадрат
- •2 Система шифрування Цезаря
- •Криптоаналіз шифру Цезаря
- •3 Аффінна система підстановок Цезаря
- •4 Система Цезаря із ключовим словом
- •5 Таблиці Трисемуса
- •Криптографічний аналіз системи одноалфавітної заміни
- •6 Біграмний шифр Плейфейра
- •7 Криптосистема Хілла
- •8 Система омофонів
- •Додаток а
- •Список літератури
- •Шифри складної заміни План
- •1 Шифр Гронсфельда
- •Криптоаналіз шифру Гронсфельда
- •2 Система шифрування Віженера
- •3 Шифр “Подвійний квадрат Уітстона”
- •4 Одноразова система шифрування
- •5 Шифрування методом Вернама
- •6 Роторні машини
- •7 Шифрування методом гамірування
- •Список літератури
- •Блочні шифри План
- •1 Алгоритм des
- •1 Алгоритм des
- •Обчислення значень ключів
- •Аналіз ефективності алгоритму des
- •Список літератури
- •Асиметричні криптосистеми План
- •Керування ключами План
- •1 Алгоритм шифрування Діффі - Хеллмана
- •Керування ключами
- •1 Алгоритм шифрування Діффі - Хеллмана
- •Контрольні питання
- •Список літератури
- •Криптографічні протоколи План
- •Контрольні запитання
- •Список літератури
- •Ідентифікація та перевірка істинності План
- •Інформаційна безпека План
- •1.2 Основні складові інформаційної безпеки
- •1.3 Важливість і складність проблеми інформаційної безпеки
- •2 Розповсюдження об’єктно-орієнтованого підходу на інформаційну безпеку.
- •2.1 Про необхідність об’єктно-орієнтованого підходу до інформаційної безпеки
- •2.2 Основні поняття об’єктно-орієнтованого підходу
- •2.3 Вживання об’єктно-орієнтованого підходу до розгляду систем, що захищаються
- •2.4 Недоліки традиційного підходу до інформаційної безпеки з об’єктної точки зору
- •2.5 Основні визначення і критерії класифікації загроз
- •Контрольні запитання
- •Список літератури
- •Інформаційна безпека Найпоширеніші загрози План
- •1 Найпоширеніші загрози доступності
- •1 Найпоширеніші загрози доступності
- •2 Деякі приклади загроз доступності
- •3 Шкідливе програмне забезпечення
- •4 Основні загрози цілісності
- •5 Основні загрози конфіденційності
- •Список літератури
- •1.2 Механізми безпеки
- •1.3 Класи безпеки
- •2 Інформаційна безпека розподілених систем. Рекомендації X.800
- •2.1 Мережні сервіси безпеки
- •2.2 Мережні механізми безпеки
- •2.3 Адміністрування засобів безпеки
- •3 Стандарт iso/iec 15408 "Критерії оцінки безпеки інформаційних технологій"
- •3.1 Основні поняття
- •3.2 Функціональні вимоги
- •3.3 Вимоги довір’я безпеці
- •4 Гармонізовані критерії європейських країн
- •5 Інтерпретація "Оранжевої книги" для мережних конфігурацій
- •Список літератури
- •Інформаційна безпека Управління ризиками План
- •2 Підготовчі етапи управління ризиками
- •3 Основні етапи управління ризиками
- •Список літератури
2.4 Недоліки традиційного підходу до інформаційної безпеки з об’єктної точки зору
Виходячи з основних положень об’єктно-орієнтованого підходу, слід в першу чергу визнати за застарілий традиційний розподіл на активні і пасивні єства (суб’єкти і об’єкти в звичній для дооб’єктной ІБ термінології). Подібний розподіл застарілий, принаймні, з двох причин.
По-перше, в об’єктному підході пасивних об’єктів немає. Можна вважати, що всі об’єкти активні одночасно і при необхідності викликають методи один одного. Які реалізовані ці методи (і, зокрема, як організований доступ до змінних і їх значень) - внутрішня справа об’єкту, що викликається; деталі реалізації приховані, інкапсульовані. Зухвалому об’єкту доступний інтерфейс, що тільки надається.
По-друге, не можна сказати, що якісь програми (методи) виконуються від імені користувача. Реалізації об’єктів складні, так що останні не можна розглядати всього лише як інструменти виконання волі користувачів. Швидше можна вважати, що користувач прямо або (як правило) побічно, на свій страх і ризик, "просить" деякий об’єкт про певну інформаційну послугу. Коли активізується метод, що викликається, об’єкт діє швидше від імені (в усякому разі, по волі) свого творця, ніж від імені користувача, що викликав його. Можна вважати, що об’єкти володіють достатньою "свободою волі", щоб виконувати дії, про які користувач не тільки не просив, але навіть не здогадується про їх можливість. Особливо це справедливо в мережному середовищі і для програмного забезпечення (ПО), одержаного через Internet, але може виявитися вірним і для комерційного ПО, закупленого за всіма правилами у солідної фірми.
Для ілюстрації приведемо наступний гіпотетичний приклад. Банк, ІС якого має з’єднання з Internet, придбав за рубежем автоматизовану банківську систему (АБС). Тільки через деякий час в банку вирішили, що зовнішнє з’єднання потребує захисту, і встановили міжмережевий екран.
Вивчення реєстраційної інформації екрану показало, що час від часу за рубіж відправляються IP-пакети, що містять якісь незрозумілі дані (напевно, зашифровані, вирішили в банку). Стали розбиратися, куди ж пакети прямують, і виявилося, що йдуть вони у фірму, АБС, що розробила. Виникла підозра, що в АБС вбудована закладка, щоб одержувати інформацію про діяльність банку. Зв’язалися з фірмою; там дуже здивувалися, спочатку всі заперечували, але врешті-решт з’ясували, що один з програмістів не прибрав з поставленого в банк варіанту налагоджувальну видачу, яка була організована через мережу (як передача IP-пакетів специфічного вигляду, з явно заданою IP-адресою робочого місця цього програміста). Таким чином, ніякого злого наміру не було, проте якийсь час інформація про платежі вільно гуляла по мережах.
В подальшій частині курсу, в лекції, присвяченій розмежуванню доступу, ми обговоримо, якомога кардинальним чином розв’язати подібні проблеми. Тут відзначимо лише, що при визначенні допустимості доступу важливе не тільки (і не стільки), хто звернувся до об’єкту, але і то, яка семантика дії. Без залучення семантики не можна визначити так звані "троянські програми", що виконують, крім декларованих, деякі приховані (звичайно негативні) дії.
Мабуть, слід визнати за застарілий і положення про те, що розмежування доступу направлено на захист від зловмисників. Приведений вище приклад показує, що внутрішні помилки розподілених ІС представляють не меншу небезпеку, а гарантувати їх відсутність в складних системах сучасна технологія програмування не дозволяє.
В дооб’єктной ІБ однією з найважливіших вимог є безпека повторного використовування пасивних єств (таких, наприклад, як області пам’яті, що динамічно виділяються). Очевидно, подібна вимога вступає в конфлікт з таким фундаментальним принципом, як інкапсуляція. Об’єкт не можна очистити зовнішнім чином (заповнити нулями або випадковою послідовністю біт), якщо тільки він сам не надає відповідний метод. За наявності такого методу надійність очищення залежить від коректності його реалізації і виклику.
Одним з найміцніших стереотипів серед фахівців по ІБ є трактування операційної системи як домінуючого засобу безпеки. На розробку захищених ОС виділяються значні кошти, часто в збиток решті напрямів захисту і, отже, в збиток реальної безпеки. В сучасних ІС, збудованих в багаторівневій архітектурі клієнт/сервер, ОС не контролює об’єкти, з якими працюють користувачі, рівно як і дії самих користувачів, які реєструються і враховуються прикладними засобами. Основною функцією безпеки ОС стає захист можливостей, що надаються привілейованим користувачам, від атак користувачів звичайних.
Це важливо, але безпека такими заходами не вичерпується. Далі ми розглянемо підхід до побудови програмно-технічного рівня ІБ у вигляді сукупності сервісів безпеки.