• Главная
  • Карта сайта
Не найдено

Балансування навантаження і відмовостійкість при перевірці статусів сертифікатів в ІВК

ЕЦП

В сучасні інформаційні системи все ширше впроваджується технологія електронного цифрового підпису (ЕЦП) на основі асиметричних криптографічних алгоритмів. ЕЦП використовується для забезпечення юридичної значимості електронних документів, аутентифікації, контролю цілісності і т. Д. Застосування цифрового підпису має на увазі наявність відповідної інфраструктури, яка називається інфраструктурою відкритих ключів (ІВК; Public Key Infrastructure, PKI). Для засвідчення факту належності ключової пари певному суб'єкту (об'єкту) в ІВК служить сертифікат відкритого ключа - підписаний ЕЦП електронний документ, що містить інформацію про власника ключової пари і відкритий ключ. В ІВК підпис сертифікатів здійснюється довіреною третьою стороною - підтверджуючий центр (УЦ). Довіра до ключової парі УЦ також ґрунтується на його сертифікаті, який може бути підписаний чи вищим УЦ, або самим УЦ * 1.

_____

* 1 Бернет С., Пейн С. Криптографія. Офіційне керівництво RSA Security. М .: Біном-Пресс, 2002

Дві точки поширення СОС в сертифікаті

У процесі управління ключами УЦ має можливість відкликання випущених ним сертифікатів, що необхідно для дострокового припинення їх дії, наприклад в разі компрометації ключа. Процедура перевірки ЕЦП передбачає крім підтвердження її математичної коректності ще й побудова і перевірку ланцюжка сертифікатів до довіреної УЦ, а також перевірку статусів сертифікатів в ланцюжку.

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

Нижче представлені загальні міркування, якими треба керуватися при вирішенні проблем балансування навантаження і відмовостійкості, надано рекомендації щодо організації безвідмовного обслуговування, а також наведені порівняльні характеристики методів поширення інформації про статуси сертифікатів стосовно цих проблем. В роботі розглянуті найбільш поширені методи надання інформації про відкликання: списки відкликаних сертифікатів (СОС; Certificate Revocation List, CRL) та OCSP-сервери (Online Certificate Status Protocol - протокол визначення статусу сертифіката в режимі реального часу).

Списки відкликання сертифікатів

Списки відкликання сертифікатів є найпоширенішим методом надання клієнтам інформації про статуси сертифікатів. Формат і застосування СОС описані в рекомендаціях X.509 * 1 і RFC 3280 (www.ietf.org/rfc/rfc3280.txt), що обумовлює підтримку СОС у всіх продуктах, які працюють з сертифікатами відкритих ключів.

_____

* 1 ITU-T Recommendation X.509 "Information technology - Open systems interconnection - The Directpry: Public-rey and attribute certificate frameworks". ITU-T, March 2000.

СОС є список серійних номерів сертифікатів, які є унікальними для сертифікатів одного УЦ, із зазначенням для кожного номера часу відгуку і, можливо, інших атрибутів. У списку також вказується видавець - сам УЦ або суб'єкт, уповноважений ним поширювати інформацію про статуси сертифікатів. Цей список підписується ключем видавця. Таким чином, в СОС включаються серійні номери всіх відкликаних сертифікатів.

У СОС також обов'язково вказується час його видання (thisUpdate) і, опціонально, час, коли буде доступна свіжіша інформація (nextUpdate). Для вказівки адреси, за якою доступний СОС, в сертифікати включається додаток CDP (CRL Distribution Point - точка поширення СОС). Таких адрес може бути кілька.

Доступ по протоколу LDAP

LDAP (Lightweight Directory Access - полегшений протокол доступу до служби каталогів) дозволяє отримувати СОС зі служби каталогів (директорій). Даний спосіб зручний у тих випадках, коли в інформаційній системі з ІВК вже застосовується служба каталогів.

З поширених продуктів для цих цілей можна використовувати Active Directory на базі контролера домену Microsoft Windows версії 2000 або 2003 або Active Directory Application Mode (ADAM) - безкоштовний продукт, який працює під управлінням Windows XP / 2003.

Необхідно відзначити, що не всі клієнти ІВК з доступних на ринку підтримують звернення за СОС по протоколу LDAP. Якщо в системі задіяні тільки програми на базі Microsoft CryptoAPI, то можна звернутися до LDAP-каталогах, в іншому випадку необхідно переконатися в наявності такої можливості в використовуваних продуктах. Microsoft, незважаючи на реалізовану підтримку протоколу LDAP, рекомендує HTTP CDP для не-Windows-клієнтів.

