SSL та ISC: Частина 1. Що таке протокол SSL і навіщо він потрібен?

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


Протокол SSL (Secure Socket Layers – протокол захищених сокетів), спільно розроблений Netscape Communications і RSA Data Security, дозволяє ефективно забезпечити таку безпеку. Протокол SSL забезпечує безпеку, аутентифікацію на базі сертифікатів і узгодження безпеки за встановленим мережевого з’єднанню, тому безліч компаній і продуктів прийняли SSL в якості комунікаційного протоколу.


У цій серії ми сконцентруємося на двох головних аспектах:



  1. Докладніша інформація про схему роботи SSL;
  2. детальна інформація про підтримку SSL в версіях 5.1 і 6.0.1 середовища ISC.

У даній статті досліджується SSL і пояснюється, чому його рекомендується реалізувати в середовищі ISC. У другій і третій частинах цієї серії буде представлена ​​докладна покрокова інструкція по реалізації та підключенню SSL до ISC 5.1 і 6.0.1.


По-перше, що таке SSL?


Знайомство з SSL


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


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


Цифрові сертифікати


Це підводить нас до обговорення цифрових сертифікатів, що грають важливу роль в SSL. Цифрові сертифікати в основному служать двом цілям:



Цифровий сертифікат випускається перевіреної повноважною організацією – джерелом сертифікатів (certificate authority – CA) і видається тільки на обмежений час. Після закінчення терміну дії сертифіката його необхідно замінити. Протокол SSL використовує цифрові сертифікати для обміну ключами, аутентифікації серверів і, при необхідності, аутентифікації клієнтів.


Цифровий сертифікат містить наступні фрагменти інформації про особу власника сертифіката та джерелі сертифікатів:



Підключення по SSL завжди ініціюється клієнтом викликом URL-адреси, що починається з https:// замість http://.


Типи сертифікатів


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


Є три способи отримати SSL-сертифікат:



  1. використовувати сертифікат від джерела сертифікатів;
  2. використовувати самоподпісанний сертифікат;
  3. використовувати “порожній” сертифікат

Використання сертифіката від джерела сертифікатів


Джерела сертифікатів (CA) – це організації, яким довіряє вся галузь і які займаються видачею сертифікатів в Інтернеті. Наприклад, такий сертифікат можна отримати від компанії VeriSign. Щоб отримати сертифікат, підписаний джерелом, необхідно надати достатньо інформації джерела, щоб він зміг перевірити вашу особистість. Тоді джерело створить новий сертифікат, підпише його і доставить його вам. Популярні Web-браузери заздалегідь налаштовані довіряти сертифікатам, виданим певними джерелами, так що не потрібно ніякої додаткової конфігурації для підключення клієнта через SSL до сервера, для якого був виданий сертифікат.


Використання самоподпісанного сертифіката


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


Використання “порожнього” сертифіката


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


Отже, що потрібно робити після одержання сертифікату?


Аутентифікація на стороні клієнта або сервера


Після того як сертифікат був отриманий, необхідно встановити його автентичність (аутентифікувати). У протоколі SSL є два типи аутентифікації:



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


SSL-аутентифікація клієнта дозволяє серверу перевірити особу користувача. Використовуючи ті ж прийоми, що і у випадку з аутентифікацією сервера, серверне ПЗ з підтримкою SSL може перевірити, що сертифікат клієнта і відкритий ключ дійсні і були видані джерелом сертифікатів, наявним в списку довірених джерел сервера. Це підтвердження може бути важливим, якщо, наприклад, сервер – це банк, що відправляє конфіденційну фінансову інформацію замовнику, і він хоче перевірити особу одержувача.


На малюнку 1 наведена діаграма, що ілюструє цей процес.


Малюнок 1. Процес аутентифікації між клієнтом і сервером
Процес аутентифікації між клієнтом і сервером

Файл ключів і файл зі списком довірених джерел


Реалізація протоколу SSL, використовувана в WebSphere ® Application Server, зберігає персональні сертифікати в файлі ключів SSL та сертифікати видавця у файлі зі списком довірених джерел. Файл ключів містить колекцію сертифікатів, кожен з яких може бути представлений під час встановлення SSL з’єднання для підтвердження автентичності. У файлі зі списком довірених джерел зберігається колекція сертифікатів, які вважаються достовірними і з якими буде порівнюватися представлений сертифікат під час встановлення SSL-з’єднання для перевірки автентичності.


SSL та WebSphere Application Server


