Використання протоколу IPSec поза VPN, Журнал мережевих рішень
Протокол IPSec призначений для захисту не лише віддаленого доступу, а й з'єднань між хостами. Поряд із «класичною» сферою застосування — взаємодія з діловими партнерами та віддаленими співробітниками через Internet — цей протокол можна також використовувати для захисту внутрішнього трафіку в локальній мережі.
У статті розглядаються технічні аспекти застосування обох сценаріїв.
IPSec отримав визнання як стандарт для надійної комунікації з IP. Він повсюдно використовується як розширення IPv4 і є невід'ємною складовою IPv6. Пакет протоколів забезпечує конфіденційність, цілісність та автентифікацію джерела даних. Аутентифікація досягається за допомогою заздалегідь наданих загальних секретних ключів або цифрових підписів; надійний обмін ключами здійснюється за протоколом обміну ключами Internet (Internet Key Exchange, IKE).
В даний час протокол IPSec застосовується головним чином у різних рішеннях VPN у двох областях: для організації надійних з'єднань між офісами та для віддаленого доступу. У разі VPN між офісами трафік між двома локальними мережами направляється на міжмережеві екрани (Firewall) або маршрутизатори з підтримкою IPSec з обох боків з'єднання. Шлюз шифрує пакети IP і відправляє їх через загальнодоступну мережу далі до шлюзу призначення, де розшифровуються і аутентифікуються. На противагу цьому, у разі віддаленого доступу шифрування та подальшу передачу пакетів бере на себе клієнтська програма на віддаленій робочій станції або портативний комп'ютер позаштатного співробітника. У сценарії із застосуванням VPN протокол IPSec працює у тунельному режимі, т. е. передача пакета IPSec відбувається «по тунелю» в пакетах IP.
IPSecпрацює на мережному рівні стека TCP/IP, таким чином, він є прозорим для додатків, завдяки чому безпеку за допомогою IPSec можна забезпечувати у багатьох різних середовищах без необхідності зміни додатків.
Ми розглянемо дві сфери застосування, які не охоплюються типовими конфігураціями VPN, та зразкові рішення на базі стандарту IPSec. Цими областями є динамічні з'єднання між хостами через Internet та захист внутрішнього трафіку в локальній мережі.
МІЖ ХОСТАМИ
VPN зв'язують дві локальні мережі за допомогою апаратних шлюзів. Така концепція призводить до деяких труднощів, якщо йдеться про встановлення з'єднань із зовнішніми партнерами. Це швидше проблема взаємодії між хостами, а не локальними мережами: підприємствам потрібно надійно підключатися до спеціальних служб своїх ділових партнерів, а не до цілих їхніх мереж. Як можна гарантувати надійність спільної VPN та одночасно забезпечити відсутність несанкціонованого доступу до інших мережних ресурсів?
Хоча протокол IPSec і є стандартом, різні «коробкові» реалізації часто працюють один з одним. Але організації з широким логістичним ланцюжком не можуть вимагати від кожного з партнерів, щоб він додав до своєї мережі додаткову платформу тільки для того, щоб забезпечити можливість зашифрованої передачі даних.
IPSec можна використовувати для організації надійного каналу зв'язку безпосередньо між хостами, що взаємодіють, без залучення додаткового обладнання. Це здійснюється шляхом створення з'єднання між хостами за протоколом IPSec із застосуванням транспортного режиму. У цьому режимі кадр IPSec вставляється у вихідний пакет IP за заголовком IP. На противагу тунельному режимуніяких додаткових заголовків IP не додається. Таке рішення вимагає підтримки IPSec в стеках IP на обох хостах.
Щоб захищений трафік IP міг пройти через міжмережевий екран мереж партнерів, адміністратори повинні відкрити UDP-порт 500 для протоколів IKE і NAT Traversal. Останнє гарантує, що інформаційний обмін протоколом IPSec не буде перериватися під час проходження через обладнання NAT.
NAT Traversal (NAT-T) інкапсулює трафік IPSec і одночасно створює пакети UDP, які NAT коректно пересилає. Для цього NAT-T містить додатковий заголовок UDP перед пакетом IPSec, щоб він у всій мережі оброблявся як звичайний пакет UDP і хост одержувача не проводив жодних перевірок цілісності. Після надходження пакета за місцем призначення заголовок UDP видаляється і пакет даних продовжує свій подальший шлях як інкапсульований пакет IPSec. Отже, за допомогою техніки NAT-T можливе встановлення зв'язку між клієнтами IPSec у захищених мережах та загальнодоступними хостами IPSec через міжмережні екрани.
ЗАХИЩЕНІ КОМУНІКАЦІЇ У ЛОКАЛЬНІЙ МЕРЕЖІ
Система ІТ піддається не лише зовнішнім атакам. Майже така ж велика ймовірність присутності зловмисника всередині мережі підприємства. При атаці з боку обізнаного співробітника наслідки можуть бути набагато серйознішими і масштабнішими, оскільки ця особа добре знайома з інфраструктурою мережі. Крім того, такі зловмисники часто мають конкретну мету та причину для атаки, тоді як атаки ззовні нерідко виконуються з чистої цікавості. Хоча потенційні збитки від атаки зсередини, як правило, більші, відповідальні за ІТ фахівці досі приділяють мало уваги захисту внутрішньомережевого трафіку. Можливо, вони вважають, що власна локальна мережа надійнавизначення. Незважаючи на це, деякі компоненти внутрішнього інформаційного обміну повинні обмежуватися конкретними групами користувачів (наприклад, фінансові транзакції, конфіденційна внутрішня інформація, закриті дані про клієнтів або паролі для технічних систем). Законодавство вимагає від підприємств запровадити спеціальні процедури контролю, щоб гарантувати захист конфіденційної інформації клієнтів, у тому числі й усередині мережі самого підприємства. Банки та інші фінансові інститути навіть зобов'язані дотримуватися внутрішніх правил аудиту для захисту частини інформаційного обміну у власній мережі.
Протокол IPSec дозволяє встановити захищені комунікаційні канали в локальній мережі. Його прозорість полегшує реалізацію, і при цьому додатків не потрібно вносити значні виправлення, що у разі критичних систем на базі мейнфреймів (успадкованих систем) на великих підприємствах було б дуже накладно.
IPSec можна поетапно вводити в існуючі мережеві середовища. На перехідному етапі адміністратор може дозволити незахищені з'єднання з хостами, які ще не можуть підтримувати IPSec.
При захисті трафіку локальної мережі віддалені користувачі навряд чи не використовують IPSec-VPN для зв'язку з локальною мережею. Щоб вони могли користуватися захищеними службами, потрібна ітераційна техніка тунелювання. При ітераційному тунелюванні хост має дві або більше Асоціації безпеки (Security Association), відповідно до яких здійснюється інформаційний обмін з іншими хостами. Так, наприклад, спочатку трафік інкапсулюється на внутрішній ділянці локальної мережі, а потім ще раз захищається для передачі через VPN. Ітераційне тунелювання може бути невидимим для хоста: наприклад, якщо хости встановлюютьз'єднання у транспортному режимі від одного сегмента до іншого через тунель IPSec, який проходить через VPN між двома філіями.
Адміністраторам, що турбуються про безпеку, здається привабливим зашифрувати весь трафік у локальній мережі, проте тунелювання IPSec має і недоліки. Так, у мережі напевно є хости, які не підтримують IPSec. Але якщо потрібно реалізувати надійну локальну мережу, IPSec необхідний всіх хостах, а трафік локальної мережі має бути захищений обох напрямах. Крім того, проблемою є шифрування широкомовного трафіку, тим більше, що широкомовні протоколи, як правило, не передбачають захисту.
АУТЕНТИФІКАЦІЯ ТА УПРАВЛІННЯ
Загальні секретні ключі (Preshared Key, PSK) або цифрові підписи з сертифікатами призначені для аутентифікації хостів, що беруть участь у комунікації один з одним. Ключі простіше у користуванні, ніж сертифікати, зате останні забезпечують більш високий рівень захисту, легше масштабуються і управляються у великих мережах.
Обмін відкритими ключами для цифрового підпису зазвичай відбувається через сертифікати, які з відкритим ключем пов'язують блок даних. Якщо сертифікат був підписаний третьою особою, якій обидва партнери з комунікації довіряють (Certificate Authority, CA), то він заслуговує на довіру. Ієрархія цих CA та їх конфіденційних відносин називається інфраструктурою відкритих ключів (Public Key Infrastructure, PKI).
Далі розглянемо кілька практичних варіантів реалізації контролю доступу із загальними секретними ключами та сертифікатами.
Однак загальні секретні ключі підходять для надійної аутентифікації лише тоді, коли процедура передачі ключа перебуває під абсолютним контролем. Тому сертифікати більше заслуговують на рекомендації. Якщо підприємство вжемає у своєму розпорядженні PKI, то воно може використовувати її також для підтримки віддаленого доступу. Доступ до сервера (обслуговуючого хоста) можна обмежувати лише користувачами певних сертифікатів, створених спеціально для цього. Якщо адміністратор надає кому-небудь доступ до служби, це виглядає так, ніби користувачеві був виданий сертифікат. За допомогою PKI адміністратор також має можливість обмежувати доступ за допомогою списку анульованих сертифікатів (Certifica te Revocation List, CRL). Технічне обслуговування такого середовища в будь-якому випадку не таке складне, як управління незліченними загальними секретними ключами.
Якщо на підприємстві немає PKI, то впровадження такого рішення лише для віддаленого доступу не завжди є доцільним. Однак сертифікати можна використовувати без PKI. Сервер та користувачі обмінюються власними підписаними сертифікатами та оголошують про свою готовність довіряти їм. Процес можна до певної міри автоматизувати, однак користувач повинен верифікувати конфіденційні відносини, перш ніж буде встановлено зв'язок. Таким чином, описаний метод майже так само складний, як використання PSK, але він дає більш високий ступінь безпеки та спрощує подальшу міграцію до PKI.
Оскільки локальна мережа постійно змінюється, керівництво політикою безпеки має здійснюватись із центру. Інакше може статися так, що хости будуть обривати з'єднання через невдалу аутентифікацію або надсилати нібито зашифровані дані в незашифрованому вигляді.
IPSec зарекомендував себе як стандартний протокол для захищених IP-з'єднань. В даний час він реалізований у багатьох рішеннях VPN і забезпечує надійні з'єднання між локальними мережами (сервісами), так і з'єднання для віддаленого доступу. ОднакДля рівноправних з'єднань IPSec існують свої сфери застосування: якщо на VPN розраховувати не доводиться, шифрування з обох кінців з'єднання є недорогою і простою в обслуговуванні альтернативою.
Термінологія
Демілітаризована зона (Demilitarized Zone, DMZ).Комп'ютери, що знаходяться в демілітаризованій зоні, доступні з корпоративної локальної мережі, а також ззовні, але не можуть встановлювати контакт з ресурсами всередині локальної мережі.
Інфраструктура відкритих ключів (Public Key Infrastructure, PKI).PKI складається з компонентів, що мають пари ключів, сертифікаційних центрів, сховищ сертифікатів (каталогів) та інших складових, необхідних для використання шифрування з відкритими ключами.
Обхід NAT (NAT Traversal, NAT-T).У разі NAT Traversal пакети IPSec упаковуються в датаграми UDP, де міститься інформація про те, як можна відновити пакети IPSec. Трафік UDP проходить тим самим шляхом, що й узгодження IKE.
Розгортання сертифікатів.Цей процес є сертифікацією відкритого ключа (Public Key) сертифікаційним центром.
Сертифікат.Спеціальні цифрові документи використовуються для верифікації ідентичності сторін, що взаємодіють.
Сертифікаційний центр (Certificate Autority, CA).Будучи складовою інфраструктури відкритих ключів, дана організація видає цифрові сертифікати (зокрема, X.509).
Список анульованих сертифікатів.Підписаний список із зазначенням серійних номерів сертифікатів, які були відкликані до дати їх закінчення або дія яких була припинена їх видавцем (сертифікаційним центром).
Шифрування.Цей механізм захисту даних перетворює інформацію на зрозумілу форму (простийтекст) у незрозумілу (зашифрований текст), щоб забезпечити конфіденційність даних. Протилежний процес називаєтьсядешифруванням.
Поділіться матеріалом з колегами та друзями