Доступ по протоколу HTTP

Поширення СОС по протоколу HTTP через веб-сервери має наступні переваги в порівнянні з LDAP:

- простота розгортання і адміністрування;

- висока ймовірність підтримки у всіх додатках, які перевіряють статус сертифікатів;

- менший час видачі відповіді, оскільки веб-сервер при належній налаштування просто читає файл СОС, що лежить на диску, а LDAP-сервер здійснює пошук СОС в своїй базі даних * 1;

_____

* 1Прі видачі відповіді веб-сервером Microsoft IIS шляхом читання файлу з диска (на відміну від виконання сценарію) отримано виграш за часом в два рази в порівнянні із запитом властивості об'єкта з Active Directory

- більш безпечний і легкий в управлінні сценарій надання доступу до СОС зовнішнім по відношенню до організації клієнтам.

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

балансування навантаження

Поширення СОС в територіально розподілених системах або в системах з великою кількістю користувачів вводить додаткові вимоги.

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

Балансування навантаження за допомогою дублювання серверів на увазі реплікацію розповсюджуваних даних (в нашому випадку - СОС) від джерела (УЦ) на всі сервери. Зрозуміло, процедура реплікації вносить затримку в поширення СОС. При цьому можлива ситуація, коли різні клієнти в один і той же момент звертаються за СОС і отримують різні списки. Необхідно враховувати дану ситуацію і величину затримки при проектуванні ІВК і відповідно коригувати розклад публікації СОС і вимоги до процедури їх реплікації.

Реплікація СОС в LDAP-директорії забезпечена вбудованою підтримкою в Active Directory на контролерах доменів і Active Directory Application Mode. Реплікація директорії може бути налаштована під потреби поширення СОС, але при використанні вже існуючого лісу ці потреби можуть конфліктувати зі сформованою практикою.

Реплікація СОС за кількома веб-серверів може зажадати додаткових зусиль, але також може бути більш гнучко налаштована під потреби системи. Подібне поширення СОС підтримується в продукті, що засвідчує, "КріптоПро УЦ".

відмовостійкість

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

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

Оскільки клієнти визначають місце розташування СОС по CDP в сертифікаті, пропонується включати в сертифікати дві CDP в наступному порядку (тип CDP - LDAP або HTTP - визначається виходячи з потреб системи):

- локальна адреса;

- глобальна адреса.

Під локальними і глобальними адресами тут мається на увазі використання DNS-імен, які будуть вирішуватися в IP-адреси в такий спосіб. У локальному адресу буде міститися ім'я сервера, подібне local.cdp.myis.ru, а в глобальному - global.cdp.myis.ru. При цьому DNS-сервери розподіленої системи налаштовуються так, що ім'я glo-bal.cdp.myis.ru має однакові IP-адреси для всіх клієнтів і посилається на центральний сервер поширення СОС - максимально надійний, а ім'я local.cdp.myis.ru має різні IP-адреси для різних клієнтів, тим самим забезпечуючи звернення клієнта за СОС на найближчий сервер (див. малюнок).

Подібну настройку DNS можна здійснити, наприклад, одним з таких способів:

- створити зону cdp.myis.ru на всіх DNS-серверах системи як первинну і налаштувати два зазначених імені на кожному сервері: local.cdp.myis.ru - на найближчий (е) сервер (и), global.cdp.myis.ru - на центральний (е) сервер (и). У цьому випадку управління адресами буде розподіленим;

- зіставити два зазначених імені з безліччю всіх адрес серверів поширення СОС: global.cdp.myis.ru - один або кілька центральних серверів, local.cdp.myis.ru - все регіональні сервери. Таку настройку необхідно здійснити на первинному DNS-сервері системи, з якого адреси будуть автоматично отримані всіма вторинними серверами. При запиті адреси сервера local.cdp.myis.ru служба DNS у відповідь впорядкує всі відомі їй адреси за принципом близькості до підмережі клієнта, і в результаті перша адреса буде вказувати на найближчий сервер. Можливість автоматичного впорядкування на основі адреси підмережі клієнта присутній в найбільш поширених продуктах - службі DNS в ОС Microsoft і BIND в ОС UNIX. У цьому випадку управління адресами буде централізованим.

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

У деяких особливих випадках має сенс використовувати одну HTTP-точку і одну LDAP-точку. Необов'язково також встановлювати другу точку пари в умовному центрі системи з однаковим для всіх клієнтів IP-адресою. Це може бути така ж, як і перша точка з різними IP-адресами для різних клієнтів. Конкретний набір CDP і стратегія резервування визначаються виходячи з потреб конкретної системи.