Гарним прикладом реалізації SSL є його підтримка в IBM WebSphere Application Server. Система безпеки цього сервера має багаторівневу архітектуру, показану на малюнку 2.


Малюнок 2. Багаторівнева безпеку WebSphere Application Server
Багаторівнева безпеку WebSphere Application Server

Рівень мережевої безпеки забезпечує аутентифікацію на транспортному рівні, цілісність і шифрування повідомлень. Комунікації між різними серверами WebSphere Application Server можуть бути сконфігуровані на використання протоколів SSL і HTTPS. Для додаткового захисту повідомлень також можна використовувати протоколи IP Security і VPN (Virtual Private Network – віртуальна приватна мережа).


Протокол SSL забезпечує безпеку на транспортному рівні: аутентифікацію, цілісність і конфіденційність для безпечного з’єднання між клієнтом і сервером в WebSphere Application Server. Цей протокол працює поверх TCP / IP і під прикладними протоколами, такими як HTTP, LDAP, IIOP, забезпечуючи достовірність і таємність переданих даних. Залежно від конфігурації SSL на клієнті і сервері можуть бути встановлені різні рівні достовірності, цілісності даних і секретності. Розуміння основ функціонування протоколу SSL дуже важливо для правильного налаштування і досягнення необхідного рівня захисту для даних клієнта і додатки.


Деякі функції безпеки, які надаються протоколом SSL:



Протокол SSL може служити ефективним засобом забезпечення безпеки інформаційного середовища організації.


Протокол SSL використовується різними компонентами всередині WebSphere Application Server для забезпечення достовірності та конфіденційності. До цих компонентів відносяться: вбудований HTTP-транспорт, ORB і безпечний LDAP-клієнт.


Реалізація SSL, використовувана в WebSphere Application Server, – це або розширення для Java – IBM Java ™ Secure Sockets Extension (IBM JSSE), або IBM System SSL. Провайдер IBM JSSE містить еталонну реалізацію, підтримуючу протоколи SSL і TLS (Transport Layer Security – безпека транспортного рівня) і API для інтеграції. З провайдером IBM JSSE також поставляється стандартний провайдер, що надає підтримку RSA для функціональності цифрового підпису з бібліотеки JCA (Java Cryptography Architecture – Архітектура Шифрування для Java) для платформи Java 2, стандартні набори шифрів для SSL і TLS, менеджерів довірених джерел сертифікатів і ключів, що використовують технологію X509, і реалізацію технології PKCS12 для сховища цифрових сертифікатів JCA.


Конфігурація провайдера JSSE дуже схожа на конфігурацію більшості інших реалізацій SSL, наприклад GSKit, однак пару відмінностей слід виділити:



SSL і Integrated Solutions Console


Додаток ISC – це єдина середу Web-консолей адміністрування для розгортання та інтеграції консольних модулів, що дозволяє замовникам управляти рішеннями, а не конкретними продуктами IBM. Ця середу включає в себе контейнер портлетів, Java-компоненти (JMX) для управління додатками і модулі довідки Eclipse.


Для реалізації конфіденційності та шифрування можна використовувати протокол SSL. За допомогою SSL можна захистити взаємодія між Web-браузером користувача і сервером ISC. Шифрування важливо тому, що в ISC використовується аутентифікація, заснована на формах; при цьому ідентифікатор та пароль користувача для входу в систему не шифруються при пересиланні по мережі. Якщо консольному модулю потрібен доступ до внутрішнім ресурсам через безпечне з’єднання, його притулити можуть використовувати SSL.


Які переваги дає використання SSL?


Чому це так важливо? Безпечна та ефективна передача даних по відкритих комунікаційних каналах – це критичний компонент забезпечення функціонування сучасної ІТ-системи, і протокол SSL дозволяє забезпечити цю безпеку. Однак підключення SSL до середовища ISC може виявитися складним і трудомістким завданням. У чому складність цього завдання? Питання безпеки даних в середовищі Web-додатків, подібних середовищі Integrated Solutions Console, може здатися трохи розмитим для новачків, тому що безпека ІТ сама по собі – вкрай широка область, що охоплює багато різних аспектів у відкритих комунікаційних мережах.


У наступних двох статтях цієї серії буде представлена ​​організація безпеки даних на основі SSL в середовищі, заснованої на Integrated Solutions Console. Спочатку ми розглянемо настройку та включення SSL для Integrated Solutions Console 5.1 з використанням порожнього, власного та випущеного видавцем сертифікатів, а потім розберемо, як виконати ті ж дії для Integrated Solutions Console 6.0.1.

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


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

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

Ваш отзыв

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

*

*