PKI: Як це працює, Локальні мережі, статті

Роджер Янглав

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

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

IPSec, протокол тунелювання Рівня 3 (мережевого рівня), сьогодні зазвичай використовується для шифрування і виділення даних для захищеної передачі по VPN корпоративних мереж. Ряд методів аутентифікації, службовців для перевірки ідентичності допущених користувачів, може реалізовуватися через IPSec, включаючи паролі, відомі серверу і клієнту, доступ з передачею маркера і цифрові сертифікати. Для широкої реалізації в екстранет найпростішим методом є Інфраструктура Відкритих Ключів (Public Key Infrastructure, PKI), що використовує технологію цифрових сертифікатів. Ця стаття розповість про те, як PKI працює в середовищі VPN.

Визначення PKI

Технологія PKI полягає у використанні двох математично-пов’язаних цифрових ключів, які мають такі властивості:

Проста PKI починається з Certificate Authority (CA), програмного пакета, що використовується в захищеному режимі довіреної третьою стороною для випуску цифрових сертифікатів X.509v3. Цифровий сертифікат являє собою структуру електронних даних, що зв’язує значення відкритого ключа з ідентифікуючої інформації про конкретний предмет. Цифровий сертифікат підписується цифровим методом (авторизується) за допомогою випуску Certificate Authority. Цифровий сертифікат гарантує будь сертифікованої організації, що використовує відкритий ключ, що відповідний закритий ключ зберігається відповідним віддаленим предметом. Роз’яснення полів інформації в сертифікаті можна знайти в RFC 2459 (Internet X.509 Public Key Infrastructure Certificate and CRL profile), опублікованому в Січні 1999 року. В сільнозащіщенной області Certificate Authority також є як мінімум X.509v3-сумісна база даних. CA-оператор випускає цифровий сертифікат до End Entity (кінцевої сутності; в даному випадку – кінцевим точкам EE-IPSec) і зберігає копію сертифіката в базі даних для подальшого звернення. Мовою, використовуваним для будь-яких запитів до бази даних X.509v3, є Lightweight Data Access Protocol v3 (LDAP v3).

Обслуговування недійсних сертифікатів

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

В цьому випадку CA-оператор може піти двома шляхами. Сертифікат може бути внесений до Certificate Revocation List (CRL-X.509v2) і випущений на певний термін. CRL залишається в v2, тому що було обумовлено, що при переході інших компонентів на v3 в нього не було внесено жодних змін. Або анулювання сертифіката здійснюється за допомогою Online Certificate Status Protocol (OCSP) на онлайновому сервері, представляє собою, наприклад, сервер бази даних X.509 v3, що забезпечує сервіс такого роду.

Кожен раз, як кінцева точка IPSec перевіряє допустимість сертифіката, наданого для аутентифікації, вона перевіряє останній кешированний CRL або використовує OCSP для визначення, чи включений даний сертифікат у відповідний список. Якщо він у списку, це означає, що сертифікат більше не дійсний і кінцева точка IPSec його відхилить.

Як працює складна PKI

Складна PKI може використовувати безліч різних CA з Root CA (кореневими CA). Root CA зберігає “власноруч” підписаний сертифікат і випускає сертифікати для підлеглих CA (тобто відносяться до більш низького рівня), які, в свою чергу, можуть випускати сертифікати для різних RA (Registration Authorities) або LRA (Local Registry Authorities). В процесі роботи RA або LRA отримує вихідний запит на сертифікат від запитуючої сторони і передає аутентіфіцированний запит своєму CA, що випускає сертифікат. Ієрархія різних CA нагадує дерево, саме тому вихідний CA названий Root CA (Див. Рис. 1).

До цього моменту між усіма EE (в даному випадку – кінцевими точками IPSec) всіх підлеглих СА встановлюється “ланцюг взаємної довіри” (chain of trust). Однак як EE-1, Relying Party (покладається на сертифікат сторона, RP), чий сертифікат випущений CA-1, дізнається, що сертифікат EE-5, випущений CA-2, заслуговує довіри? Це відбувається наступним чином:

  1. Спочатку EE-1 перевіряє або всі CRL або використовує OCSP, щоб визначити допустимість сертифіката EE-5.
  2. Потім EE-1 перевіряє, хто підписав сертифікат EE-5, і виявляє, що авторизує стороною є CA-2.
  3. Тепер EE-1 необхідно дізнатися, хто такий CA-2, тому вона перевіряє, хто підписав сертифікат CA-2.
  4. EE-1 виявляє, що це був CA-0, кореневий сертифікат, який підписав і сертифікат CA-1.
  5. CA-1 випускає та підписує сертифікат EE-1.

Ця інформація забезпечує перевірку допустимості EE – 5, так як вони знаходяться в рамках однієї PKI. Така процедура називається “прохід по ланцюгу довіри” або просто “прохід по ланцюгу”. Це основні елементи роботи окремої PKI. Далі в цій статті будуть розглянуті множинні реалізації PKI. Сертифікаційна політика (Certificate Policy) встановлює основні правила. Незалежно від того, сама компанія, що реалізує PKI, використовує CA, або доручає це робити комусь ще, вона все одно повинна визначити для себе сертифікаційну політику (Certificate Policy, CP). CP окреслює вимоги, необхідні в процесі аутентифікації для отримання сертифіката від CA, а також може визначати рівень повноважень (наприклад, “цей сертифікат має право підпису інформації за угодами, не перевищує один мільйон доларів “).

