5.2.2.Сертифікати

При симетричному шифруванні як надавач, так і приймач спільно використовують секретний ключ. Поширення секретного ключа мусить відбуватися (з відповідним захистом) перед початком шифрованої комунікації. Однак при асиметричному шифруванні надавач використовує приватний ключ для шифрування або цифрового підписування повідомлень, тоді як приймач вживає публічний ключ для дешифрування повідомлення. Публічний ключ поширюється вільно до будь-кого, хто потребує приймати зашифровані повідомлення або повідомлення із цифровим підписом. Надавач потребує надійно захищати тільки приватний ключ.

Захист VPN базується не тільки на математичних алгоритмах і ключах, але також на захищеному методі генерування, поширення та управління ключами. Якщо ключ скомпроментований, то ціла мережа піддається загрозі. Орган, уповноважений до генерування і поширення приватних і публічних ключів учасників VPN мусить мати вищий рівень довіри, бо поєднання пар ключів з користувачем визначає захист всіх вихідних обмінів даними про ключі.

Щоб забезпечити цілісність публічного ключа, він публікується із сертифікатом. Сертифікат (або сертифікат публічного ключа) – це структура даних, яка захищена цифровим підписом органу сертифікації (certificate authority – CA) – органу, якому користувач сертифікату може довіряти. Сертифікат містить послідовність значень, таких як ім’я сертифікату та його вживання, інформацію для ідентифікації власника публічного ключа, сам публічний ключ, дату закінчення його чинності, назву органу сертифікації. CA використовує власний приватний ключ для підпису сертифікату. Якщо користувач знає публічний ключ органу сертифікації, то приймач може перевірити, чи сертифікат справді отриманий від довіреного CA і тому містить надійну інформацію і правильний публічний ключ. Сертифікати поширюються електронним чином (через Web або електронну пошту), або через інтелектуальні картки чи гнучкі диски. Процес управління ключами здійснюється через систему керівних принципів, відомих як інфраструктура публічних ключів (Public Key Infrastructure – PKI).

Отже, сертифікати публічних ключів забезпечують зручний і надійний метод для перевірки ідентичності надавача. IPSec опційно може використовувати цей метод для наскрізної ідентифікації. Сервери віддаленого доступу можуть вживати сертифікати публічних ключів для автентифікації користувачів, як це описано нижче.

5.2.3.Автентифікація користувачів та управління доступом

Досі розглядалися компоненти захисту приватності даних, автентифікації та цілісності даних. Онаково важливим є також процес виявлення, чи користувач є тим, за кого себе подає (автентифікація користувача) і контроль ресурсів, які йому доступні (управління доступом). На рис. показано, що пересилання зашифрованих даних є тільки частиною загального комунікаційного потоку даних; користувач повинен бути автентифікований для забезпечення уповноваженого доступу до окремих послуг, застосувань і ресурсів.

Р ис. . Управління доступом та автентифікація користувачів.

5.2.4.Автентифікація користувача

Інтегрована в пункт доступу до VPN, автентифікація користувача здійснює ідентифікацію особи, використовуючи вузол VPN і виключаючи можливість неавторизованого доступу до корпоративної мережі, оскільки шифрована сесія вже встановлена між двома пунктами. Окремі поширені схеми автентифікації користувачів включають: ім’я користувача/пароль операційних систем, S/Key (колишній) пароль, автентифікаційну схему RADIUS і жорстку двофакторну схему, базовану на маркері. Найжорсткішою схемою автентифікації користувача, наявною в комерційних застосуваннях, є двофакторна автентифікаційна схема, яка вимагає двох елементів для перевірки ідентичності користувача – наявності у нього фізичного елемента (електронного пристрою-маркера) і коду, який запам’ятовується (PIN-номера). Певні скрайні розв’язання вживають біометричні механізми, такі як відбиток пальця, відбиток голосу і сканування сітківки, однак вони мало поширені.

При виборі VPN-розв’язань важливо розглянути розв’язання, які містять як механізми автентифікації даних, так і автентифікації користувачів, бо поширені VPN-розв’язання, які мають тільки одну форму автентифікації. Внаслідок цього надавачі послуг VPN, які підтримують тільки один із двох автентифікаційних механізмів, можуть посилатися на автентифікацію взагалі, без розрізнення того, чи вони підтримують автентифікацію даних, користувачів, чи обидві. Повні VPN-розв’язання повинні підтримувати обидві схеми.