Мало хто сумнівається, що в кінцевому підсумку віртуальні приватні мережі (VPN, Virtual Private Network) витіснять більшість систем на базі виділених ліній зв'язку, якщо не все. Завдяки своїй нижчою ціною і більшої гнучкості VPN надзвичайно привабливі для компаній будь-яких розмірів.
Поки, проте, адміністратор, який працює над створенням VPN, стикається з надзвичайно складними проблемами безпеки. Відсутність стандартів на механізми забезпечення безпеки на мережевому рівні IP-мереж змушує компанії вдаватися до застосування приватних протоколів, а в результаті вони виявляються прив'язані до одного-єдиного постачальника.
Для вирішення цієї проблеми організація Internet Engineering Task Force (цільова група інженерної підтримки Internet) продовжує роботи над створенням нового стандарту під назвою IPSec, який повинен визначити відкриті протоколи для захищеної Internet.
Говорячи максимально спрощено, VPN - це захищене з'єднання між двома або більше точками входу в загальнодоступну мережу. VPN на базі Internet не тільки коштує дешевше звичайної приватної глобальної мережі, але і являє собою більш масштабується засіб віддаленого доступу до корпоративних обчислювальних ресурсів. За допомогою такої VPN мобільні користувачі отримують можливість зв'язатися з корпоративною мережею через Internet з найближчої до них точки доступу, пропонованої оператором послуг доступу. Цим виключається необхідність установки в корпоративних обчислювальних центрах серверів віддаленого доступу і множинних банків модемів. Трафік, породжуваний віддаленими користувачами, може оброблятися так само, як і будь-який інший Internet-трафік.
Однак можливість застосування подібних систем повністю залежить від гарантій безпеки зв'язку. Системи її забезпечення можуть охоплювати всю дистанцію від однієї робочої станції до іншої або діяти на окремих її ділянках (наприклад, між вузлами мережі або між брандмауерами).
З впровадженням розробляється IETF специфікації IPSec багаторівневі системи забезпечення безпеки стануть більш стандартизованими і сумісними один з одним. Ці нові протоколи передбачають забезпечення безпеки на фізичному рівні і на рівні лінії передачі даних з використанням фільтрів пакетів, на мережевому рівні - за допомогою спеціальних доповнень до IP-брандмауерів, на рівні сеансів зв'язку - із застосуванням проксі-додатків, а на рівні додатку - з використанням таких стандартів, як Secure Sockets Layer і Secure HTTP.
Для спрощення організації в Internet захищених тунелів для передачі трафіку IETF пропонує використовувати гібрид протоколів Point-to-Point Tunneling Protocol корпорації Microsoft і Layer 2 Forwarding фірми Cisco Systems, який буде називатися Layer 2 Tunneling Protocol.
Нижче описані процедури захисту змісту дейтаграм при передачі між брандмауерами з використанням певних IPSec методів аутентифікації і шифрування.
Захист VPN на третьому рівні (Layer 3) вимагає застосування аутентифікації і шифрування дейтаграм і відповідно процедур обміну необхідними для цього ключами.
Використання коштів шифрування на базі ключових алгоритмів вимагає передачі ключа або пари ключів між відправником і отримувачем. На базі алгоритму з закритим ключем і відправник, і одержувач застосовують одну і ту ж цифрову комбінацію, яка повинна бути передана відправником одержувачу, перш ніж вони почнуть обмінюватися захищеними повідомленнями.
При алгоритмі з відкритим і закритим ключами передача ключа значно простіше. І відкритий, і закритий ключі генеруються в одному і тому ж центрі. Відкритий ключ, який може бути переданий кореспондентові по незахищених каналах, використовується для шифрування даних, а закритий - для їх розшифровки.
В рамках архітектури IPSec передбачено застосування двох видів заголовків дейтаграм, кожен - для вирішення свого завдання. Тема IP-аутентифікації (IP Authentificationn Header, AH) призначений для аутентифікації і контролю цілісності даних. З його допомогою одержувач може переконатися, що дейтаграма дійсно була передана зазначеним в поле адреси відправника суб'єктом і що вона не піддалася модифікації в дорозі. А заголовок інкапсуляції секретного змісту (Encapsulating Security Payload, ESP) захищає вміст IP-дейтаграм шляхом його шифрування. Для забезпечення сумісності два брандмауера - на приймальному і передавальному кінцях - повинні бути узгоджені за наступними пунктами: комбінація AH / ESP; математичне перетворення для обчислення AH і математичне перетворення для обчислення ESP; секретний ключ для обчислення аутентификационной сигнатури повідомлення і секретний ключ шифрування / дешифрування. Перераховані елементи утворюють набір параметрів системи забезпечення безпеки.
В рамках архітектури IPSec набором параметрів системи забезпечення безпеки називається інформація, передана між кореспондентами під час сеансу адміністрування ключів, який повинен бути проведений перш, ніж стане можливий обмін захищеними повідомленнями.
Пропозиції IETF по специфікації IPSec були опубліковані в якості Пропозицій для обговорення (RFC, номери з 1825 по 1829). Однак для ефективного розгортання системи забезпечення безпеки необхідна також процедура поширення криптографічних ключів, використовуваних для аутентифікації і шифрування. Стандарт X.509 описує формат цифрових сертифікатів, але не визначає, яким чином два вузла узгоджують набори параметрів своїх систем забезпечення безпеки і вибирають ключ для шифрування в кожному конкретному сеансі зв'язку.
Робоча група по IPSec зосередила свою увагу на протоколах адміністрування ключів SKIP (Simple Key management for Internet Protocol) і ISAKMP / Oakley (Internet Security Association and Key Management Protocol).
SKIP простіше в реалізації, але не має механізму узгодження алгоритму шифрування; при його використанні, якщо одержувач не зміг розшифрувати пакет, тим все і закінчується.
ISAKMP / Oakley пропонує більш розвинені можливості узгодження, і тому був обраний за основу для визначається IPSec обов'язкового протоколу адміністрування ключів для IPv6. А для IPv4 допускається використання як ISAKMP / Oakley, так і SKIP.
Плани на майбутнє
Оскільки протоколи адміністрування ключів, вийняті з печі IETF, ще не встигли охолонути, заснованих на них дійсно сумісних продуктів для організації VPN доведеться, мабуть, почекати ще не менше року.
У той же час в області тестування підтримують IPSec продуктів на сумісність вже досягнуто значного прогресу. Перші випробування проходили при ручній процедуру обміну ключами, але останні тести на сумісність проводяться з використанням узгоджених електронних процедур передачі ключа.
Дейв Козюра - старший консультант фірми Decisys (Серлінг, шт. Віргінія). З ним можна зв'язатися за адресою:
Дейв Козюра
Версія для друку
Тільки зареєстровані користувачі можуть залишати коментарі.
