Твердження 4.
Для забезпечення надійної ідентифікації об'єктів розподіленої ОС при створенні віртуального каналу необхідно використовувати криптоалгоритмы з відкритим ключем.
Слідство 4.1.
Необхідно забезпечити цифровий підпис повідомлень.
Слідство 4.2.
Необхідно забезпечити можливість шифрування повідомлень.
Контроль за маршрутом повідомлення в розподіленій ОС
Як відомо, кожен об'єкт розподіленої ОС повинен володіти адресою, унікально його ідентифікуючим. Для того, щоб повідомлення від одного об'єкту було передане на інший об'єкт системи, воно повинне пройти через ланцюг маршрутизаторів, задача яких - проаналізувавши адресу призначення, вказану в повідомленні, вибрати оптимальний маршрут і, виходячи з нього, переправити пакет або на наступний маршрутизатор або безпосередньо абоненту, якщо він напряму підключений до даного вузла. Таким чином, маршрут до об'єкту визначається ланцюжком вузлів, пройдених повідомленням. Як було показано раніше, маршрут повідомлення може бути інформацією, аутентіфіцирующей з точністю до підмережі достовірність адреси суб'єкта, що відіслав повідомлення. Очевидно, що перед будь-якою системою зв'язку об'єктів в РОС встає стандартна проблема перевірки достовірності адреси повідомлення, що прийшло на об'єкт. Цю задачу, з одного боку, можна вирішити, ввівши додаткову ідентифікацію повідомлень на іншому, вищому рівні OSI. Так, адресація здійснюється на мережному рівні, а додаткова ідентифікація, наприклад, на транспортному. Проте подібне рішення не дозволить уникнути проблеми контролю за створенням з'єднань, оскільки додаткова ідентифікація абонентів буде можлива тільки після створення з'єднання. Тому розробникам розподіленої ОС можна запропонувати наступні шляхи рішення проблеми.
У першому випадку функцію перевірки достовірності адреси відправника можна покласти на маршрутизатор. Це нескладно зробити, оскільки маршрутизатор може відстежити, звідки його дійшов пакет (від іншого маршрутизатора або від підключеного до нього хоста з підмереж, напряму підключених до даного маршрутизатора). Маршрутизатор може перевіряти відповідність адреси відправника з адресою відповідної підмережі, звідки прийшло повідомлення. У разі збігу повідомлення пересилається далі, а інакше - фільтрується. Цей спосіб дозволить на початковій стадії відкинути пакети з невірними адресами відправника.
Інший варіант рішення може полягати в створенні в заголовку пакету спеціальних полів, куди кожен маршрутизатор, через який проходить пакет, заносить маршрутну інформацію (частина своєї адреси, наприклад). При цьому перший маршрутизатор, на який поступив пакет, заносить також інформацію про клас мережі (А, B, З), звідки прийшов пакет. Проте, внесення в пакет адрес всіх пройдених по дорозі маршрутизаторів буде неоптимальним рішенням, оскільки в цьому випадку складно наперед визначити максимальний розмір заголовка пакету.
Коли повідомлення дійде до кінцевого адресата, в його заголовку буде повністю відмічений пройдений маршрут. По цьому маршруту, незалежно від вказаної в пакеті мережної адреси відправника, можна, по-перше, з точністю до підмережі ідентифікувати достовірність адреси і, по-друге, визначити з точністю до підмережі істинну адресу відправника. Отже, одержавши подібне повідомлення з вказаним маршрутом, мережна операційна система аналізує маршрут і перевіряє достовірність адреси відправника. У разі його невірогідності пакет відкидається.
Зі всього вищесказаного виходить наступна вимога до створення захищених систем зв'язку в розподілених ОС:
Твердження 5.
У розподіленій ОС необхідно забезпечити на мережному рівні контроль за маршрутом повідомлень для аутентифікації адреси відправника.
Контроль за віртуальними з'єднаннями в розподіленій ОС
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.