Балансування навантаження при зверненні клієнтів за цими адресами можна здійснювати будь-якими відповідними методами.

Управління розміром СОС

Одним з методів балансування навантаження є управління розміром СОС. Проблема розміру СОС може стати актуальною в системі з великим числом користувачів. У СОС присутня інформація про всі відкликаних або призупинених сертифікатах з числа діючих в даний момент. З розрахунку 16-байтного серійного номера на кожен сертифікат припадатиме в середньому 35 байт інформації. При використанні доповнень до запису СОС, наприклад причини відкликання, дати передбачуваної компрометації ключа і т. П., Обсяг інформації, очевидно, ще збільшиться. Припускаючи, що кожен 20-й сертифікат відгукується до закінчення терміну його дії, розмір СОС досягне 100 Кб в системі вже з 60 000 користувачів. На момент написання статті СОС одного з УЦ VeriSign досягав обсягу 700 000 байт (!) При 22 000 відкликаних сертифікатів.

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

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

При використанні останнього способу і наявності двох ключів УЦ, якими підписано рівну кількість сертифікатів, трафік СОС по запитах клієнтів зменшиться в два рази в порівнянні з варіантом з одним ключем і одним СОС.

протокол OCSP

Протокол OCSP (Online Certificate Status Protocol) описаний в RFC 2560 (www.ietf.org/rfc/rfc2560.txt). Хоча цей документ опублікований в 1999 р, отримання інформації про відкликання з даного протоколу менш поширене в доступних на ринку продуктах.

Концептуальна відмінність протоколу OCSP від ​​СОС полягає у видачі відповіді на запит статусу конкретних сертифікатів, т. Е. OCSP-відповідь, якщо відволіктися від його формату, являє собою той же підписаний СОС, але з інформацією тільки про запитаних сертифікатах.

Адреса для доступу до серверів OCSP вказується в додатку AIA (Authority Information Access - точка доступу до інформації УЦ) сертифікатів. Таких адрес може бути кілька. До числа і послідовності їх вказівки застосовні ті ж міркування, що і до адресами CDP, за винятком того, що для сумісності з доступними продуктами тут слід вказувати тільки HTTP-адреси.

Розглянемо докладніше переваги і недоліки протоколу OCSP в порівнянні з СОС з точки зору балансування навантаження і підвищення відмовостійкості. Окремо зупинимося на класичному протоколі OCSP та протоколі OCSP з кешуванням. Класичний протокол OCSP має на увазі створення відповіді в режимі реального часу, тоді як кешуючий сервер поширює попередньо створені відповіді.

Класичний протокол OCSP має наступні переваги в порівнянні з СОС:

- менший обсяг інформації, що пересилається клієнту інформації, так як розмір відповіді фіксований і становить близько 300 байт при мінімальному наповненні OCSP-відповіді (при вкладенні, наприклад, сертифікату, на якому відповідь підписаний, обсяг відповіді збільшиться на розмір сертифіката - на 1-2 Кб);

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

Недоліки протоколу в порівнянні з СОС:

- по кожному запиту статусу необхідно обчислення ЕЦП, а це процедура не швидка, накладає обмеження на використовувані засоби криптографічного захисту інформації (СКЗИ). Якщо для підпису сертифікатів і СОС можливо використовувати повільне, але більш захищене апаратне ЗКЗІ, то для OCSP-сервера це швидше за все неприйнятно;

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

Протокол OCSP з кешуванням має наступні переваги в порівнянні з класичним протоколом:

- не треба обчислювати ЕЦП при кожній відповіді, що прискорює пошук по базі даних;

- немає необхідності управління ключами і сертифікатами безлічі серверів.

Для роботи сервера з даного протоколу потрібно передати йому підписані OCSP-відповіді для всіх випущених УЦ сертифікатів. Може знадобитися і поширення OCSP-відповідей для знову випущених сертифікатів.

При вікорістанні кешуючіх OCSP-серверів слід візначіті оптимальну Кількість Місць генерації OCSP-Відповідей. Якщо створювати всі відповіді в умовному центрі системи (наприклад, на УЦ), потрібно всього лише по одному додатковому ключу і сертифікату, управління яким може бути максимально простим через його зберігання в УЦ, але доведеться поширювати порівняно великий обсяг інформації по системі до всіх кешуються OCSP-серверів.

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

Протокол з кешуванням має наступні недоліки в порівнянні з класичним:

- відсутність підтримки поля nonce, що робить можливими атаки типу "повтор повідомлення", які виключені в разі класичного протоколу OCSP;