У разі кінцевої точки IPSec CP визначає, яка інформація повинна бути пред’явлена ​​CA для аутентифікації до випуску сертифіката для цієї кінцевої точки. Він також визначає, яку інформацію буде містити індивідуальний сертифікат і як він буде виглядати. CP визначає оновлення CRL або вимоги розміщення повідомлення про анульованому сертифікаті на сервері OCSP. Крім того, CP може також визначати вимоги фізичної безпеки, яким повинен відповідати CA.

Присвоєння і реєстрація об’єктних ідентифікаторів (Object Identifier)

Коли CP вже сформульована, її слід розмістити на сайті компанії. Компанія, яка становить CP, повинна бути зареєстрована через IANA (Internet Assigned Numbers Association), щоб її CP був привласнений Об’єктний ідентифікатор (Object Identifier, OID). OID являє собою представлення компанії в чисельної формі. Цей OID слід помістити в сертифікат, щоб RP (особа, яка отримує даний сертифікат) могло знайти і ознайомитися з CP сертифіката на сайті ідентифікованої компанії. Прочитавши CP, RP самостійно вирішує, чи заслуговує цей сертифікат довіри.

Написання Положення про використання сертифіката (Certificate Practice Statement)

Для успішної реалізації CA, в залежності від рівня необхідної авторизації, оператор CA повинен або написати спеціальне Положення про використання сертифіката (Certificate Practice Statement, CPS) або скласти загальне CPS. CPS є документ, що описує подробиці реалізації CP і пояснює порядок співвіднесення CA до вимог CP. За правилами American Bar Association, ідентифікатор CPS (OID) також повинен включатися в сертифікат. Ця інформація в подальшому дозволить RP перевіряти кваліфікацію Certificate Authority.

Створення власного CA

Якщо компанія реалізує власний CA, вона повинна створити також і CP і CPS. Кращим довідковим матеріалом при написанні CP і CPS є RFC 2527 (Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework), що побачила світ у березні 1999 року. Перш, ніж публікувати CP і CPS, необхідно також проконсультуватися з юристами компанії. Тим не менш, не слід чекати від них особливої ​​допомоги ні в питанні створення CP, ні CPS – на жаль, дуже мало хто корпоративні юристи здатні розбиратися в таких речах.

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

Взаємна сертифікація означає, що сертифікат, випущений однією PKI, стає застосуємо в іншій PKI. І CP і CPS кожної з PKI буде перевірений інший PKI з метою переконатися, що їхні сертифікати можна розглядати як рівнозначні щодо важливих для них аспектів (не зовсім вірно було б називати їх повністю “рівнозначними”, так як юридично це означало б і словесне збіг). Взаємна сертифікація являє собою просте фізичне дію: кожен CA випускає для іншого сертифікат, що містить Policy Mappings Extension (Розширене відображення політики), що закріплює вищевказане угоду. Складність полягає в узгодженні угод CP і CPS між двома PKI.

Взаємна сертифікація може бути обтяжлива, коли існує безліч PKI, так як в цьому випадку число взаємних сертифікатів зростає в геометричній прогресії. Якщо є дві PKI, буде два сертифікати, але якщо PKI буде чотири, їм доведеться обмінятися вже дванадцятьма сертифікатами. У якийсь момент індивідуальний EE втратить здатність проходити цей ланцюг для з’ясування допустимості можливо легітимного пред’явленого йому сертифіката, тобто реалізація цього EE не має обчислювальних можливостей для проходження ланцюга такої протяжності. В даному випадку рішенням буде Bridged PKI (шунтовані PKI).

Окремий Bridge CA обмінюється взаємними сертифікатами з усіма Root CA наявних PKI. Це зменшує довжину ланцюжка, яку необхідно пройти EE, щоб провести аутентифікацію сертифіката, пред’явленого їй ззовні її PKI. Це основна причина реалізації Bridged PKI, однак така технологія вигідна тому, що вона спрощує анулювання взаємної сертифікації. Замість розміщення 12 сертифікатів необхідно буде розмістити тільки один – той, що випущений Bridge CA для взаємної сертифікації. Отже, ми розібралися з основними поняттями технології PKI. А тепер найскладніше …

Реалізація PKI: замовляти або робити самим?

Існує два методи реалізації PKI, один полягає в замовленні цих послуг за контрактом, а інший – у самостійній її реалізації. Проблема вибору повинна вирішуватися не тільки на підставі порівняння цін (які при перспективному аналізі будуть практично рівні), а в основному згідно з результатами аналізу реалізації спільної політики безпеки компанії і її вимог. Власне, питання полягає в тому, підтримує Чи компанія повний контроль своєї PKI самостійно, або вона дає можливість контролювати це аспект своєї безпеки комусь ще?

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

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*