- відсутність можливості запиту статусу кількох сертифікатів за допомогою одного звернення. Цим і попереднім пунктом визначаються відмінності протоколу OCSP з кешуванням RFC 2560;

- необхідність передачі кешуючого порівняно великого обсягу інформації. Наприклад, для 60 000 сертифікатів обсяг згенерованих OCSP-відповідей буде близько 18 Мб, тоді як СОС, в якому присутній кожен 20-й сертифікат, займає близько 100 Кб.

Слід зазначити, що СОС також не захищені від подібних атак. Успішне використання атак повтору обмежена часом thisUpdate - nextUpdate СОС або OCSP-відповіді, що дозволяє управляти рівнем ризику атаки.

Детальніше про протокол OCSP з кешуванням см. Роботу Deacon A., Hurst R., Lightweight OCSP Profile for High Volume Environments. - IETF, Internet Draft, November 2003 і www.corestreet.com/whitepapers/w02_07v2_distributed_ocsp.pdf.

Актуальність інформації в OCSP-відповіді

OCSP-сервер, що працює по СОС, створює відповіді, актуальність яких відповідає СОС. Щоб клієнти могли отримувати найбільш актуальну інформацію, необхідно додаткове поширення інформації від УЦ до OCSP-серверів. Це можна забезпечити, налаштувавши УЦ на розсилку повідомлень при зміні статусу сертифіката в режимі реального часу. У разі генеруючих OCSP-серверів повідомленням може служити анонс відкликання, описаний в RFC 2510 (www.ietf.org/rfc/rfc2510.txt), для кешуючих серверів це повинен бути безпосередньо OCSP-відповідь. При розсилці подібних повідомлень також можлива гібридна схема з генеруючими і кешуючого.

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

Висновок

Для поширення інформації про статуси сертифікатів відкритого ключа УЦ може використовувати списки відкликаних сертифікатів (CRL), доступні по протоколах LDAP або HTTP, або OCSP-сервери. У розподілених системах і системах з великим числом користувачів виникають проблеми балансування навантаження і забезпечення відмовостійкості при доступі клієнтів до даної інформації.

Списки відкликання сертифікатів підтримуються всіма продуктами, доступними на ринку. Розташування списків на HTTP-серверах дозволяє прискорити доступ до них в порівнянні з LDAP-серверами, але поширення списків по всіх HTTP-серверів буде складнішим, ніж при використанні протоколу LDAP, який підтримує реплікацію. При великій кількості користувачів розмір списку відкликаних починає відігравати суттєву роль. Для його зменшення можна використовувати різницеві списки (Delta CRL) або часту планову зміну ключа засвідчує центру.

OCSP-сервери дозволяють знизити трафік при зверненні клієнтів до мінімуму, але протокол OCSP підтримується не всіма продуктами. Найбільш зручним для балансування навантаження є застосування кешуючих OCSP-серверів. У порівнянні зі списками відкликання сертифікатів в цьому випадку буде потрібно передача великих обсягів інформації до самих серверів, а при поширенні інформації про зміни статусів сертифікатів в режимі реального часу можуть виникати проблеми з надійністю каналів зв'язку. Тут розглянуті і інші особливості зазначених методів надання інформації про відкликання стосовно до проблеми балансування навантаження і відмовостійкості.

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

З автором можна зв'язатися за адресою: [email protected].

Версія для друку

Тільки зареєстровані Користувачі могут залішаті Коментарі.

Провайдеры:
  • 08.09.2015

    Batyevka.NET предоставляет услуги доступа к сети Интернет на территории Соломенского района г. Киева.Наша миссия —... 
    Читать полностью

  • 08.09.2015
    IPNET

    Компания IPNET — это крупнейший оператор и технологический лидер на рынке телекоммуникаций Киева. Мы предоставляем... 
    Читать полностью

  • 08.09.2015
    Boryspil.Net

    Интернет-провайдер «Boryspil.net» начал свою работу в 2008 году и на данный момент является одним из крупнейших поставщиков... 
    Читать полностью

  • 08.09.2015
    4OKNET

    Наша компания работает в сфере телекоммуникационных услуг, а именно — предоставлении доступа в сеть интернет.Уже... 
    Читать полностью

  • 08.09.2015
    Телегруп

    ДП «Телегруп-Украина» – IT-компания с 15-летним опытом работы на рынке телекоммуникационных услуг, а также официальный... 
    Читать полностью

  • 08.09.2015
    Софтлинк

    Высокая скоростьМы являемся участником Украинского центра обмена трафиком (UA — IX) с включением 10 Гбит / сек... 
    Читать полностью